aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Howto estimate projects - which method preferable? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Howto estimate projects - which method preferable?" Watch "Howto estimate projects - which method preferable?" New topic
Author

Howto estimate projects - which method preferable?

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi,

you know all the fact that your manager is asking how long you will need to make this or that project. And most of us have the difficulty to give him the right estimates .

Personally I think that Feature Driven Development (FDD) comes near to a good solution. At least I was in projects where this method worked good. However to give reliable estimates it takes time (1 week) and you have to go through the whole modelling chain of FDD. I mean how can one give reliable estimates when he/she has not gone through the whole OOAD process .

Now, to satisfy a Manager with reliable estimates, what method do you advise .

Regards,
Darya


SCJP, SCJD, SCWCD, SCBCD
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Darya, we discussed something along these lines just a couple of days ago in this thread. You might want to read some people's views in that thread.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Thanks Lasse, I take a look at it.

Regards,
Darya
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Oh , I already read this one. However I want to get something tangible out of my new thread. Hopefully someone comes forward with a good suggestion. Otherwise I would definitely stick with Feature Driven Development (FDD).

What confuse me is the fact that here at JavaRanch there is not a lot of really talk about FDD .

Regards,
Darya
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Darya Akbari:
What confuse me is the fact that here at JavaRanch there is not a lot of really talk about FDD

I suppose that's evidence of one of two things: a) FDD is not that common, and/or b) FDD users have their own forums to which they focus their discussions (like the one at featuredrivendevelopment.com).
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Lasse,

you are right, however I don't want to talk about FDD :roll: but about another and maybe easier and faster method. I would appreciate when someone here could explain such a method in easy words.

Regards,
Darya
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I'm afraid there is no universally "best" process (no silver bullet). I'm sure it would help if you could describe your particular setting in a bit more detail because that would let us associate your problems and assets with the characteristics of a number of processes or process frameworks.

For example, here's some questions I might ask if you'd ask for consultation:
1) What is the product you're developing?
2) What size of a team do you have?
3) What is the experience level of your team in general?
4) What is the experience level of your team with the technologies involved?
5) What is the experience level of your team in software processes?
6) What is the corporate culture like regarding software processes?
7) What does the management think regarding software processes?
8) What other problems do you see in your current environment?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'm getting old and cynical, but I've about decided nobody estimates for beans. The infamous Chaos reports seem to indicate that we are getting better. The percentage of projects coming on time and budget is edging up slowly, but it's still pretty darned low.

I like to point out that Microsoft, who must develop about as many lines of code as anybody, is still terrible at estimating. My favorite was "Windows 4" which in late 1993 was scheduled for late 1994, and in late 1994 was scheduled for late 1995. It slipped a year in a year. Sheesh. Longhorn has been slipping dates and removing features lately.

All this makes me very interested in the agile movement's emphasis on small, rapid iterations. Most of the hype is about delivering better software earlier and faster, which I'm inclined to believe. But my favorite part is the transparent visibility of progress. Every two or three weeks you measure what you've done, refine your estimates of the work remaining and your speed at chewing through the work.

If it appears you won't deliver the amount of value the customer needs by the date he needs it, you all know about it right away and you can negotiate what to change to make things better. I wonder if that openness and participation doesn't lead to as many satisfactory project outcomes in the Chaos report as better estimates would have.

So estimate to the best of your abiltiy. On your first project, that ability will probably be poor. Not your fault. On your third project with the same technology, team and customer your estimate will probably be pretty darned good, but I've never had that many things stay constant that long. Then find a process that makes progress as visible as possible and get everyone to participate in adjusting the plan over time.

My 2 cents.


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
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Thanks Lasse and Stan

I talk in general. There is no specific project I could tell you. I will definitely look more into
Stan's homepage. My first impression was superb .

