《敏捷開發(fā)介紹》ppt課件

1、PSST質(zhì)量與成本管理部/系統(tǒng)工程部,華為敏捷軟件開發(fā)解讀,,2009年06月 N.001,Page 2,關(guān)于管理者和軟件開發(fā)相關(guān)人員掌握敏捷知識(shí)的要求 為落實(shí)敏捷軟件開發(fā)在我司的順利推行，使廣大軟件開發(fā)管理者和開發(fā)人員深刻領(lǐng)會(huì)敏捷核心理念，熟練掌握敏捷實(shí)踐方法，從而達(dá)到增強(qiáng)應(yīng)對(duì)需求變化的能力、提高產(chǎn)品質(zhì)量、提升開發(fā)效率和縮短交付周期等方面的目標(biāo)。為此，特提出如下要求：PM及以上管理者要深刻領(lǐng)會(huì)敏捷核心理念

2、、理解我司敏捷推行策略、了解各種敏捷實(shí)踐。軟件開發(fā)相關(guān)人員（含PL、軟件開發(fā)人員、軟件測(cè)試人員、軟件架構(gòu)人員、系統(tǒng)分析人員、與軟件相關(guān)的資料人員和研發(fā)質(zhì)量人員）要深刻理解敏捷理念、掌握敏捷實(shí)踐、了解我司敏捷推行策略。通過敏捷相關(guān)知識(shí)的考試是軟件開發(fā)相關(guān)人員任職資格的基本要求。考試試題分為管理者版本和員工版本，分別針對(duì)管理者和員工應(yīng)知應(yīng)會(huì)的知識(shí)進(jìn)行考試。敏捷學(xué)習(xí)參考材料包括：《華為敏捷開發(fā)解讀》及相關(guān)附件。,目錄,敏捷概述正確理解

3、敏捷我司敏捷開發(fā)實(shí)施策略我司敏捷案例,Page 4,,,業(yè)界敏捷浪潮,ISO 9000（09版）標(biāo)準(zhǔn)將在原來八大原則的基礎(chǔ)上新增敏捷原則2000年美國軍方軟件開發(fā)標(biāo)準(zhǔn)（DOD 5000.2）推薦迭代為軟件開發(fā)優(yōu)選模式世界影響最大的美國波多里奇國家質(zhì)量獎(jiǎng)將敏捷作為核心的十一大原則之一,Page 5,,,,軟件作坊,軟件過程控制,重型過程,2001~今 敏捷正在流行,,軟件規(guī)模小，以作坊式開發(fā)為主；硬件飛速發(fā)展，軟件規(guī)模和

4、復(fù)雜度激增，引發(fā)軟件危機(jī)；引入成熟生產(chǎn)制造管理方法，以“過程為中心”分階段來控制軟件開發(fā)（瀑布模型），一定程度上緩解了軟件危機(jī)；軟件失敗的經(jīng)驗(yàn)促使過程被不斷增加約束和限制，軟件開發(fā)過程日益“重型化”，開發(fā)效率降低、響應(yīng)速度變慢；隨著信息時(shí)代到來，需求變化更快，交付周期成為企業(yè)核心競爭力，輕量級(jí)的，更能適應(yīng)變化的敏捷軟件開發(fā)方法被普遍認(rèn)可并迅速流行。,軟件危機(jī),20世紀(jì)60年代,80年代,90年代,軟件開發(fā)順應(yīng)時(shí)代變化，從

5、重型過程轉(zhuǎn)向輕量型敏捷,70年代,敏捷誕生的歷史背景,,,,,,,,Page 6,,敏捷宣言揭示更好的軟件開發(fā)方法,敏捷宣言（ 2001年）是敏捷起源的基礎(chǔ)，由上述4個(gè)簡單的價(jià)值觀組成，敏捷宣言的簽署推動(dòng)了敏捷運(yùn)動(dòng)敏捷宣言本質(zhì)是揭示一種更好的軟件開發(fā)方式，啟迪人們重新思考軟件開發(fā)中的價(jià)值和如何更好的工作,,敏捷宣言,Page 7,,,,軟件更像一個(gè)活著的植物，軟件開發(fā)是自底向上逐步有序的生長過程，類似于植物自然生長敏捷開發(fā)遵循軟件客

6、觀規(guī)律，不斷的進(jìn)行迭代增量開發(fā)，最終交付符合客戶價(jià)值的產(chǎn)品,傳統(tǒng)開發(fā),敏捷開發(fā),敏捷更符合軟件開發(fā)規(guī)律,Page 8,敏捷對(duì)生產(chǎn)率、質(zhì)量、滿意度、成本有明顯改進(jìn),82%的項(xiàng)目生產(chǎn)率有提高,78%的項(xiàng)目質(zhì)量有提高,78%的項(xiàng)目客戶滿意度有提高,37%的項(xiàng)目成本有降低,* 以上數(shù)據(jù)來自DDJ 2008由Scott Ambler發(fā)起的網(wǎng)上調(diào)查結(jié)果,目錄,敏捷概述正確理解敏捷統(tǒng)一敏捷認(rèn)識(shí)敏捷理念解讀敏捷實(shí)踐解讀我司敏捷開發(fā)實(shí)施策略我

7、司敏捷案例,Page 10,,對(duì)敏捷的常見誤解,誤解一： 敏捷開發(fā)意味著可以不需要文檔、設(shè)計(jì)和計(jì)劃誤解二： 敏捷只是一些優(yōu)秀實(shí)踐，或者是優(yōu)秀實(shí)踐的結(jié)合誤解三： 敏捷只適用于小項(xiàng)目開發(fā)誤解四： 敏捷只會(huì)對(duì)研發(fā)產(chǎn)生改變誤解五： 管理者不需要親自了解敏捷，只需要管理上支持就可以了誤解六： 引入敏捷只需要按照既定的步驟去做就可以了誤解七： 敏捷是CMM的替代品，是另一種流程誤解八： 敏捷只注重特性的快速交付，在敏捷下架構(gòu)不重要了,

8、Page 11,,,,統(tǒng)一認(rèn)識(shí)：敏捷=理念+優(yōu)秀實(shí)踐+具體應(yīng)用,理念,優(yōu)秀實(shí)踐,具體應(yīng)用,理念（敏捷核心思想）敏捷包括3個(gè)層次 優(yōu)秀實(shí)踐（敏捷的經(jīng)驗(yàn)積累） 具體應(yīng)用（能夠結(jié)合自身靈活應(yīng)用才是真正敏捷）,,,Page 12,,理念：聚焦客戶價(jià)值(Value)，消除浪費(fèi),軟件業(yè)：45%的軟件特性客戶沒有使用,Source：Standish Group 來自5萬個(gè)軟件開發(fā)項(xiàng)目的調(diào)查,Source：中國

9、電信總工韋樂平在《華為公司工程與技術(shù)大會(huì)》上的講話,Source：《如何提升軟件開發(fā)效率》08年統(tǒng)計(jì),電信業(yè)：“電信級(jí)”帶來的浪費(fèi),“價(jià)值”在“敏捷宣言”中的體現(xiàn),產(chǎn)品商業(yè)成功為目標(biāo)，聚焦客戶價(jià)值、圍繞價(jià)值流消除浪費(fèi),我司：研發(fā)版本廢棄特性,07.1-08.6年某產(chǎn)品線所有產(chǎn)品中重要特性無應(yīng)用的比例達(dá)22%（需求變更和分析不足占63%）,Page 13,理念：激發(fā)團(tuán)隊(duì)(Team)潛能，加強(qiáng)協(xié)作,我司試點(diǎn)開發(fā)測(cè)試?yán)?，效率質(zhì)量改善明顯,團(tuán)

