敏捷化的訣竅: 小增量、迭代和尋求回饋?

.

小增量

實行敏捷的訣竅: 小增量、迭代和尋求回饋

.

累積專業知識

在 Feature Team 的架構下(如果你還是傳統的Component Team架構,專業知識將比較不容易串接起來,工程師做完一個功能,最大的收穫是Coding 技巧而非專業技能),開發團隊經常能由後向前延伸,也就是團隊成員直接接觸到客戶,這是最理想的清況,當程式設計人員能夠直接取得客戶回饋的時候(面對面的溝通模式),程式設計師成為一線的維運人員,運維的工作自然會務實,它不但提升了客戶的滿意度,工程師也會有大收穫。與傳統方式工程師躲在市場人員後面,那種缺乏實際事務經驗的作法,要實在多了。透過數個迭代之後,功能的成熟度與程式員的專業度都提升了,這對產品的未來也將打下良好的基礎,雖然成本高了些,但卻是直接提供客戶價值的最好作法。這一點跟公司的大小無關,純粹是你怎麼安排你的組織架構。

.

熟悉客戶行為

UX設計師總是揣摩客戶的各種行為模式,來提供PO藉以產出各式各樣協助客戶完成功能操作的需求。開發團隊如果能夠做到與客戶面對面的進行溝通,則許多的假設便能得到驗證,整個開發團隊也都將更熟悉客戶的行為模式,這在後續的開發作業上將成為更加明確、更為務實的依據。

.

需求切割太小,便很難作展示;切大了,又失去小增量的意義。

.

小增量是一種挑戰

將需求切割成片段的需求描述是一種自然的作法,但由於敏捷追求的增量是一種能讓客戶做成回饋的增量,這一點便挑戰著撰寫需求的人與負責開發的工程師在客戶認知上的素養。理想狀態是客戶就坐在距離開發團隊不遠的周圍,團隊能經常得到即時的回饋,然後便能夠做到即時的修正。但實質上;片段的功能程式可能無法表達得讓客戶有所感覺,自然就沒有回饋了,而切割成片段的抽象化程式可能又太難寫成可對照的需求;也就是需求難以描述出小程式想達到的邏輯。因此想要獲得小增量、又有好的回饋效果自然成為一種困難的挑戰。最普遍的參考方式是不斷的以SMART原則去檢核需求為依歸。

.

SMART原則

  1. 具體的 Specific:目標設定不要太抽象。
  2. 可以衡量的 Measurable:最好能以數字表現,盡量將目標量化,這將有助於規劃達成目標的行動步驟(如同OKR在制定 Key Result的關鍵指標一般)。
  3. 可以達成的Attainable:要合乎實際,而不是好高騖遠。
  4. 合理的 Reasonable:不要有互相衝突,顯得不太合理。
  5. 明確的截止期限 Time-based:要設定完成的期限,才有驅動的力量。

.

設計成足以試錯的小增量

先試錯,而不是一次就達標。要讓程式碼變成是一種試錯的工具。我們在開發程式之前先運用科學的精神。先要求組成一組可以達到成功動作的程式碼,再來進行包裝加工作業,再讓它變成完備的功能程式。而在開發作業時持續的求取外部的回饋,以確認自己在真的做對了的前提下逐步的完成功能的開發。我稱這種開發方式為 MVP式的開發方式(Minimum Viable Program, 最簡可行程式碼開發方式)。

 

善用MVP的程式撰寫方式。意思是當你只是在嘗試是否能夠做到預定功能時所撰寫的程式,所指的是沒有 Try-Catch 或是例外處理Exception等的防衛性程式碼,只有達成功能所需的最少程式碼,就稱之為MVP程式碼。這種程式碼不是最終版可以上線的程式碼,而是嘗試看看是否能達成程式目標所做的簡潔測試程式。一旦功能被確認了才有必要進行衍生成正式的功能程式。這是一種敏捷化的程式撰寫方式。他秉持以科學的精神,要求先試錯在完備開發作業的模式。

.

目的是追求創新

小增量多迭代是一種敏捷的開發方法,它只是比傳統的開發方法多了一些修正錯誤的機會。但在我們加入以「試錯」為主的理念時,犯錯所累績下來的經驗便轉換成我們擁有創新的機會所在。綜觀上圖,敏捷的小增量、迭代和尋求回饋的作業方法,讓開發作業形成一條龍式的由貫穿產品製作到客戶使用的連續作業,這也是推行DevOps時的真正目標,我們在進行 end to end的開發時成就了專業知識的累積。並在與客戶頻繁接觸,驗證需求是否實用的狀態下,對客戶行為更加熟悉了。也成就了團隊擁有創新契機的動能。.

.

(這裡省略了回饋的部份,有機會在談)

 

敏捷的意義

.

我們不是因為難而不敢作,是因為不敢而感到難.

– 古羅馬哲學家.塞內加

.

意義.png

方法: 小增量、迭代、回饋. 策略: 透明、檢核、調適. 目標: 交付價值給客戶

.

敏捷不是軟體界的專利,是一種管理、思維、文化上的變革。

.

敏捷的意義

