Scrum敏捷项目管理

敏捷的背景与动机

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

软件项目的复杂性

横轴代表需求的复杂度!
纵轴表示技术的复杂度
还有人力资源的复杂度

可以工作的软件胜过面面俱到的文档：
1、过多的面面俱到的文档往往比过少的文档更糟
2、软件开发的主要和中心活动是创建可以工作的软件
3、直到迫切需要并且意义重大时，才进行文档编制
4、编制的内部文档应尽量短小并且主题突出

客户合作胜过合同谈判：
1、客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
2、为开发团队和客户的协同工作方式提供指导的合同才是最好的合同

响应变化胜过循环计划：
1、变化是软件开发中存在的现实
2、计划必须有足够的灵活性与可塑性
3、短期的迭代的计划比中长期计划更有效

敏捷开发的12个原则

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

什么是敏捷方法/h2>

敏捷方法是一类软件开发流程的泛称；
敏捷方法是相对于传统的瀑布式软件过程提出的；
敏捷方法可以用敏捷宣言（4条）、敏捷原则（12条）来概括；
敏捷原则通过一系列的敏捷实践来体现出来；
敏捷方法有很多种。

敏捷的方法

1. Extreme Programming (XP)极限编程
2. Scrum
3. Adaptive Software Development (ASD)自适应软件开发
4. Crystal Clear and Other Crystal Methodologies水晶方法
5. Dynamic Systems Development Method (DSDM)动态系统开发方法 等

敏捷方法 VS. 瀑布模型

瀑布模型
固定的、没有弹性的。
很困难去达到互动。
假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的model是比较不适合的。
敏捷方法
完整地开发，每少数几周或是少数几个月里可以测试功能。
强调在获得最简短的可执行功能的部分，能够及早给予企业价值。
在整个项目的生命周期里，可以持续的改善、增加未来的功能。
瀑布模型：

敏捷项目管理VS传统项目管理

传统项目管理：

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

敏捷项目管理:

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

敏捷 与CMMI双剑合璧

CMMI更加关注于流程，敏捷更加关注于人
CMMI自顶向下，敏捷自底向上
敏捷并不排斥必要的文档
敏捷的很多实践是对CMMI的一种实现，比如sprint计划会议就是PP的实现，每日例会就是在做PMC
很多CMMI4~5级的公司也在应用敏捷，比如说宝信、华为
项目级的敏捷实践通过CMMI可以在组织级得以重用

Scrum开发流程

敏捷关键实践2——测试驱动开发 TDD

什么是测试驱动/strong>

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

敏捷关键实践3——持续集成

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

敏捷关键实践4——面对面交流

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

敏捷方法的其它实践

1. 结对编程
2. 每日立会
3. 用户故事
4. 团队工作室
5. 频繁发布
6. 自组织团队

重构——改善既有代码的设计

Martin Fowler提出
代码的坏味道
Martin Fowler和Kent Beck列举了22种坏味道：冗余代码、冗长的方法、巨大的类、过多的参数等等
重构可以弥补设计的不足
简单设计的思想
重构与测试驱动的关系
TDD是重构的脚手架
IDE已经对主要的重构模式提供了自动化支持：Rename, extract method, move field等等
简单设计>>测试用例>>实现再说>>（重构>>回归测试）*

Scrum角色

Sprints(冲刺)

Scrum的项目过程有一系列的Sprint组成。
Sprint的长度一般控制在2-4周。
通过固定的周期保持良好的节奏。
产品的设计、开发、测试都在Sprint期间完成。
Sprint结束时交付可以工作的软件。
在Sprint过程中不允许发生变更。

Scrum仪式之Sprint计划会议

Scrum仪式之每日Scrum会议(Daily Scrum)

