【濟南中心】Android就業(yè)面試技巧系列-技術篇(敏捷開發(fā)二)敏捷開發(fā)的6個實戰(zhàn)經驗分享總結了6個實施敏捷開發(fā)的技巧：快速迭代、讓測試人員和開發(fā)者參與需求討論、編寫可測試的需求文檔、多溝通&盡量減少文檔、做好產品原型、及早考慮測試等。1.快速迭代

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

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

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

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

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

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

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

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

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

規(guī)劃業(yè)務需求，可以采用“3W模板”，也就是：·誰（Who）·是什么（What）·為什么（Why）上面的3W實際上就是描述了相關利益者是誰，他們想要什么，他們?yōu)槭裁从羞@種需求。下面舉一例子進行說明：為了更加接近“用戶故事”，我們可以改寫為：敏捷項目中編寫用戶故事有一個常用模板：作為一名[用戶類型]，我想要[需求]，以便于[原因]。應用到這個例子，就是：作為一名用戶，我想要將歸檔程序數(shù)字化，以便于增強溝通、提高分享效率。

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

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

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

團隊要確保日常的交流，面對面溝通比郵件強得多。

敏捷開發(fā)鼓勵日常的協(xié)調會議和碰頭會，5~7人參與的會議盡量控制在10分鐘內。碰頭時，要過一遍昨天完成了什么，今天要做什么，哪些問題仍待討論?？梢杂肂urndownChart（燃盡圖）來形象展示工作進度。每次迭代的時候也都要開一個計劃會議和評審會議，一般需要的時間可能會長些，比如半天。這些會議的目的就是對工作查缺補漏。

評審會議很重要，傳統(tǒng)開發(fā)模式往往略過該環(huán)節(jié)，導致一些錯誤做法不斷重復，好的做法無法推廣。

開會時，可以將原先的分組打散，讓整個團隊都參與到項目的需求討論和測試中來，這樣可以突出成員個人，讓大家更樂意參與。

5.做好產品原型

建議使用草圖和模型來闡明用戶界面。并不是所有人都可以理解一份復雜的文檔，但人人都會看圖。

一個常見的問題是軟件新的功能與用戶想要的不一致。為了避免這一問題，可以模擬真實操作，改進模擬操作過程中難以理解和不清楚的操作行為。

6.及早考慮測試

及早地考慮測試在敏捷開發(fā)中很重要。傳統(tǒng)的軟件開發(fā)，測試用例很晚才開始寫，這導致過晚發(fā)現(xiàn)需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了。

敏捷開發(fā)中一個常見問題就是開發(fā)者沒有對已有的代碼庫進行充分的回歸測試。迭代周期很短，從開始到交付就是4周的時間，這樣可以對迭代的設計、實現(xiàn)和底層測試一塊進行回歸測試。

一系列迭代之后，可以只針對測試活動再補充一