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

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

.

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

.

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

.

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

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

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

快速直覺的抉擇方式，往往缺少了深思熟慮

.

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

.

技術債 Technical debt

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

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

.

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

.

程式碼的黑洞

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

學會刪減程式碼的習慣

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

上線後的重構作業

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

.

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

.

結語

作為改善開發效能顧問的雙管齊下手法；一是運用敏捷與精實(看板)來改善開發流程的效能。另一是深入商業領域探討對此領域(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.

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下去了。

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

.

專案重做一次

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

.

小結

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

.

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

.

無知的警語

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

.

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

.

無知是一種優勢 — 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 在寫程式上、在專案規畫上及分析作業上的心得:

於撰寫程式上:

.

於專案規畫上:

.

於分析作業上:

.

註 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.

 

 

 

刻意發現 Deliberate Discovery

.如同Ericsson先生的刻意練習一書所言，透過刻意練習也能打破無知。Dan North認為專案開始之初的無知，也能藉由刻意發現來彌補我們最初的無知，迅速累積相關的知識，避免因為無知而犯下錯誤的決策。(無知；指的是資訊的不足， 刻意發現 Deliberate Discovery)

.

刻意發現 – Dan North

專案啟動時，團隊缺乏業務領域、構建技術、遺留代碼、工具等方面的知識，處於對專案最無知的狀態，其中也包含對無知的無知(don’t know what I don’t know)。無知是專案開發進度和品質的最大制約。被動的、基於已有知識決策是不夠的。團隊應該在開發過程中，通過有計劃的活動，刻意的去探索發現，以最快和最大化的消除影響專案進展的無知。這一過 程被稱為刻意發現的過程，它加速了軟體發展的知識創建過程，同時為專案決策提供知識和技能的支援。

 

刻意發現(Deliberate Discovery) 強調了無論是需求還是設計，都要避免過多的預設計，而要通過在日常功能開發過程中不斷地、有紀律地、刻意地去發現，去抽象，去演進，才會做出好的系統。運用反覆運算(迭代)的方式貫穿整個產品開發的方方面面，是刻意的。

.

敏捷運用多迭代的方式，提供延遲在每一個迭代結束時在做決策的時機

.

這裡試著把軟體開發的過程分成前、中、後期，也就是前期:前置分析、中期:行動學習及後期:後置回饋三個時期。敏捷開發中的 Scrum 大都以會議的形式達成後置開發的經驗(知識)的累積。下圖中分別以思維、過程、對象及工具為縱軸，並填入敏捷流行的應用工具(前置分析為影響地圖、需求開發階段則為使用者故事地圖)。採用影響地圖來做前期的分析工具，相對比較主觀所以一定要加入衡量和替代方案的概念。行動學習期則搭配使用者故事地圖，能提供看得見的需求全貌，讓團隊可以一直知道自己現在的位置，也有利於做需求的優先排序。

.

視覺化產品開發中的價值

.

專案；重做一次(註2)

回顧會議進行到尾聲時，我總喜歡問工程師；如果讓你重做一次，你會怎麼做? 需要多少時間? 目的是希望工程師能記住遇到過的障礙，同時讓團隊成員也能學到他的經驗。但其實；真的重做一次，你就能克服所有的限制了嗎? 正確的思考方式應該是TOC；如果你熟悉高德拉特的限制理論(TOC; Theory of Constraints)的話，應該就能輕易地意識到還是有太多你始料未及的障礙存在哪裡，而你是不可能完全弄清楚的(總是會有你不知道的訊息不知道的限制存在；所謂的無知 ignorance指的是；系統裡存在太多你不會知道的訊息)。所以敏捷以小增量、多迭代與尋求回饋來持續改善。因此落實敏捷可以讓你做得更好。另外；精實理論Lean 則推廣延遲決策的原則，來最佳化你的決策。圖示如下，應該以刻意發現的策略來彌補專案相關知識不足的地方，待續 …

.

針對計畫、需求、技術的延遲決策 進行延遲決策

.

註 1. 參考網站 https://dannorth.net/2010/08/30/introducing-deliberate-discovery/

註 2. 有關刻意發現，Dan North 的一場精彩演講。 裡面提到"專案；重做一次"應該有的思維方式。

 

高品質的關注

塑造文化，就從高品質的關注開始。

.

積極傾聽是帶來高品質關注的首要元素。

.

孩子的行為在引起關注

孩子的行為表現來自於我們對他們的行為所表現出來的態度。孩子們表現的調皮搗蛋無非是想得到我們的關注，這個時候；我們所給予的關注品質將會影響到他們未來的人格發展。

 

所以當孩子們在胡鬧的時候；請後退一步，換位思考(stand back and deliver；註2)：“這是怎麼回事？小傢伙想要幹什麼呢？”這就是奧妙所在。如果孩子的反社會行為是想引起注意，那麼你給予的注意，其品質是不是值得商榷呢?

 

關注具有多樣性; 它分為很多不同的等級和面孔。盡其所能給予孩子高品質的關注，應該成為每位在意孩子們行為表現的家長們所追求的目標；它對孩子們的幸福和心理健康極為重要。孩子永遠迫切需要得到高品質的關注，滿足孩子的這種需求對你也裨益良多。當孩子獲得的關注的等級不能得到滿足的時候(通常他們都會爭取最高品質的關注)，他們會繼續尋求，不找到他們需要的關注是不會善罷甘休的(愛搗蛋、話多)。反過來說；如果你給予孩子最高品質的關注，就會得到一個乖巧聽話的孩子。

 

要如何展現高品質的關注呢?

積極傾聽；上面的圖示拆解「聽」這個字，解答了我們的問題。我們用耳多來進行來聽的行為，也就是傾聽；這是父母在公司裡忙碌一天回到家後最容易忽略的地方，也就是沒有能專注地聆聽孩子們的說話。傾聽；我們不只是要表現得專注的在聽，還要用心地聽，必須清楚的區分；孩子們現在說的是在描述他們經過一整天與人相處之後所得到的經驗還是他對事情的想法、建議。適當的回應他將落實他內心的所得，若能再加以正確的引導，將形成他對於事物的邏輯思維，形成一種經驗的傳承，這是無價的溝通與親情的培養，而這一切起始於積極傾聽。

.

主管的思維模式決定了領導方式

.

高品質的關注對於團隊行為的影響

「主管對於團隊行為所表現出來的關注品質」將直接影響到團隊的表現。如同家庭文化的形成一般，團隊的文化也是在彼此的交互關注之下逐漸形成的。一個領導者的心態的轉變，將容易造成整個組織文化的改變，因此組織變革的首要事務，是在弄清楚要解決的問題之後，先改變主管的心態，進而讓他影響到團隊行為的變遷，再來才是調整流程，讓正確的流程帶起效能與品質的提升，然後再根據這種心態來解題。至於變革的成效有一大半要歸結於團隊(含主管)相互的關注品質的程度好壞。

 

敏捷強調的是團隊的自組織，也就是團隊需要自主管理並經常性的實行團隊共同決策的方式。但其實不只是敏捷團隊如此，包含美國總統在白宮內所做的決策，也多半是來自智囊團隊，也是某種形式的群體決策，(當然那些獨裁者是例外的)，如何善用團隊智慧便成為決策體系所依賴的一種共通形式，畢竟沒有人能什麼都懂、什麼都知道的，而團隊決策能讓決策訊息變深變廣，但團隊決策也不是一定都是好的(註1.《破解團隊迷失》Cass R. Sunstein 凱斯.桑思坦、Reid Hastie雷德.海斯蒂)，這一點常常成為主管不放心充分授權的藉口，這是一種典型的短視症候群。解法是組織變革時要盡力去改善的訊息流程，好的流程可以減少錯誤的決策，也能夠增加我們的視野，看見那些原本隱藏著的訊息。

.

高品質的關注換來孩子健康的心靈，也是建立團隊互信的基礎。

.

團隊決策要避免的錯誤

.

註1.《破解團隊迷失》Cass R. Sunstein 凱斯.桑思坦、Reid Hastie雷德.海斯蒂)