10、隊(duì)是價(jià)值的真正創(chuàng)造者，應(yīng)加強(qiáng)團(tuán)隊(duì)協(xié)作、激發(fā)團(tuán)隊(duì)潛能軟件開發(fā)是一種團(tuán)隊(duì)活動(dòng)，首先應(yīng)做到提升溝通效率降低交流成本,Source: 08年測(cè)試行業(yè)超過30個(gè)項(xiàng)目試點(diǎn),Source：《經(jīng)濟(jì)學(xué)家2003》& DeMarco 研究報(bào)告,“團(tuán)隊(duì)”在“敏捷宣言”中的體現(xiàn),研究表明面對(duì)面的溝通最有效 業(yè)界調(diào)查：一個(gè)50人開發(fā)團(tuán)隊(duì)，每人平均30%時(shí)間用于編碼，70%的時(shí)間用于與其他成員交流。,研究表明1981年來自不同公司的優(yōu)秀程序員生產(chǎn)率之比

11、是7:1，而2007年最新的研究數(shù)據(jù)，則是40:1。,人是軟件開發(fā)的決定因素,Page 14,理念：不斷調(diào)整以適應(yīng)(Adapting)變化,麥當(dāng)勞是簡單可預(yù)測(cè)生產(chǎn)過程,《人月神話》：軟件開發(fā)是人類最復(fù)雜工作之一，軟件具有四個(gè)屬性：復(fù)雜性、一致性、可變性和不可見性。軟件開發(fā)是不可重復(fù)、探索性的、演進(jìn)的，適應(yīng)性過程。,隨軟件規(guī)模增長，需求變化呈非線性增長,軟件開發(fā)是復(fù)雜不可預(yù)測(cè)的經(jīng)驗(yàn)控制過程,,“適應(yīng)變化”在“敏捷宣言”中的體現(xiàn),不斷的根

12、據(jù)經(jīng)驗(yàn)調(diào)整，最終交付達(dá)到業(yè)務(wù)目標(biāo)的產(chǎn)品,軟件開發(fā)規(guī)律再審視,Page 15,,優(yōu)秀實(shí)踐: 業(yè)界敏捷優(yōu)秀實(shí)踐概覽,結(jié)對(duì)編程,,,測(cè)試驅(qū)動(dòng)開發(fā),客戶參與驗(yàn)收,計(jì)劃游戲,代碼集體所有,每日站立會(huì)議,產(chǎn)品backlog（帶優(yōu)先級(jí)的需求清單）,燃燒圖,迭代計(jì)劃會(huì)議,回顧會(huì)議,Scrum Master,Product Owner,Anatomy（系統(tǒng)解剖）,One Track,Systemakut（缺陷管理和決策）,重構(gòu),完整團(tuán)隊(duì),穩(wěn)定開發(fā)節(jié)奏,

13、Lagomising（需求決策）,隱喻,電信業(yè)偏重大規(guī)模產(chǎn)品實(shí)踐、Scrum偏重項(xiàng)目管理，XP偏重編程實(shí)踐,,,,電信業(yè),Scrum,XP,持續(xù)集成,迭代交付,Page 16,,,開發(fā)團(tuán)隊(duì)一,,具體應(yīng)用：因地制宜選擇適合的敏捷實(shí)踐,團(tuán)隊(duì)在透徹理解敏捷理念的基礎(chǔ)上，可以靈活選擇最適合自己的實(shí)踐，避免教條化,站立會(huì)議,排序的工作列表,持續(xù)集成,持續(xù)集成,重構(gòu),持續(xù)集成,結(jié)對(duì)編程,迭代開發(fā),+,+,迭代開發(fā),+,+,+,+,+,

14、…,+,…,+,…,開發(fā)團(tuán)隊(duì)三,敏捷理念,開發(fā)團(tuán)隊(duì)二,敏捷理念,敏捷理念,Page 17,敏捷轉(zhuǎn)型是系統(tǒng)性工程,敏捷轉(zhuǎn)型7個(gè)方面優(yōu)先級(jí),Source：Cutter Agile Transformation（Jim Highsmith大師）,敏捷轉(zhuǎn)型是系統(tǒng)工程，覆蓋7個(gè)方面：實(shí)踐、績效考核、組織、過程、文化、管控、技術(shù)和業(yè)務(wù)對(duì)齊敏捷在敏捷轉(zhuǎn)型不同階段，敏捷轉(zhuǎn)型框架的7個(gè)方面引入的優(yōu)先級(jí)不一樣，初期以實(shí)踐為主,Numbers repres

15、ent typical relative importance at each stage.,目錄,敏捷概述正確理解敏捷統(tǒng)一認(rèn)識(shí)敏捷敏捷理念解讀敏捷實(shí)踐解讀我司敏捷開發(fā)實(shí)施策略我司敏捷案例,Page 19,深入理解敏捷理念,深入理解“適應(yīng)變化”認(rèn)請(qǐng)“客戶是逐步發(fā)現(xiàn)真正需求”小批量是快速交付的關(guān)鍵通過迭代計(jì)劃不斷調(diào)整以適應(yīng)需求變化應(yīng)持續(xù)保持良好的軟件架構(gòu)利用多層次反饋不斷調(diào)整以逼近目標(biāo),深入理解“激發(fā)團(tuán)隊(duì)”認(rèn)清團(tuán)隊(duì)

16、的基本事實(shí)敏捷方式下管理者的轉(zhuǎn)變敏捷方式下團(tuán)隊(duì)成員的轉(zhuǎn)變,深入理解“聚焦客戶價(jià)值”標(biāo)識(shí)和消除軟件開發(fā)中的浪費(fèi)交付剛剛好的系統(tǒng)隨時(shí)構(gòu)建質(zhì)量，不容忍缺陷及時(shí)消除技術(shù)債務(wù)，持續(xù)保持快速響應(yīng),,Page 20,聚焦客戶價(jià)值，標(biāo)識(shí)和消除軟件開發(fā)中的浪費(fèi),Source：《精益軟件開發(fā)》,,Page 21,,當(dāng)質(zhì)量、進(jìn)度、資源沖突時(shí)，能改變的只有項(xiàng)目范圍，即選擇“交付剛剛好的系統(tǒng)”產(chǎn)品交付前，客戶往往期望多而全的功能，產(chǎn)品交付后，客戶把

17、穩(wěn)定的質(zhì)量放在首位，尤其在電信領(lǐng)域，客戶對(duì)產(chǎn)品質(zhì)量要求是Always work，不是Sometimes。與其為了滿足多而全的功能導(dǎo)致交付延遲，質(zhì)量不穩(wěn)定，不如按時(shí)交付剛剛好的系統(tǒng)，保證其高質(zhì)量運(yùn)行。交付剛剛好的系統(tǒng)，基于對(duì)客戶需求的深入理解，并花時(shí)間了解細(xì)節(jié)，簡化（simplify）需求（降低復(fù)雜性）而不是簡單地拒絕需求（delete）。做到“交付剛剛好的系統(tǒng)”，同時(shí)需要管理者有足夠的勇氣和果斷決策,,聚焦客戶價(jià)值，交付剛剛好的系

18、統(tǒng),在項(xiàng)目明顯超負(fù)荷時(shí)，管理者簡單地期望靠團(tuán)隊(duì)work harder來解決，最終導(dǎo)致：質(zhì)量下降項(xiàng)目延期客戶不滿意團(tuán)隊(duì)疲勞埋下長期隱患,Page 22,,,,缺陷遺留帶來高額成本：對(duì)單獨(dú)質(zhì)量保證活動(dòng)（如后端測(cè)試）的依賴，容易形成缺陷可以遺留到下個(gè)階段的心理，導(dǎo)致缺陷發(fā)現(xiàn)成本升高（系統(tǒng)測(cè)試階段缺陷定位和解決成本是開發(fā)階段的10倍）例1：E公司開發(fā)階段和測(cè)試階段發(fā)現(xiàn)缺陷的比例為7：3，而我司大量缺陷集中在后端發(fā)現(xiàn)，帶來高額成本

