文章轉自 http://blog.csdn.net/zinking3/article/details/15408225，有些圖片不能顯示，重新配上新圖

Joel on Software

Evidence Based Scheduling

基於事實證據的進度計劃

by Joel Spolsky Friday, October 26, 2007

Softwaredevelopers don’t really like to make schedules. Usually, they try to get awaywithout one. “It’ll be done when it’s done!” they say, expecting that such abrave, funny zinger will reduce their boss to a fit of giggles, and in theensuing joviality, the schedule will be forgotten.

軟體開發人員實在是不喜歡定計劃。他們通常會嘗試不做計劃。他們會說“做好的時候就做好了！”，期望這樣勇敢，幽默的臺詞會讓老闆付之一笑，在隨後的愉悅中，軟體計劃就被忘到一邊了。

Most of theschedules you do see are halfhearted attempts. They’re stored on a file sharesomewhere and completely forgotten. When these teams ship, two years late, thatweird guy with the file cabinet in his office brings the old printout to thepost mortem, and everyone has a good laugh. “Hey look! We allowed two weeks forrewriting from scratch in Ruby!”

你通常看見的計劃大都是漫不經心的產物。他們被存在某個共享的地方然後就完全被忘記了。當這些團隊兩年後釋出產品的時候，那個守著檔案櫃的怪人事後就從他的辦公室拿出了那份老的列印版，然後每個人都開始大笑。“嘿，看，我們當時居然允許花兩個禮拜時間用Ruby來重寫！”。

Hilarious! If you’re still inbusiness.

如果你還在做這事的話，那實在太滑稽了。

You want to bespending your time on things that get the most bang for the buck. And you can’tfigure out how much buck your bang is going to cost without knowing how longit’s going to take. When you have to decide between the “animated paperclip”feature and the “more financial functions” feature, you really need to know howmuch time each will take.

你肯定希望把時間花在最划算的事情上。然後如果你不知道你的事情要花多長時間的話，你肯定也不知道要花多少錢。當你要決定是做“動畫回形針”還是“更多的金融功能”特性的時候，你真的得搞清楚他們各要花多長時間。

Why won’tdevelopers make schedules? Two reasons. One: it’s a pain in the butt. Two:nobody believes the schedule is realistic. Why go to all the trouble of workingon a schedule if it’s not going to be right?

為什麼開發人員不定計劃？兩個原因。一：實在是太他媽痛苦了。 二：沒人會相信計劃是現實的。 如果計劃不正確的話那幹嘛還費那麼大力氣來做呢？。

Over the lastyear or so at Fog Creek we’ve been developing a system that’s so easy even ourgrouchiest developers are willing to go along with it. And as far as we cantell, it produces extremely reliable schedules. It’s called Evidence-BasedScheduling, or EBS. You gatherevidence, mostly from historical timesheetdata, that you feed back into your schedules. What you get is not just one shipdate: you get a confidence distribution curve, showing the probability that youwill ship on any given date. It looks like this:

在過去的一年多，在FogCreek公司我們開發了一個系統，這個系統是如此簡單易用以至於我們最愛抱怨的開發者都願意拿來使用。就目前為止，它產生的計劃還是非常靠譜的。我們把它叫做基於事實的計劃定製（EBS），你可以從歷史事件表裡蒐集事實然後將其反饋會計劃制定。你得到的不僅僅是一個釋出日期：你得到一個置信分佈曲線，該曲線顯示了你在任意給定日期交付的概率。看起來是這個樣子的。

The steeper thecurve, the more confident you are that the ship date is real.

曲線越是陡，你的釋出日期就越準確可信。

Here’s how you doit.

下面是如何來生成該曲線。

1)    Break ‘er down

2)   分解。

When I see aschedule measured in days, or even weeks, I know it’s not going to work. Youhave to break your schedule into very small tasks that can be measured in hours.Nothing longer than 16 hours.

當我看見以天甚至星期為單位制定的計劃時，我知道這肯定是不準確的。你需要把你的計劃分解成用小時衡量的小任務。 所有任務不得超過16小時。

This forces youto actually figure out what you are going to do. Write subroutine foo.Create this dialog box. Parse the Fizzbott file. Individual development tasksare easy to estimate, because you’ve written subroutines, created dialogs, andparsed files before.

