敏捷開發(fā)全景視圖(流程、方法和最佳實踐).ppt

1、敏捷開發(fā)全景視圖（流程、方法和最佳實踐）,鐘瑋軍 2016-02-25,目 錄 Contents,敏捷 vs 傳統(tǒng) 敏捷開發(fā)流程框架 敏捷方法和最佳實踐 思考與答疑,敏捷 vs 傳統(tǒng),IT項目管理方法的發(fā)展歷史,1960,1970,1980,1990,2000,2010,SDLC,WATERFALL,RAD,PMBOK ITIL PRINCE Zachman,DSDM,RUP XP PRINCE2 CRYSTAL,SCRUM AGILE MANIFESTO FEA TOGAF 8.0,LEAN,KANBAN,軟件開發(fā)生命周期（SDLC）,/wiki

2、/Systems_development_life_cycle,傳統(tǒng)軟件開發(fā)模式,傳統(tǒng)瀑布式軟件開發(fā)方式,向迭代式軟件開發(fā)方式轉(zhuǎn)變（RUP框架）,傳統(tǒng)軟件開發(fā)模式存在的問題,傳統(tǒng)軟件件開發(fā)過程的常見癥結(jié) 交付周期長；害怕需求變更；中間過程不可控；測試周期被一縮再縮；最終結(jié)果差強人意 與“唯快不破”的互聯(lián)網(wǎng)經(jīng)濟格格不入,敏捷軟件開發(fā)模式 由傳統(tǒng)迭代式軟件開發(fā)模式發(fā)展而來，Time-Boxed 拋開傳統(tǒng)軟件開發(fā)模式的繁文縟節(jié)，強調(diào)產(chǎn)品價值、團(tuán)隊協(xié)作、客戶參與、先期驗證、簡化流程、擁抱變化 總結(jié)吸收成功軟件項目研發(fā)的最佳實踐；與現(xiàn)代管理思想相輔相成 前期有學(xué)習(xí)成本，后期會獲益匪淺,敏捷軟件開發(fā)模式,

3、Source: Forrester Research, Inc.,趨勢：敏捷開發(fā)逐漸成為主流模式,2009 Q3,2014,Growth,敏捷開發(fā)帶來的好處,TOP 5 reported benefits:,Improved quality (56%),More opportunities for mid-course corrections (56%),Overall improved customer and business satisfaction (38%),Better business-IT alignment (37%),Improved time to market (32%

4、),A lot more than velocity,質(zhì)量改善,利于中途修正,總體改善客戶和業(yè)務(wù)的滿意度,商業(yè)需求與IT實施更加匹配,更快投入市場,Source: 2013 Forrester Research, Inc.,敏捷開發(fā)宣言,Manifesto for Agile Software Development Individuals and interactions over processes and tools 人和交互 重于 過程和工具 Working software over comprehensive documentation 可以工作的軟件 重于 面面俱到的文檔 Cus

5、tomer collaboration over contract negotiation 客戶合作 重于 合同談判 Responding to change over following a plan 隨時應(yīng)對變化 重于 遵循計劃 雖然右邊也有其價值，但我們認(rèn)為左項更加重要,敏捷原則 (Agile Principles),Satisfy the Customer Welcome Change Deliver Frequently Work as a Team Motivate People Communicate Face-to-Face,Measure Working Software M

6、aintain Constant Pace Excel at Quality Keep it Simple Evolve Designs Reflect Regularly,敏捷開發(fā)價值觀,專注：由于我們在一段時間內(nèi)只專注于少數(shù)幾件事情，所以我們可以很好地合作并獲得優(yōu)質(zhì)的產(chǎn)出。我們能夠更快地交付有價值的事項。 公開：在團(tuán)隊合作中，大家都會表達(dá)我們做得如何，以及遇到的障礙。我們發(fā)現(xiàn)將擔(dān)憂說出來是一件好事，因為只有這樣才能讓這些擔(dān)憂及時得到解決。 尊重：因為我們在一起工作，分享和成功失敗，這有助于培養(yǎng)并加深互相之間的尊重，并幫助彼此成為值得尊重的人。 承諾：由于對自己的命運有更大的掌握，我們會有更

7、堅強的信念獲得成功。 勇氣：因為我們不得單打獨斗，我們能夠感受到支持，而且掌握更多的資源。這一切賦予我們勇氣去迎接更大的挑戰(zhàn)。,從傳統(tǒng)到敏捷：思維的轉(zhuǎn)變,形而上者謂之道，形而下者謂之器。 形而上者起于學(xué)、行于理、止于道，形而下者起于教、行于法、止于術(shù)。,從重視“流程”到重視“原則” 道本器末，不忘初心 做正確的事比正確地做事更重要 如何看待流程、方法、最佳實踐在敏捷開發(fā)中的作用 無其器則無其道，器和道一樣重要 上善若水，原則的“剛性”和流程的“柔性”,從傳統(tǒng)到敏捷：認(rèn)識誤區(qū),從傳統(tǒng)到敏捷：阻礙和要點,改變我們的商業(yè)文化,采用敏捷技術(shù)實踐,改變我們的IT文化,以一種敏捷的態(tài)度使用我們現(xiàn)有的工具,

