首先，我们转换到有目的的发行版本日期，使其包含明确的更改和新的功能。像许多的内部产品，MeshTV有着明显的直接的用户（MeshTV had users who lived "right down the street."）。新特性的不同的声音淹没在所有的目标回应中，我们尝试经常性的从那些所有从会议厅走下来，停下来聊会儿天的用户那里获取要求。（这些打断也可以避免我们持续工作）荒谬的是在试图获取所有要求中，我们不能满足他们中的大多数，我们失望了。所以我们从这种方法上退回来。或者试图将所有要求放进去（可能匆忙地完成，没有更多明显的bugs）,或者针对最后的抱怨作一个改正（从而没有旧的要求）。我们需要一个载明新发行版本应体现哪些要求的计划。
这表明另一个过程需要改进。在决定之前，我们通过将bugs报告和要改变的要求写到纸上，保证可追踪。这片纸经常“走向了所有事物的归途”，或者偶然的扔进了废纸篓，或者压在了其他所有的纸张下面。（这点上我坚信我已危险地靠近制造我自己桌面中子星）（译者注：黑洞乎）那些纸随着时间的流逝而不能理解，无心的造成了客户输入损失的结果。
我们需要很好的保持我们改变要求的追踪，这样我们就可以为下一个发行版本选择明确的要求。在对几个产品调研后，我们购买了Pure Atria的ClearDDTS，帮助我们管理我们的改变要求，我们试图一年四次发布新版本应用程序，这作为一策略被我们采纳，这样我们就可以很快的清晰地增加新功能，不用更新得过于频繁导致没有时间测试我们的修改。为了达到结束点，我们努力选择一定量的能够在三个月内完成的工作。第一次时，因为我们没有人知道如何预测一个详细的修改需要多长时间，我们彻底失败了。幸运的是，我们可以通过ClearDDTS跟踪我们曾经预测的时间和工作中实际花费的时间，并且个别开发人员利用这些数据预测将来。在为其他版本的选择工作中，这获得了重大的成功。变革明显的站住了脚。
我们也决定与目标发行版本并进，着手提高质量的工作。为了完成这点，我们要求所有决意要改变的要求要被不具有开发责任的其他人所验证。当我们知道其他人会检查工作时，我们就都会非常仔细，这多么惊奇。我们也开始采用Mercury Interactive’s Xrunner和内部使用的脚本开发了一个自动测试系统。将来，在我们发布一个新版本应用程序前，这些测试必须成功的测试过。
持续的改进
所有这些工作都以我们不能想象的方式的到回报了。我们更好地跟踪我们的改变要求，也就是我们没有丢掉它们，我们确实能跟得上用户的更新状态了。用户喜欢这点，我们也不再面对来自客户的挫折。他们也喜欢我们更频繁的更新和更加健壮的程序。
我们正在寻找另外的方式，我们可以从改变我们过程中获得好处的方式。现在，我们正在研究软件开发成熟度模型（CMM）,看是否能通过遵从2级帮助我们提供更好的应用软件（请到http://www.sei.cmu.edu/查看更多的CMM信息）。我们可以从这种方式中获得好处，但是我们想确认通过2级认证能够编写更好的代码，不只是更多的文书工作的要求。我们的兴趣在于进步，不在于核对boxes。
我们正在进行的另一个改变是，我们能够更容易地在我们每年四个主版本之间发布修订bugs的版本。这点可以是我们更快的转向用户的要求，平息用户的愤怒。（我们基于用户认识到的严重性和我们察觉的严重性的比较，选择哪些bugs被改正，还包括工作区存在的风格。我们在整体上也为客户整合了全部优先级的感觉）
我们过程改革的更多惊人结果之一是不只影响了程序，更多地影响了程序开发人员。他们停止了改善用户的态度，转向提高应用程序。程序变得更可靠，发行版本变得更可预测的同时，用户对应用软件整体上也更加满意。
但是我们不仅只关心我们的过程的改革。MeshTV的开发人员同其他的开发小组并同工作着，我们试着同其他的小组分享我们的经验，学习我们的胜利和错误。围绕我们新的过程，我们提供了四个展示，至少有一个小组已经决定采用我们的一些经验。变革在成长。
成功孕育成功
当管理层尝试推动改变过程时，从最初的怀疑和愤怒，我们在这个过程中经历了巨大的变革。这些曾经著名的过程都是那些所有刊物都讨论过，当作福音传授给我们的同事。当我回头看看我们的小组，我惊奇于我们从使用一个版本控制系统改变到几个可重用性、文档化过程，甚至将那些经验出售给别人。什么能够允许我们背离我们正规的商业方式
对于我们来说，在开展新的过程中最重要的因素是一个成功的战士，他酝酿了过程改革中的兴趣。这个战士应该是一个受到尊敬的开发人员，在小组里的，因持续工作而闻名，因渴望经验的增长而受人尊重。在我们的事中，我们有二位战士，我的同事Sean Ahern和我自己。在我们兴奋于可能的好处并开始着手于一些改革后，小组的其他人信服了并跟随我们。当管理层决定了过程必须跟随时，来自小组外的压力出现了。对于外来的，组员将可能排斥它，对此我不能强调得足够多。然而，来自里受人尊敬的组成员的狂热，开发人员感到是必须听从。毕竟，这些人们事实上知道到底它象个什么样子。一旦其他团队里的人看到了真正的好处，他们就会跳进这个潮流中，变革也就会良好的进行下去。当开发人员开始思考改进过程的方式，获取真正的好处时，好戏就开始了
你如何开始你的变革？每次一个改变。一旦明显有好处，你的同事就会加入到你的行列中，同你一起征服编程世界。
文章来源于领测软件测试网 https://www.ltesting.net/