隨著時代的快速變化,敏捷 Agile;原本是一群軟體工程師為了解決傳統軟體開發上過度依賴計畫而錯失時間與應變能力的開發模式。Agile Development泛指的就是一堆以敏捷宣言為宗旨的開發方法。其中又以稱為Scrum的框架最為流行,受到最多組織採用。但隨後大家發覺,其實Scrum 也適合運行在非軟體開發上,例如運行在維運、人資、會計 … 等專業上頭也十分受用。當然這是因為Scrum 的二位作者,在設計這個框架時,就刻意的不放進任何的軟體技術,使得這個框架具有了橫向的適應性,這是Scrum 受歡迎的一大原因。久而久之;當組織需要應變需求快速變化時,我們就稱這個組織需要提高敏捷度,也就是進行敏捷化,正是時下所流行的組織轉變;我們總是稱之為「變革」,聽起來有一點嚇人,但細看英文( Change )就沒那麼驚人了。

 

Agile development 指的是軟體開發上的敏捷開發,而Agile 敏捷 則泛指組織在追求敏捷化上的改變。如上圖;接下來我們就針對開發方法目標需求的價值來做說明。

.

敏捷開發是一套經驗主義

所謂經驗主義,就是張知識是來自實際體驗以及從目前己知情況下來做決定所獲得。對於預作「假設」這件事便顯得十分敏感,也就是不輕易的假設,所以可以稱之為是一套「務實」的開發方法,對於每一個工作流程都嚴謹的實施:透明化檢驗,與調適性的工作。開發的方法: 是採用多次迭代小增量的方式並在每一次開發完成時尋求客戶的回饋,目的是確定進行開發作業是符合客戶的需求,也就是具有實際上的價值。而對於開發團隊則採用自組織的運作方式。所謂自組織;這是一種由公司、組織充分授予團隊權力,讓他們自我管理他們自己的工作運作方式。開發團隊的效率和效用也因此得到最佳的協作。(研究發現;一個運行自組織的團隊,擁有最高的運作效能。)

.

敏捷是一種容許試錯的模式

上圖左一;我們怕犯錯,因為犯了錯誤會被責罰。但如果錯誤變小了,也就是犯了個小錯誤,責罰也就相對地變小了,當小錯誤再變得更小更小呢? 這時候你可能就在不怕犯錯了。因為夠小的錯誤對你的幫助可能遠超過責罰的代價,所以我們就能勇敢的小步前進,那怕是方向上有了偏差,也能迅速地調整回來。這便是敏捷的基本精神,可以說是科學的精神。

敏捷化就是一種試犯錯的方式,但它能被許可,被許可的原因是犯錯小卻有大收益。這就是小增量多迭代這種工作模式的精髓所在,而回饋則是告訴我們到底是做對了還是做錯了的依據。事後的反思;則是學到什麼了的經驗回顧。

.

授權與賦能

其實想達到敏捷化的效能,不是只有施行敏捷的方法才會變得敏捷的,說穿了;只要是掌握工作時能讓流程變得盡量的透明,並做到適時的檢核,然後在尋求回饋後能夠進行調適,據此持續的去調整對需求的變化,自然而然地就變得敏捷了。美國的反恐作業便是一個好例子,他們(斯坦利將軍)為了應對恐怖分子的高度機動性,努力地將原本層層授權的機制,改成先執行後授權的方式,當然前提是擁有足夠的資訊透明性,層層的團隊都能在應對資訊時擁有共同的認知(共識),才能夠在短時間內突破體系的限制進行協作,各個團隊以完成任務為首要依規。打破了傳統上以主管為輻射中心,成員則位於輻射狀的尾端,互不相干的作業方式。團隊以完成任務為主,當獲得足夠資訊時便能相互配合打破傳統的團隊與團隊之間的 Silo限制,成功的完成協作。其實;基礎也是建立在透明、檢核與持續的調適上。授權與賦能都是團隊能否及時完成任務的基礎,而關鍵實則落在主管的身上。

.

透明之於團隊是眾人的行徑,要眾人皆知。之於主管則是開誠布公、言行一致的表現。

能夠形成共識才能產出力量

.

敏捷轉型成敗在主管的敏捷性

Scrum Alliance® 和《福布斯洞察》Forbes Insights聯合發佈的一份報告顯示有 87% 的受訪者認為,CEO首席執行官是組織敏捷性重要的支持者。也就是說組織要想成功的實踐敏捷,高管必須自己先採用敏捷的思維方式,就是主管需要先敏捷起來,組織才可能轉型成功。呼應到上面所謂的授權後賦能。就是主管在充分授權後,還要能夠為團隊是否能夠完成任務,做到賦予達成任務的能力的責任。這一點牽扯到主管如何敏捷化的學習過程,可以參考Roger Schwarz 的《學習的領導打造成長的團隊》。

.

MVP的思維可以協助工程師免於迅速掉入被程式碼淹沒的困境。

謂之;最簡潔可行程式碼

.

mvp.png

工程師或PO到管理階層都需要有的概念

.

敏捷化的需求

MVP (minimum viable product) 最簡可行產品是一個只有重要核心功能,可以提供給客戶的產品,沒有其他多餘功能的產品。」它是解決方案中最簡潔的驗證方法。它還不是一個完整的解決方案,只是拿來檢驗這個需求是否是打到客戶真正的需求,客戶又有多急切需要它。與敏捷要求小增量多迭代的開發方式殊途同歸,目的正是為了尋求回饋後有修正需求的機會,也是為了要持續檢核開發的需求是否符合客戶要求的作法,正是一種MVP的理念。

 

原本MVP是 Eric Ries 拿來驗證新創理念是否有價值的作法,後來Google Ventures (GV)將它發展成一套驗證創投的程序,稱為 Design Sprint。而現在由於市場變化的加劇,這樣的做法幾乎成為所有產品開發的起步藍本。也符合了敏捷堅持開發給客戶它所需要的東西,而不是他認為他所需要的東西。在這裡;務實成了開發作業的前提,也成就了持續改善的做法。其實;整個過程的精神在衡量,運用這種方式來降低對未知事物的不確定性。

