正確解讀敏捷課件

1、正確解讀敏捷正確解讀敏捷目錄統(tǒng)一敏捷認(rèn)識敏捷理念解讀敏捷實踐解讀Copyright 2011 HiSoft Technology International Limited. All Rights Reserved. Internal2目錄統(tǒng)一敏捷認(rèn)識Copyright 2011 HiSoft Page 3對敏捷的常見誤解誤解一： 敏捷開發(fā)意味著可以不需要文檔、設(shè)計和計劃誤解二： 敏捷只是一些優(yōu)秀實踐，或者是優(yōu)秀實踐的結(jié)合誤解三： 敏捷只適用于小項目開發(fā)誤解四： 敏捷只會對研發(fā)產(chǎn)生改變誤解五： 管理者不需要親自了解敏捷，只需要管理上支持就可以了誤解六： 引入敏捷只需要按照既定的步驟去做就可以了

2、誤解七： 敏捷是CMM的替代品，是另一種流程誤解八： 敏捷只注重特性的快速交付，在敏捷下架構(gòu)不重要了Page 5對敏捷的常見誤解誤解一： 敏捷開發(fā)意味著可以不需Page 4統(tǒng)一認(rèn)識：敏捷=理念+優(yōu)秀實踐+具體應(yīng)用理念優(yōu)秀實踐具體應(yīng)用 理念（敏捷核心思想）敏捷包括3個層次 優(yōu)秀實踐（敏捷的經(jīng)驗積累） 具體應(yīng)用（能夠結(jié)合自身靈活應(yīng)用才是真正敏捷）Page 6統(tǒng)一認(rèn)識：敏捷=理念+優(yōu)秀實踐+具體應(yīng)用理念優(yōu)秀Page 5理念：聚焦客戶價值(Value)，消除浪費“價值”在“敏捷宣言”中的體現(xiàn)產(chǎn)品商業(yè)成功為目標(biāo)，聚焦客戶價值、圍繞價值流消除浪費個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶

3、合作勝過合同談判響應(yīng)變化勝過遵循計劃Page 7理念：聚焦客戶價值(Value)，消除浪費“價值Page 6理念：激發(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)做到提升溝通效率降低交流成本“團(tuán)隊”在“敏捷宣言”中的體現(xiàn)個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃效率流行度文檔錄制的視頻錄制的音頻2人郵件溝通2人白板溝通2人電話溝通不支持問答形式支持問答形式研究表明面對面的溝通最有效 業(yè)界調(diào)查：一個50人開發(fā)團(tuán)隊，每人平均30%時間用于編碼，70%的時間用于與其他成員交流。P

4、age 8理念：激發(fā)團(tuán)隊(Team)潛能，加強(qiáng)協(xié)作團(tuán)隊是價Page 7理念：不斷調(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)變化勝過遵循計劃Page 9理念：不斷調(diào)整以適應(yīng)(Adapting)

5、變化麥當(dāng)Page 8優(yōu)秀實踐: 業(yè)界敏捷優(yōu)秀實踐概覽結(jié)對編程測試驅(qū)動開發(fā)客戶參與驗收計劃游戲代碼集體所有每日站立會議產(chǎn)品backlog（帶優(yōu)先級的需求清單）燃燒圖迭代計劃會議回顧會議Scrum MasterProduct OwnerAnatomy（系統(tǒng)解剖）One TrackSystemakut（缺陷管理和決策）重構(gòu)完整團(tuán)隊穩(wěn)定開發(fā)節(jié)奏Lagomising（需求決策）隱喻電信業(yè)偏重大規(guī)模產(chǎn)品實踐、Scrum偏重項目管理，XP偏重編程實踐電信業(yè)ScrumXP持續(xù)集成迭代交付Page 10優(yōu)秀實踐: 業(yè)界敏捷優(yōu)秀實踐概覽結(jié)對編程測試驅(qū)Page 9開發(fā)團(tuán)隊一具體應(yīng)用：因地制宜選擇適合的敏捷實踐團(tuán)隊在

