產品專案的九個敏捷開發經驗

　　敏捷開發越來越火熱，但在實際應用當中很多時候都是隻有敏捷的“形”，卻缺少敏捷的“神”，還只是在摸索中。

　　在《Scrum：兼顧計劃與靈活的敏捷開發》一文中，作者最後也提到過，借鑑一種新的模式的時候，最好能夠批判性的吸收其精華的部分，不能全部照搬，照搬了反而會出問題。

　　其實敏捷對產品經理的要求是很高的，需要安排至少兩個迭代的任務，兩個迭代的規劃。

　　對程式設計師的要求也很高，當所有的任務都拆散了之後，最終做出來的東西要形成一個產品，技術人員的整體意識要比較強，且一開始就得熟知產品的整個規劃，否則到最後就會出現所有任務都已完結，合併出來的最終產物卻是什麼都不是。

　　並且敏捷開發不僅僅是IT部門的事情，還需要各個業務部門對敏捷的理解和支援，形成合力，從而提升開發效率和業務滿意度。

　　執行一段時間的敏捷之後，發現最容易接受敏捷這種方式的是開發團隊，不管是瀑布式還是敏捷，只是做工作的形式不一樣了，進度更容易把握了，更能適應需求的變化了，實質其實並沒有變化。

　　對測試團隊來講，測試資源調配會更加的緊張，敏捷要求做完一條側一條，與原先的整體專案排期完全不一樣；對產品經理來說，敏捷能讓自身更好的掌握整個產品的進度。

　　但需求分析與產品設計階段的敏捷拆分還是較為頭疼的，究竟要不要寫文件了，是不是有什麼做什麼，還是說要規劃完整體設計之後才進行拆分？疑問很多，蒐集了部分資料，結合敏捷實踐的經驗，分享如下：

　　一、敏捷開發最少需要維護哪些文件？

　　軟體或者系統產品終歸是人來維護的，業務知識和技能的傳遞就成為產品可持續發展的一個重要因素，這就需要有知識性的沉澱，需要有文件的產出。

　　實際情況是大多數人都不喜歡編寫文件、也不太喜歡研讀文件，因此太多的文件只會消耗團隊有限的時間，並不能帶來多大的好處；敏捷開發照樣重視文件的作用，也重視文件的維護。

　　但文件宜少且精煉，一般情況下建議維護三份文件：

　　《產品需求規格說明書》

　　也即PRD：定義產品應該具有的功能、邊界描述等，它作為產品團隊之間共同的討論基礎，並在設計和開發過程中不斷的更新維護，並記錄所有的需求變更；

　　《系統設計說明書》

　　開發人員編寫的技術設計，包含資料庫E-R圖，架構設計等：說明產品如何實現，內部之間是什麼關係;

　　《測試用例和測試報告》

　　由測試人員編寫：記錄所有功能點的測試計劃、過程和測試結果；

　　二、敏捷開發是否需要系統設計？

　　前面也提到過，敏捷開發對開發人員來講實質差異不大，只是以小週期代替大週期。

　　小週期包括：需求、設計、開發、測試、釋出，這個過程中的設計環節是指要做產品設計和系統設計；由於做完整的設計需要有相對完整的資料和比較長的時間，與小週期是相對立的。

　　因此敏捷開發不主張高度細化和完整的設計，提倡做出一個大粒度的框架性設計，一般指架構設計或者系統設計，避免在以後的重構中發生架構級別的變化，然後在逐步實現的過程中逐漸深入展開、細化。

　　傳統的一些設計方法比如結構化設計、快速原型法都是可以融入敏捷開發過程中加以使用的。

　　三、敏捷開發是否需要專案計劃？

　　敏捷開發只是把整體拆分成許多個體，產品的開發實現過程對產品的功能完整性、穩定性、即時性等都有較高的要求。

　　它是一種有組織有目標的行為，往往我們都將其作為一個專案來管理，這就是討論為什麼有產品經理的同時還要有專案經理，為什麼要求產品經理要有專案管理的能力，因此它需要專案計劃。

　　但這個計劃是一個短程計劃，根據未實現的功能情況、前一個版本的反饋和組織目標制定開發計劃；唯有這樣才能不斷的融入新的需求變更；

　　四、敏捷開發的迭代週期大概多長？

　　敏捷開發的迭代週期沒有硬性的規定，結合專案里程碑、目標、功能實現情況、產品穩定性綜合決定，如果產品使用者活躍、功能實現難度小、維護複雜度低，建議以周為週期。

