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

1、敏捷開發(fā)全景視圖（流程、方法和最佳實踐）鐘瑋軍2016-02-25目 錄 Contents敏捷 vs 傳統(tǒng)敏捷開發(fā)流程框架敏捷方法和最佳實踐思考與答疑敏捷 vs 傳統(tǒng)IT項目管理方法的發(fā)展歷史196019701980199020002010SDLCWATERFALLRADPMBOKITILPRINCEZachmanDSDMRUPXPPRINCE2CRYSTALSCRUMAGILEAGILEMANIFESTOMANIFESTOFEATOGAF 8.0LEANKANBAN軟件開發(fā)生命周期（SDLC） /wiki/Systems_development_

2、life_cycle傳統(tǒng)軟件開發(fā)模式傳統(tǒng)瀑布式軟件開發(fā)方式向迭代式軟件開發(fā)方式轉(zhuǎn)變（RUP框架）http:/ 傳統(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)品價值、團隊協(xié)作、客戶參與、先期驗證、簡化流程、擁抱變化 總結(jié)吸收成功軟件項目研發(fā)的最佳實踐；與現(xiàn)代管理思想相輔相成 前期有學(xué)習(xí)成本，后期會獲益匪淺敏捷軟件開發(fā)模式Source: Forrester Research, Inc.趨勢

3、：敏捷開發(fā)逐漸成為主流模式2009 Q32014Growth敏捷開發(fā)帶來的好處TOP 5 reported benefits: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%)A lot more than ve

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

5、作的軟件 重于 面面俱到的文檔 Customer collaboration Customer collaboration over contract negotiation 客戶合作 重于 合同談判 Responding to change Responding to change over following a plan 隨時應(yīng)對變化 重于 遵循計劃 雖然右邊也有其價值，但我們認(rèn)為左項更加重要敏捷原則 (Agile Principles)1. Satisfy the Customer2. Welcome Change3. Deliver Frequently4. Work as a Te

6、am5. Motivate People6. Communicate Face-to-Face7. Measure Working Software8. Maintain Constant Pace9. Excel at Quality10.Keep it Simple11.Evolve Designs12.Reflect Regularly敏捷開發(fā)價值觀 專注：由于我們在一段時間內(nèi)只專注于少數(shù)幾件事情，所以我們可以很好地合作并獲得優(yōu)質(zhì)的產(chǎn)出。我們能夠更快地交付有價值的事項。 公開：在團隊合作中，大家都會表達我們做得如何，以及遇到的障礙。我們發(fā)現(xiàn)將擔(dān)憂說出來是一件好事，因為只有這樣才能讓這些擔(dān)

7、憂及時得到解決。 尊重：因為我們在一起工作，分享和成功失敗，這有助于培養(yǎng)并加深互相之間的尊重，并幫助彼此成為值得尊重的人。 承諾：由于對自己的命運有更大的掌握，我們會有更堅強的信念獲得成功。 勇氣：因為我們不得單打獨斗，我們能夠感受到支持，而且掌握更多的資源。這一切賦予我們勇氣去迎接更大的挑戰(zhàn)。從傳統(tǒng)到敏捷：思維的轉(zhuǎn)變 形而上者謂之道，形而下者謂之器。 形而上者起于學(xué)、行于理、止于道，形而下者起于教、行于法、止于術(shù)。 從重視“流程”到重視“原則” 道本器末，不忘初心 做正確的事比正確地做事更重要 如何看待流程、方法、最佳實踐在敏捷開發(fā)中的作用 無其器則無其道，器和道一樣重要 上善若水，原則的“

8、剛性”和流程的“柔性”從傳統(tǒng)到敏捷：認(rèn)識誤區(qū)從傳統(tǒng)到敏捷：阻礙和要點改變我們的商業(yè)文化采用敏捷技術(shù)實踐改變我們的IT文化以一種敏捷的態(tài)度使用我們現(xiàn)有的工具采用新的敏捷開發(fā)工具采用敏捷管理實踐從傳統(tǒng)到敏捷：關(guān)鍵因素改變我們的商業(yè)文化采用敏捷管理實踐改變我們的IT文化采用敏捷技術(shù)實踐采用新的敏捷開發(fā)工具以一種敏捷的態(tài)度使用我們現(xiàn)有的工具敏捷開發(fā)流程框架產(chǎn)品研發(fā)：一個持續(xù)的過程WhatWhat？HowHow？Management is doing things right; leadership is doing the right things. (Peter Drucker)敏捷開發(fā)流程框架：S

