在中國應如何改良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, theSprint 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框架

原文轉自：http://www.kjueaiud.com