在中國應如何改良Scrum架構

 
在中國應如何改良Scrum架構

 

@吳穹Adam (新浪微博)

 

在我的CSDN部落格（http://blog.csdn.net/adwu73）上面，我發表了一個“為什麼純粹的Scrum在中國很難落地”系列，其中通過解讀新版的Scrum Guide來分析如果在中國嚴格照搬Scrum會遇到哪些困難，有興趣的讀者可以去看看，而在本文中將在總結Scrum架構缺陷的基礎上，討論應如何改良Scrum架構，以保證實施成功。

 

首先，何為改良Scrum架構？Scrum Guide開宗明義，Scrum不是一個具體技術或流程，而是一個可以和其他流程和技術相結合來保證項目成功的架構。因此，將Scrum與其他技術相結合不是改良，而就是Scrum預設的用法，就想裝修好的房子裡面，再擺上傢具一樣。而所謂改良就是修改Scrum核心架構的內容，就想打掉一個屋子的一面牆一樣。Scrum架構的核心內容包括團隊的角色定義，時間箱，交付物和規則，下面我們就一一看看應如何改造。

 

在改造之前，同時也需要瞭解哪些架構是Scrum的本質，因為如果修改了這些本質內容，那麼就不是改良Scrum，而是推翻Scrum了，這就好像裝修不能打掉承重牆一樣。Scrum 的三個支柱是透明，審視和適應。透明強調團隊之間通過透明來加強新人，應對變化；審視和適應是指在過程中，通過不斷審視來不斷進行適應性改善 。好了，找到了承重牆，避開它們，然後就開始幹吧！

 

角色定義 – Manager/Lead

 

首先，我們來看一下角色定義，Scrum當中設定了三種角色：Product Owner，Scrum Master和Team。Team當中由參與交付的Developers, Testers等角色群組成，注意這裡是沒有給Manager和Lead留出位置，Scrum架構當中隱含了團隊應該是自管理的要求。這其實和歐美的實際情況有關，在那裡你能看到大把的白頭髮程式員，而在國內，則非常稀少。

 

而在中國，在我幫客戶實施敏捷的過程中，發現在許多組織中由於研發團隊都很年輕，並不敢真正實施自組織，而Manager或Lead又沒有了位置，於是紛紛偽裝成了Scrum Master，然後一切照舊，而真正該做Scrum Master的人反而沒有位置了。這造成了許多Scrum實施的失敗。其實，管理人是最難的一件事情，自組織只是一種可能的管理方式，而這種管理方式恰恰是在中國現在的軟體企業裡很難成功的管理方式。因此，我認為，應該改良Scrum架構剝離自組織管理方式，而去強調Manager as Coach.。

“Manager as Coach.”這一思想可以在敏捷的另一個流派-精益(Lean)當中找到而且是Lean的基礎，我覺得這種思維很可能更適合中國的現狀，因為大多數團隊中的成員都非常年輕缺乏經驗，因此，他們需要的很可能並不是自組織，而是真正能Coach他們的Manager或者Lead。即使現在Manager和Lead 還不稱職，那麼企業的重點也更可能應該是儘快提升這些Manager和Lead的Coach能力，轉變他們的思想，而並不是去推行自組織。

 

還有一點需要注意，這裡說的Manager/Lead，不是只哪些只管人不幹活的，Lean的思想建議，Manager/Lead必須是有動手能力的領域專家，這樣才能真正能做到Coach一線研發人員，否則就只能紙上談兵了。另外，最近在微博上的討論中，大家往往將信任和自組織畫上等號，其實，有Manger、Lead並不代表不信任，這種非黑即白的看法是錯誤的。

 

 

綜上所述，我建議，團隊在應用Scrum架構時，如果認為應該採用Manager as Coach這種管理方式，那麼就應該在Scrum架構的角色定義當中，明確加入Manager/Lead這個角色，也可以修改團隊（Team）的定義，將Manager/Lead也作為團隊的一部分。

活動 - Time Box

Scrum架構的另一個大問題是對架構的忽視，而在中國，現在最大的問題不是過度設計，而是設計不充分。而Scrum更助長了這種輕視設計的風氣。當然，強調架構設計並不一定意味要寫很厚的架構設計文檔，或者進行複雜的UML建模，如何進行架構設計，做到什麼程度，應有團隊自己決定。下面就看一下應該如何改進Scrum架構：

 

Scrum架構當中的活動有幾個：Release Planning Meeting, the Sprint, the Sprint Planning Meeting, the Sprint Review, the Sprint Retrospective, and the Daily Scrum.”

 

Release Planning meeting基本上是一個目標計劃會，與架構設計無關。而在每個Sprint的Planning Meeting上，會有兩個部分，第一部份澄清需求，第二部分進行設計，但時間太短，往往無法承載架構設計。

 

因此，嚴格的照搬Scrum架構，在一些大量應用現成架構的產品開發過程中，或在一個產品的維護階段，還可能成功。但是，對於大型複雜產品開發而言，不進行架構設計，結果基本上是災難性的。

 

