第七章：敏捷开发工具方法-part1-敏捷开发基础

一、Scrum基础概念

敏捷开发背景
速度是企业竞争致胜的关键因素，软件项目的最大挑战在于一方面需要应付变动中的需求，一方面需要在有限的时间完成项目，传统的软件工程难以满足这些要求
所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。

1.1 传统开发模式与敏捷开发的区别

1、瀑布开发：

• 预见性开发模式
• 每一个步骤有严格产出成果
• 设计越完美，成本损失越小
• 不适应快速变化
  
  2、敏捷开发
• 人和交互重于过程和工具
• 可工作的软件 重于全而完备的文档
• 客户协作 重于合同谈判
• 随时应对变化 重于 循规蹈矩
  

1.2 传统项目管理与敏捷项目管理的区别

1、传统项目管理

• 事先对整个项目进行估计、计划、分析
• 反对变更，变更需要重新估计、重新规些
• 严密的合同来减少风险，如果改变需求要走CR 流程
• 项目作为一个“黑盒子”，对客户与供应商的可视性差
• 文档和计划驱动的方法软件交付时间晚，意识到风险的时间晚WBS,甘特图,关键路径分析

2、敏捷项目管理

• 对整个项目做一个粗略的估计,每一次迭代都有详细的计划
• 鼓励变化，客户价值驱动开发
• 信任和赋予权力;合约使变更变得简单，增加价值
• 客户和开发人员之间是紧密的连续的合作关系
• 每次迭代都产生可交付的软件，专注于交付软件
• 第一次迭代就可交付能工作的版本，风险发现的早

1.3 敏捷宣言

1、敏捷宣言

1. 个体和交互 胜于 流程和工具
2. 可工作软件 胜于 几长的文档
3. 与客户协作 胜于 合同的谈判
4. 对变化响应 胜于 遵循原计划

敏捷开发的核心思想是: 以人为本，适应变化敏捷思想是:一种以人为核心、迭代、循序渐进的开发方法

2、敏捷开发12个原则

1. 最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
2. 即使到了开发的后期，也欢迎改变需求。
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的 时间间隔越短越好
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个人来构建项目。
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的 交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡平稳的开发节奏;发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单化是根本(不做过度设计和预测)
11. 最好的构架、需求和设计出自于自组织的团队。
12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。

1.4 敏捷开发的特征

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

1、敏捷的方法

敏捷方法包括：Extreme Programming（XP）极限编程、Scrum、Adaptive Software Development (ASD)自适应软件开发、Crystal Clear and Other Crystal Methodologies水晶方法、Dynamic Systems Development Method (DSDM)动态系统开发方法 等等

1、Extreme Programming（XP）极限编程

• XP我们一般称为极限编程，是最轻量级的开发流程。每个Sprint的迭代周期大致为1-2周。
• 最主要的精神是：在客户有系统需求时，给予及时满意的可执行程序、所以最适合需求快速变动的项目
• 它强调客户所要的是：
  • workable的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作
• XP的实践包括：
  • 完整团队、计划游戏、客户测试、简单设计、结对编程、测试驱动开发、改进设计、持续集成、集体代码所有权
  • 编码标准、隐喻、可持续的速度
    
    2、Scrum整体框架
• Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开
  发过程。
• 在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2至4周
• 在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。
• 在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个选代结束时，Scrum团队将递交潜在可交付的产品增量
  

二、角色与职责

本节介绍Scrum开发方法下的角色与职责。

• 角色包括：Product Owner(PO)产品负责人（所有者），Scrum Master 敏捷教练，Team团队
• Artfacts工件 ： Product Backlog 产品Backlog（需求清单），Sprint Backlog 迭代Backlog，Increment潜在可交付产品增量
• Ceremonies仪式（敏捷开发过程中的会议）：PB Refinement 产品需求澄清、Sprint Review 迭代计划会议、Daily Meeting 每日立会、Sprint Review 评审会议、Sprint Retrospective回顾会议
  特性Features：Courage勇气，Openness 开放、Commitment 承诺、Focus 专注、Respect 尊重

2.1 Scrum Team

