ACM通信

• 利益相关者识别
• 了解并记录优先事项
• 高效的开发团队
• 有效的开发工具
• 有效的端到端测试模式
• 高代码质量
• 有效的代码部署模式
• 高部署速度
• 有效的操作工具
• 快乐的用户

这是一个很好的清单，对吧?所以，去做吧。严重,就这样做．

开发中最难的部分是确定优先级，这是因为人类是不理性和不可预测的。没有任何开发方法能够解决这个问题。如果涉及多个涉众，特别是多个涉众，情况就更加复杂了组的利益相关者。唯一的方法是用强制的优先级记录需求，并不断提醒人们它们是什么以及相应的状态。工具是有帮助的，但更多的是关于围绕工具的沟通和理解。如果没人相信它所说的话，再花哨的工具也无济于事。

有人难免会哭，“但我们需要灵活!”这很好。这是好吧不时地改变优先级。但相对的优先事项也必须改变，之前设定的预期也必须改变。那是最难的部分。得到之前的期望是不公平的而且修正预期;这是疯狂的说法。再说一次，这是人类的问题。不要忘记，在软件发布过程中任意地踩下紧急刹车，可能会使开发工作停滞不前。当然，这只是比喻。

接下来，为目标时间线的直接优先级用例设计软件。在前面的句子中有很多重要的限定词，如“立即的”、“优先的”和“有目标的时间线”。软件设计总是有上下文，因为软件工程是一门艺术权衡．有总是权衡。坦克不是轿车也不是赛车也不是卡车，但它们都是有效的交通工具。我们从经典中知道，比如设计模式(Gamma，等)和重构清晰的软件设计、可配置性和可扩展性很重要，但我们也经常忘记利用每一个单一的设计模式并不是重点。猜测在用例上——功能和技术上——几乎总是使结果更糟。记住Knuth的名言:“过早优化是万恶之源。”他很久以前就发现了这一点，从那时起，软件世界只会变得更加复杂。诱惑和干扰无处不在。

五角大楼的战争是一部被低估的1998年的喜剧，它描述了一个虚构的和讽刺的发展布拉德利战车，试图成为每个人的一切．这是基于非常真实和严肃的书五角大楼的战争是关于武器设计和采购的。这是完全合理的，我们希望做出设计上的权衡在我称之为“目标用例”。只是要知道，当权衡变得如此之大时，它们会损害所述案例的完整性和有效性。工程既是科学又是艺术，没有任何开发方法可以解决这个问题。

我曾经在一家公司工作，有人非常支持控制反转模式。这个人非常喜欢这种模式，以至于产生的代码很难理解，也无法测试。事实上，单元测试都被配置为模拟实现，以至于测试的只是假代码。这似乎太荒谬了，不可能是真的，但它确实发生了，一旦实际的代码部署到实际的客户，这是一场灾难。我被拉进来清理这个，因为每个版本都需要大量的紧急修复程序。不要过于迷恋某个技术模式或框架，因为它会模糊人们对应该首先解决的真正问题的视野。

然后自动化，自动化，再自动化。从低级的构建过程到单元测试，到环境设置，到部署，到所有形式的监视和度量收集。这是显而易见的“代码应该始终工作并处于可部署状态”咒语。显而易见，但不一定容易因为把资源投入自动化需要纪律——这又是一个人为因素。好消息是，在过去的几十年里，这个领域的框架和技术有了很多改进和进步，可以提供帮助。捡起谷歌SRE书籍首先。

找出适合用户基础的最频繁的发布周期。这可能因行业而异，通常技术方面并不是决定因素。能够尽可能快速、轻松地发布高质量的产品。

最后,进行迭代。继续．交付速度就是生命。对任何软件产品来说，最糟糕的事情就是盛宴和饥荒的循环，没有任何开发方法可以解决这个问题。保持势头可以说是最困难的方面，因为持续向前的进展完全依赖于人力因素，比如投资组合优先级、资源、预算，以及其他事情，比如您的软件在市场上的表现如何。管理人力和资金的困难由来已久。但也不是没有希望，只是很难。所以赶紧行动吧。

我在几年前的Strata Data会议上听到过这个:“如果你的软件成功了，你就永远不会结束这是明智的建议。同样，一个人实际上可以确保软件解决方案不通过不稳定的交付获得成功。

我曾见过太多的人为了某种特定的开发方法而不惜牺牲整个项目的成功。但是一个开发方法只是一个“如何”——它不是目标．虽然没有任何软件的成功是可以保证的，但是开发团队快乐的最好机会是关注共同的人为因素，比如涉众对齐、优先级、沟通，以及保持前进的纪律。并且谦逊地接受错误将不可避免地出现，并在未来的版本中尽可能快地解决。