8、采用新的敏捷開發(fā)工具,采用敏捷管理實踐,從傳統(tǒng)到敏捷：關(guān)鍵因素,改變我們的商業(yè)文化,采用敏捷管理實踐,改變我們的IT文化,采用敏捷技術(shù)實踐,采用新的敏捷開發(fā)工具,以一種敏捷的態(tài)度使用我們現(xiàn)有的工具,敏捷開發(fā)流程框架,產(chǎn)品研發(fā)：一個持續(xù)的過程,What？,How？,Management is doing things right; leadership is doing the right things. (Peter Drucker),敏捷開發(fā)流程框架：Scrum,注：Scrum是最為流行的敏捷開發(fā)流程框架之一,What？,How？,Scrum框架：簡介,Scrum 是一個用于開發(fā)和維持復(fù)雜產(chǎn)

9、品的框架，是一個增量的、迭代的開發(fā)過程。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint)。在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表條目的體現(xiàn)形式通常為用戶故事。Scrum團(tuán)隊總是先開發(fā)對客戶具有較高價值的需求。在Sprint中，Scrum團(tuán)隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進(jìn)行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlog

10、。在每個迭代結(jié)束時，Scrum團(tuán)隊將遞交潛在可交付的產(chǎn)品增量。Scrum起源于軟件開發(fā)項目，但它適用于任何復(fù)雜的或是創(chuàng)新性的項目。 要素： 周期：Product Release=Time-Boxed Sprint=Daily Continous Delivery 團(tuán)隊：Product Owner，Scrum Master，Dev Team(Cross-Functional) 工件：Product Backlog，Sprint Backlog，Product Increment 活動：Sprint Planning Meeting/Review Meeting/Retrospective Mee

11、ting，Daily Scrum Meeting，Product Backlog Refinement 度量：Burndown圖、Burnup圖、Velocity,Scrum（一） ：迭代周期框架,迭代周期框架： Product ReleasePortfolio=Product=Release=Sprint=Daily Working,What？,How？,Scrum（二）：團(tuán)隊,Build The Right Thing,Build The Thing Right,Build It Fast,Scrum Team Achievement-oriented Customer-oriented

12、Committed Motivated Self-organized Empowered Skilled,Scrum團(tuán)隊：團(tuán)隊文化,共贏的文化 團(tuán)隊成功 個人發(fā)展 立足現(xiàn)實 挑戰(zhàn)極限,Scrum團(tuán)隊：角色分工概覽,Scrum團(tuán)隊：Product Owner職責(zé),主要負(fù)責(zé)確定產(chǎn)品的功能和達(dá)到要求的標(biāo)準(zhǔn)，指定軟件的發(fā)布日期和交付的內(nèi)容，同時有權(quán)利接受或拒絕開發(fā)團(tuán)隊的工作成果 PO在Scrum中承擔(dān)了多項職責(zé) 產(chǎn)品經(jīng)理：愿景和方向，結(jié)果負(fù)責(zé) 需求分析：業(yè)務(wù)分析和需求分析 需求管理：維護(hù)、終止和變更 項目管理：優(yōu)先級排序和項目狀態(tài)跟蹤 質(zhì)量保障：檢查產(chǎn)品結(jié)果 客戶代表：產(chǎn)品體驗/接受拒絕 PO對外承擔(dān)

13、了與產(chǎn)品干系人交流溝通的職責(zé) 老板、客戶和用戶、營銷和銷售、,Scrum團(tuán)隊： PO的職責(zé)關(guān)系,Product Owner屬于研發(fā)角色，但與戰(zhàn)略、市場和銷售等公司其它角色存在密切合作關(guān)系，需要掌握跨界知識和語言表達(dá)。,圖示表現(xiàn)了產(chǎn)品管理四種角色之間的關(guān)系和分工定義，但根據(jù)項目規(guī)模不同，某一成員可能身兼數(shù)職。,Scrum團(tuán)隊： PO能力要求,業(yè)務(wù)分析能力（Business Analysis） 工程技術(shù)能力（Engineering） 領(lǐng)導(dǎo)和協(xié)調(diào)能力（Leadership & Coordination）,Business Analysis CapabilitiesHelping organizati