19、。例2：我司顧問指出：華為測(cè)試和開發(fā)“相隔1000英里”。,聚焦客戶價(jià)值，隨時(shí)構(gòu)建質(zhì)量，不容忍缺陷,從項(xiàng)目一開始就隨時(shí)構(gòu)建質(zhì)量：形成零缺陷文化，不要容忍缺陷：發(fā)現(xiàn)缺陷應(yīng)立即停下來解決，以保證在堅(jiān)實(shí)的質(zhì)量基礎(chǔ)上前行。開發(fā)和測(cè)試緊密協(xié)作：測(cè)試人員參與到設(shè)計(jì)和開發(fā)過程中，共同預(yù)防缺陷的產(chǎn)生。,例如：持續(xù)集成暴露的問題需立即解決,Page 23,,,,聚焦客戶價(jià)值，及時(shí)消除技術(shù)債務(wù)，持續(xù)保持快速響應(yīng),為什么會(huì)有技術(shù)債務(wù)：為滿足短期商業(yè)目

20、標(biāo)，不影響其外部表現(xiàn)的情況下，會(huì)在技術(shù)方面進(jìn)行一定的讓步，這種讓步雖對(duì)當(dāng)前版本的質(zhì)量影響甚微，但會(huì)嚴(yán)重影響后續(xù)版本響應(yīng)客戶需求的能力，從而形成技術(shù)債務(wù)。,對(duì)待技術(shù)債務(wù)的態(tài)度：技術(shù)債務(wù)是有成本的，如不及時(shí)償還，會(huì)隨時(shí)間積累利息變高，導(dǎo)致開發(fā)效率大幅下降，從而降低客戶響應(yīng)能力。因此對(duì)待技術(shù)債務(wù)的態(tài)度是加以管理并及時(shí)償還（如及時(shí)重構(gòu)）。,常見技術(shù)債務(wù):日益腐爛的架構(gòu)、圈復(fù)雜度高的代碼、低的測(cè)試自動(dòng)化率、不及時(shí)清除的靜態(tài)檢查告警等。,Pag

21、e 24,,,激發(fā)團(tuán)隊(duì)，認(rèn)清團(tuán)隊(duì)的基本事實(shí),Source: Jeff CSM Training material,信任是高績效團(tuán)隊(duì)的基石,信任,承諾,沖突,創(chuàng)新,,關(guān)于團(tuán)隊(duì)激勵(lì)： 當(dāng)團(tuán)隊(duì)自管理時(shí)效率最高人們對(duì)自己做出的承諾比別人要求的承諾更認(rèn)真人們會(huì)盡力做到最好在強(qiáng)大的壓力下努力工作，人們會(huì)自然而然地降 低對(duì)質(zhì)量的要求關(guān)于團(tuán)隊(duì)績效： 當(dāng)團(tuán)隊(duì)成員不被打擾時(shí)，工作效率最高當(dāng)團(tuán)隊(duì)解決自我問題時(shí)，提升最快廣泛的、面對(duì)面的

22、交流是團(tuán)隊(duì)工作最高效的方式關(guān)于團(tuán)隊(duì)構(gòu)建：團(tuán)隊(duì)生產(chǎn)率大于相同數(shù)目的個(gè)體生產(chǎn)率之和當(dāng)不同技能領(lǐng)域的人員組成團(tuán)隊(duì)并聚焦于工作 時(shí)，產(chǎn)品更健壯,Page 25,,激發(fā)團(tuán)隊(duì)，敏捷方式下管理者的轉(zhuǎn)變,管理者努力“控制” 團(tuán)隊(duì)：制定詳細(xì)的工作計(jì)劃，并做出詳細(xì)的工作安排指令性工作方式監(jiān)控過程基于復(fù)雜規(guī)則的管理,,管理者努力“激發(fā)”團(tuán)隊(duì)：通過目標(biāo)來牽引團(tuán)隊(duì)自主工作幫助團(tuán)隊(duì)提供資源，排除障礙營造團(tuán)隊(duì)自我管理的工作氛圍作為教練輔導(dǎo)團(tuán)隊(duì)

23、進(jìn)步基于簡單原則的管理，原則簡單但必須被遵守,敏捷方式下對(duì)管理者最大的挑戰(zhàn)是學(xué)會(huì)放松”控制”(loose control),,傳統(tǒng)方式,敏捷方式,Page 26,,激發(fā)團(tuán)隊(duì)，敏捷方式下團(tuán)隊(duì)成員的轉(zhuǎn)變,團(tuán)隊(duì)成員是“聽從安排的獨(dú)立貢獻(xiàn)者”:被動(dòng)等待主管下指令安排工作獨(dú)立工作為主，協(xié)作少以文檔和郵件為主要溝通方式只關(guān)注個(gè)體任務(wù)“做完”，不關(guān)注團(tuán)隊(duì)目標(biāo)能力相對(duì)單一，學(xué)習(xí)動(dòng)力不足,敏捷方式的管理者,,從被動(dòng)到主動(dòng)的心態(tài)轉(zhuǎn)變是團(tuán)隊(duì)成員適

24、應(yīng)敏捷開發(fā)的關(guān)鍵,團(tuán)隊(duì)成員是“全方位的積極參與者”:共同參與計(jì)劃制定和任務(wù)安排團(tuán)隊(duì)協(xié)作貫穿工作始終面對(duì)面交流是主要溝通方式關(guān)注團(tuán)隊(duì)目標(biāo)，共擔(dān)責(zé)任能力要求更廣，主動(dòng)學(xué)習(xí)適應(yīng)崗位要求,傳統(tǒng)方式,敏捷方式,,Page 27,,,殘酷現(xiàn)實(shí)客戶是逐步發(fā)現(xiàn)他真正要的東西開發(fā)人員逐步發(fā)現(xiàn)如何開發(fā)產(chǎn)品滿足客戶需求在這個(gè)過程中隨時(shí)可能發(fā)生變化,美好愿望客戶知道自己要的是什么開發(fā)人員知道如何開發(fā)來滿足客戶需求在開發(fā)過程中需求不會(huì)發(fā)生變

25、化,期望客戶一開始就想清楚他們真正要的東西是不現(xiàn)實(shí)的。我們應(yīng)當(dāng)通過不斷的向客戶交付可用的產(chǎn)品，啟發(fā)客戶逐步的發(fā)現(xiàn)真正的需求。,我們認(rèn)識(shí)到,適應(yīng)變化，認(rèn)清“客戶是逐步發(fā)現(xiàn)真正需求”,,Page 28,適應(yīng)變化，小批量是快速交付的關(guān)鍵,我們首先要做的是通過盡早地、持續(xù)地交付有價(jià)值的軟件來使客戶滿意。經(jīng)常性的交付可以工作的軟件，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好。

26、 ——摘自敏捷軟件的十二個(gè)原則,在需求響應(yīng)周期相同的情況下，批量（一次開發(fā)的需求量）越小，資源利用率更高。在資源利用率相同的情況下，批量越小，交付周期更短。,減小批量不僅帶來縮短交付周期，而且還帶來提高質(zhì)量、促進(jìn)創(chuàng)新、降低管理成本、更高的效率等其他好處，大幅提升商

27、業(yè)價(jià)值。,減少批量的好處,Source：Craig Larman,減小批量,1.減少排隊(duì),3.縮短交付周期,2.加快反饋,4.增強(qiáng)質(zhì)量,5.改善創(chuàng)新,6.降低管理成本,7.更高的效率,$$,排隊(duì)理論：小批量與縮短交付周期、人員有效產(chǎn)出的關(guān)系,Page 29,,,適應(yīng)變化，通過迭代計(jì)劃不斷調(diào)整以適應(yīng)需求變化,正確做計(jì)劃方法在每一輪迭代開始，只詳細(xì)確定本次迭代的工作內(nèi)容，并嚴(yán)格執(zhí)行，對(duì)后續(xù)較遠(yuǎn)的迭代內(nèi)容只做粗略的計(jì)劃，避免浪費(fèi)。,,項(xiàng)

