翻译 项目管理艺术 2.3

 

2.3 计划是什么样

    所有的计划都有一个根本原则：三分法。这只是一种极端粗略的估计，类似于“信封背面计算法”，但这可以说是理解明白计划最简单的方法。如果你经历过作计划，并且正要退缩的话，我力图使整个过程简单化。我要提供一个最简单的立足点，用来讨论什么容易出错，为什么会发生，以及怎样解决。

    这里是一个用来计划工作的极端简化的模型：对于任何项目，将可以利用的时间分成三份，一份用来设计，一份用来实现，一份用来检验。根据你使用的方法论的不同，这些阶段也有不同的叫法，也许它们在某些方法上互相有交迭，但所有的方法论都有负责这三种活动的时间段。任何一天，你不是在弄清楚要做什么（设计），就是在实际做事情（实现生产代码），要不就是核实，分析，优化已经做好的结果（检验）。

 

2.3.1 应用三分法

按照一般性原则推论，你每计划一天的时间写代码，就应该花费一天时间搞计划和设计，还有一天时间测试和优化结果（参见图 2-1）。这样可以很容易的检查任何已经存在的项目或者从头开始一个新的项目。如果总的时间没有被大概的分成这样的三等份，就应该有一些可理解的原因，说明为什么这个项目需要的工作划分是不平均的。只要是经过了考虑，在测试上比在实现上多花20%的时间也是合理的。

图 2-1. 项目计划三分法

 

设想一个虚构的网络项目：如果你有6周的时间来开发它，第一步，你要把时间大致分成三份，然后根据划分，计算出工作完成的时间。如果在较高的预期水准上，还不能提供足够的时间来完成任务，那就是出现了某些根本性的错误了。不是改变计划，就是要减少预期要完成的工作数量（或者降低质量要求）。肖建削减设计或检验时间只会增加写代码被误导或者代码难以管理维护的几率。 三分法对于揭示项目的零和性质很有用。添加一个新特性需要不止一个程序员来完成；设计和检验的花费是无法避免的。当计划变动，这是因为有一些隐藏的或者忽略的花费没有被统计到。

 

2.3.1.1 渐进开发（反项目的项目）

       出于完整性，考虑一个最简单的情况是很有意义的,那就是没有项目的情况。所有的工作都是基于要求的出现渐进的被完成，它们的评估基于其他工作，然后被投入到计划的下一个空隙中。有些开发组，网站开发人员，或者IT程序部门都是这样工作的。这些组织很少对大的增量进行投入和承诺。敏捷方法（稍候讨论）经常被推荐给这样的团队作为组织工作最适宜的体系，因为这些方法都强调适应性，简洁性，和对变化的可预见性。如果你同时被分配了几个任务，你就要从本书以项目为中心的例子中自己进行推理了。

    三分法仍然适用于这些情况。即使是每一个程序员都在独立的进行很小的任务，他还是要划分大约三分之一的时间来指出要做什么，三分之一的时间用来做事，最后三分之一的时间用来保证工作的正确性。他可能会在这些时间的使用上做一些调整，但是作为一种理解任何工作的大概的方法，三分法适用于任何规模的项目。

 

2.3.2 划分和控制（大计划 = 许许多多小计划）

    如果你研究了绝大多数的软件开发方法论，就会明白三分法的大致概念。设计的目的和实现的具体方法可能不尽相同，但是在最高层上，最终的目的都是相似的。

    项目越大，时间越长，就越复杂，这就需要将计划划分成小一点的片断，每个片断都有自己设计，实现和检验时间。极限编程（也称为XP）称这些片断为迭代；螺旋模型中称做阶段；还有一些组织则称它为里程碑。在XP中，这些时间段可能只表示几个星期，在螺旋模型中可能就意味着几个月，但是基本的理念的相同的：为有限的时间范围作详细的计划。

       项目的变化越多，越不稳定，里程碑就应该越短。这样才能降低计划的风险数，因为主计划已经被划分为可以管理的片断。计划片断之间的间隔提供了做调整和改进的机会，从而使下一个里程碑能正确的指导自己的工作。（我们将在14章讨论怎样去做。）

 

2.3.2.1 敏捷和传统方法

       XP和其他的敏捷方法都假定未来是不稳定的，所以它们更看重能容易体现方向变化的过程。那些具有很大生产消耗的项目（比如说，盖摩天大楼，生产视频游戏终端，或是制作嵌入式操作系统）走的则是另一条路，它们在计划和设计活动中作了很大投入。它能够被完成，但每个人都要致力于计划中做出的决定，而且为变化付出高昂代价是不可避免的。

    大多数的软件项目都是出于两者的中间。它们有初始的计划，要应付未来用户需求的不稳定性，工作按阶段划分，每个阶段都有设计，实现和质量保证的时间。如果出现一个新问题，可以考虑把它放在当前阶段，也可以安排在下一个阶段研究理解。

    对于绝大多数项目，初始计划时间是用来从客户和业务人员那里获取足够的信息，从而来定义需要多少阶段，每个阶段的重心是什么（见 图2-2）。按照大计划，每个阶段都要花很多时间来设计和检验。一个阶段可以被划分为两个更小的阶段（采用更加敏捷的开发方式），或者两个阶段可以被合并起来（采用更集成的方式）。但是在所有情况下，都要在阶段之间分配时间，从而对变化加以利用。这包括了对那些在前一阶段出现但无法全面解决的问题的处理。

 

图 2-2 大项目就是小项目组成的序列

 

    这些就是我要讲的高层的计划方法论。14章和15章将讲述怎样通过整体计划管理项目，但是它们都将重点放在管理和领导的角度，而不是具体描述怎么样应用一个特定的方法论。如果你能看完下面几段（即使你不完全同意其中的观点），那么不管你怎样组织和计划你的项目，14章和15章里面的意见都是相关的，实用的。

    总之，我对那些在这一节退出的人表示抱歉。现在，一切都结束了，我保证这个轻量的，简单的计划视图正是你所需要的，你可以以此来更好的理解本章余下部分的原理。

 

 

 

所谓「信封背面计算法」，便是当你对某个问题的答案不确定时，可以拿出一个旧信封，思考一下基础的原理，然后在信封背面写下几个近似方程序，互换几个可能数值，看看求出的答案可否解释这个难题。如果无法解答，便继续找寻其它答案。这种算法就好像拿刀子切奶油一样，可以去掉一些无价值的答案。