Nội dung

StoryTag This is a mixed-case identifier for the story. Giving a handle to the story simplifies communication about it. In my experience, customers tend to have trouble filling in this field in the beginning. Programmers are used to naming things (subroutines, modules, etc.), and they may be able to help the customer choose appropriate story tags. Release The date or name of the release. We use this field loosely to categorize stories by release or project. We couldn’t predict when CloseChase would be done, so we just put it in the Misc category. Some teams work on several projects simultaneously, and this field helps keep the story cards organized. Priority After the customer physically orders the story cards, she writes their numeric priority in this field. The numbering scheme is arbitrary. Sometimes you need to insert a story card in the middle of a sequence. We add a letter, for example, 5a, or use a dotted decimal notation, 5.1. If you drop the story cards, it’s important to be able to get them back in priority order. Author The person who wrote the story. You then know whom to ask for the details. on The date the story was written. Accepted The date the story’s implementation is accepted by the customer. We do this at the start of every planning game before we get into the new stories. This helps remind the customer what has just been accomplished, and, sometimes, lets the customer catch incomplete stories. Description A few sentences and/or pictures explaining the requirement. Be brief. If the description isn’t clear, rip up the card and start over. This is the most important field, so you may want to fill it in first. See examples in Stories. Estimate The programmers write their best guess for the implementation time. See discussion about the time scale in Estimation. Considerations The programmers list the implementation risks and prerequisites in this section. This gives the customer more information about the confidence of the estimate and helps her order dependent Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 25 stories. Don’t implement the story here. It’s tempting to write pseudocode or to outline the design. Save the design for when you are in front of a computer with your programming partner. Task The list of activities required to implement the story. If the list of tasks grows to more than fits in a few lines, you probably need to split the story. The original story estimate is probably wrong, too. We try to avoid large, complex stories to ensure the software pipeline stays full, and XP’s many feedback loops remain active. This field is filled in during iteration planning, which is covered in Iteration Planning. Who The person who is responsible for this task. Sometimes we add the partner who helped implement the task. It can be useful when trying to remember why the code was written in a particular way. Est. The estimate for this task. Done The date the task is finished. This field can also be used to record the actual time to implement the task. We use it to help audit our billable hours. Acceptance Test This field reminds everybody that stories should have acceptance tests. Ideally, the customer should be responsible for this task, but a programmer probably ends up doing most of the work. See Acceptance Testing for more detail. 4.6 Dead Wood One important characteristic of story cards is their physical implementation. They are real dead plant matter. You write on them with ink, not electrons. PDAs and laptops are not recommended for planning meetings.3 The planning game is an interpersonal communication process. Story cards are a simple communication medium, which enables people to have as much face time as possible. You can read the cards from any angle, in almost any lighting condition. 3 XP assumes the entire team, including the customer, share the same office. If the customer or part of the team are not colocated, you may want to scan your story cards after the planning game and store them in the collective repository. I’m not a fan of purely electronic story cards, but some people like them. As with all things XP, try it by the book and then season to your taste. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 26 The stories listed so far have been text. Sometimes text won’t do. Paper is also an excellent medium for creating pictures on-the-fly. Here’s another example that demonstrates the versatility of story cards to capture the story: PaymentsInFiscalYear Story Card And, here’s the final user interface: PaymentsInFiscalYear User Interface The simple picture was enough to get the point across.4 4 Cards are context sensitive, so you may not understand the details of the PaymentsInFiscalYear story or implementation. The point is to demonstrate how little information you need on a story card, and how closely a quick sketch matches the final implementation. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 27 4.7 Estimation After a customer completes her portion of the story card, the programmers can estimate its implementation, and note any special considerations, such as, new hardware requirements or prerequisite stories. Estimation is an art, where consistency is much more important than precision or accuracy. The customer uses them to assess the relative cost of stories to aid prioritization. Programmers use estimates to compute and compare velocities (velocity is the sum of estimates for an iteration–see Velocity for details). Stories are estimated in ideal programming days, not real-time. It’s hard enough to forecast a story’s implementation without considering other factors such as, hardware failures, sick time, or activation of military reservists. Not to mention unforeseeable refactorings required to accommodate the implementation or changes requested by the customer as the implementation evolves. Ideal day are the way we avoid thinking about such factors that we can neither influence nor estimate. Don’t be afraid of making incorrect estimates. By definition, estimates are forecasts made with incomplete information. You should be concerned when estimates end up matching reality exactly, because it’s likely due to the effects of Parkinson’s Law: work expands so as to fill the time available for its completion. Plan-driven methodologies often succumb to Parkinson’s Law. Programmers are rewarded for making or beating their estimates. Over-estimation is a great way to make sure this happens. In XP, if you over-esimate, you simply get more work to do. You don’t get to go home early, because the length of an iteration is measured in real-time, not ideal time. There is always more business value to add, and the code can always be improved through refactoring. Other XP feedback mechanisms, such as, small releases, pair programming, and continuous integration, also help to combat Parkinson’s Law. So don’t worry about Parkinson, the weather, or politics. Just write your best guess as to how many ideal days the story will take to implement, and move on to the next card. 4.8 Easing Estimation Sometimes you can’t come up with a number that you have any confidence in. The typical problem is that the story is too large, and it needs to be split up. As a rule of thumb if the story comprises more than one week’s Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 28 worth of work, decompose it into smaller stories. For example, this is a story that was too large for me to estimate: Create a web site with the ability to upload Microsoft Word documents by me and viewed by anybody. The documents are categorized by visitor (consumer, broker, etc.). With the help of a customer, we split the story into four smaller, more easily estimable stories: • Create the web site home page and navigation scheme. • Implement pages with Word document links and hand-installed documents. • Allow site administrators to login. • Implement upload page for Word documents accessible only by administrators. We were able to deliver business value on the first story. After the second story, the customer had a functional site from the end-user perspective. We were able to populate the site using non-web-based file transfer tools. The last two stories gave the customer full administrative control of the site, which is business value, but not as important as having a site at all. Most stories can be broken down this way. It’s quite similar to decomposing a story into tasks (see Iteration Planning). 4.9 Spike Solutions Some stories defy estimation or decomposition. The programmers knows so little about the problem domain that they may not even know if it is feasible to implement the story. Some fundamental research is required. In XP, we call this a spike solution. Two programmers prototype, mockup, or just explore the problem space in detail for a short time. System integration is often important to spike. There are usually so many variables that are out of the programmers’ control. For example, one project we were involved in required us to download transactions from financial websites. Our first attempt was to use the Open Financial Exchange (OFX) protocol. It turned out that OFX is not very open, and we hit a non-technical roadblock. In parallel with talking to the OFX consortium, we also spiked a web crawling solution for downloading transactions from Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 29 financial websites. We quickly learned that the algorithmic complexity was not in the transaction download component but in the backend–integrating the transactions into an existing accounting database. This was an unexpected and important discovery. The spike solution gave us the information we needed to estimate our stories. The spike solution should be estimated, too. This caps the time the customer must pay for experimentation. The goal is to determine feasibility and cost, not to implement a fully working solution. Spike solutions are thrown away. The result of a spike solution is a new story or stories, which can be estimated with confidence. 4.10 Prioritization Once the stories that can be estimated have been estimated, the customer groups and prioritizes them. The physical ordering process requires a large table so the customer can see as many of the cards as possible. The customer groups the stories in two piles: this release and subsequent releases. The size of the release depends on the customer, although you should avoid releases exceeding a few months. The team will divide this release into iterations that last a few weeks at most (see Iteration Planning). From the customer’s perspective each iteration is a partial but usable software distribution. The size of a release is therefore a bit of a fuzzy concept. The customer may choose to stop work on a release before all the stories are implemented, and shall still have a working system albeit with fewer features than planned. This is why prioritization is so important, and can’t be left to the programmers. The customer should see a continuous flow of software distributions in order of decreasing business value. XP eschews big bang releases. A working end-to-end system is available very early on in the implementation of a release plan. For this reason, programmers should avoid creating too many dependencies between stories. It’s all too easy to control the prioritization through unnecessary linking. If you find yourself saying, “We need to build the infrastructure for this story.” Remember XP’s guideline: you aren’t going to need it (YAGNI). Infrastructure evolves from refactoring as you discover what parts of the system need it. When the planning game is over put the subsequent releases pile into storage until the next planning game. The team may get done early in which case pull them out mid-release and add enough stories to meet the Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 30 deadline for the current release. The nice thing with XP is that you can add or rearrange stories at any time. The stories that are already implemented have already been tested within the context of a working system. There’s no end of release panic to integrate the parts into the whole. Indeed, the system probably is already in use well before the end of the release. 4.11 All the Facts The customer’s job is hard. She is managing other factors besides implemention complexity, such as, time to market and resource acquisition. To simplify the planning process, she has to have all the data from the programmers. Any work which consumes time and resources needs to be on the planning game table. The considerations of stories may be significant. If the story requires a relational database to be implemented, you need to make this clear. Or, it may be obvious that a story requires major code restructuring. If so, get it on a card. While you’re coding, you’ll notice problems. You may have to copy-andpaste, because the refactoring required to make the pasted code reusable may be lengthy.5 Write down the problem on a story card and bring it to the next planning game or iteration planning meeting. The customer and management are made aware of internal quality issues before they get out of control. 4.12 Small Releases Release planning is the way we communicate business objectives to the programmers and enable programmers to communicate technical constraints. The planning game is a simple forum for effective communication that relies on interactive feedback. By limiting the length of releases to one or two months, we limit the length of planning meetings. This means we have fewer objectives to discuss. It is easy to maintain the cohesion of small releases and to identify dependencies and other potential problems. XP simplifies plan digestion by encouraging us to take a small bite and chew it thoroughly before taking the next bite. 5 Lengthy to me means anything that takes an hour or more. You may have completed several refactorings already, and any more will blow your budget. For a complete discussion on refactoring, see Refactoring. Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 31 Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 32 Chapter 5 Iteration Planning Plans are useless, but planning is indispensable. – Dwight D. Eisenhower An iteration adds function to a system without breaking it. The new features are delivered to the customer in a complete software distribution. This way the customer can try out the story implementations, and the programmers can get feedback on the system every few weeks, before the entire release is implemented. While release planning sets the pace for the customer, iterations are the heartbeat of the system’s implementation. By distributing the software on a fixed schedule, typically from one to three weeks, the programmers stay focused on delivering complete stories. This avoids the situation where the system remains “95% done” until the entire release has been implemented. XP programmers complete the most important story first before moving on to the next one. This chapter covers dividing stories into tasks during the iteration planning meeting, estimating tasks, grouping tasks into iterations, and tracking team and individual velocity to schedule the next iteration’s work. 5.1 Tasks A task is the basic unit of work of an iteration. The stories are broken down into a list of tasks during the iteration planning meeting. For example, here are the tasks for two of the stories from Release Planning: PaymentsInFiscalYear • Mockup report. 33 • Implement year at a glance widget. • Implement data model and report. • Acceptance test: validate payments in months for members. CloseChase • Compare rates and services at local banks. • Open new account. • Move automatic payments (FedEx, EarthLink) • After last check clears, transfer remaining funds. • Acceptance test: verify account is closed and automatic payments working. For reasons of simplicity, I write the tasks directly on the bottom of the story cards. This keeps the motivation for the work (the story) and the list of work items on one piece of paper. This helps me stay focused on the trees without getting lost in the forest. Alternatively, you might create separate task cards, one for each work item. This allows you to divide up the work for an individual story among several programmers. If you tend towards larger, multi-week stories, task cards are probably the way to go. 5.2 The Meeting Iteration planning involves the entire team. Somebody reads the stories aloud, and everybody contributes to identifying the tasks, which are written on whiteboards or flip charts for all to see. Another person writes the tasks down on the cards once everyone agrees they are correct. The meeting is a time for group design discussions. It isn’t always obvious what tasks are required to implement a story. While ad hoc design discussions pop up during programming, iteration planning is a time for the whole team to discuss the system’s implementation. You might realize that a global refactorings need scheduling. This may add dependencies and possibly a new story for the customer to prioritize. After all the tasks are listed on the board, people commit to implementing them. Individuals take the cards and estimate the tasks they are planning to implement. As with stories, estimate in ideal programming days. Everybody’s ideal timescale is different, don’t expect the task and story estimates to add up. If a task is difficult to estimate, ask for help. Others may have a better feeling for the problem and/or implementation. Sometimes a task is too Copyright c 2004 Robert Nagler All rights reserved nagler@extremeperl.org 34