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