第一部分——价值的循环

开发取向

频繁交付小的，价值大，代价小的特性

因为软件需求难免会变。把开发进度切成小块，利于快速迭代。
下图每一个小矩形代表一个功能特性。其宽度代表需要付出的人力，高度代表带来的收益。原则就是尽量沿着绿色路径走。

测试

同时要有业务测试和开发测试

业务测试关注软件功能，是相对重型的测试；
开发测试注重软件底层实现

开发测试应在代码开发的同时完成甚至先于代码完成

代码开发过程中，更清楚当前开发的这些代码哪里最需要测试。所以开发测试要尽早做。
最好就是先写测试代码，再开发。这通常被称为测试驱动开发(test-driven devlepment, TDD)

开发测试不是浪费了人力。而是把后期发现问题并找问题的时间前置。并且通常在前期测试并修复问题，远比后期测试再修复问题更容易，花费时间更少。

重构

在软件开始开发时，拥有比较好的设计比较容易。但是在软件迭代过程中，设计退化是很难避免的事情。
因此，重构就是一项必备技能。“测试与重构结合在一起，使得增量式开发成为可能”

同时，业务测试和技术层面的测试，则是重构过程中软件特性及质量不受影响的保障。

第一部分总结

第二部分——说明与论述

团队

目的

产品推动人为团队提供目的，包括大方向和细节上的目的。并使得团队深入理解为什么要做这个事情。

自主

团队成员自主做决定，来判断如何解决问题，如何具体实现需求。自主可以带来创造力，以及更高的工作效率

专精

专精来自迭代过程。

五卡法预测软件计划

把项目整体分成3-5 个部分，然后将拆分的3-5个部分继续各自拆分成3-5 个部分。重复这一过程，直到拆分后的每一个小部分都能够在一周内完成。

控制好自己所参与项目的数量

“同时做太多事情，只会使所有事情的进展都变得缓慢”

提高团队的效率，提高个人的能力

提高团队的效率而不是个人的工作效率。

1. 团队有良好的技能组合
2. 关键技能团队成员必须是全职的
3. 专家指导来提高其他成员的能力

提高个人能力来提高个人的效率。单纯的压力只会使个人在交付时减少测试，减少代码的设计重构，降低交付的质量。这样短期内能交付，但是会埋下巨大隐患，从而延误整体进度。员工很难会自己利用闲暇时间提升自己，因此团队培训非常必要。

“速度最快的团队总是平稳、优雅地前进”

每几周就有一个可发布的，已完成的产品增量版本。这个版本经过了充分的测试。
这样的开发方式中，团队在每次迭代中承担的工作比以前要少（因为要有测试），但是交付质量会提升。从而在整体上提高了效率。

重构

重构应遵循“露营地原则”：在离开营地时，要让它变得比你来的时候更好。
重构时，不应停下所有功能开发进行重构，而是一边开发，一边清理代码。