敏捷軟件開發(fā)

效率的團(tuán)隊項目開發(fā)

（之一：敏捷開發(fā)）目錄敏捷概述正確理解敏捷認(rèn)識敏捷敏捷理念解讀敏捷實施過程軟件作坊軟件過程控制重型過程2001~今敏捷正在流行軟件規(guī)模小，以作坊式開發(fā)為主；硬件飛速發(fā)展，軟件規(guī)模和復(fù)雜度激增，引發(fā)軟件危機(jī)；引入成熟生產(chǎn)制造管理方法，以“過程為中心”分階段來控制軟件開發(fā)（瀑布模型），一定程度上緩解了軟件危機(jī)；軟件失敗的經(jīng)驗促使過程被不斷增加約束和限制，軟件開發(fā)過程日益“重型化”，開發(fā)效率降低、響應(yīng)速度變慢；隨著信息時代到來，需求變化更快，交付周期成為企業(yè)核心競爭力，輕量級的，更能適應(yīng)變化的敏捷軟件開發(fā)方法被普遍認(rèn)可并迅速流行。軟件危機(jī)20世紀(jì)60年代80年代90年代軟件開發(fā)順應(yīng)時代變化，從重型過程轉(zhuǎn)向輕量型敏捷70年代敏捷誕生的歷史背景Page3業(yè)界敏捷浪潮ISO9000（09版）標(biāo)準(zhǔn)將在原來八大原則的基礎(chǔ)上新增敏捷原則2000年美國軍方軟件開發(fā)標(biāo)準(zhǔn)（DOD5000.2）推薦迭代為軟件開發(fā)優(yōu)選模式世界影響最大的美國波多里奇國家質(zhì)量獎將敏捷作為核心的十一大原則之一Page4敏捷開發(fā)是一種思維方式和軟件過程方法論 在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。敏捷開發(fā)敏捷開發(fā)是由一些業(yè)界專家針對一些企業(yè)現(xiàn)狀提出了一些讓軟件開發(fā)團(tuán)隊具有快速工作、響應(yīng)變化能力的價值觀和原則，并于2001初成立了敏捷聯(lián)盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法。簡單的說，敏捷開發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法擁抱變化的開發(fā)流程Page5敏捷宣言揭示更好的軟件開發(fā)方法敏捷宣言（2001年）是敏捷起源的基礎(chǔ)，由上述4個簡單的價值觀組成，敏捷宣言的簽署推動了敏捷運動敏捷宣言本質(zhì)是揭示一種更好的軟件開發(fā)方式，啟迪人們重新思考軟件開發(fā)中的價值和如何更好的工作敏捷宣言Page6軟件更像一個活著的植物，軟件開發(fā)是自底向上逐步有序的生長過程，類似于植物自然生長敏捷開發(fā)遵循軟件客觀規(guī)律，不斷的進(jìn)行迭代增量開發(fā)，最終交付符合客戶價值的產(chǎn)品傳統(tǒng)開發(fā)敏捷開發(fā)敏捷更符合軟件開發(fā)規(guī)律Page7使用SWOT分析法注重概念和架構(gòu)設(shè)計，輕詳細(xì)設(shè)計市場和需求驅(qū)動，而非技術(shù)驅(qū)動時刻考慮版本兼容性敏捷開發(fā)要點強(qiáng)調(diào)的是產(chǎn)品的路線規(guī)劃、市場趨勢、客戶價值、技術(shù)趨勢等。在敏捷開發(fā)中，更加注重客戶需求。進(jìn)行SWOT分析，就能選出付出最小工作量，但能獲得最大價值的模塊。擁抱變化，但不盲目變化。產(chǎn)品的改動需要經(jīng)過概念設(shè)計、架構(gòu)設(shè)計以及SWOT分析后，三思而后行。時刻考慮產(chǎn)品的架構(gòu)、規(guī)劃路線圖，老版本的兼容性，及遷移平滑性。否則，隨著版本的增多，必將面對著大量的維護(hù)工作。敏捷開發(fā)強(qiáng)調(diào)溝通的重要性，而輕冗余文檔。但敏捷開發(fā)并不意味著無文檔。在敏捷開發(fā)過程中，適量的文檔還是很有幫助，有助于整理思路，加快溝通和討論。輕文檔，但非無文檔Page8敏捷對生產(chǎn)率、質(zhì)量、滿意度、成本有明顯改進(jìn)82%的項目生產(chǎn)率有提高77%的項目質(zhì)量有提高78%的項目客戶滿意度有提高37%的項目成本有降低*以上數(shù)據(jù)來自DDJ2008由ScottAmbler發(fā)起的網(wǎng)上調(diào)查結(jié)果Page9目錄敏捷概述正確理解敏捷認(rèn)識敏捷敏捷理念解讀敏捷實施過程對敏捷的常見誤解誤解一：敏捷開發(fā)意味著可以不需要文檔、設(shè)計和計劃誤解二：敏捷只是一些優(yōu)秀實踐，或者是優(yōu)秀實踐的結(jié)合誤解三：敏捷只適用于小項目開發(fā)誤解四：敏捷只會對研發(fā)產(chǎn)生改變誤解五：管理者不需要親自了解敏捷，只需要管理上支持就可以了誤解六：引入敏捷只需要按照既定的步驟去做就可以了誤解七：敏捷是CMM的替代品，是另一種流程誤解八：敏捷只注重特性的快速交付，在敏捷下架構(gòu)不重要了Page11敏捷=理念+優(yōu)秀實踐+具體應(yīng)用理念優(yōu)秀實踐具體應(yīng)用理念（敏捷核心思想）敏捷包括3個層次優(yōu)秀實踐（敏捷的經(jīng)驗積累）具體應(yīng)用（能夠結(jié)合自身靈活應(yīng)用才是真正敏捷）Page12理念：聚焦客戶價值(Value)，消除浪費軟件業(yè)：45%的軟件特性客戶沒有使用Source：StandishGroup來自5萬個軟件開發(fā)項目的調(diào)查產(chǎn)品商業(yè)成功為目標(biāo)，聚焦客戶價值、圍繞價值流消除浪費“價值”在“敏捷宣言”中的體現(xiàn)個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃Page13理念：激發(fā)團(tuán)隊(Team)潛能，加強(qiáng)協(xié)作團(tuán)隊是價值的真正創(chuàng)造者，應(yīng)加強(qiáng)團(tuán)隊協(xié)作、激發(fā)團(tuán)隊潛能軟件開發(fā)是一種團(tuán)隊活動，首先應(yīng)做到提升溝通效率降低交流成本Source：《經(jīng)濟(jì)學(xué)家2003》&DeMarco研究報告“團(tuán)隊”在“敏捷宣言”中的體現(xiàn)個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃效率流行度文檔錄制的視頻錄制的音頻2人郵件溝通2人白板溝通2人電話溝通不支持問答形式支持問答形式研究表明面對面的溝通最有效