28、目范圍常發(fā)生變化需求出現(xiàn)了增加、刪除、優(yōu)先級(jí)調(diào)整（如圖E、O、P、J）工作量在需求細(xì)化后發(fā)現(xiàn)離原始工作量估計(jì)有偏差，引發(fā)計(jì)劃調(diào)整；（如圖中I）客戶使用了產(chǎn)品后，發(fā)現(xiàn)有些需求已不再需要（如圖中D、G）,變化無法一次性預(yù)測(cè)，一開始制作大而全的計(jì)劃易造成浪費(fèi)應(yīng)根據(jù)迭代積累的經(jīng)驗(yàn)和需求變化的情況對(duì)計(jì)劃不斷調(diào)整和細(xì)化,,Page 30,適應(yīng)變化，應(yīng)持續(xù)保持良好的軟件架構(gòu),,,,良好軟件架構(gòu)是適應(yīng)變化的基石電信軟件的特點(diǎn)是龐大、復(fù)雜、生命

29、周期長，因此需要良好架構(gòu)來保證長期的演進(jìn)，避免大規(guī)模的返工；優(yōu)秀的架構(gòu)通過可擴(kuò)展性來很好地適應(yīng)需求的變化，對(duì)敏捷起到支持作用，相反拙劣的架構(gòu)會(huì)阻礙敏捷；良好架構(gòu)使系統(tǒng)部件處于松耦合狀態(tài)，有助于制定出合適的增量開發(fā)/集成計(jì)劃，使分層分級(jí)的持續(xù)集成更加容易實(shí)施。軟件架構(gòu)需要盡早驗(yàn)證和持續(xù)維護(hù)新產(chǎn)品開發(fā)通過早期迭代來實(shí)現(xiàn)和驗(yàn)證架構(gòu)，有利于架構(gòu)的盡早穩(wěn)定；增量開發(fā)需識(shí)別影響架構(gòu)的需求，優(yōu)先實(shí)現(xiàn)，規(guī)避架構(gòu)風(fēng)險(xiǎn)；通過重構(gòu)及時(shí)維護(hù)和優(yōu)化架

30、構(gòu)（償還技術(shù)債務(wù)），使架構(gòu)保持生命力。,Page 31,適應(yīng)變化，利用多層次反饋不斷調(diào)整以逼近目標(biāo),結(jié)對(duì)編程,單元測(cè)試,持續(xù)集成,站立會(huì)議/回顧會(huì)議,客戶驗(yàn)收,對(duì)代碼質(zhì)量的反饋,對(duì)單元功能的反饋,對(duì)團(tuán)隊(duì)運(yùn)作的反饋,對(duì)系統(tǒng)功能的反饋,對(duì)客戶需求的反饋,利用多層次反饋手段，在變化的環(huán)境中讓團(tuán)隊(duì)準(zhǔn)確地了解與目標(biāo)的差距，不斷調(diào)整自身行為，并逐步逼近靶心,多層次反饋手段,,目錄,敏捷概述正確理解敏捷統(tǒng)一認(rèn)識(shí)敏捷敏捷理念解讀敏捷實(shí)踐解讀我

31、司敏捷開發(fā)實(shí)施策略我司敏捷案例,Page 33,,,,,,敏捷實(shí)踐概覽,,技術(shù)實(shí)踐,,,迭代計(jì)劃會(huì)議每日站立會(huì)議可視化管理迭代驗(yàn)收迭代回顧會(huì)議,管理實(shí)踐,產(chǎn)品Backlog（需求清單）迭代Backlog完成標(biāo)準(zhǔn),敏捷團(tuán)隊(duì)角色Product Owner（PO）Scrum MasterTeam完整團(tuán)隊(duì)實(shí)踐,團(tuán)隊(duì),用戶故事結(jié)對(duì)編程TDD（測(cè)試驅(qū)動(dòng)開發(fā)）持續(xù)集成Anatomy系統(tǒng)解剖,工作件,,,敏捷軟件開發(fā)是以短

32、周期迭代為核心，包含團(tuán)隊(duì)、工作件、管理和技術(shù)優(yōu)秀實(shí)踐的集合,,,迭代開發(fā),Page 34,,敏捷軟件開發(fā)典型場(chǎng)景,PO和開發(fā)團(tuán)隊(duì)對(duì)產(chǎn)品業(yè)務(wù)目標(biāo)形成共識(shí)PO建立和維護(hù)產(chǎn)品需求列表（需求會(huì)不斷新增和改變）,并進(jìn)行優(yōu)先級(jí)排序PO每輪迭代前，Review需求列表，并篩選高優(yōu)先級(jí)需求進(jìn)入本輪迭代開發(fā)開發(fā)團(tuán)隊(duì)細(xì)化本輪迭代需求，并按照需求的優(yōu)先級(jí)，依次在本輪迭代完成開發(fā)團(tuán)隊(duì)每日站立會(huì)議、特性開發(fā)、持續(xù)集成，使開發(fā)進(jìn)度真正透明PO對(duì)每輪迭代（

33、2－4周）交付的可工作軟件進(jìn)行現(xiàn)場(chǎng)驗(yàn)收和反饋回到第3步，開始下一輪迭代,Page 35,什么是迭代式開發(fā)迭代開發(fā)將整個(gè)軟件生命周期分成多個(gè)小的迭代（一般2-4周），每一次迭代都由需求分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試在內(nèi)的多個(gè)活動(dòng)組成，每一次迭代都可以生成一個(gè)穩(wěn)定和被驗(yàn)證過的軟件版本。,迭代式開發(fā)的好處通過將高技術(shù)風(fēng)險(xiǎn)的需求在早期迭代里實(shí)現(xiàn)，有助于盡早暴露問題和及時(shí)消除風(fēng)險(xiǎn)通過提供功能漸增的產(chǎn)品，持續(xù)從客戶獲得反饋，根據(jù)反饋及時(shí)調(diào)整，使最終

34、產(chǎn)品更加符合客戶的需要通過小批量減少排隊(duì)，提供更靈活、快速的交付能力平滑人力資源的使用，避免出現(xiàn)瓶頸,迭代式開發(fā)的關(guān)鍵要點(diǎn)每一次迭代都建立在穩(wěn)定的質(zhì)量基礎(chǔ)上，并做為下一輪迭代的基線，整個(gè)系統(tǒng)的功能隨著迭代穩(wěn)定地增長和不斷完善。每次迭代要邀請(qǐng)用戶代表（外部或內(nèi)部）驗(yàn)收，提供需求是否滿足的反饋迭代推薦采用固定的周期（2-4周），迭代內(nèi)工作不能完成，應(yīng)當(dāng)縮減交付范圍而不是延長周期,,,敏捷軟件開發(fā)核心——迭代開發(fā),迭代開發(fā)是有節(jié)奏地

35、小步快跑，但建立在堅(jiān)實(shí)的質(zhì)量基礎(chǔ)上,Page 36,敏捷團(tuán)隊(duì)包括3個(gè)核心角色: PO(Product Owner)、Scrum Master(Scrum教練)和Team(開發(fā)產(chǎn)品),敏捷團(tuán)隊(duì)的三個(gè)核心角色,Marketing,用戶,用服,管理,..etc…,利益相關(guān)人,SM,SM,SM,SM：Scrum MasterPO：Product Owner,Page 37,敏捷團(tuán)隊(duì)的角色職責(zé),Page 38,什么是完整團(tuán)隊(duì)敏捷開發(fā)中，以St