.

程式員要懂得如何刪減程式碼

這個時代撰寫程式跟維護程式碼的方式太不科學了,我們經常寫一堆沒有人用的功能,然後卻白白努力的去維護它,任由那些程式碼閒置在那裡的作法,只是平填思維時的複雜度卻不懂得要刪除(減少維護的數量)。這種只會加功能卻不懂得去探詢這個功能到底有多少人在用,應該改善作法增加使用率,還是把它移除呢?少了這種思維,這種工程師將成為下一代學寫程式人員的笑柄。

.

敏捷對需求的價值觀

開發需求」或是「交付價值」?

敏捷首重交付價值,產品開發的任何功能應該以是否能為客戶產生價值為依規。因此對需求的優先排序,始終抱以一種動態的、隨市場認知的價值進行調整的方式在做排序。也就是說;需求的來源是用戶故事地圖,優先順序則來自對市場(客戶)價值的衡量(投資報酬率)做為依據。當然;衡量是困難的,但比起運用猜測或是假設而做了一大堆無用需求而言,還是有他的價值的。

.

衡量是一種持續改善的檢核與調適。要衡量一個剛剛上線功能的價值所在,往往不是那麼的直覺,因為市場的回饋可能需要一段時間,也就是說有時間延遲的效益存在,要能夠正確詮釋衡量到的訊息,可能沒有那麼快速且完備,因此衡量是一種持續進行的工作,也需要持續改善。

衡量是一種敏捷的態度,因為沒有衡量你就不會知道自己在哪裡?也就看不清系統的全貌。更別說改善了,沒有衡量就急著作改善是盲目的,改了半天到底改對了或是改錯了也不得而知。唯有依靠最初的問題消失了,才能判斷是否做對了,這是作了最糟糕的假設。而敏捷就是要解決預作這種假設的問題。因此擁有一種務實的科學精神是不能缺少的。

雖然世上沒有不能衡量的事物,但;我們只需要衡量那些重要的事物,多做的衡量可能讓我們看得更清楚些,但時間和精力上的浪費可能就不是那麼划得來了。因此在衡量之前,弄清楚衡量的成本,值得才作。要有清晰的目標,也才能在獲得數據後順利的詮釋它的意義。

衡量要居於一種好奇的心態。它是一種動力,一種我們可以追根究柢的動能。

.

敏捷;改變心態作起

心態至上;心態變了,習慣就跟著變了,習慣變了,行為就變了;行為變了,命運就變了;命運變了,也就間接改變了自己的人生。

.

主管的態度是形成團隊的主要因素

0021.png

心態真的改變了,才是敏捷化不會重蹈覆徹的關鍵

.

註:

因為遇到必須將敏捷的理念導入非軟體產業中,所以撰寫這篇文章,因此避開軟體開發中的種種技術,刻意寫一些理念上的東西而非實務。

創新, 一件你不會相信的事

.

女:  如果;你必須跟別人說一件沒有人會相信的事,你會怎麼做?

男:  I’ll try.

<時空線索>.

0000_00_003.png

電影: 2006 <時空線索> 丹佐.華盛頓 主演

.

既然是創新的東西,必然是別人沒有想過的解題方式,也想當然耳的沒人會相信可以這麼做。也就是你說出來的時候,不會有人相信的事。

問題: 如果;你必須跟別人說一件沒有人會相信的事,你會怎麼做?

.

0000_00_004.png

敏捷就是小增量、迭代與尋求回饋

.

敏捷怎麼解題呢?

依據所謂的小增量、迭代與回饋的思維方式;首先在不失去大方向的情形下縮小你的陳述範圍,計畫多做幾次部分卻還算完備的說明,注意聽取聽者的回饋修正你的預設陳述,最後再將整個陳述串聯起來。依據聽者的反應,做好層次性的溝通(*1. ORID 提問方式)然後持續的進行。

.

2019-12-24_084943.png

焦點討論法

.

問一個好問題,比得到答案本身還重要。

.

運用焦點討論法

ORID是一套知名、易用的提問方法,一般稱之為「引導式討論法」Guided Conversation。它最棒的地方在將提問分成了4個層次的溝通,讓人們有機會用對的順序,詢問對的問題,讓被討論的話題始終可以聚焦,而不至於討論半天卻找不到重點。(註 4. 雖然看來只分成四個層次,但實際進行時是區分成好多層次,依據的是否已形成共識來作為判別是否要進入下一個層次)

ORID的四個層次提問是:

  1.  O-「Objective」:觀察外在客觀、事實。問句如下:

發生了什麼事了?你看到了什麼?它給你了什麼印象?

例: 關於這件事,你有什麼印象嗎? 你覺得呢? (引發興趣,如果他興趣缺缺,就該由上、下游移動你的破題方式)

  1.  R-「Reflective」:重視內在感受、反應。問句如下:

有什麼地方讓你很感動/驚訝/難過/開心?有什麼是你覺得比較容易或困難處理的?讓你覺得印象最深刻的地方?

例: 你為什麼會產生這種感覺呢? 跟什麼有關係。(共鳴是溝通時的起步,沒共鳴就是白講了,也就會造成陳述了半天而毫無收穫)

  1.  I-「Interpretive」:詮釋意義、價值、經驗。問句如下:

