專案實踐－進度遊戲(1): Schedule Chicken

Refer to:http://www.codinghorror.com/blog/archives/000288.html

I've been meaning to write a series of posts on schedule games, and a story I heard over the weekend has jolted me into writing about schedule chicken.

I'm most familiar with schedule chicken that happens in meetings. Usually in a project status meeting, with the project manager and the project team, especially where the meeting is a form of serial status, everyone claims they're on time. But the reality is that each person is waiting for another person to explain why he or she is not ready. In that case, each person graciously says, "Oh, that's fine with me if you take an extra week or two or three. No problem." Of course it's no problem, if everyone else needs more time.(在專案狀態會議上，每個人都在申明自己的任務都按時完成了，但是實際情況確認每個人都在等著其他人解釋為什麼他或她還沒有準備好。如果你準備好了或按時了，我就能夠按時，但是如果每個人都需要額外的時間來準備，進度如何得到保證呢? )

專案中的活動和任務不可避免的存在著相互的依賴和關聯，下游的任務負責人就是上游任務的內部客戶。如果上游提供給你的工件延期或質量不高引起你的抱怨和不滿，那麼將心比心，你應該更有責任和義務為下游按時提供高質量的工件。要信守承諾，不要推卸自我的責任，不要犯本位主義的錯誤。

But I just learned of another schedule chicken. In this case, everyone claims to be on time. And, the developers are checking in code every night and building every night. But imagine there's a milestone, named something like "code freeze." After code freeze, you can't add any more code, all you can do is fix the code that already exists. The day before code freeze, developers check in two to four times as much code as they had any of the previous days before. The results? Sure, you "met" the code freeze milestone, but the build doesn't work, or even worse, you can no longer build. You spend the next week or two (at one of my clients, it was up to three weeks) fixing the code just so you have a successful build. Now that you have a working build (some time later than the testers expected), the testers find all kinds of problems.(在這裡提到了另外一個很值得思考的話題，為了檢查專案的進展狀態，我們開始在專案中設定里程碑或檢查點，為了檢查編碼工作是否完成，我們設定了和定義的編碼里程碑和編碼凍結點。到了編碼凍結點的時候，所有的程式碼檔案確實都已經增加完成和檢入了，這給了我們一個假象，因為里程碑雖然達到了但是確沒有達到我們的質量要求，編碼檔案是都完成了但是整個系統可能連程式碼構建都無法成功，我們還得花費1-2周甚至更長的時間來解決這些本該在該里程碑前完成的事情。)

Schedule chicken occurs when PMs only measure the milestones (the date), and not the stuff that's created (the feature set) and the progress towards creating that stuff (velocity) and how good that stuff is (the defect levels) all throughout the project. If you know how much progress people are making, you can use your sense of smell to see if all those checkins were really to make code freeze, or were developers covering their tushes to meet the milestone.(專案管理的過程就是一個系統思維和平衡的過程，沒有質量的進度是毫無意義的虛假進度。因為我們必須要重新審視里程碑的深刻含義，必須要對里程碑的出口準則做明確的定義。當你下次在關注程式碼凍結檢查點的時候，你就會發揮你敏銳的嗅覺來審查整個環境是否已經整合和構建成功，冒煙測試是否都通過等問題。)

When I manage projects, I want to know the reality of the project, whether I like it or not. I don't want to play schedule games with the project team, nor do I want them to play schedule games with me. And if you're in senior management, or are a project sponsor, don't make people "commit" to a project date they don't think they can make, because you're setting yourself up for schedule chicken.(進度延期的一個重要原因不是沒有里程碑和檢查點，而是我們的檢查點存在進度欺騙，你和專案團隊成員在玩著這種沒有明確檢查標準的進度遊戲。所以這裡再給我們一個重要的警示，里程碑的出口準則往往比里程碑更加重要。不要為了單純的進度里程碑而犧牲了專案其它重要屬性。)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-429695/，如需轉載，請註明出處，否則將追究法律責任。