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

在理想状态下，产品型组织由松散耦合、自主的团队组成，这些团队能够对明确和未明确的用户需求做出快速响应。然而，有时会出现需要跨多个团队协调才能应对的机会。如果管理不当，结果将导致收入损失、客户不满意和团队能力浪费。我们将应对这些机会的组织计划称为项目。在本文中，我们将通过一个失败项目的例子，分享我们在产品型组织中管理项目的经验。

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

启动是在项目开始时进行的一项活动，目的是将相关人员聚集在一起，为正在进行的工作设定共同的方向和工作方式。精益启动是一种集中的启动形式，可以在一周内完成。在此期间，我们将了解产品的关键功能和客户，并构建一个画布来制定最小可行产品的特征。

一致性地图是组织信息辐射器，有助于可视化正在进行的工作与业务成果之间的一致性。这项工作可能是常规功能添加或技术工作，例如重新架构或偿还技术债务或改进构建和部署管道。团队成员使用一致性地图来了解他们的日常工作旨在改进哪些业务成果。业务和 IT 负责人使用它们来了解正在进行的工作与其关心的业务成果之间的关系。

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

持续流是一种安排工作的方法，通常与敏捷软件开发相关联。团队将软件的功能分解成用户故事。然后，他们将这些故事按优先级排列成一个粗略的列表。然后，团队会从这些用户故事中挑选一些来处理，当他们完成一个故事后，他们会从列表中提取下一个故事。

在设计耐力假说中，设计收益线是指在该功能量以下，可以用设计质量来换取上市时间。

技术债务是一个非常有用的概念，但它提出了一个问题，即如何衡量它？遗憾的是，技术债务不像金融债务，因此很难说你欠了多少债务（尽管我们最近似乎在衡量金融债务方面遇到了一些麻烦）。

你不能把十磅重的屎装进五磅重的袋子里

-- 任何尝试过的人

当 Kent 和我写《规划极限编程》时，我们加入了这句异想天开的引言，以帮助理解规划的本质。

许多人认为，在敏捷项目中不能签订固定价格合同。由于敏捷流程的重点是无法预测未来，因此这种想法并非没有道理。然而，这并不意味着你不能达成一份固定价格的敏捷合同，它真正意味着的是你不能达成一份固定范围的合同。

许多公司喜欢签订固定范围和价格的合同，因为他们认为这降低了他们的风险。这种幻觉认为，他们的财务义务固定在交易价格上。如果他们没有得到满意的软件，那么他们就不会有任何损失。

一个常见的问题是，大型项目是否可以使用敏捷技术来完成。毕竟，许多敏捷方法都是为较小的项目设计的，而它们所抵制的那些重量级思想在更大的项目中更需要。

在我最近的客户合作中，我预见到无服务器架构是一个完美的选择。然而，采用无服务器架构的想法并没有得到我们客户的认可，因为他们担心供应商锁定。对于零售商来说，这是一个有趣的时期，因为留在 AWS 可能意味着亚马逊作为另一家零售企业，将获得竞争优势。考虑到不支持竞争对手的想法，我的客户希望确保我们选择的解决方案可以完全移植到其他云供应商。

软件的好处之一是人们似乎想要它，而且想要得很快。组织要求团队加快软件生产速度是很常见的，而且组织不时地会寻求以真正体现其承诺的方式提供帮助——花钱为团队增加人手。

我第一次接触敏捷软件开发是在极限编程的黎明与 Kent Beck 一起工作。那个项目给我留下深刻印象的一件事是我们进行规划的方式。这包括一种轻量级但比我以前见过的更有效的估算方法。十多年过去了，现在经验丰富的敏捷人士之间出现了一种争论，即估算是否值得做，或者实际上是有害的。我认为，要回答这个问题，我们必须看看估算将用于什么目的。

敏捷开发的一个关键特性是弄清楚如何使系统只使用一小部分功能就能上线运行。我们构建软件是为了它提供的商业价值，我们上线的速度越快，我们就能越快地获得至少一部分商业价值。

敏捷开发的基本原则之一是，需求变更不仅是预料之中的，也是受欢迎的。当像 Thoughtworks 这样的外部公司为客户工作时，这构成了一个特殊的挑战。许多客户希望签订固定价格协议，这实际上是固定范围，因为他们看到了固定范围的幻觉。但是，固定范围的合同与敏捷开发完全不一致，那么像我们这样的公司该怎么办呢？

使用时间盒迭代的一种常见方法是为每次迭代分配尽可能多的用户故事，以便最大限度地利用相关人员。闲置时间是指故意留出未分配给故事的时间，将这些时间用于计划外工作。虽然这看起来效率低下，但它通常会显著提高团队的生产力。

最近我听到了一些关于为多个使用极限编程计划方法的团队制定标准故事点机制的问题。他们希望几个团队都使用等效的故事点，以便一个团队的三个故事点的工作量与另一个团队的三个故事点相同。

我认为尝试想出这个办法往好了说是价值有限，往坏了说是危险的。

如果您正在使用 XP 风格的计划，您需要从开发人员那里获得快速的共识估算。抛出估算可以让您快速判断开发人员对估算是否有相似的看法（以便您可以记下它并继续进行），或者是否存在分歧（当您需要更详细地讨论用户故事时）。

时间盒迭代是一种划分和安排项目工作的方式，尤其适用于敏捷软件项目。团队将软件的可见功能分解成用户故事，并将时间分解成固定的周期（例如一周），称为迭代。然后，他们通过将故事分配到迭代来安排故事。故事会被粗略估计，以便团队能够计算出一个迭代中可以容纳多少个故事。

速度是一个概念，它通过将广泛的工作量陈述与经过的时间联系起来，帮助校准计划。速度是指一个团队（如果是个人速度，则指一个人）在一段时间内完成多少工作的陈述。您通常应该通过测量过去一段时间内完成了多少工作来确定速度，遵循昨日天气的原则。一种典型的方法是将过去三个时间段的速度平均，以确定未来时间段的速度。速度最初是作为极限编程的一部分形成的，但后来传播开来，现在广泛应用于各种形式的敏捷软件开发中。

YAGNI 最初是一个首字母缩略词，代表“你不会需要它”。这是极限编程中的一句口头禅，在敏捷软件团队中也经常被普遍使用。它指的是，我们认为软件将来可能需要的一些功能现在不应该构建，因为“你不会需要它”。

这条原则说的是，你今天完成的工作量将与你昨天完成的一样多。在迭代项目中，它指的是你应该计划在这个迭代中完成与上一个迭代一样多的工作。这个词来自极限编程社区。