綜上所述，建議團隊在實施Scrum的過程中，在Release Planning Meeting之後，增加一個Release Architecture Design Workshop來進行架構設計，時間長度和Release Planning Meeting一樣，當然，這個Workshop和Release Planning Meeting一樣，也是可選的。

 

交付物 - Artifacts

Scrum架構中的交付物有四個：Product Backlog, the Release Burndown, the Sprint Backlog,和 the Sprint Burndown. Product Baclog比較簡單，就是所有需要做的事情。這裡特意沒有明確Product Backlog Item是以什麼方式定義的，以便可以整合這方面不同的實踐（如使用者故事，用例，FDD等）。

 

而在Spring Backlog的內容方面則有些問題，不太一致，細節就不在這裡展開了，具體大家可以去看我的部落格。我贊同最後在Release Notes當中的提法，Scrum Backlog就是由本迭代希望完成的Product Backlog Item組成，這些Item可以進一步拆分成任務來追蹤。

 

改良總結

綜上所述，可以將改良之後的Scrum架構總結在一張圖裡面，如下：

 

 

實施Scrum應保的態度

看到這裡，我想讀者對Scrum架構應該有一個初步的瞭解。在正式實施Scrum架構之前，首先需要看透Scrum架構的商業本質，對它抱一個正確的態度。

 

Scrum架構其實可以被理解成是敏捷的商標，就象一個果農要賣蘋果，賣一個兩個那就賣了，但是如果要賣的多，那就需要有一個商標了。Scrum架構也是一樣，許多敏捷大師都有自己的敏捷理念，很難統一，於是，大家選定了這個形而上，空空的Scrum架構作為大家共同的商標，這樣哪個大師也不會反對。

 

所以，你去上一節Scrum Master的培訓，你得到了什麼，一個認證，對Scrum架構的基本瞭解和許多許多培訓師自己的敏捷實踐經驗。因此，能不能值回票價完全取決於培訓師的個人能力而已，而那張認證可以肯定一定不證明你就是一個合格的Scrum Master了。

 

因此，在實施Scrum時，不要抱著過高的期望，不要期冀銀彈，而要抱著務實、開放、輕鬆的態度，根據企業的實際情況定製或擴充Scrum架構

如何在中國成功實施改良Scrum架構

改良Scrum架構根據中國的實際情況已經強化了管理者的作用，強化了架構的作用，但是在中國實施改良Scrum架構還是會經常遇到一些阻礙，針對這些障礙，則必須克服才能取得成功：

1.         職能性組織、模組組織：由於實施CMMI的影響、團隊年輕、人員流動等各種原因，許多企業都慢慢轉向用職能性組織（如開發部，測試部，架構設計部，需求分析部，或者，如前端開發組，應用伺服器組等等），實施改良Scrum架構，可以暫不改變現有的職能性管理架構，但必須要求Scrum團隊的成員是跨職能、跨模組的，而且是在一起辦公的，這個要求不可妥協。

 

2.         客戶的參與信任關係的建立：在國內，有時客戶不太願意參與到Scrum過程中，參與了有時還不太適應他們手中排優先順序的權利，這個可以慢慢培養，但是，必須要求客戶和Team Dev一起辦公，共同參與Scrum過程，這樣才能逐步建立起互信的關係。這在軟體開發當中非常重要，因為，所有估算方式都只是一種拍腦袋的方式而已，只有讓和客戶建立起較強的互信關係，才能共同面對不斷變化的開發交付過程，而沒有比一起辦公更透明的方式了。

 

3.         變革之心與QA的正確作用：在國內，交付壓力都非常大，要求團隊既能交付又要不斷思考可以如何最佳化、變革是一個非常高的要求。我認為，這裡應該正確發揮QA人員的作用，QA需要放棄那種只是簡單比對流程要求，不符合就開NC（Non-Compliance）的粗暴做法，而真正做到參與到Scrum流程當中，冷靜旁觀，不斷挑戰現狀、發現問題、和團隊一起探索解決方案。因此，在我心目中，好的QA其實是Scrum Master的理想人選，有了變革的驅動者，每個迭代的迴歸會議才可能真正落到實處。

 

4.         增量交付價值：在國內，看到許多號稱做Scrum的團隊每個Sprint都在交付功能點，但是這些功能點並不能真正運行，這其實是偽Scrum，很可能還不如不迭代。因此，做好Scrum，就必須堅持不斷交付客戶可見的業務價值。也就是說，交付的代碼必須是可執行，可以給客戶示範的。對於複雜系統而言，這對劃分Backlog Item提出了很高的要求，但是，是可以解決的，本文就不在這裡展開了，未來再寫文章詳細解釋吧！

 

5.         測試的全程參與：以前看到另一種偽Scrum，號稱開發在前，測試之後一個Sprint。這種做法其實完全破壞了Scrum團隊，開發測試無法形成合力。因此，必須堅持A-TDD和驗收測試自動化，這又是一個很大的話題。

 

因此，大家可以看到，Scrum雖然簡單，但是這正做好Scrum需要在組織上，人力上，技術上有許多的儲備才行，所謂功夫棋外呀！最好，願大家掌握改良Scrum匡計的精髓，靈活應用，在實際工作取得好的效果！