第十二章 里程碑及期限.docVIP

第十二章　里程碑及期限 ＊企划的时程安排 ＊避免独断的期限 ＊破除模糊的里程碑 ＊企划的开始 不管我们多喜欢在自由而且没有压力的情况下撰写软体，一些里程碑与期限这是有必要的。是的，它们是所有［不琐碎软体企划］的常见要素，而且也是许多研发者生命中的祸根。 在看看所有的里程碑和期限后，很令人惊讶的是，大部分的里程碑规格都是设定在一个独断的风格之中：而且在大部份的情况下，期限则是定义在一个［期限］的基础上，而非实际的预估。这个特点来自不同要素的作用，包括市场的影响、没有经验的软体管理者，而且在某些情况下，包括了极为固执的人。当然了，大部份的人们只是不知道如何针对软体的研发来预估时程。想要维持公平是一个困难的过程，而且它包括了许多的分析与计算，才能产生有用的结果。 在游戏产业之外，软体公司使用一个比较严密的方式，而不是［选一天并期望那天做完］。即使如此，贵重的训练以及指导方针，还是有助于在合理的态度下，定义出里程碑。 里程碑的作用是把企划分解成可以管理的厚块。最不应该采用的作法，就是列出一长串想用的功能列表，让研发者一个个查看是不是统统完成：当然了，事实上也不应该建议这种方式。您可以想象到，在一个企划持续了18个月的时间后，每个星期只能在几个要件上面打勾，会让士气低落到什么样子？这种做事的方式有可能成功吗？小组要怎样去集中精神并保持热忱？如同它的荒谬之处，有些企划仍然使用这样的系统来进研发，而它们的过程可能是软体研发中最无趣的。 在这边呈现的方式可以运用在各种类型的软体上，不管是试算表、资料库或是大型电玩中的射击游戏。这个章节将告诉您一组以［良好经验］为基础的指导方针，以更实际的方法来定义里程碑和期限。在本书的后面，我们会解释这些预测是如何进展，并随着企划的延续而越来越精确。这个越来越精确的现象，可以视为集中性的规则。在讨论企划的全面结构时，这个章节也可以做为本书未来章节的地图。所以，如果您正在寻找研发过程的相关资讯，这个章节可以说是您的第一站。 里程碑如何运作 您有多少次，非要用一个［模糊］的里程碑当做目标来工作？对没有经验的人而言（而且数量不能太多！），一个模糊里程碑是一个有很多解释且具备X种可能完成它的方式，而这个X代表您想要的任何数字，只要比1大就行。 而且您要怎么样才知道您抵达了一个模糊里程碑？如果这个里程碑的目标十分模糊，在预想的情况下，它们就是开放性的解释。那谁的解释才算数？当然了，这通常要靠您的老板才能做出［正确］的解释，而且很可能出现的情况是，他与您的看法完全不同。 试试这个简单的测试。想象您的老板给您一张纸，上面画了五角形的五个点，标示出A、B、C、D和E，如同图12.1所示。 现在，想象您的老板说：［我今天很忙，而且我需要在一个小时中完成这个工作。我有很多人要见，所以我只能简要的告诉你我需要你做些什么事。我要你在A和B之间画一条线，在我从生意上的午餐回来之前做好。 三个小时之后，您的老板蹒跚的回到办公室，并向您要完成的文件。 如果您直接在A与B之间画一条线（如同图12.2），我很抱歉，但您输了。不过，如果您先在A与E之间画一条线，然后确定这条线延伸绕着五角形穿过D、E和B，（如同图12.3），而且在A与B之间留下空白，那您就成功的达民了里程碑。 好吧，您的老板不会叫您做这些琐碎的事，这边的重点是：含糊的里程碑是没用的。 要走到您的解答，它可能代表您作了太多或是太少的事情；而大部份的情况下，程式设计师的基本心理一定会倾向后者。这并不表示良好的程式设计师都是懒虫；这只是表示在普通的原则下，二点之间的最短距离是直线（大部份的良好程式设计师，喜欢以最小的工作量，产生出规定的结果）。 不过，在前者的情况下（作了太多事）也通常代表错误的工作方式，这表示程式设计师在解答方面太过热心，提供了不需要或是没有必要的复杂功能。 在完美的情况下，里程碑不应该有这些大的活动空间，但很不幸的是，这一类状况正是大部分安排时程的问题核心所在。在一个比率公平的企划中，里程碑之间的距离放得太远，它们之间就可以容许一定程度的偏移；象是进行不必要的工作，或是缺乏集中注意力的焦点。 一个里程碑应该十分明确而简洁。它应该也很明显，足以一眼就看出这个里程碑是否已经到达：黑与白、失败与成功。它不应该迎合或是鼓励任何野心的结果或是灰暗的阴影。没有人可以说一个里程碑完成了90%；一个完成90%的里程碑给人的感觉，好象是一个灯泡的亮度为90%；这个灯泡只有亮与不亮，里程碑也是如此。 这个要点十分重要。模糊里程碑是在企划中最常见的单一问题。 您老板的五角形工作，应该以下列的方式来说明。 1．必备工具：尺以及一只黑笔，可以划出连续的细线。 2．在点A到点E之间，以粗细均匀的黑线相连。 3．在点E到点D之间，以粗细均匀的黑线相连。 4．在点D到点C之间，以粗细均匀的黑线相