從管理學看敏捷開發(fā)Scrum
Scrum
Scrum近幾年已經(jīng)成為最有影響的軟件開發(fā)過程，從Forrester 關于敏捷模式的調(diào)查報告我們可以看出一些倪端,而且微軟也推出了更Scrum的模板，相信.Net平臺下越來越多的團隊會采用這一過程。
圖1： Forrester 關于敏捷模式的調(diào)查報表
Scrum的在軟件日趨復雜的環(huán)境下,其成功不是偶然的,其指導思想符合我們現(xiàn)代管理學的一般規(guī)律。
管理學
經(jīng)過近百年的管理理論的演進，管理一般被認為是一個協(xié)調(diào)工作活動的過程，以便能夠有效率和有效果地同別人一起或通過別人實現(xiàn)組織的目標，其協(xié)調(diào)工作活動一般分為計劃,組織，人員，領導，控制五個方面,這五個方面并沒有嚴格的時間斷點,而是一個相對獨立的問題域,周而復始的貫穿整個管理過程。
計劃：計劃涉及使命、目標選擇、決策完成使命的行動方案。
計劃是管理的首要職能。它是在預見未來的基礎上對組織活動的目標和實現(xiàn)目標的途徑作出籌劃和安排，以保證組織活動有條不紊地進行,計劃內(nèi)容包括“5W1H”.制定計劃首先要確定目標,在制定目標時候要參照SMART法則.
組織：維護群體的工作方式，旨在建立一個合適的角色體系，創(chuàng)造一個促進員工完成任務的環(huán)境。
組織意指一個正式的、刻意設計的角色或職位結構以滿足組織目標實現(xiàn)，明確所需要的活動并加以分類，對那些為實現(xiàn)目標所需要的活動進行分組，每個小組安排有監(jiān)督職權的管理人員來領導，為組織結構中的橫向協(xié)調(diào)和縱向協(xié)調(diào)制定有關的規(guī)定。 在組織設計的時候要注意統(tǒng)一指揮原則 ，控制幅度原則，權責對等原則，柔性經(jīng)濟原則，同時注意強調(diào)組織有效性和組織文化。
人員：組織角色的填充,涉及人員的配置和保持人員的穩(wěn)定。
人力資源管理工作直接影響整個企業(yè)的經(jīng)營狀況，現(xiàn)代管理學人為人力資源部門為企業(yè)利潤中心，在人力資源管理方面，企業(yè)總的目標是盡可能擁有高素質(zhì)的員工，以使企業(yè)得以保持競爭優(yōu)勢；而人力資源管理部門則主要側(cè)重與這一總目標有關的更為具體的目標即生產(chǎn)力以及質(zhì)量和服務，通常人力資源的變革涉及企業(yè)在文化、領導方式和人力資源政策與實踐慣例等方面作出相應的改變。
領導：對團隊人員施加影響，促進其對組織和群體目標做工作。
領導是影響人們心甘情愿和滿懷熱情地為實現(xiàn)群體的目標而努力的藝術或過程。越是了解那些激勵下屬的因素以及如何使這些因素發(fā)揮作用，并體現(xiàn)于管理的實際行為之中，那么領導就越有效,在領導過程中可以從分發(fā)揮采用委員會和小組的優(yōu)點。
控制：確保事情的發(fā)展方向符合計劃，評定和糾正人員和組織的績效手段。
控制是對績效進行衡量和矯正，確保企業(yè)目標以及為實現(xiàn)目標所制定的計劃能夠順利完成,控制基本過程為確定標準，衡量績效,糾正偏差，在控制點上我們可以選擇實物標準、成本標準、資本標準、收益標準、計劃標準、無形標準、以系統(tǒng)目標為標準、以戰(zhàn)略計劃作為控制點。
解析Scrum
Scrum框架圖如下：
圖2： Scrum框圖
1.產(chǎn)品列表和迭代計劃
產(chǎn)品任務列表（Product Backlog Item/PBI） 是可以預知的所有仸務，包括功能性的和非功能性的仸務，PBI屬于計劃階段，指出了我們目標，PBI表述的時候建議的原則
Independent 獨立性，避免與其他Story的依賴性。
Negotiable 可談判性，Scrum中的story不是瀑布開始某事中的Contract, Stories不必太過詳細，開發(fā)人員可以給出適當?shù)慕ㄗh。
Valueable 有價值性， Story需要體現(xiàn)出對于用戶的價值。
Estimable 可估計性，Story應可以估計出Task的開發(fā)時間。
Sized Right 合理的尺寸， Stories應該盡量小，并且使得團隊盡量在1個sprint(2 weeks)中完成。
Testable 可測試性， User Story應該是可以測試的，***有界面可以測試和自動化測試。每個任務都應有Junit Test。
這個雖然加入了一些軟件技術性描述，但是總體上和我們說Smart原則上是一致的。
迭代計劃(Sprint Planning )，綜合考慮項目環(huán)境,在下一個迭代周期的目標,其中的Sprint Backlog來自PBI，這個就是我們所討論的計劃工作中對目標實現(xiàn)的途徑作出安排。
圖3：迭代計劃
當然這涉及到?jīng)Q策問題,比如迭代的周期？先實現(xiàn)那些PBI？比如迭代周期的選擇，這個就是個非程序化決策，需要我們自己的經(jīng)驗判斷，PBI的優(yōu)先性我們可以從PBI的字段描述中進行程序化決策。
1.Scrum中的角色與團隊
Scrum定義了許多角色，關于豬和雞的笑話很形象，對于豬的角色來說又分三種：產(chǎn)品負責人（Product Ower），Scrum主管（Scrum Master）,開發(fā)團隊（Scrum Team）
產(chǎn)品負責人代表了客戶的意愿。這保證了Scrum團隊在做從業(yè)務角度來說正確的事情。產(chǎn)品負責人編寫 用戶故事，排出優(yōu)先級，并放入產(chǎn)品訂單。
Scrum主管Scrum主管促進 Scrum過程，他的主要工作是去除那些影響團隊交付沖刺目標的障礙。Scrum主管并非團隊的領導（由于他們是自我組織的），而是負責屏蔽外界對開發(fā)團隊的干擾。
Scrum主管確保Scrum過程按照初衷使用。Scrum主管是規(guī)則的執(zhí)行者。開發(fā)團隊負責交付產(chǎn)品的團隊。由5至9名具有跨職能技能的人（設計者，開發(fā)者等）組成的小團隊完成實際的開發(fā)工作。
Scrum中這三種角色是精心設計的,符合我們管理理論組織的理論，一個產(chǎn)品只能有一個Product ower符合我們的統(tǒng)一指揮原則，Scrum Master的主要工作是去除那些影響團隊交付沖刺目標的障礙，也是為了項目實現(xiàn)創(chuàng)造環(huán)境等等。 在實施Scrum的時候，所做的***件事情就是打亂特定于組件的團隊，創(chuàng)建豎井式的團隊。它減少了諸如“我們沒法完成這個條目，因為我們在等server那幫家伙完成他們的工作“之類的情況發(fā)生
1.Scrum中的會議
敏捷的宣言中包括個體與交互勝過過程和工具,Scrum中對于會議分為：計劃會 （Sprint Planning Meeting）, 每日立會 (Daily Standup Meeting),評審會(Review Meeting)，回歸會(Retrospective Meeting）。
計劃會 Sprint Planning Meeting：在每個沖刺之初，由產(chǎn)品負責人講解需求，并由開發(fā)團隊進行估算的計劃會議。
每日立會 Daily Standup Meeting：團隊每天進行溝通的內(nèi)部短會，一般包括完成了什么？是否遇到了障礙？即將要做什么？因一般只有15分鐘且站立進行而得名。
評審會 Review Meeting：在沖刺結束前給產(chǎn)品負責人演示并接受評價的會議，在這個會議上產(chǎn)品負責人確定完成了哪些工作和剩余哪些工作。
回顧會 Retrospective Meeting：在沖刺結束后召開的關于自我持續(xù)改進的回憶。
這個和我們管理中控制息息相關,其中計劃會指明了控制的方向,每日立會作為前饋控制,評審會可以作為現(xiàn)場控制，回顧會可以作為后饋控制，為我們下一步計劃做參考,在會議中各個Sprint Backlog完成情況可以作為員工績效考核的一個因素。
1.燃盡圖
是一個公開展示的圖表，顯示當前沖刺中未完成的任務數(shù)目，或在沖刺訂單上未完成的訂單項的數(shù)目，通常燃盡圖可以在每日立會展示，作為我們控制的一個輔助手段。
圖3：燃盡圖
Scrum文化建設
讓團隊坐在一起，從分共享信息，這些都切合我們管理學領導中激勵的概念，滿足員工工作個人成就的需要。
原文鏈接：http://www.cnblogs.com/Roping/archive/2010/12/21/1912525.html
【編推薦】
