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.(进度延期的一个重要原因不是没有里程碑和检查点，而是我们的检查点存在进度欺骗，你和项目团队成员在玩着这种没有明确检查标准的进度游戏。所以这里再给我们一个重要的警示，里程碑的出口准则往往比里程碑更加重要。不要为了单纯的进度里程碑而牺牲了项目其它重要属性。)