9、crum注：Scrum是最為流行的敏捷開發(fā)流程框架之一WhatWhat？HowHow？Scrum框架：簡介 Scrum 是一個用于開發(fā)和維持復(fù)雜產(chǎn)品的框架，是一個增量的、迭代的開發(fā)過程。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個SprintSprint，每個Sprint的建議長度是2到4周(互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint)。在Scrum中，使用產(chǎn)品BacklogBacklog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表條目的體現(xiàn)形式通常為用戶故事。Scrum團隊總是先開發(fā)對客戶具有較高價值的需求。在Sprint中，Scr

10、um團隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlogSprint backlog。在每個迭代結(jié)束時，Scrum團隊將遞交潛在可交付的產(chǎn)品增量。Scrum起源于軟件開發(fā)項目，但它適用于任何復(fù)雜的或是創(chuàng)新性的項目。要素： 周期：Product Release=Time-Boxed Sprint=Daily Continous Delivery 團隊：Product Owner，Scrum Master，Dev Team(Cross-Functional) 工件：Product B

11、acklog，Sprint Backlog，Product Increment 活動：Sprint Planning Meeting/Review Meeting/Retrospective Meeting，Daily Scrum Meeting，Product Backlog Refinement 度量：Burndown圖、Burnup圖、VelocityScrum（一） ：迭代周期框架迭代周期框架： Product Release=Time-Boxed SprintPortfolio=Product=Release=Sprint=Daily WorkingWhatWhat？HowHow？S

12、crum（二）：團隊Build The Right ThingBuild The Thing RightBuild It FastScrum TeamAchievement-orientedCustomer-orientedCommittedMotivatedSelf-organizedEmpoweredSkilledScrum團隊：團隊文化共贏的文化 團隊成功 個人發(fā)展 立足現(xiàn)實 挑戰(zhàn)極限Scrum團隊：角色分工概覽http:/ Owner職責(zé) 主要負(fù)責(zé)確定產(chǎn)品的功能和達到要求的標(biāo)準(zhǔn)，指定軟件的發(fā)布日期和交付的內(nèi)容，同時有權(quán)利接受或拒絕開發(fā)團隊的工作成果 PO在Scrum中承擔(dān)了多項職責(zé) 產(chǎn)

13、品經(jīng)理：愿景和方向，結(jié)果負(fù)責(zé) 需求分析：業(yè)務(wù)分析和需求分析 需求管理：維護、終止和變更 項目管理：優(yōu)先級排序和項目狀態(tài)跟蹤 質(zhì)量保障：檢查產(chǎn)品結(jié)果 客戶代表：產(chǎn)品體驗/接受拒絕 PO對外承擔(dān)了與產(chǎn)品干系人交流溝通的職責(zé) 老板、客戶和用戶、營銷和銷售、Scrum團隊： PO的職責(zé)關(guān)系http:/ Owner屬于研發(fā)角色，但與戰(zhàn)略、市場和銷售等公司其它角色存在密切合作關(guān)系，需要掌握跨界知識和語言表達。圖示表現(xiàn)了產(chǎn)品管理四種角色之間的關(guān)系和分工定義，但根據(jù)項目規(guī)模不同，某一成員可能身兼數(shù)職。Scrum團隊： PO能力要求 業(yè)務(wù)分析能力（Business Analysis） 工程技術(shù)能力（Engine

14、ering） 領(lǐng)導(dǎo)和協(xié)調(diào)能力（Leadership & Coordination）http:/ Analysis CapabilitiesHelping organizations develop the capabilities to achieve Enterprise AgilityUnderstand Needs of the Customer Develop Product StrategyManage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product Strategy

15、Solution RequirementsDevelop ProductLaunch ProductOperate and Support ProductDefine Product Backlog Establish Product VisionDefine Product RoadmapPlan Launch Engage StakeholdersPlanning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process AdherenceIdentify and Remove I

16、mpedimentsEnsure Internal CommunicationMaintain Work EnvironmentDevelop TeamSupport Operations Provide Customer SupportSupport Implementation Coordinate Work Maintain Architecture Understand Requirements Maintain Product Quality Design and Engineer SolutionDeploy Product Integration Testing Learn fr

17、om Outside SourcesCommit To AgilityManage Risks Provide Job TrainingEveryoneEveryoneEnvironment Environment Perform Maintenance and Customizations Product DevelopmentProduct Developmenthttp:/ CapabilitiesHelping organizations develop the capabilities to achieve Enterprise AgilityUnderstand Needs of

