在我的csdn部落格（上面，我發表了乙個「為什麼純粹的scrum在中國很難落地」系列，其中通過解讀新版的scrum guide來分析如果在中國嚴格照搬scrum會遇到哪些困難，有興趣的讀者可以去看看，而在本文中將在總結scrum框架缺陷的基礎上，討論應如何改良scrum框架，以保證實施成功。
首先，何為改良scrum框架？scrum guide開宗明義，scrum不是乙個具體技術或流程，而是乙個可以和其他流程和技術相結合來保證專案成功的框架。因此，將scrum與其他技術相結合不是改良，而就是scrum預設的用法，就想裝修好的房子裡面，再擺上家具一樣。而所謂改良就是修改scrum核心框架的內容，就想打掉乙個屋子的一面牆一樣。scrum框架的核心內容包括團隊的角色定義，時間箱，交付物和規則，下面我們就一一看看應如何改造。
在改造之前，同時也需要了解哪些框架是scrum的本質，因為如果修改了這些本質內容，那麼就不是改良scrum，而是推翻scrum了，這就好像裝修不能打掉承重牆一樣。scrum 的三個支柱是透明，審視和適應。透明強調團隊之間通過透明來加強新人，應對變化；審視和適應是指在過程中，通過不斷審視來不斷進行適應性改善 。好了，找到了承重牆，避開它們，然後就開始幹吧！
首先，我們來看一下角色定義，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也作為團隊的一部分。
scrum框架的另乙個大問題是對架構的忽視，而在中國，現在最大的問題不是過度設計，而是設計不充分。而scrum更助長了這種輕視設計的風氣。當然，強調架構設計並不一定意味要寫很厚的架構設計文件，或者進行複雜的uml建模，如何進行架構設計，做到什麼程度，應有團隊自己決定。下面就看一下應該如何改進scrum框架：
scrum框架當中的活動有幾個：release planning meeting, the sprint, thesprint planning meeting, thesprint review, thesprint retrospective, and thedaily scrum.」
release planning meeting基本上是乙個目標計畫會，與架構設計無關。而在每個sprint的planning meeting上，會有兩個部分，第一部份澄清需求，第二部分進行設計，但時間太短，往往無法承載架構設計。
因此，嚴格的照搬scrum框架，在一些大量應用現成框架的產品開發過程中，或在乙個產品的維護階段，還可能成功。但是，對於大型複雜產品開發而言，不進行架構設計，結果基本上是災難性的。
綜上所述，建議團隊在實施scrum的過程中，在release planning meeting之後，增加乙個release architecture design workshop來進行架構設計，時間長度和release planning meeting一樣，當然，這個workshop和release planning meeting一樣，也是可選的。
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 master的培訓，你得到了什麼，乙個證書，對scrum框架的基本了解和許多許多培訓師自己的敏捷實踐經驗。因此，能不能值回票價完全取決於培訓師的個人能力而已，而那張證書可以肯定一定不證明你就是乙個合格的scrum master了。
因此，在實施scrum時，不要抱著過高的期望，不要期冀銀彈，而要抱著務實、開放、輕鬆的態度，根據企業的實際情況定製或擴充套件scrum框架
改良scrum框架根據中國的實際情況已經強化了管理者的作用，強化了架構的作用，但是在中國實施改良scrum框架還是會經常遇到一些阻礙，針對這些障礙，則必須克服才能取得成功：
1.職能性組織、模組組織：由於實施cmmi的影響、團隊年輕、人員流動等各種原因，許多企業都慢慢轉向用職能性組織（如開發部，測試部，架構設計部，需求分析部，或者，如前端開發組，應用伺服器組等等），實施改良scrum框架，可以暫不改變現有的職能性管理架構，但必須要求scrum團隊的成員是跨職能、跨模組的，而且是在一起辦公的，這個要求不可妥協。
2.客戶的參與信任關係的建立：在國內，有時客戶不太願意參與到scrum過程中，參與了有時還不太適應他們手中排優先順序的權利，這個可以慢慢培養，但是，必須要求客戶和開發團隊一起辦公，共同參與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匡計的精髓，靈活應用，在實際工作取得好的效果！
在中國應如何改良Scrum框架
原文 在我的csdn部落格 上面，我發表了乙個 為什麼純粹的scrum在中國很難落地 系列，其中通過解讀新版的scrum guide來分析如果在中國嚴格照搬scrum會遇到哪些困難，有興趣的讀者可以去看看，而在本文中將在總結scrum框架缺陷的基礎上，討論應如何改良scrum框架，以保證實施成功。首...
在中國應如何改良Scrum框架
在我的csdn部落格 上面，我發表了乙個 為什麼純粹的scrum在中國很難落地 系列，其中通過解讀新版的scrum guide來分析如果在中國嚴格照搬scrum會遇到哪些困難，有興趣的讀者可以去看看，而在本文中將在總結scrum框架缺陷的基礎上，討論應如何改良scrum框架，以保證實施成功。首先，何...
在中國應如何改良 Scrum 框架
首先，何為改良 scrum 框架？scrum guide 開宗明義，scrum 不是乙個具體技術或流程，而是乙個可以和其他流程和技術相結合來保證專案成功的框架。因此，將 scrum 與其他技術相結合不是改良，而就是 scrum 預設的用法，就想裝修好的房子裡面，再擺上家具一樣。而所謂改良就是修改 s...