如果没有截止日期，编写的软件会质量更高么？

对开发人员保密

> Photo by Zach Betten on Unsplash

如果您有世界上所有的时间，您将如何编写软件？ 您会做与现在不同的事情吗？ 这是极限编程中的一个问题。

您一定听说过项目管理三角，对吗？

制作一个三角形，在每个点上，您都会有以下变化：成本，时间，范围。 您只能控制三个中的两个。

在三角形的中心是一个点，当它移向任何一个角时，它必须与其他角移得更远。 这是一个有用的概念，但是缺少一些东西。

那么质量呢？

让我们放弃三角形，然后想象一下控制各个方面的一系列刻度盘。 作为客户和付款人，您将范围扩大到10，表明获得所有功能是最重要的考虑因素。

但是这样做，成本和时间刻度也被设置为0。它们将被牺牲在示波器的祭坛上。 因此，您需要一点拨 时间，因为圣诞节之前您需要所有功能。

这样做会降低质量表盘，因为提供所需功能的唯一方法是接受技术债务并跳过测试，重构和同行评审之类的事情。

这是很典型的。 在开发人员和利益相关者看来，质量通常是最灵活的要素，即使他们不同意。

我听过很多团队说过这样的话：”我想编写测试，但我没有时间”，或者：”我们将在下一个版本发布后进行重构。”

有时，这是必要的-无论您的体系结构多么漂亮，延迟交付都将错失机会成本。 有时，您根本没有钱雇用30名专业开发人员，因此您可以利用自己拥有的一切。

但是我曾经有幸在质量至上的公司工作。 如此之多，以至于尽管有一个由40名开发人员组成的团队和5年的生产软件，但他们只有两个人从事支持工作，而这两个人每周都要更换。

轮到我时，我继续进行日常工作，并在一周内总共处理了两张简单的支持事件。 我曾在一些规模较小的公司工作，他们有专门的支持人员团队，他们在飓风中肆虐。

这个团队的素质来自于他们对极端编程的严格遵守以及他们称之为黄金法则的东西：

开发团队不得知道任何截止日期。

他们没有发明这个概念，但这是我第一次看到它起作用，因为每个人都相信它。 唯一知道截止日期的人是产品所有者，他们有恪守黄金法则的正直，信念和权威。

那么，为什么我认为这很重要？ 进行以下对话：

老板：”要交付此功能需要多长时间？”您：”一周”。老板：”还不够好！”您：”好，一天。”

发生了什么变化？ 你是第一次说谎吗？ 您的老板是否激发您在更少的时间内编写更多代码？ 您可能已经调整了估算，使其更加可口。 我们已经做到了，以后再后悔。

我看到不成熟的Scrum团队一直在发生同样的事情：您强加了这些人为的截止日期，最终每两周就要着急完成工作。

有了一点点烟雾和镜子，您就可以通过sprint审查获得用户故事，而无需进行测试或使用一些硬编码的数据。 无论您需要注销什么。

这很糟糕，因为现在您要在后脚开始下一个冲刺。 您只是根据产品对完成的定义告诉产品所有者，故事A已完成。

大概，您对”完成”的定义不会说：”对偶然的观察者来说，它看起来已经完成了。”

因此，在下一个冲刺中，当产品负责人认为您正在处理故事B时，您实际上仍在完成故事A中未完成的工作。

或更糟糕的是，您减少损失并继续前进，接受技术债务是别人可以偿还的。

因此，假设我们要延迟交付并想尝试修复它。 我们认为我们可以控制什么？

1.范围

首先是范围。 好吧，这是显而易见的选择，但是碰巧的是，我所工作的团队已经非常擅长弄清楚任何给定故事的最低可行产品是什么，因此范围已经尽可能地缩小了。 。

当然，产品负责人可能有更大的影响力，但在大多数情况下，情况并非如此。

对于那些没有在利益相关者，产品所有者和开发人员之间实现最高协调的人来说，如果不能按时完成任务，那么范围绝对是您应该考虑的第一件事。

2.费用

其次是成本，通常是指资源（我讨厌资源一词，因为开发人员不可替代，但我们继续吧）。 一种建议的解决方案是加班。

XP的核心原则之一是，如果您的团队必须连续两周加班，那么有些问题就需要解决。 除非紧急情况，否则不要加班，因为这会使团队精疲力尽。

另一个建议的解决方案通常是雇用更多的开发人员。 从长远来看，这可能会奏效，但是即使是最有经验的开发人员也需要花费时间来熟悉该项目。

雇用更多的开发人员是解决短期问题的长期方法。 它现在无法帮助您更快地交付。 有时，从长远来看，它甚至都无济于事。 请记住，有九个女人一个月内无法生孩子。

3.质量

我们可以牺牲的最后一件事是质量。

换句话说，我们可以偷工减料。 您可能会跳过同行评审或暂时禁用一些失败的测试，因为它们需要重写。 您积technical了技术债务，从明天开始有时间支付今天的问题。

在我供职的公司中，几乎在每种情况下都不选择牺牲质量。 必须牺牲质量的地方是暂时的，坚决承诺以后再还钱。 尽管想一想，但我一次也看不到看到他们诉诸于此。

因此，通过消除范围，成本和质量作为可变值，唯一的结论是时间不可能成为最重要的。

它不一定是最不重要的，因为通过遵守MVP，范围已经被牺牲以促进快速交付。 但是，它的重要性不如质量，提高成本直到为时已晚才产生可观的影响。

因此，不要给开发人员任何偷工减料的诱惑。 取消最后期限，让他们做出正确的选择来交付高质量的软件。

从长远来看，这将减少专门的支持团队的成本，从而带来红利，并且通常可以通过编写易于使用的代码来加快交付速度。

我想向那些认为您的团队不可能做到的人提出挑战。 向您的利益相关者解释这个概念。 请务必说明最低限度可行产品的概念（我将在博客中单独介绍）。

要求他们按重要性顺序对四个变量进行排名。 我希望他们给你这样的东西：

· 高质量

· 快速交货

· 低成本

· 宽范围

让他们负责，并确保您的产品所有者也这样做。 您可能会惊讶于这种想法与付账人的共鸣。