讓敏捷更敏捷的「假說思考」

身為敏捷教練;可能一輩子都會不停地在尋找能夠讓敏捷更加敏捷的方法(它可能就是我這輩子的無限賽局了)。其實可以推廣的理念很多,例如 Dan North刻意發現(Deliberate Discovery),就是一個讓敏捷開發更早開始的好概念。應該算是團隊在開始開發行為之前的前置處理動作吧。這種讓開發者在還沒開始動手之前就能先加強相關domain knowhow的做法(增進開發專案的相關知識),對即將到來的開發作業一定會有著某種程度上的幫助的(與prototype 或MVP應該有著一樣的貢獻)。波士頓諮詢公司BCG的「假說思考」在某種形式上也算是一個前置思考的方法,但要更讓人驚艷。

若能譯成「假設驅動管理」會更直覺些

我們習慣的思考方式

一般人在面對問題的時候,都會採取先搜集、分析資訊再做決策。也就是依據戴明博士的 PDCA循環(註1)做解題的動作。這樣做的結果往往容易花費大量的時間在做資料蒐集(尤其是在現今資訊過量的時代),卻未能及時的拿出解決問題的策略(敏捷化的團隊則是在收集了部分足夠開工的資訊後就啟動Sprint,這種啟動方式避免了過度分析資料的做法。說起來是一種快速啟動作業的開發方式)。但其實;在這個資訊爆炸的時代「捨棄資訊比搜集資訊更重要」。因此而衍生出來一種更快速的解題模式,它的做法是先構建假說,並在向前推進工作的同時,對假說加以驗證,然後持續探索解決策略。這是一種既科學又符合敏捷精神的作法;這種方式就稱為「假說思考」方式。

在VUCA的時代下,未來是多變、不確定的,因此無論多大規模的企業,都需要應對未來的一切變化。所以,應該培養並持續累積顧問式的經驗法則,如此便能在遭遇問題時立即(先)做假設,以快速的回應來爭去時效。這對任何企業的管理者來說,藉由累積的經驗來掌握假說思考方法都是至關重要的。

假說(hypothesis):未經證明而最接近答案的解答。

內田和成

假說思考: 就是先做假設,然後再去驗證它的對錯,藉此避免過度蒐集資訊,而浪費太多時間在做分析上。它是以結論為起點的一種思考模式。 從右腦大膽假設,再交由左腦細心求證。可分成二個先後階段: 首先藉由假說找到真正的課題。再續用假說尋求解決課題的最佳答案或最適決策。

假說思考:先採用假設解決實際問題

首先要有假説 – 第一條法則: 捨棄資訊比搜集資訊更重要

提出假説的好處是能加速解決問題的速度,而且能避免一開始就陷入資訊洪流中,藉著思考描繪問題框架(避免一開始就Google!)。有經驗的顧問們通常都能見微知著,從簡單的細節看出問題的模式(pattern),然後提出假説並釐清問題解決流程。不過就算是新手,也別害怕提出假説,一旦發現錯誤了,只要能心平氣和地修正就好,千萬不要死守假説或不必要的資訊。最後要相信,對顧問而言;假説能力遠比分析能力更重要,因為唯有能提出解決方案的人才能成為顧問因而立足商場,如果過度重視分析能力而身陷資料流沙中,便無法幫助企業解決問題。

在目標確定之後,透過大家Brain Storming ,列出種種假設,然後挑選最被看好的幾個依序去分析它們,再去驗證它們,如果錯了就換下一個來做,發現對了就挖到寶了,這麼做;怎麼說都比全部去分析、驗證要划得來許多,省下不少時間。是先快速做假設,看起來很盲目但其實對於一開始我燜面對無知的探討實在是很科學,能快速的過濾多做假設所造成的雜訊,也提升了許多效能。

避免窮盡分析網羅思考

網羅思考vs假説思考。網羅思考就如同人機對弈時AlphaGo所採用的窮盡分析法,每下一步棋,電腦就得將所有的可能性都分析一遍,強調決策一定要基於完整的資訊和分析角度。這在超級電腦上或許行得通,但在瞬息萬變的商業市場上則是行不通的,一方面商業發展的可能性無窮無盡,另一方面它變化快速,而網羅思考耗時耗力,是無法滿足即時分析的需求而快速的產生解決方案的。

假說思考讓敏捷更加敏捷

假說思考的特色是;於一開始就從事物全貌切入,再來思考如何解決個別問題。這一點與敏捷強調以小增量、多迭代與尋求回饋的方式十分相似。敏捷避開了傳統開發法在前置分析上的時間浪費。但這麼做只縮小了在開發量上資源的浪費,並未減少需要收集資訊量的大小,若是再加上預做假說的思考模式,就可以大量減少資訊收集的範疇(對系統思維System Thinking而言;就是先運用假設來縮小系統的邊界),而在分析、求證上只針對該假設的範疇來進行,在時間上更符合小增量、多迭代的思維,然後在透過驗證假設是否正確的嘗試得到實質上的回饋。做為新假說的依據。所以說;假說思考的方式能讓敏捷更加敏捷,也更能聚焦在一個基於假說上的小增量上頭。也更符合科學精神。

假說思考是來自波士頓諮詢公司BCG的策略思維方法。(請參考内田和成所著的《假說思考:培養邊做邊學的能力,讓你迅速解決問題》,原著標題是The BCG Way—The Art of Hypothesis-driven Management) 是一種思維模式也是一種顧問需要養成的習慣。就是在解題時從資訊還相當有限的初期階段起,就不斷思考問題全貌與結論的方法。先做假說;這麼做可以有效的減少需要考慮的系統範圍,一旦系統範圍縮小了,就能讓我們更專注在小事件的驗證上,小範圍能便於快速的進行驗證,又能以逐步釐清的方式去看見問題事件的全貌。它符合敏捷開發小增量的核心觀念,讓我們專注的聚焦於小的驗證上頭,逐步去釐清問題的看見它的全貌。

要了解自己的第一步,就是做出一個決定 ;然後去質疑自己關於自己的種種預設,去積極考證我們在別人眼裡的樣子,去帶著一種積極的思維和接納自我的態度去追求真實。  

-《深度洞察力》,TASHA EURICH

傳統思維 vs 假說思維 的敏捷性

傳統開發法是認為仔細的分析後就能按部就班地完成專案。相對的;敏捷開發追求邊做邊學,再蒐集足夠開工的資訊時就快速的開工,以應對變化為常態的一種開發方式,進行方法是衝刺(sprint,全力邁進)的小增量、多迭代與尋求回饋的開發作業。傳統對問題的思考模式是認為資訊收集的越多,就越能確保決策會越正確。假說思考法則認為: 捨棄資訊比搜集資訊更重要。運用假說來縮小驗證的範圍,迅速的邁入求解的途徑。

假說思考的好處

1.  解決問題的速度倍增:     以答案為起點的做法,讓該做什麼變得清楚分明。

2. 能夠累積出解題的路徑,有效的「定位問題」: 如果在遇到問題的同時,就能夠在心裡建立「暫時的解答」,便可以很快的去「驗證這個暫時的解答是否正確」。

3. 假說無論對錯,驗證完後(/) 都能夠讓下步更清晰 : 如果目前假說是對的,可以深入分析,並試圖提出可能的解決方案。如果發現假說不對,便可以快速的換到下一個假說去驗證它。

4. 可以有效累績、運用過去的經驗 :「假說」是基於現有知識的最佳解,因此隨著你對於問題的相關領域的了解越來越深,或是日積月累解決問題的經驗越來越豐富,很有可能在一開始就提出了正確的假說。因此假說暫解是善用及累積經驗的好方法。

以假說(設)為基礎的思考方式,是一種以最短時間有效達成目標的方法

小結

敏捷開發Agile development不是一種快速的開發方法,它是應對需求多變的一種開發方法。目的是避免軟體在專案前期花費太多時間進行分析、文件製作的工作上,而在遇到變化時反而因為依循計畫而失去彈性的缺失。波士頓諮詢公司BCG的「假說思考」則更進一步的依據工作者的經驗先進行假說,有效的縮小了問題系統的開發範籌,雖然它是顧問公司所用的一種快速取樣驗證的手法,但在搭配以敏捷化的小增量、多迭代與尋求回饋的增量,就更能展現出它的效益了,也更能符合多變的VUCA時代的問題特徵。

假說思考法是一種顧問的策略模式。是一種吻合科學實驗的方法(若是你沒先做好假設就開始做實驗,當取得實驗數據時;反而會不知如何去詮釋)。它以為在問題出現的前期,即提出假説的好處是能加速解決問題的速度,而且能避免一開始就陷入在資訊洪流因為吸收過多訊息而造成分析上的時間浪費。這是一種基於捨棄資訊比搜集資訊更重要的實際行動。核心觀念是遇到問題時,先「想」或猜(依據經驗而來)有什麼可行的解法,接著再進行數據的收集與分析驗證。也就是所謂的「大膽假設、小心求證」的科學實驗精神。這與我們一般在做策略規劃的流程: 先分析再設定目標然後擬定對策的正規思考方式不同(1.現況、2.目標、3.分析、4. 擬定策略、5.資源投入與建議的五步驟解題流程)。假說思考法是直接跳到最後一步(步驟五、資源投入與建議)上,依靠顧問的直覺與經驗快速的給予解題建議。但它是一種暫時性的答案,還需要驗證,透過驗證才能確認問題的全貌與結論。

