eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers [Electronic resources] نسخه متنی

Problem Breakdown Exercise

Hopefully you have a good idea of what we''re aiming for now, so let''s try to tackle a slightly more complex problem. This problem may still seem trivial in comparison to many real-world problems you will encounter, but we have to start somewhere, and this should give you at least introduce you to the concept of breaking down customer stories into tasks.

Exercise 3-1: Defining the Story

The first thing to happen is that the customer will provide the development team with a story. A story is a simple description of a piece of functionality that the system needs to perform. In a full XP environment, the team will play the planning game. This involves the customer writing a number of stories on cards (usually index cards). Then the development team will place rough time estimates on each story. The customer then decides which stories to do first. The planning game provides a long-term view of how the project could pan out eventually, but also includes short-term goals for the next few weeks. By repeating the planning game every few weeks, the accuracy of the estimates should get better and you enable the customer to choose the direction of the project on a smaller scale. Figure 3-1 shows a sample story card.

A story can be considered similar (and are often compared) to a UML Use Case. The story should not explain all the details of the functionality. A story provides a rough idea of the scope. Stories are promises to hold conversations between the developers and the customer. This conversation occurs when the time comes to begin implementing the story. The conversation enables the developers to explore exactly what tasks will have to be carried out to satisfy the customer that the functionality described in the story is finished.

The best way to start this is to begin a conversation with your customer. Let''s see how our team does it:

Eddie: What would you like this software to do?

Chris: I need to be able to display the time in different places in the world on my desktop.

Pete: You mean you want clocks, one for each place in the world?

Chris: Yes, but I want to be able to choose which places to display the time for, not just have a clock for every time zone that exists.

Eddie: Okay, how about we start with simply doing one clock for one time zone and then build the system from there.

Chris: Um... well, I want to choose the time zone and have multiple clocks.

Eddie: Yes, I understand that, but we want to get some core functionality for you to see as soon as possible, and then we can add to the software from there.

Chris: Okay, as long as you are aware that we will need more than one clock.

Eddie: Sure, so what shall we put down as the first story? How about "Select time zone to display?"

Chris: Sounds good. I also want to be able to put my own label next to the clock, so if I select GMT, I want to be able to label it as London.

Pete: Fine, so the second story could be "Add custom label to selected time zone?"

Chris: Yes that''s right; so what next? I can select a time zone and associate a label with it, but I need to be able to see the clock. Do you need a story for displaying the clock?

Eddie: You''re right; how do you want it displayed? I assume that just a digital text output is okay? Something like "Time in London is: 14:23." How does that sound?

Chris: No, no, no! You''ve misunderstood me! I need to see a clock. You know, with hands and a round face! Like this. (The customer grabs a scrap of paper and scribbles the picture shown in Figure 3-2.)

Pete: Panic! That wasn''t what I was thinking.

Eddie:Sure, we can do that, but it will take a bit more work.

Chris:How much work? Doesn''t sound that hard to me.

Eddie: Well let''s break it down and I''ll tell you how long it will take.

Chris: I don''t have time for all this; I just want a clock on my screen for different places in the world!

Eddie: Okay, we''ll get back to you soon with some estimates for timeframes.

Chris: Great, when?

Eddie: In the next hour.

Chris: Oh okay, that''s not so bad.

Some of this conversation probably sounds familiar. It is not uncommon for customers (managers) to be short of time and want answers on the spot. As developers, we need to respect that they have other pressures and do what we can to help them. It is important not to let their stress get to us and force us to make on-the-spot decisions or provide time estimates based on nothing more than numbers plucked out of the air. Notice how Eddie, who has more experience, steers the conversation. Eddie is guiding both Pete and Chris through the process in a way that gives them the best chance of succeeding.

Exercise 3-2: Breaking Down the Stories into Small Subtasks

From the preceding conversation, Eddie and Pete can draw the following story cards:

Allow the user to select a time zone.









Allow the user to associate a custom label with the time zone selected.









Draw a clock for the time zone and a label for it.

From these stories, could you give reasonable time estimates? For the first two, you may be able to get reasonably close (apart from one issue). The third one is a little trickier because the clock has to show the correct time and be updated as the time changes. Let''s see what Eddie and Pete come up with when they break these stories down.

Story 1: Allow User to Select a Time Zone

Task

Estimated Time

Get a list of time zones from the operating system

?

Test to check selected time zone is valid

15 minutes

Test to validate selected time zone is stored in memory

15 minutes

Test to validate correct behavior when invalid time zone selected

15 minutes

User interface to allow user to select a time zone from the list

10 minutes

Check code into source control

5 minutes

Eddie has put a question mark next to the first task because neither he nor Pete are sure what is involved in getting all the time zones from the operating system. They know the time zones must be there because when they set the Windows clock they can select from a list of available time zones. To find out where this list is stored, they need to carry out some investigation and experimentation.

