資訊專欄INFORMATION COLUMN
摘要：但這并不意味著敏捷開發(fā)完全拋棄文檔，敏捷開發(fā)遵循輕文檔，重溝通的原則。把功能點拆分，導(dǎo)入到項目管理軟件中，相關(guān)人員只需要按照需求目錄一條條執(zhí)行即可，不再需要一頁一頁的看了。如今的任務(wù)看板和燃盡圖已經(jīng)由實物形式轉(zhuǎn)變?yōu)轫椖抗芾碥浖?/p>
我們比較熟知的軟件項目管理方法是瀑布。其基本流程是需求-> 設(shè)計->開發(fā)->測試。基本假設(shè)只要把每一個環(huán)節(jié)都做正確，那么最終得到的結(jié)果也是正確的。瀑布開發(fā)有非常成功的案例，比如微軟。但從總體來講，瀑布項目失敗率比較高。國外的軟件先行者們針對瀑布開發(fā)中暴露出來的問題進行了一系列的探索、思考和總結(jié)，提出了Agile Dev的概念，中文翻譯為敏捷開發(fā)。
一．什么是敏捷開發(fā)
敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構(gòu)建初期被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備可視、可集成和可運行使用的特征。
換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。相對于瀑布開發(fā)模式，敏捷開發(fā)更加靈活可操作。
二．敏捷開發(fā)方式及流程
敏捷開發(fā)有很多種方式，如scrum,XP,LSD，F(xiàn)DD等，其中scrum是非常流行的一種。
scrum將產(chǎn)品的開發(fā)分解為若干個小sprint(迭代)，其周期從1周到4周不等，但不會超過4周。參與的團隊成員一般是5到9人。每期迭代要完成的user story是固定的。每次迭代會產(chǎn)生一定的交付。
scrum的基本流程如圖所示：
1.po（product owner指產(chǎn)品負責人）負責整理user story，形成左側(cè)的product backlog（按優(yōu)先順序排列的一個產(chǎn)品需求列表)。
2.發(fā)布計劃會議：po負責講解user story，對其進行估算和排序，發(fā)布計劃會議的產(chǎn)出就是制定出這一期迭代要完成的story列表，叫做sprint backlog。
3.迭代計劃會議：項目團隊對每一個story進行任務(wù)分解，分解的標準是完成該story的所有任務(wù)，最終每個任務(wù)都有明確的負責人，并完成工時的初估計。
4.每日例會：每天sm（scrum master指項目負責人）召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題。
5.演示會議：迭代結(jié)束之后，召開演示會議，相關(guān)人員都受邀參加，團隊負責向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由po整理，形成新的story。
6回顧會議：項目團隊對本期迭代進行總結(jié)，發(fā)現(xiàn)不足，制定改進計劃，下一次迭代繼續(xù)改進，已達到持續(xù)改進的效果。
敏捷流程中的三個關(guān)鍵要素是：
product backlog（產(chǎn)品需求）
sprint backlog（本期迭代任務(wù)）
burn-down chart（燃盡圖，進度的體現(xiàn)）
呈現(xiàn)了任務(wù)下達-拆分-推進的整個過程。
三．“輕文檔，重溝通”的敏捷
我們知道，瀑布開發(fā)是以文檔為驅(qū)動，文檔是一切工作的核心，po需要寫非常多而復(fù)雜的文檔，例如：需求文檔、設(shè)計文檔、API文檔、驗收文檔等等。
敏捷宣言說，“可工作的軟件勝于詳盡的文檔”。敏捷反對這種 “重文檔”的方法，而是強調(diào)成員之間的緊密協(xié)作、面對面的溝通、頻繁交付的新版本、緊湊而自我組織型的團隊?？梢姡艚蓍_發(fā)是更實際，更注重操作性的開發(fā)方式。
但這并不意味著敏捷開發(fā)完全拋棄文檔，敏捷開發(fā)遵循“輕文檔，重溝通”的原則。
“輕文檔”體現(xiàn)在，敏捷開發(fā)只關(guān)注文檔中的重要點，盡可能的簡化文檔，或者用軟件工具呈現(xiàn)另一種形式的文檔。
以傳統(tǒng)文檔來說，一個PRD（產(chǎn)品需求文檔）中包含對多個成員的訴求，比如前端工程師、后端工程師、測試人員。眾多的產(chǎn)品需求導(dǎo)致文檔厚重繁瑣，而且在實際工作中，很多開發(fā)人員并不喜歡看文檔。因為常常一個PRD中可能有好幾頁內(nèi)容都是與自己無關(guān)的，但是要看過才知道是否與自己有關(guān)，這在無形中就造成了時間的浪費。
敏捷管理中采用了用戶故事的方式進行product backlog的呈現(xiàn)，“用戶故事（稱作user story）”是采用用戶熟悉的術(shù)語來表達需求的一種方法，是用戶講給開發(fā)人員的故事（實際由po搜集用戶需求并整理成用戶故事）。
例如“作為禪道 用戶，我希望能實現(xiàn)自動登陸功能，這樣能更方便的登陸系統(tǒng)?！斑@就是一個具體的需求描述。
在這個需求描述中，涉及到三個要素“用戶角色（禪道用戶）”、“達成的目的（自動登陸功能）”、“開發(fā)價值（更方便的登陸系統(tǒng)）”
當然除了這三個要素，還需要涉及到驗收標準、優(yōu)先級、評審人等。
借助軟件工具實現(xiàn)product backlog的信息傳達是敏捷開發(fā)最普遍的做法。po把功能點拆分，導(dǎo)入到項目管理軟件中，相關(guān)人員只需要按照需求目錄一條條執(zhí)行即可，不再需要一頁一頁的看PRD了。后端只需要與提供接口相關(guān)的，前端主要看與功能相關(guān)的部分，而不需要查看與自己無關(guān)的內(nèi)容。如果開發(fā)人員在具體的sprint backlog開發(fā)中存在問題和疑問怎么辦呢？溝通！
“重溝通”體現(xiàn)在以結(jié)果為導(dǎo)向，以人為核心。通過面對面溝通的方式快速反應(yīng)，推動進度。
你可以隨時一對一溝通po解除疑問。而且整個敏捷團隊還需要召開發(fā)布計劃會議、迭代計劃會議、演示會議等內(nèi)部會議及每日站立會議。每日站立會議上，團隊成員依次回答昨天做了什么今天計劃做什么，有什么問題，發(fā)現(xiàn)問題及時提出和解決。每個人發(fā)言完后，要走到任務(wù)看板前更新自己的燃盡圖。這也是敏捷流程中不可缺少的環(huán)節(jié)。
任務(wù)看板一般包含未完成、正在做、已完成的工作狀態(tài)，假設(shè)你今天把一個未完成的工作已經(jīng)完成，那么你要把小卡片從未完成區(qū)域貼到已完成區(qū)域。每個人的工作進度和完成情況都是公開的，如果有一個人的工作任務(wù)在某一個位置放了好幾天，大家都能發(fā)現(xiàn)他的工作進度可能出現(xiàn)了什么問題。
如今的任務(wù)看板和燃盡圖已經(jīng)由實物形式轉(zhuǎn)變?yōu)轫椖抗芾碥浖１憩F(xiàn)形式基本延續(xù)實體看板的形式，禪道中分為未開始、進行中、已暫停、已完成、已取消、已關(guān)閉幾種狀態(tài)。在看板頁面，成員完成某項任務(wù)后即可從進行中拖拽到已完成列，跟實體看板的作用如出一轍。
比起傳統(tǒng)開發(fā)模式，敏捷更加強調(diào)去流程化，文檔不再必須，變得可以簡化和被取代。因為在敏捷開發(fā)中，最簡單的解決方案就是最好的解決方案，最高效的工作方式就是最好的工作方式。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/52481.html
摘要：畢竟，架構(gòu)師不參與寫代碼的工作。例如，通常架構(gòu)師需要針對可能發(fā)生的每種情況進行規(guī)劃。這種架構(gòu)師需要信任開發(fā)團隊來編寫代碼。 showImg(https://segmentfault.com/img/bVblaqV?w=900&h=383); Talk is cheap, show me the code！但是在互聯(lián)網(wǎng)企業(yè)中，身處技術(shù)要職的架構(gòu)師到底需不需要寫代碼？ showImg(ht...
摘要：簡單來說就是給定條件執(zhí)行流程預(yù)期結(jié)果的一個文檔，供后續(xù)測試人員進行測試。測試用例的設(shè)計需要盡可能覆蓋軟件的所有狀態(tài)，盡量考慮周期。針對測試人員少，上線時間緊的項目，可只做思維導(dǎo)圖列出測試點。我平時是用去設(shè)計測試用例。 ...
摘要：看起來沒有集合框架，線程，等那么耀眼，但它可是很多框架的基礎(chǔ)啊回復(fù)反射查看相關(guān)文章，先把基礎(chǔ)學(xué)會，后面的得用到它。 回頭看看， 我進入Java 領(lǐng)域已經(jīng)快15個年頭了， 雖然學(xué)的也一般， 但是分享下我的心得，估計也能幫大家少走點彎路。[入門]我在2001年之前是C/C++陣營， 有C和面向?qū)ο蟮幕A(chǔ)， 后來轉(zhuǎn)到Java ，發(fā)現(xiàn)沒有指針的Java真是好簡單， 另外Java 的類庫好用的讓...
摘要：自動填補分號的規(guī)則在說要不要寫分號之前，先了解一下自動填補分號的規(guī)則。后來看到知乎上的作者尤雨溪和前端大神賀師俊的回答后，我對寫分號的想法完全顛覆了。總是寫分號并不能完全解決缺陷如后換行會自動插入分號。 在打算寫這篇文章之前，我是一個分號黨，在寫這篇文章之后，可能會轉(zhuǎn)為無分號黨了。之前是寫分號是編輯器語法較檢所養(yǎng)成的強迫癥，現(xiàn)在觀念的轉(zhuǎn)變，是因為看了不少大神的討論后，覺得javascr...
摘要：原文鏈接有大量平均水平左右的工人可被選擇參與進來這意味著好招人有成熟的大量的程序庫可供選擇這意味著大多數(shù)項目都是既有程序庫的拼裝，標準化程度高而定制化場景少開發(fā)工具測試工具問題排查工具完善，成熟基本上沒有團隊愿意在時間緊任務(wù)重的項目情況 原文鏈接：http://pfmiles.github.io/blog/java-groovy-mixed/ 有大量平均水平左右的工人可被選擇、參與...
閱讀 2516·2021-11-18 10:02
閱讀 748·2021-10-08 10:04
閱讀 2390·2021-09-03 10:51
閱讀 3624·2019-08-30 15:44
閱讀 2883·2019-08-29 14:09
閱讀 2535·2019-08-29 12:21
閱讀 2129·2019-08-26 13:45
閱讀 1879·2019-08-26 13:25
