如何实施scrum及常见问题-精选版.ppt

Page ? * Page ? * 如何实施scrum及常见问题 青岛易软天创网络科技有限公司 2012/4/14 * 实施scrum几个阶段 第一阶段：严格按照scrum的流程进行。 scrum已经是最简流程，不宜再进行删减。 学习一样东西很重要的就是初心，把原有的东西放下。 组织结构层面的支持非常重要。 第二阶段：根据团队实际情况进行调整。 找到团队最佳的迭代周期。 找到团队最佳的开发实践。 建立产品的发布节奏。 * 传统团队转向敏捷团队 瀑布开发转向迭代开发。 固定的迭代周期，迭代周期内不能随意改变需求。 项目经理转向scrum master 放权 产品经理转向 product owner 项目成员转向 team member 需求改用 user story 跟踪 任务分解改为团队来做。 任务指派改为自由领取。 甘特图改用燃尽图。 独立考核改为团队的共进退。 * 开好几个会议 计划会议第一部分：做好优先级的排序，考虑投入产出。 计划会议的第二部分：团队分解，自主领取。 每日的站立会议：控制时间，重在沟通，非汇报会议。不解决问题。 演示会议：展示成果，得到反馈。提高团队成就感。 总结会议：逐步改进实践。 * 逐步找到适合团队的开发实践 结对编程 代码规范 源代码管理 代码review 每日提交 交叉测试 重构 分享会议 简单设计 自动化测试 框架 * 产品常见问题 如何写用户故事？ 是否还需要原型图？ 是否还需要详细设计？ 如何决定用户故事的优先级？ 向迭代中添加需求 没有发布计划 没有定义需求完成的标准 不参与研发过程。 * 如何写用户故事 角色，做的事情，价值或者原因。 定义完成的标准。 User Story应遵循INVEST规则： Independent 独立性，避免与其他Story的依赖性。 Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。 有价值性， Story需要体现出对于用户的价值 Estimable 可估计性，Story应可以估计出Task的开发时间。 Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。 Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test. * 是否还需要原型图？ scrum里面并没有规定要写原型图。 原型图比较直观，可以作为user story的补充。 * 是否还需要详细设计？ 不需要。 应当将之前写的需求的详细设计，或者产品规格说明书拆解，拆分成一个个的user story. 原因： 无法排序 无法单独跟踪 限制了研发团队的发挥 * 如何规定用户故事的优先级？ 根据需求的价值和投入来估算ROI，投入产出比。 有的需求价值很高，但开发团队实现起来非常难，也是不行的。 * scrum杀手：向迭代中添加需求 某天，大老板说，我们要做个什么东东。 产品经理就找项目经理(scrum master)，说，老板说了，要做个什么事情。项目经理就把需求加上去了。 或者产品经理直接找到研发人员，偷偷摸摸的加上功能。 scrum master应勇敢的说, no, 请等待n周。 * 没有定义user story完成的标准 也就是最重要的几个用例，要定义这个需求完成的标准是什么。 比如一个用户登录功能，其完成的标准： 输入正常的用户名和密码，应当能够登录系统。 输入错误的用户名和密码，应当提示登录错误。 * 不参与研发过程 不参与研发过程，和开发团队有对立情况。 应当及时和开发团队进行沟通和交流，随时发现问题，随时解决。 可以考虑完成某一个功能之后，就立马验证。 * 项目经理相关 从管理者转为服务者 关于考核 后续如何发展？ * 从管理者转为服务者 从原来的管理者转变为服务者 心态的调整 从事必躬亲改为放权 放手让团队去做，允许团队犯错 * 如何考核员工？ 敏捷开发团队更是一个整体。 共进共退，荣誉与共 团队的集体考核 团队内部自己进行考核 * 后续发展方向 scrum master 做到最成功的地方就是这个团队不再需要你了。 那么肯定有项目经理犯嘀咕了，那我怎么办啊。 可能的方向： scum master trainer：培养更多的scrum master 带其他的团队 专向架构师 转向产品 转向开发团队 * 开发团队相关 团队人数要适当 包含多种能力和角色 指派任务改为自由领取任务 每期项目改进一点 自我组织的团队 镀金行为 文档 忘记更新燃尽图 * 团队人数要适当 有的团队人数太多，每天早上开站立会议都要很长时间。 团队人数太少，无法完