《假說思考法》作者內田和成在書裡的定義;所謂「假說」,是指在蒐集資料過程、著手分析之前先做的「暫時性答案」。「假說思考」可說是一種思維模式或是習慣,從資訊還相當有限的階段起,就不斷思考問題全貌與結論。換句話說;是一種刻意發現。 換言之,假說思考法的精髓在於”假設可能的答案”,而這個答案可能是整體問題的答案,特定步驟的答案或是支援論點數據的答案,而它只是一個”暫時的答案”。所以問題來了,如何進行此假設,或是如何提升假設的準確度與深度呢?這便是顧問公司所擁有的實力與經驗了。也就是我們常常聽到的麥肯錫顧問公司Mckinsey或波士頓顧問公司BCG這類的顧問公司,在為客戶提案之前早已完成了”70%的結果”,而這七成的結果其實就是從經驗或過往案例所推演出來的假說結果。說穿了就是依靠顧問們在實戰經驗中累積下來的相關經驗,正是敏捷開發中所謂的經驗主義下的快速產物了。

解決方案先行

所有的客戶都急切的想從顧問口中聽到解決方案,為了有效地說服客戶,我們花費大量精力去尋找合適的資料,繪製複雜的表格,製作大量的PPT,為的是用精準的數據來打動聽者。但這種方法並不怎麼有效,我們的溝通對象根本沒有時間和耐心來聽枯燥的報告,他們需要的是解決方案,而且立刻就想知道!因此假說思考法便顯得如此可貴。因此要持續累積經驗形成模式(pattern)才不會讓我們弄巧成拙。就如《極簡思考》作者Mike Ferriolo所言(註3. 推廣結構化思維);假設是一種實驗性的、可在未來分析中做進一步測試的觀察、現象或疑問。在結構化思維過程中,假設是你在第一步中為問題找到的答案,你之後將以它為核心進行分析,從而將其證明或推翻。不要擔心,在你把方案徹底想好前,你無須將結論與任何利益相關人分享,一些利益相關人直到你做完了全部論證才能看到你的想法。跟科學實驗相同,實驗室的初步假設往往與事實有著巨大的差異,但最終你卻端出了極具價值的原理。請記住,當你埋首於分析的時候,你並不能創造任何價值。

假說先行的思考方式;對於專案負責人PO或資料分析團隊Data Team而言,都是一種先定位後驗證的科學式思維。運用系統思維的說法是一種能讓我們面對眾多的選擇中縮減範圍畫出系統邊界再求證的做法。對專案負責人PO而言,在面對龐大的產品需求時,可以大膽的假設客戶只需要這些足夠的需求,就能接受我們的產品並感到滿意。因此而勇敢的排除了那些次要的功能,選擇依據假設先完成部分的功能,讓開發時間變得簡短了。然後在以客戶的回饋作為驗證,修正假設。若假設是不符合客戶的期望,再修正假設決定是那些功能需要既須開發來滿足假設。對於資料分析團隊言,則可以先鎖定假設,不致於被蒐集到的龐大資料所迷惑,以至於難以做成分析結論。並在持續收集到的資訊中驗證假設是否正確,並持續的修正假設來獲取結論。

註1. 戴明博士的PDCA 循環是針對品質工作按規劃、執行、查核與行動來進行活動,以確保可靠度目標之達成,並進而促使品質持續改善。這個過程也被人們熟知為:Plan-Do-Study-Act(PDSA)。是企業界早已普遍運用的一套「目標管理」流程,透過規劃Plan、執行Do、查核Check、行動Act四階段,確保每次的目標都能達成。

註2. 假說;Hypothesis亦可翻譯成假設,但是為了符合原著上的翻譯,這裡一律採用假說一詞。

註3. 極簡思考by Mike Ferriolo, 迈克·费廖洛。書中闡述的極簡思考法: 結構化思考。結構化思考是被假設驅動的,出於以下幾個原因。這個方法可更快地找出一個答案。你的假設將確定你論證所需要獲取的資訊,並指出哪些資訊與你最終的結論無關,以此能減少你花在無用分析上的時間。假設能讓你以事實為依據去找尋結論,也能讓你有能力找到事實來證明或推翻它。如果你推翻它,你將進入優化反覆運算的過程,直到找到一個可以證明為“真”的建議。你的假設越簡潔,其他人就越有可能理解你的回答和建議。

註4. 如何選擇一個正確的假設?

參考自內田和成的結構思考法

敏捷管理就是善用情境領導

主管需要成為“教練”嗎?

是的,主管需要成為團隊的教練。因為今天組織是以團隊運作的方式為主,已經不是主管一個人所能獨自完成的工作了。主管需要的是去瞭解他們的員工正在做什麼,但是並不是要像每位員工一樣能夠熟練地完成工作。再說;現在的員工並不需要一個權威人物來告訴他們或督導他們做什麼了。相反地,員工需要的是一個能夠傾聽、指導、訓練以及幫助他們的「教練」。身為教練這個角色的首要任務,便是能夠確保團隊成員擁有完成一流工作時所需要的資源。同時;還必須不斷激勵他們學習成長,為他們釐清責任和目標,使他們能提高工作績效,並且在組織內貢獻自己的力量。(參考: 《高績效教練》by: Sir John Whitmore)

主管需要的技能

成為你所負責的(主要)活動的通才。越是高層的管理者越需要是通才。你必須在這個領域上成為通才。也就是說;大多數的主管在他們所熟悉的特定領域內進行管理,只有如此你才能了解團隊成員們所遭遇到的困難。但就熟悉的程度而言;你只需要是一個通才。相反的;「人際關係」是一種能讓成員很好地與別人一起工作的能力,理解團隊的需求,建立良好的溝通,以及激勵他人的能力,這樣的人際技能,反倒是主管所不能或缺的。

.

主管每日實踐守則

.

由於主管是通過其他人來完成工作的,所以對於團隊而言;他必須擁有良好的人際能力來溝通、激勵、協商、授權和解決衝突。尤其是對工作上的概念(conceptual),雖然沒有必要懂得工作上的細節,但是能夠擁有足夠的概念,在就實際而言,這種「深入的概念」將更能幫助管理者做出更好的決策。尤其是對相關領域的熟悉程度,也就是需要有更充足的領域知識(domain knowhow),以建立足夠溝通的良好模式。
.

部屬發展模型(情境領導模型 II)

.

情境領導理論 Situational leadership theory

主張領導風格應該根據具體的情境而有所不同。保羅·赫塞(Paul Hersey;老師)和他的學生肯尼斯·布蘭查德(Kenneth Blanchard)所共同提出的理論。情境領導關注於所謂的員工成熟度。成熟度(readiness,D1-D4) 指的是員工能夠並願意完成某項具體任務的程度。赫塞布蘭查德定義了成熟度的四個階段:

階段1 = D1:員工既缺乏能力但滿腹熱情時。【熱心的新手

階段2 = D2:員工能力提升但仍需協助,且無意願從事必要的工作。【半生不熟

階段3 = D3:員工有能力但卻不願意做領導者希望他們做的工作時。【專家】

階段4 = D4:員工既有能力又願意做領導者希望他們做的工作。【獨自處理】

該模型主要在說明的是作為一位領導者,你應該怎麼去做。也就是針對不同的階段你該如何進行溝通,就是依據成員的行為反映來進行不同的溝通方式和類型。

隨後布蘭查德又提出進階的「部屬發展模型」Development Level of the Individual 4階段,以員工的工作能力工作意願,來判斷員工處於哪一發展階段,並據此將部屬個人的發展階段與主管的領導風格連結了起來。因為是藉由不同的工作任務來界定員工處於哪種發展階段,所以當某一項工作任務更換時,就得重新診斷員工的發展階段。(參考MBA智庫百科)

情境的S1-S4 相對於成熟度的D1-D4:

低能力、高意願 D1:部屬為新進員工時,雖然工作意願高,但對工作技術不熟悉。這時領導者應採取「指導型S1領導風格,協助員工。

能力平平、意願低D2:部屬的能力雖然有所進展,但在工作上還是需要幫助才能完成,遇到困難時,部屬工作意願跟著降低。此時領導者應採取「教練型」領導 S2,除了指導外,還要給予較高的支持行為,傾聽部屬的困惑。

高能力、意願不定D3:員工有足夠的能力,但欠缺獨當一面的自信,或不確定自己能不能做好,此時適合採用「支持型」領導S3,由領導者和部屬一起進行決策。

高能力、高意願D4:員工有充分的能力和意願,對自己的能力充滿自信,甚至可能比領導者更有經驗。此時領導者應該採用「授權型」領導S4,由部屬來決定工作的計畫和組織,偶爾過問工作的進展情況和遇到的困難即可。

結論

情境領導模式只是一種可以幫助團隊成員成長的領導方式的簡易判斷模式。強調的是領導者應該依據成員的「成熟度」來決定採用的領導方式。目的是幫助團隊成員的成長。只是一種易於運用的領導風格。藉由D1~D4的成熟度分析來決定領導者需要採用的管理模式,也就是 S1~S4情境運用。

敏捷教練也能依據這個模型,指導主管應該前進一步去協助團隊成員,或後退一步讓團隊成員自己做決定。也就是:

  • 當成員處於S1情境: 缺乏能力但滿腹熱情時,這個時候主管無法光靠引導的方式就能讓成員順利完成任務時,主管此時應該要勇於前進許多步,主動協助完成工作。
  • 當成員處於S2情境: 成員的能力提升了但仍需協助,且工作意願不足的時候,主管此時應該要前進一步,除了主動討論如何完成工作之外也給以適當激勵是十分重要的,並協助他做好正確的決定。
  • 當成員處於S3情境: 有能力但卻意願低的時候,此時主管應該要後退一步,主動與該成員一起討論如何完成工作,但將決策交予該成員。譬如: 下屬跑來請示應該如何完成工作時,此時主管對有能力完成工作者,不應該直接給予建議。反之;應該詢問該成員,準備如何完成他的工作,採取退一步的方式,引導他想出對策,不直接給建議。
  • 當成員處於S4情境: 既有能力又有意願做領導者希望他們做的工作時,主管應該後退許多步,授權下屬讓他能完全獨自完成工作,主管只需稍加留意即可。全權交予下屬自行做決策,只在必要時予以提醒協助。