這個過程會迫使你去搞清楚你將要做什麼。編寫子過程foo。建立這個對話方塊。傑西Fizzbott檔案。但一個的開發任務很容易估算，因為你以前寫過子過程，建立過對話方塊，以及解析過檔案。

If you aresloppy, and pick big three-week tasks (e.g., “Implement Ajax photo editor”),then you haven’t thought about what you are going to do. Indetail. Step by step. And when you haven’t thought about what you’re going todo, you can’t know how long it will take.

如果你很隨便，選擇了一個大的3個星期的任務（像，實現一個Ajax照片編輯器），那麼你還沒想清楚你要幹什麼。具體的，一步一步。而且如果你沒想清楚你要怎麼做，你就不可能知道要花多久。

Setting a 16-hourmaximum forces you to design the damn feature. If you have ahand-wavy three week feature called “Ajax photo editor” without a detaileddesign, I’m sorry to be the one to break it to you but you are officially doomed.You never thought about the steps it’s going to take and you’re sure to beforgetting a lot of them.

設定16個小時的上限就是為了迫使你去設計那個該死的功能。如果你掰掰手指頭就說有個三個禮拜的功能叫做“Ajax照片編輯器”而沒有詳細的設計，很抱歉我是那個打破你幻想的人，但客觀的說你肯定不能那樣。你從沒想過裡面的步驟，你肯定不會記得大部分這些步驟。

3)   Track elapsed time

4)   跟蹤花費時間。

It’s hard to getindividual estimates exactly right. How do you account for interruptions,unpredictable bugs, status meetings, and the semiannual Windows Tithe Day whenyou have to reinstall everything from scratch on your main development box?Heck, even without all that stuff, how can you tell exactly how long it’s goingto take to implement a given subroutine?

You can’t,really.

很難把每個任務都估算的絕對準確。你怎麼考慮哪些打斷，沒法預測的錯誤，狀態會議，以及每半年的Windows受難日（這天，你要重新安裝你的主開發伺服器上的所有東西）呢？見鬼，就是沒有這些東西，你又如何精確的估算你實現一個指定的子過程要花多長時間呢？

你真的沒辦法做到的。

So, keeptimesheets. Keep track of how long you spend working on each task. Then you cango back and see how long things took relative to the estimate. For eachdeveloper, you’ll be collecting data like this:

所以，做個時間表，記錄你在各項任務上花費的時間。然後你能回過去觀察每樣任務時間和預計相比花了多長時間。對每一個開發人員，你都要蒐集像這樣的資料：

Each point on thechart is one completed task, with the estimate and actual times for that task.When you divide estimate by actual, you getvelocity: how fast the taskwas done relative to estimate.

圖上的每個點都代表一個完成的任務，同時還有那項任務的實際和估計時間。如果你用實際時間處以估算時間你就得到了速度因子：相對於預期你完成任務的速度因子。

Over time, foreach developer, you’ll collect a history of velocities.

日復一日，對每一個開發人員，你都會獲得這樣的一個速度因子歷史。。

·   The mythical perfect estimator, who exists only in yourimagination, always gets every estimate exactly right. So their velocityhistory is {1, 1, 1, 1, 1, …}

·   那種神祕的完美估演算法，僅存在於想象當中，也就是每項估算都完全正確，因此他們的速度因子為{1,1,1,1,1,…}

·   A typical bad estimator has velocities all over themap, for example {0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0}

·   一個典型的壞的估算就是在圖中有著各種各樣的速度因子，例如{0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0}

·   Most estimators get the scale wrong but the relative estimatesright. Everything takes longer than expected, because the estimate didn’taccount for bug fixing, committee meetings, coffee breaks, and that crazy bosswho interrupts all the time. This common estimator has veryconsistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6,0.5, 0.6, 0.7, 0.6}

·   大多數的估算規模是錯誤的，但是相對估計是正確的。 所有的事情都比預計要花更多的時間，因為估算沒有考慮修正錯誤，委員會會議，咖啡休息然後還有那個總是來打斷的瘋子老闆。這種常見的估算者有著很穩定的速度因子，但他們都小於1.0 例如{0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7,0.6}。

As estimatorsgain more experience, their estimating skills improve. So throw away anyvelocities older than, say, six months.

隨著估算者獲得越來越多的經驗，他們的估算技能也慢慢改進。所以拋棄那些已經超過6個月的估算。

