敏捷破壞者實戰手冊

.

.

破壞易，建設難

建立一個敏捷的團隊何其困難，但要破壞一個團隊的敏捷性卻是那麼的容易。原因很簡單；因為敏捷追求的是效能，而產出物要對客戶有真正的價值才有意義。所以無論是破壞開發的效能或是故意產出客戶不需要的東西，對運行敏捷都是一種破壞。

 

這裡參照了William J. Donovan 威廉. 唐納文將軍在二次世界大戰時所製作的《簡單破壞實戰手冊》撰寫了一篇《敏捷破壞者實戰手冊》，旨在提供團隊成員能夠相互提醒並引以為戒，避免同僚之間誤犯了破壞敏捷的忌諱。

 

敏捷性大都來自於團隊成員之間的相互學習

你可能上過一天或是數天的敏捷訓練課程，或者是經過一晚的熬夜之後便考上了CSM:  Certified ScrumMaster的證照(常常聽人們這麼說的)，有機會成為敏捷教練也就是所謂的敏捷教練Scrum Master. 但隨後當你面對問題時，引面而來的懷疑與慌張會持續許久許久，請不要懷憂喪志，因為敏捷開發是一種經驗主義，在你習得那些敏捷教練所教導的準則之後，實戰才要真正的開始。所以你的敏捷開發技巧與屬性，大都來自與同僚之間互動中所習得，當然參加敏捷社群活動可能是醞釀你的敏捷實力最好的地方。但說穿了，懂得與人相處才是重點。看書有用嗎? 當然有用，但要獲得實戰經驗才是重點，教學相長可能是一個好方法，尤其是獲得回饋更是彌足珍貴。

 

要敏捷；先懂得如何與人相處。

沒有比一群Scrum Master聚在起加入社群相互學習能更快敏捷化的了.

 

敏捷破壞者實戰手冊

第一招  凡事都要問主管

也就是一切按照公司規定依據規範來做事，即便是顯而易見的行事變通也絕不跨越公司規範。嚴格說起來你是最遵守組織規定的成員，理應得到獎賞，列為優秀員工並予以表揚，但試著想想看，有多少次你可以見機行事擴大工作成效或是避開錯誤細節的機會，但你卻因為害怕違反公司規範而作罷。老實說；有時你應該選擇違規行事而不是事事請示上級。創始看板的 Toyota生產線就有一句名言是這樣說的:「現場的工頭才是真正了解現況的人，因此決策應該是由他來下達才最正確」，所謂盲目遵循規範是最不敏捷的行為，敏捷追求小增量、多迭代的方式，正是避開錯誤的假設造成巨大錯誤的法則，追求的是持續修正，因此一切以回饋為重。視回饋為避開錯誤並持續修正的首要原則。

 

遵循公司一切的規定，就是所謂的服從者或可稱之為「服從破壞者」， 為什麼稱他為破壞者呢? 因為我們做事解決問題時，有時應該試著成為「違規者」，或可稱為一種嘗試失敗的勇氣，因為只有試過後才是學到最多東西的時候。人們是依據自己的價值觀行事，團隊依據團隊的價值觀行事，組織依據組織的價值觀行事(而這些行事的抉擇將形成一種組織的文化)，因此當你面試一位新人要加入團隊時，最重要的準則便是該人士的價值觀與團隊的價值觀是否一致，一致的價值觀足以形成團隊的內聚力，這種內聚力便能形成團隊一起工作時效能的後盾(反之；將成為排斥的力量)，這也就是為何Scrum Master會一直要求主管要後退一步的原因，讓團隊習慣獲取自治的所有權，形成習慣性的自組織形式，讓團隊依據團隊價值觀決定行事的準則，才能引發群體智慧自行解決疑難雜症，你說應該是依據準則做事還是方便行事呢?

.

主管與團隊行為相互影響循環

.

始作俑者是主管

主管的態度決定他的行為，而團隊依據對主管行為的解讀來決定團隊的行為。所以主管的態度間接影響了團隊的抉擇，因此表現的公正不阿是任何一位做主管者應該要有的基本態度，而建立與下屬之間的誠信度則決定了團隊自組織的成效。

 

了解你的團隊 – 常態分布檢測法

想知道自己的團隊是屬於服從破壞者較多，還是違規者較多呢 ?做一個簡單的問卷分析便能清楚了。實驗是這樣的；做一個問卷，問每個人假設他是一位櫃台經理，他有權利給予入住房客升等房型的決定權。他可以破例給任何一位旅客升等，也可以不給。給了以後升等房型就減少了，旅社就少賺一點錢了。不給則可能失去那些上回被升等過的老客戶。由他們回答問卷的行為模式，便可以統計出來團隊的服從者與違規者的數量。基本統計應該是呈現標準的常態分配曲線，如下圖。

.

.

敏捷較害怕服從型的破壞者

對於違規者只要多加耳提面命，幾次之後就不難修正他善於違規的行為。但因絕對服從而造成的破壞者行為就比較困難了。如果團隊表現的讓上面的鐘形曲線偏右，怎顯示這個團隊擁有較佳的敏捷性。反之；則團隊固執於傳統的管理模式。

 

先知道平衡點在哪裡才可能站得穩

這是八條破壞手則的第一條，我認為它是最重要的。這是因為我們以自組織為最優團隊的原故，而團隊要自主到什麼地步呢？他們懂得拿捏分吋嗎？決定就在這個平衡點了。團隊必須首先擁有認同於企業文化的思維方式之後，才具有塑造自己價值觀的能力。因此發掘並創造一個團隊的價值觀正是自組織的基礎，所以擁有決策時能一致的服從性，應該是最重要的一環。

 

第二招    長篇大論話當年

經驗讓我們預見事情的後果，但也是最能誤導我們的東西。如果我們做事一切依照經驗的話，就少了創新的機會。這裡要談的是「經驗型的破壞者」。這類人士通常不是技術領導人(Technical Leader)就是中間的主管。這是一種很能做事的人，但經驗經常左右了他的決策，當遇到該變通的時候，他往往是最後一個察覺到該改變了的人，對於敏捷要求針對需求的改變作出快速應變的原則相違悖，也間接造成了團隊效能停滯不前的緣故，因為這個團隊少了嘗試錯誤的機會。經驗跟他說，如果你這樣做的話，會在某某地方出錯，因此他就直接避開了或是不去嘗試了，因此團隊的學習與創新也都受限了。找個不知變通的技術老士官長來帶領團隊就可以破壞團隊的敏捷性了。一般過於疼愛孩子的家長也在此列，因為總是擔心孩子受到失敗的打擊而禁止他做這個或是做那個，結果是過度的保護造成孩子不敢於嘗試的個性。

《 待續… 》

 

→ 完整的內容將在 GOPS 2019全球运维大会 . 北京站發表。

.

參考:

美國情報機構所設計出創新的方法來擊敗對手，在1944年中情局(CIA)的前身戰略服務辦公室(OSS)創建，由 William J. Donovan 威廉. 唐納文將軍所創的《簡單破壞實戰手冊》.

.

 

廣告

決策者的工具: Cynefin Framework

.

Dave Snowden 喜歡的平板式 Cynefin Framework圖示，皺褶處指的是山谷或山脊

.

