敏捷的背景与动机
软件危机及软件工程的出现
速度是企业竞争致胜的关键因素，软件项目的最大挑战在于，
一方面要应付变动中的需求，一方面要在紧缩的时程内完成项目，
传统的软件工程难以满足这些要求
所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。
这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。
软件项目的复杂性
解决复杂性问题需要采用经验式方式
解决问题的两种方式：
预定义过程控制（富士康流水线生产）
经验性过程控制（摸着石头过河）
如果复杂度超过预定义方式的能力范围，应该采用经验性方式
经验性方式的三大支柱：可见性、检查及适应
敏捷价值观：敏捷宣言
敏捷开发的核心思想是：以人为本，适应变化。
个体和交互胜过过程和工具：
1、人是软件项目获得成功最为重要的因素
2、合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要
3、方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；
可以工作的软件胜过面面俱到的文档：
1、过多的面面俱到的文档往往比过少的文档更糟
2、软件开发的主要和中心活动是创建可以工作的软件
3、直到迫切需要并且意义重大时，才进行文档编制
4、编制的内部文档应尽量短小并且主题突出
客户合作胜过合同谈判：
1、客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
2、为开发团队和客户的协同工作方式提供指导的合同才是最好的合同
响应变化胜过循环计划：
1、变化是软件开发中存在的现实
2、计划必须有足够的灵活性与可塑性
3、短期的迭代的计划比中长期计划更有效
敏捷开发的12个原则
- 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
- 即使到了开发的后期，也欢迎改变需求。
- 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好 。
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
- 围绕被激励起来的个人来构建项目。
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
- 工作的软件是首要的进度度量标准。
- 敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
- 不断地关注优秀的技能和好的设计会增强敏捷能力。
- 简单化是根本（不做过度设计和预测）。
- 最好的构架、需求和设计出自于自组织的团队。
- 每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。
什么是敏捷方法？
敏捷方法是一类软件开发流程的泛称；
敏捷方法是相对于传统的瀑布式软件过程提出的；
敏捷方法可以用敏捷宣言（4条）、敏捷原则（12条）来概括；
敏捷原则通过一系列的敏捷实践来体现出来；
敏捷方法有很多种。
敏捷的方法
- Extreme Programming (XP)极限编程
- Scrum
- Adaptive Software Development (ASD)自适应软件开发
- Crystal Clear and Other Crystal Methodologies水晶方法
- Dynamic Systems Development Method (DSDM)动态系统开发方法 等
Scrum框架
Scrum角色
Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master 组成。Scrum 团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum 团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。Scrum 团队（自身）已经证明，对于所有之前所述 Scrum 的应用以及任何复杂工作来说，它都是越来越有效的。
Scrum 团队迭代增量式地交付产品，籍此最大化地获得反馈的机会。增量式交付“完成”的产品保证了一个可工作产品的潜在可用版本总是存在。
产品负责人
产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨组织、Scrum 团队和团队成员个体的不同而有所不同。
产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
• 清晰地表述产品待办列表项；
• 对产品待办列表项进行排序，使其最好地实现目标和使命；
• 优化开发团队所执行工作的价值；
• 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及
• 确保开发团队对产品待办列表项有足够深的了解。
产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。
产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。
为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另一套需求开展工作。
开发团队
开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。
开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应能最大化开发团队的整体效率和效用。
开发团队具有下列特点：
• 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
• 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
• Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
• Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
• 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
开发团队的规模
开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master 角色不包含在此数字中，除非他们同时也参与执行 Sprint 待办列表中的工作。
Scrum Master
Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。
Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。
Scrum Master 服务于产品负责人
Scrum Master 以各种方式服务于产品负责人，包括：
• 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
• 找到有效管理产品待办列表的技巧；
• 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
• 理解在经验主义的环境中的产品规划；
• 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
• 理解并实践敏捷性；以及，
• 按要求或需要引导 Scrum 事件。
Scrum Master 服务于开发团队
Scrum Master 以各种方式服务于开发团队，包括：
• 在自组织和跨职能方面给予开发团队指导；
• 帮助开发团队创造高价值的产品；
• 移除开发团队工作进展中的障碍；
• 按要求或需要引导 Scrum 事件；以及，
• 在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。
Scrum Master 服务于组织
Scrum Master 以各种方式服务于组织，包括：
• 带领并指导组织采纳 Scrum；
• 在组织范围内规划 Scrum 的实施；
• 帮助员工和利益攸关者理解并实施 Scrum 和经验产品开发；
• 引发能够提升 Scrum 团队生产率的改变；以及，
• 与其他 Scrum Master 一起工作，增加组织中 Scrum 应用的有效性。
Scrum 事件
Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是规定的，不能缩短或延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。
Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint 不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。
Sprint
Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。
Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。
在 Sprint 期间：
• 不能做出有害于 Sprint 目标的改变；
• 不能降低质量的目标；以及，
• 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会澄清和重新协商。
每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于完成某些事情。每个 Sprint 都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品增量。
Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一个月的成本上。
取消 Sprint
Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力，虽然他或她做这样的决定也可能受到来自利益攸关者、开发团队或是 Scrum Master 的影响。
如果 Sprint 目标过时，那么 Sprint 就会被取消。比如公司的发展方向或者市场上或技术上的状况发生改变，这些变化都可能导致 Sprint 被取消。总的来说，如果某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消。然而，由于 Sprint 的时间都很短，所以取消 Sprint 的意义不大。
当取消某个 Sprint 时，任何做完和“完成”的产品待办列表项都需要评审。假如成果的任何部分具有潜在可发布的话，产品负责人通常会接受这个成果。所有未完成的产品待办列表项都会被放回到产品待办列表中，并重新估算。花在它们身上的工作会很快地贬值，所以必须经常性地重估。
取消 Sprint 会消耗资源，因为每个人都重新集合在另外一个 Sprint 计划会议来开始另一个 Sprint 。取消 Sprint 通常会对 Scrum 团队造成重创，这种情况非常罕见。
Scrum 流程
Sprints(冲刺)
Scrum的项目过程有一系列的Sprint组成。
Sprint的长度一般控制在2-4周。
通过固定的周期保持良好的节奏。
产品的设计、开发、测试都在Sprint期间完成。
Sprint结束时交付可以工作的软件。
在Sprint过程中不允许发生变更。
Scrum仪式之Sprint计划会议
Scrum仪式之Sprint计划会议
Scrum仪式之每日Scrum会议(Daily Scrum)
每日Scrum会议，即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立进行。
最好是每天早晨开，一般15分钟左右，时间比较短，也有利于团队成员安排好当天的工作。
只有团队成员可以在例会上发言，其他人员有兴趣可以参加，但只能旁听，不能发言。（小猪和小鸡的故事）
每日Scrum会议由Scrum Master主持， Scrum团队所有成员轮流回答以下3个问题：
昨天我完成了什么工作？
今天我打算做什么？
我在工作中遇到了什么困难？
Scrum 任务板(Task Board)
任务板（墙）展现了在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。通常的任务板是下面这个样子:
Scrum仪式之Sprint评审会议
Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Product Owner会组织这阶段的会议并且邀请相关的干系人参加。
团队展示Sprint中完成的功能
一般是通过现场演示的方式展现功能和架构
不要太正式
不需要PPT
一般控制在2个小时
团队成员都要参加
可以邀请所有人参加
Scrum仪式之Sprint回顾会议
团队的定期自我检视，发现什么是好的，什么是不好的。
一般控制在15-30分钟
每个Sprint都要做
全体参加
Scrum Master
产品负责人
团队
可能的客户或其它干系人
Scrum物件之产品订单(Product Backlog)
一个需求的列表。
一般情况使用用户故事来表示backlog条目
理想情况每个需求项都对产品的客户或用户有价值
Backlog条目按照商业价值排列优先级
优先级由产品负责人来排列
在每个Sprint结束的时候要更新优先级的排列
Scrum物件之产品订单(Product Backlog)
Scrum物件之冲刺订单(Sprint Backlog)
Sprint Backlog 示例
Scrum物件之冲刺订单(Sprint Backlog)
管理Sprint的backlog:
团队成员自己挑选任务，而不是指派任务
对每一个任务，每天要更新剩余的工作量估算
每个团队成员都可以修改Sprint backlog，增加、删除或者修改任务
Scrum物件之燃尽图(Burn Down Chart)
扩展Scrum
一般情况一个团队的人数控制在5-9人
大型项目可以采用多团队，通过team of teams来扩展Scrum。
影响扩展的因素
团队规模
项目类型
项目周期
团队分布
Scrum曾被用于超过1000人团队规模的项目。
Scrum Of Scrums
Scrum项目之估计
Scrum团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单位Story Points (模糊的).
也可采用人天或者人小时作为单位，但容易混淆： a) 实际的规模 b) 时间的单位.
精确的估计值可以在Sprint 规划时给出, 当前阶段没有足够的信息.
规模的相对值才有意义.
这个估计值有助于确定优先级;
可以采用估算扑克
完成的定义
当迭代任务清单上的任务都完成时，变为“已完成”状态
定义“已完成”的含义是非常重要的, 例如:
如何记录软件的变化.
使用什么样的代码分析工具 ，发现的问题应当如何处理.
进行了什么样的测试, 结果是如何记录的, 通过标准（如覆盖率、修正的错误）是什么.
定义“已完成”意味着定义质量上的需求.
“已完成”是0/1变量：完成或者未完成. 所有的任务（task)都完成了迭代任务才算完成.
在第一个迭代开始之前应该定义好，因为它会影响工作量, 而且必须文档化，这样团队和产品所有者的理解是一致的.
完成的定义 - Example
完成的定义
遵循编码规范
能在模拟器上演示
使用PCLint 进行静态代码分析
具有EUnit 测试套件的通过率 和执行率.
或者使用结对编程，或者进行代码走查
障碍
基本上，任何阻止团队正常工作的，都可称之为障碍，例如:
无法访问信息系统.
所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确
开发环境或者原型系统出现问题
其他的任务分配：培训，售前支持
缺乏必要的信息或者相应的知识
对于团队提出的各项障碍，Scrum Master要以列表形式进行记录，
谁来清除障碍？
每个人
自我管理、自我组织的团队
Scrum Master
产品所有者
管理层
其他相关的干系人
Scrum Master 负责确定障碍已经清除，不一定亲自自己清除
清除障碍
某些障碍是浪费
部分地完成工作
额外的过程
额外的功能
任务转换
等待
缺陷
浪费产生的原因
多问几个“为什么”
对于每个标识的障碍或者浪费，问一问“为什么”浪费会存在
多问几个“为什么”，找到造成浪费的根本原因
SCRUM实践
研发部2009年开始在几个项目当中进行了SCRUM项目管理的尝试：
营销综合停电系统开发
FLEX-ADP开发
海颐OA项目
等
SCRUM看板
SCRUM燃尽图
SCRUM带来的改善
项目的计划性更强了，将项目按SPRINT进行分解，每个SPRINT要进行计划和总结，每天也有立会来进行简短的总结和计划；
引入SCRUM以后，项目团队的沟通比以往更有效，项目看板为项目团队沟通提供了一个统一的项目视图，每日立会是项目团队沟通的有效通道；
项目的阶段性比以前更明确，通过SPRINT将项目划分成阶段，通过SPRINT演示等活动将项目整体的压力分解到每个SPRINT，这样可以有效降低项目的整体风险。
一些常见的误解
敏捷是拯救任何项目的银弹.
敏捷方法只有运用得当才有效果.
敏捷意味着 ad-hoc hacking ，不需要任何文档.
敏捷是有严格要求的，也是面向质量的
根据沟通的需要产生相应的文档.
敏捷只是开发者的问题
基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.
采用敏捷方法的开发组/项目不需要制定计划
敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的.
敏捷项目的范围可以随时改变.
变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更
只对小项目适用
在中型和大型的项目中一样取得了成功
参考链接：