项目管理01_如何实施scrum课件

如何实施如何实施scrum青岛易软天创网络科技有限公司 2012/4/14（原作）彭优 2017/04/26（精简）如何实施scrum青岛易软天创网络科技有限公司 2012/Page 2总目录总目录scrum流程scrum中常见问题项目经理相关研发团队相关测试人员相关会议相关2总目录scrum流程2Page 3scrum流程流程scrum的基本流程图scrum的基本流程详情实施scrum的两个阶段传统团队转向敏捷团队开好几个会议逐步找到适合团队的开发实践3scrum流程scrum的基本流程图3Page 4scrum的基本流程图的基本流程图4scrum的基本流程图4Page 5scrum的基本流程详情的基本流程详情5如上图所示，基本流程如下：产品负责人负责整理user story，形成左侧的product backlog。发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，最终每个任务都有明确的负责人，并完成工时的初估计。每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。scrum的基本流程详情5如上图所示，基本流程如下：Page 6实施实施scrum的两个阶段的两个阶段第一阶段：严格按照scrum的流程进行。scrum已经是最简流程，不宜再进行删减。学习一样东西很重要的就是初心，把原有的东西放下。组织结构层面的支持非常重要。第二阶段：根据团队实际情况进行调整。找到团队最佳的迭代周期。找到团队最佳的开发实践。建立产品的发布节奏。6实施scrum的两个阶段第一阶段：严格按照scrum的流程进Page 7传统团队转向敏捷团队传统团队转向敏捷团队瀑布开发转向迭代开发。固定的迭代周期，迭代周期内不能随意改变需求。项目经理转向scrum master（简称SM）放权产品经理转向 product owner（简称PO）项目成员转向 team member需求改用 user story 跟踪任务分解改为团队来做。任务指派改为自由领取。甘特图改用燃尽图。独立考核改为团队的共进退。7传统团队转向敏捷团队瀑布开发转向迭代开发。7Page 8开好几个会议开好几个会议计划会议第一部分：做好优先级的排序，考虑投入产出。计划会议的第二部分：团队分解，自主领取。每日的站立会议：控制时间，重在沟通，非汇报会议。不解决问题。演示会议：展示成果，得到反馈。提高团队成就感。回顾会议：逐步改进实践。8开好几个会议计划会议第一部分：做好优先级的排序，考虑投入产出Page 9逐步找到适合团队的开发实践逐步找到适合团队的开发实践结对编程代码规范源代码管理代码review每日提交交叉测试重构分享会议简单设计自动化测试框架9逐步找到适合团队的开发实践结对编程9Page 10scrum中常见问题中常见问题如何写用户故事？如何决定用户故事的优先级？向迭代中添加需求，SM应该怎么做？10scrum中常见问题如何写用户故事？10Page 11如何写用户故事？如何写用户故事？角色，做的事情，价值或者原因。定义完成的标准。User Story应遵循INVEST规则：Independent 独立性，避免与其他Story的依赖性。Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract,Stories不必太过详细，开发人员可以给出适当的建议。Valuable 有价值性，Story需要体现出对于用户的价值 Estimable 可估计性，Story应可以估计出Task的开发时间。Sized Right 合理的尺寸，Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。Testable 可测试性，User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test.11如何写用户故事？角色，做的事情，价值或者原因。11Page 12如何规定用户故事的优先级？如何规定用户故事的优先级？根据需求的价值和投入来估算ROI，投入产出比。有的需求价值很高，但开发团队实现起来非常难，也是不行的。12如何规定用户故事的优先级？根据需求的价值和投入来估算ROI，Page 13向迭代中添加需求，向迭代中添加需求，SM应该怎么做？应该怎么做？某天，大老板说，我们要做个什么东东。产品经理就找项目经理(scrum master)说，“老板说了，要做个什么事情”，项目经理就把需求加上去了。或者产品经理直接找到研发人员，偷偷摸摸的加上某功能。向迭代中添加需求是scrum杀手，scrum master应勇敢的说“不，请等待n周！”研发人员：没有在（禅道）任务列表中的不做！scrum master：没有放入（禅道）sprint backlog的不做！13向迭代中添加需求，SM应该怎么做？某天，大老板说，我们要做个Page 14项目经理相关项目经理相关角色的转变考核的转变后续的发展14项目经理相关角色的转变14Page 15角色的转变角色的转变从原来的管理者转变为服务者心态的调整，从事必躬亲改为放权放手让团队去做，允许团队犯错15角色的转变从原来的管理者转变为服务者15Page 16考核的转变考核的转变敏捷开发团队更是一个整体。共进共退，荣誉与共团队的集体考核团队内部自己进行考核16考核的转变敏捷开发团队更是一个整体。16Page 17后续的发展后续的发展scrum master 做到最成功的地方就是，这个团队不再需要你了。那么肯定有项目经理犯嘀咕了，那我怎么办啊。可能的方向：scum master trainer：培养更多的scrum master带其他的团队专向架构师转向产品转向开发团队17后续的发展scrum master 做到最成功的地方就是，这Page 18研发团队相关研发团队相关团队人数要适当包含多种能力和角色将指派任务改为自由领取每次迭代改进一点形成自我组织的团队将镀金行为转换为迭代需求文档是必要的记得更新任务状态18研发团队相关团队人数要适当18Page 19团队人数要适当团队人数要适当有的团队人数太多，每天早上开站立会议都要很长时间。团队人数太少，无法完成大的功能突破。建议5-9人。scrum master和product owner不是team成员19团队人数要适当有的团队人数太多，每天早上开站立会议都要很长时Page 20包含多种能力和角色包含多种能力和角色比如后台和前台比如测试比如DBA完成本期迭代所需要的所有技能20包含多种能力和角色比如后台和前台20Page 21将指派任务改为自由领取将指派任务改为自由领取传统项目管理中，都是项目经理分解任务，然后指派到人。现在改为团队自主分解，自由领取。一定要选择自己感兴趣的。21将指派任务改为自由领取传统项目管理中，都是项目经理分解任务，Page 22每次迭代改进一点每次迭代改进一点在每次迭代后，找到可以改进的地方持续改进找到适合团队最佳的开发实践22每次迭代改进一点在每次迭代后，找到可以改进的地方22Page 23要形成自我组织的团队要形成自我组织的团队要形成自我组织的团队。项目经理的放权。开发团队成员自主意识的崛起。23要形成自我组织的团队要形成自我组织的团队。23Page 24将镀金行为转换为迭代需求将镀金行为转换为迭代需求某位开发人员很开心的说，我又增加了一个功能。这个功能可能会酷，但它不在我们的计划范围内。功能可能会带来很多意想不到的问题，甚至后果很严重。有想法可以提技术类的需求，排到迭代中。24将镀金行为转换为迭代需求某位开发人员很开心的说，我又增加了一Page 25文档是必要的文档是必要的敏捷并不是不需要文档各种各样的设计文档，比如数据库设计文档，api接口文档。安装部署文档。25文档是必要的敏捷并不是不需要文档25Page 26记得更新任务状态记得更新任务状态燃尽图开始横着走啦。每天应当重新估计自己所负责任务的预计剩余时间。26记得更新任务状态燃尽图开始横着走啦。26Page 27测试人员相关测试人员相关bug管理及时关注task及bug的进度积极并认真地参与会议测试用例需经产品经理和开发人员复查27测试人员相关bug管理27Page 28bug管理管理所有bug，不论bug的严重程度和bug的紧急程度，都要在禅道上有体现。确认是bug的，关闭该bug时，解决方案不是“已解决”的，都必须备注关闭原因。其中“不予解决”和“延期处理”的必须经产品经理确认后方可关闭。每天下班前在对应的项目群里发出所有未修正的bug列表，并对应开发。线下测试时新版本发布后，先验证禅道上已解决的bug，再继续接下来的测试工作。28bug管理所有bug，不论bug的严重程度和bug的紧急程度Page 29及时关注及时关注task及及bug的进度的进度最小可测试单元完成开发后，及时测试bug修复后，及时部署到测试环境并回归29及时关注task及bug的进度最小可测试单元完成开发后，及时Page 30积极并认真地参与会议积极并认真地参与会议务必参与以下会议需求讨论会每日站会参会前一定要准备充分，如在需求讨论会之前，熟悉需求文档、原型图和流程图。30积极并认真地参与会议务必参与以下会议30Page 31测试用例需经产品经理和开发人员复查测试用例需经产品经理和开发人员复查测试用例完成后，需告知产品经理和开发人员产品经理和开发人员可以从不同的角度对测试用例进行完善。31测试用例需经产品经理和开发人员复查测试用例完成后，需告知产品Page 32会议相关会议相关计划会议不宜太长站立会议不宜太长演示会议的必要性回顾会议的必要性32会议相关计划会议不宜太长32Page 33计划会议不宜太长计划会议不宜太长33产品计划会议和迭代计划会议严格控制在一天内结束。scrum master需要主要掌控会议进程。在召开产品计划会议之前，scrum master和产品负责人可以事先做一些准备。计划会议不宜太长33产品计划会议和迭代计划会议严格控制在一天Page 34站立会议不宜太长站立会议不宜太长站立会议最好控制在15分钟内。站立会议主要的目的在于沟通，团队成员之间彼此更新信息，及时发现风险。不是问题的解决会议。问题应该在会后讨论，并由相关人员加以解决。34站立会议不宜太长站立会议最好控制在15分钟内。34Page 35演示会议的必要性演示会议的必要性演示会议是非常好的展示团队风采和提升团队士气，增加成就感的方式。也是非常好的展示产品和获得反馈的机会。也是对外证明，我们的游戏规则是遵守的，你可以信赖我们。35演示会议的必要性演示会议是非常好的展示团队风采和提升团队士气Page 36回顾会议的必要性回顾会议的必要性回顾会议是为了持续改进。会议要形成计划，产生行动。36回顾会议的必要性回顾会议是为了持续改进。36Page 3737谢谢结束结束37谢谢结束