應該授權或賦能到什麼程度與方式? 應該視(依據)成員的成熟度來決定如何做前進或後退的指導方式,並非一意運用引導(Facilitation)的方式,或是全然採用命令干預的方式進行管理的措施。傳統上;大多的主管只會採用一到二種策略來進行領導下屬的行為,赫塞和布蘭查德情境領導理論則提供了更完整的視情境決定領導方式,值得敏捷管理者參照。

.

參考: 《高績效教練》by: Sir John WhitmoreMBA智庫百科.

狹義與廣義的敏捷

敏捷開發是指向軟體界的新型開發方法,但敏捷 Agile 二字卻被普遍拿來應對世事多變下的一種變革方式(敏捷變革),在這裡做了一下區分,以狹義的敏捷指向軟體開發,廣義的敏捷指向我們在面對模糊不清與無知的情境下的敏捷性。

敏捷開發的定義

敏捷軟體開發(Agile software development),簡稱為敏捷開發,是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法(著名的XP極致編程、Scrum框架…等)的稱謂,是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中,專案以迭代的方式建構(切分)成多個子項目,各個子項目的成果都經過測試,具備集成和可運行的特征(也就是產出所謂的潛在可交付的小增量,目的是較具有意義跟讓客戶容易回饋)。這是一種原本用來針對軟體開發的改善方法,但由於世事多變而且越見複雜(有一種VUCA時代的描述,VUCA: Volatility易變性、Uncertainty不確定性、Complexity複雜性、Ambiguity模糊性的縮寫),人們逐漸意識到多變是一種不可避免的現象,因此很多組織便開始改變原本漫長的開發生產過程,轉而希望借助推行敏捷化的力量來加快適應的步調希望能藉此跟上市場多變的腳步。

敏捷狹義的定義;指的是針對軟體開發流程的改善。
敏捷廣義的定義;則泛指所有的行為規範。

.

何謂敏捷?

.

敏捷的狹義觀念 -應對需求多變

狹義的定義;指的是針對軟體開發流程的改善。敏捷是一種應對需求多變的開發方法。它並不是一種為了求快而開發出來的開發方法(敏捷開發為何比較快)。相對於傳統習慣於先做全盤的規劃之後在按部就班的開發方式,敏捷是以小步開發的方式,採用先輪廓再逐步細化的開發方式,透過客戶的參與與回饋,來讓描述產品功能的需求全貌越來越趨近於穩定。所以「小增量、多迭代與尋求回饋」便成為了描述敏捷開發時的代名詞了。

敏捷的廣義觀念  – 應對模糊不清與無知

廣義的敏捷定義則超越了軟體開發的領域,以提升敏捷性為主導,但相同的是仍然以透明、檢核與調適持續改善行為模式為核心。「低結論需求、多嘗試、多聽取建議」三個原則是針對我們的「無知」而來。這裡所謂的無知;指的是對問題的缺乏知識或是錯誤的認知。換句話說;當我們面對問題時,好的敏捷性可以協助我們減少在無知的情境下,因為過大的時程壓力而做出錯誤的決策。當我們在面對未來(陌生的工作)時,一種必然的無知時,希望這三個原則可以幫助你刻意的去發現正確的解題方式:

  • 低結論需求 Need for closure

當遇到問題時,能夠接受其中的不確定性,也就是能夠忍受心中在矛盾下所產生的不舒服,並克服對獲得結論的需求的急切程度,經驗告訴我們;當結論需求的程度越低時便是越能夠靜下心來做仔細的分析解題,反之;結論需求的程度越高者便是在當下急切於獲得對於問題的結論,越是急切的心,自然就越容易產生錯誤的判斷。這便是所謂的「敏捷性敏捷性越高的人,越傾向於能夠處於不確定的困擾之下仍然能夠仔細且穩定的工作著(延遲決策與看見全貌,請參考: 關於決策時的無知)。也就是更能接受問題的不確定性,更能克服因為不確定性所帶來的焦慮感。(參考結論需求量表,註1)

.

所謂「結論需求」,是指人的大腦多半無法容忍矛盾或模糊(因子),故而急需某種結論來消除焦慮。對這種需求結論愈高,固然可使一個人堅定不移地行動(因為有著很深的信念),但也更容易誤判。
by: Jamie Holmes

.

面對模糊不清事務的焦慮感容易導致錯誤的判斷

.

.

 碰到困難的時候,務必停下來徹底思考目前的狀況,想通透之後,再定出你自己的解答!

-葛洛夫給你的一對一指導

  • 多嘗試

嘗試是處理模糊不清時的最佳方式,它是一種學習的心態,一種勇於創新、實驗、冒險的精神(新新創業時的MVP方法,Google 的設計沖刺都是一種先嘗試的作法)。這種精神能夠接受失敗是最好的學習,也就是遇未知的事物時有意願去嘗試的科學實驗精神。當你面對無知時,最好的應對方式便是假設自己一定有不知道的地方,然後透過各種方式去發掘它,嘗試則是克服疑惑積極的運用實驗的方式來驗證它,因此要勇於嘗試。

知識的獲得經常是先抽象(模糊)之後逐漸弄清楚的,當我們遇到專案有重做一次的機會時,首先要考慮的是針對那些模糊不清的地方,設法透過實驗或其他方式嘗試把它弄清楚,以奠定重作一次的知識基礎再去做,自然會做得更好。

  • 多聽取建議

有別於特定的回饋方式(例如Scrum的檢核會義Review Meeting,針對的一個小增量的意見回饋), 在我們不知道自己不知道些什麼的時候(也就是處於無知的無知的時候),最便捷的方式便是從別人的角度聽取意見,由聆聽他人的說詞去審視,並嘗試用不同的視角去詮釋問題的原委,藉此來讓自己能夠更客觀的看清楚問題的全貌。

結語

應對無知的二個利器,限制理論與刻意發現。限制理論(Theory of Constraints,TOC)是一種系統思維,它是由以色列學者伊利雅胡·高德拉特所發展出來的一種全方面的管理哲學,主張一個複雜的系統隱含著簡單化。但是它一定存在著某種約束,這些約束造成他無法達到最高的效率,而我們只有透過持續的去發覺並解決最大的約束才能提升效能(註3,限制理論範例)。這是一種針對系統全貌下的持續改善思維。這種思維跟我們說,即便讓你一次再一次的進行重作相同的專案,你仍然會受到某些約束(無知始終是你最大的約束),它是限制你的效能無法無限制提升的最大約束,TOC這個系統思維工具的最大特色也就是在形容一個系統裡具有著相互關連的動態屬性,當你想要提升系統的效能時,只能持續的去發掘最大的限制(如果你處理的不是最大的約束時,你可能是在做局部優化的動作,對提升系統整體的效能將沒有幫助),然後改善它,接著再去尋找下一個最大的約束,繼續改善下去。

BDD之父 Dan North 於2003年提出了刻意發現(Deliberate discovery) 的概念,目的是用來應對專案開始時的無知(請參考「無知的無知」)。多年來的成果,是鼓舞了業界發展出來許多好用的工具用來協助我們發覺未知的困擾。下圖右側是精實開發的處理原則: 延遲決策與看見全貌來解決無知,上半部則是一些發展出來的實用工具。

一些前置處理的工具可以協助我們進行刻意發現

狹義的敏捷是用來應對軟體開發需求的多變時的處理方法,口訣是: 小增量、多迭代及尋求回饋。廣義的敏捷則是用來應對處裡事務時在情境上的模糊不清與無知用的,口訣是: 低結論需求、多嘗試多聽取建議。二者都能協助你提升敏捷性。至於何時運用它則看你所扮演的角色而定。但核心思想都是透明、檢核與調適。舉例來說: 如果你身為主管的話,透明對你而言就是開誠布公,檢核與調適則是能夠在授權後進行賦能的作為。

.

註1. 結論需求量表,為 唐娜.韋伯斯特(Donna M. Webster)和 克魯格蘭斯(Arie Kruglanski)於1994年所發表,共42道問題,下面節錄的是經過心理學家尼爾.羅伊茲(Arne Roets)和 愛連.馮.海爾(Alain Van Hiel)在2010年的15題精簡版。(可參考《無知的力量》page 115. 及 google圖書,《石頭湯實驗:文化隔閡為什麼如此頑固》)

給分區間:  1分: 完全不同意 6分: 完全同意

  • (  ) 1. 我不喜歡不明確的情境。
  • (  ) 2. 我不喜歡,可以有不同答案的問题。
  • (  ) 3. 條理井然、作息規律的生活適合我的個性。
  • (  ) 4. 要是無法理解生活中為何會發生某項事件,我就會很不自在。
  • (  ) 5. 如果團體中有人和其他人都意見不合,我就會很生氣。
  • (  ) 6. 我不喜歡落入無法預料未來發展的局面。
  • (  ) 7. 下了決定後,我會鬆一口氣。
  • (  ) 8. 遭遇麻煩時,我拚死也想趕快解決它。
  • (  ) 9. 要是沒法立即找到方法解決麻煩,我很快就會變得煩躁。
  • (  ) 10. 我不喜歡和行為難以捉摸的人在一起。
  • (  ) 11. 我不喜歡聽人說起話來模稜兩可。
  • (  ) 12. 建立前後一貫的生活常規讓我更能享受人生。
  • (  ) 13. 我喜歡確切、有條理的生活模式。
  • (  ) 14. 在形成看法前, 我不常欲徵詢別人的意見。
  • (  ) 15. 我不喜歡難以預料的情境。