業(yè)界調(diào)查：一個50人開發(fā)團(tuán)隊，每人平均30%時間用于編碼，70%的時間用于與其他成員交流。研究表明1981年來自不同公司的優(yōu)秀程序員生產(chǎn)率之比是7:1，而2007年最新的研究數(shù)據(jù)，則是40:1。人是軟件開發(fā)的決定因素Page14理念：不斷調(diào)整以適應(yīng)(Adapting)變化麥當(dāng)勞是簡單可預(yù)測生產(chǎn)過程《人月神話》：軟件開發(fā)是人類最復(fù)雜工作之一，軟件具有四個屬性：復(fù)雜性、一致性、可變性和不可見性。軟件開發(fā)是不可重復(fù)、探索性的、演進(jìn)的，適應(yīng)性過程。隨軟件規(guī)模增長，需求變化呈非線性增長軟件開發(fā)是復(fù)雜不可預(yù)測的經(jīng)驗控制過程“適應(yīng)變化”在“敏捷宣言”中的體現(xiàn)不斷的根據(jù)經(jīng)驗調(diào)整，最終交付達(dá)到業(yè)務(wù)目標(biāo)的產(chǎn)品軟件開發(fā)規(guī)律再審視個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃Page15開發(fā)團(tuán)隊一具體應(yīng)用：因地制宜選擇適合的敏捷實踐團(tuán)隊在透徹理解敏捷理念的基礎(chǔ)上，可以靈活選擇最適合自己的實踐，避免教條化站立會議排序的工作列表持續(xù)集成持續(xù)集成重構(gòu)持續(xù)集成結(jié)對編程迭代開發(fā)++迭代開發(fā)+++++…+…+…開發(fā)團(tuán)隊三敏捷理念開發(fā)團(tuán)隊二敏捷理念敏捷理念Page16目錄敏捷概述正確理解敏捷認(rèn)識敏捷敏捷理念解讀敏捷實施過程深入理解敏捷理念深入理解“適應(yīng)變化”認(rèn)請“客戶是逐步發(fā)現(xiàn)真正需求”小批量是快速交付的關(guān)鍵通過迭代計劃不斷調(diào)整以適應(yīng)需求變化應(yīng)持續(xù)保持良好的軟件架構(gòu)利用多層次反饋不斷調(diào)整以逼近目標(biāo)深入理解“激發(fā)團(tuán)隊”認(rèn)清團(tuán)隊的基本事實敏捷方式下管理者的轉(zhuǎn)變敏捷方式下團(tuán)隊成員的轉(zhuǎn)變深入理解“聚焦客戶價值”標(biāo)識和消除軟件開發(fā)中的浪費交付剛剛好的系統(tǒng)隨時構(gòu)建質(zhì)量，不容忍缺陷及時消除技術(shù)債務(wù)，持續(xù)保持快速響應(yīng)Page18浪費類別浪費舉例1部分完成的工作部分完成但沒有最終落地的工作（沒有轉(zhuǎn)化成代碼的設(shè)計文檔；未及時合入的代碼導(dǎo)致引發(fā)后續(xù)更多同步工作量）。2未應(yīng)用特性開發(fā)完成但沒有被客戶應(yīng)用的特性。3再次學(xué)習(xí)人員頻繁流動導(dǎo)致經(jīng)驗不能積累，反復(fù)重新學(xué)習(xí)；在多個環(huán)節(jié)移交時，接收信息者也需要重新學(xué)習(xí)；擁有某領(lǐng)域的專家，但在開發(fā)過程中需要此領(lǐng)域經(jīng)驗時，他卻沒參與，而是團(tuán)隊重新摸索。4移交知識信息的傳遞總是伴隨信息丟失，隱形知識尤其困難，分工過細(xì)往往導(dǎo)致過多不必要的移交（如詳細(xì)設(shè)計和實現(xiàn)分離，造成大量設(shè)計信息丟失）。5任務(wù)切換研究表明多任務(wù)工作會導(dǎo)致效率下降20%-40%（員工多頭工作或雜事繁多）。6延遲因任務(wù)或資源相互依賴而導(dǎo)致工作停滯（集成時被關(guān)鍵模塊阻塞，等待測試環(huán)境就緒）。7缺陷解決缺陷活動本身就是浪費，而且缺陷越遺留到后端浪費越大。聚焦客戶價值，標(biāo)識和消除軟件開發(fā)中的浪費Source：《精益軟件開發(fā)》Page19當(dāng)質(zhì)量、進(jìn)度、資源沖突時，能改變的只有項目范圍，即選擇“交付剛剛好的系統(tǒng)”產(chǎn)品交付前，客戶往往期望多而全的功能，產(chǎn)品交付后，客戶把穩(wěn)定的質(zhì)量放在首位，客戶對產(chǎn)品質(zhì)量要求是Alwayswork，不是Sometimes。與其為了滿足多而全的功能導(dǎo)致交付延遲，質(zhì)量不穩(wěn)定，不如按時交付剛剛好的系統(tǒng)，保證其高質(zhì)量運行。交付剛剛好的系統(tǒng)，基于對客戶需求的深入理解，并花時間了解細(xì)節(jié)，簡化（simplify）需求（降低復(fù)雜性）而不是簡單地拒絕需求（delete）。做到“交付剛剛好的系統(tǒng)”，同時需要管理者有足夠的勇氣和果斷決策聚焦客戶價值，交付剛剛好的系統(tǒng)在項目明顯超負(fù)荷時，管理者簡單地期望靠團(tuán)隊workharder來解決，最終導(dǎo)致：質(zhì)量下降項目延期客戶不滿意團(tuán)隊疲勞埋下長期隱患Page20缺陷遺留帶來高額成本：對單獨質(zhì)量保證活動（如后端測試）的依賴，容易形成缺陷可以遺留到下個階段的心理，導(dǎo)致缺陷發(fā)現(xiàn)成本升高（系統(tǒng)測試階段缺陷定位和解決成本是開發(fā)階段的10倍）例：E公司開發(fā)階段和測試階段發(fā)現(xiàn)缺陷的比例為7：3，而我司大量缺陷集中在后端發(fā)現(xiàn)，帶來高額成本。聚焦客戶價值，隨時構(gòu)建質(zhì)量，不容忍缺陷從項目一開始就隨時構(gòu)建質(zhì)量：形成零缺陷文化，不要容忍缺陷：發(fā)現(xiàn)缺陷應(yīng)立即停下來解決，以保證在堅實的質(zhì)量基礎(chǔ)上前行。開發(fā)和測試緊密協(xié)作：測試人員參與到設(shè)計和開發(fā)過程中，共同預(yù)防缺陷的產(chǎn)生。例如：持續(xù)集成暴露的問題需立即解決Page21聚焦客戶價值，及時消除技術(shù)債務(wù)，持續(xù)保持快速響應(yīng)技術(shù)商務(wù)為什么會有技術(shù)債務(wù)：為滿足短期商業(yè)目標(biāo)，不影響其外部表現(xiàn)的情況下，會在技術(shù)方面進(jìn)行一定的讓步，這種讓步雖對當(dāng)前版本的質(zhì)量影響甚微，但會嚴(yán)重影響后續(xù)版本響應(yīng)客戶需求的能力，從而形成技術(shù)債務(wù)。時間技術(shù)債務(wù)開發(fā)速率對待技術(shù)債務(wù)的態(tài)度：技術(shù)債務(wù)是有成本的，如不及時償還，會隨時間積累利息變高，導(dǎo)致開發(fā)效率大幅下降，從而降低客戶響應(yīng)能力。因此對待技術(shù)債務(wù)的態(tài)度是加以管理并及時償還（如及時重構(gòu)）。常見技術(shù)債務(wù):日益腐爛的架構(gòu)、圈復(fù)雜度高的代碼、低的測試自動化率、不及時清除的靜態(tài)檢查告警等。Page22聚焦客戶價值，及時消除技術(shù)債務(wù)，持續(xù)保持快速響應(yīng)進(jìn)行系統(tǒng)思考清償技術(shù)債務(wù):用今天的付出換回未來可預(yù)見的持續(xù)發(fā)展。產(chǎn)品重于項目產(chǎn)品成功將會有很長的生命周期，若軟件產(chǎn)品不考慮需求更改，就沒有可持續(xù)發(fā)展。解決技術(shù)債務(wù)流程找出債務(wù)的位置。構(gòu)建業(yè)務(wù)案例，并對債務(wù)影響領(lǐng)域的優(yōu)先級達(dá)成共識（包括團(tuán)隊和利益相關(guān)者）。采用行之有效的策略修復(fù)選擇處理的債務(wù)問題。重復(fù)執(zhí)行上述步驟。Page23激發(fā)團(tuán)隊，認(rèn)清團(tuán)隊的基本事實Source:JeffCSMTrainingmaterial信任是高績效團(tuán)隊的基石信任承諾沖突創(chuàng)新關(guān)于團(tuán)隊激勵：

