今日杂谈----软件质量和deadline

继续阅读康斯坦丁的作品，看到与这个标题相关的内容，发表一些自己的看法。
首先，我想谁都想知道什么时候才算是及时交付？我觉得康斯坦丁的那个例子很好。
他说，从伦敦飞往罗马的飞机误点了，但是当你到了罗马的时候，你还是准时地赶上了去弗洛伦萨的火车.
那么这里的deadline是罗马开往弗洛伦萨火车的时间点。而不是飞机准点的降落在罗马的时间点，schedule变化了，但是还是赶上了deadline。
虽然一切按照进度的软件开发模式还没有在中国盛行起来，或者确切的说，我们大多数还停留在混乱开发模式下，还没有到达按照进度开发软件的开发模式，但是这并不能说，它是没有缺点的。如同在我们国家，我们也很少听到"快速软件开发"这样的流行的单词，但是，这并不表明我们明白快速软件开发带来的种种问题，而实际上，我们的开发大多数情况下，都是编码，然后是设计，这样的本末倒置。可以想象这样的软件质量是糟糕的，即使是非常聪明的程序员。
那么我希望的是什么样子呢？
1.我希望项目经理没有必要把deadline向开发人员隐瞒，而是应该共享这一信息。
2.开发前期，开发人员应该花费足够的时间对问题进行分析，进行设计，和后续阶段的资源分配。
3.然后才是模块设计，编码和测试。
也就是说，按照我的理解，设计很大一部分是在需求分析中做出来的，而且进度表也只有在完成需求分析和初步设计，才会有些意义。而不是很多项目管理者想象中的按照按时交付时间给出臆想中的进度。
如果在初步设计之后给出的scheduler远远超出了deadline,那么，毫无疑问，deadline是有问题的。

现实中，我们遇到的情况很多是这样子的:
项目不可能按时交付，deadline一改再改，此时我想问，这个时间还叫是dead line吗?只可能是某些管理者或者市场人员一项中的东西，deadline的定义应该是，如果此前不能完成，那么项目停止或者取消。就如去弗洛伦萨的火车不会等你一样，但是，罗马到弗洛伦萨只有一趟火车吗？这是可能someone想问的问题。但是对不起，当你乘坐下趟到弗洛伦萨的火车，你已经不能再见到教皇，或者说你的会议已经结束了。

deadline就应该算是dead line.而你的软件设计，实际上应该按deadline来做计划，而不是臆想中的deadline.

在前面的分析中，我们假设，只有充足的时间才能保证软件的高质量性。从而要求软件开的schedule，一要求是可精确度量的，二同样要做到应急缓冲措施。但是真正的软件的质量问题，不可能仅仅因为这一个元素的改善就会提高，而是一个复杂的过程。但我依然相信:一个经过充分研究问题，经过初步设计而制定的schedule相对于按市场压力制定出的计划，更有可能开发出更好的软件，而且也不会失去市场的分额。因为，管理者和市场人员得出的deadline,并非生活中的deadline.无数的事例可以证明:这些deadline都没有成为世界末日，相反，我们的软件在这些deadline的面前，距离世界末日却不远了.....