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

1、敏捷開(kāi)發(fā)全景視圖（流程、方法和最佳實(shí)踐）,鐘瑋軍 2016-02-25,目 錄 Contents,敏捷 vs 傳統(tǒng) 敏捷開(kāi)發(fā)流程框架 敏捷方法和最佳實(shí)踐 思考與答疑,敏捷 vs 傳統(tǒng),IT項(xiàng)目管理方法的發(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,軟件開(kāi)發(fā)生命周期（SDLC）,/wiki

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

3、Source: Forrester Research, Inc.,趨勢(shì)：敏捷開(kāi)發(fā)逐漸成為主流模式,2009 Q3,2014,Growth,敏捷開(kāi)發(fā)帶來(lái)的好處,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實(shí)施更加匹配,更快投入市場(chǎng),Source: 2013 Forrester Research, Inc.,敏捷開(kāi)發(fā)宣言,Manifesto for Agile Software Development Individuals and interactions over processes and tools 人和交互 重于 過(guò)程和工具 Working software over comprehensive documentation 可以工作的軟件 重于 面面俱到的文檔 Cus

5、tomer collaboration over contract negotiation 客戶合作 重于 合同談判 Responding to change over following a plan 隨時(shí)應(yīng)對(duì)變化 重于 遵循計(jì)劃 雖然右邊也有其價(jià)值，但我們認(rèn)為左項(xiàng)更加重要,敏捷原則 (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,敏捷開(kāi)發(fā)價(jià)值觀,專注：由于我們?cè)谝欢螘r(shí)間內(nèi)只專注于少數(shù)幾件事情，所以我們可以很好地合作并獲得優(yōu)質(zhì)的產(chǎn)出。我們能夠更快地交付有價(jià)值的事項(xiàng)。 公開(kāi)：在團(tuán)隊(duì)合作中，大家都會(huì)表達(dá)我們做得如何，以及遇到的障礙。我們發(fā)現(xiàn)將擔(dān)憂說(shuō)出來(lái)是一件好事，因?yàn)橹挥羞@樣才能讓這些擔(dān)憂及時(shí)得到解決。 尊重：因?yàn)槲覀冊(cè)谝黄鸸ぷ?，分享和成功失敗，這有助于培養(yǎng)并加深互相之間的尊重，并幫助彼此成為值得尊重的人。 承諾：由于對(duì)自己的命運(yùn)有更大的掌握，我們會(huì)有更

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

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

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

10、。在每個(gè)迭代結(jié)束時(shí)，Scrum團(tuán)隊(duì)將遞交潛在可交付的產(chǎn)品增量。Scrum起源于軟件開(kāi)發(fā)項(xiàng)目，但它適用于任何復(fù)雜的或是創(chuàng)新性的項(xiàng)目。 要素： 周期：Product Release=Time-Boxed Sprint=Daily Continous Delivery 團(tuán)隊(duì)：Product Owner，Scrum Master，Dev Team(Cross-Functional) 工件：Product Backlog，Sprint Backlog，Product Increment 活動(dòng)：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)隊(duì),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)隊(duì)：團(tuán)隊(duì)文化,共贏的文化 團(tuán)隊(duì)成功 個(gè)人發(fā)展 立足現(xiàn)實(shí) 挑戰(zhàn)極限,Scrum團(tuán)隊(duì)：角色分工概覽,Scrum團(tuán)隊(duì)：Product Owner職責(zé),主要負(fù)責(zé)確定產(chǎn)品的功能和達(dá)到要求的標(biāo)準(zhǔn)，指定軟件的發(fā)布日期和交付的內(nèi)容，同時(shí)有權(quán)利接受或拒絕開(kāi)發(fā)團(tuán)隊(duì)的工作成果 PO在Scrum中承擔(dān)了多項(xiàng)職責(zé) 產(chǎn)品經(jīng)理：愿景和方向，結(jié)果負(fù)責(zé) 需求分析：業(yè)務(wù)分析和需求分析 需求管理：維護(hù)、終止和變更 項(xiàng)目管理：優(yōu)先級(jí)排序和項(xiàng)目狀態(tài)跟蹤 質(zhì)量保障：檢查產(chǎn)品結(jié)果 客戶代表：產(chǎn)品體驗(yàn)/接受拒絕 PO對(duì)外承擔(dān)

13、了與產(chǎn)品干系人交流溝通的職責(zé) 老板、客戶和用戶、營(yíng)銷(xiāo)和銷(xiāo)售、,Scrum團(tuán)隊(duì)： PO的職責(zé)關(guān)系,Product Owner屬于研發(fā)角色，但與戰(zhàn)略、市場(chǎng)和銷(xiāo)售等公司其它角色存在密切合作關(guān)系，需要掌握跨界知識(shí)和語(yǔ)言表達(dá)。,圖示表現(xiàn)了產(chǎn)品管理四種角色之間的關(guān)系和分工定義，但根據(jù)項(xiàng)目規(guī)模不同，某一成員可能身兼數(shù)職。,Scrum團(tuán)隊(duì)： 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)隊(duì)： Scrum Master職責(zé),/community/articles/2014/may/what-it-is-that-a-scrum-master-does-all-day-long,主要負(fù)責(zé)整個(gè)Scrum流程在項(xiàng)目中的順利實(shí)施和進(jìn)行，以及清除擋在客戶和開(kāi)發(fā)工作之間的溝通障礙，使得客戶可以直接驅(qū)動(dòng)開(kāi)發(fā)。,Scrum團(tuán)隊(duì)： Scrum Master能力要求,出色的溝通和決策能力 能及時(shí)、清楚、明確地傳播信息； 知道什么時(shí)候做出決定，不必要再

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

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

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

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

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

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

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