填寫問卷後,加總起來得分在57分以上者,表示當下的結論需求高於平均值。

註2. 《無知的力量》作者: Jamie Holmes,書裡面描述無知與知之間的模糊因子以及我們如何來應對它。

註3. 工程師的機會成本,請參考限制理論的提水救火範例。

關於決策時的「無知」

人遇到問題,就是無法忍受心中的矛盾,一定得從矛盾之中找出一個脈絡來脫逃這種因為矛盾所產生的不悅,才會覺得舒服。而這種不斷的去解決這些困惑的動力,其實就是人們探索這個世界的方式。

-追求知識的衝動(結論需求)

.

.

知識的情境

如果全然「無知」因為完全不知道,自然對事情不會有任何感受,也就讓無感或是麻木佔領了心靈。如果真正「」道了;對於來來往往的資訊,可能會會心微笑或是產生認同領悟,心中會有一種篤定的喜悅。至於在無知與知之間則充斥著模糊,越是靠近無知就越是覺得模糊,若是模糊逐漸減少了便是更接近的領域了。全然的知或許是Dr. 米哈里(註1)所謂的「心流」吧!

所謂的知識;就是要帶領我們由無知穿越模糊並持續累積正確資訊再邁向知的依據。但模糊是個大泥沼,它會帶來猶豫、徬徨,在我們心中產生焦慮不安,

如果問題一日不解,困惑、疑慮就會持續佔滿心頭,這時候我們可能會說無知反而是一種幸福,這種矛盾的心態只有在我們找到問題的解答後才可能平復,也才能由模糊因子的降低換來較舒服的心態甚至是喜悅。

模糊因子決定決策品質

焦慮的心態是做決策時的一大陷阱,當我們處於時間緊迫或是承受重大壓力時,這個時候所做的決策,要如何維持一定的品質呢? 此時;對問題相關領域了解的程度可能是決定性的因子(或可稱為模糊因子)。基本上;人在責任感的驅使下,都會想盡辦法去降低對問題認知的模糊性,此時模糊因子的大小正好與決策品質的好壞成正比。因此設法降低模糊因子,才能形成好的決策品質。

在這個資訊爆炸的時代,我們缺少的經常不是相關資訊而是缺乏過濾相關資訊的能力。有一句對發明家的評語在這裡派得上用場,那就是擁有較寬廣的視野與願意深入理解的心。正是遇問題先看見問題的全貌,然後才去深入探索問題。這是降低模糊性的好方法。對應到精實原則(Lean principle)則是建議我們要盡量延遲決策(Decide as late as possible),避免直覺反應式的直觀決策方式,並以著眼整體(See the whole)的方式來處理問題。

.

無知的情境

.

面對未來,我們將必然的處於一種無知的狀態。當我們思考如何應對的策略時,也就是思考機會成本,其實就是在思考決策標準或價值觀。

.

小結

當你要做決策時,面對未來的不確定性,存在著一定不可避免的「無知」。你唯一能做的就是在做決策之前設法降低對問題領域的模糊性,也就是增加你對問題的相關知識。上圖是在描述無知的情境,介於「無知與知」之間的模糊會引發的一種心理狀態一般稱為「猶疑」或「徬徨」,這種心態會「放大」情緒。猶疑的人首先會感到焦慮,而焦慮會讓人更加痛苦想盡快解決問題(註3. 結論需求)。反之;解決問題的樂趣會令人帶來愉快。(短暫的無知是一種樂趣;很多好笑的惡作劇、幽默的笑話之所以好笑,都是從對事情的無知、論述的猶疑開始,在發現真相之後,才會讓人忍不住笑出來。)

當我們在全然無知和全然知道時,心情都很篤定,此時不會產生困惑。但一旦我們有一絲感想又覺得不是很清晰了然時,一種困惑的心情便會自然地染上心頭,這是一種對模糊知識所產生的猶豫、徬徨,它會讓我們感到焦慮,一種莫名的不快,我們會自然的催促我們趕緊搞定它的行為,就是試著去找出為什麼會這樣的原因。但是在模糊性過高的情境下做決策,往往會由於對訊息過濾的過於倉促,而做了錯誤的判斷。這是不智的行為。當我們帶著焦慮做決策時,若能夠後退一步,先看見事態的全貌,設法降低模糊因子,並在延遲決策的原則下再做決策。則因為無知的情境而做了錯誤機率就會顯著的下降了。

圖下方的「未意識到的無知」與「意識到的無知」係參考 安.克爾溫 (Ann Kerwin)的無知矩陣如下圖。她描述到顯性知識與隱性知識(必須實際經驗過才會擁有的資訊),當我們再處理未知的事務時,必須先確定這種模糊的未知是顯性知識(一種透過閱讀就能學習到的知識)還是我們應該做成模型(prototype或 MVP)才能確認的知識,以降低我們的無知(減少模糊因子)來做出更好的決策。

.

培養敏捷性(agility)是應對不確定性的最佳良方。

.

安·克爾溫的無知矩陣

.

註1. 《心流:高手都在研究的最優體驗心理學》為 米哈里.契克森米哈伊 1940年的作品。(Flow: The Psychology of Optimal Experience)

註2. 《無知的力量》為 Jamie Holmes 的作品。

註3. 人們急於尋求問題解答的特性稱為「結論需求」Need for Closure。當結論需求越高的人士,越是會急於下決策而忽略了去仔細推敲眼前資訊的可信度。他在感知到問題時的焦慮程度也會越高,越想要盡快盡快取得明確化的情境。

註4. 「歷史終結」 The End of History Illusion,描述的是人容易將過往設想成故事彷彿具備的情節,必然的朝某一個方向去發展。而忽略了過去、現在及未來都是未知待發展的。

安全的失敗 safe to fail

找一個會議來刻意讓他失敗,是一種絕佳的safe to fail.

.

讓會議失敗是一種safe to fail的好嘗試

.

開會是工程師工作時間的最大殺手

會議是任何組織都不可避免的一種意見交流、訊息傳播及溝通的活動。但對工程師來說會議卻是工作時間的最大殺手,我們都知道;工程師要在座位上專注而用力地敲擊鍵盤才有產能,任何打斷他們思維的事務都是干擾,都應該盡力的去避免。因此在專案成立之初將整個團隊一起關進一個隔離空間(成立所謂的戰情室);根絕任何(會議)干擾,將立即有效地提升團隊的產能(尤其對那些有deadline 的專案更有幫助)。

無心開會;專案在緊鑼密鼓時,工程師大都不會把心思帶進會議室,開會時;你會看到團隊大部分的成員帶著筆電進來開會,明顯的他們根本無心來開會,此時會議的效能想當然就不會太好了。做顧問時我會建議主管體諒一下,在會議剛開始時讓在趕進度的工程師,能有自由選擇是否參加(非必要)會議的特權。相對的;也可以看出團隊裡目前誰的壓力最大,最需要協助了。正確的作法是以先行溝通的方式來避免這種現象才是。反過來;讓工程師把腦子裡在想的事情不要隱藏著,公開出來;讓透明化使得大家能夠知道何時能夠幫你,才是聰明的工程師應該有的做法,讓自己融入團隊,與團隊成員分享協作才是上策。

會議太多是溝通不良的徵兆

幾乎所有的主管都整天不停地忙於開會,是受會議干擾最嚴重的一群。要知道運用會議來吸收或分享訊息實際上是成本最高的一種作法,團隊基於有許多事情我們必須知道就需要為此招開一個會議嗎? 如果能夠透過其他方法讓訊息快速共享不就可以擺脫這種聚集群眾來開會的形式了嗎。當然還有另外一種方法,就是你可以選擇相信、信任的方式,相信他們能做得很好而你不必知道它們是怎麼做的;這就是比較高深一點的團隊自組織了。

敏捷Agile以透明、檢核與調適的過程來解決組織溝通上的問題,要求以小團隊做出發點,並以固守時間盒(time boxing)的會議方式來簡約時間與資源,然後依靠每日一次的短時間的站立會議來實踐它。其中的Scrum框架更以簡潔易懂的流程方式擄獲了變革者的心靈,成功的改善了舊有傳統開發方式的缺失,讓流程更為靈活更為多樣性。

※《賦能》一書裡則以一、讓互信和目標共享。其二、以小團隊構成大團隊(信息共享、共享意識與自組織) 這二個宗旨來化解傳統組織層層節制的架構限制,解決溝通上的屏蔽,減少會議的干擾,追求高效運作的能力。

讓會議失敗

大家都知道怎麼開好會議(如何高效能的開會,是職場必備的常識),例如: 一開始就要講清楚會議的目的以及希望達成的目標。重要事項通常不是在會議上研議出來的,而是在會議前就先溝通好的,會議只是用來迅速達成共識用的。主講人的會前功課就是要讓大家都帶著有概念的方式進來開會,而不是臨場短暫的聽取簡報就做好決定該怎麼做的。我們經常會犯上知易行難的問題;現實中大家真正開起會來卻與認知完全不同。開會時,有帶筆電的、看手機的比比皆是,還有到場才問開會主題是什麼的? 到底是什麼原因造成大家都知道的最佳解卻沒人去依循呢?

這是一種典型的「霍桑效應」,人們在沒有被強迫、要求下或是沒有產生痛點的時候,惰性便會戰勝一切,容易將錯就錯不做決擇的一種怠惰的自然行為,就像是暑假作業一樣,不到假期最後是不會去做的,也就是暑假快要結束了那種急迫性才會敦促我們趕緊去做的。 所以要讓會議失敗。