註2. 《Stand back and deliver》 作者 Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent J. Mcdonald

 

敏捷精神

迭代開發是敏捷用來應對模糊、不確定性的良方。

-《敏捷文化》

.

只有擁有了敏捷精神才能由Doing Agile走向Being Agile.

.

衡量敏捷化

你一定很想知道組織實行敏捷化的成效如何? 網路上有一堆評估的表格，你可以試著去填填看，或許會有讓你驚訝的結果。但填完後，結果出來了卻反而讓人覺得好像不是那麼的重要了，因為團隊在開發上的實質表現才是真正值得我們去關注的。哪些問卷上的選項只是提醒我們疏忽了那些地方，又有那些地方是我們應該持續去改善的。作過以後總會有一些心得的，但還是無從衡量團隊的敏捷化程度。

 

Doing Agile 實行敏捷

實行敏捷變革，一般我們會由組織與流程開始轉變起，也就是從 Doing Agile 開始。在實行一段時間的敏捷化後，許多執行上的困惑；『我這樣做敏捷嗎?』、『 我做對了嗎?』 這些問題會經常來困擾你，會有讓你想衡量看看自己所實施的敏捷到底作到什麼程度的疑惑，你會想去衡量看看，然後在衡量之後；又會覺得知道了又好像沒有知道一般，這時候你就能體會到敏捷其實是一種文化，它比較難用數據來作評估，雖然難以評估，但它卻能充分的表現在團隊的行為上。下面所描述的這幾個行為表徵，正可以拿來判斷你的團隊是否擁有敏捷化的精神，而不只是在Doing Agile依樣畫葫蘆而已。