If you have a newestimator on your team, who doesn’t have a track record, assume the worst: givethem a fake history with a wide range of velocities, until they’ve finished ahalf-dozen real tasks.

如果你的團隊來了一個新的估算師，他沒有跟蹤記錄，考慮一下最壞情況：給他們一個虛假的各種範圍速度因子的歷史，直到他們完成了一半真實任務的時候。

3) Simulate thefuture

3）模擬未來

Rather than justadding up estimates to get a single ship date, which sounds right but gives youa profoundly wrong result, you’re going to use the Monte Carlo method tosimulate many possible futures. In a Monte Carlo simulation, you can create 100possible scenarios for the future. Each of these possible futures has 1%probability, so you can make a chart of the probability that you will ship byany given date.

相比於僅僅相加然後得出一個最後的釋出日期，這聽起來不錯，但給出的絕對是錯誤的結果，你應該採用蒙特卡洛演算法來模擬許多可能的未來。在一個蒙特卡洛模擬中，你可以建立100個可能的未來場景。每個這些未來常見都僅有1%可能，這樣你可以做出一張任意給定日期釋出可能性的圖示。

While calculatingeach possible future for a given developer, you’re going divide each task’sestimate by a randomly-selected velocityfrom that developer’shistorical velocities, which we’ve been gathering in step 2. Here’s one samplefuture:

當你為每個給定的開發人員計算這樣的一個可能未來的時候，你應該將每項任務除以一個從開發者的歷史速度因子裡隨機選擇的速度因子（這項資料我們在步驟二里已經蒐集過了），下面就是一個樣本的未來資料。

估計:	4	8	2	8	16
隨機速度因子	0.6	0.5	0.6	0.6	0.5	Total:
E/V:	6.7	16	3.3	13.3	32	71.3

Do that 100times; each total has 1% probability, and now you can figure out theprobability that you will ship on any given date.

Now watch whathappens:

重複這個過程100次；每個總計都只有1%的可能，然後你就可以得出你在任意給定日期釋出的概率。

現在看看發生了什麼：

·   In the case of the mythical perfect estimator, all velocities are 1.Dividing by a velocity which is always 1 has no effect. Thus, all rounds of thesimulation give the same ship date, and that ship date has 100% probability.Just like in the fairy tales!

·   在那種神奇的完美估算者的情況下，所有的速度因子都是1.處以速度因子為1等於沒有除。然後所有的模擬都會給出相同的釋出日期，然後那個釋出日期有著100%的概率。就像童話裡描述的那樣。

·   The bad estimator’s velocities are all over the map. 0.1 and 13.0are just as likely. Each round of the simulation is going to produce a verydifferent result, because when you divide by random velocities you get verydifferent numbers each time. The probability distribution curve you get will bevery shallow, showing an equal chance of shipping tomorrow or in the farfuture. That’s still useful information to get, by the way: it tells you thatyou shouldn’t have confidence in the predicted ship dates.

·   會的估算者的速度因子在圖表裡到處都是，0.1和13.0一樣可能。每一輪的模擬都會產生非常不同的結果，因為當你每次處以隨機的速度因子的時候你都會得到很不一樣的記過。這時你得到的概率分佈曲線就非常淺薄，意味著你明天釋出的可能性和遙遠的未來發布的可能性是一樣的。雖然還是有那麼點兒用處，順便說一下：它同時告訴你，你不應親信預測的釋出日期。

·   The common estimator has a lot of velocities that are pretty closeto each other, for example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}. When youdivide by these velocities you increase the amount of time something takes, soin one iteration, an 8-hour task might 13 hours; in another it might take 15hours. That compensates for the estimators perpetual optimism. And itcompensatesprecisely, based exactly on thisdevelopers actual, proven, historical optimism. And since all thehistorical velocities are pretty close, hovering around 0.6, when you run eachround of the simulation, you’ll get pretty similar numbers, so you’ll wind upwith a narrow range of possible ship dates.