6、透徹理解敏捷理念的基礎(chǔ)上，可以靈活選擇最適合自己的實踐，避免教條化站立會議排序的工作列表持續(xù)集成持續(xù)集成重構(gòu)持續(xù)集成結(jié)對編程迭代開發(fā)+迭代開發(fā)+開發(fā)團(tuán)隊三敏捷理念開發(fā)團(tuán)隊二敏捷理念敏捷理念Page 11開發(fā)團(tuán)隊一具體應(yīng)用：因地制宜選擇適合的敏捷實踐Page 10敏捷轉(zhuǎn)型是系統(tǒng)性工程敏捷轉(zhuǎn)型7個方面優(yōu)先級Source：Cutter Agile Transformation（Jim Highsmith大師）敏捷轉(zhuǎn)型是系統(tǒng)工程，覆蓋7個方面：實踐、績效考核、組織、過程、文化、管控、技術(shù)和業(yè)務(wù)對齊敏捷在敏捷轉(zhuǎn)型不同階段，敏捷轉(zhuǎn)型框架的7個方面引入的優(yōu)先級不一樣，初期以實踐為主Wave3 (企業(yè)級）Wa

7、ve2 (產(chǎn)品級)Wave1(項目級)2121334Stage522Alignment1112Culture13Governance22Performance212Process1122Organization3211PracticesStage4Stage3Stage2Stage1Numbers represent typical relative importance at each stage.實踐績效組織過程文化管控技術(shù)和業(yè)務(wù)對齊敏捷轉(zhuǎn)型框架Page 12敏捷轉(zhuǎn)型是系統(tǒng)性工程敏捷轉(zhuǎn)型7個方面優(yōu)先級So目錄統(tǒng)一敏捷認(rèn)識敏捷理念解讀敏捷實踐解讀Copyright 2011 HiSoft T

8、echnology International Limited. All Rights Reserved. Internal11目錄統(tǒng)一敏捷認(rèn)識Copyright 2011 HiSoft Page 12深入理解敏捷理念 深入理解“適應(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)Pag

9、e 14深入理解敏捷理念 深入理解“適應(yīng)變化” 深Page 13浪費類別浪費舉例1部分完成的工作部分完成但沒有最終落地的工作（沒有轉(zhuǎn)化成代碼的設(shè)計文檔；未及時合入的代碼導(dǎo)致引發(fā)后續(xù)更多同步工作量）。2未應(yīng)用特性開發(fā)完成但沒有被客戶應(yīng)用的特性（交換機(jī)2000多個功能客戶只用了1%）。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任

10、務(wù)切換研究表明多任務(wù)工作會導(dǎo)致效率下降20%-40%（員工多頭工作或雜事繁多）。6延遲因任務(wù)或資源相互依賴而導(dǎo)致工作停滯（集成時被關(guān)鍵模塊阻塞，等待測試環(huán)境就緒）。7缺陷解決缺陷活動本身就是浪費，而且缺陷越遺留到后端浪費越大。聚焦客戶價值，標(biāo)識和消除軟件開發(fā)中的浪費Source：精益軟件開發(fā)Page 15浪費類別浪費舉例1部分完成的工作部分完成但沒有Page 14當(dāng)質(zhì)量、進(jìn)度、資源沖突時，能改變的只有項目范圍，即選擇“交付剛剛好的系統(tǒng)”產(chǎn)品交付前，客戶往往期望多而全的功能，產(chǎn)品交付后，客戶把穩(wěn)定的質(zhì)量放在首位，尤其在電信領(lǐng)域，客戶對產(chǎn)品質(zhì)量要求是Always work，不是Sometimes。

11、與其為了滿足多而全的功能導(dǎo)致交付延遲，質(zhì)量不穩(wěn)定，不如按時交付剛剛好的系統(tǒng)，保證其高質(zhì)量運行。交付剛剛好的系統(tǒng)，基于對客戶需求的深入理解，并花時間了解細(xì)節(jié)，簡化（simplify）需求（降低復(fù)雜性）而不是簡單地拒絕需求（delete）。做到“交付剛剛好的系統(tǒng)”，同時需要管理者有足夠的勇氣和果斷決策聚焦客戶價值，交付剛剛好的系統(tǒng)在項目明顯超負(fù)荷時，管理者簡單地期望靠團(tuán)隊work harder來解決，最終導(dǎo)致：質(zhì)量下降項目延期客戶不滿意團(tuán)隊疲勞埋下長期隱患Page 16當(dāng)質(zhì)量、進(jìn)度、資源沖突時，能改變的只有項目范圍Page 15缺陷遺留帶來高額成本：對單獨質(zhì)量保證活動（如后端測試）的依賴，容易形成

12、缺陷可以遺留到下個階段的心理，導(dǎo)致缺陷發(fā)現(xiàn)成本升高（系統(tǒng)測試階段缺陷定位和解決成本是開發(fā)階段的10倍）例1：E公司開發(fā)階段和測試階段發(fā)現(xiàn)缺陷的比例為7：3，而我司大量缺陷集中在后端發(fā)現(xiàn)，帶來高額成本。例2：我司顧問指出：華為測試和開發(fā)“相隔1000英里”。聚焦客戶價值，隨時構(gòu)建質(zhì)量，不容忍缺陷 從項目一開始就隨時構(gòu)建質(zhì)量：形成零缺陷文化，不要容忍缺陷：發(fā)現(xiàn)缺陷應(yīng)立即停下來解決，以保證在堅實的質(zhì)量基礎(chǔ)上前行。開發(fā)和測試緊密協(xié)作：測試人員參與到設(shè)計和開發(fā)過程中，共同預(yù)防缺陷的產(chǎn)生。例如：持續(xù)集成暴露的問題需立即解決Page 17缺陷遺留帶來高額成本：聚焦客戶價值，隨時構(gòu)建質(zhì)Page 16聚焦客戶價

13、值，及時消除技術(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)檢查告警等。Page 18聚焦客戶價值，及時消除技術(shù)債務(wù)，持續(xù)保持快速響Page 17

14、激發(fā)團(tuán)隊，認(rèn)清團(tuán)隊的基本事實Source: Jeff CSM Training material信任是高績效團(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)品更健壯Page 19激發(fā)團(tuán)隊，認(rèn)清團(tuán)隊的基本事實Source: JPage 18激發(fā)團(tuán)

15、隊，敏捷方式下管理者的轉(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é)會放松”控制”(loose control)傳統(tǒng)方式敏捷方式Page 20激發(fā)團(tuán)隊，敏捷方式下管理者的轉(zhuǎn)變管理者努力“控Page 19激發(fā)團(tuán)隊，敏捷方式下團(tuán)隊成員的轉(zhuǎn)變團(tuán)隊成員是“聽從安排的獨立貢獻(xiàn)者”:被動等待主管下指令安排工作獨立工作為主，協(xié)作少以文檔和郵件為主要溝通方

16、式只關(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)方式敏捷方式Page 21激發(fā)團(tuán)隊，敏捷方式下團(tuán)隊成員的轉(zhuǎn)變團(tuán)隊成員是“Page 20殘酷現(xiàn)實客戶是逐步發(fā)現(xiàn)他真正要的東西開發(fā)人員逐步發(fā)現(xiàn)如何開發(fā)產(chǎn)品滿足客戶需求在這個過程中隨時可能發(fā)生變化美好愿望客戶知道自己要的是什么開發(fā)人員知道如何開發(fā)來滿足客戶需求在開發(fā)過程中需求不會發(fā)生變化期望客戶一開始就想清楚

17、他們真正要的東西是不現(xiàn)實的。我們應(yīng)當(dāng)通過不斷的向客戶交付可用的產(chǎn)品，啟發(fā)客戶逐步的發(fā)現(xiàn)真正的需求。我們認(rèn)識到預(yù)期需求實際需求價值時間適應(yīng)變化，認(rèn)清“客戶是逐步發(fā)現(xiàn)真正需求”Page 22殘酷現(xiàn)實美好愿望期望客戶一開始就想清楚他們真正Page 21適應(yīng)變化，小批量是快速交付的關(guān)鍵我們首先要做的是通過盡早地、持續(xù)地交付有價值的軟件來使客戶滿意。經(jīng)常性的交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。 摘自敏捷軟件的十二個原則在需求響應(yīng)周期相同的情況下，批量（一次開發(fā)的需求量）越小，資源利用率更高。在資源利用率相同的情況下，批量越小，交付周期更短。減小批量不僅帶來縮短交

18、付周期，而且還帶來提高質(zhì)量、促進(jìn)創(chuàng)新、降低管理成本、更高的效率等其他好處，大幅提升商業(yè)價值。減少批量的好處資源利用率交付周期大批量中批量小批量Source：Craig Larman減小批量1.減少排隊3.縮短交付周期2.加快反饋4.增強(qiáng)質(zhì)量5.改善創(chuàng)新6.降低管理成本7.更高的效率$排隊理論：小批量與縮短交付周期、人員有效產(chǎn)出的關(guān)系Page 23適應(yīng)變化，小批量是快速交付的關(guān)鍵我們首先要做的Page 22適應(yīng)變化，通過迭代計劃不斷調(diào)整以適應(yīng)需求變化正確做計劃方法在每一輪迭代開始，只詳細(xì)確定本次迭代的工作內(nèi)容，并嚴(yán)格執(zhí)行，對后續(xù)較遠(yuǎn)的迭代內(nèi)容只做粗略的計劃，避免浪費。項目范圍常發(fā)生變化需求出現(xiàn)了

19、增加、刪除、優(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ì)化Page 24適應(yīng)變化，通過迭代計劃不斷調(diào)整以適應(yīng)需求變化正Page 23適應(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)會阻礙敏捷；

20、良好架構(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)保持生命力。Page 25適應(yīng)變化，應(yīng)持續(xù)保持良好的軟件架構(gòu)良好軟件架構(gòu)Page 24適應(yīng)變化，利用多層次反饋不斷調(diào)整以逼近目標(biāo)結(jié)對編程單元測試持續(xù)集成站立會議/回顧會議客戶驗收對代碼質(zhì)量的反饋 對單元功能的反饋 對團(tuán)隊運作的反饋對系統(tǒng)功能的反饋 對客戶需求的反饋利用多層次反饋手段，在變化的環(huán)境中

21、讓團(tuán)隊準(zhǔn)確地了解與目標(biāo)的差距，不斷調(diào)整自身行為，并逐步逼近靶心多層次反饋手段Page 26適應(yīng)變化，利用多層次反饋不斷調(diào)整以逼近目標(biāo)結(jié)對目錄統(tǒng)一敏捷認(rèn)識敏捷理念解讀敏捷實踐解讀Copyright 2011 HiSoft Technology International Limited. All Rights Reserved. Internal25目錄統(tǒng)一敏捷認(rèn)識Copyright 2011 HiSoft 敏捷管理實踐：一體化辦公Copyright 2011 HiSoft Technology International Limited. All Rights Reserved. Intern

22、al26所有的團(tuán)隊成員，包括開發(fā)人員、SE、測試人員都圍繞同一張桌子坐下，他們在一起工作、討論、保持良好的溝通。敏捷管理實踐：一體化辦公Copyright 2011 HiSPage 27敏捷工程實踐：用戶故事（user story）什么是用戶故事用戶故事是站在用戶角度描述需求的一種方式；每個用戶故事須有對應(yīng)的驗收測試用例；用戶故事是分層分級的，在使用過程中逐步分解細(xì)化；典型的描述句式為：作為一個XXX客戶角色，我需要XXX功能，帶來XXX好處。用戶故事的好處用戶故事站在用戶視角便于和客戶交流，準(zhǔn)確描述客戶需求；用戶故事可獨立交付單元、規(guī)模小，適于迭代開發(fā)，以獲得用戶快速反饋；用戶故事強(qiáng)調(diào)編寫驗

23、收測試用例作為驗收標(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

24、.1作為網(wǎng)絡(luò)規(guī)劃人員，我想用文件方式從管理系統(tǒng)下載媒體網(wǎng)關(guān)參數(shù)用例：用戶在管理系統(tǒng)上選擇以文件方式下載媒體網(wǎng)關(guān)參數(shù)，執(zhí)行成功后，檢查文件是否正確下載到本地且內(nèi)容正確1.2.2作為網(wǎng)絡(luò)規(guī)劃人員，我想用MML結(jié)構(gòu)方式從管理系統(tǒng)下載媒體網(wǎng)關(guān)的參數(shù)用例:故事樣例用戶故事便于團(tuán)隊站在用戶角度分解細(xì)化需求并制定驗收標(biāo)準(zhǔn)Page 29敏捷工程實踐：用戶故事（user story）Page 28敏捷管理實踐：每日站立會議什么是每日站立會議每日工作前，團(tuán)隊成員的例行溝通機(jī)制，由Scrum Master組織，Team成員全體站立參加聚焦在下面的三個主題：我昨天為本項目做了什么？我計劃今天為本項目做什么？我需要什么

25、幫助以更高效的工作？每日站立會議的關(guān)鍵要點準(zhǔn)時開始：按計劃會議制定的時間地點開會，形成團(tuán)隊成員的自然習(xí)慣；高效會議：會議限時15分鐘，每個人都保持站立，依次發(fā)言，不討論與會議三個主題無關(guān)的事情（如技術(shù)解決方案等）；問題跟蹤：Scrum Master應(yīng)該記錄下所有的問題并跟蹤解決；每日站立會議的好處增加團(tuán)隊凝聚力，產(chǎn)生積極的工作氛圍及時暴露風(fēng)險和問題；促進(jìn)團(tuán)隊內(nèi)成員的溝通和協(xié)調(diào)。每日站立會議促進(jìn)團(tuán)隊溝通協(xié)調(diào)，及時暴露問題Page 30敏捷管理實踐：每日站立會議什么是每日站立會議每Page 29敏捷管理實踐：可視化管理可視化管理的好處簡單，一目了然 ，降低管理成本；實時狀態(tài)顯示，及時暴露問題；信息

26、同源使團(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)展信息?？梢暬芾淼年P(guān)鍵要點物理實體：可視化一定要做到物理上的實體化，大家在公開場所都容易看到，觸摸到，（存在電腦中的文件不是可視化的）；內(nèi)容精簡，易懂：信息展示一目了然，切實對團(tuán)隊有幫助，切忌貪多求全，難以分辨；實時刷新：延遲的信息拖延問題暴露，降低運作效率。可視化管理及時暴露問題，激勵團(tuán)隊Story墻（展示Story進(jìn)度）缺陷走勢圖（展示缺陷解決進(jìn)展）Anatomy視圖（展示系統(tǒng)集成進(jìn)展）Page 31

27、敏捷管理實踐：可視化管理可視化管理的好處什么是Page 30敏捷工程實踐：結(jié)對編程什么是結(jié)對編程兩位程序員在一臺電腦前工作，一個負(fù)責(zé)敲入代碼，而另外一個實時檢視每一行敲入的代碼；操作鍵盤和鼠標(biāo)的程序員被稱為“駕駛員”，負(fù)責(zé)實時評審和協(xié)助的程序員被稱為“領(lǐng)航員”；領(lǐng)航員檢視的同時還必須負(fù)責(zé)考慮下一步的工作方向 ，比如可能出現(xiàn)的問題以及改進(jìn)等。結(jié)對編程的好處有助于提升代碼設(shè)計質(zhì)量；研究表明結(jié)對生產(chǎn)率比兩個單人總和低 15%，但缺陷數(shù)少 15%，考慮修改缺陷工作量和時間都比初始編程大幾倍，所以結(jié)對編程總體效率更高（source: The Economist）；結(jié)對編程能夠大幅促進(jìn)團(tuán)隊能力提升和知識傳

28、播。結(jié)對編程的關(guān)鍵要點程序員應(yīng)經(jīng)常性地在“駕駛員”和“領(lǐng)航員”間切換，保持成員間平等協(xié)商和相互理解，避免出現(xiàn)一個角色支配另一個角色的現(xiàn)象；開始一個新Story開發(fā)的時候即可變換搭檔，以增進(jìn)知識傳播；培養(yǎng)團(tuán)隊成員積極、主動、開放、協(xié)作的心態(tài)能夠增進(jìn)結(jié)對編程效果；實施初期需要精心輔導(dǎo)，幫助團(tuán)隊成員克服個性沖突和習(xí)慣差異。結(jié)對編程提高代碼質(zhì)量和工作效率Page 32敏捷工程實踐：結(jié)對編程什么是結(jié)對編程結(jié)對編程的Page 31敏捷管理實踐：迭代驗收什么是迭代驗收每次迭代開發(fā)結(jié)束時舉行，通過演示可工作的軟件檢查需求是否滿足客戶要求；由Scrum Master組織， PO和用戶代表（外部或內(nèi)部利益相關(guān)人）

29、負(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。迭代驗收盡早演示可工作的軟件，收集反饋意見Page 33敏捷管理實踐：迭代驗收什么是迭代驗收迭代驗收的Page 32敏捷管理實踐：迭代回顧會議迭代回顧會議的好處激勵團(tuán)隊成員；幫助團(tuán)隊挖掘優(yōu)秀經(jīng)驗并繼承；避免團(tuán)隊犯重復(fù)的錯誤；營造團(tuán)隊自主改進(jìn)的氛圍。什么是迭代回顧會議

30、在每輪迭代結(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)的Page 34敏捷管理實踐：迭代回顧會議迭代回顧會議的好處什Page 33敏捷工程實踐：持續(xù)集成(CI)什么是持續(xù)集成持續(xù)集成（CI）是一項軟件開發(fā)實踐，其中