每次我們看敏捷開發Scrum都是從技術角度，今天我們嘗試從管理角度來看這個問題。

Scrum

Scrum近幾年已經成為最有影響的軟體開發過程，從Forrester 關於敏捷模式的調查報告我們可以看出一些倪端,而且微軟也推出了更Scrum的模板，相信.Net平臺下越來越多的團隊會採用這一過程。

圖1： Forrester 關於敏捷模式的調查報表

Scrum的在軟體日趨複雜的環境下,其成功不是偶然的,其指導思想符合我們現代管理學的一般規律。

管理學

經過近百年的管理理論的演進，管理一般被認為是一個協調工作活動的過程，以便能夠有效率和有效果地同別人一起或通過別人實現組織的目標，其協調工作活動一般分為計劃,組織，人員，領導，控制

計劃：計劃涉及使命、目標選擇、決策完成使命的行動方案。

計劃是管理的首要職能。它是在預見未來的基礎上對組織活動的目標和實現目標的途徑作出籌劃和安排，以保證組織活動有條不紊地進行,計劃內容包括“5W1H”.制定計劃首先要確定目標,在制定目標時候要參照SMART法則.

組織：維護群體的工作方式，旨在建立一個合適的角色體系，創造一個促進員工完成任務的環境。

組織意指一個正式的、刻意設計的角色或職位結構以滿足組織目標實現，明確所需要的活動並加以分類，對那些為實現目標所需要的活動進行分組，每個小組安排有監督職權的管理人員來領導，為組織結構中的橫向協調和縱向協調製定有關的規定。 在組織設計的時候要注意統一指揮原則 ，控制幅度原則，權責對等原則，柔性經濟原則，同時注意強調組織有效性和組織文化。

人員：組織角色的填充,涉及人員的配置和保持人員的穩定。

人力資源管理工作直接影響整個企業的經營狀況，現代管理學人為人力資源部門為企業利潤中心，在人力資源管理方面，企業總的目標是儘可能擁有高素質的員工，以使企業得以保持競爭優勢；而人力資源管理部門則主要側重與這一總目標有關的更為具體的目標即生產力以及質量和服務，通常人力資源的變革涉及企業在文化、領導方式和人力資源政策與實踐慣例等方面作出相應的改變。

領導：對團隊人員施加影響，促進其對組織和群體目標做工作。

領導是影響人們心甘情願和滿懷熱情地為實現群體的目標而努力的藝術或過程。越是瞭解那些激勵下屬的因素以及如何使這些因素髮揮作用，並體現於管理的實際行為之中，那麼領導就越有效,在領導過程中可以從分發揮採用委員會和小組的優點。

控制：確保事情的發展方向符合計劃，評定和糾正人員和組織的績效手段。

控制是對績效進行衡量和矯正，確保企業目標以及為實現目標所制定的計劃能夠順利完成,控制基本過程為確定標準，衡量績效,糾正偏差，在控制點上我們可以選擇實物標準、成本標準、資本標準、收益標準、計劃標準、無形標準、以系統目標為標準、以戰略計劃作為控制點。

解析Scrum

Scrum框架圖如下：

圖2： Scrum框圖

1.產品列表和迭代計劃

產品任務列表（Product Backlog Item/PBI） 是可以預知的所有仸務，包括功能性的和非功能性的仸務，PBI屬於計劃階段，指出了我們目標，PBI表述的時候建議的原則

Independent 獨立性，避免與其他Story的依賴性。

Negotiable 可談判性，Scrum中的story不是瀑布開始某事中的Contract, Stories不必太過詳細，開發人員可以給出適當的建議。

Valueable 有價值性， Story需要體現出對於使用者的價值。

Estimable 可估計性，Story應可以估計出Task的開發時間。

Sized Right 合理的尺寸， Stories應該儘量小，並且使得團隊儘量在1個sprint(2 weeks)中完成。

