敏捷軟件開發方法中的6個實戰經驗

　　摘要：Ulf Eriksson根據自己多年的敏捷開發經歷，總結了6個實施敏捷開發的技巧：快速迭代、讓測試人員和開發者參與需求討論、編寫可測試的需求文檔、多溝通&盡量減少文檔、做好產品原型、及早考慮測試等。

　　在大型企業中經常是各種軟件開發模式混用，一些采用敏捷開發，一些則是采用傳統的瀑布式或RUP(統一軟件開發過程)。敏捷開發，相對傳統軟件開發模式，它主要是針對快速變化的需求，不斷優化管理流程，最終推出優質軟件。

　　原文作者Ulf Eriksson，是一家在線問題跟蹤軟件公司的創始人之一，他是敏捷開發的忠實粉絲，已經進行了多年敏捷開發的實踐。下面內容主要是作者根據自己多年經歷進行的經驗總結。

　　1. 快速迭代

　　相對那種半年一次的大版本發布來說，小版本的需求、開發和測試更加簡單快速。一些公司，一年僅發布僅2~3個版本，發布流程緩慢，它們仍采用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。

　　由一年發布2個版本轉到一個月發布2個版本，這也不太可能。但是現在來看，快速迭代已經成為事實標準，關鍵是要比目前的版本發布速度更快一些。

　　快速迭代，可以逼迫團隊不斷優化流程、提升工作效率，不要在無足輕重的事情上浪費時間。如果離deadline還有6個月，那么整個工作節奏必然悠哉。如果每月發布一個版本，那么較以前效率必然會更高。如果發布周期過長，導致無法盡快發現用戶需求，進而無法及時改進產品。

　　2. 讓測試人員和開發者參與需求討論

　　需求討論以研討組的形式展開最有效率。研討組，需要包括測試人員和開發者，這樣可以更加輕松定義可測試的需求，將需求分組并確定優先級。

　　同時，該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強。

　　確定需求時，不要過度盯在細節上。需求報告過于詳細，就是一種不敏捷的習慣，還浪費大家的時間。當然，不能錯過好點子，但就是不要太細，因為項目真正實施起來時需求將會產生很大的變動。

　　3. 編寫可測試的需求文檔

　　開始就要用“用戶故事”(User Story)的方法來編寫需求文檔。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的注意力。

　　規劃業務需求，可以采用“3W模板”，也就是：

　　誰(Who)

　　是什么(What)

　　為什么(Why)

　　上面的3W實際上就是描述了相關利益者是誰，他們想要什么，他們為什么有這種需求。下面舉一例子進行說明：

　　為了更加接近“用戶故事”，我們可以改寫為：

　　敏捷項目中編寫用戶故事有一個常用模板：作為一名[用戶類型]，我想要[需求]，以便于[原因]。應用到這個例子，就是：作為一名用戶，我想要將歸檔程序數字化，以便于增強溝通、提高分享效率。

　　多數情況下，需求內容需要更加充實和詳細，這一步要放到后面做，開始不要這樣。用戶故事的方法有時會因過于簡短、不斷重復而受到批評。這里我們必須明白：需求文檔不是散文或詩歌，應該清晰、簡明地描述用戶需求;需求文檔的重點也在于此，不要管形式多變或內容是否重復這樣的問題。

　　4. 多溝通，盡量減少文檔

　　任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子里面混得越久，越會強調良好高效的溝通的重要性。

原文轉自：http://www.csdn.net/article/2013-12-09/2817746-6-practical-agile-techniques