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