因為;失敗學到的比成功還多。讓會議失敗團隊由失敗中學到教訓。打破大家將錯就錯的心態,開始選擇有效率、認真的參與會議,實質上,是協作出好的、有效能的會議。如果會議的一大目的是獲取共識的話,自然是獲得與會者的協作才是達成會議高效的基礎。所以要讓它先失敗,大家體會到痛點之後,自然容易痛定思痛選擇對的開會方式了。

.

「失敗」迫使人在事態背離盤算時,重新省思舊有的篤定信念,那些原先以為理解的事情成因,這時都不得不強行加上模糊因子來重新檢視了。

.

結語

會議開多了就很會開會了嗎? 答案恐怕是相反的(反而容易麻痺),一個敏捷的團隊除了5大制式會議之外,應該盡量減少會議的中斷,讓工程師能夠獲得充分的工作時間,效能自然會越好。但就是有一些非開不可的會議;試問我們能不開部門會議嗎?能不開主管周會、月會嗎? 需不需要開這些會議呢? 相較之下;需要斟酌的是機會成本;當不開會的損失可能要大於招開會議時的時間損失時,就應該要開。因此會議招開的效能才是真正平衡損益的關鍵,也就是高效的開會獲得最多損失最少。

回顧三步工作法的第三步、文化 Culture ;用意在增強對產品的信心,營造一種勇於創新、實驗、冒險的環境及高信任度的文化。其中頗為引起爭議的,就是實驗與冒險,這二者都是為了學習,而失敗時所能學到的通常都比成功時還要多得多,因此就有所謂的「安全的失敗」Safe to fail的說法。但除非你是在實驗室裡工作,試問誰願意失敗呢? 又有哪一個老闆能接受員工經常的失敗呢? 身為顧問經常會聽到來自CEO們的要求:『盡量不要失敗,如果一定要失敗的話麻煩讓失敗盡可能的縮小。』可見大家有多(都)害怕失敗。建議你: 運用失敗的會議來改善團隊的協作。

會議是一種團隊的協作。會議開得沒有效能或沒有達到目的,對於團隊而言是一種協作上的失敗,但這種失敗卻是最常被忽略的失敗,若是能在事後進行回顧,共同檢討失敗真正的原因,即便之前的會議失敗了,只要用心去回顧是什麼原因造成失敗的,此時的收穫恐怕能讓團隊學得更多獲得更多,而這不就驗證了「失敗時所能學到的通常都比成功時還要多得多。」 敏捷在成立新的團隊時,有經驗的 Scrum Master 通常會將接下來的第一個Sprint 改成一個星期,然後刻意的讓它失敗,也就是讓團隊的第一個協作的Sprint 沒有能夠達成它的預定目標,聽起來是沒有依循青年守則所謂的「好的開始是成功的一半」Well begun is half done的西方諺語。但其實這種失敗反而能讓團隊學到最多,對於團隊未來的協作十分有利,因此是一種刻意的失敗作業,也是一種典型的Safe to fail的模範。而刻意讓會議失敗,也具有異曲同工之妙

.

與成功相比,我們從失敗中可以學到更多;與讚美相比,我們從批評中可以學到更多。

-金.斯科特

.

三步工作法 The three steps.

.

如何解決軟體系統太複雜?

複雜性是不可避免的,這就是進化的原理。

.

考慮系統複雜性對開發速度的影響因素

.

(紅色區塊: 不利於開發速度, 綠色區塊: 有利提升開發效能, 黃色區塊:需適度選擇, 紅線: 造成下降, 綠線: 造成增加.星號: 改善重點, 倒三角: 危害重點)

.

這裡的解決複雜性,所指的是軟體開發單位如何提升開發速度,想方設法加快開發效能;這可能是所有的CEO們都夢寐以求的,因為有太多的需求在排隊等著要作了,但卻偏偏卡在這裡,一定要設法來加快開發單位的效能才是。身為顧問,我經常受邀去診斷研發單位為何效能不彰的問題,習慣上我都會私下先跟負責人強調:「一個夠好的需求,勝過作好無數個實用的功能。」在開發之前;多花一點時間排好需求開發的優先序才是上策。但怎麼說了卻無法激發當事人的反思(基本上從來沒有生效過)而有所改變。很快的他們就會要求各個部門配合我進行診斷作業,然後催促著要我交報告,急著作決策,那種急切心情很教人激賞,我又怎能辜負它呢。

上圖是參考 Targetprocess公司 Michael Dubakov先生在Blog上所發表的著作(註2. 原文),它是拿來分析軟體開發速度相關元素的極好的參考資料,這裡我僅僅擷取與系統複雜性有關的區塊翻譯成中文。加了一點實作上的考量(原文抽象度太高),但在右上角我加進了「架構設計」的影響,並給予它和程式技巧區塊一個AND的屬性。意思是好的架構與好的程式技巧都能消減系統的複雜性。而程式設計巧甚至會受到架構設計的制約(限制),所以我擅自加了一個綠色的區塊跟一個橢圓的符號。因為這也是我最常建議開發單位進行改善時的起始點(所以用三顆星來顯示)。

採用AND橢圓的符號是為了關聯性,因為人們經常只看到一個現象就快速的針對現象進行分析與改善的動作,完全忽略了與其他項目之間相關的交互影響,這是系統思維的基本要求;要看見全貌而不至於見樹不見林。
快速直覺的抉擇方式,往往缺少了深思熟慮

.

針對解決複雜統架構實作的通則

.

技術債 Technical debt

這個觀念是由Wiki之父Ward Cunningham先生提出來的,也是開發單位效率不彰最常見的元凶,就是只知道要求開發速度(註1. 技術債的真正定義,指工程師挑選了實踐非最佳解決方案或編寫非最佳程式碼的刻意決定,以便能夠更快地發佈軟體功能。),而忽略了自己正在提油救火,讓約束(限制你開發速度的瓶頸)變得更大了。給它二顆星是因為我們應該正視並支持工程師適時作正確抉擇的心態,勇於去挑戰技術債才是對提升效能作出最好的貢獻。

開發單位其實在邀請外部顧問作診斷之前,都已經作了自我改善的努力,而他們所作的努力也不是完全沒有效用,只是經常是改在所謂的最大的限制之前,因此看不到功效,成了一種無效的優化(局部優化,參考工程師的機會成本)。身為顧問必須避開重蹈覆轍,所以要先找到最大的約束才能開始解題(請參考限制理論)。

.

一個好的需求,勝過作好無數個實用的功能。

.

程式碼的黑洞

人類比病毒要複雜得多了(但這並不意味著人們可以更好地生存著,事實是能活的最久的是適應性最好的,而非最強大的)。寫程式是一種複雜性呈現指數型上升的拓普結構,一定會越寫越複雜的,當程式寫得越多,細部的邏輯就會越來越難以記得清楚也就越見複雜了,然後維護的負荷也跟著越來越大了。這是不變的真理,我們要學會(也只能夠)適應這種複雜性,然後避免寫出複雜的程式,寫程式時要努力去追求簡潔而不是快速,正是所謂的簡約至上。

學會刪減程式碼的習慣

程式碼一旦被發布出去後就很少有人會去刪減它了(執行的好好的,我為什麼要去改它,萬一改壞了怎麼辦),即便你覺得這段功能碼根本沒有人會去呼叫到它(所謂的死程式碼),你還是會留著它然後幻想有一天你會需要它(它一定會再被用到的,一種沉沒成本的謬誤)。所以我們在發布之後,就變得只增加程式碼而不會去刪減程式碼了,當程式員寫越多的程式就背負越多的維護債。這是一種非必要的複雜性(它會間接的拖慢你的開發效能),但你因為不敢刪除它因此就會一直背負下去,但其實刪減上線程式的習慣不但可以增加組織實施DevOps的能力,又能延續產品的生命週期,還能讓維護作業更輕鬆些,CP值極高。但要怎麼做呢?

上線後的重構作業

一般的重構作業指的是寫完程式後或在code review 之後立即進行「重構程式碼」的動作(重構程式碼時是既不修正錯誤,又不增加新的功能的一種行為)。它是用於提高程式碼的可讀性或者改變程式碼內部的結構與設計,並且移除死程式碼,使其在未來更容易被維護。在極限編程式設計(XP)中,重構需要自動化的單元測試來支援(馬丁·福勒的名著《重構》是值得經典的參考書籍)。但這裡所指的是更需要勇氣的在上線之後作重構的程式碼,目的是;刪減那些所謂的死程式碼,就是沒有被用到的功用、無人在使用的程式碼。它需要支撐的就不只是自動化的單元測試了,而是完整的 DevOps作業(經典的思維問題是: 漏改一行程式碼你需要多久才能修正它呢?)。

.

漏改一行程式碼你需要多久才能修正它呢?

.

讓新人快速入門的好方法,也是解決複雜系統開發、維護的良方;是

建立部門好的 knowledge Base 系統,運用好的文件資訊揭露系統的複雜性。

.

結語

作為改善開發效能顧問的雙管齊下手法;一是運用敏捷與精實(看板)來改善開發流程的效能。另一是深入商業領域探討對此領域(domain)的技術債。上圖中綠色的區塊;是指可以增加開發效能的行為。常用的起手式是實作看板;讓看見瓶頸就能知道如何改善的一種透明化的視覺驅動改善方法)。再來是對技術債進行盤整,這是因為許多開發部門因為專案時程太趕了,選擇長期忽略會拖慢他們開發效率的技術債(只增不減無視於技術債的存在,沒有將解技術債的需求排進正常開發流程),這是人為的因素,可以運用架構與技能(Skills)的提升來避免它。其它的綠色區塊: 嚴謹的開發紀律(敏捷所謂簡單規範)與短時間激勵(對團隊運用的激勵方法增加短時間的產能)則屬於管理上的措施,需要與主管一同配合實施(這屬於人事的問題,老實說;比較難有短時間的改善成效)。