.

如果你要衡量團隊敏捷化的程度，請發問卷讓團隊個別去作答，而不是自己去填寫問卷。

-由利益相關者填寫問卷，才有意義。

.

》自主決策，不要等待命令

前提是透明與形成共識。應對快速變化的良方是在第一時間作出正確的反應，避免錯失良機。這是繼2001年的911事件後，最為世界各國情報單位所追求的效率目標，也是所有反恐部隊的圭臬。大家幾乎同時意識到訊息的價值，不是在獲得而是在獲得之後如何去處理，此時透明化便成了最基本的要求，要反應快速，讓訊息被看見的視覺化與看見後能形成共識便成了能否快速行動的先決條件。要知道；敏捷開發 agile development並不是一個強調快速開發的方法，而是強調如何應對快速變化之下的處理措施，在快速應變的前提下，人們常常會誤會敏捷不是不作計畫嗎? 不作計畫怎麼行得通呢! 敏捷也作計畫只是不作太長遠的計畫，敏捷總是在規劃如何以小增量、多迭代及快速尋求回饋的方式持續運作著。也就是「計畫可以粗略些，但是必須分步驟落實」。(註1.《賦能》為斯坦利·麥克里斯特爾將軍所著)

 

》主動找問題，不是等待問題找上門

這是敏捷努力要打破的一種傳統組織(就是以部門為中心組成開發團隊；稱為 component team的組隊方式)容易產生的詬病，也就是所謂的 Silo穀倉效應，它描述人人自掃門前雪的問題，也就是大家只重視自己的責任是否守住了，而忽略了團隊的真正目標是要完成任務才有意義。就是人人以各司其職，只為自己負責，便產生了問題找人的現象，責任被分散了。反之；敏捷以團隊的目標為導向成敗由團隊負責，此時一個任務變成由多個人來負責，就形成一種人找問題的現象(強調以 Feature team的方式組成開發團隊)。(註 2. 《穀倉效應》為 Gillian Tett 所著)

 

》維持彈性調整，優先做最重要的事。

工程師對著PO說道: 『這跟你上次講的不一樣?』、『不是已經講好了要這樣做了嗎?怎麼又改了.』一副準備發飆的樣子。

敏捷開發是應對需求快速變化所衍生出來的開發方法，只要知道是對的事，需求經常很務實的就跟著改變了(因為增量小，因此改變的衝擊也小了)。但頻繁的更改需求一定會造成工程師的一大困擾，但如果改變是必要的時候，上面的現象就難以避免了。由團隊對變更的反應可以看出他們的敏捷性，埋怨是合理的，但如果是必要的；「我可以接受PO隨時調整需要調整的任務內容，因為開發的目的是產出對客戶有價值的東西，這才是重點」。

 

相對的是；PO是否對任務的優先序也時時在作評估跟調整呢? 也就是說；我們要always (總是)作最重要的事，而不是盲目的依序計畫在工作。對於有限時間的規劃(加班是一種變相加長工時的作法，不符合敏捷的精神，應該追求的是效能)，以追求對顧客最有價值的功能為主。說穿了；就是在正常開發時間下，盡量去開發較有價值的需求，時間到了就停止開發，一種時間盒的概念(註3，Scrum的會議都採用時間盒的會議，時間盒；就是時間到了就結束的作法)。

 .