36、ory為單位的持續(xù)交付要求系統(tǒng)組、開發(fā)和測(cè)試等跨功能團(tuán)隊(duì)進(jìn)行密切協(xié)同，相互獨(dú)立的功能團(tuán)隊(duì)難以應(yīng)對(duì)。完整團(tuán)隊(duì)是跨功能領(lǐng)域（需求分析師、設(shè)計(jì)師、開發(fā)人員、測(cè)試人員、資料人員等）的人員組成一個(gè)團(tuán)隊(duì)，坐在一起工作，團(tuán)隊(duì)成員遵循同一份計(jì)劃，服從于同一個(gè)項(xiàng)目經(jīng)理。,完整團(tuán)隊(duì)的好處有助于團(tuán)隊(duì)成員形成共同目標(biāo)和全局意識(shí)，促進(jìn)各功能領(lǐng)域的拉通和融合；通過面對(duì)面溝通提升溝通效率。實(shí)現(xiàn)團(tuán)隊(duì)成員的高度協(xié)同，支撐高密度地、持續(xù)地、短周期的交付。,完整團(tuán)隊(duì)

37、的關(guān)鍵要點(diǎn)成員來自多功能領(lǐng)域：團(tuán)隊(duì)擁有完成目標(biāo)所需的各職能成員；坐在一起辦公：團(tuán)隊(duì)成員無障礙地溝通；團(tuán)隊(duì)保持相對(duì)穩(wěn)定：臨時(shí)組建的團(tuán)隊(duì)生產(chǎn)效率較低，團(tuán)隊(duì)穩(wěn)定非常關(guān)鍵。,,完整團(tuán)隊(duì)聚焦客戶需求交付，提高協(xié)作效率,敏捷團(tuán)隊(duì)實(shí)踐：完整團(tuán)隊(duì),Page 39,產(chǎn)品Backlog關(guān)鍵要點(diǎn)清楚表述列表中每個(gè)需求任務(wù)對(duì)用戶帶來的價(jià)值，做為優(yōu)先級(jí)排序的重要參考；動(dòng)態(tài)的需求管理而非“凍結(jié)”方式，PO持續(xù)地管理和及時(shí)刷新需求清單，在每輪迭代前，都要重

38、新篩選出高優(yōu)先級(jí)需求進(jìn)入本輪迭代；迭代的需求分析過程，而非一次性分析清楚所有需求（只對(duì)近期迭代要做的需求進(jìn)行詳細(xì)分析，其它需求停留在粗粒度）。,敏捷工作件：產(chǎn)品Backlog,什么是產(chǎn)品Backlog經(jīng)過優(yōu)先級(jí)排序的動(dòng)態(tài)刷新的產(chǎn)品需求清單，用來制定發(fā)布計(jì)劃和迭代計(jì)劃。,產(chǎn)品Backlog的好處通過需求的動(dòng)態(tài)管理應(yīng)對(duì)變化，避免浪費(fèi)；易于優(yōu)先交付對(duì)用戶價(jià)值高的需求。,產(chǎn)品Backlog是需求動(dòng)態(tài)管理的載體,Page 40,什么是迭代

39、Backlog迭代Backlog是團(tuán)隊(duì)在一輪迭代中的“任務(wù)”（Task）清單，是團(tuán)隊(duì)的詳細(xì)迭代開發(fā)計(jì)劃；當(dāng)團(tuán)隊(duì)接收從產(chǎn)品Backlog挑選出要在本輪迭代實(shí)現(xiàn)的需求時(shí)，召開團(tuán)隊(duì)迭代計(jì)劃會(huì)議，將需求轉(zhuǎn)化為具體的“任務(wù)”；每項(xiàng)任務(wù)信息包括當(dāng)前剩余工作量和責(zé)任人。,敏捷工作件：迭代Backlog,迭代Backlog的好處將需求分解成更細(xì)小的任務(wù)，利于對(duì)迭代內(nèi)進(jìn)度進(jìn)行精確控制；剩余工作量可用來實(shí)時(shí)跟蹤團(tuán)隊(duì)當(dāng)前進(jìn)展。,迭代Backlog關(guān)

40、鍵要點(diǎn)“任務(wù)”由團(tuán)隊(duì)成員自己分解和定義，而不是上級(jí)指派，支撐需求完成的所有工作都可以列為任務(wù)；任務(wù)要落實(shí)到具體的責(zé)任人；任務(wù)粒度要小，工作量大于兩天的任務(wù)要進(jìn)一步分解；用小時(shí)做為任務(wù)剩余工作量的估計(jì)單位，并每日重估計(jì)和刷新。,迭代Backlog提供精細(xì)的迭代開發(fā)計(jì)劃,任務(wù),責(zé)任人,狀態(tài),剩余工時(shí),日期,Page 41,敏捷工作件：完成標(biāo)準(zhǔn)（Definition of Done）,什么是完成標(biāo)準(zhǔn)基于“隨時(shí)可向用戶發(fā)布”的目標(biāo)制定

41、衡量團(tuán)隊(duì)工作是否已完成的標(biāo)準(zhǔn)，由團(tuán)隊(duì)和PO形成共識(shí)；,完成標(biāo)準(zhǔn)的好處共同協(xié)商的完成標(biāo)準(zhǔn)是團(tuán)隊(duì)的自我承諾，團(tuán)隊(duì)會(huì)更認(rèn)真；用于準(zhǔn)確評(píng)估團(tuán)隊(duì)工作進(jìn)展；清晰和明確的完成標(biāo)準(zhǔn)保證了每次迭代是高質(zhì)量的。,完成標(biāo)準(zhǔn)的關(guān)鍵要點(diǎn)團(tuán)隊(duì)自協(xié)商：團(tuán)隊(duì)根據(jù)項(xiàng)目實(shí)際情況來定義完成標(biāo)準(zhǔn)，并嚴(yán)格遵守；有層次：一般分為三個(gè)層次：Story級(jí)別，迭代級(jí)和發(fā)布級(jí)，每個(gè)級(jí)別都有各自的完成標(biāo)準(zhǔn)。,,,,Story完成標(biāo)準(zhǔn)樣例,迭代完成標(biāo)準(zhǔn)樣例,發(fā)布完成標(biāo)準(zhǔn)樣例,代碼合

42、入主干,代碼符合規(guī)范,代碼100%檢視,通過驗(yàn)收測(cè)試,通過迭代驗(yàn)收,系統(tǒng)測(cè)試用例100%通過,通過性能測(cè)試,所有Story完成,通過回歸測(cè)試,所有缺陷解決,更新配套資料,完成標(biāo)準(zhǔn)的樣例,代碼100%通過單元測(cè)試,持續(xù)集成無錯(cuò)誤,完成標(biāo)準(zhǔn)確保團(tuán)隊(duì)每一步前進(jìn)都奠定在堅(jiān)實(shí)的質(zhì)量基礎(chǔ)之上,Page 42,敏捷管理實(shí)踐：迭代計(jì)劃會(huì)議,什么是迭代計(jì)劃會(huì)議每輪迭代啟動(dòng)前，團(tuán)隊(duì)共同討論本輪迭代詳細(xì)開發(fā)計(jì)劃的過程，輸入是產(chǎn)品Backlog，輸出是團(tuán)隊(duì)迭

43、代Backlog；多團(tuán)隊(duì)迭代計(jì)劃會(huì)議要分層召開版本迭代計(jì)劃會(huì)議：將產(chǎn)品Backlog（需求）分配給團(tuán)隊(duì)；團(tuán)隊(duì)迭代計(jì)劃會(huì)議：將選取的產(chǎn)品Backlog需求轉(zhuǎn)換成迭代Backlog（任務(wù)） ，分配給團(tuán)隊(duì)成員；迭代計(jì)劃會(huì)議內(nèi)容：澄清需求、對(duì)“完成標(biāo)準(zhǔn)”達(dá)成一致工作量估計(jì)、根據(jù)團(tuán)隊(duì)能力確定本輪迭代交付內(nèi)容；細(xì)化、分配迭代任務(wù)和初始工作計(jì)劃。,迭代計(jì)劃會(huì)議的好處通過充分討論，使團(tuán)隊(duì)成員對(duì)任務(wù)和完成標(biāo)準(zhǔn)理解一致；團(tuán)隊(duì)共同參與，促進(jìn)