紅色的區塊;是指增加系統複雜性的行為。給「不穩定緩慢測試」二個倒三角的原因是效能不彰的團隊多半是因為返工過多的原因(做一次整合測試要花上大半天的時間),說穿了;就是Bugs太多了。團隊花過多的時間在返工(處理同一件事)上。解題之道是重視測試讓測試變得快速而順暢,自然能讓團隊願意花時間去作測試,能更積極的去重視開發品質,有趣的是當你重視測試的時候,團隊的紀律會自然提升,這一點也有助於推行「嚴謹的開發紀律」的綠色區塊最後;是大家都喜歡的自由式coding(Cowboy coding),一種自由coding的模式,老實說;我們都是這麼開始的,一種可以充分享受coding樂趣而不需要背負任何責任的行為模式,可惜的是;現實中每一行的程式碼都有它必須正確完成任務的責任,我們要為軟體產品負責、對團隊負責所以責任大於自由,我們必須嚴謹的遵循程式員的開發紀律,遵守團隊code review裡的規範。

黃色的區塊;是指作多了反而降低開發效能的行為。例如過多的重構或是花太多時間在解技術債,都會降低開發團隊的效能。

要解決軟體系統太複雜的問題;需要在架構上、coding技巧上以及管理層面上進行改善,許多開發單位的主管都以為能夠雇用到更優秀的工程師自然就能克服更複雜的系統問題(有一點銀子彈的味道),乍看起來這個想法好像是對的,但在現實環境下這種想法是行不通的(可能有一點用),因為專案工作不是單獨一個人就可以完成的,開發團隊需要頻繁溝通才能協作或必須先問清楚(在複雜系統之下,光是要弄清楚應該找誰來問問題,這種問來問去的溝通本身就是最大的成本)就可以佔據掉任何一個聰明人的所有上班時間了,因此你很難只靠優秀的人才就能有效的降低系統太複雜的問題。你需要持續去進行改善,但在改善以前需先分析目前最大的瓶頸(約束)在哪裡,針對它來進行改善。若是順序弄錯了先改到最大瓶頸之前的約束,則對達成目標或提升整體的效能都不會有所幫助的(請參考限制理論中的關鍵鏈)。

.

工程師的溝通;就是你中斷我、我中斷你,彼此都無法專注的工作了。

工程師的會議;就是大家一起暫停coding的作業。

.

鍊條的強度取決於最脆弱的一環,而不是整體的強度

.

註1. 技術債的真正定義

這個觀念是由Wiki之父Ward Cunningham先生提出來的,技術債務是一種機會成本,工程師挑選了實踐非最佳解決方案或編寫非最佳代碼的刻意決定,以便更快地發佈軟件。如果工程師是在一種無知的狀態下,設計了不好的解決方案,就不能算是技術債,純粹是程式設計的技巧太差。

註2. 參考 Targetprocess公司 Michael Dubakov先生的文章,原圖如下:

工程師的機會成本

.

機會成本(Opportunity Cost)是指決策過程中面臨的多項選擇,當中被放棄而價值最高的選擇,又可稱為「替代性成本Alternative Cost」,也就是你所放棄的成本,也就是俗話所說的「世界上沒有白吃的午餐」、魚與熊掌不可兼得,正是這個意思。

.

程式開發的過程無時無刻不在做抉擇

程式員可能是工作時做最多抉擇的職業之一。因為寫程式時他一直面臨著各種抉擇。所謂程式設計;是由抽象而模糊的程式架構逐步堆疊出嚴謹而明確邏輯結構的一種思維過程。程式員在過程中不斷地面臨著各種選擇,從程式語法的挑選到程式段落架構、選擇適用的過程模式或是特定的功能模組,這些抉擇都是一種機會成本。請問你是依據什麼做成的決定? 是你的喜好(習慣已久的起手式)。還是依據經驗(上回也是這麼開始的;蠻好的)。或是新語法的嘗試(從來沒這麼寫過,這回來試試看效果怎麼樣)? 不論你所依循的抉擇是哪一種,它都是透過你的邏輯思維所產出的結果。但轉變都太快了,來得太快變得太快,讓人都來不及思考;也改得太快了而你也依據這樣的速度持續修正了幾回,直到它達到了預期的效果。而後續呢? 如果它太複雜了,你甚至會有不願意再看到它(逃避思考)的想法,這個時候你一定要進行重構,逃避只會使問題更糟,休息一下緩一緩再來進行重構,這是你最佳的抉擇。

乍看起來我們好像一直在做抉擇,快速的思考著。但實質上我們有一半的時間是在跟程式編譯器對話,當然越厲害的程式設計師跟編譯器的對話就越短暫。但要想完全不作對話是不太可能的,也就是完全不去管編譯器的語法檢核是不可能的,即便你對程式語言的語法十分的熟悉,工程師對工具的依賴仍是開發過程不可或缺的一塊。因此對於工具抉擇及運用上的熟悉程度也會有相對地幫助。但是它是否提供足夠抉擇支援才是最是慎選工具的重點。

.

每一個決定都是一次權衡.

-Dan north

千萬避免在迷失之後才開始找尋出口。

.

梳理你的機會成本

每一個抉擇都有它的機會成本,但因為有太多抉擇了,而你卻沒有太多時間做思考。所以提供限制理論的三個核心提問來協助你做抉擇。在coding 完一段程式碼後;(1)先問自己我作對了嗎? 試著確認這段程式碼的對錯,它可靠嗎?程式的其他部分可以依賴它嗎? 單元測試是你最好的選擇,如果你做了單元測試,它可以替你掛保證;這個問題也就過關了(實行TDD可以讓你更上一層樓)。

(2)再問自己這樣做好嗎,我有製造技術債嗎? 盡量不要把相關的問題留到後面,也就是只做了部分解或是做了暫時解(不完整的解法是最糟糕的程式碼)。心裡想的是(一直想說服自己);這樣做比較快、比較簡潔,等到最後收尾時再來對付這些紛雜的小問題,目前這樣做就夠了。千萬不要等到最後再來收拾殘局(等我有時間時再來優化),放心好了,等你寫完時;你連註釋都不會去改它;又何來改正呢?這種拖延是寫程式最糟糕的壞味道。

(3)然後捫心自問;還有更好的作法嗎? 思考一下;這塊程式碼是在我的程式瓶頸之前還是之後呢? 如果是在之前;就先回去改善程式的瓶頸,才再回來思考這個優化的問題,這樣做才有意義(所有的程式瓶頸之前的優化都是一種浪費,限制理論TOC)。這裡沿用的是高德拉特先生限制理論的思維方式,用開始的三個問題來應對機會成本,用核心思維來協助自己的思維抉擇。

.

限制理論的三個核心問題、五個解題步驟與五棵解題樹

.

組織變革後覺得效能不彰

身為主管的你;是否努力地在改善團隊的效能卻覺得成效不彰呢? 明明已經採用了許多看似有效的方法、也頻繁的進行檢討,看起來都做對了,但卻遲遲看不到整體效能有所改善呢? 運用瓶頸理論(短板理論,註1)的思維;或許你改善的措施都位於瓶頸之前吧,所以始終受到瓶頸的約束,因此效能無法提升起來。如下圖中右側的「提水救火」為例,當長長人龍排成一列,每個人用傳遞的方式將盛滿水的桶子往前傳遞時,很快的我們就會看到傳遞的速度取決於傳遞最慢的那位仁兄,無論前面的夥伴打水、傳遞桶子的速度有多快捷,救火的速度則始終沒有改變,它受限於最慢的也就是長長人龍瓶頸處的速度,在瓶頸之前的所有改善措施,將無法影響到整體的效能,或可說成瓶頸之前的優化將只是局部優化,對於整體而言是無效的。這便是大部分的組織變革未獲得明顯改善的最大原因,沒有解決到正確的地方,仍然受限於最大瓶頸的約束。這也是限制理論裡所謂的限制約束。

.

限制理論TOC(Theory of Constraints): 在任何時間,一個複雜的系統可能是由成千上萬人和一系列設備所組成,但我們應該把它視為一個系統。 任何系統;只有非常少的變數或只有一個,稱為限制,它會限制或阻礙系統達到更高的效能目標。

所以我們應該找出最大的約束,然後傾全力的去解決它,並在確認解決之後,移向解決下一個的約束。

.

瓶頸之後的改善仍受制於該瓶頸

.

所謂思考機會成本,其實就是思考決策標準或價值觀。

-《機會成本》 作者: 清水勝彥

.

切勿緊抓「沉沒成本」不放

沉沒成本(Sunk Cost);是指已經付出且不可收回的成本。例:都已經花這麼時間了,寫那麼多程式碼,雖然 Bug多了些,我還不想放棄。雖然執著是一種美德,但有時也是一種愚蠢的行為。為什麼會有這種荒謬行為呢?因為人類想努力表現得堅韌,堅韌是我們發出的可靠信號。我們害怕矛盾。如果我們決定中斷一個專案,我們就是在製造矛盾:承認從前的想法與今天不同。繼續執行一個無意義的專案是在推遲這一疼痛認識。那樣我們就顯得更堅韌。其實;你應該思考一下機會成本了。