Testable 可測試性， User Story應該是可以測試的，最好有介面可以測試和自動化測試。每個任務都應有Junit Test。

這個雖然加入了一些軟體技術性描述，但是總體上和我們說Smart原則上是一致的。

迭代計劃(Sprint Planning )，綜合考慮專案環境,在下一個迭代週期的目標,其中的Sprint Backlog來自PBI，這個就是我們所討論的計劃工作中對目標實現的途徑作出安排。

圖3：迭代計劃

當然這涉及到決策問題,比如迭代的週期？先實現那些PBI？比如迭代週期的選擇，這個就是個非程式化決策，需要我們自己的經驗判斷，PBI的優先性我們可以從PBI的欄位描述中進行程式化決策。

2.Scrum中的角色與團隊

Scrum定義了許多角色，關於豬和雞的笑話很形象，對於豬的角色來說又分三種：產品負責人（Product Ower），Scrum主管（Scrum Master）,開發團隊（Scrum Team）

產品負責人代表了客戶的意願。這保證了Scrum團隊在做從業務角度來說正確的事情。產品負責人編寫 使用者故事，排出優先順序，並放入產品訂單。

Scrum主管Scrum主管促進 Scrum過程，他的主要工作是去除那些影響團隊交付衝刺目標的障礙。Scrum主管並非團隊的領導（由於他們是自我組織的），而是負責遮蔽外界對開發團隊的干擾。

Scrum主管確保Scrum過程按照初衷使用。Scrum主管是規則的執行者。開發團隊負責交付產品的團隊。由5至9名具有跨職能技能的人（設計者，開發者等）組成的小團隊完成實際的開發工作。

Scrum中這三種角色是精心設計的,符合我們管理理論組織的理論，一個產品只能有一個Product ower符合我們的統一指揮原則，Scrum Master的主要工作是去除那些影響團隊交付衝刺目標的障礙，也是為了專案實現創造環境等等。 在實施Scrum的時候，所做的第一件事情就是打亂特定於元件的團隊，建立豎井式的團隊。它減少了諸如“我們沒法完成這個條目，因為我們在等server那幫傢伙完成他們的工作“之類的情況發生.

3.Scrum中的會議

敏捷的宣言中包括個體與互動勝過過程和工具,Scrum中對於會議分為：計劃會 （Sprint Planning Meeting）, 每日立會 (Daily Standup Meeting),評審會(Review Meeting)，迴歸會(Retrospective Meeting）。

 計劃會 Sprint Planning Meeting：在每個衝刺之初，由產品負責人講解需求，並由開發團隊進行估算的計劃會議。

 每日立會 Daily Standup Meeting：團隊每天進行溝通的內部短會，一般包括完成了什麼？是否遇到了障礙？即將要做什麼？因一般只有15分鐘且站立進行而得名。

 評審會 Review Meeting：在衝刺結束前給產品負責人演示並接受評價的會議，在這個會議上產品負責人確定完成了哪些工作和剩餘哪些工作。

 回顧會 Retrospective Meeting：在衝刺結束後召開的關於自我持續改進的回憶。

這個和我們管理中控制息息相關,其中計劃會指明瞭控制的方向,每日立會作為前饋控制,評審會可以作為現場控制，回顧會可以作為後饋控制，為我們下一步計劃做參考,在會議中各個Sprint Backlog完成情況可以作為員工績效考核的一個因素。

4.燃盡圖

是一個公開展示的圖表，顯示當前衝刺中未完成的任務數目，或在衝刺訂單上未完成的訂單項的數目，通常燃盡圖可以在每日立會展示，作為我們控制的一個輔助手段。

圖3：燃盡圖

Scrum文化建設

讓團隊坐在一起，從分共享資訊，這些都切合我們管理學領導中激勵的概念，滿足員工工作個人成就的需要。

原文連結：http://www.cnblogs.com/Roping/archive/2010/12/21/1912525.html