每周交付，持续交付，天下武功，唯快不破
更新历史
- 2022.07.16：完成初稿
读后感
这算是第二次阅读这本书了，第一次读的时候因为基本都是自己一个人开发，所以不懂；第二次读，已经比较少参与到实际的开发过程中，但反而有了更多的思考，这就是读书的轮回。
读书笔记
敏捷简介
- 每周交付一些有价值的东西
- 可工作的软件是衡量项目成功的主要度量指标
- 三条简单准则
- 在项目的初期不可能收集到所有的需求 -> 不要等万事俱备，先干起来
- 不管你收到什么需求，最终他们肯定都会发生变化 -> 拥抱变化
- 总会有任务超时、超支 -> 设置优先级
结识敏捷团队
- 敏捷团队的分析、编码、设计和测试是一串连续性的活动，从来不会停止
- 业务人员和开发者在项目的整个过程中每天都要协同工作
- 最好的架构、需求和设计都来源于自组织的团队
- 要善于激励项目人员。为他们提供所需要的环境和支持，并且相信他们能完成工作。
敏捷项目开端
- 将项目的目标、愿景和背景传达给团队成员，使其在执行过程中做出明智的决策
- 向利益相关者提供信息，以帮助他们决策项目是否应该继续
- 提前提出所有的尖锐问题
- 交付启动计划
- 为什么会进行这个项目？客户是谁？为什么首先考虑这个项目
- 做一个电梯演讲：30秒和两句话来描述项目
- 创建一个否定清单：不应做什么也同样重要
- 估算项目的规模：周期多长
- 谁是我们的邻居：这个项目会影响谁，谁更可能和我们一起
纵览全局
电梯演讲模板
- 对于【目标客户】来说
- 他们有这样的【需求或机会】
- 我们的【产品名称】
- 是一种【产品类别】的产品
- 我们产品的【主要优势，令人信服的购买原因】
- 其不同于【主要的竞争产品】
- 在于我们的产品有如下【主要区别】
收集用户故事
- 无论是团队内还是团队间，传递信息最有效的方法就是面对面的交流
- 优秀的用户故事第一要素就是它要对客户有价值，客户愿意出钱的东西就是有价值
- 第二个要素就是有始有终，贯穿所有层面
敏捷计划
- 拥抱变化，即使再项目开发后期。要善于利用需求变化，帮助客户获得竞争优势
- 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术
创建敏捷沟通计划
- 任何敏捷项目都要做两件事：设置期望值、获取反馈
- 迭代必备四项工作
- 故事计划会议：确保下一迭代工作准备就绪
- 展示活动：从上一迭代故事中得到反馈
- 迭代会议计划：制定下一迭代的工作安排
- 小型回顾：不断找出需要改进的部分
创建可视化工作区
- 故事墙
- 发布墙
- 速率表+燃尽图
- 交付启动计划
单元测试
- 在修复 bug 前，编写单元测试
- 证明你理解了 bug 的本质
- 相信你已将其修复
- 确保 bug 不会再返回到程序中去
- 测试任何可能出错的地方
重构
- 偿还技术债务
- 对技术的精益求精以及对设计的不断完善将提升敏捷性