華為敏捷開發(fā)介紹(華為敏捷軟件開發(fā)解讀V1.01)專題培訓課件

1、華為敏捷開發(fā)介紹(華為敏捷軟件開發(fā)解讀V1.01)Page 2關于管理者和軟件開發(fā)相關人員掌握敏捷知識的要求 為落實敏捷軟件開發(fā)在我司的順利推行，使廣大軟件開發(fā)管理者和開發(fā)人員深刻領會敏捷核心理念，熟練掌握敏捷實踐方法，從而達到增強應對需求變化的能力、提高產品質量、提升開發(fā)效率和縮短交付周期等方面的目標。為此，特提出如下要求：PM及以上管理者要深刻領會敏捷核心理念、理解我司敏捷推行策略、了解各種敏捷實踐。軟件開發(fā)相關人員（含PL、軟件開發(fā)人員、軟件測試人員、軟件架構人員、系統分析人員、與軟件相關的資料人員和研發(fā)質量人員）要深刻理解敏捷理念、掌握敏捷實踐、了解我司敏捷推行策略。通過敏捷相關知識的

2、考試是軟件開發(fā)相關人員任職資格的基本要求?？荚囋囶}分為管理者版本和員工版本，分別針對管理者和員工應知應會的知識進行考試。敏捷學習參考材料包括：華為敏捷開發(fā)解讀及相關附件。目錄敏捷概述正確理解敏捷我司敏捷開發(fā)實施策略我司敏捷案例Page 4業(yè)界敏捷浪潮ISO 9000（09版）標準將在原來八大原則的基礎上新增敏捷原則2000年美國軍方軟件開發(fā)標準（DOD 5000.2）推薦迭代為軟件開發(fā)優(yōu)選模式世界影響最大的美國波多里奇國家質量獎將敏捷作為核心的十一大原則之一Page 5軟件作坊軟件過程控制重型過程2001今 敏捷正在流行 軟件規(guī)模小，以作坊式開發(fā)為主；硬件飛速發(fā)展，軟件規(guī)模和復雜度激增，引發(fā)軟

3、件危機；引入成熟生產制造管理方法，以“過程為中心”分階段來控制軟件開發(fā)（瀑布模型），一定程度上緩解了軟件危機；軟件失敗的經驗促使過程被不斷增加約束和限制，軟件開發(fā)過程日益“重型化”，開發(fā)效率降低、響應速度變慢；隨著信息時代到來，需求變化更快，交付周期成為企業(yè)核心競爭力，輕量級的，更能適應變化的敏捷軟件開發(fā)方法被普遍認可并迅速流行。軟件危機20世紀60年代80年代90年代軟件開發(fā)順應時代變化，從重型過程轉向輕量型敏捷70年代敏捷誕生的歷史背景Page 6敏捷宣言揭示更好的軟件開發(fā)方法敏捷宣言（ 2001年）是敏捷起源的基礎，由上述4個簡單的價值觀組成，敏捷宣言的簽署推動了敏捷運動敏捷宣言本質是揭

4、示一種更好的軟件開發(fā)方式，啟迪人們重新思考軟件開發(fā)中的價值和如何更好的工作敏捷宣言Page 7軟件更像一個活著的植物，軟件開發(fā)是自底向上逐步有序的生長過程，類似于植物自然生長敏捷開發(fā)遵循軟件客觀規(guī)律，不斷的進行迭代增量開發(fā)，最終交付符合客戶價值的產品傳統開發(fā)敏捷開發(fā)敏捷更符合軟件開發(fā)規(guī)律Page 8敏捷對生產率、質量、滿意度、成本有明顯改進82%的項目生產率有提高78%的項目質量有提高78%的項目客戶滿意度有提高37%的項目成本有降低* 以上數據來自DDJ 2008由Scott Ambler發(fā)起的網上調查結果目錄敏捷概述正確理解敏捷統一敏捷認識敏捷理念解讀敏捷實踐解讀我司敏捷開發(fā)實施策略我司敏

5、捷案例Page 10對敏捷的常見誤解誤解一： 敏捷開發(fā)意味著可以不需要文檔、設計和計劃誤解二： 敏捷只是一些優(yōu)秀實踐，或者是優(yōu)秀實踐的結合誤解三： 敏捷只適用于小項目開發(fā)誤解四： 敏捷只會對研發(fā)產生改變誤解五： 管理者不需要親自了解敏捷，只需要管理上支持就可以了誤解六： 引入敏捷只需要按照既定的步驟去做就可以了誤解七： 敏捷是CMM的替代品，是另一種流程誤解八： 敏捷只注重特性的快速交付，在敏捷下架構不重要了Page 11統一認識：敏捷=理念+優(yōu)秀實踐+具體應用理念優(yōu)秀實踐具體應用 理念（敏捷核心思想）敏捷包括3個層次 優(yōu)秀實踐（敏捷的經驗積累） 具體應用（能夠結合自身靈活應用才是真正敏捷）P

6、age 12理念：聚焦客戶價值(Value)，消除浪費軟件業(yè)：45%的軟件特性客戶沒有使用Source：Standish Group 來自5萬個軟件開發(fā)項目的調查Source：中國電信總工韋樂平在華為公司工程與技術大會上的講話Source：如何提升軟件開發(fā)效率08年統計電信業(yè)：“電信級”帶來的浪費“價值”在“敏捷宣言”中的體現產品商業(yè)成功為目標，聚焦客戶價值、圍繞價值流消除浪費我司：研發(fā)版本廢棄特性07.1-08.6年某產品線所有產品中重要特性無應用的比例達22%（需求變更和分析不足占63%）個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃Pag

7、e 13理念：激發(fā)團隊(Team)潛能，加強協作我司試點開發(fā)測試拉通，效率質量改善明顯團隊是價值的真正創(chuàng)造者，應加強團隊協作、激發(fā)團隊潛能軟件開發(fā)是一種團隊活動，首先應做到提升溝通效率降低交流成本Source: 08年測試行業(yè)超過30個項目試點Source：經濟學家2003& DeMarco 研究報告“團隊”在“敏捷宣言”中的體現個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃效率流行度文檔錄制的視頻錄制的音頻2人郵件溝通2人白板溝通2人電話溝通不支持問答形式支持問答形式研究表明面對面的溝通最有效 業(yè)界調查：一個50人開發(fā)團隊，每人平均30%時間

