為什麼你的敏捷沒有起作用？

作為一名敏捷教練，我經常被問到的一個問題是：「我們實施了敏捷，但是為什麼它沒有起作用？」

問這個問題的人，是真正被困擾的人。

我遇到過許多團隊，在對團隊進行結構重組、職責重新劃分、流程重新定義的過程中經歷了許多的麻煩，但是令他們感到沮喪的是，經歷這些之後他們的生產力和士氣甚至都不如從前。

每個組織都有它自己獨特的功能障礙類型。

作為一名教練，我要讓自己深入團隊，密切觀察和理解他們是如何工作的。

但是，儘管每個團隊都有自己的獨特性，還是會經常出現相同的問題模式。

幾乎在每個案例里，團隊決定採用敏捷是因為他們遇到了現實生活中的問題，比如低的生產力和低的生產質量，他們希望敏捷能夠奇蹟般地讓他們起死回生。

他們沒有意識到的是，敏捷僅僅是管理軟體的一種系統方法。敏捷可以支撐一些遠大的目標，比如「通過滿足客戶不斷變化的需求使客戶滿意」。看到這些目標後，管理者通常都會很興奮，並且迫不及待地跳上敏捷這部列車。

敏捷的問題是在實施過程中它帶來了很多麻煩：

每日站立會議，

規劃會議，

和回顧會議。

咋看之下，一群人圍著一個白板徘徊的景象，可能會讓一些天真的管理者認為它起作用了；但是他們沒有意識到在缺乏重要的管理和技術支持的環境下，敏捷將無法生存，甚至更糟，團隊會背地裡開始討厭這種麻煩，希望事情能夠回歸到從前的模式。

管理問題

今年我一起工作過的一個團隊就陷入了上面描述的那種麻煩里。

它是一個大型團隊，被分成了7個scrum團隊。你可以想像每天早晨辦公室是多麼的嘈雜，幾乎同一時間召開的scrum會議，之後是scrum of scrum會議。

管理部門很高興；畢竟他們已經為聘請敏捷教練實施敏捷支付好了價錢。

事情開始轉變的很快。

我連續參加了團隊的scrum會議數周，並且特別注意到其中有一個團隊，他們已經被同一個技術問題持續阻塞了好幾天。

團隊不能繼續向前開展工作，所以他們開始著手其它的事情，但是這導致了大量未完成的代碼，不能測試和演示。

在敏捷里，scrum master理應為團隊掃除障礙。然而當被問到時，這個團隊的是scrum master也非常的沮喪。

他說，整個團隊里只有一小部分人理解相關的技術細節，但是他們又不在他的scrum團隊里。

他們被他的經理安排去開發實現另外一種功能了。

下面是軟體團隊遇到的一些典型問題:

問題一

每個敏捷倡導者都可以從積壓的工作中撿起任何任務，但是在現實中，只有幾個人理解一些晦澀的技術。很難激勵其他人學習並熟知這些技術，尤其是那些跟不上時代發展的人。

即使你成功激勵了他們，當面對大量積壓的工作的時候，也很難抗拒處理其它事務，使積壓起來的工作看上去很少的衝動。

問題二

敏捷scrum master理應移走團隊面前的大山，讓他們無阻礙地前行。

在現實中，scrum master經常缺乏這樣做的權利。

這種權利通常存在於管理者手中，正如大家所知，權利很容易上癮，並且很難放棄。

在實踐中，如果管理者有抵觸情緒，我也不會催促組織改變管理的角色。

如果某個管理者能夠勝任敏捷scrum master，可以安排管理者承擔scrum master的一些職責：

常常管理者在獲取資源和處理矛盾方面更有經驗，尤其是與其它同行者之間的矛盾。

但是這個團隊遇到了更大的麻煩。團隊經理另外開始開發實現一種單獨和私有的功能——但是沒有一個scurm團隊被分配去實現那方面的功能，因此我就不能建立它的進度表。經過進一步的探索，我發現RnD團隊和產品經理團隊之間互相不信任；產品經理團隊「命令」RnD團隊去開發一種功能，但是RnD團隊卻保留了部分資源，開發實現另外一種他們認為更突出的功能。

我與RnD管理團隊坐下聊了聊，在白板上畫了一張因果關係圖：

因果關係圖是一種很強大的工具。

儘管管理者一直在抱怨敏捷對他們團隊沒有起作用，但是因果關係圖清楚地顯示了更深層次的根本原因。

因果關係圖也有循環，這表明如果根本原因得不到解決，惡性循環將會繼續。

技術問題

雖然這支團隊擁有管理層的全力支持，但是仍然並不是所有的事情都運行的很順暢。

特別是，持續集成總是失敗。團隊在辦公室前面裝配了一台大屏幕用來顯示集成狀態，這樣當每個人進入或者離開的時候可以看到它。

這個屏幕平均每天有1-2小時時間是綠色的。當然，這在很大程度上推遲了團隊的進度。

有一個規則，除非屏幕是綠色的，否則不能簽入代碼，但是因為它經常失敗，所以有人偷偷潛入（sneaked in）代碼。