1: 木桶原理又稱「短板理論」,木桶短板管理理論,所謂“木桶理論”也即“木桶定律”,其核心內容為:一隻木桶盛水的多少,並不取決於桶壁上最高的那塊木塊,而恰恰取決於桶壁上最短的那塊。

2: 機會成本的四大面向 (參考自 機會成本》)
  I.【做決策的機會成本】──有捨才有得
  ‧運用左手欄以減少迷失。

  II.【決策過程的機會成本】──要戰勝凡事都想計畫的誘惑
  ‧運用敏捷化的小增量、多迭代做到延遲決策的方式。
  III.【決策後悔的機會成本】──不斷追求完美只會越來越不安
  IV.【如何使機會成本最小化】──達到真正意義上的目標共享
  ‧排定優先順序,等於確認目的 – 做最重要的事
  ‧要做成一件事,必須用減法而非加法 –簡約至上
  ‧避免無知的自信 – 無知的信心大於知識(達爾文)。

無知的無知

無知的無知 I don’t know that I don’t know.

圖片 001

2000, Philip Armor發表了一篇名為 《無知的五個程度Five orders of ignorance

.

為了避免你成為「第四級的元無知」,在此介紹 DDD 領域驅動開發的網上電子書 (《领域驱动设计15年》, from DDD-China) ,相當值得閱讀。紅線框框是指專案開始之初,我們總是處於二級無知的範疇。而犯了一些錯誤的認知或決策。

二級無知 你不知道自己不知道

無知的無知是天生的。專案開始之初;最常見的情況是, 你僅僅得到一個解決方案的規格說明, 但其中並沒有描述這個解決方案要解決的問題是什麼? 而你也沒有去追問為什麼要這樣做。這種無知程度的另一種表現是, 自以為具有某種本來不具備的能力, 而根本沒有意識到這一點。這種人可能同時缺乏業務和技術知識, 在這個無知水準上會做出許多錯誤的決定。

.

作者群的原意是為了,專案開始之初大家對無知與知識的相對缺乏,便輕率的做出錯誤的決策。而減少無知程度的唯一方法便是設法針對相對領域(domain know how)提升認知水準。要知道無知程度越高,就越會有意無意地導致知識的缺乏和對問題的誤解,從而增加了做出錯誤方案的機率。為解決這個問題Dan North 提出了刻意發現(Deliberate discovery), Alberto Brandolini  提出事件風暴(Event storming,註1. 這本書的目錄)。如果你尚未關注到這個恆久的話題,就很難在這個時代持續敏捷、DevOps下去了。

圖片 002

無知對產品的影響(參考自 DDD- China)

.

專案重做一次

我們經常以為"專案如果能重做一次",我已經完全弄清楚是怎麼一回事了,一定可以更快速的交付,產出更好的成果。但事實並非如此;由於無知的限制(在高德拉特先生的限制理論 TOC 裡面描述了我們對於domain know how 始終會受到未知的約束),只能藉著持續改善來加強它的效能。上圖中描述產品的 version 1.0 通常仍然具有相當的無知程度,只是在減少無知的過程當中,只能依靠一些前置的探索工具如刻意發現或是事件風暴來降低無知所帶來的風險。

.

小結

這裡所謂的無知;不是拿來罵人的, 指的是對專案目標缺少相關資訊。敏捷在開發流程中刻意的移除了 ‘設計’的項目,因此必須倚賴頻繁的迭代來累積設計,因此造成了浮現式設計的時程壓力太過於沉重而且不容易看見全貌(尤其是做架構設計)。 其實;我們應該在專案開始之初盡力的去蒐集與學習開發領域的相關domain know how才是, 這樣可以降低我們因為無知所犯下的錯誤. 也能讓專案進行得更順暢。例如先做’影響地圖’就可以蒐集到更多的外部資訊, 而學會 domain know how是盡早具備撰寫程式必須具備的內部資訊, 這才是真正有用的解題之道。一般在專案 Kickoff 之後,工程師們通常都太快開始進入 coding 作業了,對於要開發的目標功能並沒有花上太多的功夫去做深入一點的了解作業,就急著做估算、撰寫使用者故事,然後開始 Breakdown 產出 task 來,然後就開始衝刺了。Dan North 以為多花一點時間刻意的去認識你將開始的工作,了解越多相關知識你的收穫就會越豐富,無知的程度自然會減少,這時候開發出正確的產品或正確的 coding 功能,自然會更有成效。

.

0039

做出正確的產品是方向,完成正確的功能是速度。

.

無知的警語

– 我只知道一件事,就是我什麼都不知道 – 蘇格拉底。
– 偏見是無知的孩子 – 哈茲立特《拿破仑传》。
– 無知的人總是特別有信心  – 達爾文。

.

這張圖片的 alt 屬性值為空,它的檔案名稱為 e59c96e78987-004.png

無知之下多勇夫 – 勇於嘗試,掌握現下.

.

無知是一種優勢 — TENET

只有當下你是無知的,無知者自然無懼,因為無知反而讓你勇於創意、勇於嘗試。若是你早早看見全貌,可能你早就打退堂鼓了,但無知卻反而給了你勇氣。這是一種反推的思維,居於一種時間回朔的概念,早知如此我就不會這麼做了。但基本上描述的是一種錯誤的態度,若是態度沒改變,即便知道了也不會去做的。天能這部戲(牽扯到知與無知之間的動作片)描述了一種不一樣的時空機,他是即時的、對稱型的;過去的事就過去了,過去是不能靠回到未來就能改變的。無知是一種優勢;解釋了即便你知道了,反而失去當初執著的勇氣,所以"人"有時是需要無知的,無知反成了一種優勢。也就是說;態度決定了一切做為。

.

註: 《領域驅動設計前15年》電子書

目录

  • 将DDD提炼成第一原则 – Scott Millett
    DDD或不DDD ……如果你的领域很无聊怎么办? – WeronikaŁabaj
    使用EventStorming发现有限的上下文 – Alberto Brandolini
    通过细化的紧急上下文 – Mathias Verraes
    守夜人 – Indu Alagarsamy
    痕迹,轨迹,轨迹和路径:探索我们如何进行软件设计 – Rebecca Wirfs-Brock
    无所不在的语言 – 不仅仅是共享词汇 – Avraham Poupko
    使用代数数据类型进行域建模 – Scott Wlaschin
    使用Monoids进行域建模 – Cyrille Martraire
    增强DDD – David West教授
    你在建造正确的东西吗? – Alexey Zimarev
    多个规范模型 – 马丁福勒
    从人类决策到建议到自动决策 – Jef Claes
    时间 – JérémieChassaing
    代理商Agent也称为steroids上的Domain对象 – Einar Landre
    领域驱动设计作为编码器的可用性 – Anita Kvamme
    在惠而浦的模型探索 – 肯尼巴斯 – 施威格勒
    领域驱动设计作为中心集 – Paul Rayner
    DDD – 被误解的咒语 – 詹姆斯O. Coplien
    释放合作障碍 – 梅尔康威
    7年的DDD:解决大规模营销系统的复杂性 – Vladik Khononov
    解决ERP软件中的复杂性:对有界上下文的情歌 – Machiel de Graaf和Michiel Overeem
    在有界上下文下平息你的精神 – Julie Lerman

.

不要被自己的大腦騙了

我們的大腦並不完美,所以不要被自己的大腦騙了。

未命名

2007年出版(繁體版: 住在大腦裡的8個騙子)

.

改善心智模式Improving Mental Models

彼得.聖吉在《第五項修練》中的第二項;改善心智模式中談到『最好的想法為什麼會失敗?』元凶正是『心智模式』所造成的。造成失敗的主要原因在於它影響了我們的觀察。心智模式塑造了我們的感知;當不同心智模式的兩個人去觀察同一件事,會給出不同的描述,原因為他們看見了不同的細節,所以做出了不同的解釋。當群體看見了同樣的情境,也不見得會有同樣的解讀,團隊不能完全相信大家對於看見之後的解讀會是相同的。必須在透過相互的交談後確認擁有相同的共識,才能篤定。這是許多新創公司運用 MVP(最簡可行產品)或 Design Sprint(衝刺設計)等方法得到產品驗證之後,結果仍然招致失敗的主要原因;彼得.聖吉 強調是心智模式在作祟。因此在心智模式修練章節裡說明了我們常犯的心智誤區: 一、推論階梯、二、左手欄、三、兼顧主張與探詢。(請參考: 領導者要消除的心智模式誤區)

 

 

人們是怎麼想的 -《大腦里8個騙子》蔻德麗雅‧范恩Cordelia Fine

這是一本描述人類心理學的著作,書裏頭闡述了人類思維的這八個騙子,希望你越早知道越好。比如,你明明覺得自己花一個星期就可以完成的計劃,卻拖拖拉拉寫了三個月?又;雙十一到了,你一再地告誡自己,這次一定要控制開銷,不買就是不買那些用不著的東西,可是到了那天,因為看到許多人都買了,你還是忍不住買了一大堆。你或許會問,這是怎麼了?自己是不是意志力太薄弱了。同樣是遲到,你沒有準時總是有合理原因,而別人沒準時,再多理由都是藉口,為什麼腦子裡會有這樣的雙重標準呢?告訴你別驚訝;是你的腦子欺騙了你。我們的大腦並不完美,因此心智需要修練。解決方法是;以系統的方式進行思維。

 

習慣以系統的方式思維 – 限制理論TOC

