aspose file tools*
The moose likes Agile and Other Processes and the fly likes Question on Software Estimation. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Question on Software Estimation." Watch "Question on Software Estimation." New topic
Author

Question on Software Estimation.

Mohan Karthick
Ranch Hand

Joined: Apr 11, 2005
Posts: 199
Hi

Can anybody advice how to do Project Estimation in a role of Project Leader, as i came across with this question many times but not able to satisfy the interviewer.

Thanks,
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You might find http://www.ambysoft.com/essays/agileProjectPlanning.html to be of interest.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mohan Karthick:
Can anybody advice how to do Project Estimation in a role of Project Leader


Ideally, you let the people who later have to do the work estimate how long it will take them, and possibly adjust that by historical data on how estimates of those persons typically differ from actuals.

One way to do that is to use the Extreme Programming Planning Game.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
Ideally, you let the people who later have to do the work estimate how long it will take them, and possibly adjust that by historical data on how estimates of those persons typically differ from actuals.


I agree with that. Everytime an estimate was done by someone who was not going to be doing the task, they were way off. I find that in addition to this, though, you need to know the people well and know whether they can normally judge how long a task will take them. So I normally:
1. Talk to the person about their estimate
2. Keep an idea from proj. to project of whether they tend to under/over estimate

Now, if you're estimating for a project that you'll have to hire people for (or that you'll later assign to people), perhaps you should use a combo of your own experience with the Use Case Point Method. http://www.coderanch.com/t/153403/java-Architect-SCEA/certification/meaning-Points
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18117
    
  39

I always considered this skill to be a form of "black magic"... :-)

I have seen both extremes, although more projects tend to be under-estimated than over-estimated. I have also noticed that there is little relation between technical skill and accuracy.

Too bad we can't just do the project first, then estimate the time for it... :-)

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Robert Paris:
2. Keep an idea from proj. to project of whether they tend to under/over estimate


Full agreement - that's what I tried to say with "adjust by historical data"...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Henry Wong:
Too bad we can't just do the project first, then estimate the time for it... :-)


But you can get close: Split a project into many small projects (for example one week iterations) which implement a small part of the functionality end-to-end. That way you can rather easily gather data on how fast you really can go.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
We spent a rough day with a couple IBM guys who wanted us to break down every task into how many hours of work were required for front-end, mid-tier, back-tier, database, who would do the work, what were their skills, etc. We eventually wore them down to accept the way we estimate tasks as 1-to-8 story points and add them up. I have heard of teams who figure once they get the story granularity down to a few days worth of work the sizes will all average out and they can do adequate estimates just based on the story count.

The industry as a whole is very poor at estimating. That's led us to trust our instincts and not invest too much effort in it. Don't confuse precision with accuracy. "The project will be done on November 11th" is precise, but no more accurate than "The project will be done in the third quarter". If the dates are nailed down, substitute some other unknown, eg how many features you'll get done.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
In the Organizational Patterns book you can find a small pattern language on scheduling. Almost all of it comes from Ward Cunningham's EPISODEs pattern language, and we have seen it empirically validated again and again.

To me, the main points are these:

  • In the four-legged stool of schedule, staff, functionality and quality, schedule is sacred. Change anything else, but not schedule. There is a lot of research that says that there's no better way to piss off a customer than to slip schedule. The best thing to do is to renogiate functionality. It happens all the time, even though the marketing superstructure may not be willing to acknowledge it. In a large telecom company where I used to work, we found that during maintenance, about 40% of the contracted features changed and were re-negotiated at the engineering and developer level after the contract was signed because conflicting requirements, incompatibilities, and nonlinear staffing repercussions arose in implementation.
  • Directly relevant experience, or analogous experience, are the best indicators. Just about anything else involves the moral equivalent of reading goat entrails and stars in the heavens.
  • Even if you can predict well, you still can't win. A management simulation study done at MIT shows that developers sense an overambitious schedule and panic to the degree they overshoot the schedule, and that they sense a padded schedule and defer work until it is too late. In both instances you overshoot the schedule by about the same amount. The solution seems to be to keep two sets of books: one for the market, and the other for your developers. In a Community of Trust you can show both sets of books to your developers -- and in those rare communities of very high trust you can show both sets of books to your customers, too.
  • At the Object conference I chaired a few years ago out here in Boston we had a panel where the panelists were asked, "What is the sure sign of a sick project?" I think it was Tom DeMarco who answered: "A schedule worked backwards from a delivery date." Such a linear schedule is not agile.


  • Contrary to previous postings:

    • You can't accurately plan anything in detail without tanking productivity. Let the Developers Control Process; they know how to interleave detailed tasks if you give them a priority-ordered Work Queue.
    • Take a modest bow to requirements but be prepared not to take them too seriously. You won't know most of them until you try to implement. This reflects not only the hard experience gained on real projects, but some fundamental properties of the design process itself. A good read is the book by Reiser et al. entitled "Software Development as Reality Construction." After reading it you'll let go of any delusions you had that you can usefully predict requirements before you're done implementing. Instead, Engage Customers. See <em>Contextual Design</em> by Beyer and Holtzblatt -- what a great book.



    • Cheers,

      Cope
      [ May 03, 2005: Message edited by: James Coplien ]

James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Eusebio Floriano
Ranch Hand

Joined: Mar 07, 2004
Posts: 235
How can we estimate the productivity in an very heterogenic team ?
Some senior developers, some junior, and so on.


Regards,


SCJP 1.4 / 5.0 - SCBCD 1.3 - SCWCD 1.4 - IBM 484
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Vinicius Boson:
How can we estimate the productivity in an very heterogenic team ?
Some senior developers, some junior, and so on.


The same as with every other team - start with gut feel, preferably with input from the whole team, and then measure.

The performance of a team is far from simply being the sum of the performance of its members. It will most heavily depend on how well the team will work together - will they communicate and collaborate well, will seniors be effective at mentoring juniors etc.
James Coplien
author
Greenhorn

Joined: Oct 26, 2004
Posts: 22
1. Ilja is exactly right -- you need "good guts."

2. You are much better off with heterogeneity than homogeneity. Homogeneous teams too often deadlock or go into brownian motion. Heterogeneity fuels the engine that keeps you from getting stuck.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by James Coplien:
2. You are much better off with heterogeneity than homogeneity. Homogeneous teams too often deadlock or go into brownian motion. Heterogeneity fuels the engine that keeps you from getting stuck.


Good point - in a well working team, diversity of experience and opinion will foster creativity, which can be a major contribution to success.
Pieter Schmidt
Greenhorn

Joined: May 01, 2005
Posts: 5
Originally posted by Mohan Karthick:
Hi

Can anybody advice how to do Project Estimation in a role of Project Leader, as i came across with this question many times but not able to satisfy the interviewer.

Thanks,


Estimation comes down to 2 different methodologies; parametric or expert based techniques.

Parametric methods involve using tools that rely on historical data calculate an estimation based upon functionality, e.g. COCOMO, Use Case Point/Function Point analysis...
Expert techniques rely on building an estimate based upon the collective experience of 'seasoned' practitioners - developers...

Have a look at these articles on the two different methods for estimation

http://liemur.co.uk/Articles/UseCasePointEstimation.html

http://liemur.co.uk/Articles/Wideband_Delphi.html
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question on Software Estimation.
 
Similar Threads
use case based Project estimation ?
estimation
Interview question on Software Estimation.
Certify My Own Certification
Function Point Analysis