　　對於規模比較大、維護複雜度高的產品，考慮以2周-6周為週期釋出較為合適；頻繁的釋出會降低使用者的期望並提高使用者成本，給使用者心理上帶來額外的負擔：他會認為產品質量低，質量控制不嚴謹等；

　　五、敏捷開發為何提倡小版本？小版本有哪些優勢？

　　小版本的目的就是分解複雜度、降低風險，改善團隊士氣等；小版本有眾多優勢：

　　1、總體風險比較少：小版本變化小，總是在上一個版本基礎上區域性調整和增加，技術複雜度低；由於規劃的功能較少，工作量也易於估算，所以其總體風險比較少，常常能如期釋出；

　　2、需求的接納能力強：由於小版本快速實現併發布測試，然後就進入下一個版本的規劃實現週期，這樣新需求一旦提出就能快速進入開發視野，就能儘快實現；

　　3、測試和開發高效協作：開發和測試可以並行工作，當開發實現第一個版本時，測試設計測試方案和用例；釋出第一個版本後，開發就進入下一個版本輪次，測試就應用測試方案測試剛才釋出的版本，提交Bug；開發在下一個版本結束時修正所有上一輪發現的Bug，然後釋出新版本，如此迴圈往復，開發和測試實現高效協作；

　　六、敏捷開發與重構的關係如何？

　　敏捷開發以重構為基礎，時時刻刻處於重構過程中；

　　七、敏捷開發為何強調團隊人員的參與、使用者的參與？

　　敏捷強調團隊成員的高度參與就是要統一認識，把團隊的目標變成每個人的工作目標，使之為每個團隊成員的認同，形成高度的凝聚力，以達到群策群力、高效協作的效果。

　　由於沒有高度細化的文件，成員之間交換資訊的唯一渠道就是面對面溝通，良好的團隊氛圍和協作關係促進這種溝通，並使訊息有效傳達。

　　使用者由於缺乏專業訓練，無法清晰、準確的表達其意圖，導致需求的歧義和模糊；使用者的參與使模糊、邊界不確定的需求在互動的過程中得到確認和完善；在使用者參與過程中，我們常常可以聽到這樣的話：

“是的，就是這樣的”

“這正是我想要的……”

“這裡需要修改一下……”

“我的想法是這樣的……”

　　這個過程中，使用者承擔了一部分測試人員的角色。我們努力做的事情就是實現使用者需要的東西，並最終讓使用者喜歡它，唯有使用者喜歡它才能用好它，那麼我們怎能不認真聽取使用者的意見呢？一句話總結就是：使用者參與幫助我們做正確的事情！

　　八、怎麼才能評估團隊是否已經敏捷了？

　　由於敏捷開發沒有標準的可供參考的實踐過程，所以很難通過某個過程而斷定其開發過程敏捷了，那麼如何來評估團隊是敏捷的呢？一般採用的辦法是根據團隊呈現出來的氛圍、專案運作狀態、團隊成員的感性認識等方面來評估團隊和其開發過程是否敏捷，常見評估專案團隊是否已經敏捷的方法如下：

• 團隊有共同的願景，並且對這個願景充滿信心
• 團隊有明確的階段目標並且為每個成員所知曉
• 團隊知曉當前計劃：做什麼、何時完成、預期效果等
• 團隊任務是低耦合的，並且緊密協作
• 釋出過程是輕鬆愉快的，構建版本並不斷測試是常態行為之一

　　九、敏捷開發能縮短專案時間並提高質量嗎？

　　從我的實踐經驗來看是可以的，但目前無法提供量化的資料做參考，只能從幾個方面評估和推斷：

• 使用者的參與幫助團隊把功能一次性完成並做正確，縮減了返工的時間；
• 不斷的重構和測試釋出能把問題發現在早期，整體質量顯著提高；
• 過程目標導向，使團隊高度集中於專案目標，提高了生產力；
• 不斷的釋出對團隊是種正向激勵，榮譽感和成功欲使團隊保持持續的激情；

　　以上是一些敏捷開發過程當中的疑問，其實還有很多，目前我這邊還只是主推讓開發和測試團隊敏捷，PD團隊還在摸索當中。下次我會分享一下如何在需求這個層面用敏捷的方式來設計，去產出PRD文件。敏捷設計、敏捷開發、敏捷測試連在一起，這樣才能最大限度的發揮敏捷的效用。