為什麼它會讓你很感動、驚訝、難過或開心的理由?它觸發你想到了什麼?有什麼領悟嗎?對你而言,意義是什麼?有學到什麼嗎?

例: 說說看這件事對你或你的朋友的意義是什麼?有什麼地方值得我們注意的。(對事情意義進行深入思考,此時將挑戰對問題的認知、範圍的界定,人們會依據自己的經驗或價值觀做成判斷以回應你的陳述)

  1.  D-「Decisional」:找出決定、行動。找出決議和行動的問句如下:

有什麼地方我們可以改變的?接下來的行動/計劃是什麼?我們需要什麼支持才能完成目標?未來要如何應用?

例: 我們該怎麼面對它? 我們進一步該做些什麼事呢? (此時再來陳述自己準備怎麼做,預期得到的效果,尋求回饋與認同)

 .

如何將一個概念轉述給他人呢?

按部就班的對內容進行陳述是基本做法。但關鍵仍在你如何分段上,小的增量若能具體而易於達成共識將是重點。也才可能獲得較具體的回饋,此時再進行溝通修正雙方的觀念差距之後,才可能產生共識。

這是一種相互學習的過程,因此一開始就應該引發聽者的興趣,他才可能會專注的聽你說話,然後你的實力,也就是對問題的了解或研究的深度,將決定可能獲得的成果。你要陳述也要專注的聆聽。然後將他人的回饋加以具體化的陳述後才可能獲得有深度的溝通然後形成初步的共識。要點是:

  • 引發聽者的興趣。
  • 加深提問的深度。
  • 專注的聆聽對方的回饋。
  • 對回饋做具體化的陳述,以取得正確的共識。

.

聽者的反應

聆聽者會依據他個人的價值觀給予回應。我常在提問前先三思後提問: 問一、自己所要陳述的是事實嗎?能驗證嗎?問二、會得到什麼效果,是否是正面的?問三、是否出自善意?答案若是能過這三問,才會做成陳述。這是陳述者的課題,也是對聽者的一種尊重。

問一個創新(沒有人想過)的議題,其實你是在探試聽者價值觀的頃向,以肯·布蘭查德 Kenneth Hartley Blanchard對情境模式(註2.情境領導)的描述,也就是二人的溝通將有可能會渡過四個階段: 一開始是熱心的生手階段,聽者表現得好奇多提問。隨後進入不置可否的憧景幻滅的學習者階段。再來轉為有問有答,顯得能幹謹慎的執行者階段。最後是形成了聽者的共識他自主的反應出他的收穫與感覺,進入獨立自主的完成者階段。這是理想的狀態,但一般情況是談話可能會終止在任何一個階段。

聽者可能屬於以下幾類: 毫無興趣者、樂於守成者、勇於挑戰者或是創新者。前二者的回答可能都是否定的;「就我的認知或我目前的環境不太可能這麼做」。對處事屬勇於挑戰者,首先想到的是,自己會這麼做嗎? 可能的回答是「我先來試試看」。創新者則將熱衷的與你一搭一唱起來,興奮的程度比你還要高(此時你可已考慮,這個 idea 還不錯?)。

※ 聽者回覆的方式是沒有對錯的,完全依據他個人的價值觀,不應該有過度的期望。

.

不可能的事.png

身為顧問最常聽見的一種回覆

.

上圖示 Toyota TPS 旗下的敏捷教練 Toda 先生在 DevOpsDays 2019 上海的演講,現場他陳述了TPS 的一個專案 OBEYA 團隊進行所謂的 One Week Sprint以及 One Hour Task的過程。引發現場講師群的熱烈討論,最多的陳述是「不可能的,我們的環境太複雜」(屬於樂於守成者)。但OBEYA團隊卻做到了(屬於勇於挑戰者或是創新者)。這一點表現出了 TPS OBEYA 團隊的敏捷化程度成就了他們在DevOps上的表現。

.

看見的力量

讓聽者看見最小可行性的產品 minimum viable productMVP(註 5),可能是最有說服力的一種方式它可以是圖形、簡報檔 PPT或是實體物件的模擬,只要能做到被看見、展現出它特定的意義、能被意識到了,這就是一種有效的做法。這種做法;也可能是最有效的一種方法。但身體力行的作法往往要付出更高的成本,並獲得更高的失敗率,可參考Google 的 design sprint一書,翻譯成「衝刺計畫」是Google 拿來解決創投提案的一種敏捷方法。

.

註 1.  焦點討論法:ORID提問方式

註 2.  情境領導 Situational Leadership

          保罗·荷西肯.布兰乍得 1969 所創理論,該理論已被納入管理學的教課書中。

註 3. DevOpsDays 2019 上海

IMG20191208105059.jpg

Koichiro Toda 接受大會主席孫振鵬先生的頒獎

.

註 4. About ORID 焦點討論法 – 讀書會的範例

讀書會.png

註 5. MVP,minimum viable product  最小可行性的產品

是新產品開發中的名詞,是指有部份機能,恰好可以讓設計者表達其核心設計概念的產品。設計者可以進行驗證式學習,根據使用者的回饋,進一步了解使用情形,並且繼續開發此產品 。最小可行產品一詞是由法蘭克·羅賓生 Frank Robinson所創,因史蒂夫·布蘭克埃里克·萊斯 (The Lean Startup 一書的作者)的使用而流行。

.

 

敏捷黃金圈

敏捷是一種潮流與趨勢

