敏捷与瀑布

敏捷的定义

一种迭代式增量开发方法

• 敏捷提倡“轻量级”开发模式
  
• 敏捷要求分析和设计要适度而不是过度，而且敏捷更强调迭代
  
• 敏捷适合在很不明确、很不确定或快速变化的环境中使用
  
• 迭代周期不要太长，通常是2~4周
  

• 项目是通过一次次的较短周期迭代完成，每次迭代都有交付
  

  为什么需要敏捷

• 提高生产率
  

  • 减少“浪费”（不需要文档，重复工作等）
    
• 提高客户满意度
  
  • 短期内产生效果
    
  • 按预期交付
    
  • 每次迭代结束，产生可见的成果
    

• 改善工作满意度
  

  • 团队精神
    
  • 减少官僚
    
  • 能够规划和管理自己的工作
    
  • 稳定的工作量（可持续的步伐）
    

    敏捷宣言

• 个体与交互重于流程和工具
  

• 工作成果重于文档
  
• 客户协作重于谈判
  

• 响应变化重于遵循计划
  

  敏捷方法的应用

  Scrum被认为是目前全球最流行与最有效的敏捷项目管理理念与方法之一

• scrum使我们能够专注如何在最短的时间内实现最有价值的部分
  

• scrum使得我们能够快速的经常的监督实际产品发展的情况（每两周或一个月）
  
• 团队按照商业价值的高低完成高优先级的产品功能，并自主管理，凝结了团队智慧创造出最好的方法因而提高效率
  
• 每隔两周或一个月，我们就可以实实在在的上线产品。此时，就可以下一步的决定是继续完善功能实现更多需求或直接发布
  

名词解析

• 功能点（WBS）：产品积压项
  
• 冲刺：两周内要干的活（需要完成的产品积压项）
  
• 冲刺会议：冲刺之前要开一个冲刺会议，固定需要做的事情
  
• 每日站立会议：15分钟分享昨天干了什么、今天要干什么、遇到了什么问题
  
• 验收会：迭代周期最后一天验收冲刺计划中安排完成的积压项
  
• 回顾会议：整体回顾冲刺期间遇到的问题
  

Scrum关键知识点

三个角色

产品负责人：Product Owner

• 编写用户故事：真正需要做的可交付成果
  

用户故事三要素

  1. 角色<br />
  1. 活动<br />
  1. 商业价值<br />

用户故事的原则

  1. 独立性<br />
  1. 可协商性<br />
  1. 有价值<br />
  1. 可以估算性<br />
  1. 短小<br />
  1. 可测试性<br />

• 排出优先级
  

• 放入产品BackLog（产品订单）
  

  Scrum主管：Scrum Master

• 保证团队资源合理利用
  

• 保证各个角色职责良好协作
  
• 解决开发团队中的障碍
  

• 作为团队和团队成员外部接口，协调解决沟通中存在的问题
  

  敏捷团队（开发、测试）：Scrum Tearm

• 执行Sprint
  

• 梳理产品Backlog
  
• 做Sprint计划
  
• 每天跟进工作进展，并对他们的工作检查和调整
  
• 每个迭代对铲平和团队成员的工作过程做检查和调整
  

Scrum三个工件

五个事件

• 冲刺计划会议
  
• 每日站立会议
  
• 冲刺评审会议
  
• 冲刺回顾会议
  
• 冲刺
  

五个价值

• 承诺
  

愿意对目标做出承诺

• 专注
  

把你的心思和能力用到你承诺的工作上去

• 开放
  

Scrum把项目的一切开放给每个人查看

• 尊重
  

每个人都有他独特的背景和经验

• 勇气
  

有勇气做出承诺，履行承诺，接受别人的尊重

Scrum四大支柱

• 迭代开发
  
• 增量交付
  
• 自组织团队
  
• 高优先级的需求驱动
  

Scrum流程

1. 制定产品订单，订单是软件产品的一个需求列表
   
2. 将整个产品订单分解成冲刺订单，这个冲刺订单是按照目前的人力物力条件可以完后的。冲刺代表一次迭代周期（通通常为30天），开发团队需要完成一个制定的冲刺订单，并且最终成果是一个增量的、可交付的产品
   
3. 召开冲刺会议，确定这个冲刺内需要完成的任务，标注任务的优先级并分配给每个成员
   
4. 进入冲刺开发周期，在这个周期内，每天需要召开冲刺站立会议
   
5. 整个冲刺周期结束，召开冲刺总结会，将成果展示给产品所有者
   
6. 团队成员最后召开冲刺回顾会议，总结问题和经验
   
7. 这样周而复始，按照同样的步骤进行下一次冲刺
   

产品订单

• 产品订单（Product backlog）是整个项目的概要文档
  
• 包括所有所需特性的粗略描述
  
• 关于将要创建的什么产品的描述
  
• 产品订单开放并且每个人都可以进行编辑
  
• 产品订单包括初略估算，通常以天为单位
  

产品订单初始化

• Product Owner和其他项目干系人根据业务需求，创建具体的产品订单
  
• 制定并提供产品订单的优先级
  
• 项目团队开始进行初始预估
  

敏捷估算

• 这个需求什么时候可以完成（个人估算）
  
• 团队集体估算
  
• 进行相对估算，估算工作量大小
  
• 记录每个Sprint的团队
  

冲刺订单

• 冲刺订单（Sprint backlog）是细化文档，包含团队如何实现下一个冲刺的需求信息
  
• 任务被分解为以小时为单位， 没有任务可以超过16小时
  
• 冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务
  

每日站立会议

• 每一天都需要举行项目状态会议，一般只有15分钟
  
• 会议准时开始。对于迟到者团队常常会制定惩罚措施
  
• 不论团队规模大小，会议被限制在15分钟
  
• 所有出席者都应站立
  
• 在固定地点和每天的同一时间举行
  
• 每个团队需要回答三个问题
  
  1. 今天完成了哪些工作
     
  2. 明天打算完成什么
     
  3. 完成目标存在什么障碍
     

冲刺评审会

• 贯穿整个迭代的全过程
  
• 针对所有有需要增加和调整过程的产品功能点进行评审
  
• 参会人员包括全体敏捷迭代团队和产品负责人邀请相关产品关键人
  
• 产品负责人陈述所有完成的产品功能列表和没有完成的部分
  
• 开发团队展示已经完部分的工作
  

任务看板

燃尽图

敏捷方法理解注意点

• 敏捷方法只有运用得当才有效果
  
• 敏捷是有严格要求的，也是面向质量的
  
• 根据沟通的需求产生相应的文档
  
• 基本的开发方法于传统相比较有明显不同，影响项目的各个方面
  
• 敏捷项目需要经常制定计划，但不需要试图超前制定项目计划
  
• 变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更
  
• 在中大型项目中一样取得了成功