约束理论

什么是约束

• XP是一个价值观、原则和实践的统一体，它着眼于解决软件开发问题。我们需要一种方法将软件开发作为一个整体来看待。一种考虑整个系统吞吐量的方法是约束理论。
• 约束理论认为，任何系统在某一时间只存在一个约束。要提高系统的整体吞吐率，那么必须首先找出那个约束，并确保它能够全速工作，然后再寻找某些办法，或者增加约束的容量，来分流一部分工作到其他非约束部分，或者完全消除约束。
• 工作是根据实际的需求在系统中推进，而不是根据计划的要求。

约束的关注点

• 整体的吞吐率

怎么在系统中找到约束呢？

• 约束理论认为约束总是存在的，我们消除一个约束的同时也产生了另一个约束。微观的优化是永远都不够的，要改进我们的结果，我们必须在决定改变什么之前先观察整个形势。
• 鲜明特征：大量的工作在约束之处积累。

扩展思考

• 当前我的约束是什么
• 团队当前的约束是什么
• 人生的约束

计划：管理范围

计划是什么

• 计划是我们共同来做的一件事情，需要合作。计划是一个听、说以及将目标和特定时间段联系在一起的训练

为什么计划

• 计划可以使目标和方向清楚明确。
• 它能帮助你与其他团队间的协调同步。

怎么做

• 把当前的目的、假设和事实公布于众，利用当前明确的信息，你们可以就什么是范围之内的、什么是范围之外的，以及下一步该做什么达成共识。
• 团队中的每个人根据团队目标来作出决定。
• 对故事进行预估。

怎么让故事的预估更准确？

• 要评估一个故事，你便要通过你知道的关于相似故事的一切，想象出一个结对需要多少小时或多少天来完成这个故事。“完成”的意思是已经为部署做好准备，包括所有的测试、实现、重构和与用户的讨论。随着你对类似故事的知识增长，你的评估也会越来越准确。评估是基于与故事相伴的合理工作，有些评估也许会较好而另一些较差，但是如果每一个人轮流评估一次，最后我们将得到一个平均值。

计划不顺时

• 当事情进展不顺利的时候，就是我们最需坚持价值观和原则的时候，同时修改我们已有的实践去尽可能地保持效率。
• 不准确的评估是信息的错误，而不是价值观或者原则的错误。

尽早测试、经常测试、自动测试

• 见字知意
• 尽早测试：越早发现缺陷，所需的花费就越少。
• 经常测试：频繁测试将减少代价和缺陷
• 自动测试：XP测试的即时性也意味着测试必须是自动的。
• 在XP中，测试与编程同样重要。

设计：时间的价值

• 增量设计是早早交付功能，并且在项目声明周期中每周持续的交付功能。
• 设计的演进：
  1. 设计所有
  2. 什么也不设计
  3. 事先大量设计
  4. 事先少量设计
  5. 事先足够设计
• XP的策略是“始终设计”
• XP团队更喜欢尽可能简单的解决方案。评价设计简单性的标准：
  1. 适合于希望得到它的人们可。设计如何华丽优美并不重要，如果需要使用它工作的人不明白它，它对他们来说就不简单。
  2. 易交流。需要交流的所有思想都表现在系统中。就像单词表里的单词，系统的每个元素都要跟未来的读者沟通。
  3. 提取来共因子。逻辑或结构的重复使得代码难以理解和修改。
  4. 最小化。在以上三点限制下，系统应该具有尽可能稍的元素。元素越少就意味着需要的测试、归档和交流地越少。
• 当面对一个大问题时，采用三个步骤：
  1. 将问题转化为小问题。
  2. 应用简单的解决方案。
  3. 如果还有问题则应用复杂的解决方案
     总之，化繁为简，化大为小，化多为少，让大团队解决的问题，分解为小团队解决。分解复杂性，同时持续交付。
• 根据特性进行计划，要记得计划中的条目都应该是用户所关心的特性。