aspose file tools*
The moose likes Agile and Other Processes and the fly likes Pre-Development Planning and Architecture Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Pre-Development Planning and Architecture" Watch "Pre-Development Planning and Architecture" New topic
Author

Pre-Development Planning and Architecture

Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
When starting a new agile project, typically how much time should be spent up front doing things like developing a high level software architecture (i.e. push vs pull system) and creating the first pass of the product backlog? Is this appropriate to do during the first iteration of a project? Or should other time be set aside for that?

Thanks,
Jeff
[ March 02, 2008: Message edited by: Jeff Storey ]

Jeff Storey
Software Developer
[url]http://jeffastorey.blogspot.com[/url]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeff Storey:
When starting a new agile project, typically how much time should be spent up front doing things like developing a high level software architecture (i.e. push vs pull system)


Just enough to roughly estimate the product backlog.

and creating the first pass of the product backlog? Is this appropriate to do during the first iteration of a project? Or should other time be set aside for that?


That, of course, depends on the size of the project. I don't know the "official Scrum answer", but if I remember correctly, "Planning Extreme Programming" suggests that it could take anything between a few hours and a week.

Typically this should be done before the first iteration starts.


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
Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
Sounds about right. But, should a new project try to do extensive requirements gathering/analysis before the project begins? I understand the concept of doing the least amount required so change is less difficult, but if we don't know the details of what we're building, how do we know what to build? Similarly, if we only make a product backlog big enough to get us through the first iteration, how can we begin to estimate a project's duration (or will the backlog be finished soon there after)? Thanks.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeff Storey:
But, should a new project try to do extensive requirements gathering/analysis before the project begins?


Depends on what you mean by "extensive". In general, your first plan should be wide, but not deep. That is, gather as many requirements as possible, but don't analyze them in depth. You want just enough details so that the developers can give very rough estimates and the customer can prioritize them and select them for iterations.

Mike Cohn's book "Agile Estimating and Planning" is considered the seminal book on this topic.
Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
Ilja,

Thanks for that response. I'm actually currently reading that book (almost finished too). I like to get other points of view too and you've really helped with that.

Thanks,
Jeff
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Frankly, I haven't yet read that book. So, does it look like I'm disagreeing with that Mike writes?
Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
He doesn't get into the details of some specific amount of time spent up front doing requirements analysis, since it is going to vary with the scope of the project. I think the general idea is to do enough analysis (and product backlog development) to at least get a rough scope the project, which would go along with your thoughts of wide but not deep. Since agile is so welcoming of change, there is no sense in trying to develop a very detailed set of requirements up front since you're probably wasting a lot of time.

One thing that a lot of software books really stress is that the quality of the product with respect to the customer's expectations is really the most important thing. Sure, it might be a little late, but most customers would probably rather have late and right than on time and not so right. So, make a rough estimate up front, refine it as you go along, but just keep the customer in the loop so there are no big surprises at the end.
[ March 05, 2008: Message edited by: Jeff Storey ]
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You might want to read my articles on initial requirements envisioning and initial architecture envisioning to get a handle on how much up-front modeling you might want to do.

- 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>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Pre-Development Planning and Architecture