一门学问。然而，我可以肯定地说，软件的度量不可能准确，尤其是对进度的把握而言。即使一个项目的开发周期看起来是如此的充裕，以至于感受不到最后期限的压力，我们仍然要对软件进度的控制采取如坐针毡的谨慎态度，即使这样在某些人的眼中，我成为了持怀疑论者，或者悲观主义者，我仍然愿意背着这样的名身恶意地怀疑项目时间不够。原因有二。其一是我们的工作量估算无法做到精确，即使是经验丰富的天才程序员，在估算项目的整体工作量时，都会出现偏差。是的，我们采用了分而治之的方式，对功能进行分解，从最小单元来评估工作量。但我们无法估算各个功能单元之间存在的各种显式和隐式关系，以及各种非功能性需求带给项目的影响。其二，我们无法事先完全预知开发过程中的各种风险。我们得为这种风险买上一份保险，这样才不至于在风险真正产生时要我们自己来买单，或者追悔莫及。
关于技术风险，最佳方式莫过于事先进行技术预演。不要揣测，或者从理论上去推导。在这个过程中，我们可以应用经验，但最保险的方式还是对系统中的核心问题以及关键问题进行研究，创建技术原型。它才是规避技术风险的定心丸。
成员变动风险是最难以预知的，因为人是最难以通过数据分析得出正确结论的动物。人的心理太复杂了，因此在软件业中还专门诞生了“人件（Peopleware）”这门学问。在我们进行项目开发过程中，谁知道有多少人会因为各种各样的因素，而萌生去意呢？此外，正所谓“人有旦夕祸福”，我们总不能预测哪些成员会在开发过程中生病或者失恋吧？若要解决这个问题，一个办法是“结对编程”。虽然提出这一方法的目的并不是为了应对成员变动的风险，但事实上这种互相协作的方式确实能够将成员离开所造成的损失降到最低。以我的经验，要发生那种编程开发的一对都离开项目的情形，实在是少之又少。还有一种办法则是Constantine提出的“交叉培训”。在其《人件集》的《稳步提升的质量》一篇中，他提出“将交叉培训纳入项目的组织形式中，……是最有效、最有影响的办法之一。这种方法同时也增加了工作透明度。通过增加团队中面对面工作的机会，团队成员间自然也就增加了相互学习的机会”。此外，他还提出 “在团队中进行软件开发角色轮循，也为成员增加了实践的机会，可以帮助大家掌握更多的技巧和知识。”这里固然在说培训，但它带来的结果是让团队中各个成员都能够了解彼此的工作，这就能够弥补因为某些成员离开项目带来的空白。
这里同样牵扯出一个话题，就是关于团队的培训。我的理解是，即使最后期限泰山压顶，也千万不要节省团队培训的时间，除非你的团队已经熟悉了项目开发的所有领域知识，以及解决领域问题的所有技术知识，同时，这个团队已经固定不变的合作过三个项目以上，因而团队成员已经达到了一个微小动作就能够心领神会的境界。有这样的团队么？或许有，不过我还没有看见。