问对敏捷环境中的大型项目进行评估

EN

这是一个基本问题。

客户端什么时候会认为他们完成了？

如果他们认为他们会在6月份之前完成，那么你就可以组建一个敏捷团队。那就是6个月的4-6个人。这是预算。从本质上讲，你为它们做乘法运算。团队*率*6个月。

如果他们认为他们会在6月份之前完成大部分工作，但在那之后会有更多的工作，那么你可能会看到9个月的工作。再说一次，你只是在做一个他们可以自己做的乘法。团队*率*9个月。

如果他们认为你会在可预见的未来成为他们的开发团队，给他们一个能让项目在年底完成的价格。团队*率* 12个月。

由于每个版本都是一个重新确定优先级的机会，因此您应该根据您在该版本中完成的事情，将每个版本作为单独的工作来定价。因为这是他们的优先方案，他们控制你的建设，他们控制预算，分阶段进行。

通常情况下，你的客户真的想知道一个特定的功能集将花费多少。他们不问这个问题，而是问总体预算(这很愚蠢)。花很多时间在第一个版本上，展示他们得到了什么，以及第一个版本将花费多少钱。

最终，他们会看到根本的真相。

从最重要的功能到最不重要的，他们都在购买这些功能。如果他们的优先顺序正确，他们可以随时停止花钱，并拥有一些有用的东西。

Done是一个相对的术语。一些项目之所以“完成”，是因为没有更多的钱。其他的则是因为没有更多的时间。很少(至少在软件开发中)因为我们没有事情可做而完成了一个项目。

对于这种情况，我们已经提供了第一块工作的估计，然后让客户根据需要购买更多的冲刺，以完成所需的工作。

随着您开发更多的系统，并将来自客户的反馈合并到sprint可交付件中，您将对所涉及的工作量以及所涉及的成本有更好的感觉。

编辑： Cool.太棒了！从你向他们推销敏捷方法的事实来看，顺便说一句，这是一个很好的方法！你有机会从敏捷的角度出发，从要实现的特性的角度来看待他们。也许你可以听听这个"Intro to Scrum“播客。你也许能够说服他们，因为他们可能不需要拥有他们认为现在需要的所有花哨的东西。

HTH

干杯,

抢夺

听着，这里有一个核心事实。您将被要求估算成本，签订特定交付日期的合同，并承诺提供完整的功能集。

你不能同时做这三件事。

而不是“你不应该”或者“明智的不去做”；你(实际上)不能。我的意思是，成功做到这三件事的概率非常小。

最好的答案是致力于成本和时间表，以及具有快速迭代和定期反馈的迭代过程，然后编写协议，以便在固定成本和时间表下完成的工作将交付。也就是说，你一直在交付新的特性(和修改)，直到时间和金钱耗尽。

事实是，即使你确实签署了所有三个，你能做的最好的是三个中的两个。还不如公开这件事。