敏捷需求和文档

Question

我的公司最近开始承担较小的软件开发项目。通常，要在客户端的intranet上使用的小型web应用程序。他们通常要工作3-5个月。

通常情况下，客户不知道他们到底想要什么，所以他们付钱给我们一个较小的项目(3-4周)，以收集需求并编写功能设计。一旦获得批准，我们都知道需要什么，并可以为项目的其余部分报价并继续进行。这是因为他们喜欢固定价格的合同，而不是支付时间和材料。

这个开发非常适合瀑布模型，我们收集需求、设计、实现、测试、交付。然而，尽管如此，我们有时还是要送货，客户说“这不是我的意思”。

我的本能是确保我们有一个更详细的预先设计，但我被告知，我们应该“更敏捷”和迭代开发系统与客户端，以便他们可以看到它的发展，我们可以发现问题的期望更早。

我很想知道如何把它融入固定价格模式。当客户甚至不知道他们想要什么的时候，我怎么估计一个项目呢？我可以看到，在这种情况下，敏捷开发是有益的，但在固定价格的情况下则不然。

我是不是遗漏了什么？

Answer 1

重要的是要同意什么将交付，然后将它放入一系列为期两周的短跑-迷你瀑布发展，如果你愿意。

如果客户端对某些东西的工作方式有点不清楚，这是很好的，但是它不应该致力于开发sprint，因为它实际上无法为它分配任何精确的开发工作。把一些线框放在一起，先解决问题。

你可能会想，你知道客户想要什么，因为这是银行里的现金，但如果在冲刺结束时(S)，客户仍然不高兴，那么他们就会把你关在桶里。在他们看来，他们已经为这一特性付出了代价，而发展应该一直持续到完成。必须不惜一切代价避免这种恶梦。我做了一个中等规模的开发，客户经理同意客户所谓的“一些简单的报告”，而没有仔细研究细节。这些“简单的报告”消耗了我们开发预算的1/3，尽管最初只有1/10的预算。让客户清楚地知道，你愿意到处扔设计，直到他们满意为止，但只有在你对所需的东西有了明确的认识之后，你才会致力于开发。

如果设计过程看起来可能需要一些时间，那么无论如何也要进行一系列并行的冲刺。客户可能会在sprint结束时决定，他们真的不清楚什么是必需的，因此可能会放弃这个想法，或者更好--他们将能够缩小他们想要的范围，从而为下一个sprint提供信息。

Answer 2

简单的事实是，你已经无法满足固定价格模式:你做字体设计，编码和交付ans然后客户说：“哦，不，我们希望它是不同的”，然后你做什么呢？新工作额外收费，还是免费完成更改？

敏捷只是改变开发模型来满足这一点，您的定价要么是花费的时间，要么是固定的交付日期。在前者中，你一直坚持到客户满意为止，而在后者中，你一直坚持到现金用完为止。(这就是为什么你必须总是在每个时间箱的末尾有一个可以交付的东西的原因之一，也许没有另一个)

希望敏捷意味着您能够完成更多的工作，因为需求捕获更便宜(因为它的迭代性，并且需要更少的完整文档和signoff)，因此客户机能够更快地得到他们想要的东西。就是这个主意..。但根据我的经验，客户从来不满意，所以他们最终支付了更多的(在一个时间花费的账单系统)，而没有注意到。总是取悦管理层:-)

Answer 3

如果客户是罚款支付3-4周的项目，他们应该罚款支付2周的项目。然后接下来的两个星期的项目。然后是下一个。下一个，等等。在每个项目的末尾，你会给他们一些半成品的应用程序，然后问他们缺少什么或者哪里有问题。另外，询问什么是最重要的，从什么是遗漏或错误，以便它可以包括在下一个项目。