1. 敏捷的历史

• 敏捷的雏形：选择小的目标，并在每个目标之后确认进展；
• 瀑布初始模型

• 这张图看起来非常像水从层层叠叠的岩石流下来，因此这项技术被称为“瀑布”；
• 从逻辑上，瀑布沿袭了科学管理；
• 它所要做的就是首先做彻底的分析，然后制定详细的计划，最后执行该计划直至完成；

2. 敏捷中心思想

• 个体和互动高于流程和工具；
• 可工作的软件高于详尽的文档；
• 客户合作高于合同谈判；
• 响应变化高于遵循计划；

3. 敏捷全貌

• 敏捷是一个框架，他可以帮助开发人员和管理人员进行务实的项目管理；
• 这种管理不是自动的，并且依赖于管理人员做出的决定；
• 并且在敏捷框架内，也完全有可能错误的管理项目并将其推向失败；

3.1 铁十字

• 质量；
• 速度；
• 成本；
• 完成；

3.2 墙上的图

• 敏捷能够提供数据，供管理人员做出正确决策；

• 敏捷关键的目标，是两张可以为管理者提供所需数据的图：

• 团队的速率；

• 速率图可以一目了然的看出一个团队的平均速率，并且预估其下周完成的故事点数；

• 燃尽图；

• 燃尽图显示了下一个主要里程碑之前还剩余多少故事点；

• 有时候会发现燃尽图中的下降幅度小于速率图中的故事点数，是因为在开发过程中会不断发现新需求和新问题。

• 敏捷开发首先是一种反馈驱动的方法；通过查看前一周，前一天，前一小时，前一分钟的结果，进行适当的调整，来驱动每周、每小时甚至每分钟的行动；
• 适用于单个程序员，也适用于整个团队的管理；

3.3 需要知道的第一件事

• 在了解项目名称或任何需求之前，会有一个数据优先于其他数据出现，就是交付日期；
• 交付日期的谈判是没有任何意义的，因为交付日期的选择是处于重要的商业理由，没有任何开发理由而去改变；
• 需求是千变万化的，因为客户永远都不知道他们想要什么，他们知道要解决什么问题，但是将其翻译成系统需求绝非易事；因此，需要不断的评估、思考需求、修改特性；
• 总的来说，就是日期被冻结，但需求却不断在变化。

3.4 分析、设计、实施阶段

• 分析和设计不是二进制交付物，它们没有明确的完成标准；如果时间到了，就可以宣布完成；
• 实施确是要实打实的进行交付。

3.5 敏捷项目

• 瀑布方式解决问题：

• 首先分析问题；

• 然后设计解决方案；

• 接着按照设计实现；

• 至于为什么是错的，在我的理解中，因为需求在不断的变更；

• 敏捷项目起始于分析，但分析永远不会结束；

• 下图代表了整个项目；

• 右边代表着结束日期；（最先知道的事情）

• 将整个项目的时间切分为若干个固定长度的时间周期，这些周期被称作迭代或者 Sprint；

• Sprint(短距离冲刺)；

• 迭代的周期通常为一到两个周；作者更倾向一个周，其实工作后，我也觉得一个周更好，拖得时间太长，会导致中间出现一些不可控的问题；

• 探索的横条贯穿整个项目是因为，编写故事，并对其进行估算，做计划，做设计的过程是持续不断的；

3.6 迭代 0

• 第一次迭代（迭代 0）用来创建简短的功能特性列表，这些功能特性称为故事（story）；
• 迭代 0，还用于设置开发环境、估算故事并制定初始计划 – 这份计划只是暂时的将故事分配给前几次迭代；
• 最后，开发人员和架构师在迭代 0 中根据暂定的故事清单来构思系统的暂定初始设计。

3.7 敏捷并不是一系列的小瀑布

• 敏捷的每个迭代并非分为 3 段；
• 分析不仅仅是在迭代开始时进行；
• 实现也不仅仅是在迭代最后阶段进行；
• 需求分析、结构、设计和实现持续贯穿整个迭代过程中；

3.8 迭代 1

• 估计这个迭代中完成的故事数；
• 迭代 1 开发结束后，会提供首次度量，让我们了解了一个迭代可以完成的任务，这是真实数据；
• 假设每个迭代都是相似的，则可以根据该数据来调整整个原始计划，并重新计算项目的结束日期；
• 这一次的计算有很大可能超出项目原定的结束日期，但因为这个估算是基于真实数据，所以不应该被忽视；
• 但因为数据单一，所以也不能太重视；
• 为了缩小误差，应该再进行两到三个迭代，来获取平均数据；
• 基本上四五次迭代后就可以更好的判定何时能完成项目；

3.9 敏捷的实质

• 敏捷不意味着要快，它从来就无关快慢；
• 敏捷是用来帮助我们了解目前进度有多糟糕，尽快的了解困难；

3.10 管理铁十字

• 管理者得到项目产生的数据，项目的管理者们就要确定该项目在铁十字方面的取舍程度了；
• 管理者通过变更范围、时间表、人员和质量来调整铁十字；
• 改变时间表；
• 增加人手；（成本很高，新员工学习期间会降低生产率）
• 牺牲质量；
• 调整范围；（要么裁掉功能，要么推迟时间）；

3.11 业务价值排序

• 每个迭代初始，应询问利益相关者接下来要实现哪些功能；
• 然后按照利益相关者的要求顺序来实现功能；

4. 生命置换

• 描述极限编程实践的一张图，被称为生命之环；

• 所有的敏捷过程都是极限编程的子集或变体；
• 由上图可得生命之环由 3 个圈组成；

4.1 外圈 – 面向业务的实践

• 这些实践为软件开发团队与业务沟通的方式以及业务和开发团队管理项目的原则提供了框架；

• 计划游戏（Planning Games）： 实践是这个圈的核心；

• 它告诉我们如何将项目分解为特性、故事和任务；

• 它认为这些特性、故事和任务的评估、优先级和排期提供了指引；

• 小步发布（Small Releases）： 指导团队以小块的方式开展工作；

• 验收测试（Acceptance Tests）： 为特性、故事和任务提供“完成”的定义；

• 它向团队展示了如何制定明确的完成标准；

• 完整团队（Whole Team）：

• 软件开发团队由许多不同的智能人员组成，包括程序员、测试人员和管理人员，他们都朝着一个目标一起工作；

4.2 中级圈 – 面向团队的实践

• 这些实践提供了开发团队在团队内进行沟通和管理的框架和原则；

• 可持续集成（Sustainable Pace）： 可以防止开发团队在完成任务之前过快的消耗资源和精力；

• 代码集体所有（Collective Ownership）： 确保团队不会将项目分割成一堆知识孤岛；

• 持续集成（Continuous Integration）： 使团队专注于频繁地进行反馈闭环，以随时了解他们目前的进展；

• 隐喻（Metaphor）： 创造并传播关于待开发系统的词汇和语言，以便团队和业务部门进行交流使用；

4.3 内圈 – 面向程序员

• 这些实践用于指导和约束程序员，来确保得到最高的技术质量；

• 结对（Pairing）： 实践使技术团队及时分享知识、及时审查和实时协作，推动团队不断创新并保持准确性；

• 简单设计（Simple Design）： 指导团队避免精力浪费的实践；

• 重构（Refactoring）： 鼓励对所有工作进行持续的改进和完善；

• 测试驱动开发（Test Driven Development）： 技术团队在快速推进的同时得以保持最高质量的安全绳；