採用敏捷開發進行專案開發已經有些天了，近幾天又看了一本關於Scrum的書。在此跟大家分享一下感受。

scrum本意是橄欖球運動中的爭球。在中國不興打橄欖球，在我的印象中，橄欖球運動是非常野蠻的，球員目的非常明確——破門得分。你可以抱著球跑，可以傳給隊友……各種方式都可以，就是要快速得分。敏捷開發就是需要這種精神。

敏捷開發不同於以往的瀑布模型開發。

瀑布模型中有嚴格的文件要求（需求、概要、詳細等）、對員工的工作量也有明確的定義與考量方法（程式碼量等等）。另外，瀑布模型對於開發者有著明確的分工：搞需求的專門搞需求，搞設計的搞設計，編碼的只管編碼，測試的只管測試。所以說，各部門之間的任務相對明確。但是溝通效率很低，由於文件的要求嚴格，各部門機制臃腫，彼此之間不能做到及時有效的溝通，不僅耗資巨大，而且延誤交付日期。另外，由於一般都是架構師整好設計，下面培訓一批寫程式碼的，所以開發者只能被動接受任務，每天干著暗無天日重複搬磚的日子，所以開發的效率也很低。

但是瀑布模型相比與敏捷開發，無疑就成了重量級，而敏捷開發則是輕量級。

瀑布模型風險較大，在實際中，並不是每個專案在前期都能夠做到需求明確，就像這樣：

而敏捷開發則非常適合需求變動的情況，敏捷開發的工作量是隨著需求的變化而不斷髮生變化的，所以整個過程中，浪費很少：

Scrum是最常用的敏捷開發（Agile）方法。下面我們來看一下Scrum大概的流程：

1、在一個Scrum專案中，產品負責人（Product Ower）建立待開發的產品條目（Product Backlog），並確定其優先順序。開發中需求的改變也要寫進去，對於調研、查閱資料、配置環境等也應考慮進去，因為這些也很佔用時間，敏捷開發中不提倡衝刺，不提倡加班，講究發揮團隊最大價值；

2、根據所列Product Backlog情況，確定產品一個迭代（Sprint）所要完成的東西，每一個Sprint大概是2-6周的時間；

3、Sprint開始前，需要開一個迭代計劃會議（Spint Planning Meeting）會議。會上，產品負責人（Product Owner）講解本次開發要開發的條目（Story），將確定的Story放入Sprint Backlog中來；

4、Sprint開發過程中，團隊每天都要開一個15以內的站立會議（Daily Stand-up Meeting），以便團隊之間瞭解彼此的開發進度。

會議由Scrum Master主持，Scrum所有成員輪流回答三個問題：（1）昨天我完成了什麼工作？（2）今天我打算做什麼？（3）我遇到了什麼障礙？會議的目的是團隊成員之間可以彼此相互熟悉工作內容，充分了解專案進度，相互幫助解決問題。

5、Sprint結束之後，需要開評審會（Review Meeting），Scrum團隊會在評審會議上把這個迭代的開發成功展示給大家；

6、之後還要開一個反思會（Restrospective Meeting），Scrum團隊會回顧過去這個Sprint，從中總結經驗教訓。

會議圍繞三個問題討論：上次迭代有哪些事情坐的好，希望繼續；哪些事情坐的不好，希望改進；有何改進計劃。會議目的旨在幫助團隊總結經驗教訓，分享經驗，使團隊持續成長。

上面就是Scrum的大概執行流程。

另外一些注意事項：

Scrum講究開發團隊坐在一起，有什麼問題即時相互詢問；

用拍撲克的方式角色每個story的開發時間；

測試要儘早加入到開發團隊中來，可以與開發人員進行結對開發，儘早的瞭解需求，大大減少測試人員的工作量；

開發人員工作量的評定要主要以團隊開發的質量為標準；

Scrum把軟體開發中各種角色形象的分為兩類：一類是“雞”，一類是“豬”。這裡源起於一個“肌肉火腿腸”的故事，不實際參與專案開的管理者稱為“雞”，全身心投入專案開發的團隊成員稱為“豬”；

剛開始實施起敏捷開發是比較困難的。很容易走教條主義的錯誤，機械的實施敏捷開發。注意，敏捷開發認為人與人之間有效的交流和協作是最重要的，透過一切流程和工具看本質，實際上就是使人能夠協作開發軟體。敏捷開發隨時擁抱變化、相應變化，而不是恪守計劃。總之，敏捷開發的本質：第一是一切活動以價值為導向；第二是以人為本。