参与变革

发现更多可重用的过程与简单的版本控制相比,更易走向成功

Lisa J. Roberts,译:mirnshi(mirnshi@263.net)

 

译者序:本文刊登于SDMagazine,2000年11月。论述了为什么要建立可重用过程以及从中得到的好处。译文中部分语句采用了意译,不妥之处和曲意之处请参见原文。

 

    开发过程共享实施猛烈的变革和改变是个什么样子?除了可能的时间大量损失(好,其实这是很小的

可能,除了正在改变开发过程时),当它们获得了人们支持时就都会成功。

    在历史上,人民,社会的劳动者,通过联合推动了社会变革。这就是我们所满意的应用程序,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),或者针对最后的抱怨作一个改正(从而没有旧的要求)。我们需要一个载明新发行版本应体现哪些要求的计划。

    这表明另一个过程需要改进。在决定之前,我们通过将bugs报告和要改变的要求写到纸上,保证可追踪。这片纸经常“走向了所有事物的归途”,或者偶然的扔进了废纸篓,或者压在了其他所有的纸张下面。(这点上我坚信我已危险地靠近制造我自己桌面中子星)(译者注:黑洞乎)那些纸随着时间的流逝而不能理解,无心的造成了客户输入损失的结果。

    我们需要很好的保持我们改变要求的追踪,这样我们就可以为下一个发行版本选择明确的要求。在对几个产品调研后,我们购买了Pure Atria的ClearDDTS,帮助我们管理我们的改变要求,我们试图一年四次发布新版本应用程序,这作为一策略被我们采纳,这样我们就可以很快的清晰地增加新功能,不用更新得过于频繁导致没有时间测试我们的修改。为了达到结束点,我们努力选择一定量的能够在三个月内完成的工作。第一次时,因为我们没有人知道如何预测一个详细的修改需要多长时间,我们彻底失败了。幸运的是,我们可以通过ClearDDTS跟踪我们曾经预测的时间和工作中实际花费的时间,并且个别开发人员利用这些数据预测将来。在为其他版本的选择工作中,这获得了重大的成功。变革明显的站住了脚。

    我们也决定与目标发行版本并进,着手提高质量的工作。为了完成这点,我们要求所有决意要改变的要求要被不具有开发责任的其他人所验证。当我们知道其他人会检查工作时,我们就都会非常仔细,这多么惊奇。我们也开始采用Mercury Interactive’s Xrunner和内部使用的脚本开发了一个自动测试系统。将来,在我们发布一个新版本应用程序前,这些测试必须成功的测试过。

 

持续的改进

 

    所有这些工作都以我们不能想象的方式的到回报了。我们更好地跟踪我们的改变要求,也就是我们没有丢掉它们,我们确实能跟得上用户的更新状态了。用户喜欢这点,我们也不再面对来自客户的挫折。他们也喜欢我们更频繁的更新和更加健壮的程序。

    我们正在寻找另外的方式,我们可以从改变我们过程中获得好处的方式。现在,我们正在研究软件开发成熟度模型(CMM),看是否能通过遵从2级帮助我们提供更好的应用软件(请到www.sei.cmu.edu查看更多的CMM信息)。我们可以从这种方式中获得好处,但是我们想确认通过2级认证能够编写更好的代码,不只是更多的文书工作的要求。我们的兴趣在于进步,不在于核对boxes。

    我们正在进行的另一个改变是,我们能够更容易地在我们每年四个主版本之间发布修订bugs的版本。这点可以是我们更快的转向用户的要求,平息用户的愤怒。(我们基于用户认识到的严重性和我们察觉的严重性的比较,选择哪些bugs被改正,还包括工作区存在的风格。我们在整体上也为客户整合了全部优先级的感觉)

    我们过程改革的更多惊人结果之一是不只影响了程序,更多地影响了程序开发人员。他们停止了改善用户的态度,转向提高应用程序。程序变得更可靠,发行版本变得更可预测的同时,用户对应用软件整体上也更加满意。

    但是我们不仅只关心我们的过程的改革。MeshTV的开发人员同其他的开发小组并同工作着,我们试着同其他的小组分享我们的经验,学习我们的胜利和错误。围绕我们新的过程,我们提供了四个展示,至少有一个小组已经决定采用我们的一些经验。变革在成长。

 

成功孕育成功

 

    当管理层尝试推动改变过程时,从最初的怀疑和愤怒,我们在这个过程中经历了巨大的变革。这些曾经著名的过程都是那些所有刊物都讨论过,当作福音传授给我们的同事。当我回头看看我们的小组,我惊奇于我们从使用一个版本控制系统改变到几个可重用性、文档化过程,甚至将那些经验出售给别人。什么能够允许我们背离我们正规的商业方式

    对于我们来说,在开展新的过程中最重要的因素是一个成功的战士,他酝酿了过程改革中的兴趣。这个战士应该是一个受到尊敬的开发人员,在小组里的,因持续工作而闻名,因渴望经验的增长而受人尊重。在我们的事中,我们有二位战士,我的同事Sean Ahern和我自己。在我们兴奋于可能的好处并开始着手于一些改革后,小组的其他人信服了并跟随我们。当管理层决定了过程必须跟随时,来自小组外的压力出现了。对于外来的,组员将可能排斥它,对此我不能强调得足够多。然而,来自里受人尊敬的组成员的狂热,开发人员感到是必须听从。毕竟,这些人们事实上知道到底它象个什么样子。一旦其他团队里的人看到了真正的好处,他们就会跳进这个潮流中,变革也就会良好的进行下去。当开发人员开始思考改进过程的方式,获取真正的好处时,好戏就开始了

    你如何开始你的变革?每次一个改变。一旦明显有好处,你的同事就会加入到你的行列中,同你一起征服编程世界。