·   普通的估算者有著大量非常相似的速度因子，例如，{0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}。當你除以這些速度因子的時候你增加了某件事情花費時間發生的可能性，所以在某次迭代中，一項8小時的任務可能要花13小時；在另一個迭代中可能要花15小時。這種過程彌補了估算者的固有樂觀傾向。而且彌補的很準確，因為這是基於該開發者的實際，真實，歷史樂觀性資料而來的。既然所有的歷史速度因子都很接近，大約徘徊在0.6左右，當你每次執行一輪模擬的時候，你都會得到一個相近的資料，所以你最後就會得到一個相對精確的釋出日期範圍。

In each round ofthe Monte Carlo simulation, of course, you have to convert the hourly data tocalendar data, which means you have to take into account each developer’s workschedule, vacations, holidays, etc. And then you have to see, for each round,which developer is finishing last, because that’s when the whole team will bedone. These calculations are painstaking, but luckily, painstaking is what computersare good at.

在蒙特卡洛的每一輪模擬中，當然，你要把小時資料轉換成日程資料，日曆資料意味著你要把開發者的工作進度，休假，公假等等都考慮進來。然後你每一輪都要觀察，哪個開發者最後完成，因為那就是整個團隊的完成時間。這些計算很痛苦， 不過幸運的是， 計算機剛好擅長這些令人痛苦的事情。

Obsessive-compulsivedisorder not required

不需要強迫症

What do you doabout the boss who interrupts you all the time with long-winded stories abouthis fishing trips? Or the sales meetings you’re forced to go to even though youhave no reason to be there? Coffee breaks? Spending half a day helping the newguy get his dev environment set up?

。如果你的老闆不停的打斷你然後給你講他去釣魚路上的冗長的故事，你會怎麼做？或者是你被迫參加你沒有任何理由應該要參加的銷售會議，你會怎麼做？咖啡間歇呢？花半天時間幫新人設定開發環境？

When Brett and Iwere developing this technique at Fog Creek, we worried a lot about things thattake real time but can’t be predicted in advance. Sometimes, this all adds upto more time than writing code. Should you have estimates for this stuff too,and track it on a time sheet?

當我和Brett在FogCreek開發這種技術的時候，我們很擔心這種實際上要花時間但是卻不能預先估計的事情。有時候，這些事情總共花費的時間比寫程式碼還多。你也應該要估算這種事情麼？用時間表來追蹤這些？。

Well, yeah, youcan, if you want. And Evidence Based Scheduling will work.

是的，如果你願意的話當然可以。然後基於事實的計劃制定就能成功。

But you don’thave to.

但你不必須那麼做。

It turns out thatEBS works so well that all you have to do is keep the clock running onwhatever task you were doing when the interruption occurred. As disconcertingas this may sound, EBS produces the best results when you do this.

EBS實際上工作的很好，你要做的事情就是當任何打斷出現的時候你都記下時間。這聽起來可能很令人不安，但EBS在你這樣做的時候才能產生最佳的結果。

Let me walk youthrough a quick example. To make this example as simple as possible, I’m goingto imagine a very predictable programmer, John, whose whole job is writingthose one-line getter and setter functions that inferior programming languagesrequire. All day long this is all he does:

讓我跟你一起來看一個快速的例子。為了儘可能簡化這個例子，我要想象一個很容易預測的程式設計師John,他的工作就是為那些低階的程式語言寫那種必須的一行的getter和setter函式。

private intwidth;
public int getWidth () { return width; }
public void setWidth (int _width} { width = _width; }

I know, I know…it’s a deliberately dumb example, but you knowyou’ve met someonelike this.

我知道，我懂…這是個故意編出來的很傻的例子，但你也知道你也見過這樣的人。

Anyway. Eachgetter or setter takes him 2 hours. So his task estimates look like this:

不管怎樣。每個getter或setter函式都要花費他兩小時，因此它的任務估計看起來是這樣的：

{2, 2, 2, 2, 2,2, 2, 2, 2, 2, 2, … }

Now, this poor guy has a bosswho interrupts him every once in a while with a two-hour conversation aboutmarlin fishing. Now, of course, John could have a task on his schedule called“Painful conversations about marlin,” and put that on his timesheet, but thismight not be politically prudent. Instead, John just keeps the clock running.So his actual times look like this:

現在，這個可憐的傢伙有個老闆，每隔一段時間就要跟他聊大概倆小時關於釣馬琳魚。現在，當然，John可以在他的任務計劃上寫上一個任務“關於馬琳魚的痛苦對話”，然後把這個加到他的時間表上，不過這似乎是“政治上”不謹慎的。所以，John不考慮這些，繼續計時，因此他的實際時間看上去就是：

