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

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

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

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

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

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

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

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

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

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

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

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

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

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

14、…,+,…,+,…,開發(fā)團隊三,敏捷理念,開發(fā)團隊二,敏捷理念,敏捷理念,Page 17,敏捷轉(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)先級不一樣，初期以實踐為主,Numbers repres

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

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

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

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

19、。例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 23,,,,聚焦客戶價值，及時消除技術(shù)債務(wù)，持續(xù)保持快速響應(yīng),為什么會有技術(shù)債務(wù)：為滿足短期商業(yè)目

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38、新篩選出高優(yōu)先級需求進入本輪迭代；迭代的需求分析過程，而非一次性分析清楚所有需求（只對近期迭代要做的需求進行詳細分析，其它需求停留在粗粒度）。,敏捷工作件：產(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)管理的載體,Page 40,什么是迭代

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

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

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

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

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

44、團隊成員更認真對待自己的承偌。,迭代計劃會議的關(guān)鍵要點充分參與：Scrum Master確保PO和Team充分參與討論，達成理解一致；相互承諾：Team承諾完成迭代Backlog中的需求并達到”完成標準“，PO承諾在短迭代周期不增加需求（2-4周）；確定內(nèi)部任務(wù)：Team和PO協(xié)商把一些內(nèi)部任務(wù)放入迭代中（例如重構(gòu)、持續(xù)集成環(huán)境搭建等），由PO考慮并與其他外部需求一起排序 。,迭代計劃會議由團隊共同確定迭代交付內(nèi)容和完成標準,Pa

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

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

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

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

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

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

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

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

53、能完成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ù)用例：用戶在管理系統(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ù)用例:…………,,故事樣例,用戶故事便于團隊站在用戶角度分解細化需求并制定驗收標準,Page 48,敏捷工程實踐：結(jié)對編程,什么是結(jié)對編程兩位程序員在一臺電腦前工作，一個負責敲入代碼，而另外一個實時檢視每一行敲入的代碼；操作鍵盤和鼠標的程序員被稱為“駕駛員”，負責實時評審和協(xié)助的程序員被稱為“領(lǐng)航員”；領(lǐng)航員檢視的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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