Post by Ron JeffriesHello, Micron. (Odd name you have! :) ) On Tuesday, May 22, 2007, at
it was the 1st company common email address
Post by Ron JeffriesPost by Micron EngineeringWhat type of estimate and management plan do you propose to a customer
asking to have its software before an exact day?
Suppose that your team can't be larger then 6 sw engineers can you
explain me how can you make an estimation to predict the end of work for
a 1000 points sw starting today supposing 25 hours for week working time
for all 6 engineers?
To begin with, it seems to me to be imprudent, whether one estimates
in real time, ideal time, points, or any other means, to imagine
that we can accurately predict how long the project will take. Few
of us are that good. (If you can do that now, I'd like to hear how.)
Ron, if I have to develop a software to sell (internal product) actually
I/we are using an approach that isn't pure XP and isn't pure traditional
(we started about 6 years ago with a pure PSP process that evolved).
In this case our phases are:
1. Idea definition and presentation
2. Marketing study
3. Application definition
4. Requirements and risk analisys (use cases and stories are written at
this stage)
5. Master planning (estimates are done here, mostly using files,
classes, classes-methods, screens/windows/forms, reports, database
tables, LOCs as unit of measures as appropriate for every module)
6. Development
7. Delivery
8. Maintenance
9. Phase out
Development phase is made with a cycle process that may be specifically
tailored; we don't use pair programming but we use inspections and
continuous testing. In any case it is a cycle that in the more complex
situation can be:
a. high level design (not so detailed) mostly using UML diagrams
b. prototyping (little code blocks to test unknown pieces of code due to
a new library, development tool, algorithm and so on).
c. validate prototyping
d. source code modules development, documentation and test
e. source code modules integration, documentation and tests
the cycle a...e is made for every module, we can use a priority
scheduling to deliver modules that have higher priority.
We can adjust our estimate at every cycle end. In practice a cycle may
take 1 week on little projects and 4 weeks in the others; in this case
last week is all reserved to integration, documentation and test without
regard to modules completion (may be that some one is on delay but the
engineer have to write their modules to don't propagate the delay to the
modules of other engineers).
Delivery, maintenance and phase-out are more simpler steps, only
maintenance uses the same cycle of development.
In a customer-project we have to make estimates at the very beginning
and we need some accuracy because to don't loose money and to don't
underestimate our effort. We also have schedules where the same engineer
already knows the next project to start after he completes the previous
so we can't have to much delay from one project to its successor.
In this situation we make estimates not using points or use cases; we
made estimations with a unit of measure that is more significant for
that module or for the complete application. So it is difficult for me
translate #db_tables to points, # reports to points and so on.
Second, my experience is that the customer already knows what the
day is when she wants the product. Therefore our job is first to
predict how much work we can get done, and second, steer the project
for delivery on that day, //even though we will get a different
amount of work done than we predicted//. (We will probably also get
different work done entirely, because of learning during the project
changing what the customer wants.)
P.S. I made some cut and paste because for some strange reasons I am not
always able to quote yahoo group emails.
Normally our customers ask to us an estimate in terms of money and time
and giving us a delivery date. It is quite common also to pay some fees
if we finish on delay.
Either way, predicting the end of a whole series of stories is much
more difficult, as is predicting just how many will get done.
Actually we have good estimates for a set of applications that we
previously developed; not because some sw is already done but mainly
because we know the problems we had. We are searching a best way to make
estimates on radically new applications or for applications where the
prototyping phase may take 50% or more of the development effort (we
made also 70% estimate time/effort error for prototypeing phases).
But to me, the essence of doing all this is not in predicting, or
committing to far-away amounts of time and features, but in steering
the project to deliver the best possible product by the desired
date. To do that, a reasonable estimate of difficulty and velocity
is sufficient to get a rough idea of what will happen. I'd prefer
point estimates plus established velocity, but also believe that
estimates in perfect days, multiplied by three, is a decent rough
rough estimate.
I can understand your idea but how can help me to make accurate
estimates at the very beginning of a new commitment?
Actually this is our best problem.
Post by Ron JeffriesI prefer estimates in points followed by measurement of velocity to
see how many points we can do in a week. This process should be
repeated every iteration, and the results drawn up in some form such
http://www.xprogramming.com/xpmag/BigVisibleCharts.htm#N190
<http://www.xprogramming.com/xpmag/BigVisibleCharts.htm#N190>
If I understand what Kent has been saying, he prefers estimation
(and /commitment/) in actual time. The difference, I imagine, is
that to commit to a specific moment of delivery for a story, one
I estimate that I need four hours;
I estimate that I'll get two hours a day;
I estimate that I can grab some extra time if things run long;
I commit to be done at the end of the second day.
(Or something like that.)
Either way, predicting the end of a whole series of stories is much
more difficult, as is predicting just how many will get done.
But to me, the essence of doing all this is not in predicting, or
committing to far-away amounts of time and features, but in steering
the project to deliver the best possible product by the desired
date. To do that, a reasonable estimate of difficulty and velocity
is sufficient to get a rough idea of what will happen. I'd prefer
point estimates plus established velocity, but also believe that
estimates in perfect days, multiplied by three, is a decent rough
rough estimate.
Ron Jeffries
www.XProgramming.com
Those who believe complexity is elegant or required don't understand
the problem. -- John Streiff
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14.01
[Non-text portions of this message have been removed]
To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com
ad-free courtesy of objectmentor.com