當(dāng)團(tuán)隊自管理時效率最高人們對自己做出的承諾比別人要求的承諾更認(rèn)真人們會盡力做到最好在強(qiáng)大的壓力下努力工作，人們會自然而然地降低對質(zhì)量的要求關(guān)于團(tuán)隊績效：

當(dāng)團(tuán)隊成員不被打擾時，工作效率最高當(dāng)團(tuán)隊解決自我問題時，提升最快廣泛的、面對面的交流是團(tuán)隊工作最高效的方式關(guān)于團(tuán)隊構(gòu)建：團(tuán)隊生產(chǎn)率大于相同數(shù)目的個體生產(chǎn)率之和當(dāng)不同技能領(lǐng)域的人員組成團(tuán)隊并聚焦于工作時，產(chǎn)品更健壯Page24激發(fā)團(tuán)隊，敏捷方式下管理者的轉(zhuǎn)變管理者努力“控制”團(tuán)隊：制定詳細(xì)的工作計劃，并做出詳細(xì)的工作安排指令性工作方式監(jiān)控過程基于復(fù)雜規(guī)則的管理管理者努力“激發(fā)”團(tuán)隊：通過目標(biāo)來牽引團(tuán)隊自主工作幫助團(tuán)隊提供資源，排除障礙營造團(tuán)隊自我管理的工作氛圍作為教練輔導(dǎo)團(tuán)隊進(jìn)步基于簡單原則的管理，原則簡單但必須被遵守敏捷方式下對管理者最大的挑戰(zhàn)是學(xué)會放松”控制”(loosecontrol)傳統(tǒng)方式敏捷方式Page25激發(fā)團(tuán)隊，敏捷方式下團(tuán)隊成員的轉(zhuǎn)變團(tuán)隊成員是“聽從安排的獨立貢獻(xiàn)者”:被動等待主管下指令安排工作獨立工作為主，協(xié)作少以文檔和郵件為主要溝通方式只關(guān)注個體任務(wù)“做完”，不關(guān)注團(tuán)隊目標(biāo)能力相對單一，學(xué)習(xí)動力不足敏捷方式的管理者從被動到主動的心態(tài)轉(zhuǎn)變是團(tuán)隊成員適應(yīng)敏捷開發(fā)的關(guān)鍵團(tuán)隊成員是“全方位的積極參與者”:共同參與計劃制定和任務(wù)安排團(tuán)隊協(xié)作貫穿工作始終面對面交流是主要溝通方式關(guān)注團(tuán)隊目標(biāo)，共擔(dān)責(zé)任能力要求更廣，主動學(xué)習(xí)適應(yīng)崗位要求傳統(tǒng)方式敏捷方式Page26殘酷現(xiàn)實客戶是逐步發(fā)現(xiàn)他真正要的東西開發(fā)人員逐步發(fā)現(xiàn)如何開發(fā)產(chǎn)品滿足客戶需求在這個過程中隨時可能發(fā)生變化美好愿望客戶知道自己要的是什么開發(fā)人員知道如何開發(fā)來滿足客戶需求在開發(fā)過程中需求不會發(fā)生變化期望客戶一開始就想清楚他們真正要的東西是不現(xiàn)實的。我們應(yīng)當(dāng)通過不斷的向客戶交付可用的產(chǎn)品，啟發(fā)客戶逐步的發(fā)現(xiàn)真正的需求。我們認(rèn)識到預(yù)期需求實際需求價值時間適應(yīng)變化，認(rèn)清“客戶是逐步發(fā)現(xiàn)真正需求”Page27適應(yīng)變化，小批量是快速交付的關(guān)鍵我們首先要做的是通過盡早地、持續(xù)地交付有價值的軟件來使客戶滿意。經(jīng)常性的交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好?！悦艚蒈浖氖€原則在需求響應(yīng)周期相同的情況下，批量（一次開發(fā)的需求量）越小，資源利用率更高。在資源利用率相同的情況下，批量越小，交付周期更短。減小批量不僅能縮短交付周期，而且還能提高質(zhì)量、促進(jìn)創(chuàng)新、降低管理成本、更高的效率等其他好處，大幅提升商業(yè)價值。減少批量的好處資源利用率交付周期大批量中批量小批量Source：CraigLarman減小批量1.減少排隊3.縮短交付周期2.加快反饋4.增強(qiáng)質(zhì)量5.改善創(chuàng)新6.降低管理成本7.更高的效率$$排隊理論：小批量與縮短交付周期、人員有效產(chǎn)出的關(guān)系Page28適應(yīng)變化，通過迭代計劃不斷調(diào)整以適應(yīng)需求變化正確做計劃方法在每一輪迭代開始，只詳細(xì)確定本次迭代的工作內(nèi)容，并嚴(yán)格執(zhí)行，對后續(xù)較遠(yuǎn)的迭代內(nèi)容只做粗略的計劃，避免浪費。項目范圍常發(fā)生變化需求出現(xiàn)了增加、刪除、優(yōu)先級調(diào)整（如圖E、O、P、J）工作量在需求細(xì)化后發(fā)現(xiàn)離原始工作量估計有偏差，引發(fā)計劃調(diào)整；（如圖中I）客戶使用了產(chǎn)品后，發(fā)現(xiàn)有些需求已不再需要（如圖中D、G）變化無法一次性預(yù)測，一開始制作大而全的計劃易造成浪費應(yīng)根據(jù)迭代積累的經(jīng)驗和需求變化的情況對計劃不斷調(diào)整和細(xì)化Page29適應(yīng)變化，應(yīng)持續(xù)保持良好的軟件架構(gòu)良好軟件架構(gòu)是適應(yīng)變化的基石軟件的特點是龐大、復(fù)雜、生命周期長，因此需要良好架構(gòu)來保證長期的演進(jìn)，避免大規(guī)模的返工；優(yōu)秀的架構(gòu)通過可擴(kuò)展性來很好地適應(yīng)需求的變化，對敏捷起到支持作用，相反拙劣的架構(gòu)會阻礙敏捷；良好架構(gòu)使系統(tǒng)部件處于松耦合狀態(tài)，有助于制定出合適的增量開發(fā)/集成計劃，使分層分級的持續(xù)集成更加容易實施。軟件架構(gòu)需要盡早驗證和持續(xù)維護(hù)新產(chǎn)品開發(fā)通過早期迭代來實現(xiàn)和驗證架構(gòu)，有利于架構(gòu)的盡早穩(wěn)定；增量開發(fā)需識別影響架構(gòu)的需求，優(yōu)先實現(xiàn)，規(guī)避架構(gòu)風(fēng)險；通過重構(gòu)及時維護(hù)和優(yōu)化架構(gòu)（償還技術(shù)債務(wù)），使架構(gòu)保持生命力。Page30適應(yīng)變化，利用多層次反饋不斷調(diào)整以逼近目標(biāo)結(jié)對編程單元測試持續(xù)集成站立會議/回顧會議客戶驗收對代碼質(zhì)量的反饋對單元功能的反饋對團(tuán)隊運作的反饋對系統(tǒng)功能的反饋對客戶需求的反饋利用多層次反饋手段，在變化的環(huán)境中讓團(tuán)隊準(zhǔn)確地了解與目標(biāo)的差距，不斷調(diào)整自身行為，并逐步逼近靶心多層次反饋手段Page31目錄敏捷概述正確理解敏捷認(rèn)識敏捷敏捷理念解讀敏捷實施過程敏捷實踐概覽技術(shù)實踐迭代計劃會議每日站立會議可視化管理迭代驗收迭代回顧會議管理實踐產(chǎn)品Backlog（需求清單）迭代Backlog完成標(biāo)準(zhǔn)敏捷團(tuán)隊角色ProductOwner（PO）ScrumMasterTeam完整團(tuán)隊實踐團(tuán)隊用戶故事結(jié)對編程TDD（測試驅(qū)動開發(fā)）持續(xù)集成工作件敏捷軟件開發(fā)是以短周期迭代為核心，包含團(tuán)隊、工作件、管理和技術(shù)優(yōu)秀實踐的集合迭代開發(fā)Page33敏捷軟件開發(fā)典型場景PO和開發(fā)團(tuán)隊對產(chǎn)品業(yè)務(wù)目標(biāo)形成共識PO建立和維護(hù)產(chǎn)品需求列表backlog（需求會不斷新增和改變）,并進(jìn)行優(yōu)先級排序PO每輪迭代前，Review需求列表，并篩選高優(yōu)先級需求進(jìn)入本輪迭代開發(fā)開發(fā)團(tuán)隊細(xì)化本輪迭代需求，并按照需求的優(yōu)先級，依次在本輪迭代完成開發(fā)團(tuán)隊每日站立會議、特性開發(fā)、持續(xù)集成，使開發(fā)進(jìn)度真正透明PO對每輪迭代（2－4周）交付的可工作軟件進(jìn)行現(xiàn)場驗收和反饋回到第3步，開始下一輪迭代迭代每日工作站立會議特性開發(fā)特性測試持續(xù)集成交付可以工作的軟件迭代計劃回顧確定一個迭代的工作內(nèi)容產(chǎn)品和利益相關(guān)人①②③、⑦④⑤⑥Page34什么是迭代式開發(fā)迭代開發(fā)將整個軟件生命周期分成多個小的迭代（一般2-4周），每一次迭代都由需求分析、設(shè)計、實現(xiàn)和測試在內(nèi)的多個活動組成，每一次迭代都可以生成一個穩(wěn)定和被驗證過的軟件版本。迭代式開發(fā)的好處通過將高技術(shù)風(fēng)險的需求在早期迭代里實現(xiàn)，有助于盡早暴露問題和及時消除風(fēng)險通過提供功能漸增的產(chǎn)品，持續(xù)從客戶獲得反饋，根據(jù)反饋及時調(diào)整，使最終產(chǎn)品更加符合客戶的需要通過小批量減少排隊，提供更靈活、快速的交付能力平滑人力資源的使用，避免出現(xiàn)瓶頸迭代式開發(fā)的關(guān)鍵要點每一次迭代都建立在穩(wěn)定的質(zhì)量基礎(chǔ)上，并做為下一輪迭代的基線，整個系統(tǒng)的功能隨著迭代穩(wěn)定地增長和不斷完善。每次迭代要邀請用戶代表（外部或內(nèi)部）驗收，提供需求是否滿足的反饋迭代推薦采用固定的周期（2-4周），迭代內(nèi)工作不能完成，應(yīng)當(dāng)縮減交付范圍而不是延長周期敏捷軟件開發(fā)核心——迭代開發(fā)迭代1迭代2迭代3反饋反饋迭代開發(fā)是有節(jié)奏地小步快跑，但建立在堅實的質(zhì)量基礎(chǔ)上Page35敏捷團(tuán)隊包括3個核心角色:PO(ProductOwner)、ScrumMaster(Scrum教練)和Team(開發(fā)產(chǎn)品)敏捷團(tuán)隊的三個核心角色Marketing用戶用服管理..etc…利益相關(guān)人SMSMSMSM：ScrumMasterPO：ProductOwnerPage36敏捷團(tuán)隊的角色職責(zé)角色名稱角色定義角色職責(zé)注意事項ProductOwner（產(chǎn)品負(fù)責(zé)人）確保Team做正確的事代表利益相關(guān)人（如用戶、Marketing、用服、管理者等），對產(chǎn)品投資回報負(fù)責(zé)確定產(chǎn)品發(fā)布計劃定義產(chǎn)品需求并確定優(yōu)先級驗收迭代結(jié)果，并根據(jù)驗收結(jié)果和需求變化刷新需求清單和優(yōu)先級除了客戶需求之外，內(nèi)部任務(wù)如重構(gòu)、持續(xù)集成環(huán)境搭建等也由PO納入統(tǒng)一管理ScrumMaster（Scrum教練）確保Team正確地做事輔導(dǎo)團(tuán)隊正確應(yīng)用敏捷實踐引導(dǎo)團(tuán)隊建立并遵守規(guī)則保護(hù)團(tuán)隊不受打擾推動解決團(tuán)隊遇到的障礙激勵團(tuán)隊不命令和控制TeamTeam（開發(fā)團(tuán)隊）負(fù)責(zé)產(chǎn)品需求實現(xiàn)負(fù)責(zé)估計工作量并根據(jù)自身能力找出最佳方案去完成任務(wù)且保證交付質(zhì)量向PO和利益相關(guān)人演示工作成果（可運行的軟件）團(tuán)隊自我管理、持續(xù)改進(jìn)一般由5-9名跨功能領(lǐng)域人員組成坐在一起工作有共同的目標(biāo)，共擔(dān)責(zé)任團(tuán)隊成員嚴(yán)格遵守團(tuán)隊規(guī)則Page37什么是完整團(tuán)隊敏捷開發(fā)中，以Story為單位的持續(xù)交付要求系統(tǒng)組、開發(fā)和測試等跨功能團(tuán)隊進(jìn)行密切協(xié)同，相互獨立的功能團(tuán)隊難以應(yīng)對。完整團(tuán)隊是跨功能領(lǐng)域（需求分析師、設(shè)計師、開發(fā)人員、測試人員、資料人員等）的人員組成一個團(tuán)隊，坐在一起工作，團(tuán)隊成員遵循同一份計劃，服從于同一個項目經(jīng)理。完整團(tuán)隊的好處有助于團(tuán)隊成員形成共同目標(biāo)和全局意識，促進(jìn)各功能領(lǐng)域的拉通和融合；通過面對面溝通提升溝通效率。實現(xiàn)團(tuán)隊成員的高度協(xié)同，支撐高密度地、持續(xù)地、短周期的交付。完整團(tuán)隊的關(guān)鍵要點成員來自多功能領(lǐng)域：團(tuán)隊擁有完成目標(biāo)所需的各職能成員；坐在一起辦公：團(tuán)隊成員無障礙地溝通；團(tuán)隊保持相對穩(wěn)定：臨時組建的團(tuán)隊生產(chǎn)效率較低，團(tuán)隊穩(wěn)定非常關(guān)鍵。完整團(tuán)隊聚焦客戶需求交付，提高協(xié)作效率敏捷團(tuán)隊實踐：完整團(tuán)隊Page38產(chǎn)品Backlog關(guān)鍵要點清楚表述列表中每個需求任務(wù)對用戶帶來的價值，做為優(yōu)先級排序的重要參考；動態(tài)的需求管理而非“凍結(jié)”方式，PO持續(xù)地管理和及時刷新需求清單，在每輪迭代前，都要重新篩選出高優(yōu)先級需求進(jìn)入本輪迭代；迭代的需求分析過程，而非一次性分析清楚所有需求（只對近期迭代要做的需求進(jìn)行詳細(xì)分析，其它需求停留在粗粒度）。敏捷工作件：產(chǎn)品Backlog什么是產(chǎn)品Backlog經(jīng)過優(yōu)先級排序的動態(tài)刷新的產(chǎn)品需求清單，用來制定發(fā)布計劃和迭代計劃。產(chǎn)品Backlog的好處通過需求的動態(tài)管理應(yīng)對變化，避免浪費；易于優(yōu)先交付對用戶價值高的需求。產(chǎn)品Backlog是需求動態(tài)管理的載體Page39什么是迭代Backlog迭代Backlog是團(tuán)隊在一輪迭代中的“任務(wù)”（Task）清單，是團(tuán)隊的詳細(xì)迭代開發(fā)計劃；當(dāng)團(tuán)隊接收從產(chǎn)品Backlog挑選出要在本輪迭代實現(xiàn)的需求時，召開團(tuán)隊迭代計劃會議，將需求轉(zhuǎn)化為具體的“任務(wù)”；每項任務(wù)信息包括當(dāng)前剩余工作量和責(zé)任人。敏捷工作件：迭代Backlog迭代Backlog的好處將需求分解成更細(xì)小的任務(wù)，利于對迭代內(nèi)進(jìn)度進(jìn)行精確控制；剩余工作量可用來實時跟蹤團(tuán)隊當(dāng)前進(jìn)展。迭代Backlog關(guān)鍵要點“任務(wù)”由團(tuán)隊成員自己分解和定義，而不是上級指派，支撐需求完成的所有工作都可以列為任務(wù)；任務(wù)要落實到具體的責(zé)任人；任務(wù)粒度要小，工作量大于兩天的任務(wù)要進(jìn)一步分解；用小時做為任務(wù)剩余工作量的估計單位，并每日重估計和刷新。迭代Backlog提供精細(xì)的迭代開發(fā)計劃任務(wù)責(zé)任人狀態(tài)剩余工時日期Page40敏捷工作件：完成標(biāo)準(zhǔn)（DefinitionofDone）什么是完成標(biāo)準(zhǔn)基于“隨時可向用戶發(fā)布”的目標(biāo)制定衡量團(tuán)隊工作是否已完成的標(biāo)準(zhǔn)，由團(tuán)隊和PO形成共識；完成標(biāo)準(zhǔn)的好處共同協(xié)商的完成標(biāo)準(zhǔn)是團(tuán)隊的自我承諾，團(tuán)隊會更認(rèn)真；用于準(zhǔn)確評估團(tuán)隊工作進(jìn)展；清晰和明確的完成標(biāo)準(zhǔn)保證了每次迭代是高質(zhì)量的。完成標(biāo)準(zhǔn)的關(guān)鍵要點團(tuán)隊自協(xié)商：團(tuán)隊根據(jù)項目實際情況來定義完成標(biāo)準(zhǔn)，并嚴(yán)格遵守；有層次：一般分為三個層次：Story級別，迭代級和發(fā)布級，每個級別都有各自的完成標(biāo)準(zhǔn)。Story完成標(biāo)準(zhǔn)樣例迭代完成標(biāo)準(zhǔn)樣例發(fā)布完成標(biāo)準(zhǔn)樣例代碼合入主干代碼符合規(guī)范代碼100%檢視通過驗收測試通過迭代驗收系統(tǒng)測試用例100%通過通過性能測試所有Story完成通過回歸測試所有缺陷解決更新配套資料完成標(biāo)準(zhǔn)的樣例代碼100%通過單元測試持續(xù)集成無錯誤完成標(biāo)準(zhǔn)確保團(tuán)隊每一步前進(jìn)都奠定在堅實的質(zhì)量基礎(chǔ)之上Page41敏捷管理實踐：迭代計劃會議什么是迭代計劃會議每輪迭代啟動前，團(tuán)隊共同討論本輪迭代詳細(xì)開發(fā)計劃的過程，輸入是產(chǎn)品Backlog，輸出是團(tuán)隊迭代Backlog；多團(tuán)隊迭代計劃會議要分層召開版本迭代計劃會議：將產(chǎn)品Backlog（需求）分配給團(tuán)隊；團(tuán)隊迭代計劃會議：將選取的產(chǎn)品Backlog需求轉(zhuǎn)換成迭代Backlog（任務(wù)），分配給團(tuán)隊成員；迭代計劃會議內(nèi)容：澄清需求、對“完成標(biāo)準(zhǔn)”達(dá)成一致工作量估計、根據(jù)團(tuán)隊能力確定本輪迭代交付內(nèi)容；細(xì)化、分配迭代任務(wù)和初始工作計劃。迭代計劃會議的好處通過充分討論，使團(tuán)隊成員對任務(wù)和完成標(biāo)準(zhǔn)理解一致；團(tuán)隊共同參與，促進(jìn)團(tuán)隊成員更認(rèn)真對待自己的承偌。迭代計劃會議的關(guān)鍵要點充分參與：ScrumMaster確保PO和Team充分參與討論，達(dá)成理解一致；相互承諾：Team承諾完成迭代Backlog中的需求并達(dá)到”完成標(biāo)準(zhǔn)“，PO承諾在短迭代周期不增加需求（2-4周）；確定內(nèi)部任務(wù)：Team和PO協(xié)商把一些內(nèi)部任務(wù)放入迭代中（例如重構(gòu)、持續(xù)集成環(huán)境搭建等），由PO考慮并與其他外部需求一起排序。迭代計劃會議由團(tuán)隊共同確定迭代交付內(nèi)容和完成標(biāo)準(zhǔn)Page42敏捷管理實踐：每日站立會議什么是每日站立會議每日工作前，團(tuán)隊成員的例行溝通機(jī)制，由ScrumMaster組織，Team成員全體站立參加聚焦在下面的三個主題：我昨天為本項目做了什么？我計劃今天為本項目做什么？我需要什么幫助以更高效的工作？每日站立會議的關(guān)鍵要點準(zhǔn)時開始：按計劃會議制定的時間地點開會，形成團(tuán)隊成員的自然習(xí)慣；高效會議：會議限時15分鐘，每個人都保持站立，依次發(fā)言，不討論與會議三個主題無關(guān)的事情（如技術(shù)解決方案等）；問題跟蹤：ScrumMaster應(yīng)該記錄下所有的問題并跟蹤解決；每日站立會議的好處增加團(tuán)隊凝聚力，產(chǎn)生積極的工作氛圍及時暴露風(fēng)險和問題；促進(jìn)團(tuán)隊內(nèi)成員的溝通和協(xié)調(diào)。每日站立會議促進(jìn)團(tuán)隊溝通協(xié)調(diào)，及時暴露問題Page43敏捷管理實踐：可視化管理可視化管理的好處簡單，一目了然，降低管理成本；實時狀態(tài)顯示，及時暴露問題；信息同源使團(tuán)隊理解一致，提升團(tuán)隊凝聚力；激勵先進(jìn)，鞭策后進(jìn)，增強(qiáng)團(tuán)隊進(jìn)取心。什么是可視化管理將項目狀態(tài)(進(jìn)度、質(zhì)量等)通過物理實體（如白板，大屏幕）實時展示，讓團(tuán)隊所有成員直觀地獲取當(dāng)前項目進(jìn)展信息。可視化管理的關(guān)鍵要點物理實體：可視化一定要做到物理上的實體化，大家在公開場所都容易看到，觸摸到，（存在電腦中的文件不是可視化的）；內(nèi)容精簡，易懂：信息展示一目了然，切實對團(tuán)隊有幫助，切忌貪多求全，難以分辨；實時刷新：延遲的信息拖延問題暴露，降低運作效率?？梢暬芾砑皶r暴露問題，激勵團(tuán)隊Story墻（展示Story進(jìn)度）缺陷走勢圖（展示缺陷解決進(jìn)展）Anatomy視圖（展示系統(tǒng)集成進(jìn)展）Page44敏捷管理實踐：迭代驗收什么是迭代驗收每次迭代開發(fā)結(jié)束時舉行，通過演示可工作的軟件檢查需求是否滿足客戶要求；由Scrum

