Scrum敏捷项目管理
敏捷的背景与动机
软件危机及软件工程的出现
速度是企业竞争致胜的关键因素，软件项目的最大挑战在于
一方面要应付变动中的需求
一方面要在紧缩的时程内完成项目
传统的软件工程难以满足这些要求
所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。
软件项目的复杂性
横轴代表需求的复杂度!
纵轴表示技术的复杂度
还有人力资源的复杂度
解决复杂性问题需要采用经验式方式
解决问题的两种方式：
预定义过程控制（富士康流水线生产）
经验性过程控制（摸着石头过河）
如果复杂度超过预定义方式的能力范围，应该采用经验性方式
经验性方式的三大支柱：可见性、检查及适应
敏捷的历史
敏捷软件开发又称敏捷开发，
从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。
2001年初，因观察到许多的软件团队身陷不断扩大的流程之中的困境，一群业界专家聚集在一起，勾勒出一些能让软件团队迅速工作，以及响应变化的价值观和原则。他们自称为Agile Alliance。
之后的七个月里，他们创造具有价值的声明，也就是敏捷软件的开发宣言。
十五人中包括：大名鼎鼎的Kent Beck（XP,TDD的创始人,Junit的创始人之一）、Ward Cunningham（Wiki概念的发明者）、Martin Fowler（《企业应用架构模式》作者）、Robert C. Martin、Ken Schwaber
敏捷价值观之敏捷宣言
敏捷开发的核心思想是：以人为本，适应变化。
个体和交互胜过过程和工具：
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)动态系统开发方法 等
敏捷方法 VS. 瀑布模型
瀑布模型
固定的、没有弹性的。
很困难去达到互动。
假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的model是比较不适合的。
敏捷方法
完整地开发，每少数几周或是少数几个月里可以测试功能。
强调在获得最简短的可执行功能的部分，能够及早给予企业价值。
在整个项目的生命周期里，可以持续的改善、增加未来的功能。
瀑布模型：
敏捷方法：
敏捷项目管理VS传统项目管理
传统项目管理：
- 事先对整个项目进行估计、计划、分析
- 反对变更; 变更需要重新估计、重新规划
- 严密的合同来减少风险, 如果改变需求要走 CR 流程.
- 项目作为一个“黑盒子” ，对客户与供应商的可视性差.
- 文档和计划驱动的方法.
- 软件交付时间晚, 意识到风险的时间晚.
- WBS,甘特图,关键路径分析
敏捷项目管理:
- 对整个项目做一个粗略的估计,每一次迭代都有详细的计划.
- 鼓励变化, 客户价值驱动开发.
- 信任和赋予权力;合约使变更变得简单，增加价值.
- 客户和开发人员之间是紧密的连续的合作关系
- 每次迭代都产生可交付的软件
- 专注于交付软件.
- 第一次迭代就可交付能工作的版本，风险发现的早.
敏捷 与CMMI双剑合璧
CMMI更加关注于流程，敏捷更加关注于人
CMMI自顶向下，敏捷自底向上
敏捷并不排斥必要的文档
敏捷的很多实践是对CMMI的一种实现，比如sprint计划会议就是PP的实现，每日例会就是在做PMC
很多CMMI4~5级的公司也在应用敏捷，比如说宝信、华为
项目级的敏捷实践通过CMMI可以在组织级得以重用
eXtreme Programming
XP我们一般称为极限编程，是最轻量级的开发流程。
最主要的精神是
『在客户有系统需求时，给予及时满意的可执行程序』，所以最适合需求快速变动的项目。
它强调客户所要的是
workable的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作。
XP的实践包括：
完整团队、计划游戏、客户测试
简单设计、结对编程、测试驱动开发
改进设计、持续集成、集体代码所有权
编码标准、隐喻、可持续的速度
Scrum开发流程
为什么采用敏捷? –预期的收益
采用敏捷方法得当的话，可以：
- 更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险 .
- 快速交付, 每次迭代都能交付可运行的软件.
- 最高风险和最高优先级的需求，最优先进行开发.
- 改善应对变更能力, 减少大量的重计划.
- 改善项目沟通.
- 更好的客户参与, 避免错误的假设.
总之:
- 提高了生产率; 减少“浪费” （不需要的文档，重复工作等） ，项目的每次迭代都有明确的目标.
- 提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结束产生可以运行的软件.
- 改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）.
敏捷关键实践1——增量迭代
- 每个迭代有一个大约为1～4周的时间框，在SCRUM里称为一次冲刺（超过1个月的详细计划往往偏差很大）
- 每次迭代都应该有明确的目标
- 每次迭代都应该有明确的可演示的工作成果
- 迭代过程中项目团队应该尽量免受打扰
- 迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解
敏捷关键实践2——测试驱动开发 TDD
什么是测试驱动？
- 首先创建测试用例，然后开发软件通过测试(在开发代码前，首先编写测试代码)
- 一种设计软件的方法，而不仅仅是一种测试方法
- 所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护
- 不需要测试的工作不需要完成
- 所创建的测试用例通常替代详细的业务和技术需求定
- 测试也有效地驱动设计，使设计更加趋向于可行的设计
- 通常情况下需要自动测试的支持 (EUnit, JUnit etc.).
- 对于UI软件应用TDD方法有一定的困难
敏捷关键实践3——持续集成
极限编程称为“每日构建”
持续集成一般利用ANT、MAVEN等工具
日构建的好处：
将集成风险降到最低
降低质量风险
提升士气
日构建可以看做是项目的心跳，冒烟测试就像是听诊器
日构建必须至少：成功编译、打包、发布；不含有任何明显的缺陷；通过冒烟测试
敏捷关键实践4——面对面交流
虽然如今通讯工具花样繁多，但面对面交流在某些场合下仍然是不可替代的；
敏捷开发把交流缺失问题考虑在内，要求团队成员彼此直接协作，尽量创造面对面交流的机会；
尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的。
匿名共享需求文档只会打开曲解和误解之门，更不用说书面信息比口头交流还要慢很多。
敏捷方法的其它实践
- 结对编程
- 每日立会
- 用户故事
- 团队工作室
- 频繁发布
- 自组织团队
- 重构
重构——改善既有代码的设计
Martin Fowler提出
代码的坏味道
Martin Fowler和Kent Beck列举了22种坏味道：冗余代码、冗长的方法、巨大的类、过多的参数等等
重构可以弥补设计的不足
简单设计的思想
重构与测试驱动的关系
TDD是重构的脚手架
IDE已经对主要的重构模式提供了自动化支持：Rename, extract method, move field等等
简单设计>>测试用例>>实现再说>>（重构>>回归测试）*
Scrum何时更有效？
公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.
敏捷方法对需求不完整以及经常变换的项目比较有效.
项目可以划分成固定时间间隔的迭代, 并且可以冻结正在进行的迭代的范围
公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.
项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.（Scrum of Scrums，Scrum的扩展）
团队成员能够以自组织的方式工作.
项目的合同允许变更.
固定价格的项目可以使用敏捷，但应当尽量避免。
最好在按时间和材料付费或者按月付费的项目中进行使用、
变更项目的范围不需要高级管理层的批准.
敏捷特别强调人的因素
相对于过程与工具，敏捷更强调“人”的因素。
诚信是基础
没有过程能够对诚信进行有效的约束
诚信与否是有效实施敏捷过程的最大限制
Scrum框架
Scrum角色
Scrum角色之Product Owner
产品负责人（Product Owner）的职责如下：
确定产品的功能。
决定发布的日期和发布内容。
为产品的profitability of the product (ROI)负责。
根据市场价值确定功能优先级。
每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）。
接受或拒绝接受开发团队的工作成果。
Scrum角色之ScrumMaster
作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:
- 保证团队资源完全可被利用并且全部是高产出的。
- 保证各个角色及职责的良好协作。
- 解决团队开发中的障碍。
- 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
- 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning
meetings。
Scrum角色之Scrum Team
一般情况人数在5-9个左右
团队要跨职能
（包括开发人员、测试人员、用户界面设计师等）
团队成员需要全职。
（有些情况例外，比如数据库管理员）
在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
高度的自我组织能力。
向Product Owner演示产品功能。
团队成员构成在sprint内不允许变化。
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 ，不需要任何文档.
敏捷是有严格要求的，也是面向质量的
根据沟通的需要产生相应的文档.
敏捷只是开发者的问题
基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.
采用敏捷方法的开发组/项目不需要制定计划
敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的.
敏捷项目的范围可以随时改变.
变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更
只对小项目适用
在中型和大型的项目中一样取得了成功
总结
Agile Software Development是软件开发所强调的一个精神，而不是一个方法。
遵循Agile Alliance所提的四个价值观与12个原则。
最常见的开发方式
XP
SCRUM
敏捷开发过程是一个艰苦的过程，重在实践
即使非敏捷的项目中也可以应用敏捷的实践经验
CMMI应该与敏捷实现融合，双剑合璧
参考ppt：
http://download.csdn.net/detail/qq1137623160/9828941