8、用于編碼，70%的時間用于與其他成員交流。研究表明1981年來自不同公司的優(yōu)秀程序員生產率之比是7:1，而2007年最新的研究數據，則是40:1。人是軟件開發(fā)的決定因素需求變更降低比例補充場景數TR4前發(fā)現缺陷比例版本周期縮短（周數）無線49.36%8855.90%2.82核心網45%19045.18%3.5網絡31%33042.5%2.6業(yè)軟30%30048.15%2.1公司平均38.84%90847.93%2.76Page 14理念：不斷調整以適應(Adapting)變化麥當勞是簡單可預測生產過程人月神話：軟件開發(fā)是人類最復雜工作之一，軟件具有四個屬性：復雜性、一致性、可變性和不可見性。軟

9、件開發(fā)是不可重復、探索性的、演進的，適應性過程。隨軟件規(guī)模增長，需求變化呈非線性增長軟件開發(fā)是復雜不可預測的經驗控制過程“適應變化”在“敏捷宣言”中的體現不斷的根據經驗調整，最終交付達到業(yè)務目標的產品軟件開發(fā)規(guī)律再審視個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃Page 15優(yōu)秀實踐: 業(yè)界敏捷優(yōu)秀實踐概覽結對編程測試驅動開發(fā)客戶參與驗收計劃游戲代碼集體所有每日站立會議產品backlog（帶優(yōu)先級的需求清單）燃燒圖迭代計劃會議回顧會議Scrum MasterProduct OwnerAnatomy（系統解剖）One TrackSystemak

10、ut（缺陷管理和決策）重構完整團隊穩(wěn)定開發(fā)節(jié)奏Lagomising（需求決策）隱喻電信業(yè)偏重大規(guī)模產品實踐、Scrum偏重項目管理，XP偏重編程實踐電信業(yè)ScrumXP持續(xù)集成迭代交付Page 16開發(fā)團隊一具體應用：因地制宜選擇適合的敏捷實踐團隊在透徹理解敏捷理念的基礎上，可以靈活選擇最適合自己的實踐，避免教條化站立會議排序的工作列表持續(xù)集成持續(xù)集成重構持續(xù)集成結對編程迭代開發(fā)+迭代開發(fā)+開發(fā)團隊三敏捷理念開發(fā)團隊二敏捷理念敏捷理念Page 17敏捷轉型是系統性工程敏捷轉型7個方面優(yōu)先級Source：Cutter Agile Transformation（Jim Highsmith大師）敏捷

