对敏捷环境中的大型项目进行估算 [英] Giving estimates for large scale projects in an Agile Environment

问题描述

我的公司刚刚收到第一笔大型开发项目咨询，我想使用敏捷流程。客户对应用程序抱有远见，但公开承认自己的需求很少，并意识到我们将按小时收费。正因为如此，我几乎所有的人都以敏捷的方法出售了他。

My firm just got its first large-scale development project inquiry and I would like to use an Agile process. The client has a vision for the application but openly admits to having very few requirements and recognizes that we will have to charge by the hour. Because of this, I've all but sold him on an Agile approach.

问题是他想要一个预算。我读过很多文章都反对放弃估算，因为客户会为这个数字做预算，即使需求发生变化，他们头脑中和书本中的数字也不会。

The problem is that he wants a figure to budget around. I've read a number of articles that pretty much advocate against giving up an estimate because the client will budget for that number and even as requirements change, the number in their head and in the books doesn't.

我读过有很多方法可以在合同中考虑价格，但是几乎所有方法（节省一个）都包含一个前期数字。这似乎违反了敏捷开发的整个原则。

I've read there are a number of ways to factor in pricing in the contract, but almost all of them (save one) incorporate an up-front number. This just seems to violate the entire set of principles of Agile development.

所以我的问题是，如果您是一家敏捷商店，您将如何规避这一陷阱-22敏捷开发？

So my question is, if you're an Agile shop, how do you manage to circumvent this Catch-22 of Agile development?

推荐答案

这是基本问题。

客户什么时候会认为他们已经完成？

如果他们认为在六月之前完成任务，那么您可以组建一个敏捷团队到位。这是4-6人，共6个月。那是预算。本质上，您需要为它们做乘法。团队*费率* 6个月。

If they think they'll be done by June, then you put an Agile team in place. That's 4-6 people for 6 months. That's the budget. Essentially, you do the multiplication for them. team * rate * 6 months.

如果他们认为大部分时间是在六月之前完成，但之后还会有更多工作要做，那么您可能会关注9个月的工作。同样，您只是在做他们自己可以做的乘法。团队*费率* 9个月。

If they think they'll be mostly done by June, but there will be more work after that, then you're possibly looking at 9 months of work. Again, you're just doing a multiply that they could do for themselves. team * rate * 9 months.

如果他们认为在可预见的将来您将成为他们的开发团队，请给他们一个价格，该价格将使该项目顺利完成年底。团队*费率* 12个月。

If they think that you'll be their development team for the foreseeable future, give them a price that will get the project through to the end of the year. team * rate * 12 months.

由于每个版本都有重新安排优先级的机会，因此您应根据自己的情况将每个版本作为单独的工作定价>将在该版本中完成。由于这是他们的优先级方案，因此他们可以控制您的建设内容，可以逐步控制预算。

Since each release is an opportunity to reprioritize, you should be pricing each release as as separate piece of work based on the things you will get done in that release. Since it's their priority scheme, they control what you build, they control the budget, phase by phase.

您的客户通常真的想知道特定功能集的价格。他们没有问这个问题，而是询问总体预算（这很愚蠢）。在第一个发行版上花费大量时间，以显示它们得到了什么以及该第一个发行版将花费多少。

Often your client really wants to know how much a particular feature set will cost. Instead of ask that, they ask about overall budget (which is silly). Spend a lot of time on the first release showing what they get and how much that first release will cost.

最终，他们会看到基本的事实。

Eventually, they'll see the fundamental truth.

他们从以下位置购买功能最重要到最不重要。如果他们确定了正确的优先顺序，他们可以随时停止花钱，得到一些有用的东西。

They're buying the features from most important to least important. If they prioritize correctly, they can stop spending money at any time and have something useful.

完成是一个相对的术语。有些项目完成了，因为没有更多的钱了。其他人之所以完成，是因为没有时间了。很少（至少在软件开发中）做过一个项目，因为我们没事做。

Done is a relative term. Some projects are "done" because there's no more money. Others are done because there's no more time. Rarely (at least in software development) is a project ever done because we ran out of things to do.

这篇关于对敏捷环境中的大型项目进行估算的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！