{2, 2, 2, 2, 4,2, 2, 2, 2, 4, 2, … }

And hisvelocities are:

他的速度就是：

{1, 1, 1, 1, 0.5,1, 1, 1, 1, 0.5, 1, … }

Now think aboutwhat happens. In the Monte Carlo simulation, the probability that each estimatewill be divided by 0.5 is exactly the same as the probability thatJohn’s boss would interrupt him during any given feature. So EBSproduces a correct schedule!

現在想想發生了什麼。在蒙特卡洛模擬過程中，每個估算被除以0.5的概率和John的老闆在任何功能實現的過程中來打斷他的概率是一樣的。所以EBS算出了真確的計劃！

In fact, EBS isfar more likely to have accurate evidence about these interruptions than eventhe most timesheet-obsessive developer.Which is exactly why it works so well.Here’s how I explain this to people. When developers get interrupted, they caneither

實際上，相比那些有記錄時間表強迫症的開發者，EBS對這些打斷的有著更加準確的事實證據。著也正是為什麼EBS如此有效的原因。下面是我如何跟別人解釋這些的。當開發者被打斷的時候，他們可以：

1.   make a big stink about putting the interruption on their timesheetand in their estimates, so management can see just how much time is beingwasted on fishing conversation, or

2.   公開抱怨這個打斷，並把它記到他們的時間表估計專案上去，這樣管理層就能知道有多少時間被浪費在這種釣魚談論中，或者。

3.  make a big stink about refusing to put it on their timesheet, justletting the feature they were working on slip, because they refuse to pad their estimateswhich were perfectly correct with stupid conversation aboutfishing expeditions to which they weren’t even invited,

4.   抱怨歸抱怨但是不把它放到時間表裡去，就讓他們工作的功能跳票，因為他們也不會為了顯得他們的估算是完全準確的而在時間表裡填上那些他們甚至都沒被邀請的愚蠢的關於釣魚的對話。

… and in eithercase, EBS gives the same, exactly correct results, no matter whichtype of passive-aggressive developer you have.

…不管是哪一種情況, 不管你被動還是主動型別的開發人員EBS都給出了相同的完全正確的結果。

4) Manage yourprojects actively

4）主動管理你的專案。

Once you’ve gotthis set up, you can actively manage projects to ship on time. For example, ifyou sort features out into different priorities, it’s easy to see how much itwould help the schedule if you could cut the lower priority features.

一旦你瞭解了這種設定，你就可以主動的管理專案以便準時釋出產品。例如，如果你把功能根據優先順序分成不同的類別，這樣就很容易看出來如果你砍掉低優先順序的功能對進度有什麼幫助。

You can also lookat the distribution of possible ship dates for each developer:

你也可以檢視每個開發者的可能交付日期分佈：

Some developers(like Milton in this picture) may be causing problems because their ship datesare so uncertain: they need to work on learning to estimate better. Otherdevelopers (like Jane) have very precise ship dates that are just too late:they need to have some of their work taken off their plate. Other developers(me! yay!) are not on the critical path at all, and can be left in peace.

有些程式設計師（就像這幅圖片裡的Milton）可能會導致問題，因為他們的交付日期是如此不確定：他們應該學習更好的估計。其他的開發者（像Jane）有著非常精確的釋出日期，就是釋出日期太晚了：得從他們的架子上拿走一些活兒。其他的開發者（對，就像我）根本就不在關鍵路徑上，可以安靜的留在那兒。

Scope creep

Assuming you hadeverything planned down to the last detail when you started work, EBS worksgreat. To be honest, though, you may do some features that you hadn’t planned.You get new ideas, your salespeople sell features you don’t have, and somebodyon the board of directors comes up with a cool new idea to make your golf cartGPS application monitor EKGs while golfers are buzzing around the golf course.All this leads to delays that could not have been predicted when you did theoriginal schedule.

專案範圍變動

假定你開始工作的時候所有的東西都已經計劃到了極致，EBS也完全正確。不過，老實說，你還是可能會遇到你原來沒有計劃的功能。你會有些新的想法，你的銷售人員會銷售你沒有的功能，董事會的某些人會幫你的高爾夫車GPS程式想出些新點子，例如讓你的程式在高爾夫選手鬧哄哄的跑來跑去的時候監視大夥兒的心電圖。這些都會導致你原來的計劃沒有預料的情況並且延遲最終交付。