Scrum 的基本单位是小团队(一般10人以下)，称为Scrum Team。Scrum Team，一名Scrum MasterProduct Owner 和 Developers 组成。在 Scrum Team 中，没有子团队或层次结构。Scrum Team是具有凝聚力的专业团体，一次专注于一个目标，即 Product Goal。
Scrum Team 是跨职能的(cross-functional)，这意味着团队成员具有在每个 Sprint 中创造价值而所害的全部技能。他们也是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。
Scrum Team 规模足够小以保持灵活，同时足够大以便可以在 一个 Sprint 中完成重要的工作，通常只有 10 人或更少。总的来说，我们发现较小的团队沟通更好，效率更高。如果 Scrum Team变得太大，则应考虑将他们重组为多个具有凝聚力的Scrum Team，每个团队都专注于同一产品。因此，他们应该共享相同的Product Goal、Product Backlog 和 Product Owner。

1、Developers

• 为 Sprint 创建计划，即Sprint Backlog;
• 通过遵循 Definition of Done 来注入质量;
• 每天根据 Sprint Goal 调整计划;
• 作为专业人士对彼此负责。

2、Product Owner

• Product Owner 负责将Scrum Team 的工作所产生的产品价值最大化
• Product Owner 还负责对Product Backlog 进行有效管理，包括:
  • 开发并明确地沟通Product Goal;
  • 创建并清晰地沟通Product Backlog 条目 (items);
  • 对 Product Backlog 条目进行排序:
  • 确保 Product Backlog 是透明的、可见的和可理解的。
• Product Ower 可以自己做上述工作，或者也可以将职责委托他人。然而无论如何，ProductOwner 是负最终责任的人。
• 为保证 Product Owner 取得成功，整个组织必须尊重他们的决定。这些决定在Product Backlog的内容和顺序中可见，并在 Sprint Review 时透过可检视的 Increment 予以体现。

3、Scrum Master

• 负责按照Scrum 指南的游戏规则来建立Scrum。他们通过帮助Scrum Team 和组织内Scrum Master的每个人理解 Scrum 理论和实践来做到这一点

• Scrum Master 以多种方式服务于Scrum Team，包括:

  • 作为教练在自管理和跨职能方面辅导Scrum Team 成员;
  • 帮助 Scrum Team 专注于创建符合 Definition of Done 的高价值 Increment;
  • 促使移除 Scrum Team 工作进展中的障碍:
  • 确保所有 Scrum 事件都发生并且是积极的、富有成效的，并且在时间盒 (timebox)内完成。

• 负责按照Scrum 指南的游戏规则来建立Scrum。Scrum Master的每个人理解 Scrum 理论和实践来做到这一点

• Scrum Master 以多种方式服务于Product Owner，包括

  • 帮助找到有效定义Product Goal 和管理Product Backlog 的技巧;
  • 帮助 Scrum Team 理解为何需要清晰且简明的Product Backlog 条目;
  • 帮助建立针对复杂环境的基于经验主义的产品规划 (empirical product planning);
  • 当需要或被要求时，引导利益攸关者协作。

• Scrum Master 负责按照Scrum 指南的游戏规则来建立Scrum。他们通过帮助Scrum Team 和组织内的每个人理解 Scrum 理论和实践来做到这一点

• Scrum Master 以多种方式服务于组织，包括

  • 带领、培训和作为教练辅导组织采纳Scrum;
  • 在组织范围内规划并建议Scrum 的实施
  • 帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法 (empirical
    approach):
  • 消除利益攸关者和Scrum Teams 之间的隔阂。

2.2 角色职责总结

Scrum团队总结出来有：三个角色，四个仪式，三个物件
1、三个角色
- 产品负责人
- Scrum Master
- 团队
2、四个仪式
- Sprint计划会议
- 每日站会
- Sprint评审会议
- Sprint 回顾会议
3、三个物件
- 产品Backlog
- Sprint Backlog
- 燃尽图

2.3、研发阶段概览

1、Sprint计划会议

• 团队从产品backlog中挑选他们承诺完成的条目。
• 创建Sprint Backlog
  • 标识具体的任务并为任务做估算
  • 由团队协作完成，而不是Scrum Master
• 考虑了高层设计
• Sprint 计划会议会产生一些实实在在的成果
  • Sprint目标
  • 团队成员名单(以及他们的投入程度，如果不是 100%的话)
  • Sprint backlog(即 Sprint 中包括的故事列表)
  • 确定好 Sprint 演示日期
  • 确定好时间地点，供举行每日 Scrum 会议
    

2、产品实施阶段

- 产品实施阶段工作:
	- 开发、测试、监控.
- 方法:
	- 任务看板、燃尽图、每日立会
- Sprint backlog的形式
	- Redmine、Jira、禅道、阿里云效等等
	
	**燃尽图**
