实施极限编程会遇到的7个问题

在实施极限编程的过程中，可能会遇到一些问题，下面我们列出几个并进行解答。
这些问题包括：

1. 如何进行准确的估算？
2. 如何计划系统架构？
3. 发布日期可以改变吗？
4. 如何更好的协调bug和功能间的时间分配？
5. 如何扩张一个10人的团队到40人？
6. 如何将XP写入商业合同？
7. 每个XP都一样吗？

如何进行准确的估算？

估算充其量只是一种技巧。无论付出多大的努力，都无法获得精确的数字。

估算单位并不重要，唯一重要的事情是始终使用同一单位。

估算要团队一起做，如果存在分歧，可以遵循“乐观主义获胜”原则，使用最短的估算时间。

记住，估算不是承诺，几次错误的估算并不会成为灾难。目的是不断提高估算的能力。

随着估算频率的增加，每个人都会估算更准确

如何计划系统架构？

有些架构需要几个月的时间去设置，而不包含客户的功能。这种风格是已经失败或者即将失败的项目的常见特征。

不包含客户的功能有以下风险：

• 花费大量时间却没有交付对客户有用的东西，会导致与客户之间的关系紧张
• 试图使系统架构包含你认为可能需要的每个方面，导致系统架构过于复杂

正确的做法是：

• 生成功能时，就改进系统架构
• 每次迭代，只为改迭代中的故事生成足够的系统架构
• 不要生成比你所需要的更为复杂的系统架构

发布日期可以改变吗？

XP最重要的法则之一就是：日期是硬性规定的，不要改变发布日期。而范围可以变化。

不要改变日期，有两个原因：

• 延迟太多容易失去信用和项目
• 容易失去控制

如何精确的估算任务需要的时间？

如何估算取决于程序员。程序员只能申请与自己在上次迭代中完成任务相等天数的任务。

XP中所有代码都是成对完成的，估算时应该考虑到这一点。

迭代期间，要让团队看到自己完成的工作，程序员担心遭到批评而不会按照自己的经验工作。这里要强调的是，程序员的速度并非其生产力、速度或者达标能力的衡量标准，只表明他能申请多少任务。进行精确的预测要比达到任何强度的生产力标准重要，速度的绝对值远没有预测能力重要。

如何更好的协调bug和功能间的时间分配？

可以将错误修复安排在故事中，因此客户可以在修复错误和添加更多功能之间进行选择。

程序员估算修复时间，客户设置优先级。

如何扩张一个10人的团队到40人？

可以通过分割以扩大团队：

• 10个人完成产品的第一个版本
• 将10个人分割为两个5人的团队
• 每个团队增加到10人
• 重复两次，团队就有40人了

应该使用什么样的工具？

应该使用简单的工具。对于成功而言，沟通比奇才更重要。

如何将XP写入商业合同？

外包合同确定了4个变量中的3个：

• 时间
• 范围
• 成本

无法确定第四个变量：质量。

固定范围的合同的基本问题在于，它将供应商和客户的利益直接对立起来。客户希望更多的功能，供应商希望更多的钱。

应用XP的合同可以这样写：供应商8个程序员为客户工作两个月的报酬是32万美元。范围将根据经典书籍《规划极限编程》每两星期进行一次协商。

每个XP都一样吗？

不要期望任意两个XP会做完全相同的事，只要你熟悉了它的基本过程，就会使其渐渐变得更加适合你自己的情况。

最后

你在实施XP的过程中遇到了什么问题吗？欢迎留言。