Ideally, you havea bunch of buffer for this. In fact, go ahead and build buffer into youroriginal schedule for:

理想情況下，你應該要有一些緩衝來應付這些情況。 實際上要為你原來的計劃制定一些緩衝來處理這些情況：

1.   New feature ideas

2.   新功能想法

3.  Responding to the competition

4.   響應競爭

5.  Integration (getting everyone’s code to work together when it’smerged)

6.   整合（當所有程式碼融合的時候花一些時間來保證所有人的程式碼都是能工作的）

7.   Debugging time

8.  除錯時間

9.  Usability testing (and incorporating the results of those tests intothe product).

10.           可用性測試（將產品的可用性測試整合進產品）

11.            Beta tests

12.            Beta測試

So now, when newfeatures come up, you can slice off a piece of the appropriate buffer and useit for the new feature.

所以現在，當有新的功能需求出現的時候，你就應該要分出合適的額外的時間並拿它來處理新的功能需求。

What happens ifyou’re still adding features and you’ve run out of buffer? Well, now the shipdates you get out of EBS start slipping. You should take a snapshot of the shipdate confidence distribution every night, so that you can track this over time:

如果你的緩衝都用完了，你還在往產品裡新增功能會怎麼樣？恩，這樣EBS計算得出的釋出日期就開始滑動。你應該每晚都快速的看一下發布日期置信分佈，這樣你就能不斷的追蹤釋出日期變化。

The x-axisis when the calculation was done; the y-axis is the ship date.There are three curves here: the top one is the 95% probability date, themiddle is 50% and the bottom is 5%. So, the closer the curves are to oneanother, the narrower the range of possible ship dates.

X軸表示的是計算完成的時候；y軸表示的是釋出日期。上圖一共有三條曲線：最上面的是置信度為95%的釋出日期，中間的是50%的下面的是5%的，所以這些曲線互相靠的越近，可能的釋出日期範圍就越精窄。

If you see shipdate getting later and later (rising curves), you’re in trouble. If it’sgetting later by more than one day per day, you’re adding work faster thanyou’re completing work, and you’ll never be done. You can also look and see ifthe ship date confidence distribution is getting tighter (the curves areconverging), which it should be if you’re really converging on a date.

如果你發現釋出日期越來越遲（曲線上升），你就遇到麻煩了。如果每天釋出日期都往後推一天，意味著你增加工作的速度比你完成工作的速度要快，那麼你永遠也沒辦法完成產品。你也要看看釋出日期的置信分佈曲線是不是越來越緊緻（曲線是否收斂），如果你的釋出日期真的收斂到一個日期的話那就應該是收斂到那一天。

While we’re at it

我們在討論這些的時候

Here are a fewmore things I’ve learned over the years about schedules.

下面是另外一些這些年我學到的關於進度計劃的東西。

1) Only theprogrammer doing the work can create the estimate. Anysystem where management writes a schedule and hands it off to programmers isdoomed to fail. Only the programmer who is going to implement a feature canfigure out what steps they will need to take to implement that feature.
只有在做實際工作的程式設計師才能估計。任何那種管理層制定計劃然後把它扔給程式設計師的進度計劃註定是要失敗的。只有那些實際要實現功能的程式設計師才能弄清楚要實現這個功能的具體步驟。

2) Fix bugs asyou find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because youdon’t know what bugs you’re going to have. When bugs are found in new code,charge the time to the original task that you implemented incorrectly. Thiswill help EBS predict the time it takes to get fully debugged code,not just working code.
當你發現錯誤的時候就開始修正它們，把時間算到你原來的這項任務裡。 你無法預先制定修正某個錯誤的計劃，因為你不知道你會遇到什麼樣的軟體錯誤。當新程式碼裡發現錯誤的時候，把時間算到你原來計劃中會正確實現的那項任務裡。這有助於EBS正確的預測你實現完整的除錯過的程式碼的時間，而不僅僅是工作程式碼。