Master組織，PO和用戶代表（外部或內(nèi)部利益相關(guān)人）負(fù)責(zé)驗收、Team負(fù)責(zé)演示可工作軟件。迭代驗收的好處通過演示可工作的軟件來確認(rèn)項目的進(jìn)度，具有真實性；能盡早的獲得用戶對產(chǎn)品的反饋，使產(chǎn)品更加貼近客戶需求。迭代驗收的關(guān)鍵要點展示“真實”的產(chǎn)品：Team應(yīng)在真實環(huán)境中展示可運行的軟件，判斷是否達(dá)到“完成”標(biāo)準(zhǔn)；收集反饋：PO根據(jù)驗收情況及客戶反饋意見，及時調(diào)整產(chǎn)品Backlog。迭代驗收盡早演示可工作的軟件，收集反饋意見Page45敏捷管理實踐：迭代回顧會議迭代回顧會議的好處激勵團(tuán)隊成員；幫助團(tuán)隊挖掘優(yōu)秀經(jīng)驗并繼承；避免團(tuán)隊犯重復(fù)的錯誤；營造團(tuán)隊自主改進(jìn)的氛圍。什么是迭代回顧會議在每輪迭代結(jié)束后舉行的會議，目的是分享好的經(jīng)驗和發(fā)現(xiàn)改進(jìn)點，促進(jìn)團(tuán)隊不斷進(jìn)步；圍繞如下三個問題：本次迭代有哪些做得好本次迭代我們在哪些方面還能做得更好我們在下次迭代準(zhǔn)備在哪些方面改進(jìn)？迭代回顧會議的關(guān)鍵要點會議氣氛：Team全員參加，氣氛寬松自由，暢所欲言，頭腦風(fēng)暴發(fā)現(xiàn)問題，共同分析根因；關(guān)注重點：Team共同討論優(yōu)先級，將精力放在最需要的地方（關(guān)注幾個改進(jìn)就夠了）；會議結(jié)論要跟蹤閉環(huán)：可以放入迭代backlog中。迭代回顧會議是促進(jìn)團(tuán)隊持續(xù)改進(jìn)的最有效手段好的能做得更好的將來改進(jìn)的Page46敏捷工程實踐：用戶故事（userstory）什么是用戶故事用戶故事是站在用戶角度描述需求的一種方式；每個用戶故事須有對應(yīng)的驗收測試用例；用戶故事是分層分級的，在使用過程中逐步分解細(xì)化；典型的描述句式為：作為一個XXX客戶角色，我需要XXX功能，帶來XXX好處。用戶故事的好處用戶故事站在用戶視角便于和客戶交流，準(zhǔn)確描述客戶需求；用戶故事可獨立交付單元、規(guī)模小，適于迭代開發(fā)，以獲得用戶快速反饋；用戶故事強(qiáng)調(diào)編寫驗收測試用例作為驗收標(biāo)準(zhǔn)，能促使需求分析人員準(zhǔn)確把握需求，牽引開發(fā)人員避免過度設(shè)計。用戶故事的關(guān)鍵要點I–Independent，可獨立交付給客戶N–Negotiable，便于與客戶交流V-Valuable，對客戶有價值E-Estimable，能估計出工作量S-Small，分解到最底層的用戶故事粒度盡量小，至少在一個迭代中能完成T-Testable，可測試初始需求：1.作為網(wǎng)絡(luò)規(guī)劃人員，我想要配置一個媒體網(wǎng)關(guān)，因為想要增加網(wǎng)絡(luò)容量和服務(wù)初次分解：1.1作為網(wǎng)絡(luò)規(guī)劃人員，我想把媒體網(wǎng)關(guān)參數(shù)上傳到管理系統(tǒng)

1.2作為網(wǎng)絡(luò)規(guī)劃人員，我想從管理系統(tǒng)下載媒體網(wǎng)關(guān)參數(shù)再次分解：1.2.1作為網(wǎng)絡(luò)規(guī)劃人員，我想用文件方式從管理系統(tǒng)下載媒體網(wǎng)關(guān)參數(shù)

用例：用戶在