身為技術人員的系統思維衝擊(註1. 由DevOps的觀點看系統思維)。專案開始之初;最應該做的是盡快看見全貌,這個全貌自然指的是一個系統,所以應該由先”定義系統及目標為開始”。先弄清楚客戶真正的問題做出發點,因為隨後而來的所有行為,都會指向這個大目標。運用把它想成是一個完整系統的方式來思考問題,由決定系統範圍開始,也就是確定專案的Scope。以一種要求客觀的思維模式,它具有很好的收斂效果,可以避免方向上過於發散。

 

抉擇是寫程式過程的必要行為

程式設計師在寫程式的過程裡,可能是所有職業中必須同時兼做最多邏輯抉擇的一種職業。天天作這麼多邏輯抉擇但卻不會改善或增強你做人處世的邏輯思維。好繞口,要怎麼說呢? 現象是不管你寫再多的程式,它並不會讓你處世的邏輯思維變得更好的。因為你的程式思維只是在做程式語法的抉擇罷了,與為人處事時的邏輯認知毫無關聯。因此務實地學會系統思維吧! 對於程式設計人員;建議由限制理論開始。

 

限制理論(TOC)是教你如何思考的方法

思維的流程是這樣子的;先問: 要改變什麼 What to Change?再來是問:  要改變成什麼What to Change to?然後是: 如何改變How to Cause the Change?

用提問的方式來思考。

 

系統改進的三個問題:

  • 要改變什麼? 針對當前狀況,陳列出系統的制約(缺陷)。
  • 要改變成什麼? 決定未來狀況,設定目標,提出核心解決方案。
  • 如何改變?確定由當前邁向未來理想狀況的關鍵要素,設定步驟改善它。

 

TOC的思維流程(工具)有二: 充分原因思維(因果歸納)、必要條件思維(演繹推理)。

  • 充分原因思維: 假設因為某些事物的存在,而導致另一些事物存。(歸納)
  • 必要條件思維: 假設某些事情必須先於其他事情存在時。(演繹)

.

羅基思維

歸納與演繹是邏輯思維的二個基本原理

.

邏輯思維的本質

上圖說明的是金字塔原理,我們在談限制理論時卻拿金字塔原理來做說明,是基於殊途同歸的原因。限制理論的二種思維工具正好是金字塔原理橫向綜合的歸納與演繹法。而限制理論的存疑則正好與金字塔原理對於上下層的So what/Why so? 的質問方式不謀而合。因為同屬於解題的思維方式,所以本質上都是教人如何思考解題的方法,自然十分相似。採用限制理論,是由於限制理論是更明確的針對製造業的流程進行持續改善的,因此在這裡讓人更能有感覺一些。

.

克服無知

運用小增量、多迭代來延遲決策

.

不要被自己的大腦騙了

專案開始之初,我們處於無知的無知之下(不知道自己不知道些什麼? 無知;指的是資訊不足)。許多的假設判斷都來自於直覺(相信大腦第一時間的判斷),因此很容易就被事物的表徵所誤導。所以;能除了經常養成質疑的精神會有所幫助之外,運用敏捷的方式也十分受用;也就是小增量、多迭代與尋求回饋,可以避免在一開始就做了過多的決策。運用精實Lean的原則也不錯;就是盡量延遲決策。借助延遲的方式爭取較多的時間獲取更多資訊,以獲得更多的訊息來減少我們的無知,減少運用直覺作成決策的機會。

 

爭取到的時間我們應該運用何種思維工具來協助我們減少無知呢? 答案是刻意發現Deliberate discovery。最後;附上 Dan North 在寫程式上、在專案規畫上及分析作業上的心得:

於撰寫程式上:

刻意發現

.

於專案規畫上:

刻意發現_2

.

於分析作業上:

刻意發現_3

.

註 1.

在描述 DevOps的《鳳凰計畫》出版之後,附錄裡的三步工作的第一步、系統思維。(稍後又被原作者改成The principles of FLOW)改成「流, FLOW」,是有原因的。作者原本的系統思維(System Thinking)所指的是高德拉特先生的限制理論(Theory of Constraints,TOC),但書裏頭卻沒有明白地說出來,只寫成「系統思維」。而System Thinking在網路上搜尋到最多的便是由麻省理工學院系統動力學之父傑·萊特·福裡斯特(Jay W. Forrester)所推廣的一種系統思維方法。雖然一樣受用,但在偏向科技的DevOps運用上確實範圍太廣了些。所以才有了這樣的修正。

 

估算與風險

敏捷不作估算,除非風險在可控管的範圍之內。

敏捷文化

.

風險

風險影響/概率圖

.

先評估風險再做估算

如果估算所引發的風險超出你所能承受的範圍時,先進行那些能夠降低風險的措施(任務),直到我們進入能夠承擔的風險範圍之內時,再進行估算(參考自Pollyanna Pixton所著的《敏捷文化》)。這裡所謂的進行那些能夠降低風險的措施;指的是獲得對工作任務更加了解的資訊(包括學習在內)。這是針對BDD之父Dan North所謂的在專案開始時,也就是專案最無知的時候,要避免做過多的決策,所引發的專案失控的災難而言。

 

上圖是極為簡潔的風險影響/概率圖(Risk Impact/Probability Chart),它比一般的Probability and Impact Matrix更簡單更容易實踐一些,拿來讓團隊一起討論一起面對風險是在好不過的了(可以大量凝聚共識),拿來在團隊進入估算作業前的前置分析使用。好處是透明化與讓團隊共同承擔,又可以避免工程師過於樂觀的估算。縱軸是風險發生的或然率,橫軸是它的影響大小。都採用 1到 10 來進行衡量(例: 如上圖所示4-3,指的是概率為4,風險指數為 3的任務單)。

 

.

風險影響/概率圖提供了一個有用的框架,可幫助您確定需要注意的風險。

-By Mind tool control team

.

概率(縱軸)所指的是風險“可能”發生的機率。它發生的可能性範圍從0%以上到100%以下。(當然;不能完全是100%,因為那樣就可以確定,而不是風險。也不能完全是0%,否則就不是風險了。)

影響(橫軸) 指的是風險從本質上來說總是產生負面影響。但是,影響的規模因成本以及對健康,人類生活或其他某些關鍵因素的影響而異。

 

採用它是想藉由可視覺化的功能來協助團隊充分了解做成決擇;它的簡潔性;在一邊發生風險的概率,而在另外一邊上表示該風險的大小影響。讓團隊能夠有效率的進行討論。並決定是否進行估算作業,或是決定估算作業應該做到哪個程度為止。風險影響/概率圖並不是主角,因為對風險評估而言,似乎簡單了些,並沒有提供對風險足夠豐富的資訊。但這裡它只是參考不是主角,估算才是。

 

估算不是一個精準的數字

沒有人會去在意估算是否精準,通常在意的是任務是否是在範圍內良好地完成了。當專案經理報告整個專案需要 25.2個人月的估算時,你的理解可能是「需要20到30個人月」才能夠完成的概念吧!。鬼才相信能在一開始就給定一個完完全正確的數值。你也肯定知道專案的精確估算是隨著開發進展持續在做提升的。因此一開始我們就應該只給定一個範圍,一個我們透過風險分析後可以承受的範圍區間。

.

管制圖

仿照Shewhart chart的估算控制圖

.

左側是修哈特圖示,它普遍被運用在流程管制上。當流程的統計特性符合常態分布時,所有數據中會有99.7300%會落入過程固有界限之間(也就是三個標準差3σ的界限)。它很像我們常看到的”財務預算表”,也從來沒有準確過,但卻能為管理者提供了一個可以依循的範圍。右側是我們運用同樣的觀念;取樣每個迭代團隊所完成的工作量,如果都能在最小與最大的範圍內持續進行,便可以預期在多少個迭代之後便能如預訂計畫中的完成任務。至於右上角出現超出最大值或是有低於最小值出現時,正是有值得我們關注的徵兆發生了,值得團隊進行檢討回顧,找出原因。

 

結論

分解是複雜問題的剋星,它能夠降低開發時的風險。我們可以借助階層的分解方式來降低任務的複雜度。傳統開發中的工作分解結構WBS(Work Breakdown Structure) 對於估算的質量而言有著相當的意義。只是敏捷為避免大量的文書作業吃掉了可以用來工作的時間,所以並沒有去強調它。久而久之反而造成工程師做估算時少去了一個良好的工具,要知道光靠使用者故事的抽象涵蓋度,是不足以支撐良好的估算的。而WBS 應該是工程師的本質學能,不宜忽略它。

 

估算與計畫是二個相關的話題,但估算不是計畫。估算應該視為客觀的分析過程,而計畫則應該看作是主觀的目標求解的過程。雖然計畫在一定程度上是依賴於估算的結果,但計畫並不一定要與估算相同,Gojko Adzic著名的影響地圖便是一個好的範例。它是敏捷開發中依靠持續衡量對計畫做修正的一種作法,也是一種延遲決策的方法。

 

敏捷做估算嗎? 敏捷只在風險可控管之下進行估算。這樣可以避免專案開始時的無知(資訊不足==無知)之下作決策所造成的災難。敏捷相反過來;要求在專案開發中快速的挖掘不足的知識,然後依靠它來做成下一個決策,這是一種演生式的過程,因此又稱為衍生式設計(Generative Design)。

 

敏捷做計畫嗎? 敏捷在行動之前當然要做計劃,但是只做較概略的計畫,至於落實它則是在進行中以踏實的步驟來完成實踐。

 

 

註1 《敏捷文化》為Pollyanna Pixton,Paul Gibson,Niel Nickolaisen 所合著。

註2. 管制圖Control chart),也稱為修哈特圖(Shewhart chart)或流程行為圖,是統計製程管制中,確定製造或業務流程是否在統計管制狀態下的一種工具。

註3. 估算不是承諾 -《软件估算:黑匣子揭秘》by Steve Mcconnell.