Timeboxing For Top Team Performance

　　Maintaining Quality

If you're in a stable state, you have a much better chance of controlling quality. A couple of basic metrics will demonstrate stability and dramatically improve your ability to deliver a quality product as you reach the end of a timebox. You need Defects Discovered, and Defects Corrected for each time period (days or weeks.) Figure 4 is a graph of these two measures; you can also derive (and graph) other important measures such as Defects Remaining and Mean Time to Repair.

　　Who does this defect tracking and graphing? According to McCarthy, Microsoft has a ratio of one Quality Assurance (QA) person for every two developers on the team. This graph is a great way for QA to highlight the coordination between these two factions on your team.

　　You can timebox anything

So far, we've been talking about timeboxing for product delivery. As I began studying the literature on timeboxing (see sidebar) I realized that I had been doing a form of timeboxing for over a decade. Training companies frequently have a set format for their courses; for example, all of their courses may be four days long. To build a course, you start with an overall four-day timebox, and break that down into smaller timeboxes to fit within breaks and lunches. That realization led me to try timeboxing in our methodology experiments at CASELab. We put every activity into a one-to two-hour timebox and gave the participants an opportunity to expand the box “a little” but not more than 20%.

　　We found that you can timebox any development activity, from requirements definition, to system design, to paper prototyping your screens. You define a time interval, and work within it. When you run out of time, you stop, and move on. Of course, you have to be reasonable; you can't do ten days of coding in a two-day timebox; but you actually might able to build a prototype in three days. You won't know until you try.

　　Stop apologizing!

Early in my career, as a young IBM Systems Engineer, I was working on a SPOOLing package with Bill Gunther, an old software hand from Northrop Corporation. I suggested that, for some good reasons, we might be able to slip the package we were working on a couple of weeks from its scheduled delivery date.

　　“NO!!” he said, vehemently. “People won't remember why we were late; they will only remember that we were late.”

　　That's still true; it's all too easy to get a reputation for always being late. If schedule is important in your software shop, you CAN be on time, if you'll simply manage the iron triangle properly. And timeboxing is a good way to do that.

　　## Go to top Go to sidebar
　　FIGURES

　　

Figure 1. The Iron Triangle

更多軟考資料請訪問：考試吧軟件水平考試欄目

希望與更多網(wǎng)友交流，請進入考試吧軟件水平考試論壇