Scrum敏捷开发模式

2.进度曲线图看各迭代进度是否可控
每个迭代的完成标准是测试用例提交率100%，并通过迭代演示。 每个迭代的测试用例提交率在90%上下时，说明进度可控，延期率清晰可度量。 在进度稳定可控的情况下，各迭代内测试用例个数逐渐增多，生存率稳步提升。
3.缺陷积压曲线图看团队工作负荷与产品质量
每个迭代缺陷积压量相对平稳，团队工作负荷稳定
每个迭代中期召开；
需求分析师向Scrum开发团队说明下一迭代工作目标和范围； 开发经理和测试工程师粗略估计工作量，最终确定下一迭代Backlog; 全员发布会议内容; 会议以开发Scrum团队为单位。
(会议的具体说明，详见附件)
计划执行差之困—分阶段制定并跟踪开发计划
在研发过程中，由于时常受到一些计划之外工作的干扰，譬如突发的项目 支持问题、需求变更，往往导致制定的计划执行性差。结合Scrum敏捷研发思 想，采用分阶段执行并跟踪计划，来确保计划的可执行性。包括估算迭代工作 量、明确迭代频度，和从计划制定、发布到跟踪的日常4个会议，随时发现进 度风险。 估算迭代工作量
2.计算平均生产力 根据每位开发工程师的工作能力和工作经验估算生产力，计算平均生产力。
分阶段制定并跟踪开发计划
3.估算总工作量 总工作量估算以开发时间为主。
明确迭代频度
通常每个Sprint周期的长度由本版本产品的全部Backlog的总工期和开发团队的 研发效率来决定的，同时也要考虑产品的特点和团队成员的开发节奏。 通常会选择2-4周作为一个Sprint迭代周期，长短的优缺点： 短的Sprint周期，意味着短的反馈周期，更频繁的交付和用户反馈，在错误的 方向上花的时间更少，学习和改进速度更快。通常适用于需求变化频繁的产品 。 长的Sprint周期，意味着团队有更多时间充分准备和解决问题，达成Sprint目标 ，同时不必被批发的Sprint计划会和演示打断开发节奏，通常适用于需求稳定的产品。 特殊说明： 1.一旦确定Sprint周期，不要轻易调整，影响团队开发节奏，影响研发效率。 2.在一个部门组织内，存在多个Scrum团队时，尽量保持所有团队步调一致。
绩效考核结构图：
效果与价值
NC5.7版本对于资金管理产品而言，是一个极具挑战的版本，需要在不足6个 月内完成4个全新的产品模块开发，完成10个模块的大幅度升级改造，在功能 上达到超越竞争对手的目标，确立商场竞争优势，为后续的NC6.0开发奠定基 础。 采取Scrum敏捷开发方法后，工作质量和工作效率得到明显提升：
以NC资金开发部的组织结构图为例：
推到“角色墙”组建多角色分层敏捷团队
团队各角色职责如下：
推到“角色墙”组建多角色分层敏捷团队
日常7个会议确保有效沟通
需求不稳定之困—分阶段细化需求，并行研发
根据Scrum敏捷研发思想，通过分阶段细化研发范围，确定每个迭代的需 求Backlog，并行研发，减少需求变化对后续开发活动的影响。并且，通过定 期召开“需求会议”和“下一次迭代内容沟通”，稳步推进需求逐步细化，为 后续开发工作提前做准备。 编写迭代详细需求
谢 谢！
“迭代回顾会议”持续提升研发效率
会议关键点： 迭代完成时召开； 总结迭代开发过程中好的工作方式和可能的改进点； 团队成员以头脑风暴、轮流发言、自愿发言方式； 全员发布会议内容； 以Scrum开发团队为单位。
“敏捷研发绩效考核”机制
涵盖Scrum敏捷团队全部角色，同时兼顾在研产品研发和发版产品的项目支持，兼 顾研产品的缺陷修复和发版后的产品质量，兼顾任务完成率和完成质量，以及推动重新 的激励机制。
确认是否可以参与产品的研发过程，告知参与方式和频度，确定具体客户代表。
产品开发阶段
参与迭代演示会议，提出迭代成果评审意见。
用户验证阶段
参与用户验证，验证产品功能。
日常研发过程分析 1.燃尽图看Sprint内任务完成情况是否出现偏差
曲线明显偏向上方时，存在任务延期风险，明显偏向下方时，任务进度提前，需要增加 Backlog。
产品引用满足度不高之困—分阶段提前验证产品满 足度
根据Scrum敏捷开发思想，在每一个迭代最后召开“迭代演示会议”，研 发团队想架构师/产品经理或原型客户演示本次迭代的成果，把产品的应用验证 提前到每个迭代，为偏差留出修正空间。同时通过日常研发过程分析，发现其 中可能存在的风险，及时调整。 “迭代演示会议”提前验证满意度 迭代演示会议： 作为迭代成果验收会议，迭代完成时召开；
全员发布会议内容;
会议以开发Scrum团队为单位。 每日立会 每天早上召开；
每个成员汇报昨天的开发进度和今天的开发计划、及遇到的障碍；
会议以开发Scrum团队为单位。
分阶段制定并跟踪开发计划
开发经理会议 每个迭代中期召开； 各Scrum开发团队的开发经理汇报各自团队进度（尤其是接口协作任务进 度）; 确定下一迭代接口协作任务的开发顺序和完成时间； 说明各自团队遇到的障碍和问题，分享各自团队好的工作方法和成果； 全员发布会议内容; 会议以开发经理Scrum团队为单位。 进度评估会 每月召开一次； 需求开发、测试分别汇报研发进度； 说明各自业务团队遇到的障碍和问题，安排负责人协调解决； 全员发布会议内容; 会议以部门级Scrum团队为单位。
分阶段制定并跟踪开发计划
从计划制定、发布到追踪日常4个会议确保计划可执行
为了确保研发计划的有效执行，通过日常的4个会议，从计划制定、发布到追踪 ，保证计划的可执行性。
迭代计划会
作为迭代启动会议，迭代开始时召开； 确定本迭代目标和本迭代Backlog; 评估工作量，完成Backlog细化开发任务、及任务的分配；
后面重点讲解
我们的背景
问题 敏捷应用关键策略 效果
Scrum敏捷开发方法简介
Scrum是一个轻量级的软件开发方法，它通过一个或多个跨职能的小型团 队分多个迭代持续增量的交付软件产品。通过迭代和快速用户反馈来管理不确 定性和拥抱变化。
在Scrum中，使用产品Backlog管理产品或项目需求。
采用优先解决影响主流程缺陷的策略，新功能开发完成后（sprint7）,缺陷积压以简单控制 性错误为主，迅速收敛，产品质量无重大风险。
研发人员业务能力参差不齐之困—通过机制保证持续提升人 员业务能力和研发效率
“全员讲师全员培训”机制
研发团队业务能力的提升一直困扰着各个研发机构，也制约着研发效率的提升。在 Scrum敏捷应用过程中，每个人发挥各自擅长领域，人人都是讲师人人都参加培训，做 到全员培训营造学习型组织。
根据产品概要需求，编写迭代详细需求文档，并形成SprintBacklog,确定迭代的工 作范围，每个backlog的编写遵循以下格式的关键要素： As a<role>,I want to <goal> so i can <business value>. 通过四步骤完成： 1.找出角色（role）； 2.明确不同角色能够做什么（goal）； 3.确定怎样做会给该角色带来的好处（business value）； 4.明确其衡量标准（Acceptance Test）。
Scrum敏捷应用的工作量估算，主要通过估算总工期、计算平均生存力，最终完成总 工作量的估算。 总工作量=开发时间+需求讨论及设计交流时间 开发时间=总工期/平均生存力/开发人数 需求讨论及设计交流时间=开发时间*30% 1.估算总工期 根据Product Backlog条目，逐条进行估算。
分阶段制定并跟踪开发计划
效果与价值
同时也取得良好效果： 促进需求、开发、测试之间的有效沟通，实现需求、开发和测试的并行工作 ，缩短开发周期。 全新产品在开发初期引入客户验证，保证发版产品功能更符合客户的真实需 求。 每个迭代都进行产品功能和流程的成果演示，保证大的流程问题都在前期暴 露并解决，有效避免了集成测试节点出现流程错误问题的几率，后期开发任 务完成后，积压的缺陷可以迅速降低。 回顾会议中团队成员提出的流程和效率类改进建议有效的提高了团队整体的 工作效率。 有效提升团队的学习能力，实现团队内部的知识共享，缩短新员工的培训周 期。
培训目的
1.提高软件开发效率缩短产品 上市时间 2.提升客户满意度和快速响应 市场变化 1.强调开发团队与业务专家紧 密协作，面对面沟通 2.频繁交付新的软件版本 3.紧凑的自我组织型团队、能 够很好地适应需求变化的代 码编写和团队组织方法，注 重软件开发中“人”的作用。
需求分析师/经理 开发经理 开发/测试工程师和经理 部门经理、主设计 架构师/产品经理 原型客户
Scrum敏捷开发模式
在研发团队的应用
郑成龙 2015年8月
目录
培训目的 我们的背景 Scrum敏捷开发方法简介 Scrum敏捷开发整体解决策略 沟通不及时之困—推到“角色墙”组建多角色分层敏捷团队 需求不稳定之困—分阶段细化需求，并行研发 计划执行差之困—分阶段制定并跟踪开发计划 产品引用满足度不高之困—分阶段提前验证产品满足度 研发人员业务能力参差不齐之困—通过机制保证持续提升人员业 务能力和研发效率 效果与价值
Sprint计划会分析、讨论和估算得到一个Sprint的任务列表。
每个迭代结束时，Scrum团队将交付潜在的可交付的产品增量。
沟通不及时之困—推到“角色墙”组建多角色分层 敏捷团队
在产品研发过程中，仅仅依靠文档进行知识传递是远远不够的，往往一个 产品 的研发效率与这个团队的沟通氛围有直接关系。为了解决沟通不及时，在 组建Scrum敏捷团队时，推到“角色墙”，组建多角色分层敏捷团队，使不同 角色之间沟通无障碍，并通过日常7会议确保有效沟通。
推到“角色墙”组建多角色分层敏捷团队
业务级Scrum团队：虚拟团队，分别由不同Scrum开发团队相同角色构成， 包括“需求Scrum团队”、“开发经理Scrum团队”、“测试Scrum团队” ，各自团队的Scrum Master分别由需求经理、主设计、测试经理担当； 部门级Scrum团队：虚拟团队，由各业务级Scrum团队的Scrum Master构成 ，Scrum Master由部门经理或主设计担当；
由测试工程师演示本迭代成果（产品功能）;
架构师/产品经理或原型客户对迭代成果发表改进意见； 演示中的问题记入下一迭代工作内容； 全员发布迭代演示结果； 会议以Scrum开发团队为单位.
附引进原型客户的四个阶段： 概要分析阶段
找出原型客户，即业务需求清晰、业务应用熟悉，具有行业普遍性或领先性。
需求调研阶段
分阶段细化需求，并行研发
Backlog示例如下：
分阶段细化需求，并行研发
两层级沟通会逐渐细化明确研发范围
需求会议： 每个迭代中期召开； 各Scrum开发团队需求分析师讨论下一迭代Sprint目标； 确定下一迭代Backlog优先级； 讨论需要跨团队协调问题，指定责任人； 全员发布会议内容; 会议以需求Scrum团队为单位。 下一迭代内容沟通会：
组建敏捷团队：
推到“角色墙”பைடு நூலகம்建多角色分层敏捷团队
研发部门的Scrum团队由3层Scrum团队构成：Scrum开发团队、业务级Scrum 团队、部门级Scrum团队。 Scrum开发团队：根据人员规模和产品模块的耦合度，分成多个Scrum开发 团队，每个团队由6-8人组成，包括需求分析师、开发经理、开发工程师、测 试工程师，团队的ScrumMaster由开发经理担当；