The purpose here is to show you how to produce a product, the XML Notepad, starting from nothing, delivering capability in small pieces, and winding up with a useful product and maintainable code. And to do this in a book that can be shipped on a suitable date. So I submitted the above stories to my editors and had them wear the customer hat this time. As a first cut, they selected the following ones for implementation:
File Operations: 2 days
File Operations, Recent Files: 1 day
WYSIWYG Display: 2 days
Validity Indicator: 1 day
Ordered List: 1 or 2 days
Unordered List: 1 or 2 days
Proper Menus and Shortcuts: 2 days
Copy Cut Paste: 2 days
Section Handling: 3 days
Change Enclosing Tag: 2 days
Insert Tag Around Selection: 2 days
User-Defined Tags: 3 days
Tabbing: 2 days
Dropped were these:
Insert Starting XML: 1 day
Insert User-Defined Starting XML: 2 days
Unit Testing Page: 4 days
Book Reviews: 6 days
XSLT to HTML: 3 days
Wiki/Weblog: 4 days
Now, this list isnt final. First, the customers arent aware yet that some kind of proper starting XML is required in order for WYSIWYG to work. I didnt mention thatin fact, I didnt think of itwhen I proposed the story. So well probably have to do that one. On the other hand, it probably isnt really a day. I just didnt want to estimate any fractional days. Most likely Ill throw that feature in when the time comes, at a cost of a few lines of code and a few paragraphs in the relevant chapter. Watch for it.
Second, we dont know what my real velocity of implementation will be. I tried to make these estimates in elapsed time. But thats difficult, because I need to take into account my other responsibilities, including consulting time and the like. (Thats how I make my living, after all.) The translation from my 2-day estimate to when a feature and its corresponding chapter content is done depends on how good my estimate is, but it also depends on when I get started and how many interruptions I have in the doing. Furthermore, each chapter already written is undergoing improvement and refinement for the book, and thats taking about a half day per chapter. All these things add up to say that we might be able to get more done, if my estimates were pessimistic, or less done, if they were optimistic or something happens to slow me down. Based on what really happens, well refine our choices for the book.
Lets emphasize that. Our real purpose here is to examine how to produce running tested software in a situation where we have a lot of learning to do, both about the application and about the environment in which were working. So while I have a personal desire to see all those stories get done, they wont fit in the book. In fact, there are many additional articles already written, about topics that wont fit in the book. What will fit in the book, Im sure, are as many lessons as I can find about how I work. Take the ones that work for you, and build them into your own approach.
One last thing: Im going to miss some of those dropped stories. I am famously poor at updating my unit testing framework page that tells people what unit testing software is available. I had hoped that doing this story would make it easier to update and keep it more current. I hate to lose that feature. Similarly with book reviews. Id like to do more, but they are very time-consuming to write and to set up on the Web site. I had hoped to improve that process. The XSLT to HTML story might have been interesting to readers of the book, because XSLT is an important technology in the XML family and you might like to know more about how to use it. And it would be valuable to me, because it would let me automate the Web site production all in Microsoft .NET instead of the current mix of .NET and Ruby. Finally, the Wiki/Weblog story would show how to build a wikia Web site that can be enhanced by anyone and to merge it with a Web log. This story, fleshed out, would provide a very nice basis for a team to use to record and communicate their work as they go along.
So well miss having these features. Every project is like this: things one would very much like to do cannot be done because resources and time are finite. The advantage to the process were describing here is that it makes the determination of what we will do and what we will defer , explicit and rather easy to do.
What we have done here is a version of the Extreme Programming Release Plan. We look at all the stories, estimate them, and see which ones to do firstthat is, before the project deadline. There is also an XP plan called the Iteration Plan, where we plan the work for a week or so. Im not using that planning step in creating this book, although in retrospect, it might have been helpful. Had I done iteration-level planning, it might have helped me to stay on track better and helped me to stay more motivated. Things have turned out reasonably well, but I could have been more effective and an Iteration Planning practice might have helped me.
We might revise this plan. We may remove more features, add some of these dropped ones back in, or add new ones altogether. Future chapters will show the results of executing the plan and of revising it if need be. The Planning Game is done for now. Its time to get back to programming.