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