現象: 需求總是排得滿滿的，優先順序都是A+.

敏捷開發以為開發工作應該盡量的正常化，偶而加班是難以避免的，正常化的工作才是長久之計。主管需要經常思考:「我要如何讓團隊成員完全不加班呢？」

-正解是思考如何提升工作效率。

.

》團隊互助: 隨時掌握情況，互相幫助解決問題

即便團隊成員在能力上都沒有增長，只要團隊開始產生互相幫助的現象，團隊的戰力就提升了。這是敏捷要求團隊自組織的基本精神 –互助。然而；要團隊產生強大的互助性，就需要feature team，在以各有專長的Feature team組成型式的開發團隊裡，彼此能夠相互學習增強團隊的戰力。

既然是以團隊為核心，團隊中的每個執行人員，都該對所有任務負責，不會有哪一個項目應該由誰來做，或東西做錯應該是誰的問題。

.

學習；就是要在不自在的環境下自在的學習著。

–不在乎暴露自己弱點的人

.

以團隊為核心

.

將站立會議上講的三個問題，改成昨天我解決了什麼問題?今天我準備克服什麼問題。

-以解決問題為主的站立會議

.

》Work smart: 專注於如何在固定時間內，產出更多價值

如何將經驗轉換成能力呢? 我們不是每經過一次事件就能完全吸收到其中的知識的，常常聽到人們在事後報怨: 『早知道我就多買一些』，但其實再給他一次機會，它可能還是會作同的決策。所謂的千金難買早知道，其實是心態在作祟，若是你真正學到了，自然心態改變了，結果也就改變了。David Kolb’s 在體驗學習環裡教我們四步驟作好紮實的學習。

.

「具體經驗 – 反思– 領會 – 實驗」四步驟，將經驗轉換成知識

.

要如何work smart 呢?

就是給他釣竿而不是直接給他魚。這裡有幾個基本的想法跟大家分享:

1. 任何問題；都不會只有一種解法；一定有不同的做法，能更快速的完成任務？
2. Do less earn more. 可以少作或是不用作的功能，盡量運用UX/UI的設計避開它來。
3. 持續調整，始終追求讓事情進行得更順暢的方法。
4. 運用系統思維: 是否能先完成某些工作，讓日後的許多工作可以一勞永逸的呢？思考架構可以幫上什麼忙?

.

敏捷精神就是團隊所表現出來的行為模式，就是團隊的敏捷文化

.

敏捷重要精神雷達圖

.

註1. 《賦能》斯坦利·麥克里斯特爾將軍.

註2. 《穀藏效應》Gillian Tett

註3. 時間盒 Timeboxing

註 4. 《敏捷文化》 Pollyanna Pixton 等

 

 

心態是組織變革的關鍵

想要改變結果，就要改變讓你如此行事的心態.

主管的心態形成他的行為，被團隊解讀之後產生團隊的行為

.

心態是你的作業系統 (註1)

心態(mindset)就是你的思維和情緒，它們是一個人的底層作業系統。而人的心態就好比電腦的作業系統一樣，電腦需要作業系統才能運作，人的心態也是如此，你用它來產生行為並獲取結果。它掌控了你的決策、發言與提問。就像作業系統一樣，心態讓你快速輕鬆巧妙的採取各種行動，它的動作取決於你的核心價值與假設來設計行成你的行為，讓你能夠即刻行動，不用花太多時間去思考就做出種種反應，這都是靠心態所為。

 

當你遭遇問題時的反應，正是你的心態對問題快速解讀之後的反應，只是它居於後台，拿電腦作比喻，我們所表現出來的行為，則可以表述為被呼叫到的應用軟體，它們透過執行特定的應用程式來達成任務，而作業系統則負責後勤支援的服務。我們都知道過時的作業系統是很難跑得動新的應用程式的(組織實行新政策也是如此)，所以我們需要定期更新作業系統，而人的心態與行為也是如此，有時你想要改變行為以追求更好的結果，此時你必須更新你的作業系統，也就是要改變你的心態才是最有效的解法，才可以跑得動新的應用程式讓它能運行順暢。這個比喻就好像我們為了改善團隊的績效，採用了新的策略來解決問題，改變作了但卻遲遲不見成效，或是始終不能順暢的推行起來，其實是作業系統需要先做更新了，你怎能期待原先(舊的)作業系統能跑得動新的應用程式呢? 你的作業系統需要更新，也就是說是你需要改變心態了。

