1. 敏捷力介绍
1. 瀑布方法
瀑布模型并不现实，不可能会有完美化的产品设计，后面开发总会有意料之外的状况以及并发症。但作为反面例子的瀑布模型却收到听众的吹捧，变得广为人知。
瀑布方法的包含的流程有需求收集、设计、编码和测试，每一步骤都需要等前一步骤结束后才能使用，其坚持的哲学BDUF(Big Design Up Front)意味着在投入生产前就能够完美化产品设计，即早点捕获错误和缺陷是可行的。这受到很多新手以及非软件领域专业人员的追捧。
但是软件产品系统是复杂系统而不是简单的流水线产品。在开发过程中，前期设计的意料之外的状况和并发症总是会涌现出来
2. 加入敏捷实践者行列
瀑布这样的开发流程只会导致整个项目的失败，BDUF并不能充分的收集需求，它自认为对未来了如指掌，但大型软件项目中唯一确定的只有变化。
一个迭代式方法论才是未来，敏捷运动中的敏捷团队提倡迭代式的需求收集、设计、编码、测试和交付。周而复始直到完工。这雪要团队、产品负责人和客户通过持续不断地沟通来达到。
无论如何敏捷开发，都需要：
- 边做边测试：后期的修复成本非线性的增加
- 及早且频繁地交付产品，只有通过可工作的软件才能发现客户真正需要什么
- 文档边做边写：文档工作融入流程，但是只写有用的文档
- 构建跨职能团队，不让任何个人或者部门成为瓶颈。
敏捷方式的核心都是迅速交付商业价值。
status
3. 敏捷价值观与原则
敏捷思想是灵活并且强大的，没有规则手册，只有价值观和原则
- 个体和互动高于流程和工具
流程和工具必须是为人服务的，敏捷流程有非常多可以选择敏捷工具、方法论和流程，要让每一个自组织团队都选择最适合他们的工具。
- 工作的软件高于详尽的文档
文档应该着眼于创造价值以及推动项目进展，但是在前期对于文档太过于投入，就会错失后期检验和适应的良机。因为没有文档的话，还有可工作软件，也可以尽可能有效且高效地前进。
- 客户合作高于合同谈判
开发团队和客户之间需要保证公开和顺畅的对话，在流程中客户的持续参与能够降低客户风险，频繁交付让用户看到样子，保障了客户可以实现所投入时间和金钱的最大化。
- 响应变化高于遵循计划
变化是不可避免的，也是理所当然的，流程就是为变化准备的，所以团队需要为变化做计划。软件项目的规划必须是流动的而非固定的。
敏捷力的商业案例
越早交付，越早盈亏平衡，越早带来收益才是王道
2. Scrum
5. Scrum历史简述
Scrum是非软件项目也可使用的工作管理和团队动力学。Scrum描述了一种以团队为单位通过来回传球的方式向前推进的流程，希望团队表现起来就像一个人。
方法的成功取决于检验和适应，而不在于预定义，因为软件项目过于复杂和混乱，无法预定义来进行管理。
而Scrum经过多年的发展，成长是大家共同贡献的结果，Scrum是一个自由的过程。
6. Scrum角色
产品负责人：
- 负责沟通，帮公司获得最高投资回报
- 是唯一有权力要求团队做事，并且改变列表优先级的人
- 代表业务和客户，并不需要负责开发，需要确保团队了解客户和用户的需要
- 作为产品愿景的监护人，在产品为谁而建，产品为何需要，如何使用等方面都必须得做出决策
- 需要解答团队成员们的问题
Scrum Master
- 担当教练角色，帮助团队理解和使用Scrum
- 交付物是自组织的团队，帮助团队解决Scrum中的各种障碍
- 需要发展出一种和团队亲密接触的关系，成为引导者和谏言者
团队成员
- 决定了工作应该如何完成
- 要完成的不是个人的工作，而是团队的工作，帮助团队交付在当前sprint承诺的故事
- 为了最大化团队生产力，在团队需要的时候，需要选择舒适区之外的工作，带来全局最优解
7. Sprint周期
需要确保sprint周期结束时候需要有可交付的软件。sprint周期的设计就是提供了多方可以接受反馈的机会，当前sprint的收获能够在下一个sprint中生效。
- 规划会议：找出有信心在sprint结束时交付的用户故事，并决定如何完成，即估值
- 站立会议：每天短期的会议，目的是保持交流
- 故事时间：保证列表顶部有一批被充分理解的故事，
- 演示会议：当作取得成就的庆祝会，如果没有可演示工作也需要进行，因为要保证透明性。给了调整产品和学习的机会。
- 回顾会议：帮助团队持续检验和设计，找出可以改进的实事而不是抱怨，找到单个改进点病立刻采取行动。
8. Scrum工件
产品列表，在整个交付周期中，作为产品预期交付物的累积清单，不断改变，没有完成之日。顶部永远是那些小而完善的条目，按照优先级精确排序，只有产品负责人可以决定，并且有多重呈现形式。
sprint列表，当前sprint的任务清单，在规划会议中产生后就不再修改，除非团队成员提出变更请求。
信息辐射器，让所有人都能看见，持续持有最新信息。
燃尽图，剩余工作随时间变化的轨迹，包括发布燃尽图和sprint燃尽图
任务板，TODO、DOGING、DONE的转变带来成就感，有多重形式
完成的定义，归为开发团队所有，也就是必须做完的任务
9. 用户故事
关注人们需要使用软件完成的事，需要指明谁、想要什么以及为什么。
10. 用故事大小值估计工作
生成估值的目标就是提供进度的可预测性度量，如果对进度可预测，就能够做出重要的业务决策，创造更多价值。
对于开发人员来说，他们并不知道真正要花多少时间，但是不管怎样他们都会给一个答案。但如果是用相对大小，就能够看见预期的进度。
可以先给所有工作项都分配相对大小，然后完成几个工作项度量实际话费的时长，得到实测数据后，给其他条目的设置估算。
估算大小的时候，对于复杂的故事，我们无法在感知他们的细微差别，所以可以使用斐波那契数列来作为故事的相对大小。
利用整个团队来一轮一轮的把故事从左到右排列整齐，直到全部通过，然后把斐波那契数列贴到故事上。最终目的是达成群体共识，从离散的估值迅速聚集为统一的估值。
3. 辅助性实践
11. 除了scrum
交给团队决定
12. 发布规划
如果要发布某个特性集，那么一定要在确保发布更好的产品的基础上选择发布日期。
如果要在固定的发布日期发布，一定要明确在那之前能够完成并发布的内容，不要错过。
如果能在固定的日期交付固定范围的内容，很难。
13. 用户角色人物
基于真实行为开发一些用户角色人物，完成用户故事。挑选首要角色人物，必须先满足这个人的需求才能满足其他的需求，如果设计产品的时候首先不要满足所有人，而是满足首要角色人物，可能一开始就能创造更多价值。
14. 绘制故事地图
作为一种组织用户故事的方式，产品列表是一维的，只由用户故事的优先级衡量，故事地图是二维的，不仅有故事的优先级，也有彼此的关系和用户更高层的目标。
)
更重要的先发布。
15. 纸上原型
最好用，最通用的还是纸张，笔以及固体浇水。
16. 项目微章程
明确记载了项目关键信息的概要文档，是捕捉想法的一种方式，微小但是设计多个话题，是有用的总结，能够快速了解项目。
17. 重构
BDUF创建的架构到后期会让人感到不安和拘谨，敏捷就是一小步一小步来，只构建当前需要的架构，然后根据需要不断发展，把设计工作内置倒开发流程中。
18. 测试驱动开发
红色-绿色-重构，先开启一个引发失败的测试，然后根据测试变成，满足测试所有功能后再后退一步，检查代码的架构和设计，选择是否重构。
这样能让开发人员集中注意力到代码展现的外部行为。
)
19. 结对编程
减少缺陷、增强可维护性以及分享代码相关知识，都能够实现更快速的开发。因为对机会所有项目而言，后期改变代码的所用时间都超过了创建代码的时间。