Timeboxing grabs that problem by the horns and wrestles it to the ground. (Forgive me -- I'm from Colorado!) We set an end time -- that is, a timebox -- and then adjust our scope so that we deliver what we can within the time allotted. This presumes that the schedule is the most important aspect of the project, and frequently it is. Now there are other aspects, including resources, development skill, scope and quality. Let's look at these aspects realistically, with an eye to managing them so that we look good!
The “Iron Triangle”
On a given project, resources are usually fixed; and unless you believe in the Mongolian Horde Approach (hire a hundred people and hope some of them are good) the best team is a small one. Once you've put that team together, you've established their capability, at least in the short run. Now you have three aspects to manage, as shown in Figure 1.
Schedule: The time when the software product is due.
Scope: The functions and features delivered in the software product.
Quality: The absence of defects in the product.
I call these three “The Iron Triangle” because they have an immutable relationship. For example:
1. If we increase the scope, the schedule must grow, or the quality must decline.
2. If we shorten the schedule, we must decrease the scope or deliver with more defects.
The best timeboxing strategy holds quality constant and reduces scope to meet a schedule. Reducing scope flies in the face of what I call “The World's Greatest Program” syndrome -- the tendency on the part of developers to put every great feature into the first release, even if it causes us to be late. (Roland Racko calls this creeping or galloping elegance.) The customer always wants those features; they just don't understand how much it will cost them. I'd like to acquaint you with the facts, so you can feel good about leaving some features out when you're approaching the end of your timebox.
The last features
Those latest and greatest features cost more than you expect, and here's why. Remember the 90:90 rule:
The first 90% of a system takes 90% of the time:
The last 10% takes the other 90% of the time!
That sounds like a joke, but Figure 2 shows why it's true. As we approach 100% complete, our progress slows down drastically. This is because we're making tough decisions in the face of uncertainty. Moreover, they're not very good decisions. We will probably have to make many of them over again, when we have more information. This last 10% also accounts for much of the arguing and fighting that goes on in a project. Timeboxing forces us to forgo these last features, but it also lets us avoid most of the conflict that goes with them.
Pareto's Law -- the old “80:20 rule” -- gives us another justification for procrastinating on those last features. In the systems world, it predicts that:
20% of the system will give us 80% of the payback.
Now, in reality, this 20% only applies to a particular set of users. If we have a diverse set of users, we will have to give each group a different 20%, but it's reasonable to expect that we can please the vast majority of our users with 80-90% of the features. Sooner or later, we're going to deliver those last features, but not right now!
更多軟考資料請(qǐng)?jiān)L問(wèn)：考試吧軟件水平考試欄目
希望與更多網(wǎng)友交流，請(qǐng)進(jìn)入考試吧軟件水平考試論壇
| 北京 | 天津 | 上海 | 江蘇 | 山東 |
| 安徽 | 浙江 | 江西 | 福建 | 深圳 |
| 廣東 | 河北 | 湖南 | 廣西 | 河南 |
| 海南 | 湖北 | 四川 | 重慶 | 云南 |
| 貴州 | 西藏 | 新疆 | 陜西 | 山西 |
| 寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
| 黑龍江 | 內(nèi)蒙古 |