14、ons develop the capabilities to achieve Enterprise Agility,Understand Needs of the Customer,Develop Product Strategy,Manage Product Portfolio,Achieve Customer Acceptance,Define Business Requirements,Product Strategy,Solution Requirements,Develop Product,Launch Product,Operate and Support Product,Def

15、ine Product Backlog,Establish Product Vision,Define Product Roadmap,Plan Launch,Engage Stakeholders,Planning,Coordinate Launch,Establish Development Environment,Manage Suppliers,Ensure Process Adherence,Identify and Remove Impediments,Ensure Internal Communication,Maintain Work Environment,Develop T

16、eam,Support Operations,Provide Customer Support,Support Implementation,Coordinate Work,Maintain Architecture,Understand Requirements,Maintain Product Quality,Design and Engineer Solution,Deploy Product,Integration Testing,Learn from Outside Sources,Commit To Agility,Manage Risks,Provide Job Training

17、,Everyone,Environment,Perform Maintenance and Customizations,Product Development,Engineering CapabilitiesHelping organizations develop the capabilities to achieve Enterprise Agility,Understand Needs of the Customer,Develop Product Strategy,Manage Product Portfolio,Achieve Customer Acceptance,Define

18、Business Requirements,Product Strategy,Solution Requirements,Develop Product,Launch Product,Operate and Support Product,Define Product Backlog,Establish Product Vision,Define Product Roadmap,Plan Launch,Engage Stakeholders,Planning,Coordinate Launch,Establish Development Environment,Manage Suppliers

19、,Ensure Process Adherence,Identify and Remove Impediments,Ensure Internal Communication,Maintain Work Environment,Develop Team,Support Operations,Provide Customer Support,Support Implementation,Coordinate Work,Maintain Architecture,Understand Requirements,Maintain Product Quality,Design and Engineer

20、 Solution,Deploy Product,Integration Testing,Learn from Outside Sources,Commit To Agility,Manage Risks,Provide Job Training,Everyone,Environment,Perform Maintenance and Customizations,Product Development,Leadership & Coordination CapabilitiesHelping organizations develop the capabilities to achieve

21、Enterprise Agility,Understand Needs of the Customer,Develop Product Strategy,Manage Product Portfolio,Achieve Customer Acceptance,Define Business Requirements,Product Strategy,Solution Requirements,Develop Product,Launch Product,Operate and Support Product,Define Product Backlog,Establish Product Vi

22、sion,Define Product Roadmap,Plan Launch,Engage Stakeholders,Planning,Coordinate Launch,Establish Development Environment,Manage Suppliers,Ensure Process Adherence,Identify and Remove Impediments,Ensure Internal Communication,Maintain Work Environment,Develop Team,Support Operations,Provide Customer

23、Support,Support Implementation,Coordinate Work,Maintain Architecture,Understand Requirements,Maintain Product Quality,Design and Engineer Solution,Deploy Product,Integration Testing,Learn from Outside Sources,Commit To Agility,Manage Risks,Provide Job Training,Everyone,Environment,Perform Maintenanc

24、e and Customizations,Product Development,Scrum團(tuán)隊： Scrum Master職責(zé),/community/articles/2014/may/what-it-is-that-a-scrum-master-does-all-day-long,主要負(fù)責(zé)整個Scrum流程在項目中的順利實施和進(jìn)行，以及清除擋在客戶和開發(fā)工作之間的溝通障礙，使得客戶可以直接驅(qū)動開發(fā)。,Scrum團(tuán)隊： Scrum Master能力要求,出色的溝通和決策能力 能及時、清楚、明確地傳播信息； 知道什么時候做出決定，不必要再

25、做分析； 平衡短期和長期目標(biāo)，快速在團(tuán)隊和Product Owner之間達(dá)成一個共同的愿景； 促進(jìn)團(tuán)隊合作的能力 能夠促進(jìn)和培養(yǎng)團(tuán)隊合作的能力，能夠診斷、理解和幫助團(tuán)隊的日常變化； 持續(xù)衡量團(tuán)隊工作狀況，并推動必要的行動，以改進(jìn)團(tuán)隊的工作； 鼓舞和激勵能力 促進(jìn)團(tuán)隊活力，鼓舞、表揚和獎勵團(tuán)隊中做得最好的人，宣揚突出的行為、技能和成就； 偉大的工作態(tài)度，總是尋找方法來改變工作，而不是認(rèn)同為什么做出改變是不可能的； 抗壓能力 在壓力環(huán)境下仍能保持鎮(zhèn)定，出色工作 解決沖突能力 促進(jìn)建設(shè)性的辯論，使得產(chǎn)生更好的決策和共同愿景 建設(shè)性地解決分歧和沖突，知道什么時候讓其他人也參與進(jìn)來 在所有交往中，體現(xiàn)出

