敏捷项目管理终极培训-Scrum

敏捷项目管理终极培训-Scrum2016年6月目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践Scrum的角色Scrum流程和工作产品Scrum应用总结2敏捷的背景与动机软件危机及软件工程的出现速度是企业竞争致胜的关键因素，软件项目的最大挑战在于一方面要应付变动中的需求一方面要在紧缩的时程内完成项目传统的软件工程难以满足这些要求所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。这正是AgileProcess(敏捷的软件开发流程)于近年来兴起的主要原因。软件项目的复杂性横轴代表需求的复杂度纵轴表示技术的复杂度还有人力资源的复杂度4解决复杂性问题需要采用经验式方式解决问题的两种方式：预定义过程控制（富士康流水线生产）经验性过程控制（摸着石头过河）如果复杂度超过预定义方式的能力范围，应该采用经验性方式经验性方式的三大支柱：可见性、检查及适应5他山之石互联网时代的出版模式作者最开始的时候并没有想出一本书，而只是把多年的积累梳理出来写成了博客，凭借博客的成功最后得到了出版商和纸版读者的认可。在写成本书的过程中，作者是渐进式的进行的，每写完一个章节，放到博客上去征求读者的反馈，很多反馈意见在后面的章节或修订中及时地体现出来，这样就形成了与读者之间的良好反馈，在出版之前就锁定了大量的读者。这就是敏捷开发提倡的“增量迭代、及时交付”的思想。这种模式能最大程度地不偏离客户需求的本质。精益制造消除浪费、关注流程、建立无间断流程以快速应变、降低库存、一次做对、基于顾客需求的拉动生产、标准化与工作创新、尊重员工，给员工授权等目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践Scrum的角色Scrum流程和工作产品Scrum应用总结7敏捷的历史敏捷软件开发又称敏捷开发，从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。2001年初，因观察到许多的软件团队身陷不断扩大的流程之中的困境，一群业界专家聚集在一起，勾勒出一些能让软件团队迅速工作，以及响应变化的价值观和原则。他们自称为AgileAlliance。之后的七个月里，他们创造具有价值的声明，也就是敏捷软件的开发宣言。十五人中包括：大名鼎鼎的KentBeck（XP,TDD的创始人,Junit的创始人之一）、WardCunningham（Wiki概念的发明者）、MartinFowler（《企业应用架构模式》作者）、RobertC.Martin、KenSchwaber敏捷价值观之敏捷宣言9敏捷开发的核心思想是：以人为本，适应变化。敏捷价值观之敏捷宣言-1个体和交互胜过过程和工具人是软件项目获得成功最为重要的因素合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；10敏捷价值观之敏捷宣言-2可以工作的软件胜过面面俱到的文档过多的面面俱到的文档往往比过少的文档更糟软件开发的主要和中心活动是创建可以工作的软件直到迫切需要并且意义重大时，才进行文档编制编制的内部文档应尽量短小并且主题突出11敏捷价值观之敏捷宣言-3客户合作胜过合同谈判客户不可能做到一次性地将他们的需求完整清晰地表述在合同中为开发团队和客户的协同工作方式提供指导的合同才是最好的合同12敏捷价值观之敏捷宣言-4响应变化胜过循环计划变化是软件开发中存在的现实计划必须有足够的灵活性与可塑性短期的迭代的计划比中长期计划更有效JiangsuMicrosoftTechnologyCenter13敏捷开发的12个原则1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2.即使到了开发的后期，也欢迎改变需求。3.经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。5.围绕被激励起来的个人来构建项目。6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。敏捷开发的12个原则7.工作的软件是首要的进度度量标准。8.敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。9.不断地关注优秀的技能和好的设计会增强敏捷能力。10.简单化是根本（不做过度设计和预测）。11.最好的构架、需求和设计出自于自组织的团队。12.每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践Scrum的角色Scrum流程和工作产品Scrum应用总结16什么是敏捷方法？敏捷方法是一类软件开发流程的泛称；敏捷方法是相对于传统的瀑布式软件过程提出的；敏捷方法可以用敏捷宣言（4条）、敏捷原则（12条）来概括；敏捷原则通过一系列的敏捷实践来体现出来；敏捷方法有很多种。问题1，请举出你知道的2个以上敏捷方法名字来敏捷的方法ExtremeProgramming(XP)极限编程ScrumAdaptiveSoftwareDevelopment(ASD)自适应软件开发CrystalClearandOtherCrystalMethodologies水晶方法DynamicSystemsDevelopmentMethod(DSDM)动态系统开发方法等敏捷方法VS.瀑布模型瀑布模型固定的、没有弹性的。很困难去达到互动。假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的model是比较不适合的。敏捷方法完整地开发，每少数几周或是少数几个月里可以测试功能。强调在获得最简短的可执行功能的部分，能够及早给予企业价值。在整个项目的生命周期里，可以持续的改善、增加未来的功能。敏捷项目管理VS传统项目管理传统项目管理：事先对整个项目进行估计、计划、分析反对变更;变更需要重新估计、重新规划严密的合同来减少风险,如果改变需求要走CR流程.项目作为一个“黑盒子”，对客户与供应商的可视性差.文档和计划驱动的方法.软件交付时间晚,意识到风险的时间晚.WBS,甘特图,关键路径分析敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有详细的计划.鼓励变化,客户价值驱动开发.信任和赋予权力;合约使变更变得简单，增加价值.客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件.第一次迭代就可交付能工作的版本，风险发现的早.20敏捷与CMMI双剑合璧CMMI更加关注于流程，敏捷更加关注于人CMMI自顶向下，敏捷自底向上敏捷并不排斥必要的文档敏捷的很多实践是对CMMI的一种实现，比如sprint计划会议就是PP的实现，每日例会就是在做PMC很多CMMI4~5级的公司也在应用敏捷，比如说宝信、华为项目级的敏捷实践通过CMMI可以在组织级得以重用21eXtremeProgrammingXP我们一般称为极限编程，是最轻量级的开发流程。最主要的精神是『在客户有系统需求时，给予及时满意的可执行程序』，所以最适合需求快速变动的项目。它强调客户所要的是workable的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作。XP的实践包括：完整团队、计划游戏、客户测试简单设计、结对编程、测试驱动开发改进设计、持续集成、集体代码所有权编码标准、隐喻、可持续的速度Scrum开发流程JiangsuMicrosoftTechnologyCenter23为什么采用敏捷?–预期的收益采用敏捷方法得当的话，可以：更加透明;随时跟踪项目的状态和进展情况，及早发现问题和风险.快速交付,每次迭代都能交付可运行的软件.最高风险和最高优先级的需求，最优先进行开发.改善应对变更能力,减少大量的重计划.改善项目沟通.更好的客户参与,避免错误的假设.总之:提高了生产率;减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明确的目标.提高客户满意度;短期内产生成效,按预期交付软件,每次迭代结束产生可以运行的软件.改善员工的满意度;团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌”，稳定的工作量（可持续的步伐）.24目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践Scrum的角色Scrum流程和工作产品Scrum应用总结25敏捷关键实践1——增量迭代每个迭代有一个大约为1～4周的时间框，在SCRUM里称为一次冲刺（超过1个月的详细计划往往偏差很大）每次迭代都应该有明确的目标每次迭代都应该有明确的可演示的工作成果迭代过程中项目团队应该尽量免受打扰迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解26敏捷关键实践2——测试驱动开发TDD什么是测试驱动？首先创建测试用例，然后开发软件通过测试(在开发代码前，首先编写测试代码)一种设计软件的方法，而不仅仅是一种测试方法所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护不需要测试的工作不需要完成所创建的测试用例通常替代详细的业务和技术需求定测试也有效地驱动设计，使设计更加趋向于可行的设计通常情况下需要自动测试的支持(EUnit,JUnitetc.).对于UI软件应用TDD方法有一定的困难27敏捷关键实践3——持续集成28•极限编程称为“每日构建”•持续集成一般利用ANT、MAVEN等工具•日构建的好处：•将集成风险降到最低•降低质量风险•提升士气•日构建可以看做是项目的心跳，冒烟测试就像是听诊器•日构建必须至少：成功编译、打包、发布；不含有任何明显的缺陷；通过冒烟测试敏捷关键实践4——面对面交流虽然如今通讯工具花样繁多，但面对面交流在某些场合下仍然是不可替代的；敏捷开发把交流缺失问题考虑在内，要求团队成员彼此直接协作，尽量创造面对面交流的机会；尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的。匿名共享需求文档只会打开曲解和误解之门，更不用说书面信息比口头交流还要慢很多。29敏捷方法的其它实践结对编程每日立会用户故事团队工作室频繁发布自组织团队重构30重构——改善既有代码的设计MartinFowler提出代码的坏味道MartinFowler和KentBeck列举了22种坏味道：冗余代码、冗长的方法、巨大的类、过多的参数等等重构可以弥补设计的不足简单设计的思想重构与测试驱动的关系TDD是重构的脚手架IDE已经对主要的重构模式提供了自动化支持：Rename,extractmethod,movefield等等简单设计测试用例实现再说（重构回归测试）*31Scrum何时更有效？公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.敏捷方法对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代,并且可以冻结正在进行的迭代的范围公司和客户都有能力担当角色尤其是ProductOwner和ScrumMaster.项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.（ScrumofScrums，Scrum的扩展）团队成员能够以自组织的方式工作.项目的合同允许变更.固定价格的项目可以使用敏捷，但应当尽量避免。最好在按时间和材料付费或者按月付费的项目中进行使用、变更项目的范围不需要高级管理层的批准.32问题2，为什么SCRUM团队人员最好在10人以内？目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践Scrum的角色Scrum流程和工作产品Scrum应用总结33敏捷特别强调人的因素相对于过程