資訊專欄INFORMATION COLUMN
摘要：但這并不意味著敏捷開發完全拋棄文檔，敏捷開發遵循輕文檔，重溝通的原則。把功能點拆分，導入到項目管理軟件中，相關人員只需要按照需求目錄一條條執行即可，不再需要一頁一頁的看了。如今的任務看板和燃盡圖已經由實物形式轉變為項目管理軟件。
我們比較熟知的軟件項目管理方法是瀑布。其基本流程是需求-> 設計->開發->測試。基本假設只要把每一個環節都做正確，那么最終得到的結果也是正確的。瀑布開發有非常成功的案例，比如微軟。但從總體來講，瀑布項目失敗率比較高。國外的軟件先行者們針對瀑布開發中暴露出來的問題進行了一系列的探索、思考和總結，提出了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解除疑問。而且整個敏捷團隊還需要召開發布計劃會議、迭代計劃會議、演示會議等內部會議及每日站立會議。每日站立會議上，團隊成員依次回答昨天做了什么今天計劃做什么，有什么問題，發現問題及時提出和解決。每個人發言完后，要走到任務看板前更新自己的燃盡圖。這也是敏捷流程中不可缺少的環節。
任務看板一般包含未完成、正在做、已完成的工作狀態，假設你今天把一個未完成的工作已經完成，那么你要把小卡片從未完成區域貼到已完成區域。每個人的工作進度和完成情況都是公開的，如果有一個人的工作任務在某一個位置放了好幾天，大家都能發現他的工作進度可能出現了什么問題。
如今的任務看板和燃盡圖已經由實物形式轉變為項目管理軟件。表現形式基本延續實體看板的形式，禪道中分為未開始、進行中、已暫停、已完成、已取消、已關閉幾種狀態。在看板頁面，成員完成某項任務后即可從進行中拖拽到已完成列，跟實體看板的作用如出一轍。
比起傳統開發模式，敏捷更加強調去流程化，文檔不再必須，變得可以簡化和被取代。因為在敏捷開發中，最簡單的解決方案就是最好的解決方案，最高效的工作方式就是最好的工作方式。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/52481.html
摘要：畢竟，架構師不參與寫代碼的工作。例如，通常架構師需要針對可能發生的每種情況進行規劃。這種架構師需要信任開發團隊來編寫代碼。 showImg(https://segmentfault.com/img/bVblaqV?w=900&h=383); Talk is cheap, show me the code！但是在互聯網企業中，身處技術要職的架構師到底需不需要寫代碼？ showImg(ht...
摘要：簡單來說就是給定條件執行流程預期結果的一個文檔，供后續測試人員進行測試。測試用例的設計需要盡可能覆蓋軟件的所有狀態，盡量考慮周期。針對測試人員少，上線時間緊的項目，可只做思維導圖列出測試點。我平時是用去設計測試用例。 ...
摘要：看起來沒有集合框架，線程，等那么耀眼，但它可是很多框架的基礎啊回復反射查看相關文章，先把基礎學會，后面的得用到它。 回頭看看， 我進入Java 領域已經快15個年頭了， 雖然學的也一般， 但是分享下我的心得，估計也能幫大家少走點彎路。[入門]我在2001年之前是C/C++陣營， 有C和面向對象的基礎， 后來轉到Java ，發現沒有指針的Java真是好簡單， 另外Java 的類庫好用的讓...
摘要：自動填補分號的規則在說要不要寫分號之前，先了解一下自動填補分號的規則。后來看到知乎上的作者尤雨溪和前端大神賀師俊的回答后，我對寫分號的想法完全顛覆了。總是寫分號并不能完全解決缺陷如后換行會自動插入分號。 在打算寫這篇文章之前，我是一個分號黨，在寫這篇文章之后，可能會轉為無分號黨了。之前是寫分號是編輯器語法較檢所養成的強迫癥，現在觀念的轉變，是因為看了不少大神的討論后，覺得javascr...
摘要：原文鏈接有大量平均水平左右的工人可被選擇參與進來這意味著好招人有成熟的大量的程序庫可供選擇這意味著大多數項目都是既有程序庫的拼裝，標準化程度高而定制化場景少開發工具測試工具問題排查工具完善，成熟基本上沒有團隊愿意在時間緊任務重的項目情況 原文鏈接：http://pfmiles.github.io/blog/java-groovy-mixed/ 有大量平均水平左右的工人可被選擇、參與...
閱讀 2434·2021-11-18 10:02
閱讀 693·2021-10-08 10:04
閱讀 2263·2021-09-03 10:51
閱讀 3549·2019-08-30 15:44
閱讀 2806·2019-08-29 14:09
閱讀 2471·2019-08-29 12:21
閱讀 2068·2019-08-26 13:45
閱讀 1810·2019-08-26 13:25
