Xp Narrative

news:comp.object just keeps begin' for that evangelist spirit:

On Tue, 4 Sep 2001 17:18:42 -0400, "John A. Byerly" <jbyerly@ess-quality_remove.com> wrote:

 >Now that the dream is over, here is how it usually takes place.  We step out
 >along the dream path, then some manager figures out that eliminating code 
 >reviews would shorten the schedule by 3 weeks, and eliminating design
 >reviews would save another 3 weeks.  With the reviews gone, and with
 >schedule pressures mounting, half the developers decide that they can just
 >start coding, and to heck with this design stuff (they didn't really
 >understand it anyway).  Finally, enough code is written to start
 >integrating.  Except, I didn't realize that we were using callbacks.  I used
 >the Observer pattern instead.  After all, we agreed that I would be
 >notified, I guess we really never settled on how.  And so on.
 >
 >What usually happens is that the schedule is shortenend on paper (which is
 >what counts to the managers) but is increased many times in actuality during
 >integration and test.  Then the course of action is to start cutting out
 >features so the delivery schedule (the third re-estimate, not the original)
 >can be met.
 >
 >You know, this would all be rather humorous if it weren't true.

It answers it very well, thank you. In essense you are saying that you work in a typical organization. That you wish you could do lots of up-front work, but that you're organization doesn't have the patience to let you do it. They seem to be driven more by dates than by rational thought. No wonder you wish you had time to do the analysis and design up front.

Let me paint you a different story.

Every TwoWeeks you and your team deliver new features to your business. They get to choose which new features they are; and you get to tell them how many new features you can do in two weeks. They see progress every two weeks. Not only that, its the progress that they want to see.

[ProjectVelocity, UserStories]

The schedule belongs to your managers. They see how much you get done every two weeks; and they order the features such that you get the most important things done first.

[PlanningGame, CustomerBillOfRights]

Each iteration you and your team work together in the same room. You work in pairs; and the pairs work three to a table. Perhaps there are two or even three tables in the room. Every day the entire team meets for thirty minutes to plan the day's activities. If someone is going to use an Observer, you're likely to find out about it at that meeting.

[AllEngineersInOneRoom, PairProgramming]

Pairs switch off twice per day. Over the course of two weeks, everybody works with everyone else on everything. Nobody owns any particular module, everybody is reasonably familiar with the whole of the code base.

[PairPromiscuously, SharedCodeOwnership?]

Integration occurs several times per day. There is one code baseline supported by a bevy of unit and acceptance tests. Every couple of hours each pair checks in their changes, makes any merges necessary, and makes sure all the tests continue to pass.

[TestInfected, CodeUnitTestFirst, AcceptanceTests, ContinuousIntegration]

No integration woes, no "callbacks instead of Observer" woes, continuous reviews, continuous design, managers who know the status of the project in detail, and who manage the schedule by selecting features.

[TestDrivenDesign]

--RobertCecilMartin

---

CategoryExtremeProgramming