我們喜歡認為軟體開發跟傳統的製造業有很大的不同，因為軟體開發更「聰明」，而在傳統製造環境下工作的工人只需要不費心思地擰上螺母（想到了摩登時代的查理·卓別林）。

在現實中，軟體開發也有一個裝配線，所不同的是，這種軟體裝配線引入了大量用來提高軟體質量的迭代。

但是，就像工廠流水線一樣，如果某一步速度變慢，事情就會堆積起來，整個流水線速度就會減慢。

對於這個團隊，裝配線在功能級別看起來是這樣的:

這個裝配線有很多的反饋迴路。反饋迴路越短越好，因為校正錯誤的成本更低。

從「演示」到「需求」和「開發代碼&本地測試」步的反饋迴路太長；理想的反饋迴路應該從「開發代碼&本地測試」步開始。

然而，因為總會遺漏bug，所以我們依賴自動化和QA測試提供反饋。

但是，在這個團隊里，構建-部署-自動化測試過程存在嚴重的麻煩，並且有些人無視規則，隨意簽入代碼甚至堵塞裝配線，這一事實進一步加劇了過程的複雜性。

我向團隊明確了裝配線的概念，他們很快就想出了解決方案，理順了裝配線，比如加強代碼審查和強制執行無簽入規則。

然而，在自動化測試問題上，意見產生了分歧。

有些人認為目前的自動化測試是完全不可維護的：代碼的合約商早已毫無蹤影，並且修複測試代碼的bug時間要超過修復通過測試代碼發現的bug的時間。

其他人認為，即使自動化測試是壞的，但是有總比沒有好，並且重新編寫自動化測試代碼對QA來講成本太高。

我要求團隊進行快速計算，以確定自動化測試的優勢：

通過自動化測試發現bug/所有回歸bug

自動化測試發現bug/所有回歸bug

結果是有些自動化測試還是相當不錯的，尤其是一些單元和組件測試，但是UI端到端的自動化測試結果卻慘不忍睹。

結論很明確：沒有必要為如此少的利益花費如此多的工作量。

同時我還指出，開發和維護自動化測試不僅僅是QA的職責。

UI端到端的測試代碼完全依賴生產代碼。在面向服務體系結構中，服務擁有定義明確，常常是多方協商後的API，如果一個服務想要變更它的API，他將要（應該）通知與其相關的服務，這樣他們可以做出相應的變更。

UI測試代碼完全受生產代碼的支配：因此如果如此多的比如ID或者UI元素的名稱在生產代碼中發生變更，那麼UI測試就有可能會失敗。

為了實現自動化測試的健壯和靈活，自動化框架必須經過精心設計。

僱傭臨時合約商是無法保證這一點的，而讓QA工程師編寫又需要依賴QA的專業技能和類型，可能也不好。

對於這個團隊，很明顯大部分QA工程師都是功能性測試人員，並不具備架構一個框架所需要的高級的架構技能。

因此我們決定讓Dev tech負責人開發自動化框架，讓Dev和QA一起開發和維護UI自動化測試。

該協議還包括Dev不能隨意更改ID和UI元素名稱的規則。

你可能認為所有的這些都發生在一個輕鬆愉快的會議上；

事實上，讓這些成為現實得到了大量的管理支持，並且前後花費了近三個月才完成了自動化框架，實現了其快速、穩定、易於編寫測試代碼的功能——這就是我們解決現實生活中的問題的方法。

敏捷是一種管理軟體的系統方法

我們需要回到原點，找出敏捷的精髓。在2001年，17名軟體大師提出了敏捷宣言，但是敏捷宣言並沒有規定怎麼做：

個體和互動高於流程和工具

工作的軟體高於詳盡的文檔

客戶合作高於合同談判

響應變化高於遵循計劃

他們還提出了12條原則，其中的一些規定了做什麼（比如業務人員和開發人員面對面的交談傳遞信息）。

但是，大部分還是跟價值觀念有關。如果我們仔細分析這12條原則，我們可以看到它實際上構成了一座金字塔。

在最頂端的是「通過滿足客戶不斷變化的需求使客戶滿意。」

我們通過「經常地交付可工作的軟體」實現這一目標。

但是為了交付可工作的軟體，需要重要的技術和管理支持。確保變化的需求不會破壞系統和延緩開發進程是最重要的一個技術問題：如何設計一個靈活的系統和如何構建可以確保變化不會破壞系統的自動化測試。

為了在團隊里培養高級專業技能，團隊需要積極從錯誤中學習並進化自我。

向敏捷過渡並不是一場容易的旅程。

如果它不起作用，就仔細的看一看，想一想。它可能暴露了你團隊中的一些根本性問題。

你可以轉向白板，找出是什麼減緩了你團隊前進的腳步，使用精益工具比如因果關係圖和五個為什麼發現根本原因，解決它們，之後你將會收穫敏捷的全部好處。

作者：ChenPing，ChenPing

推薦閱讀：