功能驱动开发项目的最长项目工期

Question

当FDD项目由于外部和内部因素而可能失败时，这些项目是否有期限限制？

例如，XP项目应该保持较短的时间，因为概念的开放性和对团队中个人的依赖，以及缺乏文档，这容易受到诸如失去团队成员等干扰的影响。

Answer 1

项目失败的可能性是你试图在早期考虑的因素。如果您看到一个项目有很高的失败概率，要么它不会启动，要么在早期的探索阶段，需要管理所确定的风险。根据OPs的例子，人们生病或离开团队是任何项目中都可能发生的因素，一个好的项目规划师会尝试在计划中增加一些额外的松懈，以尝试解决可能出现的“不可预见的”问题。

缺乏文档的问题不应该出现在FDD项目上，因为这在很大程度上是一种人工合成的方法。此外，如果编写代码是为了便于阅读，并且需求已经被适当列出和整理，那么缺乏关于XP或敏捷过程的文档来扩展OPs示例不应该成为敏捷过程的一个问题。

因此，“期限”限制实际上并没有什么意义，因为FDD项目的期限通常是由合同确定的。项目工期内的可交付成果通常被定义为功能集，功能集的持续时间将是可变的，因为它取决于正在实现的功能的数量和复杂性。

然而，FDD也是我喜欢的包装方法，因为在开发/测试阶段的范围内，特性集本身可以被视为小型项目，如果它被认为为项目及其所有涉众提供了价值，则可以使用敏捷方法来实现。FDD真正提供的是一组工件--尤其是报告--可以用来测量项目进度，当在每次迭代结束时很难提供工作代码时，这一点就显得尤为重要，因为客户想知道，在他们没有看到所付出的代价的几个月的开发中，已经花费了大量的时间。因此，如果风险很高，并且在很长一段时间内只以很少的时间间隔来指定工作模块，则可以使用报告和其他项目工件形式的可交付产品来缓解项目看起来可能偏离轨道时可能出现的一些问题。报告/停车场图表等.可以交付，越早的措施可以尝试和保持一个项目的轨道上，或限制随着时间的推移可能造成的损害。

Answer 2

任何有很高失败风险的项目都应该致力于尽快交付一些东西。

这是有益的，有几个原因：

• 您可以判断您的产品是否会有必要的需求，并提前失败。
• 您可以得到关于已经开发的功能的快速反馈。
• 您可以得到关于哪些优秀特性仍然被认为是重要的快速反馈。功能的相对优先级将随着时间的推移而改变，新的需求将出现，而旧的需求则会顺理成章。
• 你可以有一些东西“在那里”向投资者展示，这样他们就会不断地给你钱。

无论您使用何种开发方法，这都是正确的。

显然，每个阶段/阶段/sprint的确切持续时间将取决于您可以投入的开发工作和在每次迭代中需要满足的最低需求集。