敏捷開發中的文檔：要不要寫？怎麼寫？

咱們比較熟知的軟件項目管理方法是瀑布。其基本流程是需求-> 設計->開發->測試。基本假設只要把每個環節都作正確，那麼最終獲得的結果也是正確的。瀑布開發有很是成功的案例，好比微軟。但從整體來說，瀑布項目失敗率比較高。國外的軟件先行者們針對瀑布開發中暴露出來的問題進行了一系列的探索、思考和總結，提出了Agile Dev的概念，中文翻譯爲敏捷開發。
一．什麼是敏捷開發

敏捷開發以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分紅多個子項目，各個子項目的成果都通過測試，具有可視、可集成和可運行使用的特徵。

換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。相對於瀑布開發模式，敏捷開發更加靈活可操做。
二．敏捷開發方式及流程

敏捷開發有不少種方式，如scrum,XP,LSD，FDD等，其中scrum是很是流行的一種。

scrum將產品的開發分解爲若干個小sprint(迭代)，其週期從1周到4周不等，但不會超過4周。參與的團隊成員通常是5到9人。每期迭代要完成的user story是固定的。每次迭代會產生必定的交付。

scrum的基本流程如圖所示：

1.po（product owner指產品負責人）負責整理user story，造成左側的product backlog（按優先順序排列的一個產品需求列表)。
2.發佈計劃會議：po負責講解user story，對其進行估算和排序，發佈計劃會議的產出就是制定出這一期迭代要完成的story列表，叫作sprint backlog。
3.迭代計劃會議：項目團隊對每個story進行任務分解，分解的標準是完成該story的全部任務，最終每一個任務都有明確的負責人，並完成工時的初估計。
4.每日例會：天天sm（scrum master指項目負責人）召集站立會議，團隊成員回答昨天作了什麼今天計劃作什麼，有什麼問題。
5.演示會議：迭代結束以後，召開演示會議，相關人員都受邀參加，團隊負責向你們展現本次迭代取得的成果。期間你們的反饋記錄下來，由po整理，造成新的story。
6回顧會議：項目團隊對本期迭代進行總結，發現不足，制定改進計劃，下一次迭代繼續改進，已達到持續改進的效果。

敏捷流程中的三個關鍵要素是：

product backlog（產品需求）

sprint backlog（本期迭代任務）

burn-down chart（燃盡圖，進度的體現）

呈現了任務下達-拆分-推動的整個過程。
三．「輕文檔，重溝通」的敏捷

咱們知道，瀑布開發是以文檔爲驅動，文檔是一切工做的核心，po須要寫很是多而複雜的文檔，例如：需求文檔、設計文檔、API文檔、驗收文檔等等。

敏捷宣言說，「可工做的軟件勝於詳盡的文檔」。敏捷反對這種 「重文檔」的方法，而是強調成員之間的緊密協做、面對面的溝通、頻繁交付的新版本、緊湊而自我組織型的團隊。可見，敏捷開發是更實際，更注重操做性的開發方式。

但這並不意味着敏捷開發徹底拋棄文檔，敏捷開發遵循「輕文檔，重溝通」的原則。
「輕文檔」體如今，敏捷開發只關注文檔中的重要點，儘量的簡化文檔，或者用軟件工具呈現另外一種形式的文檔。

以傳統文檔來講，一個PRD（產品需求文檔）中包含對多個成員的訴求，好比前端工程師、後端工程師、測試人員。衆多的產品需求致使文檔厚重繁瑣，並且在實際工做中，不少開發人員並不喜歡看文檔。由於經常一個PRD中可能有好幾頁內容都是與本身無關的，可是要看過才知道是否與本身有關，這在無形中就形成了時間的浪費。

敏捷管理中採用了用戶故事的方式進行product backlog的呈現，「用戶故事（稱做user story）」是採用用戶熟悉的術語來表達需求的一種方法，是用戶講給開發人員的故事（實際由po蒐集用戶需求並整理成用戶故事）。

例如「做爲禪道 用戶，我但願能實現自動登錄功能，這樣能更方便的登錄系統。「這就是一個具體的需求描述。

在這個需求描述中，涉及到三個要素「用戶角色（禪道用戶）」、「達成的目的（自動登錄功能）」、「開發價值（更方便的登錄系統）」

固然除了這三個要素，還須要涉及到驗收標準、優先級、評審人等。

藉助軟件工具實現product backlog的信息傳達是敏捷開發最廣泛的作法。po把功能點拆分，導入到項目管理軟件中，相關人員只須要按照需求目錄一條條執行便可，再也不須要一頁一頁的看PRD了。後端只須要與提供接口相關的，前端主要看與功能相關的部分，而不須要查看與本身無關的內容。若是開發人員在具體的sprint backlog開發中存在問題和疑問怎麼辦呢？溝通！
「重溝通」體如今以結果爲導向，以人爲核心。經過面對面溝通的方式快速反應，推進進度。

你能夠隨時一對一溝通po解除疑問。並且整個敏捷團隊還須要召開發布計劃會議、迭代計劃會議、演示會議等內部會議及每日站立會議。每日站立會議上，團隊成員依次回答昨天作了什麼今天計劃作什麼，有什麼問題，發現問題及時提出和解決。每一個人發言完後，要走到任務看板前更新本身的燃盡圖。這也是敏捷流程中不可缺乏的環節。

任務看板通常包含未完成、正在作、已完成的工做狀態，假設你今天把一個未完成的工做已經完成，那麼你要把小卡片從未完成區域貼到已完成區域。每一個人的工做進度和完成狀況都是公開的，若是有一我的的工做任務在某一個位置放了好幾天，你們都能發現他的工做進度可能出現了什麼問題。

現在的任務看板和燃盡圖已經由實物形式轉變爲項目管理軟件。表現形式基本延續實體看板的形式，禪道中分爲未開始、進行中、已暫停、已完成、已取消、已關閉幾種狀態。在看板頁面，成員完成某項任務後便可從進行中拖拽到已完成列，跟實體看板的做用一模一樣。
比起傳統開發模式，敏捷更增強調去流程化，文檔再也不必須，變得能夠簡化和被取代。由於在敏捷開發中，最簡單的解決方案就是最好的解決方案，最高效的工做方式就是最好的工做方式。