Re: [AM] Why Traceability?
Brad Appleton <[email protected]> Tue, 16 Mar 2004 15:35:21 -0600
| Newsgroups | gmane.comp.programming.modeling.agile |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Mar 16, 2004 at 09:41:06AM -0500, Paul Oldfield wrote: > <rant mode> > Of all the people that quoted Impact Assessment as the > reason, I have yet to find a credible explanation unless > we assume a level of incompetence in the developers of > the existing code that would surely render any traceability > information worthless. I don't believe so. I believe the assumption being made is that you have a single, small, colocated team and a small enough system (under a million lines of code) that people can reasonably wrap their brains around the whole domain model. And impact analysis is often about doing enough analysis in order to find out whom to communicate with in order to obtain an estimate (as opposed to doing the estimate itself). See my previous post on this thread for more details. People simply have limits to the quantity of complexity they can effectively deal with - thats a fact rather than an attack on competence. So the main ways we know of are to strip away what you can live without, and then if the rest is still too complex, either "divide & conquer" or "conquer & divide". "Divide & Conquer" parcels the complexity across multiple teams, organizations, phases, projects, products, etc. And then pays the communication and coordination price for being less able to see the forest for the trees. "Conquer & Divide" (as XP has sometimes been described) parcels the complexity by managing its scope, and the granularity of changes/requests/iterations/releases by keeping them as small and simple and fine-grained as possible for the current "timebox" and save the rest for subsequent reprioritization and feedback adjustment/correction. Instead of fragmenting the people and the communication it fragments system size/scope and grows it in a piecemeal "emergent" fashion based on tight-feedback of small chunks so that the size and scope of the people doing the work can be kept simple. Instead of dividing up the solution over people using a "master plan", Agile prefers dividing up the problem over time using "organic growth". It's a very big shift in mind-set for some folks to make, and very scary leap at that. -- Brad Appleton <[email protected]> www.bradapp.net Software CM Patterns (www.scmpatterns.com) Effective Teamwork, Practical Integration "And miles to go before I sleep." -- Robert Frost For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com --^---------------------------------------------------------------- This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h Or send an email to: [email protected] For Topica's complete suite of email marketing solutions visit: http://www.topica.com/?p=TEXFOOTER --^----------------------------------------------------------------