3) Don’t let managersbadger developers into shorter estimates. Manyrookie software managers think that they can “motivate” their programmers towork faster by giving them nice, “tight” (unrealistically short) schedules. Ithink this kind of motivation is brain-dead. When I’m behind schedule, I feeldoomed and depressed and unmotivated. When I’m working ahead ofschedule, I’m cheerful and productive. The schedule is not the place to playpsychological games.
不要讓專案經理糾纏程式設計師制定更短時間的估計。 許多初級軟體專案經理會認為他們可以通過給予程式設計師更“緊湊”（時間短到不現實）的進度計劃來激勵程式設計師更加快速的工作。我覺得這種所謂的激勵簡直就是腦殘。當我落後於進度的時候我會覺得註定是這樣的，抑鬱，並且失去動機。當我提前於進度計劃，我就會很高興並且充滿效率。進度計劃不是玩心理遊戲的地方。

Why do managerstry this?

為什麼經理會嘗試這麼做？。

When the projectbegins, the technical managers go off, meet with the business people, and comeup with a list of features they think would take about threemonths, but which would really take twelve. When you think of writing codewithout thinking about all the steps you have to take, it always seems like itwill take n time, when in reality it will probably take morelike 4n time. When you do a real schedule, you add up all the tasksand realize that the project is going to take much longer than originallythought. The business people are unhappy.

當專案開始的時候，技術經理就會去會見業務人員，然後定出一堆他們覺得只要花3個月的功能，實際上這些功能可能要花12個月。 當你只考慮寫程式碼而不考慮寫程式碼的所有步驟的時候，總是看起來要花N的時間，而實際上可能要花4N的時間。當你制定實際的計劃的時候，你把所有的任務都加起來然後意識到專案要比原來的計劃要花多得多的時間。業務人員就不高興了。

Inept managerstry to address this by figuring out how to get people to work faster. This isnot very realistic. You might be able to hire more people, but they need to getup to speed and will probably be working at 50% efficiency for several months(and dragging down the efficiency of the people who have to mentor them).

無能的經理就會通過讓人工作的更快來解決這個問題。這很不現實。你可以僱更多的人，但他們得花時間瞭解情況然後可能只能以50%的效率工作幾個月（同時會拉低那些要輔導他們的人的效率）。

You might be ableto get 10% more raw code out of people temporarilyat the cost ofhaving them burn out 100% in a year. Not a big gain, and it’s a bit like eatingyour seed corn. Of course, when you overwork people, debugging time doubles anda late project becomes later. Splendid karma.

你可能臨時的讓他們多寫出10%的原始程式碼，代價是一年之內他們都筋疲力盡了。不是什麼太大的收穫，有點像吃掉你自己的玉米種子。當然，當你開始讓大家加班，除錯時間就會翻倍，延遲的專案會更遲，完全就是因果報應。

But you can neverget 4n from n, ever, and if you think you can, pleaseemail me the stock symbol for your company so I can short it.

但你絕對不能從N裡得到4N，如果你覺得你能，發電子郵件告訴我你們公司的股票程式碼，我絕對會做空它的。

4) A scheduleis a box of wood blocks. If you have a bunchof wood blocks, and you can’t fit them into a box, you have two choices: get abigger box, or remove some blocks. If you wanted to ship in six months, but youhave twelve months on the schedule, you are either going to have to delayshipping, or find some features to delete. You just can’t shrink the blocks,and if you pretend you can, then you are merely depriving yourself of a usefulopportunity to actually see into the future by lying toyourself about what you see there.
進度就像一盒子的木料。 如果你有一堆木料而且你無法把他們裝進盒子裡，你有兩個選擇：選個更大的盒子，或者去掉一些木料。如果你想要在6個月內釋出，但你的進度上有12個月的內容，你要麼延遲釋出，要麼找些功能刪除掉。你不能縮減內容，如果你假裝可以的話，你不過是在對你自己撒謊你能在未來看到什麼，你剝奪了自己很好的機會來看看未來實際是怎樣的。

Now that Imention it, one of the great benefits of realistic schedules is that you are forcedto delete features. Why is this good?

既然我提到了，現實版的進度計劃的最大好處之一就在於你被迫刪除功能特性。為什麼這樣好呢？。

Suppose you havetwo features in mind. One is really useful and will make your product reallygreat. The other is really easy and the programmers can’t wait to code it up(”Look! <blink>!”), but it serves no useful purpose.