每日Scrum会议，即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立进行。
最好是每天早晨开，一般15分钟左右，时间比较短，也有利于团队成员安排好当天的工作。
只有团队成员可以在例会上发言，其他人员有兴趣可以参加，但只能旁听，不能发言。（小猪和小鸡的故事）
每日Scrum会议由Scrum Master主持， Scrum团队所有成员轮流回答以下3个问题：
昨天我完成了什么工作
今天我打算做什么
我在工作中遇到了什么困难

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)

Sprint Backlog 示例

扩展Scrum

一般情况一个团队的人数控制在5-9人
大型项目可以采用多团队，通过team of teams来扩展Scrum。
影响扩展的因素
团队规模
项目类型
项目周期
团队分布
Scrum曾被用于超过1000人团队规模的项目。

Scrum Of Scrums

完成的定义

当迭代任务清单上的任务都完成时，变为“已完成”状态
定义“已完成”的含义是非常重要的, 例如:
如何记录软件的变化.
使用什么样的代码分析工具 ，发现的问题应当如何处理.
进行了什么样的测试, 结果是如何记录的, 通过标准（如覆盖率、修正的错误）是什么.
定义“已完成”意味着定义质量上的需求.
“已完成”是0/1变量：完成或者未完成. 所有的任务（task)都完成了迭代任务才算完成.
在第一个迭代开始之前应该定义好，因为它会影响工作量, 而且必须文档化，这样团队和产品所有者的理解是一致的.

完成的定义 – Example

完成的定义
遵循编码规范
能在模拟器上演示
使用PCLint 进行静态代码分析
具有EUnit 测试套件的通过率 和执行率.
或者使用结对编程，或者进行代码走查

障碍

基本上，任何阻止团队正常工作的，都可称之为障碍，例如:
无法访问信息系统.
所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确
开发环境或者原型系统出现问题
其他的任务分配：培训，售前支持
缺乏必要的信息或者相应的知识

对于团队提出的各项障碍，Scrum Master要以列表形式进行记录，

谁来清除障碍/h2>

每个人
自我管理、自我组织的团队
Scrum Master
产品所有者
管理层
其他相关的干系人

Scrum Master 负责确定障碍已经清除，不一定亲自自己清除

清除障碍

某些障碍是浪费
部分地完成工作
额外的过程
额外的功能
任务转换
等待
缺陷

SCRUM实践

研发部2009年开始在几个项目当中进行了SCRUM项目管理的尝试：
营销综合停电系统开发
FLEX-ADP开发
海颐OA项目
等

SCRUM看板

SCRUM带来的改善

项目的计划性更强了，将项目按SPRINT进行分解，每个SPRINT要进行计划和总结，每天也有立会来进行简短的总结和计划；

引入SCRUM以后，项目团队的沟通比以往更有效，项目看板为项目团队沟通提供了一个统一的项目视图，每日立会是项目团队沟通的有效通道；

项目的阶段性比以前更明确，通过SPRINT将项目划分成阶段，通过SPRINT演示等活动将项目整体的压力分解到每个SPRINT，这样可以有效降低项目的整体风险。

一些常见的误解

敏捷是拯救任何项目的银弹.
敏捷方法只有运用得当才有效果.
敏捷意味着 ad-hoc hacking ，不需要任何文档.
敏捷是有严格要求的，也是面向质量的
根据沟通的需要产生相应的文档.
敏捷只是开发者的问题
基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.
采用敏捷方法的开发组/项目不需要制定计划
敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的.
敏捷项目的范围可以随时改变.
变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更
只对小项目适用
在中型和大型的项目中一样取得了成功

总结

Agile Software Development是软件开发所强调的一个精神，而不是一个方法。
遵循Agile Alliance所提的四个价值观与12个原则。
最常见的开发方式
XP
SCRUM
敏捷开发过程是一个艰苦的过程，重在实践
即使非敏捷的项目中也可以应用敏捷的实践经验
CMMI应该与敏捷实现融合，双剑合璧

参考ppt：
http://download.csdn.net/detail/qq1137623160/9828941