2001年二月在美國 猶他州一個叫做Snow Bird的滑雪聖地聚集了17位著名的軟體開發專家,為了解決專案開發失敗率過高的問題,提出了Agile 敏捷開發這個概念,並共同簽署了《敏捷宣言》(*1),目的是為了改變軟體界習以為常的一種稱為傳統瀑布式的開發方法。看起來這只是電腦軟體界的一場改革聲浪,但實質上這宣告的是一種時代的趨勢。就在同年的9月,在美國本土的紐約市發生一系列自殺式恐怖襲擊事件,「蓋達組織」承認其發動此次襲擊;當天早晨,19名蓋達組織恐怖分子劫持4架民航客機。劫持者故意使其中兩架飛機分別衝撞紐約世界貿易中心雙塔,造成飛機上的所有人和在建築物中許多人死亡;兩座建築均在兩小時內倒塌,並導致臨近的其他建築被摧毀或損壞,總共有2,749人在這次襲擊中死亡或失蹤。它引發美國政府深切的檢討,如何來防犯恐怖分子這種快速瘋狂的襲擊行為。以目前組織層層回報的官僚機制是絕對無法做到快速回應的,因此政府需要敏捷化(*2,參考自《賦能》斯坦利.麥克格里斯特將軍等人所著)。

.

000.png

2001年發生的事件

.

※ 敏捷反恐單位(斯坦利.麥克格里斯特將軍)都採用了: 透明、檢核與調適的原則來處理訊息多變的問題。讓整個組織可以共享訊息、不分彼此一起協同合作,達到高績效團隊的產出表現。

.

0001_00_02.png

敏捷與反恐怖組織破壞行動都採用了: 透明、檢核與調適的原則

.

潮流告訴我們,無論是在商場上還是戰場上,快速反應和適應能力都至關重要,在技術和干擾性力量導致變革速度加快的時代更是如此。它要求我們必須有新的溝通方式,有新的協作方式。當今世界,創造是協同合作的產物,創新亦是團隊努力的結果。任何想在潮流上生存下來的企業或組織,都必須有一套快速應對變化的能力,在商場上我們稱之為敏捷 Agile, 在戰場上斯坦利將軍稱之為授權與賦能。而這二者的解題方法也都相同,也就是做到透明、檢核與調適,我稱之為「敏捷的黃金圈」。

.

003.png

類似提問Why-How-What 黃金圈的敏捷黃金圈

.

斯坦利將軍的激進作法是: 為了透明化;他甚至不願在自己的辦公室裡接聽重要電話,反過來在開放的辦公區間裡大聲的溝通講話,目的是要讓幕僚們能夠知道足夠的訊息,並充分了解自己的決策方式。並經常要求下屬們替自己做決策,這一點解決了,深更半夜下屬敲自己的房門來要求簽署授權的問題,他的說詞是:「如果你認為我聽完了你的報告後,會怎樣做決定,那就盡快去執行吧,事後再來跟我報備,不要錯失了最好的執行時機」,這為資訊透明打開了大門,也為及時反應開啟了優勢的先機。

 

反觀軟體界的諸多敏捷開發方法就溫和多了,運用角色的界定來進行分工,用會議的方式來達成透明、檢核與調適

.

透明檢核調適.png

從一個小團隊的角度做到透明、檢核與調適

.

透明 Transparency

看見或聽見是一種透明化的基礎,但僅僅是看到相同的資訊並不能保證任何事情,觀測者對所看見的事物需要形成一種共同的觀點,認知相同才是真正的透明,也就是達到看到了並擁有相同的認知,也就是所謂認知上的透明。

.

0000_02

Scrum運用每日的站立會議讓團隊的工作達到透明(91 App請支源收銀團隊)

.

檢核 Inspection

Review會議是Scrum用來檢驗遞增成品和評估是否調整產品需求的會議。下圖中將會議流程繪製成看板,讓會議內容標示在看板上,讓會議的進行透明化並自然形成紀錄。

.

0000_03.png

Scrum在Sprint結束時運用公開展示進行檢核

.

調適 Adaptation

回顧會議(Retrospective)提供 Scrum 團隊一個自我檢驗的機會以及做出一個可制定的改進計劃用來使用在下一個Sprint。下圖中將會議流程繪製成看板,目的在讓會議結果透明化並形成共識,以期待團隊能由其中得到(學習)最多。

.

0000_04.png

Scrum運用回顧會議讓團隊有機會自省調適

.

敏捷黃金圈

取這個名字是參考自Simon Sinek的黃金圈Golden Circle 理論(*3)。敏捷黃金圈的目的在闡述先透明後進行檢驗並在度量後作成調適。原因是害怕工程人員常犯的錯誤就是看見問題後就一口氣落入解題的陷阱,看起來很正常,但黃金圈理論跟我們說應該由內往外,先問Why在循序問How再到 What,先弄清楚為何而作,確定目標後再開始思考解題之道。秩序錯了可能會平白作了許多白工,努力錯了方向事後還要受到返工的時間浪費。

 

敏捷黃金圈則把透明放在內圈,強調的是避免作了猜測式的假設,應該在看見事實接著確認自己與他人有著相同的認知後,再向外移,接著透過檢核取得度量後依此進行調整。

 

透明必須是小增量的,也就是居於小的功能,一個不是很大的區塊,它能夠讓我們一目了然並造成共識的增量。如果太大了則難免變得複雜而容易形成他人的判讀錯誤,未能形成真正的共識。因此小增量是必須的。

.

