对开发过程共享实施猛烈的变革和改变是个什么样子？除了可能的时间大量损失（好，其实这是很小的
可能，除了正在改变开发过程时），当它们获得了人们支持时就都会成功。
在历史上，人民，社会的劳动者，通过联合推动了社会变革。这就是我们所满意的应用程序，MeshTV，用二维和三维的有限元网格以图形的方式可视化和分析数据。它也能处理多种不同的网格类型，提供各种方式查看数据并去除了大多数的硬件和厂商的依赖，同时以自身图形硬件的速度显示图形。MeshTV也可以并行工作，你可以想象得到这需要一些组织级别满足程序的复杂性，保持有序。最后说一点，MeshTV大约有450,000行源代码。
这是我所作的全部描述。如果你想了解得更多，查看www.llnl.gov/bdiv/meshtv，你可以下载可执行程序、源代码和手册。
受约束的混乱
象许多为内部使用而开发的程序一样，在加利福尼亚Livemore的劳伦斯Livemore国家实验室，对程序必需的修改和增加超出了可用的资源。在MeshTV项目中，这导致了混乱，（on the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（译者注：这句话不好译）没有人有时间坐下来画出应用流程。我们都在实验室的里里外外，忙于我们客户的贪婪的需求。（有约150个文档用户-可能更多，实际上要靠5个兼职的开发人员支持）在我们这种状况下，这种过程导致了我们用户更多的抱怨和可靠性匮乏的程序。
三年前，我们的职责很小（几个用户，几个开发人员，很少有广泛的应用功能）允许我们在CVS上用非常不正规的过程管理源代码。当用户数和他们需求差异增多时，相应的代码管理的复杂性也增加了。处理我们增长的工作量也变得更加困难，我们知道有些事情必须要改变了。我们决定加入到我们部门的其他开发小组中去，并使用Rational软件公司的版本控制系统—ClearCase。从此，我们过程的改进氛围（our process improvement culture）开始改变，变革的种子已经播下了
在我们转向ClearCase前，我们小组的一位经理曾经诱导我们更多的集中在过程上，她徒劳了。她看到了增长的压力和用户的不满，她想我们应该尝试用不同的方法提高我们程序的可靠性和在用户那里的名声。不幸的是，她的话从来没有引起重视，同样我们也认识到了这点，但我们不得不忙于作完我们的工作。开发人员认为最好的情况是软件工程学所论述的那样，而在最糟和最可能的情况下，会占用大量的时间，提供众多的文档，用处不是很大。我们的一些老开发人员认为改进我们的过程没有用并且……（Some of our veteran developers saw no use for "improving our process" and would have sooner appeared in public in a tutu rather than utter such a sissy phrase.）（译者注：这句话太难译了，单词也不认识）而且俱乐部所有人，包括我也怀疑我们要收获的巨大好处。我认为CVS工作得很好，我们真的不需要更多先进的东西。
在CVS工作的同时，ClearCase工作得更好。我认为在每个软件工程生产力上没有真正的提高，但是可以用我以前不能采用的工作方式工作。这些新的工作方法可以使管理源代码变得更容易，同时也减少了我曾经在CVS中遇到的问题。例如，我现在可以轻松的多并发地开发，我可以在我完成后可靠的归并我所作的。新特性弥补了我花在开发和学习新过程上的时间。
真正的产出
过渡不久，一位同事和我与一位来自苹果计算机公司的开发同行进行了一次有趣的讨论。他的工作需要产品开发过程的急迫应用，包括构建方法学和发行版本管理过程。当我们叙述我们通常随意无计划的方式时，他几乎震惊晕倒。后来的讨论，使我们惊奇的了解到了通过改进我们的过程所获得的好处。有一位经理鼓励我们是一方面，但是非同寻常的另一面是听到一位开发同行称赞他发现的好处。这是真正的产出，计算机科学风格的。
我们对其思考的越多，我们越认识到我们需要行动。将新特性和缺少固定发行日期联系起来的狂热，导致了在发行新版本和功能性的匮乏测试间长久的延期。我们的意图是好的，我们想让我们的客户满意。然而，不知何故，我们的期望事实上很糟糕，似乎看起来我们工作得很辛苦，但是，我们听到了更多的抱怨。我们需要改变现状。
首先，我们转换到有目的的发行版本日期，使其包含明确的更改和新的功能。像许多的内部产品，MeshTV有着明显的直接的用户（MeshTV had users who lived "right down the street."）。新特性的不同的声音淹没在所有的目标回应中，我们尝试经常性的从那些所有从会议厅走下来，停下来聊会儿天的用户那里获取要求。（这些打断也可以避免我们持续工作）荒谬的是在试图获取所有要求中，我们不能满足他们中的大多数，我们失望了。所以我们从这种方法上退回来。或者试图将所有要求放进去（可能匆忙地完成，没有更多明显的bugs）,或者针对最后的抱怨作一个改正（从而没有旧的要求）。我们需要一个载明新发行版本应体现哪些要求的计划。 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