26、情感成熟度（周到、客觀、正直、可靠） 即使在他/她不同意的時候，也會支持哪些已經(jīng)做出的決定 敏捷開發(fā)實踐能力 Backlog跟蹤，burndown圖，會議組織，計劃能力，進(jìn)度跟蹤，風(fēng)險管理，組織變革、團(tuán)隊成長，敏捷開發(fā)實踐，持續(xù)集成/交付/部署，.,參考：/community/articles/2007/april/the-right-skill-set-the-right-mind-set-the-right,Scrum團(tuán)隊： Scrum Master特質(zhì),專注并細(xì)心 確保團(tuán)隊行為始終與驗收標(biāo)準(zhǔn)和項目目標(biāo)（愿景）保持一致； 通過良好的組

27、織方法分配工作任務(wù)，減少失誤； 團(tuán)隊合作者 勇于承擔(dān)任何能夠幫助團(tuán)隊的任務(wù)，并以身作責(zé)（比如，團(tuán)隊決定加班來完成Sprint目標(biāo)，Scrum Master應(yīng)該和團(tuán)隊在一起） 善于解決問題的能力 是一個能快速獲取信息去解決問題的老手； 幫助團(tuán)隊識別沖突的優(yōu)先級，并表達(dá)并逐級向上反應(yīng)不能快速的問題； 值得信賴 信守承諾，說到做到 親近 平易近人，風(fēng)度翩翩 高度的決心和毅力 這是成功的關(guān)鍵性因素。因為，對于推動隊員思維模式的轉(zhuǎn)變是非常困難的，更不用提整個組織的轉(zhuǎn)變了，特別是在看到組織內(nèi)部有失敗案例的時候； 你必須有足夠的耐心來幫助團(tuán)隊一步一步地轉(zhuǎn)變，因為要想看到積極的趨勢是會花很多時間和精力的。在出

28、現(xiàn)“信任危機”的時候（非?？赡艹霈F(xiàn)），你必須要有足夠的耐心來說服他人、影響他人； 既要理解標(biāo)準(zhǔn)化的Scrum模式，又要根據(jù)自己組織的固有特點來實際地運用它 這是成功的決定性因素。因為沒有任何兩家公司是相同的； 這也要求你要比較溫和的推進(jìn)轉(zhuǎn)變。記?。河賱t不達(dá)； Scrum Master需要制定一個比較長遠(yuǎn)的推進(jìn)計劃，然后步步為營，直到團(tuán)隊自己找到基于Scrum框架和思維模式的最佳工作方法； 準(zhǔn)備好挑戰(zhàn)他人并接受他人的挑戰(zhàn) 向管理層尋求幫助固然有用，但通常比較困難。因此在適當(dāng)?shù)臅r候記得去挑戰(zhàn)你的老板。很多成功的變革通常是由下至上發(fā)起的，不要一味地依賴?yán)习宓闹甘荆?若在實施過程中受到外界的挑戰(zhàn)和動

29、搖，一定要對自己、對團(tuán)隊、對組織有堅定的信心。如果外界的動搖具有10分的摧毀力，那么你自己的動搖則具有100分； 持續(xù)改進(jìn)自我的愿望 這點不僅適用于團(tuán)隊成員，更是適用于Scrum Master自身。因為通過自我的持續(xù)改進(jìn)，你才能有效的影響團(tuán)隊成員，讓大家積極的凝聚在一起，直到找到最高效的工作方法這一終極目標(biāo)。,Scrum團(tuán)隊： Dev Team職責(zé),主要負(fù)責(zé)軟件產(chǎn)品在Scrum規(guī)定流程下進(jìn)行開發(fā)工作，人數(shù)控制在510人左右，每個成員可能負(fù)責(zé)不同的技術(shù)方面，但要求每個成員必須要有很強的自我管理能力，同時具有一定的表達(dá)能力；成員可以采用任何工作方式，只要能達(dá)到Sprint的目標(biāo)。 主要職責(zé) 定義（

30、分解）工作任務(wù) 評估工作量 開發(fā)產(chǎn)品 確保質(zhì)量 完善過程,Scrum團(tuán)隊：Dev Team(1) 跨職能團(tuán)隊,Scrum團(tuán)隊： Dev Team(2) 特性團(tuán)隊,Component Team,Feature Team,VS.,Component Team的組織方式會導(dǎo)致瀑布式的開發(fā)流程，以便協(xié)調(diào)團(tuán)隊間的工作任務(wù)。,Feature Team組織方式的成功依賴于團(tuán)隊能力，以及團(tuán)隊對于重構(gòu)、持續(xù)集成、自動化測試等敏捷開發(fā)工具和實踐的使用。,Scrum團(tuán)隊： Dev Team成員能力拓展,成就全棧工程師,瀑布式： 團(tuán)隊成員專司一職，難以獲得橫向拓展,SCRUM： 人們可能主要技能不盡相同，如有人擅長開

