5.尽可能自动化和标准化

    自动化使你能够在不占用宝贵的人力资源的条件下，完成重复的任务。标准化确保你的自动化的输入和输出每一次都是一致的。

    在我们参与项目前，工程团队手工制作可部署的软件包。新软件包当时不能保证与上一个软件包相同;事实上，甚至不能保证它是他们开发的软件，更不能保证它是否能运行!创建具有他们在一个可能部署的结果中提供的特性的软件包常常需要技术人员花很多天时间。

    我们立即设计了一个部署工程团队将提交给我们的软件包的结果和接受标准，并帮助他们实现制作软件包的标准化。这触发了部署在每一次发行时的一致的结构中构建软件的自动化的过程。

    发行软件打包突然不再是个问题。因为我们自动完成接受标准的检验――例如，这段代码必须在提交和测试之前进行单元测试，以确保它可以得到部署――因此我们保证了它的可执行性。因此，我们能够在非常短的时间内利用一条命令进行完成的代码的打包、确定版本以及测试和部署。

    但是，自动化并不仅限于此。在每一个开发周期中，我们有更多的回归测试要做。已有的回归测试手工执行需要3个月时间;因此，发行的软件从没有得到完全的测试。

    我们新建立的发行周期意味着在我们能够发行软件投入生产应用的两周内，软件必须完成回归、性能和集成测试。我们可以通过为每一类测试建立不同的环境来克服不同的测试类型(集成和性能)的问题。但我们怎样才能将3个月的回归测试压缩到两周的时间窗里呢?

    首先，我们发起了一次确定优先重点的运动。客户确定了最高优先级的回归测试：他们接受的作为老功能仍在工作的证明的最小值。然后，我们着手自动化完成这些工作。随后的接受测试还实现了自动化，从而确保我们可以在几个小时而不是几天回归测试每一发行版本。

    6.建立正面的预期

    如果发行软件对于你十分重要的话，不要对它秘而不宣。当我们的团队知道这十分重要时，他们改进了提交软件版本的承诺。

    我们通过确定指定的发行经理在团队同意软件准备就绪时预测软件准备就绪来支持这种重要性。我们让程序经理(实际上是我们的客户)向团队解释这个软件版本为什么重要的原因。(最终，这归结于损失数百万英镑!)

    我们要求工程团队提交的软件符合标准(确定了版本、经过测试、提供文档资料和打包);我们确定我们将在每一个发行周期需要这种标准包。我们必须解释我们为什么以这种方式需要软件(它使我们的自动化过程变得更容易、更一致)，并且我们将工程团队的反馈融入到发行工程中。

    建立正面的预期是增加每个参与这个过程的人的动力的非常好的办法。我们没有被赋予任何行政权力，因此不害怕制裁或开除。相反，我们利用正面预期的力量，让人们参与进来帮助我们改进发行过程。我们让个人做出关键决定(他们以前从未感到能这样做)，因为“"Mike 和Tym周四前需要这个软件，我们说我们将提交它。”

    7.向人员投资

    不管我们在硬件、软件和神奇的过程上花了多少钱，没有团队成员的积极参与，你在发行软件上享受不到可持续的成功。更糟的是，你甚至最后不能发行任何软件!

    你可能认为我们要谈的是找到合适的人员并重奖他们，或者认为我们要谈的是工程团队完成工作所需要的工具和技能。事实是，你知道你应当为你的团队找到合适的人员(“合适”的定义对于不同行业是不同的)，你应当恰如其分地根据他们提供的价值奖励他们，是的，你应当确保他们拥有他们所需的工具和技能。

    一个基本的前提是，人们本质上对做好的工作感兴趣。如果你想让团队成员关心你的产品，关心做好工作，你首先必须证明你关心什么对于他们重要。从项目一开始，我们就在相互尊重和理解的基础上，与团队中的每个人建立了非常好的和谐关系。我们证明我们灵活处理个人面对的挑战，我们尽我们的可能提供帮助。不管这是购买午餐、提供饮料、组织培训与整理建议、倾听问题或扮演辩论时的对立面，我们都去做各种让每个人都感到作为发行过程的关键部分的价值所需要的事情。

    当谈到项目时，我们发现一种普遍的冷漠感。一些长期的永久雇员只简单地等待冗余包;另一些人由于从来没有把事情做好而从不被要求做任何事情。让许多人回到关心向发行过程贡献他们的个人价值的状态，需要大量的人际关系建设和时间投入以及正面的肯定。

    发行管理是任何软件项目非常重要的部分，但常常没有给与应得的重视。在我们理顺这个中型电信企业的软件发行过程的经验方面，我们还有很多很好的提示、建议和结论。但上面的7条是这个案例中对于我们最重要的7条经验，尽管我们期望它们成为应用于任何案例的好想法。

    好的发行管理需要艰苦的工作、坚定的决心和通畅的交流勾通;但是，最伟大的技能是审查、学习和适应改进的能力。