Edmunds.com是一种非常受供应商欢迎的在线汽车定价工具，成功应用源于其不断创新。创新需要试验，这可能意味着严重的风险。要使快速转变和安全发展之间达到平衡需要改变Edmunds.com的IT。持续软件开发可以让工厂和运营部门尝试新的规划方式，而不会引入过多的不稳定性。

Ajit Zadgaonkar是Edmunds软件工程部主任，他认为过去和现在公司在专注于技术开发。该业务正推动如自动化和云基础设施这样的新技术，同时也促进了如DevOps和设计思维这样的新技术发展。如果方法正确，这些组件可以对软件开发起到积极作用。

Stephen Felisan是Edmunds有限公司的工程部和运营部副主任，认为这种转变会带来巨大的成功，同时也为开发团队和公司带来丰厚的利润。然而，成功不需要大张旗鼓。Felisan说，在完成一系列软件开发之前，他听到了很多有关部署困难的投诉，后来他干脆装作什么都没听到。他说：“然后，公司理所当然地认为自动化部署会有作用。”

根据Felisan所说，一般像Edmunds.com这样的QA公司，不得不经历一些艰难的改革，才能确保持续交付是可行的。“不仅仅是QA公司，大多数人都不喜欢变化，任何地方都是这样。”尽管改变通常非常的困难，但是一旦人们看到了其中的价值，人们倾向于接受它。

找到一个更具协作性的策略

开发团队曾经依赖于产品拥有者来定义需求，从功能到可用性。在一种新的开发项目的初级阶段，开发人员、项目经理和运营部聚在一起开会，为了研究出项目需要什么样的初级评估。

Zadgaonkar说：“当我们问他们有关技术细节时，业务人员经常只是猜测，例如他们到底需要什么样的功能。”因为他们缺乏技术经验，所以让他们判断业务服务将需要五个9或者九个9亦或者仅需要两个9是非常困难的任务。

在Edmunds.com目前的持续软件交付模式下，开发人员和企业的利益相关者们编写服务水平协议 (SLA)，该协议是基于业务需求和技术能力的设计思想。服务水平协议服务于环境需求和环境代码文档。Felisan说：“这些信息被编入源代码，并成为实际管理它的开发人员的工作内容。”

他说，采取这些超出业务人员工作范围的技术手段并将其运用到开发项目中是有道理的。开发人员知道他们的应用程序多么脆弱，知道他们可以在多大程度上推动他们的应用程序，并且也知道如何解决应用程序中出现的问题。有些时候，SLA需要进行一些修正。

当业务需求部门和开发部门的工作内容发生分离时，两个部门需要坐下来，共同决定项目回到正轨上的正确做法。此时是项目经理大展身手的时候了。聪明的项目经理会采取协作策略，让整个团队在一起工作，并让每个员工都朝着完成共同目标的方向发展。

将其整合到一起

Edmunds.com的软件开发人员曾成功地将SLA合并到源代码中，这种成功的经验促使他们将文本内容以及视频和图片的媒体控制从内容管理系统转移到源代码中。他们进一步扩大了源代码，包括基础设施中所有配置。最近，他们已经增加了维基百科和其他外部资源的内容，因此可以打包成源代码。

保证源代码顺利进行可以增加持续软件交付的利益，也使Edmunds.com中的应用程序变得容易维护。该公司的开发人员非常依赖于Perforce的源代码管理工具。Zadgaonkar说：“Perforce是基础，我们将一切都看作是软件，Perforce将所有软件都放在同一个地方。”Zadgaonkar对Perforce提供的版本功能的影响也非常深刻。Microsoft Team Foundation Server、IBM Rational Team Concert、Apache Subversion以及其他一些项目都是Perforce的备选方案。

历史与个性

像大多数企业开发商店一样，在过去的十年里Edmunds.com发生了很多变化。在2005年之前，Edmunds.com采取了瀑布式来完成软件开发。然后，开始的采用敏捷开发方式，2006年决定采用迭代Scrum方法。在着眼于持续软件开发之前，花费了四年时间建立了敏捷组织。真正推动持续交付是在2011年底，真正发生改变是在2012年，此时公司接受了这种设计思想。

设计思维是由斯坦福大学所开创的方法，被Ideo这样的公司采用。设计思维与敏捷开发在很多方面有相似之处，但是，设计思维却愿意超越了软件开发。Felisan将设计思维看作是保证整个团队专注于最终目标的所有成员间协作过程，而不是个人协作。