44、團(tuán)隊(duì)成員更認(rèn)真對(duì)待自己的承偌。,迭代計(jì)劃會(huì)議的關(guān)鍵要點(diǎn)充分參與：Scrum Master確保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考慮并與其他外部需求一起排序 。,迭代計(jì)劃會(huì)議由團(tuán)隊(duì)共同確定迭代交付內(nèi)容和完成標(biāo)準(zhǔn),Pa

45、ge 43,敏捷管理實(shí)踐：每日站立會(huì)議,什么是每日站立會(huì)議每日工作前，團(tuán)隊(duì)成員的例行溝通機(jī)制，由Scrum Master組織，Team成員全體站立參加聚焦在下面的三個(gè)主題：我昨天為本項(xiàng)目做了什么？我計(jì)劃今天為本項(xiàng)目做什么？我需要什么幫助以更高效的工作？,每日站立會(huì)議的關(guān)鍵要點(diǎn)準(zhǔn)時(shí)開始：按計(jì)劃會(huì)議制定的時(shí)間地點(diǎn)開會(huì)，形成團(tuán)隊(duì)成員的自然習(xí)慣；高效會(huì)議：會(huì)議限時(shí)15分鐘，每個(gè)人都保持站立，依次發(fā)言，不討論與會(huì)議三個(gè)主題無關(guān)的事情

46、（如技術(shù)解決方案等）；問題跟蹤：Scrum Master應(yīng)該記錄下所有的問題并跟蹤解決；,,每日站立會(huì)議的好處增加團(tuán)隊(duì)凝聚力，產(chǎn)生積極的工作氛圍及時(shí)暴露風(fēng)險(xiǎn)和問題；促進(jìn)團(tuán)隊(duì)內(nèi)成員的溝通和協(xié)調(diào)。,每日站立會(huì)議促進(jìn)團(tuán)隊(duì)溝通協(xié)調(diào)，及時(shí)暴露問題,Page 44,敏捷管理實(shí)踐：可視化管理,可視化管理的好處簡單，一目了然 ，降低管理成本；實(shí)時(shí)狀態(tài)顯示，及時(shí)暴露問題；信息同源使團(tuán)隊(duì)理解一致，提升團(tuán)隊(duì)凝聚力；激勵(lì)先進(jìn)，鞭策后進(jìn)，增強(qiáng)團(tuán)隊(duì)

47、進(jìn)取心。,什么是可視化管理將項(xiàng)目狀態(tài) (進(jìn)度、質(zhì)量等)通過物理實(shí)體（如白板，大屏幕）實(shí)時(shí)展示，讓團(tuán)隊(duì)所有成員直觀地獲取當(dāng)前項(xiàng)目進(jìn)展信息。,可視化管理的關(guān)鍵要點(diǎn)物理實(shí)體：可視化一定要做到物理上的實(shí)體化，大家在公開場(chǎng)所都容易看到，觸摸到，（存在電腦中的文件不是可視化的）；內(nèi)容精簡，易懂：信息展示一目了然，切實(shí)對(duì)團(tuán)隊(duì)有幫助，切忌貪多求全，難以分辨；實(shí)時(shí)刷新：延遲的信息拖延問題暴露，降低運(yùn)作效率。,可視化管理及時(shí)暴露問題，激勵(lì)團(tuán)隊(duì),St

48、ory墻（展示Story進(jìn)度）,缺陷走勢(shì)圖（展示缺陷解決進(jìn)展）,Anatomy視圖（展示系統(tǒng)集成進(jìn)展）,Page 45,敏捷管理實(shí)踐：迭代驗(yàn)收,什么是迭代驗(yàn)收每次迭代開發(fā)結(jié)束時(shí)舉行，通過演示可工作的軟件檢查需求是否滿足客戶要求；由Scrum Master組織， PO和用戶代表（外部或內(nèi)部利益相關(guān)人）負(fù)責(zé)驗(yàn)收、Team負(fù)責(zé)演示可工作軟件。,迭代驗(yàn)收的好處通過演示可工作的軟件來確認(rèn)項(xiàng)目的進(jìn)度，具有真實(shí)性；能盡早的獲得用戶對(duì)產(chǎn)品的反饋

49、，使產(chǎn)品更加貼近客戶需求。,迭代驗(yàn)收的關(guān)鍵要點(diǎn)展示“真實(shí)”的產(chǎn)品：Team 應(yīng)在真實(shí)環(huán)境中展示可運(yùn)行的軟件，判斷是否達(dá)到“完成”標(biāo)準(zhǔn)；收集反饋：PO 根據(jù)驗(yàn)收情況及客戶反饋意見，及時(shí)調(diào)整產(chǎn)品Backlog。,,迭代驗(yàn)收盡早演示可工作的軟件，收集反饋意見,Page 46,敏捷管理實(shí)踐：迭代回顧會(huì)議,迭代回顧會(huì)議的好處激勵(lì)團(tuán)隊(duì)成員；幫助團(tuán)隊(duì)挖掘優(yōu)秀經(jīng)驗(yàn)并繼承；避免團(tuán)隊(duì)犯重復(fù)的錯(cuò)誤；營造團(tuán)隊(duì)自主改進(jìn)的氛圍。,什么是迭代回顧會(huì)議在

50、每輪迭代結(jié)束后舉行的會(huì)議，目的是分享好的經(jīng)驗(yàn)和發(fā)現(xiàn)改進(jìn)點(diǎn)，促進(jìn)團(tuán)隊(duì)不斷進(jìn)步；圍繞如下三個(gè)問題：本次迭代有哪些做得好本次迭代我們?cè)谀男┓矫孢€能做得更好我們?cè)谙麓蔚鷾?zhǔn)備在哪些方面改進(jìn)？,迭代回顧會(huì)議的關(guān)鍵要點(diǎn)會(huì)議氣氛：Team全員參加，氣氛寬松自由，暢所欲言，頭腦風(fēng)暴發(fā)現(xiàn)問題，共同分析根因；關(guān)注重點(diǎn)：Team共同討論優(yōu)先級(jí)，將精力放在最需要的地方（關(guān)注幾個(gè)改進(jìn)就夠了）；會(huì)議結(jié)論要跟蹤閉環(huán)：可以放入迭代backlog中。,迭代

51、回顧會(huì)議是促進(jìn)團(tuán)隊(duì)持續(xù)改進(jìn)的最有效手段,好的,能做得更好的,將來改進(jìn)的,Page 47,敏捷工程實(shí)踐：用戶故事（user story）,什么是用戶故事用戶故事是站在用戶角度描述需求的一種方式；每個(gè)用戶故事須有對(duì)應(yīng)的驗(yàn)收測(cè)試用例；用戶故事是分層分級(jí)的，在使用過程中逐步分解細(xì)化；典型的描述句式為：作為一個(gè)XXX客戶角色，我需要XXX功能，帶來XXX好處。,用戶故事的好處用戶故事站在用戶視角便于和客戶交流，準(zhǔn)確描述客戶需求；用戶故

52、事可獨(dú)立交付單元、規(guī)模小，適于迭代開發(fā)，以獲得用戶快速反饋；用戶故事強(qiáng)調(diào)編寫驗(yàn)收測(cè)試用例作為驗(yàn)收標(biāo)準(zhǔn)，能促使需求分析人員準(zhǔn)確把握需求，牽引開發(fā)人員避免過度設(shè)計(jì)。,用戶故事的關(guān)鍵要點(diǎn)I – Independent，可獨(dú)立交付給客戶N – Negotiable，便于與客戶交流V - Valuable ，對(duì)客戶有價(jià)值E - Estimable ，能估計(jì)出工作量S - Small ，分解到最底層的用戶故事粒度盡量小，至少在一個(gè)迭代中