假設你腦海中有兩個功能。其中之一非常有用而且會讓你的產品非常棒。另外一個非常簡單程式設計師實在等不及要實現它了（“瞧!一眨眼就好了！”），不過它沒什麼特別有用的地方。

If you don’t make a schedule,the programmers will do the easy/fun feature first. Then they’ll run out oftime, and you will have no choice but to slip the schedule to do theuseful/important feature.

如果你不制定進度計劃，程式設計師就首先會做最簡單/有趣的功能，然後他們就沒時間了，你除了跳票掉原來的有用功能的進度計劃之外沒有選擇。

If you do make aschedule, even before you start working, you’ll realize that you have to cutsomething, so you’ll cut the easy/fun feature and just do the useful/importantfeature. By forcing yourself to chose some features to cut, you wind up makinga more powerful, better product with a better mix of good features that shipssooner.

如果你確實制定計劃，那排在你開始工作之前，你就會意識到你必須要砍掉些東西，然後你就砍掉那些容易/有趣的功能然後只做那些有用/重要的功能。通過強迫自己選出一些功能來砍掉，你最終做出了更加強大，更好的產品，產品融合了更好的功能，也能較早釋出。

Way back when Iwas working on Excel 5, our initial feature list was huge and would havegone way over schedule. “Oh my!” we thought. “Those are all superimportant features! How can we live without a macro editing wizard?”

早在我還在EXCEL5工作的時候，我們最早的功能列表巨大而且早就已經超出了進度計劃。“噢，天吶！”我們想“這些都是超級重要的功能！我們怎麼能沒有一個巨集編輯嚮導呢？”。

As it turns out,we had no choice, and we cut what we thought was “to the bone” to make theschedule. Everybody felt unhappy about the cuts. To make people feel better, wetold ourselves that we weren’tcutting the features, we weresimply deferring them to Excel 6.

實際上，我們別無選擇，我們必須砍掉我們認為“骨子裡”重要的的功能來趕上進度。所有人都會對這些功能裁剪感到不高興。為了讓人們覺得好一點，我們告訴自己我們不是在砍掉這些功能，我們只是把他們推遲到Excel6。

As Excel 5 wasnearing completion, I started working on the Excel 6 spec with a colleague,Eric Michelman. We sat down to go through the list of “Excel 6” features thathad been punted from the Excel 5 schedule. Guess what? It was the shoddiestlist of features you could imagine. Not one of those featureswas worth doing. I don’t think a single one of them ever was. The process ofculling features to fit a schedule was the best thing we could have done. If wehadn’t done this, Excel 5 would have taken twice as long and included 50%useless crap features that would have had to be supported, for backwardscompatibility, until the end of time.

在Excel5快要完成的時候，我開始和同事EricMichelman編寫Excel6的規範，我們坐下來討論從Excel5推遲過來的特性。你猜怎麼著？那簡直就是你能想象的最挫的功能列表。沒有一個功能值得做。 我不覺得任何一個值得去做。 裁剪功能了列表來迎合進度計劃的過程是做得最好的事情。如果我們沒有這麼做，Excel5至少要花兩倍的時間而且包含了50%的無用垃圾功能。這些功能還得後續技術支援，後向相容直到最後。

Summary

總結

UsingEvidence-Based Scheduling is pretty easy: it will take you a day or two at thebeginning of every iteration to produce detailed estimates, and it’ll take afew seconds every day to record when you start working on a new task on atimesheet. The benefits, though, are huge: realistic schedules.

使用基於事實的進度計劃相當簡單：在開始的時候每個迭代大約要花你一兩天來產生詳細的估算，然後每天工作的時候要花你幾秒鐘把任務記錄到時間表裡。好處是巨大的：現實的進度計劃。

Realisticschedules are the key to creating good software. It forces you to do the bestfeatures first and allows you to make the right decisions about what to build.Which makes your product better, your boss happier, delights your customers,and—best of all—lets you go home at five o’clock.

符合現實的進度是建立好的軟體產品的關鍵。它強迫你先做最好的特性然後讓你做出關於要創作什麼的最好決定。這個過程讓你的產品更好，讓你的老闆更高興，讓你的顧客高興，然後最好的一點-讓你5點鐘可以準時回家。

P.S.

Evidence BasedScheduling is built into FogBugz6.0.

加一句

基於事實的進度計劃已經被集合進了FogBugz6.0