31、發(fā)而另外的人擅長測試，但是，在Scrum團(tuán)隊里，我們鼓勵團(tuán)隊成員學(xué)習(xí)新的領(lǐng)域技能，嘗試在新的領(lǐng)域工作，團(tuán)隊成員跨領(lǐng)域互相幫助完成一項產(chǎn)品特性。比如，一個“架構(gòu)師”可能要寫自動化測試代碼，而一個“測試人員”則可能要分析業(yè)務(wù)。,SCRUM（三）：SCRUM工件,SCRUM工件 核心工件：Product Backlog，Sprint Backlog， Shippable Product Increment； 其它工件：Dependencies / Blocker list；,SCRUM工件：Product Backlog,Product Backlog是條目化/量化的用戶需求，它將需求文檔中需要實際

32、開發(fā)的需求（包括功能性和非功能性需求）條目化地表達(dá)出來。 Product Owner維護(hù)，用場景描述的用戶需求(Story)列表 經(jīng)過優(yōu)先級排序和工作量評估的 優(yōu)先級越高的條目，User Story描述粒度越細(xì) 反映了業(yè)務(wù)的計劃,SCRUM工件：PB(1)Items,My primary rule for including any item in the product backlog is that the work must be something the product owner can understand and can reasonably prioritize agains

33、t features. So if you do choose to include PBIs of typetechnical work, you will need to make the value of the item clear to the product owner. ,SCRUM工件：PB(2)User Story描述,As a , I want a So that I can get .,基于目標(biāo)和場景驅(qū)動，體現(xiàn)業(yè)務(wù)價值,SCRUM工件：PB(3)User Story 粒度,按照業(yè)務(wù)優(yōu)先級次序，將大粒度的用戶故事拆解為小粒度的用戶故事，并依次經(jīng)過評估后安排進(jìn)入Release

34、計劃和Sprint計劃,SCRUM工件：PB(4)User Story優(yōu)先級,SCRUM工件：PB(5)User Story評估,用戶故事INVEST模式 Independent: 減少依賴，便于計劃 Negotiable: 通過協(xié)作添加細(xì)節(jié) Valuable: 對客戶有價值 Estimable: 太大或太模糊的用戶故事，無法評估 Small: 可以在由一個團(tuán)隊在一周內(nèi)完成 Testable: 有好的驗收原則 評估用戶故事的大小 Story Points Anchor Story，相對值評估 斐波那契數(shù)列和撲克牌游戲 貼墻技術(shù) 衡量團(tuán)隊Velocity 用46個Sprint來確定速率,SCRU

35、M工件：PB(6) 非功能性需求描述,Nonfunctional requirementsrepresent important system-level constraints that affect the design and testing of most or all items in the product backlog. Nonfunctional requirements are used to specify various characteristics such as system performance, accuracy, portability, reusabil

36、ity, maintainability, interoperability, capacity, platform fan-out, and so on. 以User Story方式描述NFR，有助于理解部分技術(shù)決策背后的原因，如： As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on. As the CTO, I want the system to use our existing orders database rather than crea

37、te a new one, so that we dont have one more database to maintain. As a user, I want the site to be available 99.999 percent of the time I try to access it, so that I dont get frustrated and find another site to use. As someone who speaks a Latin-based language, I might want to run your software some

38、day. As a user, I want the driving directions to be the best 90 percent of the time, and reasonable 99 percent of the time. 參考,SCRUM工件： Sprint Backlog,確保考慮到工作中所有細(xì)節(jié)：編碼、測試、代碼評審、會議、學(xué)習(xí)新技術(shù)、編寫文檔 Sprint tasks需要評估到小時 如果任務(wù)需時超過一天，嘗試分割成幾個小任務(wù) 如果團(tuán)隊認(rèn)為Sprint Backlog項目過多或過少，和產(chǎn)品負(fù)責(zé)人一起調(diào)整問題數(shù)量 團(tuán)隊確認(rèn)Sprint目標(biāo) 如果工作不清晰，可以先建一

39、個粗粒度的Sprint Backlog，然后再分解 所有任務(wù)項都分配給團(tuán)隊成員 每日更新剩余工作評估 團(tuán)隊成員對任務(wù)的DoD(Definition of “Done”)應(yīng)該有共同的理解 只計算全力以赴完成所需要的時間，剩下的交給燃盡(Burndown)圖解決,Sprint Backlog是Scrum團(tuán)隊在Sprint Planning會議中確認(rèn)的待辦任務(wù)列表，映射到傳統(tǒng)項目管理理論中就是WBS，而且是典型的采用面向交付物的任務(wù)分解方法得到的WBS。,SCRUM工件： Impediments List(1),Impediments（障礙）是指任何阻止團(tuán)隊有效工作的事或物。 部分障礙可以由團(tuán)隊自己