18、the Customer Develop Product StrategyManage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product StrategySolution RequirementsDevelop ProductLaunch ProductOperate and Support ProductDefine Product Backlog Establish Product VisionDefine Product RoadmapPlan Launch Engage

19、StakeholdersPlanning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process AdherenceIdentify and Remove ImpedimentsEnsure Internal CommunicationMaintain Work EnvironmentDevelop TeamSupport Operations Provide Customer SupportSupport Implementation Coordinate Work Maintai

20、n Architecture Understand Requirements Maintain Product Quality Design and Engineer SolutionDeploy Product Integration Testing Learn from Outside SourcesCommit To AgilityManage Risks Provide Job TrainingEveryoneEveryoneEnvironment Environment Perform Maintenance and Customizations Product Developmen

21、tProduct Developmenthttp:/ & Coordination CapabilitiesHelping organizations develop the capabilities to achieve Enterprise AgilityUnderstand Needs of the Customer Develop Product StrategyManage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product StrategySolution Requir

22、ementsDevelop ProductLaunch ProductOperate and Support ProductDefine Product Backlog Establish Product VisionDefine Product RoadmapPlan Launch Engage StakeholdersPlanning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process AdherenceIdentify and Remove ImpedimentsEnsur

23、e Internal CommunicationMaintain Work EnvironmentDevelop TeamSupport Operations Provide Customer SupportSupport Implementation Coordinate Work Maintain Architecture Understand Requirements Maintain Product Quality Design and Engineer SolutionDeploy Product Integration Testing Learn from Outside Sour

24、cesCommit To AgilityManage Risks Provide Job TrainingEveryoneEveryoneEnvironment Environment Perform Maintenance and Customizations Product DevelopmentProduct Developmenthttp:/ Scrum Master職責(zé)/community/articles/2014/may/what-it-is-that-a-scrum-master-does-all-day-long主要負(fù)責(zé)

25、整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發(fā)工作之間的溝通障礙，使得客戶可以直接驅(qū)動開發(fā)。Scrum團隊： Scrum Master能力要求出色的溝通和決策能力能及時、清楚、明確地傳播信息；知道什么時候做出決定，不必要再做分析；平衡短期和長期目標(biāo)，快速在團隊和Product Owner之間達成一個共同的愿景；促進團隊合作的能力能夠促進和培養(yǎng)團隊合作的能力，能夠診斷、理解和幫助團隊的日常變化；持續(xù)衡量團隊工作狀況，并推動必要的行動，以改進團隊的工作；鼓舞和激勵能力促進團隊活力，鼓舞、表揚和獎勵團隊中做得最好的人，宣揚突出的行為、技能和成就；偉大的工作態(tài)度，總是尋找方法來改變

26、工作，而不是認(rèn)同為什么做出改變是不可能的；抗壓能力在壓力環(huán)境下仍能保持鎮(zhèn)定，出色工作解決沖突能力促進建設(shè)性的辯論，使得產(chǎn)生更好的決策和共同愿景建設(shè)性地解決分歧和沖突，知道什么時候讓其他人也參與進來在所有交往中，體現(xiàn)出情感成熟度（周到、客觀、正直、可靠）即使在他/她不同意的時候，也會支持哪些已經(jīng)做出的決定敏捷開發(fā)實踐能力Backlog跟蹤，burndown圖，會議組織，計劃能力，進度跟蹤，風(fēng)險管理，組織變革、團隊成長，敏捷開發(fā)實踐，持續(xù)集成/交付/部署，.參考：/community/articles/2007/april/the-right

27、-skill-set-the-right-mind-set-the-rightScrum團隊： Scrum Master特質(zhì)專注并細(xì)心確保團隊行為始終與驗收標(biāo)準(zhǔn)和項目目標(biāo)（愿景）保持一致；通過良好的組織方法分配工作任務(wù)，減少失誤；團隊合作者勇于承擔(dān)任何能夠幫助團隊的任務(wù)，并以身作責(zé)（比如，團隊決定加班來完成Sprint目標(biāo)，Scrum Master應(yīng)該和團隊在一起）善于解決問題的能力是一個能快速獲取信息去解決問題的老手；幫助團隊識別沖突的優(yōu)先級，并表達并逐級向上反應(yīng)不能快速的問題；值得信賴信守承諾，說到做到親近平易近人，風(fēng)度翩翩高度的決心和毅力這是成功的關(guān)鍵性因素。因為，對于推動隊員思維模式的