Cynefin Framework 庫尼文

解題難，尤其是起步時更難。遇問題時，通常我們會先進行觀察(Observe)，然後回頭看看自己所處的環境(定位，Orient)估算一下自己在當下能夠解題嗎?也可能會反覆的觀察一下然後在判斷一下，直到弄清楚是怎麼回事之後，在做好決定(Decide)然後開始行動。這種行為模式，稱之為OODA循環的決策模式(*1)。這個方法最早應用於美國空軍戰鬥機飛行員的訓練，作為交戰程序的一部份。感覺上既簡單、符合人性又有效率，但這個方法在遇到難題時，好像就幫助不大了。Dave Snowden 提供了更進一步的決策模式，Cynefin Framework庫尼文(發音[ku.nev.in])是威爾斯語「棲息地」的意思。

 

它只是一個架構不是解題的方法，當你遇問題時可以用這個架構來判斷問題的類型然後參考架構所推薦的解題方式，然後在決定如何去處理它。Cynefin Framework尤其適合在現在多變的環境下，尤其是管理者遇到找不到正確答案的問題的時候。你需要有相當的創意與創新的做法來解題，敏捷開發裡 Scrum 的指導原則便是在這個時候發揮功效的，因為你無法用簡單的因果關係來看出問題的全貌，只有透過探索的方式，運用迭代每次產出小增量，經由結果的回饋來進行解題，就稱為浮現式的解題方式。

 

Cynefin Framework為 Dave Snowden在 1999年所創，指的是我們環境與經驗中的許多因素，會以我們無法理解的方式影響我們，因此決策者可以用描述問題, 環境與系統, 對照到這個架構所落入的象限中, 便適合使用什麼樣的解決方案，一個提供決策者客觀解題的架構。採用此庫尼文架構，可以協助高階主管了解自己所處的情況，避免因個人偏好某種管理風格而容易犯錯。

 

解法是這樣的；當我們面對一個問題時，首先要決定的是它是屬於有序還是無序的系統類型，有序的；指的是我們可以將因果聯繫起來; 也就是如果我們採取了某一種行動，我們知道它便會產生什麼影響。而無序的系統；指的是我們無法確定這麼做了，會得到什麼樣的回應的因果關係。

.

問題依它的狀態可分成有序跟無序二類

.

有序的類型能分成簡單(Simple)的系統及繁雜(Complicated)的系統二種。在有序系統中，特徵是；系統受到高度約束，行為具有高度的可預測性，因果關係可以從經驗中明顯看出，也可以通過分析來確定。簡單的系統；原因很明顯可見，適合稱之為不言而喻。如果原因不是那麼明顯但仍可以通過分析來確定，我們就說這是一個複雜的系統，俗稱為專家意見，也就是需要透過專業的分析過程來追溯出原因。

.

無序的類型又能分成複雜及 Chaotic

.

無序的類型又能分成複雜Complex及 混沌Chaotic，以及一種沒有能確定的失序系統，把它們放在正中間，稱之為“無序”。複雜的系統；它的因果關係是事前不可預知的、是不穩定的，一般情況下，這類問題往往沒有標準答案。問題無法單純通過拆解分析的方式來解決。混沌性的系統；問題的因果關係不可得知，完全無法瞭解問題是怎麼發生的，也就是原因不明，或者是原因太過多變，那麼就屬於混亂的系統，系統緣無故出現突發性的問題便屬於這一類。

 

依據這五種系統類型的定義，決策者使用時可以依照問題的類型，採取相對有效的解題步驟。Dave Snowden建議；當遇到簡單型問題時；可以採用察覺、分類的方來因應它。遇到繁雜型問題時；可以透過專家進行感知、分析來因應它。當遇到複雜型的問題時；則必須透過連續試探後再得到相當的因果關係後再進行感知來因應它。至於屬於混沌型的問題，則因為無法一下子就解決，因此首先要做好停損，然後迅速採取行動，嘗試將所處的領域再轉變為其他類型的問題領域，然後才再來解題。整理成表格如下:

參考自“A Leader’s Framework for Decision Making, ”HBR , November 2007

.

網路上已經有太多 Cynefine Framework 的圖形了，但還沒有專門的書來談它，能找到的只有一本小冊子(The-Cynefin-Mini-book-online By Greg Brougham)，為了上課方便，容我在增加一個。

.

右下角；簡單問題的象限: 由於問題顯而易見，因此在觀察(sense)之後透過分類或階層化的方式便能做到最佳的實踐，是一種適合制定SOP的解題類型。此時可以採用Waterfall 的方式來解題。 【步驟: 觀察→分類→因應】

右上角；繁雜問題的象限: 由於問題稍見複雜性，因此可能需要透過專家來進行分析尋求較好的解答。此時適合採用看板方法或 Scrum等敏捷的方法來解題。【步驟: 觀察→分析→因應】

左上角；複雜問題的象限: 由於問題的現象變來變去，感覺上像是動態的在改變，在這種情況下，很難採用因果關係單靠還原現象做分析來推論解題，此時運用反覆的探索、觀察的方式來嘗試找到一種浮現方式的解答，機會較大。適合運用Scrum的敏捷方法，採用小增量、迭代的模式去趨近問題的核心以求取在持續嘗試錯誤之下所衍生出來的解答。一般專案大都屬於這個範疇內，所以運用影響地圖來確認真正的問題及採用用戶故事地圖來掌握需求，這樣的工具都有利於浮現出可行的解答。【步驟: 試探→觀察→因應】

左下角；混沌問題的象限: 由於問題的因果關係不可知，完全無法瞭解問題發生的原因，或者問題的原因太過多變，那麼就屬於混亂型。這個時候，首要任務是及時停損。迅速採取行動，嘗試將所處領域轉變為其他領域。也就是試著從混亂轉變為複雜問題。【步驟: 行動→觀察→因應】

一般IT部門在遇到無緣無故發生的嚴重Bug時，經常就處於這種狀況下，此時需要果斷的處置行動，先求停損然後在設法轉成複雜問題的象限來處理。此時可以參考原著(The Origins of Cynefin)的這張圖示:

.

在象限中轉換

.

專案進行的過程，總是由複雜透過抽絲撥繭到逐漸明朗化成為繁雜的一堆事物，再經由持續實作演進到大家都能看清楚的有序狀態，在專案完成前來到簡單的領域，並在最終獲得成功。上圖中問題求解的循環實際上是一直在轉換中演進的，無所謂靜態的停滯的，也就是說事情擺著會逐漸變得更糟的，而敏捷正是以一種務實的精神運用小增量、迭代化去求解的過程。

.

結語

人的習慣是先觀察再定位然後下決定。但要觀察什麼？要定位到什麼呢？觀察什麼、定位什麼，它會有大不同的。在多變且越來越複雜的世界裡，往往沒有一種放諸四海皆準的方法，越來越多標準作業程序被打破、需要修正，明顯的我們應該視問題的狀態再來採取相對應的解題方式，而 Cynefine framework 正是一個可以參考的架構。網路上有太多衍生出來的解法，看上去也都很有價值，敏捷只是一種做事的態度，時時存乎於心才是上策。

.

註 1. OODA循環的決策