Regards,
Darya
[ February 27, 2005: Message edited by: Darya Akbari ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
And most of us have the difficulty to give him the right estimates .


If we knew for sure that the estimate is right, it wouldn't be an *estimate*! :roll:



However to give reliable estimates it takes time (1 week) and you have to go through the whole modelling chain of FDD.


1 week for what project size?


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
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Ilja,

1 week was just an example. It could be less or more depending on the project.

You are right when you say that estimates are just that, estimates . However when I want give estimates to my manager I want to give him something profound.

And whatever method we are after it should be something tangible. Of course I like to know the method with the smallest overhead. FDD for example is described on 6 pages and that's it.

I don't know anything about the Agile process and whether a method like FDD would play a role or not. Honestly FDD and MDD (Model Driven Development) are the only methods I practized with.

I will have to read in Stan's homepage to get some new insights.

Regards,
Darya
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
1 week was just an example. It could be less or more depending on the project.


I was asking because using the XP Planning Game, you could spend, say, half a day estimating and the rest of the week implementing the first stories for getting first feedback on our actual "velocity". See http://c2.com/cgi/wiki?ProjectVelocity
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Ilja,

I saw the input from you concerning the Planning Game and saw it also on Stan's homepage. I never heard about it before and will definitely take a deeper look to it.

Thanks,
Darya
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
See also http://www.extremeprogramming.org/rules/velocity.html
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
My environment still has huge pressures to fix scope and date. Our customer gets money from their customers. Together they have to schedule big chunks of money into fiscal periods and big chunks of functionality to regulatory and business calendars. For example, "If you can deliver the employee enrollment functionality by the day enrollment starts we want it. If you can't make the date, don't even try; we'd rather have something else."

The first highest-level estimates must be good enough to lay out the large puzzle pieces. Fortunately we've had the same team and customer for a long time and the technology is starting to stabilize again and we can get in the ballpark. Unfortunately, missing and fuzzy requirements at that level mean we have as much change during the course of a project as anybody. Sigh. I believe the improved visibility of small stories and short iterations helps keep us honest and makes our customer our partner and friend in solving problems. We still pull long days right before deployments, but there's not so much confusion and panic as the old days.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
"If you can deliver the employee enrollment functionality by the day enrollment starts we want it. If you can't make the date, don't even try; we'd rather have something else."


Mhh, "employee enrollment" sounds like a quite coarse grained requirement to me. How long would it take to implement only what is *absolutely* necessary to use it?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
We made the customer put all the stories in priority order on the table - real index cards - and draw the "line of value" that must be met. Without that much functionality, they'd rather stay with the old system. That's a pretty firm requirement for scope and date.

Some user groups who currently have manual processes leave a lot of stuff on the "optional" side of the line ... nearly anything is better than nothing, the rest is gravy. Typically groups who are trying to replace existing systems want all or nothing. It's very hard to talk them into moving the line away from a one-to-one replacement of features, often impossible to omit external inputs and outputs.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
We made the customer put all the stories in priority order on the table - real index cards - and draw the "line of value" that must be met. Without that much functionality, they'd rather stay with the old system. That's a pretty firm requirement for scope and date.


Sounds fair.

I think the best to do in that case is to say "we estimate the probability of hitting the 'line of value' in time at xx%. If you give us the go, we will give you an updated probability at the end of every week. At each time you can decide to change direction or cancel the project."

What do *you* do in that situation?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Personally I use a dart board. If I get a bulls eye, that is a month long project. All the other number is in terms of days.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
What do *you* do in that situation?


Your suggestion is largely what I described earlier, but I didn't mention the option of shutting it down explicitly. That's always there. I focus on two things: One is we have to be able to estimate well enough to know whether or not we want to sign up for the job. We usually do pretty well, but sometimes we commit and wind up with a painful crunch at the end. The other is the transparency of small stories and short ierations - compared to the old days of giant use case sized promises and big bang delivery - make it a lot more likely that the software team and the customer will identify problems early and collaborate on a solution that keeps us all happy.

In real life we've worked with customers accustomed to hard dates and by showing them early how and why we're off the original plan negotiated scope and date changes that they never would have agreed to if we just showed up a week before deadline and begged for more time.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Interesting points:
1. It's easier to estimate small things than large ones.
2. The best estimates are done by people who have built it before.
3. The best estimates are often done by the people who will do the work, because they're the most motivated.
4. Are traditional estimating techniques such as function points, COCOMO, ... anything more than busy work?

- 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>
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Howto estimate projects - which method preferable?