3 ms·

In the enterprise I work in, people need estimates in order to manage resourcing - which is not something unique just to the software industry. We always have

In the enterprise I work in, people need estimates in order to manage resourcing - which is not something unique just to the software industry. We always have a prioritised list of projects but only a limited number of developers, so for us estimation lets us know when a developer is available to work on the next project. Estimation is important and before any project is accepted we go through maybe a day or two working out the main application structure, breaking it down and providing rough, high-level efforts. Then we factor in the usual holidays, risk buffer (illness, estimation uncertainty), rigging, testing, release etc. Once the project's accepted then a more accurate plan is delivered after we have a design and task list ready. The main thing I've learnt is people are far more willing to accept over-estimated plans at the beginning rather than extend a project that's run overtime.

wpietri 13y ago
Resourcing and estimating against plans is one approach, but it's not the only one. You can also use a flow-based approach. Basically, you have teams with queues; whenever a team is out of work, they pop something from the queue and work on it until complete. Or, if the organization is more subtle, you release early and often, ending a project when it looks like the team can be more usefully deployed elsewhere. Mary and Tom Poppendieck cover this approach a fair bit in their books.
- jacques_chester 13y ago
  I agree that this is a good alternative; I certainly prefer it. I prefer to think of it as a derived factory. It used to be that we thought of software projects as being like a factory, which eventually turned out the end product: a single piece of software. Now we've taken the first derivative in a calculus sense and realised that the actual output of this conceptual factory is changes to software. The manufacturing analogy makes more sense in that respect; though concepts like SPC are hard to map because normal variation of software production can be very high indeed.

wpietri 13y ago

Resourcing and estimating against plans is one approach, but it's not the only one. You can also use a flow-based approach. Basically, you have teams with queues; whenever a team is out of work, they pop something from the queue and work on it until complete. Or, if the organization is more subtle, you release early and often, ending a project when it looks like the team can be more usefully deployed elsewhere. Mary and Tom Poppendieck cover this approach a fair bit in their books.

jacques_chester 13y ago
I agree that this is a good alternative; I certainly prefer it. I prefer to think of it as a derived factory. It used to be that we thought of software projects as being like a factory, which eventually turned out the end product: a single piece of software. Now we've taken the first derivative in a calculus sense and realised that the actual output of this conceptual factory is changes to software. The manufacturing analogy makes more sense in that respect; though concepts like SPC are hard to map because normal variation of software production can be very high indeed.