敏捷開發的6個實戰經驗

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

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

1. 快速迭代

相對那種半年一次的大版本發佈來講，小版本的需求、開發和測試更加簡單快速。一些公司，一年僅發佈僅2~3個版本，發佈流程緩慢，它們仍採用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。
由一年發佈2個版本轉到一個月發佈2個版本，這也不太可能。可是如今來看，快速迭代已經成爲事實標準，關鍵是要比目前的版本發佈速度更快一些。
快速迭代，能夠逼迫團隊不斷優化流程、提高工做效率，不要在無足輕重的事情上浪費時間。若是離deadline還有6個月，那麼整個工做節奏必然悠哉。若是每個月發佈一個版本，那麼較之前效率必然會更高。若是發佈週期過長，致使沒法儘快發現用戶需求，進而沒法及時改進產品。
2. 讓測試人員和開發者參與需求討論
需求討論以研討組的形式展開最有效率。研討組，須要包括測試人員和開發者，這樣能夠更加輕鬆定義可測試的需求，將需求分組並肯定優先級。
同時，該種方式也能夠充分利用團隊成員間的互補特性。如此肯定的需求每每比開需求討論大會的形式效率更高，你們更活躍，參與感更強。
肯定需求時，不要過分盯在細節上。需求報告過於詳細，就是一種不敏捷的習慣，還浪費你們的時間。固然，不能錯過好點子，但就是不要太細，由於項目真正實施起來時需求將會產生很大的變更。
3. 編寫可測試的需求文檔
開始就要用「用戶故事」（User Story）的方法來編寫需求文檔。這種方法，可讓咱們將注意力放在需求上，而不是解決方法和實施技術上。過早的說起技術實施方案，會下降對需求的注意力。
規劃業務需求，能夠採用「3W模板」，也就是：

誰（Who）

是什麼（What）

爲何（Why）

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

誰（Who）	是什麼（What）	爲何（Why）
用戶	但願藉助一個應用程序在不一樣服務器間傳輸文件	爲了存儲項目數據

爲了更加接近「用戶故事」，咱們能夠改寫爲：

誰（Who）	是什麼（What）	爲何（Why）
消費者/用戶	想將歸檔過程數字化	爲了加強溝通，提升分享效率

敏捷項目中編寫用戶故事有一個經常使用模板：做爲一名[用戶類型]，我想要[需求]，以便於[緣由]。應用到這個例子，就是：做爲一名用戶，我想要將歸檔程序數字化，以便於加強溝通、提升分享效率。
多數狀況下，需求內容須要更加充實和詳細，這一步要放到後面作，開始不要這樣。用戶故事的方法有時會因過於簡短、不斷重複而受到批評。這裏咱們必 須明白：需求文檔不是散文或詩歌，應該清晰、簡明地描述用戶需求；需求文檔的重點也在於此，不要管形式多變或內容是否重複這樣的問題。
4. 多溝通，儘可能減小文檔
任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子裏面混得越久，越會強調良好高效的溝通的重要性。
團隊要確保平常的交流，面對面溝通比郵件強得多。
敏捷開發鼓勵平常的協調會議和碰頭會，5~7人蔘與的會議儘可能控制在10分鐘內。碰頭時，要過一遍昨天完成了什麼，今天要作什麼，哪些問題仍待討 論。能夠用Burndown Chart（燃盡圖）來形象展現工做進度。每次迭代的時候也都要開一個計劃會議和評審會議，通常須要的時間可能會長些，好比半天。這些會議的目的就是對工 做查缺補漏。
評審會議很重要，傳統開發模式每每略過該環節，致使一些錯誤作法不斷重複，好的作法沒法推廣。
開會時，能夠將原先的分組打散，讓整個團隊都參與到項目的需求討論和測試中來，這樣能夠突出成員我的，讓你們更樂意參與。
5. 作好產品原型
建議使用草圖和模型來闡明用戶界面。並非全部人均可以理解一份複雜的文檔，但人人都會看圖。
一個常見的問題是軟件新的功能與用戶想要的不一致。爲了不這一問題，能夠模擬真實操做，改進模擬操做過程當中難以理解和不清楚的操做行爲。
6. 及早考慮測試
及早地考慮測試在敏捷開發中很重要。傳統的軟件開發，測試用例很晚纔開始寫，這致使過晚發現需求中存在的問題，使得改進成本太高。較早地開始編寫測試用例，當需求完成時，能夠接受的測試用例也基本一塊完成了。
敏捷開發中一個常見問題就是開發者沒有對已有的代碼庫進行充分的迴歸測試。迭代週期很短，從開始到交付就是4周的時間，這樣能夠對迭代的設計、實現和底層測試一塊進行迴歸測試。
一系列迭代以後，能夠只針對測試活動再補充一個迭代。這個迭代能夠將重點放在系統測試、與其餘系統的集成度、性能等方面。敏捷開發過程當中，可能會致使過少的測試文檔。若是迭代週期爲1個月左右，能夠沒必要對測試文檔過於要求，但要制定好測試策略。
最後 可能大多數公司或團隊尚未開始嘗試敏捷開發，不過能夠開始從點滴作起，好比開碰頭會、爲項目管理採用一個更加高效的管理工具等等。最後，但願上面的建議可以爲你們的軟件開發管理帶來幫助。