28、轉(zhuǎn)變是非常困難的，更不用提整個組織的轉(zhuǎn)變了，特別是在看到組織內(nèi)部有失敗案例的時候；你必須有足夠的耐心來幫助團隊一步一步地轉(zhuǎn)變，因為要想看到積極的趨勢是會花很多時間和精力的。在出現(xiàn)“信任危機”的時候（非?？赡艹霈F(xiàn)），你必須要有足夠的耐心來說服他人、影響他人；既要理解標(biāo)準(zhǔn)化的ScrumScrum模式，又要根據(jù)自己組織的固有特點來實際地運用它這是成功的決定性因素。因為沒有任何兩家公司是相同的；這也要求你要比較溫和的推進轉(zhuǎn)變。記?。河賱t不達；Scrum Master需要制定一個比較長遠的推進計劃，然后步步為營，直到團隊自己找到基于Scrum框架和思維模式的最佳工作方法；準(zhǔn)備好挑戰(zhàn)他人并接受他人的挑戰(zhàn)

29、向管理層尋求幫助固然有用，但通常比較困難。因此在適當(dāng)?shù)臅r候記得去挑戰(zhàn)你的老板。很多成功的變革通常是由下至上發(fā)起的，不要一味地依賴?yán)习宓闹甘?；若在實施過程中受到外界的挑戰(zhàn)和動搖，一定要對自己、對團隊、對組織有堅定的信心。如果外界的動搖具有10分的摧毀力，那么你自己的動搖則具有100分；持續(xù)改進自我的愿望這點不僅適用于團隊成員，更是適用于Scrum Master自身。因為通過自我的持續(xù)改進，你才能有效的影響團隊成員，讓大家積極的凝聚在一起，直到找到最高效的工作方法這一終極目標(biāo)。Scrum團隊： Dev Team職責(zé) 主要負(fù)責(zé)軟件產(chǎn)品在Scrum規(guī)定流程下進行開發(fā)工作，人數(shù)控制在510人左右，每個成

30、員可能負(fù)責(zé)不同的技術(shù)方面，但要求每個成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以采用任何工作方式，只要能達到Sprint的目標(biāo)。 主要職責(zé) 定義（分解）工作任務(wù) 評估工作量 開發(fā)產(chǎn)品 確保質(zhì)量 完善過程Scrum團隊：Dev Team(1) 跨職能團隊Scrum團隊： Dev Team(2) 特性團隊Component TeamFeature TeamVS.http:/ Team的組織方式會導(dǎo)致瀑布式的開發(fā)流程，以便協(xié)調(diào)團隊間的工作任務(wù)。Feature Team組織方式的成功依賴于團隊能力，以及團隊對于重構(gòu)、持續(xù)集成、自動化測試等敏捷開發(fā)工具和實踐的使用。Scrum團隊：

31、Dev Team成員能力拓展成就全棧工程師瀑布式：團隊成員專司一職，難以獲得橫向拓展SCRUMSCRUM：人們可能主要技能不盡相同，如有人擅長開發(fā)而另外的人擅長測試，但是，在ScrumScrum團隊里，我們鼓勵團隊成員學(xué)習(xí)新的領(lǐng)域技能，嘗試在新的領(lǐng)域工作，團隊成員跨領(lǐng)域互相幫助完成一項產(chǎn)品特性。比如，一個“架構(gòu)師”可能要寫自動化測試代碼，而一個“測試人員”則可能要分析業(yè)務(wù)。SCRUM（三）：SCRUM工件SCRUMSCRUM工件 核心工件：Product Backlog，Sprint Backlog， Shippable Product Increment； 其它工件：Dependencies

32、 / Blocker list；SCRUM工件：Product BacklogProduct Backlog是條目化/量化的用戶需求，它將需求文檔中需要實際開發(fā)的需求（包括功能性和非功能性需求）條目化地表達出來。 Product Owner維護，用場景描述的用戶需求(Story)列表 經(jīng)過優(yōu)先級排序和工作量評估的 優(yōu)先級越高的條目，User Story描述粒度越細(xì) 反映了業(yè)務(wù)的計劃SCRUM工件：PB(1)ItemsMy primary rule for including any item in the product backlog is that the work must be som

33、ething the product owner can understand and can reasonably prioritize against features. So if you do choose to include PBIs of type technical worktechnical work, you will need to make the value of the item clear to the product owner.http:/ Story描述As a ,I want a So that I can get.基于目標(biāo)和場景驅(qū)動，體現(xiàn)業(yè)務(wù)價值SCRU

