This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
In reading Agile Software Engineering (I'm done Junilu) Here's how I understand XP to work (in a very very summarized version: 1) Customers define needed use cases. 2) The engineers estimate how long each use would take to implament. 3) The customers prioritize which use cases go into which iteration. After each iteration, things can be changed, i.e. cases added, removed, or reprioritized. (Note: the above is only part of the XP process, and it's obviously short on details even for those steps; if I'm skipping other parts or details that are key to getting the above to work, please correct me.)
What I have not seen explicitly state, by seems implied is changing the estimates on the use cases. Surely as the system grows, the cost of implamenting a use case will change. Are all (or event many) use cases formally revisited at the start of each iteration? What happens if someone else did hte estimate, but you then picked up that task and think the estimate is off (or perhaps, because of different skill levels, it will take you longer, but the person who can do it fastest is already planning on other work)?
I think your preferred terminology might be getting in the way here. Beck carefully chose to call these units of required functionality "stories" rather than "use cases", for several good reasons.
A story might refer to something not directly related to a more traditional use case (e.g the vague story "responses should come back quickly", or "installation guide")
A story might not need to be formally documented or processed. A story in XP is really just a reminder to talk about something in more depth later.
Stories can be split or combined at will to make units of work which are more likely to be estimateable
Where I have seen "use cases" used, they have almost always been quite large pieces of end-to-end functionality, and required a lot of system knowledge to undertand and estimate. And the estimates have often been wildly wrong. A key part of the XP planning process which you skip over in your list is the bit where stories which can't be realistically estimated straight away are split into smaller chunks which either can be estimated (near enough) or need some more discussion or experimentation. So I might reword the list as follows:
Customer and developers discuss ideas for things to be added or changed, noting them down as "stories" as they go.
The developers go through the pile of stories putting a rough estimate of work on each one. If a story is too big or too unknown to estimate the team can:
defer it to some future iteration, (or maybe never)
split it into smaller stories which can be estimated
discuss the story until the developers know enough to estimate it
add a new story about some experimentation needed to find out more
Overlapping with this, the customer gathers the most important estimated stories into an "iteration"'s worth of work.
As soon as everyone is happy that an acheivable selection of the most important work has been chosen for this iteration, development can start.
This process ("the planing game") takes place at the start of every iteration, including the re-estmation of any remaining already-estimated stories. Note that from lots of studies and practical experience, long-term estimates are much more likely to be wrong. So the planning process emphasises splitting long or complex stories into shorter, simpler ones (say a few days work at most). In this way everyone involved in the process gets feedback on progress much sooner. Expectations and deliverable goals can be changed at any point in the process: If a story is taking too long to develop either it or some other stories it can be split, rescheduled, changed etc. in discussion with the customer. If a story is no longer important to the customer it can be removed or rescheduled, and the developers and customer can discuss what else to add to the "iteration" in its place. And so on. [ July 22, 2002: Message edited by: Frank Carver ]
Originally posted by Frank Carver: Note that from lots of studies and practical experience, long-term estimates are much more likely to be wrong.
Just as a point of clarification, do you mean 'lots of studies of planning with XP', or do you mean it in the broader sense? There are non-XP techniques for planning relatively large projects that have been successful, but that doesn't mean that many people know about them or are sufficiently skilled in applying them. I only bring it up because statistics only attempt to describe typical population behaviour, not what may or may not be possible to achieve. [ July 22, 2002: Message edited by: Reid M. Pinchback ]
Reid - SCJP2 (April 2002)
Joined: Jan 07, 1999
do you mean it in the broader sense? Very much in the broader sense. Planning anything is harder the further ahead it looks. There's just more possibilities for things to interfere with the plans.
Originally posted by Reid M. Pinchback: There are non-XP techniques for planning relatively large projects that have been successful, but that doesn't mean that many people know about them or are sufficiently skilled in applying them.
I think it depends on how you define "successful". If you define it as "delivered exactly what was planned when it was planned for", it certainly is an astonishing accomplishment - but nothing XP primarily strives for! XP explicitely strives for "delivering maximal business value at the end of each iteration". And it presumes that it is very unlikely to know from the start on how to do that for any interesting project. In fact I even experienced a project changing direction by ninety degrees at the start of the third iteration - not because it was badly planned, but because of a suddenly arising new opportunity. If you are so committed to "embracing change", there simply isn't much value in a detailed long-term plan. [ July 23, 2002: Message edited by: Ilja Preuss ]
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
Joined: Dec 04, 2000
Originally posted by Ilja Preuss: XP explicitely strives for "delivering maximal business value at the end of each iteration". And it presumes that it is very unlikely to know from the start on how to do that for any interesting project. In fact I even experienced a project changing direction by ninety degrees at the start of the second iteration - not because it was badly planned, but because of a suddenly arising new opportunity.
Do tell! I'm interested in the story. --Mark
Joined: Jul 11, 2001
Originally posted by Mark Herschberg: Do tell! I'm interested in the story.
Originally posted by Ilja Preuss: I think it depends on how you define "successful". If you define it as "delivered exactly what was planned when it was planned for", it certainly is an astonishing accomplishment - but nothing XP primarily strives for!
Actually, it really isn't rocket science, although for accurate estimates in big projects (year+, 100+ people) there are some techniques to learn and historical industry data to purchase. I was thinking more on the estimating side of things, than on the strict planning component. As bizarre as it sounds, estimating works best if you divorce it from the planning. Frank's point is correct; plans get fragile the farther out you go, so if you base your estimate on the accuracy of the tasks described in the plan, you can get yourself in hot water. Estimates work much better if they are tied to analysis artifacts and you do a little bit of data tracking across your projects. For example, I've been on projects where you begin by mocking up web pages and working out the navigation paths between the pages. That doesn't usually take a small team very long. You then categorize your pages into 'easy' and 'complex', estimate the typical growth in added pages over the life of the project, stuff the numbers into a nice linear formula based on performance in past projects or project iterations, and out pops a number. Few concrete plans were made, other than assigning responsibilities for various pages or back-end services to each developer. If you aren't doing any dramatic technology changes, a 3-man, 3-month project should be able to hit its target plus or minus a week. Generally any delays are due to things outside the control of the project team (e.g. delivery of something from a vendor), but over time you improve your estimates to make allowances for that. In our case we actually identified some of those risks beforehand; we just made sure we did the best we could on our part of the project. Similar techniques can be used for larger projects (actually, the approach came from the larger projects, not the other way around). The full-fledged version is called function point counting. Historically it had some technology limitations (it was designed at IBM around file I/O apps), but it has gradually been extended into other areas. Widget counting is a low-tech variant that was developed for GUI-intensive app creation. I've done similar things for small process improvement projects where no software was involved at all (the estimate was based on the artifacts in an outline of the final report), and had results similar to that for small web projects. [ July 23, 2002: Message edited by: Reid M. Pinchback ]
Similar techniques can be used for larger projects (actually, the approach came from the larger projects, not the other way around). The full-fledged version is called function point counting. Historically it had some technology limitations (it was designed at IBM around file I/O apps), but it has gradually been extended into other areas. [ July 23, 2002: Message edited by: Reid M. Pinchback ]
wanted add certain things. Function points are of two types , Adujusted & Unadjusted. There are around 14 parameters which have to be considered for adjusted function points. Function Points can be applied to entire GUI based systems also. They can also be applied to OO environments. Now , you have got 3D function points in which three dimensions are data , function & control. there are certifications for certified function point specialist . regards.