經(jīng)驗(yàn)分享---敏捷開(kāi)發(fā)流程

1、 敏捷開(kāi)發(fā)流程介紹目錄什么是軟件開(kāi)發(fā)方法什么是敏捷開(kāi)發(fā)方法我們?cè)摬捎檬裁捶椒ㄊ裁词擒浖_(kāi)發(fā)方法什么是軟件開(kāi)發(fā)方法軟件開(kāi)發(fā)定義軟件開(kāi)發(fā)定義 根據(jù)用戶(hù)需求建造出軟件系統(tǒng)的產(chǎn)品開(kāi)發(fā)過(guò)程。包括需求獲取、開(kāi)發(fā)規(guī)劃、需求分析和設(shè)計(jì)、編程實(shí)現(xiàn)、軟件測(cè)試、版本控制。 - 維基百科維基百科常見(jiàn)種類(lèi)常見(jiàn)種類(lèi)瀑布式開(kāi)發(fā)迭代式開(kāi)發(fā)敏捷式開(kāi)發(fā)瀑布式開(kāi)發(fā)最典型的預(yù)見(jiàn)性方法，嚴(yán)格遵循預(yù)先計(jì)劃按照需求分析、設(shè)計(jì)、編碼、集成、測(cè)試、維護(hù)的步驟順序進(jìn)行。步驟成果用以衡量進(jìn)度，例如需求規(guī)格，設(shè)計(jì)文檔，測(cè)試計(jì)劃等，方便定義里程碑主要問(wèn)題是嚴(yán)格分級(jí)導(dǎo)致自由度降低，早期承諾導(dǎo)致對(duì)后期需求變化難以調(diào)整，代價(jià)高昂 迭代式開(kāi)發(fā)彌補(bǔ)傳統(tǒng)開(kāi)發(fā)方式

2、的一些弱點(diǎn)，具有更高的成功率和生產(chǎn)率開(kāi)發(fā)被分為一系列的小的、固定長(zhǎng)度的小項(xiàng)目，稱(chēng)為一系列的迭代。每次都包括需求分析、設(shè)計(jì)、實(shí)現(xiàn)與測(cè)試。開(kāi)發(fā)工作可在需求被完全確定前啟動(dòng)，并在一次迭代中完成部分功能。再通過(guò)客戶(hù)反饋來(lái)細(xì)化需求，開(kāi)始新一輪迭代。 Agile software development什么是敏捷開(kāi)發(fā)方法什么是敏捷開(kāi)發(fā)方法主要原則：主要原則：個(gè)體和互動(dòng)個(gè)體和互動(dòng)：高于流程和工具工作的軟件工作的軟件：高于詳盡的文檔客戶(hù)合作客戶(hù)合作：高于合同談判響應(yīng)變化響應(yīng)變化：高于遵循計(jì)劃vs迭代：迭代：都強(qiáng)調(diào)在短的開(kāi)發(fā)周期提交軟件，敏捷的周期可能更短，更強(qiáng)調(diào)人的高度協(xié)作vs瀑布：瀑布：敏捷強(qiáng)調(diào)盡早將小的可

3、用功能交付使用，在項(xiàng)目周期中持續(xù)改善，自由度高主要方法：主要方法：極限編程極限編程測(cè)試驅(qū)動(dòng)開(kāi)發(fā)測(cè)試驅(qū)動(dòng)開(kāi)發(fā)Scrum機(jī)制機(jī)制看板文化看板文化極限編程Extreme programming，縮寫(xiě)為XP，強(qiáng)調(diào)可適應(yīng)性而不是可預(yù)測(cè)性認(rèn)為軟件需求變化是自然現(xiàn)象在項(xiàng)目周期的任何階段去適應(yīng)變化，降低因需求變更而帶來(lái)的成本快速反饋：快速反饋：對(duì)客戶(hù)反饋?zhàn)龅郊皶r(shí)、迅速，重視單元測(cè)試假設(shè)簡(jiǎn)單：假設(shè)簡(jiǎn)單：認(rèn)為任何問(wèn)題都可以“極度簡(jiǎn)單”地解決，拒絕預(yù)測(cè)需求，拒絕為了未來(lái)而考慮重用 增量變化：增量變化：一次完成大的改造是不可能的，采用增量變化，小步前進(jìn)包容變化：包容變化：強(qiáng)調(diào)不反抗變化，應(yīng)該包容變化測(cè)試驅(qū)動(dòng)開(kāi)發(fā)Tes

4、t-Driven Development，簡(jiǎn)稱(chēng)TDD。它要求在編寫(xiě)代碼之前先寫(xiě)測(cè)試代碼，只編寫(xiě)使測(cè)試通過(guò)的功能代碼，通過(guò)測(cè)試來(lái)推動(dòng)整個(gè)開(kāi)發(fā)的進(jìn)行。編寫(xiě)簡(jiǎn)潔可用和高質(zhì)量的代碼，并加速開(kāi)發(fā)過(guò)程。 （FDD, DDD）根據(jù)客戶(hù)需求編寫(xiě)測(cè)試用例，從使用者角度設(shè)計(jì)代碼易測(cè)試和測(cè)試獨(dú)立性的要求使設(shè)計(jì)松耦合頻繁地運(yùn)行測(cè)試，盡早地發(fā)現(xiàn)錯(cuò)誤，提高代碼質(zhì)量持續(xù)的回歸測(cè)試，持續(xù)地跟蹤整個(gè)系統(tǒng)的狀態(tài)單元測(cè)試代碼可作為文檔，展示所有的API該如何使用和運(yùn)作主要角色：主要角色：Scrum Master ：Scrum教練和團(tuán)隊(duì)帶頭人，確保團(tuán)隊(duì)合理的運(yùn)作Scrum產(chǎn)品負(fù)責(zé)人（產(chǎn)品負(fù)責(zé)人（Product Owner）:確定產(chǎn)品

5、方向，定義產(chǎn)品內(nèi)容、優(yōu)先級(jí)及交付時(shí)間開(kāi)發(fā)團(tuán)隊(duì)（開(kāi)發(fā)團(tuán)隊(duì)（Team）: 跨職能的小團(tuán)隊(duì)（5-9人），擁有交付軟件需要的各種技能一種迭代式增量軟件開(kāi)發(fā)過(guò)程，包括了一系列實(shí)踐和預(yù)定義角色的過(guò)程骨架，通常用于敏捷軟件開(kāi)發(fā)。英語(yǔ)是橄欖球中爭(zhēng)球的意思ScrumScrum過(guò)程總覽Scrum階段1：制定產(chǎn)品Backlog 產(chǎn)品 backlog 是 Scrum 的核心 由需求或特性等組成的列表 用客戶(hù)的術(shù)語(yǔ)加以描述 按照重要性的級(jí)別進(jìn)行排序 backlog 條目稱(chēng)為故事（story）每個(gè)故事包括如下字段： ID(統(tǒng)一標(biāo)識(shí)符) Name（名稱(chēng)） Importance（重要性） Initial estimate（初

6、始估算工作量） How to demo（如何做演示） Notes（注解） Bug tracking ID（Bug 跟蹤 ID）產(chǎn)品產(chǎn)品 BACKLOG（示例）（示例）IDNameImpEstHow to demoNotes1存款305登錄，打開(kāi)存款界面，存入 10 歐元，轉(zhuǎn)到我的賬戶(hù)余額界面，檢查我的余額增加了 10 歐元。需要需要 UML 順順序圖。目前不序圖。目前不需要考慮加需要考慮加密的問(wèn)題。密的問(wèn)題。2查看自己的查看自己的交易明細(xì)交易明細(xì)108登錄，點(diǎn)擊登錄，點(diǎn)擊“交易交易”，存入一筆款項(xiàng)。返存入一筆款項(xiàng)。返回交易頁(yè)面，看到回交易頁(yè)面，看到新的存款顯示在頁(yè)新的存款顯示在頁(yè)面上。面上。使

7、用分頁(yè)技使用分頁(yè)技術(shù)避免大規(guī)術(shù)避免大規(guī)模的數(shù)據(jù)庫(kù)模的數(shù)據(jù)庫(kù)查詢(xún)。和查看查詢(xún)。和查看用戶(hù)列表的用戶(hù)列表的設(shè)計(jì)相似。設(shè)計(jì)相似。 獨(dú)立 基本相當(dāng)于一個(gè)feature 對(duì)客戶(hù)有價(jià)值 易于評(píng)估時(shí)間和難度 不易太大或太小 可測(cè)試Story的準(zhǔn)則的準(zhǔn)則-+ValueRiskLowHighHigh優(yōu)先級(jí)評(píng)估優(yōu)先級(jí)評(píng)估工作量的估算 最小單位為一個(gè)故事點(diǎn)（story point），相當(dāng)于一個(gè)理想的人天 投入最適合的人員，完全沒(méi)有打擾，需要幾天給出一個(gè)經(jīng)過(guò)驗(yàn)證，可以交付的完整實(shí)現(xiàn) 不需要絕對(duì)無(wú)誤，保證相對(duì)準(zhǔn)確（即:兩個(gè)點(diǎn)的時(shí)間應(yīng)該是四個(gè)點(diǎn)的一半） 估算全部工作，而不只是自己的部分 把故事分拆成更小的故事以達(dá)到更精確