OODA循環（英語：OODA loop），也被稱為柏伊德循環（Boyd cycle），由美國空軍上校約翰.柏伊德提出的決策方法。這個方法是一個循環，由觀察（Observe），定位（Orient），決定（Decide），與行動（Act）組成，反覆進行。

主管的引導方式 – 目標式引導

薩提爾女士的冰山理論模式

 

敏捷教練們經常要求主管要後退一步，目的是讓團隊能自己做決策，形成自我組織的團隊，但對於主管而言，這是一種消極的做法，不適合主動性強的人士。積極的做法應該是去改變管理方式，也就是運用引導的方式來協助下屬達成目標。

 

目標式引導 (Facilitate)

管理者的引導方式是不同於一般引導者的，一般引導強調必須有著中立的立場，例如: Scrum Master或引導師進行引導時。這是因為管理者需要去評核他們的表現，也就是打考績，所以很難扮演絕對中立的角色，你必須時時進行評估與判斷，才可能適時的授權給他們，而且你還必須與他們共同負起成敗的責任，團隊會更在意的是過程，但管理者的引導應該更注重在目標而非過程。因此適當的目標導向是管理者的引導與引導師最大不同點。說穿了就是運用目標來做溝通，用目標來做計劃，運用引導的技能來達成目標。

 

著名的維琴尼亞．薩提爾女士(Virginia Satir，1916-1988)所提出的冰山理論，正是一種以目標為導向的引導方式。它把重點放在運用冰山理論揭開部屬的行為障礙及思維盲點上，也就是讓他們看見現狀的事實，然後再進行轉化及改變。程序是：

 

1. 確認目標

要先確認談話的目標，如果情境不合宜，就得調整目標，才能使整個交談能夠聚焦在單一的重點上。當目標過多時，便很難達到預期的效果了。

 

2. 辨識並排除冰山盲點的干擾，開創新的可能

辨識及排除冰山盲點的方法可以簡單歸納為下列三點：

1. 詢問他為什麼這樣做，是什麼觀點造成你決定這樣做的，讓他講出來自己的觀點，你可以觀察到他的情緒、觀點、期待及渴望。也就是冰山下的盲點。
2. 引導他探討、分析固守的行為、情緒、觀點、期待及渴望模式對於其外在表現的利弊得失，讓他能客觀的認知自己的盲點在哪裡。
3. 引導他去探討不同的可能性，找出可以改變行為的重要因素，進而創造出新的可能並發揮出要達成目標所需要的潛能。

一旦能夠自覺地看到自己的盲點，也看到其他的可能性，就有機會突破既有框架，發揮出潛力。

 

3. 落實改變行動

教練式領導的目標是藉此促使部屬改變行為模式，而不僅止於內在心理因素的改變。

.

結語: 引導就是問對問題

領導者應該多提問，尤其是那些能夠幫助個人、團隊、組織以及我們自身成長的問題。你會發現越是卓越的領導者則越是能夠提出精彩的問題。提問已經成為領導者必備的技能了。舉一個架構的例子來看，敏捷開發的團隊裡遇到最大挑戰便是架構的設計，因為你不能一口氣就把整個架構都設計完畢，必須隨著功能的推進以鷹架(Scaffolding)的方式逐步地堆疊出你的架構，我們稱這種設計方式為衍生式設計(emergent design)或是浮現式設計。但架構設計要如何能像築鷹架一樣，鷹架築到三樓蓋二樓、築到四樓蓋三樓，以一種漸增的方式來構築呢?

 

其實這種理念是違背架構設計的，架構設計就是要先去設想到全貌會長成什麼樣子，才能接著拿它去做依據的來進行設計，記得自己在剛踏入敏捷領域的時候就已經做了多年的架構設計了，那個時候每當我必須作架構設計時，我總是改不掉老習慣，先用自己的假設把架構圖畫完，然後就把架構圖收到抽屜裏去，就以提問的方式，選擇與團隊一起討論出一個初步的架構圖來，然後始終用團隊共同討論出來的架構來做設計，一直到有一天工程師因為換位置的關係從我的抽屜裡找到這張架構圖，然後笑說什麼時候我重畫了大家討論的架構圖也不分享出來。其實這是一開始就做好的架構思維，我只是把它轉變成一系列的問題，再透過團隊一起討論一起取得共識，而我的作法是在討論的過程裡選擇一直去問對問題，運用問題來引導團隊去進行架構的設計，我必須承認這不是一種標準的衍生式設計的方式，但效果好極了。透過大家圍繞問題的討論，所獲得的結果讓大家都清楚了這個設計，而且也更願意主動去實現它。多年來我還是一直這樣做，而沒有想說，這正是一種引導式的設計。

主管對執行內容與團隊成員的態度無法是中立的，大多數情況他憑藉著個人的知識和經驗，對內容進行評價、判斷，並很難無視於團隊成員的錯誤，因此，態度是最困難的(請參考主管要如何面對團隊)。

.

註: 薩提爾模式

維琴尼亞．薩提爾女士(Virginia Satir，1916-1988)所提出，薩提爾模式是以人性關懷的角度(人本信念)，來探索行為背後的緣由，並從其中找到轉化的方法(冰山理論)，以協助當事人重新學習及成長。又因為薩提爾模式強調學習成長，所以也被稱為是成長導向的模式。

參考:  引導式對話，讓員工自己發現問題背後的原因！

主管要如何面對團隊？

.

循環式學習螺旋(註)

.

「主管處裡事務的態度決定了公司的文化」、「文化不是一天可以形成的」…

.

建構學習型組織 -第五項修練

如何形成敏捷的企業文化呢?首先要在認知上同意《第五項修練》彼得聖吉所謂的持續學習是企業最重要的技能。如果我們接受讓團隊持續學習是企業存活的前提，則所有的行為就應當以促進團隊的學習效能為主，然後在這個前提下主管就容易決定如何與團隊相處了，我們可以參照「循環式學習螺旋」來調整與團隊相處的關係。通常主管們以達成上級所交代的任務為前提，這一點沒有問題，但敏捷是這樣看的，敏捷會後退一步(系統思維)，讓團隊持續學習，經過學習來克服他們昨天所作不到的事(運用小的迭代來進行檢核、調整，至於範圍的大小就看你可以承受的短期失敗而定了 )，也就是讓團隊自己做，用學習來增強能力克服任務上的困難以達成任務，正如同賈伯斯所言: 「我們不該去追求成功，要去追求卓越則成功將隨之而來」

.

我們不是為了健康而去運動，而是為了興趣而持續去運動，健康則是附帶而來的。

-系統思維

.

主管要如何面對團隊?

如上圖中循環式學習螺旋的描述，主管依靠自己的基本信念及經驗預設團隊將會有的反應，並依此決定了行動方案，而團隊則會依據對主管行動的解讀而形成他們的行動，主管在經由團隊的行為表現進一步驗證了自己最初的假設而採取了接下來的行動，這是一種循環。為了跳離傳統的命令與控制型的管理，主管必須重新思考自己的角色。主管不可以在試圖知道所有的事情和做出所有的決定，他的重點需要轉移到定義團隊方向和營造一個環境使其他人也有機會學習和做出決定。這一點像極了家長在對待即將成年的孩子一般，你必須停止去替他們下決策也就是後退一步，他們必須學會為己的決策負責，否則就會像長不大的孩子一樣，不會主動為自己的行為負責，始終無法獨立。這一點常常是家長們放不開所致，一如主管凡事都事必躬親一般，也就不容易建立與團隊之間的信任度了。

 