※  如何讓工程師不怕犯錯呢? 請將工作量盡量切小,每次做一件小的工作,越小的工作可以讓人們越不害怕犯錯,因為這個小時我做錯了,下個小時補回來就好了,一點也不會害怕,原因是容易修正沒甚麼好怕的,自然就不怕犯錯了。又;當工作範圍很小的時候,才可能輕易達成共識。

 

檢核必須是迭代的。一次性的檢核方式容易造成沒有機會再回頭來修正,因此要適度的迭代的進行檢核,才有迭代進行改善的機會。另外;檢核必須依靠數據,用認知進行檢核是不明確的,即便你得到改善後也無從確認是否達到改善的目標。這一點可以依據OKR設定關鍵目標的方式來進行,效果會更好。

 

調適必須是有回饋的。沒有回饋就沒有敏捷,因為你無從知道客戶是喜歡還是不喜歡,我們作對了還是做錯了,而又該從哪一個方向去修正改善呢? 因此修正或變來變去的依據便是經常詢問(調研)客戶真正要的是什麼,是我們剛剛做完的功能呢? 還是另有其物。因此進行調適時務必要有明確的依據,也就是只有在擁有回饋的管道時我們才作調整,調整也才有意義。

 

而 Scrum 就是依據這樣的理念所設計出來的一種框架。

.

scrum framework.png

Scrum是 Jeff Sutherland 和 Ken Schwaber 所創的敏捷開發框架

.

敏捷黃金圈有什麼用呢?

透明之於個人是開誠布公,在行為上的言行一致,也就是知行合一的理念。檢核之於個人則可避免心智上的誤區,事事求驗證可避免過多錯誤的假設,誤導了你的認知。調適之於個人便是持續改善,行事力求回饋,用好奇心來鼓舞創新,時時聽取別人的意見隨時調整自我,它更能增進我們處理複雜問題的能力。

.

註 1. 敏捷宣言

藉著親自並協助他人進行軟體開發,我們正致力於發掘更優良的軟體開發方法。敏捷的價值觀:

  • 個人與互動 重於 流程與工具
  • 可用的軟體 重於 詳盡的文件
  • 與客戶合作 重於 合約協商 
  •  回應變化 重於 遵循計劃 

也就是說,雖然右側項目有其價值,但我們更重視左側項目。

.

註 2. 《賦能》斯坦利.麥克格里斯特將軍所著

賦能:打造應對不確定性的敏捷團隊,

作者: 斯坦利·麥克里斯特爾、坦吐姆·科林斯、戴維·西爾弗曼、克里斯·富塞爾合著。

斯坦利·麥克里斯特爾退役時為四星上將。

.

註 3. 參考自著名演講家 Simon Sinek 的黃金圈Golden Circle 理論

先問,為什麼?:顛覆慣性思考的黃金圈理論,啟動你的感召領導力

團隊績效 1+1=?

目前男子400米賽跑世界紀錄保持者是南非選手Wayde van Niekerk。他在2016年8月14日創下了43.03秒的記錄(室內400米賽跑的世界記錄則是Michael Norman創下的44.52秒,由此可見環境的影響力)。反觀;團體的四百公尺四人接力則是由波特 Usain Bolt所帶領的牙買加團隊以36秒84寫下的世界紀錄。可以看出團隊合作的結果遠遠勝過個人成績。四百接力除了首棒成員是靠自己的力量跑完100公尺之外,其他幾棒都是奠基在別人交棒時的初速上,才能讓自己跑出超過自己能力的好成績。這也說明了集體比個體更有力量的表現,而組織與公司則正是展現這件事的地方。

.

若是用團隊36秒84的成績去除以4可以得到平均每個人跑出了9.21 秒,也就是大家都跑出了超越他個人的最佳成績,也都超越了波特的世界紀錄(9.58秒)。這便是團隊合作的力量。

.

0001_03

參考自《高績效教練》Sir. John whitmore 的佳作

.

  • 個人 400米 世界紀錄(室外)  =  43.03 秒
  • 個人 400米 世界紀錄(室內) =  44.52 秒
  • 團隊接力400米 世界紀錄= 36秒84 
  • 36秒84 除以 4 = 9.21秒 ; 超越了任何人類跑100米的成績

.

團隊的績效曲線

來自國際績效顧問公司所建立的績效曲線(Performance curve)模式圖(左側圖示),圖中每向右邊移動,就表示公司會得到更好的利潤。縱軸的度量是績效的高低,橫軸則是企業文化所展現的特質,被區分成四個區間,剛好對照到右側的馬斯洛需求金字塔的四個分類。需求金字塔描述了人們隨著生活品質的提升,對達到滿足的激勵要素也隨之改變,它們可以區分成四個較具體的階段,分別是由最底層的滿足生存條件,一直向上提升至精神層面的價值定義。它闡述了:

  • 感情驅動」;凡事表現得具有可預測性,展現出最低程度的覺察力和責任感。
  • 依賴」;組織強調穩定經營,單向的溝通模式,展現出低到中的覺察力和責任感。
  • 獨立」;特色是組織支持創新和培育個人,相信可以展現他的才能,展現出中到高的覺察力和責任感。
  • 相互依存」;強烈的教練文化,團隊相互依賴以獲取高績效,展現出高的覺察力和責任感。

強調企業若要追求高績效就要放棄傳統的高壓管理風格,主管必須將管理轉變為教練式的領導風格,才能創造出團隊的高績效表現。這種理念應該早已是管理學裡不爭的事實了,但令人驚訝的是還有那麼多企業那麼多的公司依然依據古老不合宜的方式在經營著,令人感嘆;這些主管難道都沒上過管理學嗎?

 

