整理如下:
第3章 根据功能特性可以指导得更好
根据功能特性交付项目能够提供更好的信息和指导，同时也会产生更好的结果。当以逐个实现功能特性的方式构建软件时，情况会好很多。我们能够看到任务完成了多少，也会知道项目进展的速度有多快。这样，我们就能够很好地预测在任意一个给定的日期到来前有多少任务是可以完成的。
第4章 根据功能特性组织团队
功能特性团队对于你来说可能是一种改变。但如果你想要项目能够迅速、顺利地进行，朝着这个方向去转变，很有可能会受益匪浅。慢慢来，别急，尽管去尝试。组建一个相当不错的功能特性团队，看看更少的交接次数是否能够在加快交付速度的同时提高交付的质量。
第5章 根据功能特性进行计划
一是确定项目的时间期限和开支预算； 二是优先开发那些最优价值的功能特性； 三是确保产品能够随时发布，并在时间结束时立即停止。 开发工作甚至很有可能会在截止日期之前停止，因为我们已经得到了最重要的功能特性。这样就能够在更短的时间内，以更少的花费交付大量价值。
-
持续计划：分解功能特性。只在项目的起始阶段做计划还远远不够。因为我们关注的是价值，所以需要一直做计划。 团队应该以固定的节奏工作，这样的工作周期通常被称为迭代（iteration）或冲刺（sprint），其长度一般为几周。每个功能特性（通常被称为故事）最好都只需要两天或者三天的时间就能够完成。 我并不推荐将故事划分得很大，然后再将其拆分成技术性条目（通常被称为任务）。如果采用任务的方式进行迭代，一方面会导致业务人员不能清楚地了解项目的进展程度，另一方面也会使得他们在为期两周的迭代期间不知道如何提供帮助。 因此，我建议坚持采用故事的方式，这样工作才能更好地进行。
-
根据“挑战性的目标”制订计划，危害性很大。
为了能够在计划的时间内多完成一个功能特性，他们会遗漏一些测试，并且所写出的代码也不像以往那样清晰整洁。
赶工将会给整个项目带来更多的缺陷。与防止缺陷发生相比，修复缺陷则需要花费更长的时间，因此赶工不但不会加快项目的进度，反而会影响进度。更糟糕的是，当项目接近尾声，越是在你不希望进度延迟的时候，它越会影响进度。
- 做计划，确定下一步要做的事情，不要吃太多。 随着项目的进行，每隔几周就做一次计划，通过计划来决定接下来要做的最重要的事情，同时团队也会明确他们要承担的任务。首先选择那些最有价值的想法——这也是使价值以最快的速度增长的方法。
第6章 根据功能特性构建产品
细化产品愿景。在根据功能特性构建产品时，每隔几周我们都会要求开发团队构建出新的功能特性。我们希望看见所构建出的是我们真正想要的，而不是一些我们不懂的技术或者类似的东西。这就意味着业务人员必须要有能力将大的、模糊的、笼统的需求切分为小的、切实可行的开发步骤，这样才能够用尽量小的努力去获取最大的价值。
总是将价值可能最大的任务列为下一个目标。随着经历的迭代越来越多，我们会越来越清楚迭代结束时能够完成多少任务量。优先完成那些最有价值的功能特性，这一点至关重要。整个团队一起合作，共同确定有能力完成且价值高、成本低的功能特性。这样一来，团队就学会了怎样在有限的时间和预算内构建最好的产品。
随着项目的进展，我们需要学习区分表面的进展与真实的进展。我们会逐渐理解，在特定的环境下什么样的“完成”才是真正的完成。
第7章 同时构建功能特性与基础
阐述的指导原则，我们将采用增量的方式逐步构建产品的功能特性，优先构建最有价值的功能特性，而价值最低的则放到最后。为了确保各个功能特性都能够顺利地完成，从项目开始到结束，都必须保证系统的设计坚实可靠。
首先构建简单而实用的版本。
如果对于每个必需的功能特性，我们都能构建出小的版本，同时还为它们打下足够坚实的基础，那么我们就能够做到最好。
我们就能以最快的速度构建出最小可行产品（minimum viable product）。
在多次迭代中逐渐完善每个功能特性
每个新的小版本都会使整个产品更加完善，这样我们在每一个时间点都会拥有当时所能拥有的最好的产品。
第8章 零缺陷与良好的设计
找出缺陷将花费很多时间，修复这些缺陷同样也要花费时间。如果将这些工作留到项目快结束时处理，那么开发新功能特性的计划就会被打断，同时我们还必须决定暂不修复哪些缺陷。
目前已知的最好方法，就是表述功能特性必须通过哪些测试，并且使这些测试工作自动化，以确保该功能特性不仅现在可用，而且以后一直可用。这就是人们常说的验收测试驱动开发（acceptance test-driven development，ATDD）。
已知的最好方法就是先写测试代码，然后再运行这些代码。这通常被称为测试驱动开发（test-driven development，TDD）。它最大的优点在于支持对设计的改进
测试不但没有减慢开发速度，反而使其变得更快！这是因为测试可以使我们犯更少的错误，同时使错误更快地被发现。与从一开始就避免问题产生相比，找出并解决问题所需的时间会更长。
在构建功能特性的每个阶段，为了保证设计对功能特性的支持，项目团队必须对设计进行足够的改进。
在改变设计的同时保持其良好状态，这通常被称为重构（refactoring）。在进行增量式软件开发时，重构是一项必备技能。
测试与重构结合在一起，使得增量式开发成为可能。软件开发工作的本质要求我们进行测试和重构。
开发就是一种随时了解哪些功能特性可用的好方法。开发人员需要精确地知道问题出在何处，测试驱动开发则是达成这一目标的主要工具。强大的自动化测试套件让我们可以随时知道哪些功能特性可用，而两个层面的测试，即业务测试和开发人员测试，则能让这项工作完成得更好。项目若要进展，就必须持续改进其设计，而利用重构对设计进行改进和优化则是实现这一目标的方法。然而，即使是最好的重构也或多或少会产生一些错误。业务层面和技术层面的测试则使我们有足够的信心，来进行所需的设计改进与优化工作。 这就是目前我们所知道的能够保证产品质量良好、流程进展顺利、进度可以预见的最佳开发方法。 测试与重构是这种方法最重要的两种工具。请别忘记使用它们。
第9章 价值的完整循环
总结一下吧。
- （1）我们最终想要的是价值，提供价值的则是功能特性。功能特性发布得越早，我们就能越早提供价值。
- （2）基于价值的管理比基于时间或工件等不提供价值的事物更胜一筹。
- （3）根据功能特性做计划很简单，只有在必要时才进行估算。根据以往完成的工作量来安排下一阶段的工作，效果会更好。
- （4）采用逐渐增加功能特性的增量式开发方法，要求我们每隔几周就能够开发出小而完整的产品。所开发的产品必须总是能够正常运行，而且其设计也是良好的。
- （5）开发工作必须要交付真正可用的功能特性。产品必须经过严格的测试，业务人员和开发人员都需要参与其中。同时，产品还必须拥有良好的设计，而且开发人员需要保持产品的设计一直处于良好状态。
第10章 价值是什么
选择价值，就是选择那些对我们重要的东西。所谓价值，就是那些我们想要的东西。
第11章 如何衡量价值
能够有一个简单的答案，像功能点的数量，或者用户点击次数等。如果你发现这些数值有用，不妨继续使用。不过，需要明白的是，所有这些衡量指标的真正作用是帮助产品推动人、项目干系人，以及团队成员理解什么是真正的价值。相反，更好的做法是与开发人员和项目干系人坐在一起，考虑要做的事情。将所有人都认为最有价值的事情作为接下去要做的事情。这样做的真正意义在于学习怎样达成共识。接着，实现选定的功能特性，并尽快交付，然后倾听用户的意见，再重复上述过程。
第14章 组建强大的团队
产品推动人为团队提供目的（不仅有大方向上的，而且还包括细节上的），并且保持每天都与团队接触，以确保团队理解为什么存在这样艰难的任务、最重要的问题有哪些，以及产品怎样能够最好地解决这些问题。产品推动人会将疑虑或者问题告诉团队，并让整个团队一起努力解决问题。
当团队能够自发地工作时，就会更加自主，同时也能激发更多的创造力去解决问题，工作效率因此也会更高。
每一次迭代都是“完成”软件的一次实践。它以开发出真正能够运行的软件为目标，同时能够使大家都看到软件的质量如何，也有助于大家思考怎样使软件更好。同样，每一次迭代都是朝着专精迈进的过程。
第17章 监督员工更加努力地工作
如果一定要更快一些，分析导致延迟的各种原因。这通常要比提高个人的工作效率更有作用。首先，我们优先要提高的是团队的工作效率，而不是个人的工作效率。既要确保每个团队都有很好的技能组合，还要保证团队有完成工作所需的全部技能。那些具备关键技能的团队成员必须是全职的，不能同时参与多个项目。 此外，还需要通过专家的指导来提高其他成员的能力。尽可能让所有的团队成员都在一起工作。其次，通过提高个人能力来提高个人的工作效率，而不是依靠督促他们更加努力地工作。“更精明地工作，而不是更努力地工作”，这意味着我们要帮助员工变得更精明。
第19章 重构
构建一个功能特性所需要的时间大致来自以下两个主要方面： 一个是它本身固有的难度，另外一个则是将它加入现有代码时可能的难度。对于功能特性固有的构建难度，开发团队一般会估计得比较准确。因此，使开发速度变得不确定或者慢下来的就是将功能特性加入现有代码时可能的难度。我们称这一难度为“劣质代码”。
遵循露营地规则（Campground Rule）似乎是最好的选择：在离开露营地时，要让它比你来的时候更好。每次要构建一个功能特性时，我们都先去清理那些将要用到的代码。并不需要让这些代码变得完美，只要能使我们比较容易地加入新的功能特性就足够了。这样，一旦功能特性可用，我们就清理应该清理的代码，外加一点相关的代码。
第20章 敏捷方法
最重要的一点：思考。构建有价值的产品是很复杂的工作。要做好这件事，并不能依靠参与并控制一切，而是要依靠观察所发生的事情并随时作出反应。 这有点像团队比赛：可能会有一些方案，甚至还可能有一些预先计划的行动；然而，比赛时所发生的情况总是会与预计的不同，而胜利则取决于团队成员的现场配合能力。矛盾的是，这样的能力其实来自于采取行动之前所做的思考。再重复一遍，思考！
第21章 大规模敏捷
如果你的所有开发团队都能够熟练地划分功能特性，正确地选出他们能够在一次冲刺中（或者是在估算的时间内）完成的功能特性数，还能够按时交付没有缺陷的已集成软件，那么大规模敏捷同样应该很简单。
来自京东读书
导出日期：2022-03-20
