第1部分 团队与自我改善基本功（1-2）

改善都应从团队开始，并要改善本来的工作习惯的不足，但改变工作习惯并不容易。首章用实例介绍公司团队如何从“破冰”到变革， 到稳定，以及成功要素。

团队的提升依赖于个人的成长与提升。敏捷开发假定每位成员都具备极高的经验与能力，如果团队成员都是刚毕业的新手，不建议使用敏捷开发。第2章后半部分介绍提升个人效率的方法。

1 关于改善的故事
2 改进从团队与自我开始

第2部分 自我管理开发过程（3-6）

如何估算工作量一直都是软件开发的挑战。大家都知道应分析历史项目数据，作为后面项目估算的参考。但首先要不同项目的数据可以相互比较。如能客观衡量项目规模大小，便可用规模作为分母把不同大小的项目归一，让不同大小的项目可比。本部分会讨论应使用什么来估算项目规模。

软件开发工程师自己收集数据并分析，是团队量化管理的基础。敏捷开发团队可以从个体软件过程(PSP)开始。 本部分也会简单介绍估算工作量、工程师如何收集数据并分析等的挑战与最佳实践。

估算本应是一个范围，不应单是一个数，会先用一个例子介绍三点估算法，并与模拟结果比较，衡量三点估算法的正确性，是否可用。

3 三点估算
4 量化管理从个人开始
5 估算软件规模
6 策划与监控

第3部分 开始过程改进之旅（7-8）

所有有效的改进，团队必须先获得管理层的关注与支持。

第7章先介绍如何以高层的“语言”分析改进对公司的价值，获取高层支持，投入资源，成立改进组，跟其他项目一样立项管理。

第8章继续用实例说明过程改进项目的主要成功要素，包括要做好根因分析。

7 获取高层支持
8 寻找改进机会

第4部分 如何做好迭代回顾（9-12）

怎样避免同类问题的重复发生？ 因为有很多问题背后的原因是整个系统的不足， 而不仅仅是个人不关注、不努力，做好根因分析可以帮助我们找出背后的根因。
怎样做好根因分析？二八原则、五个“为什么”（5Why）等，大家可能都听过。 在网上也可能找到相关的理论知识。但很多人还是有误解,没有弄清楚应该如何利用这些技巧来找出根因。
针对软件开发的过程改进，也可以使用根因分析，帮助软件开发团队避免问题的重复发生，以提升团队的质量和效率。
迭代回顾(Retrospective)可以让团队每走一小步（一个冲刺），便立马回顾过程中有哪些不足、分析根因，以便在下一小步中得到改善。
要做好迭代回顾，除了要了解根因分析的技巧，还要了解回顾背后的原则，配合团队互动练习，再配合工具做好数据分析，才能使团队有实际的提升，让老板满意。
这部分会讨论：

●  根因分析的主要元素

●  软件开发团队应针对哪方面入手，才能最容易取得效果

●  迭代回顾前应如何做好准备

●  内部教练引导团队做回顾时应注意什么

●  如何可延续,让团队（甚至组织级）开始建立标杆

9 二八原则
10 根因分析
11 软硬兼施
12 从团队实验到持续改善

第5部分 软件工程质量（13-19）

当团队已经开始每次迭代做回顾，分析缺陷与返工工作量，按二八原则识别改进的针对点后，还需要了解软件工程，包括需求、开发、集成等的常见问题，才能有效分析，并制定下轮的改进措施。

高层的理解与支持很关键，所以本部分会简单介绍软件工程的重点，让大众读者也能了解外，还会解读敏捷开发背后的重要思路、原理。

13 精益与敏捷
14 测试驱动开发与重构
15 评审与结对编程
16 持续集成
17 软件需求
18 协作改进整个系统
19 从AI到最佳设计

第6部分 度量与分析（20-23）

有些人有“数学恐惧症”，一听到概率与统计学便退避三舍，这几年机器学习、数据挖掘等技术快速发展，例如，客户不需要再查统计数据表，或写软件程序分析数据；只要挑选模型，系统便能自动出分析结果。 但千万不要误以为系统能自动分析数据，要做好分析还是非常依赖有经验的人。只是有了更先进的工具，有更多模型的选择。

本部分会先介绍描述或图示化展示各类数据的技巧，再利用实例介绍一些假设检验的分析技巧，然后以问卷调查为例，介绍度量计划的主要元素。

当团队开始养成每天收集数据的习惯，在迭代回顾时分析数据并保留记录，达到一定数量后，便可以开始基于数据建立标杆（基线）与预测模型。

20 取消量化目标
21 教小孩统计分析
22 做问卷调查
23 预测模型

第7部分 从改善到创新（24-26）

前面的迭代根因分析只归属于问题解决，不算是创新，这部分会先回顾和分析个人和企业的创新案例，探索创新的要素。

25章探索如何能持续学习，保持个人的创新能力。

最后26章会利用实例回顾人类从20世纪至今的创新，探索如何继承前人的根与翼。

24 创新：从个人到公司
25 北京手记
26 根与翼