53、能完成T - Testable，可測(cè)試,初始需求：1.作為網(wǎng)絡(luò)規(guī)劃人員，我想要配置一個(gè)媒體網(wǎng)關(guān)，因?yàn)橄胍黾泳W(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ù)用例：用戶在管理系統(tǒng)上選擇以文件方式下載媒體網(wǎng)關(guān)參數(shù)，執(zhí)行成功后，檢

54、查文件是否正確下載到本地且內(nèi)容正確1.2.2作為網(wǎng)絡(luò)規(guī)劃人員，我想用MML結(jié)構(gòu)方式從管理系統(tǒng)下載媒體網(wǎng)關(guān)的參數(shù)用例:…………,,故事樣例,用戶故事便于團(tuán)隊(duì)站在用戶角度分解細(xì)化需求并制定驗(yàn)收標(biāo)準(zhǔn),Page 48,敏捷工程實(shí)踐：結(jié)對(duì)編程,什么是結(jié)對(duì)編程兩位程序員在一臺(tái)電腦前工作，一個(gè)負(fù)責(zé)敲入代碼，而另外一個(gè)實(shí)時(shí)檢視每一行敲入的代碼；操作鍵盤和鼠標(biāo)的程序員被稱為“駕駛員”，負(fù)責(zé)實(shí)時(shí)評(píng)審和協(xié)助的程序員被稱為“領(lǐng)航員”；領(lǐng)航員檢視的

55、同時(shí)還必須負(fù)責(zé)考慮下一步的工作方向 ，比如可能出現(xiàn)的問題以及改進(jìn)等。,結(jié)對(duì)編程的好處有助于提升代碼設(shè)計(jì)質(zhì)量；研究表明結(jié)對(duì)生產(chǎn)率比兩個(gè)單人總和低 15%，但缺陷數(shù)少 15%，考慮修改缺陷工作量和時(shí)間都比初始編程大幾倍，所以結(jié)對(duì)編程總體效率更高（source: The Economist）；結(jié)對(duì)編程能夠大幅促進(jìn)團(tuán)隊(duì)能力提升和知識(shí)傳播。,結(jié)對(duì)編程的關(guān)鍵要點(diǎn)程序員應(yīng)經(jīng)常性地在“駕駛員”和“領(lǐng)航員”間切換，保持成員間平等協(xié)商和相互理解，避

56、免出現(xiàn)一個(gè)角色支配另一個(gè)角色的現(xiàn)象；開始一個(gè)新Story開發(fā)的時(shí)候即可變換搭檔，以增進(jìn)知識(shí)傳播；培養(yǎng)團(tuán)隊(duì)成員積極、主動(dòng)、開放、協(xié)作的心態(tài)能夠增進(jìn)結(jié)對(duì)編程效果；實(shí)施初期需要精心輔導(dǎo)，幫助團(tuán)隊(duì)成員克服個(gè)性沖突和習(xí)慣差異。,結(jié)對(duì)編程提高代碼質(zhì)量和工作效率,Page 49,敏捷工程實(shí)踐：測(cè)試驅(qū)動(dòng)開發(fā)（TDD）,什么是測(cè)試驅(qū)動(dòng)開發(fā)TDD以測(cè)試作為編程的中心，它要求在編寫任何代碼之前，首先編寫定義代碼功能的測(cè)試用例，編寫的代碼要通過用例，并

57、不斷進(jìn)行重構(gòu)優(yōu)化；TDD要求測(cè)試可以完全自動(dòng)化運(yùn)行。,測(cè)試驅(qū)動(dòng)開發(fā)的好處和代碼同步增長的自動(dòng)化測(cè)試用例，能為代碼構(gòu)筑安全網(wǎng)，保證代碼重構(gòu)的質(zhì)量；TDD有助于開發(fā)人員優(yōu)化代碼設(shè)計(jì)，提高代碼可測(cè)試性。,測(cè)試驅(qū)動(dòng)開發(fā)的關(guān)鍵要點(diǎn)測(cè)試代碼和源代碼一樣都需要簡潔，可讀性好；測(cè)試用例的設(shè)計(jì)要保證完備，覆蓋被測(cè)單元的所有功能；每個(gè)測(cè)試用例盡量保持獨(dú)立，減少依賴，提高用例的可維護(hù)性；當(dāng)功能單元較大時(shí)，為降低難度，可分解為多個(gè)更小的功能單元，

58、并逐一用 TDD 實(shí)現(xiàn)。,測(cè)試驅(qū)動(dòng)開發(fā)保證代碼整潔可用（Clean code that works）,Page 50,,敏捷工程實(shí)踐：持續(xù)集成(CI),什么是持續(xù)集成持續(xù)集成（CI）是一項(xiàng)軟件開發(fā)實(shí)踐，其中團(tuán)隊(duì)的成員經(jīng)常集成他們的工作，通常每人每天至少集成一次，每次集成通過自動(dòng)化構(gòu)建完成。,持續(xù)集成的好處大幅縮短反饋周期，實(shí)時(shí)反映產(chǎn)品真實(shí)質(zhì)量狀態(tài)；缺陷在引入的當(dāng)天就被發(fā)現(xiàn)并解決,降低缺陷修改成本；將集成工作分散在平時(shí)，通過每天生

59、成可部署的軟件；，避免產(chǎn)品最終集成時(shí)爆發(fā)大量問題。,持續(xù)集成的關(guān)鍵要點(diǎn)持續(xù)集成強(qiáng)調(diào) “快速”和“反饋”，要求完成一次系統(tǒng)集成的時(shí)間盡量短，并提供完備且有效的反饋信息；自動(dòng)化測(cè)試用例的完備性和有效性是持續(xù)集成質(zhì)量保障；修復(fù)失敗的構(gòu)建是團(tuán)隊(duì)最高優(yōu)先級(jí)的任務(wù)；開發(fā)人員須先在本地構(gòu)建成功，才可提交代碼到配置庫 ；持續(xù)集成的狀態(tài)必須實(shí)時(shí)可視化顯示給所有人；大系統(tǒng)持續(xù)集成需分層分級(jí)，建立各層次統(tǒng)一的測(cè)試策略。,持續(xù)集成提供產(chǎn)品質(zhì)量的快速

60、反饋，保證隨時(shí)擁有可工作的軟件,參見附件：持續(xù)集成解讀.ppt,Page 51,Page 51,敏捷工程實(shí)踐：Anatomy系統(tǒng)解剖,什么是AnatomyAnatomy（解剖）來源于電信行業(yè)，從用戶視角全面展示復(fù)雜產(chǎn)品系統(tǒng)的功能依賴關(guān)系，讓整個(gè)系統(tǒng)的功能按自底向上逐步有序地開發(fā)和集成。,Anatomy的關(guān)鍵要點(diǎn)Anatomy不是系統(tǒng)架構(gòu)視圖，圖中的Block是表示系統(tǒng)提供給用戶使用的一個(gè)功能（capability），是站在純用戶視角

61、，不包含設(shè)計(jì)信息；Anatomy中的依賴關(guān)系是用戶使用系統(tǒng)功能的依賴關(guān)系，而不是設(shè)計(jì)或架構(gòu)上的依賴關(guān)系；Anatomy是系統(tǒng)全視圖，由最了解系統(tǒng)的工程師繪制出基線，在增量開發(fā)時(shí)需不斷刷新。,Anatomy幫助團(tuán)隊(duì)理解系統(tǒng)全局，制定合理的迭代計(jì)劃,Anatomy的好處Anatomy是迭代計(jì)劃制定的重要依據(jù)，保證系統(tǒng)按照類似生物自然生長的順序自底向上有序地開發(fā)和集成（Organic integration）；Anatomy也可作為可