相反的，主管的信任度和行為表現可以引領團隊職級的學習。此時如果主管嘉獎獨立、有擔當的員工，則團隊自然會產生相對應的行動。信任便成了團隊的回報，它也能減少主管的擔憂。這是促成團隊凡事朝向正面思維的重要一步，上圖的循環說明了主管的態度將引導團隊的行為模式，而建立信任在適當授權給團隊，讓團隊為自己的工作負責則是建立自組織團隊的基礎。相反的，如果團隊有推諉、逃避責任的現象，則表明了主管與團隊之間的信任度是不足的，要讓團隊敏捷起來則應該從建立互信著手。

 

結語

主管不能歧視任何人，你的態度將被團隊成員放大來解讀，而成為團隊一種無形的規範。檢視的方法是去傾聽團隊對事情的看法，若是偏向負面則你的循環式學習螺旋就會偏向負面(產生負面的學習過程)，一種常聽見的說詞是”我不喜歡但還是得這麼做，因為這是我們主管所樂意見到的”。主管應該視團隊行為是一種回饋，並依此來調整自己對團隊或個別成員之間的態度，有時放入太多的關注反而沒能讓團隊學到該有的經驗，應盡可能引導團隊朝正面思維方式是建立互信的基礎。有一個很好的做法是從「表現的公正」開始。

.

.

註: 參考自《敏捷文化》循環式學習螺旋， by Pollyanna Pixton 等。

誰說敏捷化一定會成功的?

.

敏捷化路徑 1. Trust-Ownership model 或許翻譯成"信任-所有權模式"會更洽當

.

以終為始

我做過許多企業的敏捷化顧問，有做1個月的也有待上2、3年的，誰說敏捷化一定會成功的! 但要怎麼來判斷敏捷化的成敗呢?最糟糕的是: 有些大企業的文化就是要追問每一個方案的成果，即便它是既抽象又無形的哪種, 或是需要過一段時間後才看得到影響效果的方案，上級也會要求要硬擠出報告來，當然最好是有數據，或是搞個問卷也成，就是要具體化產出，真是勞民傷財!

身為專業的敏捷教練，我是怎麼看成敗的呢?! 這裡說給你聽:

》你的效率變好了嗎?

敏捷不是一種實施完就結束了的活動，是必須一直持續下去的。但敏捷也不是商業行為，企業的本業才是。所以敏捷是用來輔助你的本業的，目的就是幫你效率化的面對市場上多變的需求。因此實行敏捷化一段時間後，試問你的效率變好了嗎?這才是重點。

我經常看不到自己顧問過的團隊後來怎麼樣了，他們是如何在我離開之後，持續的把敏捷(的心態)運用在工作上頭的。是否能在面對重大又困難的專案來臨時能善用敏捷的原則，維持住敏捷的步調呢? 這一點非常重要，因為你要相信它，敏捷才能幫你分憂解危，你才可能用得好敏捷。不要一遇到金額大得嚇人、時程又趕的不得了的專案就慌了手腳，這是我離開顧問團隊時最擔心的一件事。(但通常都沒來得及交代，就必須離開團隊了，繼續迎接新團隊，這就是做顧問的生活，看不到結果也只能窮擔心了)

上面那張「信任與責任模型圖」可以回答我們的疑惑。縱軸是主管對團隊或個人的信任程度，越往上表示信任度越高，也就是授權與賦能做得越好。橫軸是代表團隊或個人對於專案成敗的責任感與承諾的程度，越往右表示團隊越能自主，組織效能越高(左下角是最低效，右上角是最高效)。這張圖重要的不得了，它驗證了主管與團隊之間的信任與責任狀態，也是團隊在透過敏捷化之後效能成果的展現。

 

圖上1.的路徑是在說明通常在敏捷教練離開團隊後的影響 (敏捷顧問離開所產生的影響純屬巧合，但幾次經驗下來結果都是一樣，但不能就這樣斷定它是必然的結果)。團隊從傳統的由主管或技術leader下命令做工作分配的控制模式下，當上升到需要高度信任的情境時，敏捷教練在的時候，會時時提醒，請主管後退一步，請技術 leader後退一步，目的就在讓團隊培養出自己組織起來面對問題的責任感。但一旦在沒有敏捷教練在一旁提醒主管時。當遇到緊急的事故，主管通常是身先士卒的跳出來處理，這時候就可能出現麻煩了，若是主管只是扮演整合釐清問題的角色，則一切OK。若是主管為了求快速解題，依靠自己豐富的經驗直接下指導棋，採用命令的方式來處理時，就完蛋了。敏捷教練辛苦建立的自組織團隊就可能被一下子打回到原形。這時候我們稱之為敏捷化停在藍色「失敗」的區間裡。也就是大家常常掛在嘴邊的，所謂「主管的敏捷性左右了敏捷化的成敗。」

.

※ 遇嚴重問題，先求暫解再做長期解。二階段的解題流程無可厚非，但要把長期解撰寫成需求加上權重在放入需求的Listing 裡，以避免永遠使用暫時解。

.

敏捷是怎麼失敗的 – 團隊失去自組織。

『就是主管下指導棋，來你做這個，你呢? 做這個，這樣就可以搞定了。相信我就沒錯了。』

請注意，信任 Trust 是沒哪麼容易建立的。需要人與人之間經過長時間的互動之後，逐漸建立起來的。在企業裡主管要產生1對1的互動比較難，必須靠誠信來逐漸樹立起互信的橋樑。所以上面那張圖又稱為誠信-責任模式。

 

敏捷是怎麼失敗的 – 沒有依據 Scrum Guide的規範。

『我們組織的特性就是這樣，很難維持小團隊』、『我們習慣的工作量就是這樣，很難做迭代式開發』、『我們的團隊在遠端，很難做站立會議』 …這就是所謂的 Scrum Butt!

 

企業以一種依循傳統超越敏捷指導原則的做事方法，進行敏捷化的行為。結果自然會遲遲看不到敏捷的成效。如果你經常這麼懷疑的話，回過頭來，檢討一下是不是犯了 Scrum Butt的現象。

 

敏捷是怎麼失敗的 – 事事根據SOP就對了。

Silo穀倉效應就是發生在這裡，敏捷是要時時應付不可預期的改變的，最怕一種稱為『服從型的破壞者』。他事事依循公司規範，不屬於自己責任範圍的工作就不會主動去幫助別人，即便這些事情就發生在眼前。這種人士，看起來循規蹈矩，不會做出傷害到公司的事情，但其實他正在破壞組織的協作效能。

還有一種叫『經驗型的破壞者』，他依靠過去的經驗行事，也不是不敏捷，但就是太依靠經驗，少了一些嚐試錯誤的勇氣。也會讓團隊行事不敏捷，經常跟團隊說相信我，這樣做就對了。少了實驗性的成長要素，讓敏捷化始終在日常的行事中冒不出來。做主管的特別要注意這種人才，他能做事不是不能，但他是在無意中限制了團隊自組織的效應，若他已經是位高權重的主管了，那就更難處了，最好的做法是派遣他去專人專職打天下的工作了。

