Читаю интересный список Agile Project Management. Выписываю длинную, но прекрасную цитату из некоего
Once the project is underway, and we have a couple of iterations under our belt, velocity measures allow us to extrapolate the project duration based on empircal results rather than the conjecture of critical path methods. That makes good sense to me. One area where I see us falling short in agile is before the project is started and before the project is even approved.
First, let me explain what I mean by fiduciary responsibility (if this is obvious to you, please forgive me). In the case of for-profit corporations, management has a fiduciary responsibility to their stockholders to reinvest company profits into projects only if those projects can provide better returns than could otherwise be earned in the market. Failing that, the profits are paid out in dividends so the stockholders can invest them elsewhere. In the case of a non- profit corporation, management has a fiduciary responsibility to contributors to ensure that their money is spent wisely for the greatest good to society. In the case of governmental agencies, management has a fiduciary responsibility to the public trust placed in them to spend tax dollars or other revenues wisely for the greatest public good. In all of those cases, management must make difficult decisions to fulfill their fiduciary responsibilities. Prime among them for this discussion is, "Which projects should be funded and which projects should be postponed or rejected in favor of those pursued?"
The management team is almost always confronted with more ideas than they can accomplish in a planning period. Marketing wants new product capabilities, manufacturing wants to improve shop floor efficiency, etc. Making those difficult decisions requires lots of thought about vision, strategy, throughput, capacity, skills and a host of factors. Among them, cost and schedule always play heavily. Management needs to know how much a project will cost, how long it will take, what benefits it will provide and when it will realize those benefits -- ROI, NPV, IRR, payback and such. They need that information so they can weigh alternatives against each other or to determine if the returns will exceed the costs of raising the necessary capital. I contend that these are legitimate needs that can't be wished away.
And yet, when I ask my agilist friends how to estimate how long the project will take, I am told, "as long as it requires," or "until the money runs out". When I tell them that I need to tell management something, I get, "Resist the pressure to answer that question too soon." This doesn't help management make better decisions. Nor does it help sell Agile. Supporting management's requirements requires estimating before the use cases are complete and before empirical velocity metrics can be derived. Numbers get put in the window way back in the business case stage that sometimes carry forward as hard constraints to which the project must be managed.