62、視化工具，通過標(biāo)識(shí)圖中每一個(gè)功能的狀態(tài)，使項(xiàng)目整體進(jìn)展一目了然，并能極大增強(qiáng)團(tuán)隊(duì)的信心；有助于團(tuán)隊(duì)從增量交付向交付全系統(tǒng)的思維轉(zhuǎn)變；是很好的培訓(xùn)教材，幫助工程師了解全系統(tǒng)。,Anatomy樣例,目錄,敏捷概述正確理解敏捷我司敏捷開發(fā)實(shí)施策略PSST發(fā)文解讀09年敏捷實(shí)施指導(dǎo)我司敏捷案例,Page 53,關(guān)于敏捷推行的指導(dǎo)意見 華為PSST函（2009）012號(hào) 簽發(fā)人：徐直軍

63、 敏捷/迭代開發(fā)已經(jīng)成為業(yè)界主流軟件開發(fā)方法，與瀑布模式相比，其在應(yīng)對(duì)需求變化、提升產(chǎn)品質(zhì)量、加快需求響應(yīng)、縮短交付周期、提前暴露風(fēng)險(xiǎn)、及時(shí)激勵(lì)員工以及平滑人力資源的使用等方面具有明顯優(yōu)勢(shì)。為了保證敏捷/迭代開發(fā)在我司有組織、有步驟、有策劃的開展和推行，現(xiàn)明確要求如下：以業(yè)務(wù)目標(biāo)（交付周期、質(zhì)量）為導(dǎo)向牽引敏捷推行，所有敏捷度量都以交付周期和交付質(zhì)量為基礎(chǔ)，而不能為了敏捷而敏捷。公司敏捷

64、推行分三步走：項(xiàng)目級(jí)敏捷、版本級(jí)敏捷和產(chǎn)品級(jí)敏捷，每一步要控制好入口，降低風(fēng)險(xiǎn)。09年重點(diǎn)全面推進(jìn)項(xiàng)目級(jí)敏捷，版本級(jí)敏捷進(jìn)行試點(diǎn)。2010-2011在版本級(jí)敏捷試點(diǎn)基礎(chǔ)上進(jìn)行逐步推廣。項(xiàng)目級(jí)敏捷要求的實(shí)踐包括：項(xiàng)目級(jí)持續(xù)集成、開發(fā)測(cè)試?yán)?、迭代、可視化管理、回顧?huì)議、自動(dòng)化測(cè)試、站立會(huì)議、用戶代表參與現(xiàn)場(chǎng)迭代特性驗(yàn)收；其他敏捷實(shí)踐項(xiàng)目組根據(jù)情況自己選擇。所有PL都要成為合格的Scrum Master（關(guān)鍵職責(zé)是輔導(dǎo)團(tuán)隊(duì)用正確的敏捷

65、方法做事），在PL任職資格中將增加該要求。,Page 54,關(guān)于全面推廣持續(xù)集成的決議華為PSST函（2009）022號(hào)簽發(fā)人:徐直軍 持續(xù)集成是業(yè)界的優(yōu)秀軟件開發(fā)實(shí)踐，對(duì)降低軟件開發(fā)風(fēng)險(xiǎn)、增強(qiáng)項(xiàng)目可視性、提高團(tuán)隊(duì)自信心、提升軟件開發(fā)效率和質(zhì)量效果明顯。為保證持續(xù)集成在我司有組織、有步驟、有策劃地開展和推行，經(jīng)PSST討論，現(xiàn)明確要求如下：09年全面開展項(xiàng)目級(jí)和產(chǎn)品級(jí)持續(xù)集成，通過《持續(xù)集成行為自

66、檢表》牽引開發(fā)人員樹立正確的持續(xù)集成理念，同時(shí)在行為上落實(shí)要求，不斷改進(jìn)持續(xù)集成工作。本地構(gòu)建是確保持續(xù)集成成功的關(guān)鍵，開發(fā)人員須首先在本地構(gòu)建（編譯鏈接、單元測(cè)試、代碼靜態(tài)檢查）成功后，方可提交代碼到配置庫。完善持續(xù)集成工具支撐分層、分級(jí)、分布式大規(guī)模部署策略，與周邊系統(tǒng)有效對(duì)接，拉通開發(fā)領(lǐng)域相關(guān)自動(dòng)化活動(dòng)。持續(xù)集成給配置管理帶來較多改變，配置管理業(yè)務(wù)和IT與持續(xù)集成必須拉通。持續(xù)集成要和系統(tǒng)測(cè)試?yán)ǎ蓽y(cè)試體系建立持續(xù)集成的

67、統(tǒng)一端到端測(cè)試策略。持續(xù)集成大規(guī)模推廣的專項(xiàng)物料，由測(cè)試統(tǒng)一規(guī)劃和部署，持續(xù)集成服務(wù)器可采用ATCA。每個(gè)產(chǎn)品落實(shí)專人負(fù)責(zé)持續(xù)集成工作，進(jìn)行產(chǎn)品持續(xù)集成的策略制定、環(huán)境搭建和維護(hù)、問題協(xié)調(diào)解決，支撐產(chǎn)品全面部署。,Page 55,軟件代碼質(zhì)量要求及樣例華為PSST函（2009）029號(hào) 簽發(fā)人:徐直軍 編寫簡潔、可維護(hù)、可靠、可測(cè)試、高效和可移植代碼是每一位軟件開發(fā)人員的責(zé)任和目標(biāo)。針對(duì)當(dāng)前突

68、出的軟件腐化問題，明確軟件代碼的質(zhì)量要求如下：簡潔：代碼簡潔就是易于理解并且易于實(shí)現(xiàn)。盡量編寫少但功能完備的簡潔代碼，日后可以隨時(shí)為額外的功能添加更多的代碼。提高簡潔的方法有：單一功能、強(qiáng)內(nèi)聚且低耦合、避免函數(shù)過長、避免嵌套過深、避免重復(fù)等?？删S護(hù)：代碼可維護(hù)性是軟件被修改的能力，包括糾錯(cuò)、改進(jìn)、新需求或功能規(guī)格變化的適應(yīng)能力。面對(duì)進(jìn)度壓力開發(fā)人員容易忽略代碼的可維護(hù)性。我們要謹(jǐn)慎的編程，使系統(tǒng)中每個(gè)組件盡可能地“保護(hù)”自己；同時(shí)不

69、要做任何假想，隨著代碼的增長，沒有記錄下來的假想會(huì)不斷地造成缺陷。提高可維護(hù)性的方法有：使用好的編碼風(fēng)格、編碼清晰、降低代碼復(fù)雜度、盡可能減少全局變量等?？煽浚捍a可靠性是軟件在給定時(shí)間間隔和環(huán)境條件下，按設(shè)計(jì)要求成功運(yùn)行程序的概率。提高可靠性的方法有：使用安全的函數(shù)和數(shù)據(jù)結(jié)構(gòu)、編譯時(shí)打開所有的警告開關(guān)并清除所有警告、使用靜態(tài)檢查工具分析代碼并清除所有警告、檢查所有的輸入、驗(yàn)證所有的運(yùn)算、檢查所有返回值、避免強(qiáng)制轉(zhuǎn)換、避免內(nèi)存越界、避

70、免內(nèi)存泄漏等?？蓽y(cè)試：代碼可測(cè)試性是指軟件發(fā)現(xiàn)故障并隔離、定位故障的能力，以及在一定的時(shí)間和成本前提下，進(jìn)行測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行的能力。提高可測(cè)試性的方法有：盡量減少依賴、保持代碼可觀測(cè)性、限制代碼復(fù)雜度等。高效：代碼性能高效是盡可能少地占用系統(tǒng)資源，包括內(nèi)存和執(zhí)行時(shí)間。提高性能的方法有：合理利用語言特性和編譯選項(xiàng)，例如禁用C++的RTTI，可以減少可執(zhí)行文件大??；代碼內(nèi)嵌，可以減少方法調(diào)用的開銷；將不變條件的計(jì)算移到循環(huán)體外；利用并