.

敏捷化路徑 2. 主管對團隊信心不足，經常 overwrite 團隊的決策

.

衝突不可怕，可怕的是衝突後的沉默。

.

衝突象限

團隊已經承諾要把專案做好，但是主管卻沒有信心。這種現象；通常在Bug層出不窮的團隊裡或是過度事必躬親的主管身上，主管會對團隊宣稱能夠把事情做好沒有信心怕他們失敗，就容易出現一種主管常常不贊成團隊的部分決策，私下overwrite某些決議事項的衝突現象，試問；當你發現孩子們的決定可能會犯錯遭致失敗的時候，你會選擇靜靜旁觀讓孩子們嘗試錯誤呢？還是毅然的出手介入，讓他們避開失敗呢？主管的作爲也可以同理心判斷，許多父母是太照顧孩子了，換來的是缺少獨立性，團隊的自主性亦然。此時團隊的信心會發生動搖，也會逐漸的選擇沉默，默認主管去做決定就好了，產生一種貌合神離的上下游關係。

尤其是在傳統階層複雜的組織裡，高階主管做了決策推行新政策，當沒有充分跟下屬溝通時，就容易讓下屬曲解了上面的意思，便盲目行事，造成團隊效能不彰的現象。歸根究柢通常是透明度不足的現象，造成團隊裡越優秀越有主見的人士失去對組織的信任，而選擇離開一途，這是組織的損失，也是執行敏捷化最害怕出現的現象。

.

看大家討論的怎麼熱烈，身爲技術主管，我建議採用這個作法… 這一下子就把所有權全部收回來了。

主管一定要避免作建議.

.

信任與責任的威力

所謂「三個臭皮匠，勝過一個諸葛亮」，在敏捷解決眾多難題裡佔著很大的份量，我們(主管與敏捷教練們)經常一再開會就為了找出一個看起來公平又公正，能讓人心服口服的解決方法的時候，團隊卻能選擇自主的透過加一點班把工作做掉的方式，輕輕鬆鬆的消除掉這個難題，這是我看到最多的現象，信任讓我們願意付出，願意承擔下這個責任(自組織就是這麼棒!)。說穿了是團隊選擇了退一步的行為，但實質上卻是責任感發揮了莫大的助力，協助管理者做到不容易處裡的事。這意味著創新與潛能持續在醞釀中，這正是團隊在累積正能量的現象。

.

由低效能走向高效能之途

.

自組織團隊是最高效能的團隊

如果你去查看(google 一下)如何樣養成一個高效能的團隊，一定會發現一個會自主管理的團隊是最高效的，換句話說就是「自組織團隊」的效能最高。也就是右上角象限的一個有活力與創新的團隊。上圖中的3A及3B路線都是到達高效能團隊路線，你或許會問我為何不是直接由左下角上升到右上角呢?這樣不是最快嗎? 這是一種在沒有歷史包袱需要克服時的途徑，它通常屬於「新創團隊」。這也就是各大企業都會選擇讓新創團隊獨立於企業外部的原因。但很不幸的，大部分我所顧問的團隊都是擁有深遠歷史的企業，長時期的組織文化根深蒂固的在層層的組織中，此時如果選擇採用穩紮穩打的形式做敏捷化變革的單位，就容易走上 3B這條路徑。對自己太有信心的單位，往往會選擇較激進的手法做改革，則容易走上 3A的路線，明顯的無論是經過失敗區間或是衝突區間這段時間都不能待太久，待久了可能就會轉型失敗，而再沒有幹勁邁向活力與創新的區間了。

 

如何讓團隊自組織呢?

二種協助自組織團隊的方法，一個是 CDE法 (CDE是Container容器 – Differences差異- Exchange交換，源自Glenda Eoyang的博士論文《Facilitating Organizational Change: Lessons from Complexity Science》)這是目前最被scrum master 們廣為採用的方法，也就是依據CDE的模型來進行引導的動作(「引導」Facilitate；它的字面意義: 「讓事情變得容易」)。