8、 最小值是 0.5，太小的任務(wù)要么被移除，要么就給 0.5Scrum階段2:制定Sprint Backlog sprint 目標(biāo) 團(tuán)隊(duì)成員名單（以及投入程度） 確定sprint backlog（即 故事列表） 確定好 sprint 演示日期 確定每日 scrum 會(huì)議時(shí)間地點(diǎn) 協(xié)商sprint的時(shí)間長(zhǎng)度召開(kāi)Sprint 會(huì)議Sprint 計(jì)劃會(huì)議：13:00 17:00 （每小時(shí)休息 10 分鐘）13:00 13:30 產(chǎn)品負(fù)責(zé)人對(duì) sprint 目標(biāo)進(jìn)行總體介紹，概 括產(chǎn)品 backlog。定下演示的時(shí)間地點(diǎn)。13:30 15:00 團(tuán)隊(duì)估算時(shí)間，在必要的情況下拆分 backlog 條目。產(chǎn)

9、品負(fù)責(zé)人在必要時(shí)修改重要性評(píng)分。理清每個(gè)條 目的含義。所有重要性高的 backlog 條目都要填寫(xiě)“如何演 示”。15:00 16:00 團(tuán)隊(duì)選擇要放入 sprint 中的故事。計(jì)算生產(chǎn)率，用作核查工作安排的基礎(chǔ)。16:00 17:00 為每日 scrum 會(huì)議安排固定的時(shí)間地點(diǎn)，把故事進(jìn)一步拆分成任務(wù)。確定Sprint生產(chǎn)力如果沒(méi)有參考怎么辦？隨便猜一個(gè)，只會(huì)在第一個(gè) sprint 里面使用，以后有了歷史數(shù)據(jù)然后做改進(jìn)。新團(tuán)隊(duì)中使用的“默認(rèn)”投入程度通常是 70%，大多數(shù)團(tuán)隊(duì)都能達(dá)到的數(shù)值。Scrum階段階段3：每天站會(huì)：每天站會(huì)看板和站會(huì) 用戶(hù)體驗(yàn)比投影儀好，大家保持清醒，并留心會(huì)議進(jìn)展，

10、更多的參與感 多個(gè)故事可以同時(shí)編輯 重新劃分優(yōu)先級(jí)變得易如反掌挪動(dòng)索引卡就行 互相看到, 所有人都可以看到彼此，都能看到任務(wù)板 例會(huì)結(jié)束時(shí)算出剩余工作量之和，在 sprint 燃盡圖上畫(huà)上一個(gè)新的點(diǎn) 處理遲到，懲罰機(jī)制看板燃盡圖Scrum階段4：Sprint演示 清晰闡述 sprint 目標(biāo) 不要花太多時(shí)間準(zhǔn)備演示，集中精力演示實(shí)際工作的代碼 節(jié)奏要快，保持演示的快節(jié)奏 關(guān)注業(yè)務(wù)層次，不要管技術(shù)細(xì)節(jié)。注意力放在“我們做了什么”，而不是“我們?cè)趺醋龅摹?可能的話(huà)，讓觀(guān)眾自己試一下產(chǎn)品 不要演示一大堆細(xì)碎的 bug 修復(fù)和微不足道的特性Scrum階段5：Sprint總結(jié)設(shè)定時(shí)間為 1 至 3 個(gè)小時(shí)參與者：產(chǎn)品負(fù)責(zé)人，整個(gè)團(tuán)隊(duì) 向大家展示 sprint backlog，對(duì)sprint 做總結(jié) 每個(gè)人輪流發(fā)言，講出自己的想法，什么是好的，哪些可以更好，哪些需要在下個(gè) sprint 中改變