什麼是心態mindset？mindset就是你思考問題的方式。

常常聽見人們後悔地說：『哎呀，我要是當年多買幾套房就好了』。但如果現在有同樣的投資機會他還是會錯過的。這就是因為一個人的思維模式沒有改變他所做的決定其實和之前都是會一樣的。

.

組織變革；心態需要先做更新。

-羅傑.史瓦茲 Roger Schwarz.

.

. 心態 (圖一) .

. 行為 (圖二).

. 表現出來的 – 績效 (圖三) .

圖一、二、三即著名的「相互學習模式」

組織變革；需要先更新心態

心態要更新；應該要先更新領導者的心態? 還是先更新團隊的心態呢? 《打造卓越領導力》一書的作者羅傑.史瓦茲建議，應該是一起改變才是，也就是相互學習(mutual learning)的心態，具體的做法呈現在上圖中，先是心態改變(圖一)導致行為(圖二)的改變，最後帶來績效(圖三)的變化。

 

組織變革；說穿了就是想要改變團隊開發作業的結果，而要改變開發作業結果，就要改變讓你如此行事的心態，如果心態不變，又怎能期待再做一次時會有不同的結果呢?

.

人在生活環境改變時，首先要改變的是你(妳)的心態

.

基因影響我們的聰明才智與天賦，但影響一個人成功與否的特質，卻並非在出生時就固定。心態，才是影響個人學習、成長、人際關係、終身成就、人生道路的最重要關鍵。

卡蘿．杜維 Carol S. Dweck

.

小結

實行敏捷變革要從哪裡開始呢? 外商公司的習慣是換一組人來負責，或是以置換負責人的方式來做起手式，(一種換人做做看的理念)新人新氣象也自然讓人容易期待好的改變的到來。但中國公司就不一樣了，我們總是以改變組織的結構(合併或拆散重組一下團隊)或是引入新的方法論(Scrum、DevOps…)，只做事的調整，沒做人的調整，就希望在重組的情形下能夠產生好的結果，一種換湯不換藥的改組形式。也顯現出中國企業容易鄉愿的心態，把這整個現象歸咎於人情味濃也可以說得過去，其實基本上是文化的因素所造成的差異，但它並不是變革成敗的關鍵因素，在鄉愿的心態下我們依然能夠變革成功的。

因為變革成敗的一個重點在領導者的心態是否真的改變了，因為一個領導者心態的轉變，將容易造成整個組織文化的改變，因而影響到團隊行為的變遷，也就是上面第一張圖所顯示的，主管的心態形成了他的行為，而主管的行為被團隊解讀之後產生了團隊的行為，團隊的行為表現又看在主管眼裡加強了主管的心態改變，形成一種交互的循環，對於敏捷而言；正向的循環是採用相互學習模式，負向的循環則是採用了傳統的單向控制模式(註1)。因此組織進行變革，首先要改變主管的心態，而心態正是改變領導方式的關鍵。

 

.

勤於練習的心態

從小到大，我們在不斷試錯、學習新事物、練習新技能的過程中成長起來。人生中值得去做的每一件事情，都需要練習。但隨著年齡的增長，我們漸漸失去了“練習的心態”，許多練習過程變成一種痛苦和煎熬：我們只盯著目標和成績，內心充滿壓力和焦慮，因此在學習一項新技能時，經常剛開始就放棄，或者面對生活或工作的挑戰，無法耐心又專心地應對。

要知道；適當的練習不是苦差事，而是一個有意義的過程，可以幫助你發展出耐心、專注與自律這樣看似難以獲得的優秀品質。

湯瑪斯 M.斯特納 Thomas M. Sterner

.

如何改變心態