32、開(kāi)發(fā)的需求（包括功能性和非功能性需求）條目化地表達(dá)出來(lái)。 Product Owner維護(hù)，用場(chǎng)景描述的用戶需求(Story)列表 經(jīng)過(guò)優(yōu)先級(jí)排序和工作量評(píng)估的 優(yōu)先級(jí)越高的條目，User Story描述粒度越細(xì) 反映了業(yè)務(wù)的計(jì)劃,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)和場(chǎng)景驅(qū)動(dòng)，體現(xiàn)業(yè)務(wù)價(jià)值,SCRUM工件：PB(3)User Story 粒度,按照業(yè)務(wù)優(yōu)先級(jí)次序，將大粒度的用戶故事拆解為小粒度的用戶故事，并依次經(jīng)過(guò)評(píng)估后安排進(jìn)入Release

34、計(jì)劃和Sprint計(jì)劃,SCRUM工件：PB(4)User Story優(yōu)先級(jí),SCRUM工件：PB(5)User Story評(píng)估,用戶故事INVEST模式 Independent: 減少依賴，便于計(jì)劃 Negotiable: 通過(guò)協(xié)作添加細(xì)節(jié) Valuable: 對(duì)客戶有價(jià)值 Estimable: 太大或太模糊的用戶故事，無(wú)法評(píng)估 Small: 可以在由一個(gè)團(tuán)隊(duì)在一周內(nèi)完成 Testable: 有好的驗(yàn)收原則 評(píng)估用戶故事的大小 Story Points Anchor Story，相對(duì)值評(píng)估 斐波那契數(shù)列和撲克牌游戲 貼墻技術(shù) 衡量團(tuán)隊(duì)Velocity 用46個(gè)Sprint來(lái)確定速率,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é)：編碼、測(cè)試、代碼評(píng)審、會(huì)議、學(xué)習(xí)新技術(shù)、編寫(xiě)文檔 Sprint tasks需要評(píng)估到小時(shí) 如果任務(wù)需時(shí)超過(guò)一天，嘗試分割成幾個(gè)小任務(wù) 如果團(tuán)隊(duì)認(rèn)為Sprint Backlog項(xiàng)目過(guò)多或過(guò)少，和產(chǎn)品負(fù)責(zé)人一起調(diào)整問(wèn)題數(shù)量 團(tuán)隊(duì)確認(rèn)Sprint目標(biāo) 如果工作不清晰，可以先建一

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

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

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

42、“Done”的幾個(gè)例子： Design, coding, unit testing, integrated Static analysis, refactored Acceptance tested, deployable,/community/articles/2008/september/definition-of-done-a-reference,Scrum（四）：Scrum活動(dòng),Scrum活動(dòng)：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)隊(duì)一起對(duì)整個(gè)產(chǎn)品Backl

46、og進(jìn)行評(píng)估，提出劃分發(fā)行版本和Sprint計(jì)劃的主要依據(jù)。,Scrum活動(dòng)：Release Planning(2),一個(gè)企業(yè)級(jí)Release Planning會(huì)議活動(dòng)日程安排的示例：,Scrum活動(dòng)：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活動(dòng)：Sprint Planning(2),一個(gè)分兩階段議程Spring計(jì)劃會(huì)議的例子： Sprint計(jì)劃會(huì)議1：產(chǎn)品負(fù)責(zé)人和團(tuán)隊(duì)一起，在先前評(píng)估的成果基礎(chǔ)上，定出Sprint目標(biāo)和既定產(chǎn)品Backlog。 Sprint計(jì)劃會(huì)議2：團(tuán)隊(duì)將既定產(chǎn)品Backlog中的每一項(xiàng)細(xì)化成多個(gè)任務(wù)，每個(gè)任務(wù)完成的時(shí)間限定

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

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

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

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

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

55、每個(gè)條目的完成時(shí)間） 流程狀態(tài)（列）可自行裁剪，適用于大小項(xiàng)目,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,大型項(xiàng)目流程框架：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è)級(jí)項(xiàng)目流程框架：SAFe,敏捷方法和最佳實(shí)踐,敏捷方法和最佳實(shí)踐概覽,戰(zhàn)略： - 機(jī)會(huì)畫(huà)布方法 - 商業(yè)模式畫(huà)布方法 - 精益畫(huà)布方法 - 價(jià)值主張畫(huà)布 - 企業(yè)架構(gòu)方法,需求： - 需求捕獲技術(shù) - 需

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

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