另一個是Philip Anderson 的企業衍化七槓桿(在這裡《The Biology of business》，這是JOHN HENRY CLIPPINGER III與幾位作者共同出版的書，Philip Anderson負責第六章 Seven Levers for Guiding the Evolving Enterprise. 1999。書裡所說明的第一個槓桿:慎選外部環境( Select the external environment) 指的正是主管要善用此外部環境，藉著讓團隊在達成任務的過程中能夠順利成長並達成所賦予的任務，指導原則是參考鷹架學習理論。意思是指主管要製造一個便利於團隊自主學習的環境，並在工作中適時的給予協助克服種種困難，讓他們能夠順利完成任務。也就是所謂的不是只有授權後便認由他們去做不用在關心了，而是在必要的時機點扮演教練的角色，並藉由調整或協助克服困難以達到賦能的情境。(請參考赋能：打造应对不确定性的敏捷团队)

.

敏捷化；不外乎是推行敏捷的流程跟改變人心。

.

結語

敏捷執行的好壞怎麼評估呢? 我們在意的是效率變好了嗎?這一點好像只要把數位看板打開來，計算一下專案的「前置時間」與「實際開發時間」，相除起來就可以度量到效能的數值了(依據利特爾法則)，但我實在不建議這麼做。原因是每個專案都有它不同之處，很難只用一、二個標準去衡量他，這樣做太不公平了(巨觀來看，如果數量夠大，當實施的是 DevOps 時度量就不能疏忽了，當你評估的次數是百到千次以上的等級時，則得到的或然率評估就變得有参考價值了)。

我會選擇去看較抽象的團隊之間的信任度與責任感，而這二個項目正是企業文化在敏捷性這塊的表現。老實說；你不可能指望團隊裡的每個人彼此之間都充滿信任感，但是你卻能創建一種文化，讓大家在一個氛圍下有利於建立和增強彼此之間的信任度。

那信任度怎麼評估呢? 通常簡單觀察一下有沒有下面的現象，就能感覺出來了:

• 團隊遇任務受打斷時，是樂觀正面的接受，還是恐懼憤怒?
• 遇有插隊工作進來時，有沒有人自願出來認領。
• 團隊成員老是會自我保護，擔心被人誤解。
• 態度消極，老是一大堆理由。
• 對決策採取消極的抵抗和表現沒有誠意。
• 團隊一起罵主管，而不是就事論事。
• 沒有耐心，遇事急著下結論。
• 八卦滿天飛，只有抱怨缺少正面的觀點。

我經常有機會跟曾經帶過的團隊聚餐(有時是主管、有時是團隊成員)，言行之間便能輕易的問出團隊的現狀，這一點；經常讓人感概世事的多變(這篇文章就是這麼來的)。但也經常能欣慰團隊能持續的成長，可以拿來作炫耀。

.

主管透過透明、檢核與調適三部曲來擺脫成為敏捷化失敗的主要原因.

.

敏捷最不需要的是衡量

透明、檢核與調適溝成了敏捷化的三大支柱，從一開始實施敏捷化起，我們就應該努力的讓工作透明化，讓事實被看見，讓假設自動被澄清，把原本被隱藏的事情逐漸挖掘出來，讓大家都看見了，看見之後並且造成有相同的感覺，也就是達成「共識」，這個時期看板方法可能是最好的開始。隨後我們得依照看見的事實來進行檢核，這個時候能讓團隊自行擬定一些做事的規範，適時的學習自我檢視用來驗證工作的成果，這時候或許看起來會顯得幼稚或粗淺，有時候這群人還會犯上一些顯而易見的錯誤，但這不是問題，因為團隊沒有一起做過一些傻事，又怎能產生彼此之間的信任感呢。接踵而來的是透過回饋之後的調整。這時候我們會設法來放大回饋的效果。不能夠僅僅依賴檢核與回顧二個固定的會議來取得回饋，最好是事情發生的當下，在問題解決之後就立即進行回顧，讓經驗不斷的累積下來成為團隊的有價資產。而這三件事是一直持續在發生的(也是敏捷化的基本)工作，如果身為主管的人沒有意識到成長，或沒有讓其他主管感覺到團隊在成長，這才是做主管的人該檢討的事，也就是沒能讓團隊的成長透明出去，讓組織或企業看見這個事實，所以展現團隊敏捷化的成果是主管的責任。所以敏捷不需衡量，讓成效透明化是主管的基本責任。他能間接成就組織的敏捷化。

 

.

要怎麼測出人跟人之間的信任度呢？（有主管slack來問問題）

哈哈！這個問題容易，思考一下自己和某人溝通處理某件事情作決定的次數和採取行動的次數。試想要花多長時間和自己不信任的人完成一項任務？當你越是要花功夫為這次溝通作準備，那你們之間的信任度就越低。想想和充分信任的人溝通就知道了，打聲招呼就搞定了。

.

註.参考自《敏捷文化》The Agile Culture.

※ 要怎麼改善現有文化呢？

應該時時選擇去正視問題：

1. 消除下屬病態的恐懼 – 你們在擔心什麼？
2. 以團隊為主的業績考核，聚焦眼前的任務。
3. 要求短迭代，體驗協作。求取好的協作。
4. 期待成功但允許試錯。

.

※ 領導者該怎麼來培養團隊的信任呢？
1. 凡事出以公心。
2. 行事增加透明度。讓大家都知道你決定的依據。
3. 表現出值得信賴。
4. 為他們爭取福利，保護疆界。
5. 保持專業心態，樂於接受回饋。

.

敏捷成功了嗎?

.

如何讓業務敏捷起來 – 影響地圖

.

圖一、進行銷售時的影響地圖思維(業務的影響地圖草圖)

.

• 詢問客戶要的是什麼? (弄清楚客戶約我來的目標。)
• 然後設身處地的以客戶的立場思考我們公司的產品能幫上什麼忙?
• 接著展開公司產品為客戶所設計的功能。
• 最後，提供解題的具體方案，並解釋給客戶了解。

.

所有的主管都必須懂業務。

.

業務人員需要敏捷嗎?

範例一、櫃台有留言，某中大型企業要求與我們的業務取得聯繫。我是一位半資深的業務人員，談不上資深是因為部門裡還有好幾位前輩在。而我被指派負責前去拜訪客戶，下班前趕緊把公司的廣告型錄帶上，預做好迎接新客戶的準備。回家的路上那種躊躇不安的心還是持續的干擾著思維，雖然我已經不是菜鳥了，但每當要去call 新的客戶，在還沒與客戶碰面之前，還是會有心靈不安的感覺。我覺得需要一種策略規劃的工具來協助自己幫客戶解決問題。尤其是這種未知的課題，誰知道這個客戶又會冒出什麼難題來，而我能回答的好嗎?

》類似的情境，會在你初次與客戶見面之前，一再的重複著。

 .

範例二、在排定需求優先順序的會議中(註1)，產品部門受到開發部門強烈的質疑，為什麼要先做A而不是B呢? 一番爭執之後，雙方似乎都沒法說服對方，『歸根究底來說；客戶到底會先要什麼? 』:負責仲裁的大PO說話了，客觀一點的作法是先找提出需求的業務來說明一下，讓我們能夠針對需求的原委有進一步的了解，也好做判斷些。此時大家把目光轉向了與會的業務主管，原本只是代表業務部門來看看下一季會有那些功能可以拿來面對客戶的，此時反倒成了大家要做抉擇時的關鍵了。業務主管先清了清嗓子:『老實說，這幾個需求已經擺在清單上很久了，客戶可能都不記得了，應該是問不到了』。

.

客戶提出要求的當下，是釐清需求的最佳時機。

.

》類似的場景在做需求排序的會議裡一再的重現，而成熟的分析師都知道，要想釐清需求得在客戶提出的當下，就立即進行釐清、紀錄才是，事後再要來追問原委，恐怕都會有所爭議了，也就是說需求要做釐清、確認，一定要在客戶還沒忘記以前讓他簽字才會有效率，這是大家都知道的「需求訪談」時的不變真諦。所以在客戶向業務提出需求的第一當下，便是一個釐清需求的好時機。但問題來了，要有怎麼樣的背景的業務人員才做得來呢?

 

著名的《實例化需求》的作者GOJKO ADZIC 2012發明了一種策略規劃的工具叫「影響地圖」Impact Mapping以提供給業務使用，他的目的是希望在推行企業敏捷化的當下能把業務部門、產品部門及開發部門串接起來，真正的實踐 DevOps所謂的端到端的價值交付。

.

以一種協助客戶解決問題為前提的策略規劃

.

※豐富化你的影響地圖，下圖跟上一張圖最大的不同點是，加入不同的角色，由不同的視角，產生不同的影響及做法。

.

多種角色 – 不同影響  – 不同的做法

• 弄清楚可以達成客戶真正目標的各種解題方法。
• 以不同角色的立場對目標進行分析。
• 以不同的角色(視角)分析出不同的行為影響。
• 針對不同的行為提供實質的做法。

.

影響地圖視覺化了不同角色在不同解題方案之下的各種可能影響的狀態。我們得到了實施各種解決方案在路徑上的里程碑，以及它們的替代方案及據此所需要的度量與評估，以便於進行決策的參考。

.

行銷最大的武器是對公司產品功能的深入了解。

.

》影響地圖可以協助客戶將需求視覺化。

影響地圖；由誰來製作它就會長成那個樣子。

.

製作影響地圖

首先要問的是，誰應該負責製作它? 作者GOJKO說道:「想要發揮影響地圖的最大功效，就要與高級技術和業務人員一起工作。」應該要由一群專長不同的人的一起協作，但老實說；由誰製作它就會長成那個樣子。業務人員與客戶可能是初版影響地圖的製作者(如圖一，影響地圖草圖)，而接手的市場人員是持續維護或修改的主要人員，至於開發人員則適當地提供了在各個里程碑的度量數據與可行的解提方案。

 

市場部門應該是影響地圖的最佳Owner

【準備】

1. 發現真實目標 (由業務人員手裡獲取業務影響地圖草圖)
2. 定義需要的度量(由技術人員提供適當的協助)
3. 計畫第一個里程碑。

.

一個完整的影響地圖製作步驟

.

【製作】

1. 畫出地圖框架: 問出目標是什麼? 列出相關的角色? 依據角色推論出可採取行動。
2. 找出首要路徑、找出可行的替代選項。
3. 確定出關鍵優先順序

 

※ 採用反覆運算交付的團隊應當一次只處理一個目標。因此分成多個目標個別來完成，會比分成多個階層分段完成要合適。

• 視覺化並不代表大家就都有共識了，要透過個別闡述與排序之後才能達成共識。
• 不要想當然地認為所有列出的東西都是要實際交付的，你應該把列出的交付內容當成可選項(Option)。

.

範例說明: 財務交易處理

.

來自《影響地圖》書上的範例及說明

.

這個地圖說明的是交易處理系統的某個里程碑，關鍵目標是降低10%的交易處理成本。

【影響路徑1. 在德國的結算團隊的路徑】

一個選擇是減少處理交易需要的手工工作，選擇針對德國的結算團隊的角色做處理，假設他們能更快地處理重要的例外交易，就能降低下游團隊的工作量，從而極大降低交易成本，方法是；引進全自動處理流程，這將直接降低結算和所有下游團隊的工作。

 

【影響路徑2. 交易員的路徑】

另一個選擇是設法減少處理交易例外的數量並減少非標準的交易量，方法是；設法引入更多交易類型，即透過部門級的報告來加強控制。

 

【影響路徑3. IT運維的路徑】

其中的一個關鍵假設是，降低IT運營成本可以實現這個目標，對應的方法是簡化系統架構和淘汰需要較高支援成本的老系統，也就是選擇做系統優化，然而，優化系統需要很大的工作量，因為要到核心架構所以相對的風險也會高些。

.

像公路地圖呈現了市鎮以及連接它們的道路一樣，影響地圖展示了我們要構建的東西，以及它們與人們使用方案解決的問題之間的連接。公路地圖的首要任務並不是提供關於市鎮的詳細資訊，而是清晰展示它們之間的連接；它的次要任務是幫助我們發現替代線路。討論影響地圖上的節點，以及如何連接它們的不同假設，可以讓不同領域的人高效參與進來，發現有效的解決方案。

.

》誤導! 下面是一般對影響地圖的定義，實質上它是打破DevOps與業務部門邊界的有效利器。

一般的定義: 對產品開發和運營組織，影響地圖是一個簡單卻又十分高效的範圍管理、戰略規劃和協作方法。

實質意義: 它提供組織不同部門人員，以相同的視角，去正視客戶的需求，它是打破開發部門Dev、運維部門Ops與業務部門SD之間邊界的利器。

.

• 反覆運算式的計畫通常缺少了完整的圖像

影響地圖剛好架起了兩者之間的橋樑(反覆式與全盤計畫式)：它既可以組織戰略規劃、思想以創建關注業務目標的整體圖景；同時也可以引導反覆運算交付過程中的持續學習，協助我們管理專案的各個里程碑。

.

結語

由推行敏捷化到進入DevOps持續交付/部署的領域，二者之間最大的差異在原本只是在意於開發階段的速度，進而變成去統計整個企業的生產效能(請參考《加速》一書)，將過去只專注於生產效能的局部優化，延伸到去度量組織整體的效能，這一點讓敏捷化也開始走入組織裡的各個部門中，大家不禁要問道:「敏捷可以給我什麼?」一時之間，敏捷可以給業務什麼?成了串起DevOps所強調的端到端的價值交付的第一個環節，其實；我們可以試著倒過來思考這個問題，也就是業務需要敏捷提供什麼呢?

 

GOJKO ADZIC 寫於2012的策略規劃工具則填補了這個缺口，它叫影響地圖Impact Mapping.它提供了業務部門、產品部門、開發部門及運維部門以各自不同的視角，來協同合作探索如何滿足客戶的需求及盡快交付價值給客戶。這是策略規劃的一大邁進，而不是如”用戶旅行地圖”一般只是提供了釐清需求的一種方法。因此；如何讓業務人員習得繪製影響地圖草圖的技能(圖一)，便成了組織跨部門實踐DevOps的一大挑戰了。

.

讓敏捷走入業務環境已經成了實踐DevOps的一大課題

.

註.

》需求排序的會議一般簡稱為ONEPB(One Product Backlog)會議。是當組織內區分成多個開發團隊時，為了開發上能夠協同合作集中開發的戰力，而刻意的把所有的需求排進一個共同的列表裡，陳列在越上面的需求便越快會被做到，為排序所衍生出來的需求排序會議。

》 影響地圖的最佳Owner 是市場部門，而草圖的繪製則很可能是由業務人員所繪製。

》「影響地圖範例遊」

.

.

.

.

.

.

.

.

.

》如何繪製影響地圖的四個重要提問

影響地圖的繪製是由一群人從提出問題、討論答案所組合出來的視覺化紀錄。繪製時要問的四個問題如下:

• 目標是什麼Why?

也就是詢問為什麼要做這件事。由確立目標做為出發點。

它回答了最重要的議題：我們為什麼做這些？也就是我們試圖達成什麼樣的目標。GOJKO把它稱為「地圖的中央部位」，業務人員應該是第一位提出這個問題的人選，時機就發生在客戶陳述了它的問題之後，這是要避免業務人員直接就接受客戶的需求，而沒有進一步釐清需求。

 

• 誰能產生需要的效果Who？

影響地圖的第一層回答了以下問題：誰能產生需要的效果？誰會阻礙它？誰是我們產品的消費者或使用者？誰會被它影響？也就是那些人是會影響結果的角色。

為了能夠高品質地又快速的交付價值，我們首先要理解的是：這些人是誰，他們想從我們的產品或專案中得到什麼。這是DevOps中最重要的端到端的思維，也就是我們在做產品前應該先弄清楚使用者的期待和他真正的用法。繪出這些角色，探討不同的角色他們真正的需求，自然能弄清楚產品真正的用戶，也可以協助我們思考程式應該做到什麼樣的程度，也縮減了那些沒有必要的範圍。

 

• 這些角色的行為是怎樣改變的How？

影響地圖的第二層從業務目標的角度設置角色，它回答如下問題：角色的行為是怎樣改變的？他們怎樣説明我們如何達成目標？他們如何幫助或妨礙我們取得成功？而這正是我們試圖創造的影響。

 這正是我們試圖創造的影響。交付成功的關鍵在於理解客戶想要做什麼，而不是他們對於產品和服務的想法。這説明了交付組織調查不同的技術選擇，探索不同的解決方案，從而達成更好的結果。這些選項在這裡被繪製出來了，視覺化讓我們清楚自己有哪些替代方案(alternative)存在，一旦目標有所改變，替代方案或許就成了主要影響路徑了。

 需要強調的是，有些影響是有競爭性的，有些是相互衝突的，有些則只是補充而已。我們並不需要實現全部影響，我們要經常去比較和設定交付內容的優先順序，經常修正避免開始時做了錯誤的假設。

 

• 我們可以做什麼來解決它What？

一旦回答了前三個問題，我們就可以開始討論範圍了。影響地圖的第三層，回答了以下問題：作為一個組織或交付團隊，我們可以做什麼來支援影響的實現？包含：交付內容、軟體功能和組織的活動。也就是解決方案。

 這是影響地圖中最不重要的一個層級，不要在一開始時就試圖把它做完整，你應該在反覆運算交付過程中不斷完善它。

 

主管不能不懂的 – 鷹架理論

鷹架學習理論長期運用在學前教育上

在一個組織裡，學習的情境無所不在，新人向資深人員求教，工程師向技術主管請教，升遷或離職時的交接工作，我們不能忽視了這個時候的學習效果，他對團隊的效能起著巨大的影響。

.

好的工作交接

回想自己剛踏入職場時，很快就面臨到要把工作交接給新人的情形。這是我第一次做交接的工作，哪裡搞得清楚，完全不知道該怎麼講最有效，就列了一張清單，按部就班的將資料遞交出去然後把工作內容說一遍，就認為完成了。至於新人到底學會了沒有，就交給他自己去處理好了，反正有問題時隨時可以來問哦。你說這是好的工作交接嗎?

 

鷹架學習理論

還記得小學數學老師怎麼教課的嗎? 首先；先講一個小故事，在引起大家的注意(興趣) 後，接著從一個最簡單的問題開始演練起，讓大家試著自行解解看，這個時候全班可能有超過一半的同學都能夠答對，然後便開始加深問題的程度，當全班只有寥寥可數的幾位同學能解得出問題時，老師便會回過頭來再做更詳細的說明。課後的作業也設定了要答對幾題才算及格，錯幾題就要打幾下的標準(設定目標)。

 

這種先引起興趣再由淺入深的進行教學的方式，便是一種鷹架學習理論的實踐方式，之所以稱為「鷹架」，取的便是事前預估樓層要蓋多高，而鷹架總要蓋得比建築物高些，而蓋好後又要逐漸的一層一層拆除，最後我們只看得見建築物了，教育正是這種型式，達成後便不見教師的成果，而主管也是如此。這是由Wood、Bruner 以及Ross 於1976年所提出的理論，它是奠基於維高斯基的最接近發展區(Zone of Proximal Development簡稱ZPD)的概念。這個區間是指如果我們讓初學者去獨立完成，跟讓有經驗的同儕去協助他一同來完成，這二種方式之間會有一個區間的落差，就謂之為ZPD。之所以稱為鷹架理論(Scaffolding)是這種教學方式，類似架鷹架一般，在初學者逐漸能養成獨立解決問題的能力時，隨後將鷹架逐漸拆下來，以達成較好的效果為目標。

 

打開DevOps 的后門

其實不論在開發團隊Dev或是維運團隊Ops裡，這件交接學習的動作它一直持續在發生中，而我們做得好壞就展現在團隊的效能上，因此我稱它為DevOps 的后門，指的正是管理者的角色，衍生到主管的管理上頭，這便是所謂的授權後賦能的動作，也就是說；當主管讓下屬獨立去完成工作時(也就是在充分授權後)，是否能做到鷹架理論所謂的先引發興趣隨後在由淺入深逐漸拿掉鷹架的方式，並保證下屬能夠達到一定水準的交付動作，也就是「賦能」的地步。這是主管在進行敏捷化時，在後退一步後所必須做到的事，具體作法可參考鷹架理論。

.

忙碌的開發單位，都已經忙得不可開交了，那有時間注重這個呢！但是沒有學習就沒有成長，這就像學生作作業一般，作再多作業的練習也沒有真正了解題目來的有用。

.

實踐鷹架學習理論的方法

.

團隊自組織後的效能依據

團隊自組織後的效能受限於團隊工作的環境，而主管正是設定這個工作環境的關鍵人物，因此如何讓團隊處於好的工作環境之下(環境 Environment 指的不只是硬體的工作環境，還包含學習資源與組織措施…等)，據 Philip Anderson 所著的《引領企業持續進化的七大槓桿》裡所說明的第一個槓桿:慎選外部環境( Select the external environment) 所指的正是主管要善用此鷹架，藉著讓團隊在達成任務的過程中能夠順利成長並達成所賦予的任務，指導原則正是參考上圖中所述的鷹架學習理論。意思是指主管要製造一個便利於團隊自主學習的環境，並在工作中適時的給予協助克服種種困難，讓他們能夠順利完成任務。也就是所謂的不是只有授與權後便認由他們去做不用在關心了，而是在必要的時機點扮演教練的角色，並藉由調整或協助克服困難以達到賦能的情境。

.

打開DevOps 的后門 – 如何成為一位傑出的領導者。

-參考自在DevOpsDays 的演講

.

這個區間應該是逐步敏捷式迭代的存在的(參考)

.

結語

若把鷹架的概念類推到教學，可推論得教師的教學應該就是所謂的鷹架，學生則是在鷹架的支援之下才能順利完工的建築物。衍生到職場上主管或資深工程師交付任務給初級的工程師，便是主管提供鷹架的支援之下讓工作可以被順利完成，而初級的工程師也能夠因此獲得良好的經驗提升。

我們若再把它推廣到團隊的自組織上頭，則其實團隊成員之間一直在做相互協作的工作，那便是一種相互的學習，主管如何設計工作環境上的鷹架，將決定團隊效能可以到達的區間，若是放任它們自己去做，則可能只達到成員實際能達到的區間，若是能提供職級的協助則可能提升到潛在發展水準的區間，這也正是我們帶領敏捷團隊時所希望獲致的自組織團隊能展現高效的地步。

有趣的是；當我們把「鷹架」和「建築物」間的關係類推到「教學安排」 和「學生成長」間的關係時，隱藏著一個如下常被忽略但卻又相當重要的問題：在搭鷹架時，會先考量建築物下個階段預計完成的高度再行架設，因此若一次就搭太高的話對施工不但沒有幫助，甚至還會有所妨礙。依此，教師在教學時，亦必先估計學生在不久的未來可能發展出來的能力，然後再提供適當的支持與引導(即鷹架)以推進學生此種能力的發展。依此說來，「自組織的團隊」也怕搭建太高的鷹架，若是給予超越他們能力太多的工作壓力，此時所產生的挫折可能會遭致對團隊提升效能的相反效果。

.

主管要如何做到搭建鷹架的能力呢? 一個最常見的工具便是「引導」Facilitate。

.

註

1. 鷹架理論 Scaffolding

鷹架理論一詞是由Wood、Bruner 以及Ross 於1976 年所提出的，它的基本概念是源自於蘇俄心理學家維高斯基(Vygotsky)的學習理論。

2. 利維·維高斯基（Лев емёнович Выготский, Lev Semenovich Vygotsky，1896年11月17日－1934年6月11日），為蘇聯心理學家。鷹架理論便是從他的理論(最近接近發展區)中在發展出一套更完善的發展理論體系。
3. 參考著作《鷹架兒童的學習─維高斯基與幼兒教育》作者為Berk & Winsler.

是由兩為美國學者所整理的維高斯基社會互動理論的重心，歷來的研究發現和方案應用，做了理論與實務的說明與驗證。

4. 引領企業持續進化的七大槓桿 (Seven Levers for Guiding the Evolving Enterprise)， By: Philip Anderson收錄於 《The Biology of Business》一書中第六章，作者為by John Henry Clippinger III .

.

 

敏捷開發的「回顧會議」是一種後置學習，也就是做完任務後的檢討學習，而鷹架學習理論則是一種前置學習，二者都不可或缺，通常要在進行回顧後再決定要拆除或繼續架設鷹架，就取決於對ZPD的運用。