要想改變心態可能比實際上所想像的還要困難，如果想要因為組織結構改變了就能夠逼迫自己改變行事作風的話，效果或許要很久很久甚至永遠都不會到來，另外一個方法是開始改變自己與團隊產生行為與結構的心態。起手式是先去理解自己的心態，了解自己為什麼會陷入困境，理解自己為何在無意中讓團隊陷入困境的決策，同時思考接下來該如何脫困呢。動作是設法去更新你的作業系統，讓它能夠適應將要到來的改變，怎麼做呢? 答案是相互學習。藉由向他人學習和與他人共同學習來達成目標。羅傑.史瓦茲 Roger Schwarz有五個自我心態的假設提供我們參考(在你開始批評或懷疑他人的言行之前，請先思考):

• 我有資訊，別人也有資訊。
• 人人都會看到別人沒看到的資訊。
• 別人就算和我意見不同，仍然可能動機純正。
• 意見不同是學習的機會。
• 問題可能是我自己造成的。

《心態致勝》作者卡蘿.杜維克博士則提供(謝文憲老師整理出來的TMDS原則):

1. 你的事,就是我的事。Team Work and Trust 
2. 運用並管理資源。Manage Resources
3. 讓夥伴參與決策。Decision Making
4. 分擔責任與共享領導。Share responsibility and leadership

 

【註】參考:

1. 羅傑.史瓦茲Roger Schwarz所著的《打造卓越領導力》
2. 卡蘿．杜維 Carol S. Dweck 所著的《心態致勝》
3. 湯瑪斯 M.斯特納 Thomas M. Sterner 《練習心態》
4.  Mindset 心態、思維模式，例如: 著名的 《心態致勝》，簡體譯成:《終身成長》mindset=思維模式.

 

在不自在的情境下，自在地工作著

. 生活免不了種種的約束.

顧問工作；就是要在不自在的情境下，自在的工作著，

而團隊開發也是如此。

.

不自在；這句話會讓你聯想到什麼呢?

是不是想到一些讓你覺得臉紅的情境、讓你覺得尷尬的場面? 假設；這個時候你是在一個完全沒有人在的環境下，你還會覺得尷尬嗎? 如果一旁的人都是你的死黨、好友，一些無條件支持你的朋友，你還會覺得尷尬嗎?

 

讓我們來想一下；是什麼因素讓你覺得不再尷尬的呢? 它是一種自在的環境，它讓你的心裡覺得自己受保護著，沒有人會瞧不起你，不懂，沒有人會譏笑你，是這種感覺讓你卸下了心防，自然而然地你就不會再覺得不自在了! 而這種不會不自在的感覺，正足以開啟你快速學習的能力，它就稱為覺察性(Awareness)，它開啟快速學習之門。

 

自在的學習，在這種情境下，你會成長的最快

暴露自己不會的技能(技術)會讓你覺得尷尬、不自在，即便你的團隊就在身旁，那裡有許多人你可以請教，很快就能找到答案迅速就能弄清楚問題，但你還是會覺得不自在，因為這項技能你還不會。但實際上；你並不在乎，因為在你周圍的都是你的夥伴，這讓你能靜下心來，然後自在地工作著。這便是這句話的意義:

.

在不自在的情境下，自在地工作著

.

是這種心境讓你打開了束縛，所以你能盡情地去學習。因為你放掉了那些限制你成長的壓力因素，所以覺察力(Awareness)在這裡提升了起來，你可以沒有太多顧忌的工作著，學習效果便大大的提升了。這正是一個敏捷團隊所要追求的工作環境。工程師們不必要掩飾那些自己所不會或不足的地方，因為不會覺得尷尬，不必擔心被敲不起，所以打開了心智，讓自己很容易沉浸在學習的愉悅中，自然的提升了學習的效果。

 

顧問工作；就是要在不自在的情境下，自在的工作著

企業遇到自己無法解決的問題時就會想到要找顧問，因此顧問總是在最不好的時候出現，我們的工作要求自己要盡量的低調，最好是在完全不影響團隊的日常作業下就能看出問題，問題經確認後接著還要冷靜的分析並找到具體的解法。所以我們的服務來的快去得也快，工作時間很短暫，從熟悉環境、認識人員到識別問題，然後撰寫分析報告，從說服業者解題的方式到真正解題，通常會在二周到一個月的時間內，就告結束了。我們必須一直跟一堆問題相處，就是要在哪種不自在的情境下，盡量自在的工作著。這句話聽起來有一點繞口，也好像不太合乎邏輯，但這就是我的工作。有趣的是，我作診斷的方法，正是找出組織裡有那些是不合邏輯的地方，而通常那就是問題所在。

 