40、解決，其中一些障礙的跟蹤最好能對全團(tuán)隊可見。 部分障礙超出團(tuán)隊能夠解決的范圍，需要Scrum Master找出相關(guān)的干系人來一起解決 也有一些小而重要的障礙，可能是公司組織所固有的，任何一個團(tuán)隊無法獨立解決，需要公司層面企業(yè)文化、組織架構(gòu)的變革來解決，這需要Scrum Master推動管理層完成。,SCRUM工件： Impediments List(2),10大典型障礙 會議規(guī)則沒能被遵循 產(chǎn)品遠(yuǎn)景和Sprint目標(biāo)不清晰 沒有產(chǎn)品負(fù)責(zé)人負(fù)責(zé)回答提問 產(chǎn)品Backlog未能按商業(yè)價值區(qū)分優(yōu)先級 并不是所有負(fù)責(zé)交付產(chǎn)品的人員都是團(tuán)隊里的成員 Scrum Master還要處理其他任務(wù)，不能集中精力

41、 團(tuán)隊人數(shù)過多（多于7個開發(fā)人員） 團(tuán)隊沒有能坐在一起工作的空間 團(tuán)隊的Sprint Backlog混亂 以障礙Backlog方式管理障礙 把所有已知的障礙加入到障礙Backlog的“新事項”欄中 按優(yōu)先級順序排列“新事項”欄中的障礙問題 每當(dāng)您開始著手解決一個障礙問題時，將它移至“正在處理事項”欄中 盡快解決這個障礙 障礙得到解決時，將它移到“已完成”事項欄中 在Scrum每日例會和Sprint回顧會議中收集新的障礙問題,Scrum工件：Definition of “Done”,對于Scrum工件中的條目，團(tuán)隊一起定義“Done”（“完成”）的真實內(nèi)在含義，以免在評估項目時發(fā)生誤解和分歧。

42、“Done”的幾個例子： Design, coding, unit testing, integrated Static analysis, refactored Acceptance tested, deployable,/community/articles/2008/september/definition-of-done-a-reference,Scrum（四）：Scrum活動,Scrum活動：Release Planning(1),Who: Scrum Coach, Product Owner, Scrum Team, Scru

43、m Master, Key Stakeholders When: before release n+1 begins (.5 -2 days) How / Topic(s): PO presents the vision, strategy and goals. PO present key dates and milestones. PO presents draft of the prioritized backlog. Discussion to understand user stories. Review rough estimates + prioritized features.

44、 Agreement on Sprint length (in weeks) and target release dates. Release Plan is organized by scope (functionality) or time (release every N sprints). Continual Planning. The initial release plan is a blueprint to get started and will be revised.,Selected stories for the release,Product Vision,High

45、level prioritized goals & roadmap,Key risks and assumptions,Stakeholder consensus,Prioritized product backlog,Goal: Establish the overall release schedule and determine in what sprint stories will likely be delivered.,Product Backlog (priority draft),Release Plan,Rough Estimates,產(chǎn)品負(fù)責(zé)人和團(tuán)隊一起對整個產(chǎn)品Backl

46、og進(jìn)行評估，提出劃分發(fā)行版本和Sprint計劃的主要依據(jù)。,Scrum活動：Release Planning(2),一個企業(yè)級Release Planning會議活動日程安排的示例：,Scrum活動：Sprint Planning(1),Who: Scrum Coach, Product Owner, Scrum Team, Scrum Master. When: before Sprint n+1 begins (2-3 hrs). How / Topic(s): PO presents the backlog items in priority order for review. Sto

47、ries with failed acceptance tests from prior sprints are added*. Discuss story creation for defects from prior sprints*. Review and clarify user stories. Breakdown larger stories and each story into tasks and acceptance criteria. Tasks are estimated in hours. 1 developer and tester assigned to be on

48、 point per story. Process continues until all available hours are used for the sprint.,Selected stories for the sprint,Sprint Plan,Prioritized product backlog,Teams capabilities (hours),Key risks and assumptions,Stakeholder consensus,Goal: Team to plan and agree on backlog items they can complete an

49、d confirm the tasks required to support acceptance.,Schedule risks / Business conditions,Release Plan,Prior Velocity,Story Effort Estimation,Scrum活動：Sprint Planning(2),一個分兩階段議程Spring計劃會議的例子： Sprint計劃會議1：產(chǎn)品負(fù)責(zé)人和團(tuán)隊一起，在先前評估的成果基礎(chǔ)上，定出Sprint目標(biāo)和既定產(chǎn)品Backlog。 Sprint計劃會議2：團(tuán)隊將既定產(chǎn)品Backlog中的每一項細(xì)化成多個任務(wù)，每個任務(wù)完成的時間限定

