scrum敏捷开发模式.ppt

Scrum敏捷开发模式 在研发团队的应用 目录 培训目的 我们的背景 Scrum敏捷开发方法简介 Scrum是一个轻量级的软件开发方法，它通过一个或多个跨职能的小型团队分多个迭代持续增量的交付软件产品。通过迭代和快速用户反馈来管理不确定性和拥抱变化。 在Scrum中，使用产品Backlog管理产品或项目需求。 Sprint计划会分析、讨论和估算得到一个Sprint的任务列表。 每个迭代结束时，Scrum团队将交付潜在的可交付的产品增量。 沟通不及时之困—推到“角色墙”组建多角色分层敏捷团队 在产品研发过程中，仅仅依靠文档进行知识传递是远远不够的，往往一个产品 的研发效率与这个团队的沟通氛围有直接关系。为了解决沟通不及时，在组建Scrum敏捷团队时，推到“角色墙”，组建多角色分层敏捷团队，使不同角色之间沟通无障碍，并通过日常7会议确保有效沟通。 组建敏捷团队： 推到“角色墙”组建多角色分层敏捷团队 研发部门的Scrum团队由3层Scrum团队构成：Scrum开发团队、业务级Scrum团队、部门级Scrum团队。 Scrum开发团队：根据人员规模和产品模块的耦合度，分成多个Scrum开发团队，每个团队由6-8人组成，包括需求分析师、开发经理、开发工程师、测试工程师，团队的ScrumMaster由开发经理担当； 推到“角色墙”组建多角色分层敏捷团队 业务级Scrum团队：虚拟团队，分别由不同Scrum开发团队相同角色构成，包括“需求Scrum团队”、“开发经理Scrum团队”、“测试Scrum团队”，各自团队的Scrum Master分别由需求经理、主设计、测试经理担当； 部门级Scrum团队：虚拟团队，由各业务级Scrum团队的Scrum Master构成，Scrum Master由部门经理或主设计担当； 以NC资金开发部的组织结构图为例： 推到“角色墙”组建多角色分层敏捷团队 团队各角色职责如下： 推到“角色墙”组建多角色分层敏捷团队 日常7个会议确保有效沟通 需求不稳定之困—分阶段细化需求，并行研发 根据Scrum敏捷研发思想，通过分阶段细化研发范围，确定每个迭代的需求Backlog，并行研发，减少需求变化对后续开发活动的影响。并且，通过定期召开“需求会议”和“下一次迭代内容沟通”，稳步推进需求逐步细化，为后续开发工作提前做准备。 编写迭代详细需求 根据产品概要需求，编写迭代详细需求文档，并形成SprintBacklog,确定迭代的工作范围，每个backlog的编写遵循以下格式的关键要素： As a<role>,I want to <goal> so i can <business value>. 通过四步骤完成： 1.找出角色（role）； 2.明确不同角色能够做什么（goal）； 3.确定怎样做会给该角色带来的好处（business value）； 4.明确其衡量标准（Acceptance Test）。 分阶段细化需求，并行研发 Backlog示例如下： 分阶段细化需求，并行研发 两层级沟通会逐渐细化明确研发范围 需求会议： 每个迭代中期召开； 各Scrum开发团队需求分析师讨论下一迭代Sprint目标； 确定下一迭代Backlog优先级； 讨论需要跨团队协调问题，指定责任人； 全员发布会议内容; 会议以需求Scrum团队为单位。 下一迭代内容沟通会： 每个迭代中期召开； 需求分析师向Scrum开发团队说明下一迭代工作目标和范围； 开发经理和测试工程师粗略估计工作量，最终确定下一迭代Backlog; 全员发布会议内容; 会议以开发Scrum团队为单位。 (会议的具体说明，详见附件) 计划执行差之困—分阶段制定并跟踪开发计划 在研发过程中，由于时常受到一些计划之外工作的干扰，譬如突发的项目支持问题、需求变更，往往导致制定的计划执行性差。结合Scrum敏捷研发思想，采用分阶段执行并跟踪计划，来确保计划的可执行性。包括估算迭代工作量、明确迭代频度，和从计划制定、发布到跟踪的日常4个会议，随时发现进度风险。 估算迭代工作量 Scrum敏捷应用的工作量估算，主要通过估算总工期、计算平均生存力，最终完成总工作量的估算。 总工作量=开发时间+需求讨论及设计交流时间 开发时间=总工期/平均生存力/开发人数 需求讨论及设计交流时间=开发时间*30% 1.估算总工期 根据Product Backlog条目，逐条进行估算。 分阶段制定并跟踪开发计划 2