34、M工件：PB(3)User Story 粒度按照業(yè)務(wù)優(yōu)先級次序，將大粒度的用戶故事拆解為小粒度的用戶故事，并依次經(jīng)過評估后安排進入Release計劃和Sprint計劃SCRUM工件：PB(4)User Story優(yōu)先級SCRUM工件：PB(5)User Story評估用戶故事INVEST模式 Independent: 減少依賴，便于計劃 Negotiable: 通過協(xié)作添加細(xì)節(jié) Valuable: 對客戶有價值 Estimable: 太大或太模糊的用戶故事，無法評估 Small: 可以在由一個團隊在一周內(nèi)完成 Testable: 有好的驗收原則評估用戶故事的大小 Story Points An

35、chor Story，相對值評估 斐波那契數(shù)列和撲克牌游戲 貼墻技術(shù)衡量團隊Velocity 用46個Sprint來確定速率SCRUM工件：PB(6) 非功能性需求描述Nonfunctional requirementsNonfunctional requirements represent important system-level constraints that affect the design and testing of most or all items in the product backlog. Nonfunctional requirements are used to

36、 specify various characteristics such as system performance, accuracy, portability, reusability, 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 Window

37、s 95 on. As the CTO, I want the system to use our existing orders database rather than create 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 t

38、o use. As someone who speaks a Latin-based language, I might want to run your software someday. As a user, I want the driving directions to be the best 90 percent of the time, and reasonable 99 percent of the time.參考http:/ Sprint Backlog確?？紤]到工作中所有細(xì)節(jié)：編碼、測試、代碼評審、會議、學(xué)習(xí)新技術(shù)、編寫文檔Sprint tasks需要評估到小時如果任務(wù)需時超

39、過一天，嘗試分割成幾個小任務(wù)如果團隊認(rèn)為Sprint Backlog項目過多或過少，和產(chǎn)品負(fù)責(zé)人一起調(diào)整問題數(shù)量團隊確認(rèn)Sprint目標(biāo)如果工作不清晰，可以先建一個粗粒度的Sprint Backlog，然后再分解所有任務(wù)項都分配給團隊成員每日更新剩余工作評估團隊成員對任務(wù)的DoD(Definition of “Done”)應(yīng)該有共同的理解只計算全力以赴完成所需要的時間，剩下的交給燃盡(Burndown)圖解決Sprint Backlog是Scrum團隊在Sprint Planning會議中確認(rèn)的待辦任務(wù)列表，映射到傳統(tǒng)項目管理理論中就是WBS，而且是典型的采用面向交付物的任務(wù)分解方法得到的WB

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

41、有負(fù)責(zé)交付產(chǎn)品的人員都是團隊里的成員 Scrum Master還要處理其他任務(wù)，不能集中精力 團隊人數(shù)過多（多于7個開發(fā)人員） 團隊沒有能坐在一起工作的空間 團隊的Sprint Backlog混亂以障礙Backlog方式管理障礙 把所有已知的障礙加入到障礙Backlog的“新事項”欄中 按優(yōu)先級順序排列“新事項”欄中的障礙問題 每當(dāng)您開始著手解決一個障礙問題時，將它移至“正在處理事項”欄中 盡快解決這個障礙 障礙得到解決時，將它移到“已完成”事項欄中 在Scrum每日例會和Sprint回顧會議中收集新的障礙問題Scrum工件：Definition of “Done” 對于Scrum工件中的條目

42、，團隊一起定義“Done”（“完成”）的真實內(nèi)在含義，以免在評估項目時發(fā)生誤解和分歧。 “Done”的幾個例子： Design, coding, unit testing, integrated Static analysis, refactored Acceptance tested, deployable/community/articles/2008/september/definition-of-done-a-referenceScrum（四）：Scrum活動 Scrum活動：Release Planning(1)Who: Scr

43、um Coach, Product Owner, Scrum Team, Scrum Master, Key StakeholdersWhen: 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

44、 estimates + prioritized features.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 th

45、e releaseProduct VisionHigh level prioritized goals & roadmapKey risks and assumptionsStakeholder consensusPrioritized product backlogGoal: Establish the overall release schedule and determine in what sprint stories will likely be delivered.Product Backlog (priority draft)Release PlanRough Estimates