50、在一天內(nèi)。,Scrum活動：Daily Meeting,每日例會：有助于團(tuán)隊進(jìn)行自我組織。這是項目團(tuán)隊成員間的一個進(jìn)度協(xié)調(diào)會議。會議每天都在同一時間同一地點舉行。時間限定在15分鐘內(nèi)。 與會者：團(tuán)隊所有成員，Scrum Master，產(chǎn)品負(fù)責(zé)人（可選），相關(guān)人員（可選） 三個重要問題： 上次會議后我完成了什么？ 到下次會議開始我準(zhǔn)備做什么？ 有什么障礙阻止了我的工作進(jìn)度？ 更新Sprint Backlog，包括增減任務(wù)項、更新任務(wù)進(jìn)度和狀態(tài) 會議控制： 如果展開了一個問題的討論，提醒團(tuán)隊成員們注意把注意力集中在回答關(guān)鍵問題上 如果相關(guān)人員想發(fā)表些言論，禮貌地提醒他，該會議只允許讓小組成員討論。

51、,Scrum活動：Sprint Review Meeting,評審會議：在每個Sprint結(jié)束后，將這個Sprint的工作成果演示給Product Owner和其他相關(guān)的人員。 團(tuán)隊按照Backlog中的問題，逐個地介紹這次Sprint的結(jié)果，和演示新功能 如果產(chǎn)品負(fù)責(zé)人想要改變功能，添加一個新問題到產(chǎn)品Backlog中 如果對功能有一個新的想法，添加一個新問題到產(chǎn)品Backlog中 如果小組報告項目遇到阻礙現(xiàn)在還沒能解決，把該障礙加入到障礙Backlog 團(tuán)隊達(dá)成對這次Sprint的結(jié)果和整個產(chǎn)品的開發(fā)狀態(tài)的共識,Scrum活動：Sprint Retro Meeting,回顧會議：在每個Sp

52、rint結(jié)束后，對于當(dāng)前的迭代周期做一個階段性的總結(jié)，包括好的方面和不好的方面，幫助團(tuán)隊在下一個迭代中揚長避短，對于一個團(tuán)隊的健康發(fā)展很有好處。 主要指導(dǎo)原則：不管我們現(xiàn)在發(fā)現(xiàn)了什么問題，我們必須懂得并堅信每個人通過他們當(dāng)時所知的，他所擁有的技能和可得到的資源，在限定的環(huán)境下，都盡其所能做出了最好的成績 在畫板上寫上“我們的成功經(jīng)驗是什么（Well Done）”、“有什么能夠改進(jìn)（Needs Improvement）” 針對以上總結(jié)，制定團(tuán)隊完善的Action Items（可以合并到Impediments List），指定負(fù)責(zé)人和完成時間，Scrum Master帶領(lǐng)團(tuán)隊盡可能落實 一般可以從

53、以下方面來進(jìn)行回顧： 開發(fā)團(tuán)隊效率如何 開發(fā)團(tuán)隊合作如何 項目進(jìn)展曲線是否平穩(wěn) 開發(fā)團(tuán)隊前端和后端的分工如何 測試團(tuán)隊的缺陷報告率如何 開發(fā)周期中有沒有被嚴(yán)重Block的因素 有沒有需求方面的不明確導(dǎo)致Rework 在任務(wù)分配方面有沒有不均衡，導(dǎo)致個別人太忙或者太閑,Scrum（五）：度量,燃盡圖是在項目完成之前，對需要完成的工作的一種可視化表示。燃盡圖有一個Y軸（工作）和X軸（時間）。理想情況下，該圖表是一個向下的曲線，隨著剩余工作的完成，“燒盡”至零。燃盡圖向項目組成員和企業(yè)主提供工作進(jìn)展的一個公共視圖。 速度(Velocity)表示每一個團(tuán)隊每一次迭代所產(chǎn)生的故事點的數(shù)量。,Scrum回

54、顧：全景視圖,Scrum回顧：要素,思考：Scrum流程框架的問題,產(chǎn)品上線后的運營，是一種事件驅(qū)動的模式，每天都有問題需要優(yōu)先處理，不適合開發(fā)人員與運營人員合一的小型公司/小型團(tuán)隊 無法事先計劃不被打擾的固定周期 太短的周期也不行，有的任務(wù)會超過一個周期 UX/UI設(shè)計跟程序設(shè)計開發(fā)的周期搭配問題 不同平臺（iOS，Android，Web）開發(fā)周期搭配問題 App Store審核時間不一定 兩周的開發(fā)迭代周期公司仍不滿意，可不可以更快，做到極致？,流程框架演進(jìn)：Kanban Board,最輕量的流程管理方法 WIP限制（TOC限制理論） 限制每個狀態(tài)的最多項目 關(guān)注Cycle Time（平均