團隊績效 1+1≧2

當團隊文化展現出一種只求生存的心態,也就是「感情驅動」的特質時,團隊中充斥著私心,人們只在意自己的工作,缺少互動、鮮少溝通,組織也不鼓勵成員投入,HR相對的缺乏人員的培育計畫。此時組織成員展現的是低績效與低責任感。但隨著組織開始成長,團隊成員彼此之間逐漸發展出互動關係,但受限於企業規範,人們雖然逐漸擁有歸屬感,但聽命行事的組織行為仍殘害著察覺性跟應該有的責任感,這是「依賴」階段的特色。

 

此時是真正需要轉變的時期,也就是管理層能夠放棄傳統命令控制式的管理模式,以尊重人性為本,轉而運用敏捷式的授權與賦能方式,運用雙向溝通來提升成員的責任感,授權讓團隊自我管理,就是所謂的「自組織」,運用團隊自己管理自己的方式,讓團隊成員進入自我察覺與自我負責的情境,促使他們逐漸培養出追求傑出表現的意願。這便是「獨立」階段所展現出來的特色,此時變革顯得逐漸生效,團隊渴望追求進一步的成功慾望,此時的 1+1戰力便已經開始超越2的績效表現,成員與成員之間開始相互依賴,彼此的常態溝通成就了默契,團隊開始展現落實企業整體的目標,團隊成員開始在意自己是為何而戰,也就是自己能為企業做些什麼,成員以自我實現的方式在工作著,處處追求傑出,團隊呈現高績效的表現,也就是達到「相互依存」的模式。當團隊能以發揮潛能的方式在進行工作時,團隊績效 1+1便遠大於2了。這也是敏捷開發為何對開發週期的命名成為Sprint的目的。

.

SPRINT 衝刺

.

結語

高績效的團隊源自於組織擁有高績效的團隊文化,而領導者無疑地是對團隊文化影響最大的成員,因此領導者的領導風格將很大一部分的影響著團隊的表現。

.

0008.png

領導者的態度影響團隊行為的交互螺旋模型

.

上圖中,描述的是領導者的態度(心態)形成他的行事作為,而團隊透過對領導者行為的解讀,形成團隊做事時的依據,而團隊的行為表現看在領導者的眼裡又進一步強化了領導者對團隊的態度,如此形成了一個持續交互影響的學習過程。這一點說明領導者在變革時所扮演的角色,在《高績效教練》作者Sir. John whitmore建議領導者要運用正確的教練模式來領導團隊產生高績效。如上述的績效曲線所陳述的團隊融合階段。當團隊處於傳統的命令控制式模式時,干擾是影響績效的最大因素,但一旦團隊邁入敏捷化的轉變後,也就是領導者採用了讓團隊自組織的形式,團隊能夠自主的管理自己,領導者又能夠採用教練式的引導方式來管理團隊,此時決定團隊績效的主要因素便成了是否能夠激發團隊潛能便成為了主因。

 

你的團隊在哪裡呢?

如果要你去評估隔壁的團隊屬於績效曲線的哪一個階段,這一點;似乎沒有太大困難,首先擬定一些問題,做幾次訪談大概就能有一個輪廓了。但若是要你說說你自己的團隊狀態位於績效曲線哪裡呢? 主觀性就會讓人比較難做成判斷了,一個可行的方式,是讓團隊交互做評估,這倒是一個可行的方式。

.

註: 《高績效教練》作者Sir. John whitmore,全球熱賣超過 1,000,000本的暢銷書。

最新版是 25周年增訂本,就是第五版。

 

變革 – 從改變心態開始

Mindset「心態」是一種看待事情的方式,它會形塑你的想法、感受與行為。因此在作任何改變前,先要改變讓你這麼作的心態.

– Roger Schwarz

.

0010.png

心態產生行為獲取結果

.
千金難買早知道;我們常常會在事後回憶、後悔事前為什麼沒想到要這麼作呢!下定決心,下次再遇見類似的事絕不會放過,但事實是你一再的錯過。為什麼呢?

》那是因為心態沒有變過來的關係。

.

變革 – 從改變心態開始

實施組織變革時,主管首先要改變自己的心態。我們要永遠選擇以讓團隊能夠專注的工作為主。首先我們要進行假設,針對領導者該做些什麼、如何跟團隊互動的某些基本假設與價值進行構思,要確定領導者與團隊成員之間的角色。

.

變革;我們要永遠選擇以讓團隊能夠專注的工作為主。

.

從採用新的基本假設開始 (註1): – 變革是眾人的事

  • 管理的責任人人有分。
  • 團隊成員也要改變。
  • 團隊成員要能彼此分擔責任。

》是這些假設讓你心態改變,所以表現的行為就會與從前不同、產生改變。

四件讓改變開始的事:

  • 整個團隊依循相同的指導原則與改變。
  • 調整結構(系統、政策與流程)以支持這些新假設。
  • 採用一個你可以公開分享,從團隊成員到整個組織都能使用的方法。
  • 在所有關係中建立互信。

.

學會如何脫離困境 – 從改變心態開始

程式員容易陷入困境,只要需求估少了或是它開始改變了,你就給自己製造了一個陷入困境的深淵。其實困境都是出自你自己內心的煎熬,是一種心態的問題,只要保持事事覺察與責任感,解決方法是坦承、透明與信任。

