基于统一迭代节奏的全功能团队
团队的精进之道
团队的精进之道就是把交付过程中的一切活动看作能力建设，把整个团队构造成促进每个成员成长的生态系统。
当我们在领导一个团队的时候，我们总是想如何做好任务分配，平衡团队战能力，交付最好的结果。于是我们在分工的时候，就会根据员工所擅长的部分，因材分工，那随着项目的进展，人员的流动等等情况的发生，项目在后期就会愈发的变得困难。
那针对上面的这个情况，我们能够做出哪些调整呢？
作者在文中举了这样一个例子：在某次项目中，项目经理会问清楚每个人擅长的部分，在分配的时候，会去让每个人做自己不擅长的部分，如果不会那么就需要 去求助擅长的人帮忙。
这种方式和方法可能在项目初期看不到效果，甚至会拖慢进度，但是在这个过程中会发展团队成员的个人能力，在一个较长的时期里平均来看，其实我们就是在以最快的速度交付结果。
这里的第二种方式就应了敏捷宣言中的那句话：个体与交互 高于 流程和工具
基于用户故事的需求及范围实时管理
估算的目的
- 资源分配：
- 对协调的帮助：
- 做决策
- 估算会议上促进团队成员的彼此交流
估算本身并无好坏，如果你不用估算也可以很好的工作，那么你就不用。如果你需要通过估算来帮你做一些决策，并且估算会影响到重大的决定，那么尽可能做出好的估算。针对你特定的上下文，决定你采用什么样的方法。
需求风险的坏味道和对策
当项目进入交付落地阶段，项目负责人就应该进入“风险模式”；而“控制需求”就成为了控制风险中最重要的一环；如何来控制风险呢？
- 尽可能的靠近决策者
- 做系统决策人
- 不要给选择
- 管理结果而非解决方案
- 建立游戏规则
软件项目规模估计，怎么估？
在规模估算的时候会有下面几个问题：
- 估计者估算的点数是否能代表团队估算的点数？
- 是否有故事卡片之外的工作时间没有考虑到？
- 故事卡的需求是否清晰呢？
如何来解决这些问题呢？
- 进行集体估算：
集体估算可以缓解个人能力不同引发的单点偏差，不同开发人员对需求的阐述，也会让大家对需求有更全面的理解，也易于发现潜藏在需求中的风险。 - 其次是方法：还有两个方法大家可以参考：
- 理想人天法
- 故事点法
- 最后还要给项目加缓冲：
- 功能缓冲
估完点后，挑出其中必须要做的70%以内的任务，剩下的30%作为可做可不做的任务，通过这种方式来缓冲项目里程碑的风险。 - 进度缓冲
用来缓冲估计之外的异常情况引发的项目时间的拉长。
- 功能缓冲