> 燃尽图 (burn down chart) 是在项目完成之前，对需要完成的工作的一种可视化表示。
> 分为：Sprint燃尽图，迭代燃尽图
> Sprint燃尽图展示了以故事点表示的在本轮迭代中剩余的工作量。
> y轴：预估剩下的故事点
> x轴：日期(非工作日除外)
> y/x=生产率
燃尽图分板示例：
![在这里插入图片描述](https://img-blog.csdnimg.cn/b68feeffc2cc4541baab4d613eefdba4.png)

哪些信息可以从每日燃尽图中得到，却不能从迭代燃尽图中得到?
每日燃尽图显示了团队在某轮迭代中的进度，你可以用这个信息判断计划的工作能否在迭代结束时都能完成。

哪些情况下燃尽图会有向上的趋势
加新任务的速度比完成任务的速度快
有大量的任务被低估了

每日例会

• 最好在每天早上开，时间一般控制在15分钟之内
• 条件允许的话，会议最好每天都在同一时间同一地点举行
• 谁都可以参加这个会议，但只有团队成员发言，其它人员只能旁听
• 所有出席者都应站立(有助于保持会议简短)
• 确定更新燃尽图
• 会议由Scrum Master主持，在会上每个团队成员需要问3个问题
  • 我昨天完成了哪些工作
  • 我今天将要做什么
  • 我遇到哪些障碍

3、Sprint评审会议

• 在Sprint结束时召开，会议时间控制在两小时以内
• 开发团队展示这个Sprint中完成的功能，不需要PPT，一般是已经完成的功能DEMO
• 客户、管理层、Product Owner以及其它开发人员都可以参加
• 主要是对项目开发的进度通过对实际已完成产品功能的审核进行控制，由产品负责人断定实际所发两点的功能是否与既定的Sprint目标一致

4、Sprint回顾会议

• Sprint结束后，时间在1-3个小时
• 回顾刚结束的Sprint，对其进行总结和反思，审视和适应的能力是Scrum 的基础，在Sprint回顾会议期间，项目团队会分析Sprint中的成功经验和所遇到的阻碍，
• 产品负责人、Scrum团队和Scrum Master参加

三、敏捷开发实践

3.1、增量迭代

每个迭代有一个大约为1~4周的时间框，在SCRUM里称为一次冲刺(超过1个月的详细计划往往偏差很大)
每次迭代都应该有明确的目标
每次迭代都应该有明确的可演示的工作成果
迭代过程中项目团队应该尽量免受打扰
迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解

3.2、测试驱动开发

什么是测试驱动？

• 首先创建测试用例，然后开发软件通过测试(在开发代码前，首先编写测试代码)
• 一种设计软件的方法，而不仅仅是一种测试方法
• 所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护
• 不需要测试的工作不需要完成
• 所创建的测试用例通常替代详细的业务和技术需求定
• 测试也有效地驱动设计，使设计更加趋向于可行的设计
• 通常情况下需要自动测试的支持 (EUnit，JUnit etc.).
• 对于UI软件应用TDD方法有一定的困难

3.3、持续集成

极限编程称为“每日构建”

• 持续集成一般利用ant,maven,jenkins等工具
• 每日构建的好处：
  • 将集成风险降到最低
  • 降低质量风险
  • 提升士气
• 每日构建可以看做是项目的心跳，冒烟测试就像是听诊器
• 每日构建必须至少:成功编译、打包、发布;不含有任何明显的缺陷;通过冒烟测试

3.4、面对面交流

• 虽然如今通讯工具花样繁多，但面对面交流在某些场合下仍然是不可替代的;
• 敏捷开发把交流缺失问题考虑在内，要求团队成员彼此直接协作，尽量创造面对面交流的机会:
• 尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的。
• 署名共享需求文档只会打开曲解和误解之门更不用说书面信息比口头交流还要慢很多

其他：

• 结对编程、每日立会、用户故事、团队工作室、频繁发布、自组织团队、重构

3.5、Scrum何时 使用更有效

• 公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法
• 敏捷方法对需求不完整以及经常变换的项目比较有效
• 项目可以划分成固定时间间隔的迭代，并且可以冻结正在进行的迭代的范围
• 公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master
• 项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.(Scrum of
  Scrums，Scrum的扩展)
• 才队成员能够以自组织的方式工作
• 项目的合同允许变更：固定价格的项目可以使用敏捷，但应当尽量避免。最好在按时间和材料付费或者按月付费的项目中进行使用、变更项目的范围不需要高级管理层的批准