.

脫離困境Traps三原則:

原則 1、當一個人勇敢地面對問題,內心就會湧出積極向上的力量。

原則 2、人生短暫且多變化,好事或壞事都不會持續太久。

Everything will be ok in the end, if it’s not ok, it’s not in the end.

原則 3、雖然人生短暫,卻有足夠的時間解決困難;雖然人生多變,未來的趨勢卻總是有跡可循的。

.

註1. The Skilled Facilitator 專業引導技巧》 by Roger Schwarz

註2. 困境下的迫害

  • 強大壓力下的自我失常。
  • 因誤判而加大的延誤。

 

程式員的察覺與責任感

著名的網球教練 提摩西·高威 (Timothy Gallwey),提出了一種新的教練方法,用於指導和發展個人和專業卓越的各種領域,他稱之為“內心遊戲” Inner game(註1),由於效果出奇的好,因此顛覆了傳統的教練教學模式(嚴厲的專業知識傳授模式),它被廣泛地運用在包括網球、高爾夫、音樂、滑雪和內心遊戲等。是一種以激發選手自我察覺力與責任感為主的教練模式。他強調的是針對選手培養發揮潛能而不是專業技巧地教學。具體的公式是:

 

選手的表現  = 潛能 (能力 + 經驗)  – 干擾

 

這是一個放諸四海皆準的法則,即便是引用在程式員身上也功效可見

.

0087_2.png

高效學習的二大要素

.

寫程式是一種學習的過程

程式員依靠對語法的記憶,一點一滴輸入程式碼以組成一個具有特殊意義的邏輯單元,然後再組合諸多的邏輯單元成較大的程式拿來解決特定的問題。在開發的過程中我們持續運用編譯工具來驗證這些程式碼及我們所創造的邏輯單元是否正確,這個過程幾乎都是一個人蒙著頭在進行的學習過程(當然Pair Programming可以讓這個過程具有共享的特色,但很難維持較長久的時間),因此大部分的程式碼是由一個人獨自完成的。所以自我察覺的能力將決定程式被撰寫出來的快慢與品質。高威教練想證明的是運動員並非完全依靠天賦的能力,實質上是可以依靠訓練來提升這種自我學習的能力的,這便是一個人在學習的過程中,自我覺察的能力,也就是察覺力 Awareness.

.

  • 察覺力就是知道周遭發生了什麼事?
  • 自我察覺也就是知道自己當下的體驗。

– (轉換成軟體開發,就是對於要開發的需求有著真正深刻的理解)

.

如何培養察覺力呢?

「提升察覺力的方法很多,每個人都不同。」:高績效教練(註2)一書的作者 John Whitmore 把它定義成;自發性的相關資訊的高品質輸入。並且強調「全心投入」就能夠擁有高品質的輸出。這也表明了不受干擾,其實是察覺力得以發揮效能最重要的因素。

提升察覺力

一種自我察覺(self – awareness)的方式,也就是學會如何 「客觀的看待自己」,就是要盡量維持好的情緒多傾聽常常反省(寫日記或做成紀錄以便事後回顧)。要常常告誡自己專注於當下、擁有正念,並對自己行事前總是要求弄清楚目標,這可以透過自我提問的方式來達成(因為不管自己在做什麼事,做事時知道事情的原委也能有很大的助益。)

下面列出一些可以用來問自己的問題,進行自我改善:

  • 我現在正想要達成什麼事情?
  • 我做的哪些事情是有效?
  • 我做了哪些拖累了自己的事情?
  • 我應該做什麼來改變自己呢?

.

熱情是程式員得以維持專注的要素

你的察覺力將隨著慢慢退去的熱情而逐漸下降。當我們能夠坐上幾個鐘頭專注的在寫程式,等告一段落時再來迎接接下來的腰酸背痛,這便是專注。是程式員最值得珍惜的地方。能夠持續支撐它的則是責任感。責任感是一種自覺主動地做好分內分外一切有益事情的精神狀態。

 

責任感則來自自主權,它可以持續支撐我們在工作上的熱情,進而表現出較高的績效。因此針對目標的自主權,團隊成員在應該如何做、誰來做、何時做以及做什麼這些方面獲得一定的選擇和自主權。則責任感自會降臨。

 

結語

程式員如何提升撰寫程式的效能呢? 增加察覺力和責任感是二個關鍵的要素。由於察覺力是學習成效的主要因素,因此培養更好的察覺力便成了程式員提升撰寫程式效能的利器。責任感則是激發程式員持續Coding熱情的助力,此二者相輔相成。

察覺力來自於清楚自己正在做什麼、為什麼這麼做及目標是什麼。所以程式員必須對正在工作的問題有著徹底的了解,自然能有效率的解題。換句話說;就是對於要開發的需求有著真正深刻的理解。而敏捷開發則是一種邊做邊學,運用小增量、迭代逐步深入學習的方法。

.

註1.《比賽,從心開始》作者: 提摩西‧高威

是第一本談論「運動心理學」的書。它運用了接近「禪學」的思想,為運動選手缺乏自信、緊張、無法專注等問題,提出了全新的學習方法。

他提倡要用引導(而不是教導)的方式,拋棄評判之心、練習專注、學會如何觀察自己,進而達到「自然而然的進步」。

它將「內心遊戲」的概念帶到企業界,開展出「教練式領導」(coaching leadership)這個全新領域。高威也因此被稱為「教練之父」。

註2. 參考自 Sir John Whitmore 名著《高績效教練》一書。