11、轉型是系統工程，覆蓋7個方面：實踐、績效考核、組織、過程、文化、管控、技術和業(yè)務對齊敏捷在敏捷轉型不同階段，敏捷轉型框架的7個方面引入的優(yōu)先級不一樣，初期以實踐為主Wave3 (企業(yè)級）Wave2 (產品級)Wave1(項目級)2121334Stage522Alignment1112Culture13Governance22Performance212Process1122Organization3211PracticesStage4Stage3Stage2Stage1Numbers represent typical relative importance at each stage.實踐績

12、效組織過程文化管控技術和業(yè)務對齊敏捷轉型框架目錄敏捷概述正確理解敏捷統一認識敏捷敏捷理念解讀敏捷實踐解讀我司敏捷開發(fā)實施策略我司敏捷案例Page 19深入理解敏捷理念 深入理解“適應變化”認請“客戶是逐步發(fā)現真正需求”小批量是快速交付的關鍵通過迭代計劃不斷調整以適應需求變化應持續(xù)保持良好的軟件架構利用多層次反饋不斷調整以逼近目標 深入理解“激發(fā)團隊”認清團隊的基本事實敏捷方式下管理者的轉變敏捷方式下團隊成員的轉變 深入理解“聚焦客戶價值”標識和消除軟件開發(fā)中的浪費交付剛剛好的系統隨時構建質量，不容忍缺陷及時消除技術債務，持續(xù)保持快速響應Page 20浪費類別浪費舉例1部分完成的工作部分完成但沒

13、有最終落地的工作（沒有轉化成代碼的設計文檔；未及時合入的代碼導致引發(fā)后續(xù)更多同步工作量）。2未應用特性開發(fā)完成但沒有被客戶應用的特性（交換機2000多個功能客戶只用了1%）。3再次學習人員頻繁流動導致經驗不能積累，反復重新學習；在多個環(huán)節(jié)移交時，接收信息者也需要重新學習；擁有某領域的專家，但在開發(fā)過程中需要此領域經驗時，他卻沒參與，而是團隊重新摸索。4移交知識信息的傳遞總是伴隨信息丟失，隱形知識尤其困難，分工過細往往導致過多不必要的移交（如詳細設計和實現分離，造成大量設計信息丟失）。5任務切換研究表明多任務工作會導致效率下降20%-40%（員工多頭工作或雜事繁多）。6延遲因任務或資源相互依賴而

14、導致工作停滯（集成時被關鍵模塊阻塞，等待測試環(huán)境就緒）。7缺陷解決缺陷活動本身就是浪費，而且缺陷越遺留到后端浪費越大。聚焦客戶價值，標識和消除軟件開發(fā)中的浪費Source：精益軟件開發(fā)Page 21當質量、進度、資源沖突時，能改變的只有項目范圍，即選擇“交付剛剛好的系統”產品交付前，客戶往往期望多而全的功能，產品交付后，客戶把穩(wěn)定的質量放在首位，尤其在電信領域，客戶對產品質量要求是Always work，不是Sometimes。與其為了滿足多而全的功能導致交付延遲，質量不穩(wěn)定，不如按時交付剛剛好的系統，保證其高質量運行。交付剛剛好的系統，基于對客戶需求的深入理解，并花時間了解細節(jié)，簡化（sim

15、plify）需求（降低復雜性）而不是簡單地拒絕需求（delete）。做到“交付剛剛好的系統”，同時需要管理者有足夠的勇氣和果斷決策聚焦客戶價值，交付剛剛好的系統在項目明顯超負荷時，管理者簡單地期望靠團隊work harder來解決，最終導致：質量下降項目延期客戶不滿意團隊疲勞埋下長期隱患Page 22缺陷遺留帶來高額成本：對單獨質量保證活動（如后端測試）的依賴，容易形成缺陷可以遺留到下個階段的心理，導致缺陷發(fā)現成本升高（系統測試階段缺陷定位和解決成本是開發(fā)階段的10倍）例1：E公司開發(fā)階段和測試階段發(fā)現缺陷的比例為7：3，而我司大量缺陷集中在后端發(fā)現，帶來高額成本。例2：我司顧問指出：華為測試

16、和開發(fā)“相隔1000英里”。聚焦客戶價值，隨時構建質量，不容忍缺陷 從項目一開始就隨時構建質量：形成零缺陷文化，不要容忍缺陷：發(fā)現缺陷應立即停下來解決，以保證在堅實的質量基礎上前行。開發(fā)和測試緊密協作：測試人員參與到設計和開發(fā)過程中，共同預防缺陷的產生。例如：持續(xù)集成暴露的問題需立即解決Page 23聚焦客戶價值，及時消除技術債務，持續(xù)保持快速響應技術商務為什么會有技術債務：為滿足短期商業(yè)目標，不影響其外部表現的情況下，會在技術方面進行一定的讓步，這種讓步雖對當前版本的質量影響甚微，但會嚴重影響后續(xù)版本響應客戶需求的能力，從而形成技術債務。時間技術債務開發(fā)速率對待技術債務的態(tài)度：技術債務是有成

17、本的，如不及時償還，會隨時間積累利息變高，導致開發(fā)效率大幅下降，從而降低客戶響應能力。因此對待技術債務的態(tài)度是加以管理并及時償還（如及時重構）。常見技術債務:日益腐爛的架構、圈復雜度高的代碼、低的測試自動化率、不及時清除的靜態(tài)檢查告警等。Page 24激發(fā)團隊，認清團隊的基本事實Source: Jeff CSM Training material信任是高績效團隊的基石信任承諾沖突創(chuàng)新關于團隊激勵： 當團隊自管理時效率最高人們對自己做出的承諾比別人要求的承諾更認真人們會盡力做到最好在強大的壓力下努力工作，人們會自然而然地降 低對質量的要求關于團隊績效： 當團隊成員不被打擾時，工作效率最高當團隊解

18、決自我問題時，提升最快廣泛的、面對面的交流是團隊工作最高效的方式關于團隊構建：團隊生產率大于相同數目的個體生產率之和當不同技能領域的人員組成團隊并聚焦于工作 時，產品更健壯Page 25激發(fā)團隊，敏捷方式下管理者的轉變管理者努力“控制” 團隊：制定詳細的工作計劃，并做出詳細的工作安排指令性工作方式監(jiān)控過程基于復雜規(guī)則的管理管理者努力“激發(fā)”團隊：通過目標來牽引團隊自主工作幫助團隊提供資源，排除障礙營造團隊自我管理的工作氛圍作為教練輔導團隊進步基于簡單原則的管理，原則簡單但必須被遵守敏捷方式下對管理者最大的挑戰(zhàn)是學會放松”控制”(loose control)傳統方式敏捷方式Page 26激發(fā)團隊

19、，敏捷方式下團隊成員的轉變團隊成員是“聽從安排的獨立貢獻者”:被動等待主管下指令安排工作獨立工作為主，協作少以文檔和郵件為主要溝通方式只關注個體任務“做完”，不關注團隊目標能力相對單一，學習動力不足敏捷方式的管理者從被動到主動的心態(tài)轉變是團隊成員適應敏捷開發(fā)的關鍵團隊成員是“全方位的積極參與者”:共同參與計劃制定和任務安排團隊協作貫穿工作始終面對面交流是主要溝通方式關注團隊目標，共擔責任能力要求更廣，主動學習適應崗位要求傳統方式敏捷方式Page 27殘酷現實客戶是逐步發(fā)現他真正要的東西開發(fā)人員逐步發(fā)現如何開發(fā)產品滿足客戶需求在這個過程中隨時可能發(fā)生變化美好愿望客戶知道自己要的是什么開發(fā)人員知道

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

21、僅帶來縮短交付周期，而且還帶來提高質量、促進創(chuàng)新、降低管理成本、更高的效率等其他好處，大幅提升商業(yè)價值。減少批量的好處資源利用率交付周期大批量中批量小批量Source：Craig Larman減小批量1.減少排隊3.縮短交付周期2.加快反饋4.增強質量5.改善創(chuàng)新6.降低管理成本7.更高的效率$排隊理論：小批量與縮短交付周期、人員有效產出的關系Page 29適應變化，通過迭代計劃不斷調整以適應需求變化正確做計劃方法在每一輪迭代開始，只詳細確定本次迭代的工作內容，并嚴格執(zhí)行，對后續(xù)較遠的迭代內容只做粗略的計劃，避免浪費。項目范圍常發(fā)生變化需求出現了增加、刪除、優(yōu)先級調整（如圖E、O、P、J）工作

22、量在需求細化后發(fā)現離原始工作量估計有偏差，引發(fā)計劃調整；（如圖中I）客戶使用了產品后，發(fā)現有些需求已不再需要（如圖中D、G）變化無法一次性預測，一開始制作大而全的計劃易造成浪費應根據迭代積累的經驗和需求變化的情況對計劃不斷調整和細化Page 30適應變化，應持續(xù)保持良好的軟件架構良好軟件架構是適應變化的基石電信軟件的特點是龐大、復雜、生命周期長，因此需要良好架構來保證長期的演進，避免大規(guī)模的返工；優(yōu)秀的架構通過可擴展性來很好地適應需求的變化，對敏捷起到支持作用，相反拙劣的架構會阻礙敏捷；良好架構使系統部件處于松耦合狀態(tài)，有助于制定出合適的增量開發(fā)/集成計劃，使分層分級的持續(xù)集成更加容易實施。軟

23、件架構需要盡早驗證和持續(xù)維護新產品開發(fā)通過早期迭代來實現和驗證架構，有利于架構的盡早穩(wěn)定；增量開發(fā)需識別影響架構的需求，優(yōu)先實現，規(guī)避架構風險；通過重構及時維護和優(yōu)化架構（償還技術債務），使架構保持生命力。Page 31適應變化，利用多層次反饋不斷調整以逼近目標結對編程單元測試持續(xù)集成站立會議/回顧會議客戶驗收對代碼質量的反饋 對單元功能的反饋 對團隊運作的反饋對系統功能的反饋 對客戶需求的反饋利用多層次反饋手段，在變化的環(huán)境中讓團隊準確地了解與目標的差距，不斷調整自身行為，并逐步逼近靶心多層次反饋手段目錄敏捷概述正確理解敏捷統一認識敏捷敏捷理念解讀敏捷實踐解讀我司敏捷開發(fā)實施策略我司敏捷案例

24、Page 33敏捷實踐概覽技術實踐迭代計劃會議每日站立會議可視化管理迭代驗收迭代回顧會議 管理實踐產品Backlog（需求清單）迭代Backlog完成標準敏捷團隊角色Product Owner（PO）Scrum MasterTeam完整團隊實踐團隊用戶故事結對編程TDD（測試驅動開發(fā)）持續(xù)集成Anatomy系統解剖工作件敏捷軟件開發(fā)是以短周期迭代為核心，包含團隊、工作件、管理和技術優(yōu)秀實踐的集合迭代開發(fā)Page 34敏捷軟件開發(fā)典型場景PO和開發(fā)團隊對產品業(yè)務目標形成共識PO建立和維護產品需求列表（需求會不斷新增和改變）,并進行優(yōu)先級排序PO每輪迭代前，Review需求列表，并篩選高優(yōu)先級需求

25、進入本輪迭代開發(fā)開發(fā)團隊細化本輪迭代需求，并按照需求的優(yōu)先級，依次在本輪迭代完成開發(fā)團隊每日站立會議、特性開發(fā)、持續(xù)集成，使開發(fā)進度真正透明PO對每輪迭代（24周）交付的可工作軟件進行現場驗收和反饋回到第3步，開始下一輪迭代迭代每日工作站立會議特性開發(fā)特性測試持續(xù)集成交付可以工作的軟件迭代計劃回顧確定一個迭代的工作內容產品和利益相關人、Page 35什么是迭代式開發(fā)迭代開發(fā)將整個軟件生命周期分成多個小的迭代（一般2-4周），每一次迭代都由需求分析、設計、實現和測試在內的多個活動組成，每一次迭代都可以生成一個穩(wěn)定和被驗證過的軟件版本。迭代式開發(fā)的好處通過將高技術風險的需求在早期迭代里實現，有助于

26、盡早暴露問題和及時消除風險通過提供功能漸增的產品，持續(xù)從客戶獲得反饋，根據反饋及時調整，使最終產品更加符合客戶的需要通過小批量減少排隊，提供更靈活、快速的交付能力平滑人力資源的使用，避免出現瓶頸迭代式開發(fā)的關鍵要點每一次迭代都建立在穩(wěn)定的質量基礎上，并做為下一輪迭代的基線，整個系統的功能隨著迭代穩(wěn)定地增長和不斷完善。每次迭代要邀請用戶代表（外部或內部）驗收，提供需求是否滿足的反饋迭代推薦采用固定的周期（2-4周），迭代內工作不能完成，應當縮減交付范圍而不是延長周期敏捷軟件開發(fā)核心迭代開發(fā)迭代1迭代2迭代3反饋反饋迭代開發(fā)是有節(jié)奏地小步快跑，但建立在堅實的質量基礎上Page 36敏捷團隊包括3個

27、核心角色: PO(Product Owner)、Scrum Master(Scrum教練)和Team(開發(fā)產品)敏捷團隊的三個核心角色Marketing用戶用服管理.etc利益相關人SMSMSMSM：Scrum MasterPO：Product OwnerPage 37敏捷團隊的角色職責角色名稱角色定義角色職責注意事項Product Owner（產品負責人）確保Team做正確的事代表利益相關人（如用戶、Marketing、用服、管理者等），對產品投資回報負責確定產品發(fā)布計劃定義產品需求并確定優(yōu)先級驗收迭代結果，并根據驗收結果和需求變化刷新需求清單和優(yōu)先級除了客戶需求之外，內部任務如重構、持續(xù)集

28、成環(huán)境搭建等也由PO納入統一管理Scrum Master（Scrum教練）確保Team正確地做事輔導團隊正確應用敏捷實踐引導團隊建立并遵守規(guī)則保護團隊不受打擾推動解決團隊遇到的障礙激勵團隊不命令和控制TeamTeam（開發(fā)團隊）負責產品需求實現負責估計工作量并根據自身能力找出最佳方案去完成任務且保證交付質量向PO和利益相關人演示工作成果（可運行的軟件）團隊自我管理、持續(xù)改進一般由5-9名跨功能領域人員組成坐在一起工作有共同的目標，共擔責任團隊成員嚴格遵守團隊規(guī)則Page 38什么是完整團隊敏捷開發(fā)中，以Story為單位的持續(xù)交付要求系統組、開發(fā)和測試等跨功能團隊進行密切協同，相互獨立的功能團隊

29、難以應對。完整團隊是跨功能領域（需求分析師、設計師、開發(fā)人員、測試人員、資料人員等）的人員組成一個團隊，坐在一起工作，團隊成員遵循同一份計劃，服從于同一個項目經理。完整團隊的好處有助于團隊成員形成共同目標和全局意識，促進各功能領域的拉通和融合；通過面對面溝通提升溝通效率。實現團隊成員的高度協同，支撐高密度地、持續(xù)地、短周期的交付。完整團隊的關鍵要點成員來自多功能領域：團隊擁有完成目標所需的各職能成員；坐在一起辦公：團隊成員無障礙地溝通；團隊保持相對穩(wěn)定：臨時組建的團隊生產效率較低，團隊穩(wěn)定非常關鍵。完整團隊聚焦客戶需求交付，提高協作效率敏捷團隊實踐：完整團隊Page 39產品Backlog關鍵

30、要點清楚表述列表中每個需求任務對用戶帶來的價值，做為優(yōu)先級排序的重要參考；動態(tài)的需求管理而非“凍結”方式，PO持續(xù)地管理和及時刷新需求清單，在每輪迭代前，都要重新篩選出高優(yōu)先級需求進入本輪迭代；迭代的需求分析過程，而非一次性分析清楚所有需求（只對近期迭代要做的需求進行詳細分析，其它需求停留在粗粒度）。敏捷工作件：產品Backlog什么是產品Backlog經過優(yōu)先級排序的動態(tài)刷新的產品需求清單，用來制定發(fā)布計劃和迭代計劃。產品Backlog的好處通過需求的動態(tài)管理應對變化，避免浪費；易于優(yōu)先交付對用戶價值高的需求。產品Backlog是需求動態(tài)管理的載體Page 40什么是迭代Backlog迭代B

31、acklog是團隊在一輪迭代中的“任務”（Task）清單，是團隊的詳細迭代開發(fā)計劃；當團隊接收從產品Backlog挑選出要在本輪迭代實現的需求時，召開團隊迭代計劃會議，將需求轉化為具體的“任務”；每項任務信息包括當前剩余工作量和責任人。敏捷工作件：迭代Backlog迭代Backlog的好處將需求分解成更細小的任務，利于對迭代內進度進行精確控制；剩余工作量可用來實時跟蹤團隊當前進展。迭代Backlog關鍵要點“任務”由團隊成員自己分解和定義，而不是上級指派，支撐需求完成的所有工作都可以列為任務；任務要落實到具體的責任人；任務粒度要小，工作量大于兩天的任務要進一步分解；用小時做為任務剩余工作量的估

32、計單位，并每日重估計和刷新。迭代Backlog提供精細的迭代開發(fā)計劃任務責任人狀態(tài)剩余工時日期Page 41敏捷工作件：完成標準（Definition of Done）什么是完成標準基于“隨時可向用戶發(fā)布”的目標制定衡量團隊工作是否已完成的標準，由團隊和PO形成共識；完成標準的好處共同協商的完成標準是團隊的自我承諾，團隊會更認真；用于準確評估團隊工作進展；清晰和明確的完成標準保證了每次迭代是高質量的。完成標準的關鍵要點團隊自協商：團隊根據項目實際情況來定義完成標準，并嚴格遵守；有層次：一般分為三個層次：Story級別，迭代級和發(fā)布級，每個級別都有各自的完成標準。Story完成標準樣例迭代完成標

33、準樣例發(fā)布完成標準樣例代碼合入主干代碼符合規(guī)范代碼100%檢視通過驗收測試通過迭代驗收系統測試用例100%通過通過性能測試所有Story完成通過回歸測試所有缺陷解決更新配套資料完成標準的樣例代碼100%通過單元測試持續(xù)集成無錯誤完成標準確保團隊每一步前進都奠定在堅實的質量基礎之上Page 42敏捷管理實踐：迭代計劃會議什么是迭代計劃會議每輪迭代啟動前，團隊共同討論本輪迭代詳細開發(fā)計劃的過程，輸入是產品Backlog，輸出是團隊迭代Backlog；多團隊迭代計劃會議要分層召開版本迭代計劃會議：將產品Backlog（需求）分配給團隊；團隊迭代計劃會議：將選取的產品Backlog需求轉換成迭代Bac

34、klog（任務） ，分配給團隊成員；迭代計劃會議內容：澄清需求、對“完成標準”達成一致工作量估計、根據團隊能力確定本輪迭代交付內容；細化、分配迭代任務和初始工作計劃。迭代計劃會議的好處通過充分討論，使團隊成員對任務和完成標準理解一致；團隊共同參與，促進團隊成員更認真對待自己的承偌。迭代計劃會議的關鍵要點充分參與：Scrum Master確保PO和Team充分參與討論，達成理解一致；相互承諾：Team承諾完成迭代Backlog中的需求并達到”完成標準“，PO承諾在短迭代周期不增加需求（2-4周）；確定內部任務：Team和PO協商把一些內部任務放入迭代中（例如重構、持續(xù)集成環(huán)境搭建等），由PO考慮

35、并與其他外部需求一起排序 。迭代計劃會議由團隊共同確定迭代交付內容和完成標準Page 43敏捷管理實踐：每日站立會議什么是每日站立會議每日工作前，團隊成員的例行溝通機制，由Scrum Master組織，Team成員全體站立參加聚焦在下面的三個主題：我昨天為本項目做了什么？我計劃今天為本項目做什么？我需要什么幫助以更高效的工作？每日站立會議的關鍵要點準時開始：按計劃會議制定的時間地點開會，形成團隊成員的自然習慣；高效會議：會議限時15分鐘，每個人都保持站立，依次發(fā)言，不討論與會議三個主題無關的事情（如技術解決方案等）；問題跟蹤：Scrum Master應該記錄下所有的問題并跟蹤解決；每日站立會議

36、的好處增加團隊凝聚力，產生積極的工作氛圍及時暴露風險和問題；促進團隊內成員的溝通和協調。每日站立會議促進團隊溝通協調，及時暴露問題Page 44敏捷管理實踐：可視化管理可視化管理的好處簡單，一目了然 ，降低管理成本；實時狀態(tài)顯示，及時暴露問題；信息同源使團隊理解一致，提升團隊凝聚力；激勵先進，鞭策后進，增強團隊進取心。什么是可視化管理將項目狀態(tài) (進度、質量等)通過物理實體（如白板，大屏幕）實時展示，讓團隊所有成員直觀地獲取當前項目進展信息?？梢暬芾淼年P鍵要點物理實體：可視化一定要做到物理上的實體化，大家在公開場所都容易看到，觸摸到，（存在電腦中的文件不是可視化的）；內容精簡，易懂：信息展示

37、一目了然，切實對團隊有幫助，切忌貪多求全，難以分辨；實時刷新：延遲的信息拖延問題暴露，降低運作效率。可視化管理及時暴露問題，激勵團隊Story墻（展示Story進度）缺陷走勢圖（展示缺陷解決進展）Anatomy視圖（展示系統集成進展）Page 45敏捷管理實踐：迭代驗收什么是迭代驗收每次迭代開發(fā)結束時舉行，通過演示可工作的軟件檢查需求是否滿足客戶要求；由Scrum Master組織， PO和用戶代表（外部或內部利益相關人）負責驗收、Team負責演示可工作軟件。迭代驗收的好處通過演示可工作的軟件來確認項目的進度，具有真實性；能盡早的獲得用戶對產品的反饋，使產品更加貼近客戶需求。迭代驗收的關鍵要點

38、展示“真實”的產品：Team 應在真實環(huán)境中展示可運行的軟件，判斷是否達到“完成”標準；收集反饋：PO 根據驗收情況及客戶反饋意見，及時調整產品Backlog。迭代驗收盡早演示可工作的軟件，收集反饋意見Page 46敏捷管理實踐：迭代回顧會議迭代回顧會議的好處激勵團隊成員；幫助團隊挖掘優(yōu)秀經驗并繼承；避免團隊犯重復的錯誤；營造團隊自主改進的氛圍。什么是迭代回顧會議在每輪迭代結束后舉行的會議，目的是分享好的經驗和發(fā)現改進點，促進團隊不斷進步；圍繞如下三個問題：本次迭代有哪些做得好本次迭代我們在哪些方面還能做得更好我們在下次迭代準備在哪些方面改進？迭代回顧會議的關鍵要點會議氣氛：Team全員參加，

39、氣氛寬松自由，暢所欲言，頭腦風暴發(fā)現問題，共同分析根因；關注重點：Team共同討論優(yōu)先級，將精力放在最需要的地方（關注幾個改進就夠了）；會議結論要跟蹤閉環(huán)：可以放入迭代backlog中。迭代回顧會議是促進團隊持續(xù)改進的最有效手段好的能做得更好的將來改進的Page 47敏捷工程實踐：用戶故事（user story）什么是用戶故事用戶故事是站在用戶角度描述需求的一種方式；每個用戶故事須有對應的驗收測試用例；用戶故事是分層分級的，在使用過程中逐步分解細化；典型的描述句式為：作為一個XXX客戶角色，我需要XXX功能，帶來XXX好處。用戶故事的好處用戶故事站在用戶視角便于和客戶交流，準確描述客戶需求；用

40、戶故事可獨立交付單元、規(guī)模小，適于迭代開發(fā)，以獲得用戶快速反饋；用戶故事強調編寫驗收測試用例作為驗收標準，能促使需求分析人員準確把握需求，牽引開發(fā)人員避免過度設計。用戶故事的關鍵要點I Independent，可獨立交付給客戶N Negotiable，便于與客戶交流V - Valuable ，對客戶有價值E - Estimable ，能估計出工作量S - Small ，分解到最底層的用戶故事粒度盡量小，至少在一個迭代中能完成T - Testable，可測試 初始需求：1.作為網絡規(guī)劃人員，我想要配置一個媒體網關，因為想要增加網絡容量和服務初次分解：1.1作為網絡規(guī)劃人員，我想把媒體網關參數上傳

41、到管理系統 1.2作為網絡規(guī)劃人員，我想從管理系統下載媒體網關參數再次分解：1.2.1作為網絡規(guī)劃人員，我想用文件方式從管理系統下載媒體網關參數用例：用戶在管理系統上選擇以文件方式下載媒體網關參數，執(zhí)行成功后，檢查文件是否正確下載到本地且內容正確1.2.2作為網絡規(guī)劃人員，我想用MML結構方式從管理系統下載媒體網關的參數用例:故事樣例用戶故事便于團隊站在用戶角度分解細化需求并制定驗收標準Page 48敏捷工程實踐：結對編程什么是結對編程兩位程序員在一臺電腦前工作，一個負責敲入代碼，而另外一個實時檢視每一行敲入的代碼；操作鍵盤和鼠標的程序員被稱為“駕駛員”，負責實時評審和協助的程序員被稱為“領航

42、員”；領航員檢視的同時還必須負責考慮下一步的工作方向 ，比如可能出現的問題以及改進等。結對編程的好處有助于提升代碼設計質量；研究表明結對生產率比兩個單人總和低 15%，但缺陷數少 15%，考慮修改缺陷工作量和時間都比初始編程大幾倍，所以結對編程總體效率更高（source: The Economist）；結對編程能夠大幅促進團隊能力提升和知識傳播。結對編程的關鍵要點程序員應經常性地在“駕駛員”和“領航員”間切換，保持成員間平等協商和相互理解，避免出現一個角色支配另一個角色的現象；開始一個新Story開發(fā)的時候即可變換搭檔，以增進知識傳播；培養(yǎng)團隊成員積極、主動、開放、協作的心態(tài)能夠增進結對編程效

43、果；實施初期需要精心輔導，幫助團隊成員克服個性沖突和習慣差異。結對編程提高代碼質量和工作效率Page 49敏捷工程實踐：測試驅動開發(fā)（TDD）什么是測試驅動開發(fā)TDD以測試作為編程的中心，它要求在編寫任何代碼之前，首先編寫定義代碼功能的測試用例，編寫的代碼要通過用例，并不斷進行重構優(yōu)化；TDD要求測試可以完全自動化運行。測試驅動開發(fā)的好處和代碼同步增長的自動化測試用例，能為代碼構筑安全網，保證代碼重構的質量；TDD有助于開發(fā)人員優(yōu)化代碼設計，提高代碼可測試性。測試驅動開發(fā)的關鍵要點測試代碼和源代碼一樣都需要簡潔，可讀性好；測試用例的設計要保證完備，覆蓋被測單元的所有功能；每個測試用例盡量保持獨

44、立，減少依賴，提高用例的可維護性；當功能單元較大時，為降低難度，可分解為多個更小的功能單元，并逐一用 TDD 實現。測試驅動開發(fā)保證代碼整潔可用（Clean code that works）Page 50敏捷工程實踐：持續(xù)集成(CI)什么是持續(xù)集成持續(xù)集成（CI）是一項軟件開發(fā)實踐，其中團隊的成員經常集成他們的工作，通常每人每天至少集成一次，每次集成通過自動化構建完成。持續(xù)集成的好處大幅縮短反饋周期，實時反映產品真實質量狀態(tài)；缺陷在引入的當天就被發(fā)現并解決,降低缺陷修改成本；將集成工作分散在平時，通過每天生成可部署的軟件；，避免產品最終集成時爆發(fā)大量問題。 持續(xù)集成的關鍵要點持續(xù)集成強調 “快

45、速”和“反饋”，要求完成一次系統集成的時間盡量短，并提供完備且有效的反饋信息；自動化測試用例的完備性和有效性是持續(xù)集成質量保障；修復失敗的構建是團隊最高優(yōu)先級的任務；開發(fā)人員須先在本地構建成功，才可提交代碼到配置庫 ；持續(xù)集成的狀態(tài)必須實時可視化顯示給所有人；大系統持續(xù)集成需分層分級，建立各層次統一的測試策略。持續(xù)集成提供產品質量的快速反饋，保證隨時擁有可工作的軟件參見附件：持續(xù)集成解讀.pptPage 51Page 51敏捷工程實踐：Anatomy系統解剖什么是AnatomyAnatomy（解剖）來源于電信行業(yè)，從用戶視角全面展示復雜產品系統的功能依賴關系，讓整個系統的功能按自底向上逐步有序

46、地開發(fā)和集成。Anatomy的關鍵要點Anatomy不是系統架構視圖，圖中的Block是表示系統提供給用戶使用的一個功能（capability），是站在純用戶視角，不包含設計信息；Anatomy中的依賴關系是用戶使用系統功能的依賴關系，而不是設計或架構上的依賴關系；Anatomy是系統全視圖，由最了解系統的工程師繪制出基線，在增量開發(fā)時需不斷刷新。Anatomy幫助團隊理解系統全局，制定合理的迭代計劃Anatomy的好處Anatomy是迭代計劃制定的重要依據，保證系統按照類似生物自然生長的順序自底向上有序地開發(fā)和集成（Organic integration）；Anatomy也可作為可視化工具，

47、通過標識圖中每一個功能的狀態(tài)，使項目整體進展一目了然，并能極大增強團隊的信心；有助于團隊從增量交付向交付全系統的思維轉變；是很好的培訓教材，幫助工程師了解全系統。Anatomy樣例目錄敏捷概述正確理解敏捷我司敏捷開發(fā)實施策略PSST發(fā)文解讀09年敏捷實施指導我司敏捷案例Page 53 關于敏捷推行的指導意見 華為PSST函（2009）012號 簽發(fā)人：徐直軍 敏捷/迭代開發(fā)已經成為業(yè)界主流軟件開發(fā)方法，與瀑布模式相比，其在應對需求變化、提升產品質量、加快需求響應、縮短交付周期、提前暴露風險、及時激勵員工以及平滑人力資源的使用等方面具有明顯優(yōu)勢。為了保證敏捷/迭代開發(fā)在我司有組織、有步驟、有策劃

48、的開展和推行，現明確要求如下：以業(yè)務目標（交付周期、質量）為導向牽引敏捷推行，所有敏捷度量都以交付周期和交付質量為基礎，而不能為了敏捷而敏捷。公司敏捷推行分三步走：項目級敏捷、版本級敏捷和產品級敏捷，每一步要控制好入口，降低風險。09年重點全面推進項目級敏捷，版本級敏捷進行試點。2010-2011在版本級敏捷試點基礎上進行逐步推廣。項目級敏捷要求的實踐包括：項目級持續(xù)集成、開發(fā)測試拉通、迭代、可視化管理、回顧會議、自動化測試、站立會議、用戶代表參與現場迭代特性驗收；其他敏捷實踐項目組根據情況自己選擇。所有PL都要成為合格的Scrum Master（關鍵職責是輔導團隊用正確的敏捷方法做事），在P

49、L任職資格中將增加該要求。Page 54關于全面推廣持續(xù)集成的決議華為PSST函（2009）022號簽發(fā)人:徐直軍 持續(xù)集成是業(yè)界的優(yōu)秀軟件開發(fā)實踐，對降低軟件開發(fā)風險、增強項目可視性、提高團隊自信心、提升軟件開發(fā)效率和質量效果明顯。為保證持續(xù)集成在我司有組織、有步驟、有策劃地開展和推行，經PSST討論，現明確要求如下：09年全面開展項目級和產品級持續(xù)集成，通過持續(xù)集成行為自檢表牽引開發(fā)人員樹立正確的持續(xù)集成理念，同時在行為上落實要求，不斷改進持續(xù)集成工作。本地構建是確保持續(xù)集成成功的關鍵，開發(fā)人員須首先在本地構建（編譯鏈接、單元測試、代碼靜態(tài)檢查）成功后，方可提交代碼到配置庫。完善持續(xù)集成工

50、具支撐分層、分級、分布式大規(guī)模部署策略，與周邊系統有效對接，拉通開發(fā)領域相關自動化活動。持續(xù)集成給配置管理帶來較多改變，配置管理業(yè)務和IT與持續(xù)集成必須拉通。持續(xù)集成要和系統測試拉通，由測試體系建立持續(xù)集成的統一端到端測試策略。持續(xù)集成大規(guī)模推廣的專項物料，由測試統一規(guī)劃和部署，持續(xù)集成服務器可采用ATCA。每個產品落實專人負責持續(xù)集成工作，進行產品持續(xù)集成的策略制定、環(huán)境搭建和維護、問題協調解決，支撐產品全面部署。Page 55軟件代碼質量要求及樣例華為PSST函（2009）029號 簽發(fā)人:徐直軍 編寫簡潔、可維護、可靠、可測試、高效和可移植代碼是每一位軟件開發(fā)人員的責任和目標。針對當前突

51、出的軟件腐化問題，明確軟件代碼的質量要求如下：簡潔：代碼簡潔就是易于理解并且易于實現。盡量編寫少但功能完備的簡潔代碼，日后可以隨時為額外的功能添加更多的代碼。提高簡潔的方法有：單一功能、強內聚且低耦合、避免函數過長、避免嵌套過深、避免重復等?？删S護：代碼可維護性是軟件被修改的能力，包括糾錯、改進、新需求或功能規(guī)格變化的適應能力。面對進度壓力開發(fā)人員容易忽略代碼的可維護性。我們要謹慎的編程，使系統中每個組件盡可能地“保護”自己；同時不要做任何假想，隨著代碼的增長，沒有記錄下來的假想會不斷地造成缺陷。提高可維護性的方法有：使用好的編碼風格、編碼清晰、降低代碼復雜度、盡可能減少全局變量等。可靠：代碼

52、可靠性是軟件在給定時間間隔和環(huán)境條件下，按設計要求成功運行程序的概率。提高可靠性的方法有：使用安全的函數和數據結構、編譯時打開所有的警告開關并清除所有警告、使用靜態(tài)檢查工具分析代碼并清除所有警告、檢查所有的輸入、驗證所有的運算、檢查所有返回值、避免強制轉換、避免內存越界、避免內存泄漏等。可測試：代碼可測試性是指軟件發(fā)現故障并隔離、定位故障的能力，以及在一定的時間和成本前提下，進行測試設計、測試執(zhí)行的能力。提高可測試性的方法有：盡量減少依賴、保持代碼可觀測性、限制代碼復雜度等。高效：代碼性能高效是盡可能少地占用系統資源，包括內存和執(zhí)行時間。提高性能的方法有：合理利用語言特性和編譯選項，例如禁用C

53、+的RTTI，可以減少可執(zhí)行文件大小；代碼內嵌，可以減少方法調用的開銷；將不變條件的計算移到循環(huán)體外；利用并行和線程來防止串行操作；避免或者移除過多的鎖；添加緩存或者緩沖層，以加快較慢的數據訪問，或防止漫長的重復計算；創(chuàng)建資源庫，以減少分配對象的開銷?？梢浦玻嚎梢浦残允菫榱嗽谠瓉碓O計的特定環(huán)境之外運行，對系統進行修改的能力。提高可移植性的方法有：使用標準庫函數，并且把它們和類似ANSIISO C標準中定義的頭文件放在一起使用；盡可能使所寫的程序適用于更多的編譯環(huán)境；把不可移植的代碼分離出來。Page 56PSST敏捷發(fā)文要點解讀：敏捷實施三步走策略三步走核心思想：敏捷轉型成功的關鍵是團隊意識的

54、轉變和能力的提升，通過三步走的策略，實現人員技能、工程能力、流程、工具等方面的積累，在風險可控的情況下逐步達到全面敏捷的目標；項目級敏捷：實施的范圍限定在TR2-TR4A，聚焦單個項目組或多個項目組協同的開發(fā)過程和能力改進；對IPD流程的對外交付點及非研發(fā)領域（用服、Marketing等）沒有影響；版本級敏捷：版本級敏捷實施的范圍將擴展到TR1-TR6，對架構、設計、非研發(fā)領域協同（用服，Marketing等）等多個方面能力提出了更高的要求；版本具備按特性向最終客戶分批交付的能力，加快對用戶響應速度（TR1表示在版本級敏捷下的TR1定義和當前IPD流程中定義的TR1將會有區(qū)別）；產品級敏捷：實

55、施范圍擴展到產品的全生命周期（含所有版本），以更小的需求包接納客戶需求，給用戶提供更快的市場響應速度，將在規(guī)劃、組織結構、主流程、市場、財務、供應鏈、商務等方面帶來巨大挑戰(zhàn)。版本級TR1開 發(fā)概 念計劃CHARTER驗 證CDCPPDCP發(fā) 布生命周期ADCPGATR2TR3TR4TR4ATR5TR6項目級產品級敏捷實施從內向外逐步擴大“迭代”循環(huán)范圍Page 57PSST敏捷發(fā)文要點解讀： 三步走之項目級敏捷項目級敏捷影響范圍聚焦在TR2TR4A的單個項目組或多個項目組協同的開發(fā)過程和能力改進實踐要求要求實踐：持續(xù)集成、開發(fā)測試拉通、迭代、回顧會議、自動化測試、站立會議、用戶代表參與現場迭代

56、特性驗收建議實踐：引入敏捷團隊的PO和Scrum Master角色、結對編程、TDD、特性團隊、重構好處培養(yǎng)人員，儲備敏捷實踐技能、帶來質量和效率的提升激發(fā)團隊士氣，逐步掌握敏捷思想入口條件適用于所有項目組風險評估已經在公司很多產品試點，風險小，可以全面推廣Page 58PSST敏捷發(fā)文要點解讀： 三步走之版本級敏捷版本級敏捷影響范圍范圍擴展到TR1-TR6具備按特性向用戶分批交付的能力，保持一個主干要求系統設計、開發(fā)和測試、資料、硬件的協同迭代交付模式的改變帶來資料、市場、用服等相應的改變實踐要求可能包含的實踐：系統Anatomy、one track、需求管理（需求優(yōu)先級不斷刷新）好處縮短交

57、付周期；降低版本維護成本；提高需求命中率；整個版本的質量和效率提升入口條件版本中的項目組已具備敏捷迭代能力版本的架構風險可控（如大部分增量開發(fā)產品）版本人員具備較好的系統設計能力具備良好的持續(xù)集成和自動化測試能力風險評估在能力不具備的情況下啟動可能會帶來如下問題：架構和設計能力不足，導致后續(xù)迭代對前面工作帶來大量返工自動化測試能力不足，無法應對密集的集成測試交付前驗收不充分，影響發(fā)布質量Page 59PSST敏捷發(fā)文要點解讀：三步走之產品級敏捷產品級敏捷影響范圍聚焦產品全生命周期將敏捷精益思想（降低批量、減少任務等待時間）融入到產品端到端流程中；從一個R版本中多個小版本的串行開發(fā)轉變到基于小需

58、求包的并行開發(fā)，并且始終保持一個主干交付周期進一步縮短對組織、流程、財務、供應鏈、商務等帶來影響實踐要求可能包含的實踐：產品需求管理、版本規(guī)劃和策略、多個并行需求包開發(fā)團隊的協同和管理好處全流程角度減少需求等待時間，最大限度的縮短TTM，更聚焦客戶價值入口條件具備成熟的版本級迭代能力風險評估精細化的需求管理對管理者和需求分析人員提出更高的要求多個需求包團隊并行開發(fā)，更容易導致合入主版本產生設計沖突Page 60PSST敏捷發(fā)文要點解讀：09年敏捷實施要求敏捷成功與否的衡量標準是業(yè)務結果（質量、TTM）的改進， 09年PSST改進目標為質量提升30%，通過質量提升縮短TTM ；所有產品的在研版本

59、均可以進行項目級敏捷實踐，實施時應盡可能覆蓋多的項目組，最低要求為：所有主力產品的在研軟件版本均要在TR2-TR4A之間進行項目級敏捷實踐，每個軟件版本至少選擇一個項目組實施；版本級敏捷可以試點，但需對入口條件進行嚴格審核以降低風險，入口條件包括：版本中的項目組已具備敏捷迭代能力版本架構清晰風險可控，通過AR點評審（DRB或架構委員會）版本人員具備良好的架構設計和系統設計能力具備版本級持續(xù)集成能力和自動化測試能力目錄敏捷概述正確理解敏捷我司敏捷開發(fā)實施策略PSST發(fā)文解讀09年敏捷實施指導首次實施敏捷的參考步驟敏捷角色在我司可能的角色人選項目組團隊的組建方式項目級敏捷實施場景我司敏捷案例Pag

60、e 62首次實施敏捷的參考步驟八步曲備注：基于業(yè)界和公司敏捷成功案例，總結出上述步驟，僅供參考。Page 63首次實施敏捷參考步驟方法、目標和誤區(qū)（一）步驟方法目標誤區(qū)1.思想動員領導動員講話敏捷松土成功團隊現身說法各級主管承諾上下同欲躍躍欲試信心滿滿領導強壓走過場2.差距分析人力技能分析代碼架構差距分析環(huán)境和工具分析技能差距清晰化代碼架構差距清晰化環(huán)境和工具差距清晰化不重視，投入分析人員能力不足，導致分析不深入，無實際指導意義3.1.環(huán)境和工具準備成立環(huán)境（配置庫，CI環(huán)境，必要硬件）專項改進小組成立工具選型和開發(fā)小組，完成開發(fā)環(huán)境，代碼靜態(tài)檢查，持續(xù)集成工具和架構評估檢查工具環(huán)境改造完全適