In XP terminology, this is called doing a spike or spiking. This spike will be another task. Because they don''t know how long the spike will take, they set an upper limit to the amount of time spent spiking before providing feedback to the customer. Eddie and Pete now have a list of tasks that looks like this:

Task

Estimated Time

Spike to discover how OS stores time zone information

4 hours

Get a list of time zones from the operating system

? (based on outcome of spike)

Test to check selected time zone is valid

10 minutes

Test to validate selected time zone is stored in memory

10 minutes

Test to test behavior when invalid time zone selected

10 minutes

User interface to allow user to select a time zone from the list

10 minutes

Check code into source control

5 minutes

They can now break down the next story.

Story 2: Allow User to Associate a Custom Label with the Time Zone Selected

Task

Estimated Time

Test to validate correct behavior when label is blank

10 minutes

Test to check label is stored and associated with time zone

10 minutes

Test to check label with non text characters is valid

10 minutes

User Interface to allow user to enter label for selected time zone

15 minutes

Check code into source control and integrate with existing code

5 minutes

Finally, they can tackle the third story: Draw a clock for the time zone and a label for it. Eddie thinks this story is too big, so he proposes they break it down into smaller stories:

3.1 Draw clock face

3.2 Draw label next to clock face

3.3 Draw clock hands

3.4 Update clock hands to reflect current time in selected time zone

3.5 As time changes, redraw clock hands to reflect current time in selected time zone

From these five stories, they can create a set of tasks for which it should be reasonably easy to provide time estimates. The tasks for each story are estimated as follows.

Story 3.1: Draw Clock Face

Task

Estimated Time

Code to draw circle

15 minutes

Code to draw 12 marks to indicate time intervals

15 minutes

Check code into source control and integrate with existing code

5 minutes

Story 3.2: Draw Label Next to Clock Face

Task

Estimated Time

Code to calculate offset from clock face to draw label

15 minutes

Code to draw label

10 minutes

Check code into source control and integrate with existing code

5 minutes

Story 3.3: Draw Clock Hands

Task

Estimated Time

Code to get time

10 minutes

Code to draw hour hand

15 minutes

Code to draw minute hand

10 minutes

Check code into source control and integrate with existing code

5 minutes

Story 3.4: Update Clock Hands to Reflect Current Time in Selected Time Zone

Task

Estimated Time

Test converting current time when time zone is in summer time savings

20 minutes

Test converting current time when time zone is in standard time

20 minutes

Code to draw clock hands based on converted time (dependent on story 3.3)

10 minutes

Check code into source control and integrate with existing code

5 minutes

Story 3.5: As Time Changes, Redraw Clock Hands to Reflect Current Time in Selected Time Zone

Task

Estimated Time

Thread function which updates clock hands based on current time (dependant on story 3.4)

20 minutes

Check code into source control and integrate with existing code

5 minutes

Based on this task breakdown, Eddie and Pete can get back to Chris, their customer, with some confidence in the estimated timeframes. The timeframes are still estimates, but the developers are happier that they have thought about the job and the tasks to complete. They can also explain that the first thing they need to do is spend half a day understanding how time zone information is stored in the operating system. When they know how the time zones are stored, they can use them in the program.

As you can see, the estimated times for each task are small; all of them except the spike are less than 30 minutes. This is a good indicator that they have got their tasks to the correct level of granularity. If you have several tasks that are four or five hours long, you should think harder about how to break them down. For me, the spike task is still cause for concern. After the customer has had time to review the task breakdowns and give the go ahead on the project, I would break down the spike task further. Let''s see how Eddie and Pete go about doing this.

Exercise 3-3: Breaking Down the Subtasks Even Further

To break down the spike task, Eddie and Pete need to think about the approach to take to find the information they are after. There are some likely candidates to find out how they can access the time zone information:

.NET Framework support









Win32 API









Work out how the date and time Control Panel applet works









COM controls









Windows Registry

Based on the fact they have given themselves 4 hours to come up with some answers, Eddie suggests spending no longer than 45 minutes investigating each area. Because both he and Pete are working on the project, they could each take a different area to investigate. This gives Eddie and Pete a task list for the spiking tasks.

Spiking Tasks

Task

Estimated Time

Investigate .NET support for time zones

45 minutes

Investigate Win32 support for time zones

45 minutes

Work out how the date and time Control Panel applet gets it time zone data

45 minutes

Investigate whether there are any COM controls that provide access to time zone data

45 minutes

Explore the Registry for time zone data

45 minutes

If they come to a dead end before 45 minutes, they can stop and move on to the next area of investigation. Likewise, if they find a mechanism that provides access to the time zone data, they don''t need to continue with any of the other spiking tasks.

Eddie and Pete are now ready to start this project with some very tightly defined tasks and outcomes at the end of each task. This tight definition of tasks enables them to move at a fast and furious pace during the working day.