• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Howto estimate projects - which method preferable?

 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Lasse, I take a look at it.

Regards,
Darya
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See also http://www.extremeprogramming.org/rules/velocity.html
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
We find this kind of rampant individuality very disturbing. But not this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic