实施极限编程会遇到的7个问题
在实施极限编程的过程中，可能会遇到一些问题，下面我们列出几个并进行解答。
这些问题包括：
- 如何进行准确的估算？
- 如何计划系统架构？
- 发布日期可以改变吗？
- 如何更好的协调bug和功能间的时间分配？
- 如何扩张一个10人的团队到40人？
- 如何将XP写入商业合同？
- 每个XP都一样吗？
如何进行准确的估算？
估算充其量只是一种技巧。无论付出多大的努力，都无法获得精确的数字。
估算单位并不重要，唯一重要的事情是始终使用同一单位。
估算要团队一起做，如果存在分歧，可以遵循“乐观主义获胜”原则，使用最短的估算时间。
记住，估算不是承诺，几次错误的估算并不会成为灾难。目的是不断提高估算的能力。
随着估算频率的增加，每个人都会估算更准确
如何计划系统架构？
有些架构需要几个月的时间去设置，而不包含客户的功能。这种风格是已经失败或者即将失败的项目的常见特征。
不包含客户的功能有以下风险：
- 花费大量时间却没有交付对客户有用的东西，会导致与客户之间的关系紧张
- 试图使系统架构包含你认为可能需要的每个方面，导致系统架构过于复杂
正确的做法是：
- 生成功能时，就改进系统架构
- 每次迭代，只为改迭代中的故事生成足够的系统架构
- 不要生成比你所需要的更为复杂的系统架构
发布日期可以改变吗？
XP最重要的法则之一就是：日期是硬性规定的，不要改变发布日期。而范围可以变化。
不要改变日期，有两个原因：
- 延迟太多容易失去信用和项目
- 容易失去控制
如何精确的估算任务需要的时间？
如何估算取决于程序员。程序员只能申请与自己在上次迭代中完成任务相等天数的任务。
XP中所有代码都是成对完成的，估算时应该考虑到这一点。
迭代期间，要让团队看到自己完成的工作，程序员担心遭到批评而不会按照自己的经验工作。这里要强调的是，程序员的速度并非其生产力、速度或者达标能力的衡量标准，只表明他能申请多少任务。进行精确的预测要比达到任何强度的生产力标准重要，速度的绝对值远没有预测能力重要。
如何更好的协调bug和功能间的时间分配？
可以将错误修复安排在故事中，因此客户可以在修复错误和添加更多功能之间进行选择。
程序员估算修复时间，客户设置优先级。
如何扩张一个10人的团队到40人？
可以通过分割以扩大团队：
- 10个人完成产品的第一个版本
- 将10个人分割为两个5人的团队
- 每个团队增加到10人
- 重复两次，团队就有40人了
应该使用什么样的工具？
应该使用简单的工具。对于成功而言，沟通比奇才更重要。
如何将XP写入商业合同？
外包合同确定了4个变量中的3个：
- 时间
- 范围
- 成本
无法确定第四个变量：质量。
固定范围的合同的基本问题在于，它将供应商和客户的利益直接对立起来。客户希望更多的功能，供应商希望更多的钱。
应用XP的合同可以这样写：供应商8个程序员为客户工作两个月的报酬是32万美元。范围将根据经典书籍《规划极限编程》每两星期进行一次协商。
每个XP都一样吗？
不要期望任意两个XP会做完全相同的事，只要你熟悉了它的基本过程，就会使其渐渐变得更加适合你自己的情况。
最后
你在实施XP的过程中遇到了什么问题吗？欢迎留言。
