软件开发项目中一个常见的争论是，是花时间提高软件质量，还是专注于发布更有价值的功能。通常，交付功能的压力主导着讨论，导致许多开发人员抱怨他们没有时间来处理架构和代码质量。这场辩论是基于这样一个假设：提高质量也会增加成本，这是我们的共同经验。但与直觉相反的现实是，内部软件质量消除了拖慢新功能开发速度的障碍，从而降低了增强软件的成本。

远程办公与集中办公之间没有简单的二分法，相反，团队的分布模式有多种，每种模式都有不同的权衡和适合的有效技术。虽然不可能确定结论性证据，但我感觉大多数团队以集中办公的方式工作效率更高。但是，您可以通过使用分布式工作模式来建立更高效的团队，因为它可以让您接触到更广泛的人才库。

技术正在变得越来越智能、越来越强大。我经常观察到，随着这些技术的引入，组织的生产力非但没有提高，反而降低了。这是因为技术增加了开发人员的复杂性和认知负担，降低了他们的效率。在本文（系列文章的第一篇）中，我介绍了一个最大限度地提高开发人员效率的框架。通过研究，我确定了关键的开发人员反馈循环，包括开发人员每天执行 200 次的微反馈循环。应该对这些循环进行优化，使其对开发人员来说快速、简单且有效。我将研究一些组织如何利用这些反馈循环来提高整体效率和生产力。

管理层喜欢他们的指标。他们的想法是这样的：“我们需要一个数字来衡量我们的工作。数字可以让人们集中注意力，帮助我们衡量成功。” 尽管出发点是好的，但用数字进行管理却违反直觉地导致了有问题的行为，并最终损害了更广泛的项目和组织目标。指标本身并不是一件坏事；只是经常被不恰当地使用。本文论证了管理层传统使用指标所造成的许多问题，并提供了一种解决这些问题的替代方案。

衡量开发人员的生产力是一项艰巨的挑战。传统的指标侧重于开发周期时间和吞吐量，这些指标是有限的，而且对于从哪里寻找其他指标也没有明显的答案。定性指标提供了一种强大的方法，可以使用从开发人员自身获得的数据来衡量和理解开发人员的生产力。组织应优先考虑使用来自人的数据（而不是来自系统的数据）来衡量开发人员的生产力。

如何提高软件开发人员的生产力？

我们看到关于软件流程、设计实践等的讨论充满了情绪化。许多争论是不可能解决的，因为软件行业缺乏衡量软件开发有效性的一些基本要素的能力。特别是，我们没有办法合理地衡量生产力。

软件界普遍接受的信念之一是，有才华的程序员效率更高。由于我们无法衡量生产力，这是一个无法证实的信念，但它似乎是合理的。毕竟，几乎所有的人类活动都表明，有些人比其他人做得更好，而且往往明显更好。程序员自己也经常观察到这一点，尽管似乎总是那些认为自己属于更有才华的人才会注意到这一点。

精心设计软件值得吗？

许多人认为，在敏捷项目中不能签订固定价格合同。由于敏捷流程的重点是您无法预测未来，因此这种假设并非没有道理。然而，这并不意味着您不能签订固定价格的敏捷合同，这实际上意味着您不能签订固定范围的合同。

我最喜欢的一句妙语是：如果它让你痛苦，就更频繁地做它。它有一个令人愉快的特点，那就是表面上看起来荒谬，但当你深入挖掘时，就会发现它蕴含着一些有价值的意义。

想象一下，一个团队正在为一个购物网站编写软件。如果我们查看团队的产出，我们可能会考虑他们在上个季度开发了多少新功能，或者是一个跨职能的衡量标准，比如页面加载时间的减少。然而，结果衡量标准会考虑衡量销售收入的增长，或者产品支持电话数量的减少。关注结果而不是产出，有利于构建能够更有效地提高软件用户和客户效率的功能。

关于结对编程的一些常见误解。

DevOps 现状报告是一份年度报告，它使用调查数据的统计分析来确定软件交付组织的有效实践。其主要作者是 Nicole Forsgren、Jez Humble 和 Gene Kim。

我经常遇到一些开发人员，他们感到沮丧，因为“管理层想要更多功能，他们不关心质量”。每当我听到这句话时，我都会感到难过，因为我知道，开发人员、管理层和他们的客户都已经失败了。他们的失败是由于将情况框定在*可交易质量假说*中造成的。