46、產(chǎn)品負(fù)責(zé)人和團隊一起對整個產(chǎn)品Backlog進行評估，提出劃分發(fā)行版本和Sprint計劃的主要依據(jù)。Scrum活動：Release Planning(2)https:/ 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 rev

47、iew.Stories 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

48、on point per story.Process continues until all available hours are used for the sprint.Selected stories for the sprintSprint PlanPrioritized product backlogTeams capabilities (hours)Key risks and assumptionsStakeholder consensusGoal: Team to plan and agree on backlog items they can complete and conf

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

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

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

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

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

54、，不適合開發(fā)人員與運營人員合一的小型公司/小型團隊 無法事先計劃不被打擾的固定周期 太短的周期也不行，有的任務(wù)會超過一個周期 UX/UI設(shè)計跟程序設(shè)計開發(fā)的周期搭配問題 不同平臺（iOS，Android，Web）開發(fā)周期搭配問題 App Store審核時間不一定 兩周的開發(fā)迭代周期公司仍不滿意，可不可以更快，做到極致？流程框架演進：Kanban Board最輕量的流程管理方法WIP限制（TOC限制理論） 限制每個狀態(tài)的最多項目關(guān)注Cycle Time（平均每個條目的完成時間）流程狀態(tài)（列）可自行裁剪，適用于大小項目Kanban: vs ScrumScrumScrumKanbanKanban相同

55、點都是敏捷開發(fā)流程框架(Lean Thinking, Agile )；都是經(jīng)驗性的，團隊需要具體情況（過往經(jīng)驗）進行調(diào)整和裁剪；都基于自組織(self-organizing)團隊；不同點指定了明確的角色沒有明確的角色定義timeboxed，固定迭代周期并不要求timeboxed限制每個迭代的WIP限制每個工作流狀態(tài)的WIP不歡迎在一個迭代內(nèi)做出變更并不拒絕Scrum board在每個迭代之間清空Kanban board在項目過程中一直有東西指定要cross-functional的團隊并不要求規(guī)定了“estimation”和“velocity”并無規(guī)定，有很多好的實踐Kanban工作流程（一）h

56、ttp:/blog.crisp.se/2009/06/26/henrikkniberg/1246053060000Kanban工作流程（二）http:/blog.crisp.se/2009/06/26/henrikkniberg/1246053060000更多流程框架比較（更規(guī)范）（更靈活）http:/ BacklogTask BacklogIn ProcessTask DoneStory BacklogAnalysisDesignBuildTestDeploy InceptionElaborationConstructionTransitionTier 1 - ScrumTier 2 - K

57、anbanTier 3 - KanbanEpicFeatureUser Storyhttp:/ of ScrumsAgendaThree questions What has my team done since we last met that might affect other teams? What will my 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?

58、Discussion Discuss items kept on an Open Issues Backlog企業(yè)級項目流程框架：SAFehttp:/ - - 機會畫布方法 - - 商業(yè)模式畫布方法 - - 精益畫布方法 - - 價值主張畫布 - - 企業(yè)架構(gòu)方法需求： - - 需求捕獲技術(shù) - - 需求建模技術(shù) - - 需求User StoryUser Story描述方法 - - 需求優(yōu)先級評估方法 - - User StoryUser Story切分技術(shù) - User Story Mapping- User Story Mapping - UML- UML用例建模技術(shù)反饋： - - 數(shù)字化

59、評估方法實現(xiàn)： - - 敏捷架構(gòu)設(shè)計方法 - - 產(chǎn)品交互體驗設(shè)計方法 - - 模型驅(qū)動開發(fā)技術(shù) - - 持續(xù)交付技術(shù) 組織： - - 組織結(jié)構(gòu) - - 打造領(lǐng)導(dǎo)力驅(qū)動型團隊 - - 研發(fā)過程管理規(guī)范體系建設(shè)戰(zhàn)略：機會畫布方法探尋機會的思維方式：- 移情：理解你的用戶- 定義：識別問題- 構(gòu)思：頭腦風(fēng)暴，形成思路- 原型：用線框圖或代碼快速搭建原型- 驗證：驗證并優(yōu)化戰(zhàn)略：商業(yè)模式畫布方法商業(yè)模式描述了企業(yè)如何創(chuàng)造價值、傳遞價值和獲取價值的基本原理。商業(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)容。來源：http:/ Lean Canvashttp:/ - eTOM/SID/TAM/TNANRF-ARTS需求：需求工程source - http:/ 需求捕獲需求捕獲指南需求捕獲是軟件項