一般而言，都是老闆或主管找我們來作顧問的，所以團隊的配合度通常都很高，大家都很容易相處，但如果開始有那種不信任的味道出現時，通常也意味著你無法在自在的工作著了，也就是顧問工作要結束了。這種事情常會發生也經常由不得你，你也很難有扭轉的機會，因此顧問與團隊間的信任度相當的重要，有時還要更勝於主管與團隊間的互信。所以更要開誠布公。因為只有徹底的透明方可以減少那些無謂的猜疑。

.

主管「開誠布公」可以讓成員了解你，而心懷「好奇」則可以讓你了解成員。

– Roger Schwarz

.

如何才能製造出這種工作環境呢?

這是一種信任的信念，它讓你不在意也不認為自己會遭受到周遭人士的譏笑，所以就 open mind 了。這個道理一點也不難，就是設法建立一個能夠互相信任的團隊環境，身處在這樣子工作環境下的工程師自然能夠自在的工作與學習著。因為專案處理的過程其實就是一種學習的過程，工程師學習得越快曲線就越陡峭(中間那條藍色的一點鏈線，綠色虛線是PO的知識取線)，開發時程也就縮短了。因此我們要追求團隊能夠快速地學習。

.

工程師學習得越快曲線就越陡峭，開發速度也就越快

.

工程師必須迅速學會專案的 Domain Know how

年輕的工程師常把做專案時的精力集中在程式開發的技巧上，希望盡快追上流行中的新技術。但資深工程師都知道；工程師就是要隨著專案的專業知識，想寫什麼就要學什麼，學得越好越快程式就會寫得越吻合客戶的需求，學習的速度影響著專案開發的速度。上面那張圖示就在說明這個道理。中間那條藍色的一點鏈線是程式設計人員對需求的了解曲線，他上升的快也下來的很快(因為工程師若僅僅是為了開發程式而學習並沒有實際去運用它，快速學來的知識便會很快的退去)，而綠色虛線則是專案PO的知識曲線，它始終維持在一定的程度上。

 

在新專案啟動時，由於負責開發的團隊必須從新學會 Domain know how，弄懂了該領域的知識才有能力開始寫程式，因此那條藍色的一點鏈線開始的起始點總是很低，也就是說團隊在第一次開發全新軟體時，總是居於專業know how不足的清況下開始學習的，就是處於處處必須向人詢問、求助的尷尬情境下，此時主管是否能協助團隊製造出一個在不自在情境下，能夠自在工作的環境，便成了協助團隊快速學習的關鍵因素，對照到上面的圖示，就是協助團隊盡快到達 Ready 的狀態(綠色的圓圈)，這個 Ready 點；對需求而言稱為「定義完備」(Definition of ready)，對於工程師而言則是具備了足夠開始開發該軟體的專業知識，稱之為「基本的專業知識」(Basic domain know how)。這便是軟體工程師的工作歷程，正是所謂的「軟體開發實際上就是一場學習的歷程」，學習得越快專案就開發的越快。因此能否讓團隊「在不自在的情境下，自在地工作著」便成為加快團隊學習能量的重要因素了。

.

小結

你的信念成就你的行事風格，而你對事情的覺察性則決定了學習的品質。覺察性(Awareness) 會深受你是否對事情產生興趣所影響，也就是說你必須先產生興趣才可能從學習中產生樂趣，而這一點決定了你對這件事情的覺察性的高低。覺察性是一種態度，它會受到你(所接觸的種種)環境所影響，而程式開發總是會遇到你比較熟悉跟比較不熟悉的技術，工程師必須秉持著開放的觀念，不因為不懂而害怕被譏笑就裝懂(隱藏自己所不了解的事)，也就是不懂裝懂不敢提問，要知道沒有人生下來就什麼都知道的，那些很厲害的人物其實也都是從不懂過渡到懂的，只是他們學得特別快而已，而如何快速的學會，重點便在能否自在的處於學習的狀態，團隊在進行開發工作時學習是一件很重要的事，是主管的責任也是團隊共同的事，因此能否營造一個讓團隊能夠「在不自在的情境下(不去隱藏自己所不懂的事)，自在地工作著(快速的學習)」便是一件對團隊開發至關重要的事。

.

團隊成員彼此之間的信任度，決定了你是否能夠

在不自在的情境下，自在地工作著。

.