55、每個條目的完成時間） 流程狀態(tài)（列）可自行裁剪，適用于大小項目,Kanban: vs Scrum,Kanban工作流程（一）,http:/blog.crisp.se/2009/06/26/henrikkniberg/1246053060000,Kanban工作流程（二）,http:/blog.crisp.se/2009/06/26/henrikkniberg/1246053060000,更多流程框架比較,（更規(guī)范）,（更靈活）,每種方法都有一定的局限性 不要限制自己只使用某一種工具！,流程框架的組合使用示例,Story Backlog,Task Backlog,In Process,Task

56、Done,Story Backlog,Analysis,Design,Build,Test,Deploy,Inception,Elaboration,Construction,Transition,Tier 1 - Scrum,Tier 2 - Kanban,Tier 3 - Kanban,Epic,Feature,User Story,大型項目流程框架：Scrum of Scrums,Agenda Three questions What has my team done since we last met that might affect other teams? What will m

57、y team do before we meet again that might affect other teams? What problems are my team having that other teams might be able to help with? Discussion Discuss items kept on an Open Issues Backlog,企業(yè)級項目流程框架：SAFe,敏捷方法和最佳實踐,敏捷方法和最佳實踐概覽,戰(zhàn)略： - 機會畫布方法 - 商業(yè)模式畫布方法 - 精益畫布方法 - 價值主張畫布 - 企業(yè)架構(gòu)方法,需求： - 需求捕獲技術(shù) - 需

58、求建模技術(shù) - 需求User Story描述方法 - 需求優(yōu)先級評估方法 - User Story切分技術(shù) - User Story Mapping - UML用例建模技術(shù),反饋： - 數(shù)字化評估方法,實現(xiàn)： - 敏捷架構(gòu)設(shè)計方法 - 產(chǎn)品交互體驗設(shè)計方法 - 模型驅(qū)動開發(fā)技術(shù) - 持續(xù)交付技術(shù),組織： - 組織結(jié)構(gòu) - 打造領(lǐng)導(dǎo)力驅(qū)動型團(tuán)隊 - 研發(fā)過程管理規(guī)范體系建設(shè),戰(zhàn)略：機會畫布方法,探尋機會的思維方式： 移情：理解你的用戶 定義：識別問題 構(gòu)思：頭腦風(fēng)暴，形成思路 原型：用線框圖或代碼快速搭建原型 驗證：驗證并優(yōu)化,戰(zhàn)略：商業(yè)模式畫布方法,商業(yè)模式描述了企業(yè)如何創(chuàng)造價值、傳遞價值和獲

59、取價值的基本原理。 商業(yè)模式畫布是一種用來描述商業(yè)模式、可視化商業(yè)模式、評估商業(yè)模式以及改變商業(yè)模式的通用語言。 參考：商業(yè)模式新生代,戰(zhàn)略：精益畫布（Lean Canvas）方法,精益畫布是從商業(yè)模式畫布改編而來的，具有制作迅速、內(nèi)容緊湊、方便攜帶的特點，便于創(chuàng)業(yè)者記錄和交流自己的商業(yè)模式。 我們可以把新產(chǎn)品開發(fā)當(dāng)作一次創(chuàng)業(yè)來看待。 參考：精益創(chuàng)業(yè)實戰(zhàn),戰(zhàn)略：產(chǎn)品精益畫布擴展版本,精益畫布擴展版本涉及更多編寫商業(yè)計劃書所需要考慮的內(nèi)容。 來源：,戰(zhàn)略：Social Lean Canvas,戰(zhàn)略：價值主張畫布,戰(zhàn)略：商業(yè)模式畫布方法概覽,戰(zhàn)略：企業(yè)架構(gòu)方法,企業(yè)架構(gòu)和敏捷架構(gòu)： 企業(yè)架構(gòu)關(guān)注于整個企業(yè)的IT架構(gòu)規(guī)劃，而敏捷架構(gòu)關(guān)注于項目交付層面； 企業(yè)架構(gòu)是著重于企業(yè)的未來，而敏捷架構(gòu)是著眼于項目的當(dāng)下； 企業(yè)架構(gòu)是自頂向下的架構(gòu)方法，而敏捷架構(gòu)更偏向于自下而上的架構(gòu)方法，兩者相輔相成，可以互為補充。 可參考架構(gòu)模型： TMForum - eTOM/SID/TAM/TNA NRF-ARTS,需求：需求工程,source - ,敏捷需求管理的目標(biāo)： 關(guān)注用戶價值 強調(diào)用戶參與 適應(yīng)需求變化 快速迭代實現(xiàn),需