软件的软性层面
PDF精益软件开发 — 构建和发布两个版本
在满足团队目标的同时，发挥开发人员的优势
Kate Matsudaira
从前，很久很久以前（所有好的故事不都是这样开头的吗？）……我当时管理着一个软件团队，我们正在进行几个项目。项目分配是基于谁有空、他们的技能以及他们的发展目标。结果，两位开发人员，我们称她们为 Mary 和 Melissa，被分配到了同一个项目。
Mary 和 Melissa 一起工作了几周后，我开始在与她们各自的一对一谈话中听到她们对彼此的抱怨。Mary 抱怨 Melissa 花太长时间做她的部分，并且在单元测试上花费时间，而这些单元测试没有意义，因为项目的事情还在变化中。与此同时，Melissa 抱怨 Mary 写的代码很草率，并且没有编写足够的测试（她甚至给我看了代码中的注释，例如“hack:....”和“to do: 应该有人在这里添加更多错误处理”）。她们每个人都对对方提出了有效的观点和反馈。
在接下来的几周里，我花时间指导她们每个人如何改进并解决对方的担忧。对于 Mary，我专注于推动她编写更多测试，而不是仅仅把东西拼凑在一起；对于 Melissa，我专注于让她快速原型化一些东西，然后在它工作后再进行润色。她们两人都非常努力地尝试了，但两人都很痛苦。这根本不是她们注定要做的事情。
这两位女性根本不适合合作。这让我开始思考：我们如何改变流程，使她们两人都可以按照自己喜欢的方式编写代码（并发挥她们的优势），同时我们仍然可以实现我们的团队目标？
由此诞生了 v1/v2 开发流程。
你看，某些开发人员喜欢构建第一个版本或原型 - 他们是那些喜欢将各种东西拼凑在一起以快速使某些东西工作的人。他们喜欢（并且最擅长）构建产品的版本 1。另一种类型的开发人员喜欢构建第二个版本。他们将代码视为一种工艺，并为所有内容编写单元测试。“测试覆盖率”和“漂亮的代码”是他们经常使用的短语。
当然，这个定义不是非黑即白的——有些人会在不同的时间落在界线的不同侧，所以它更像是一个光谱。
通常，v1 类型的人不喜欢与 v2 类型的人一起工作，反之亦然——不是出于个人原因，而是因为他们思考和创建软件的方式不同。从根本上说，他们享受自己所做事情的根本原因不同。
通过改变我们对软件的看法，我们能够解决这个问题，并实际上使团队更具敏捷性，并在过程中解决一些业务问题。
v1/v2 流程
当涉及到软件开发时，有很多方法可以构建和创建产品。
以我的经验，第一次就构建出正确的产品是很困难的。我所说的“正确”不仅仅是指客户想要和使用的东西，并且希望能够产生收入，还包括正确的技术解决方案。客户将如何使用产品可能很难预测。例如，在发布产品的第一个版本之前，可能很难回答诸如以下问题：
• 数据增长的速度有多快？
• 写入需要多快？
• 直接写入数据存储是否可行？还是需要队列来管理写入？
• 吞吐量是多少？是否足够？
• 系统是否会随着使用量而扩展？
即使您可以合理地回答这些问题，或者如果您构建了一个考虑了所有这些因素的系统，以便您可以“只需添加硬件”，那么工作量可能比您仅仅推动快速发布第一个版本更大。而且，这样的系统很可能（即使不总是很可能）会被过度设计（因为它被设计为以可能无用的方式解决问题或扩展），甚至会有其他无法预见的问题。虽然第一次就做对肯定有优点，但实际上很难做到正确，而且构建最终系统将花费更长的时间，从而延迟回答所有表明您正在朝着正确方向前进的问题。
有一个流行的运动叫做精益创业，它提倡快速迭代和数据收集，以便尽快找到正确的产品和需求。这一切都是为了弄清楚客户将使用什么，然后构建这些东西。这些想法也可以应用于我们构建产品的技术方式。
快速构建 v1，然后正确构建 v2
类似于创建最小可行产品 (MVP)，构建满足业务目标的最小可行技术实现（意味着产品可以满足当前的使用需求和性能）。
大多数工程团队都被教导从一开始就考虑软件设计和架构，并构建可以扩展的东西。但是，如果您还没有任何客户，那么扩展真的不是您的挑战。因此，在某些方面，当您尚不需要扩展时就为扩展而设计是在解决错误的问题。
当然，我不是提倡做一些愚蠢的事情或编写糟糕的代码，但不要过度设计或在您遇到问题之前就解决问题。这里有一些例子：
• 放弃部署多节点 Cassandra 集群，并将初始数据存储在单个数据库（带有备份）中，该数据库速度快且易于执行任意查询
• 使用标准表单和图表进行更快的 UI 开发，而不是有趣的形状或花哨的自定义图形
• 在单元测试（因为单元正在变化）或注释和文档方面偷工减料
所有这些捷径都将帮助您更快地发布某些东西。它们可能不是最佳实践，但它们确实确保您正在构建正确的东西。
在许多方面，这个过程是关于以不同的方式看待问题，而不是解决“大”问题，而是专注于速度和效率——为您的开发资源获得最高的 ROI（投资回报率）。
因此，您修改您的开发流程以快速发布第一个版本，然后在 v1 发布后，计划立即开始 v2。
那么您的 v2 可以解决产品第一个版本的所有问题。您可以根据客户的使用情况和反馈改进可用性、删除或添加功能、选择合适的技术和库来支持产品，并花时间编写不太可能更改的验收测试和单元测试。从业务角度来看，您可以更快地将产品推向市场，因此很容易看出该产品是否会带来收入和成功。
为什么这个过程有意义
它降低了过度设计的风险。 如上所述，更快地发布某些东西并了解它的使用方式（或它在市场上的成功程度）将有助于确认您正在构建正确的产品，并为您的业务解决正确的技术问题。这使您可以降低构建或扩展可能无法解决生产问题的系统的风险。
如果您构建了错误的东西，您可以纠正它。 由于该产品确实是最小可行产品，因此您可以降低浪费资源创建错误产品的风险。此外，您将在发布周期的早期获得反馈，并且可以更快地进行调整或更改（因为更改一个具有大量移动部件的系统总是更困难）。
您更有可能更快地进入市场。 快速构建某些东西将帮助您更快地发布，这将帮助您更快地测试和确定产品的可行性，而不是等待更大的发布。这意味着您不会花时间构建客户不会使用或您无法销售的软件。
人员配备和员工幸福感。 这是此方法最大的优点之一。软件工程师可以以一种符合他们优势的方式做他们喜欢做的事情。此外，他们不会被迫与不认同他们方法的人一起工作，而且他们不必在他们无法塑造成他们想要的艺术品的代码库中工作。
那么缺点是什么？
构建的总时间比您第一次就做对要长。 在此模型中，v2 开发很可能会稍后完成，并且总开发时间将比您构建一次产品要长。如果您使用一种技术构建 v1（例如，无法按您需要的方式扩展的 MySQL 数据库），然后 v2 需要另一种技术（例如，用于更快查询的适当键值存储），团队将花费时间在一个数据库上进行发布和构建专业知识，最终却不得不学习和管理另一个数据库。
运维可能很麻烦。 大多数经验丰富的工程师都会告诉您，如果使用量或数据以未考虑的方式增长，那么快速构建某些东西可能会导致运维噩梦。没有团队喜欢运维和救火。当然，如果这是一个问题，可能意味着您的产品已经获得了一些采用和成功，所以至少您正在解决一些产生真正价值的东西。但是，即使对于 v1，识别风险和潜在瓶颈仍然是值得的，因此，如果出现问题，团队将有一些解决方案的想法。
那么你想在家试试吗？呃……工作？
像任何软件流程或方法一样，重要的是评估这是否对您的业务、产品和公司有意义——它当然不是一刀切的。但是，它肯定有其优点，所以请随意借鉴您喜欢的部分。
如果您确实开始这段旅程，以下是我根据我的经验给出的一些建议：
获得管理层的支持。 这非常关键，因为这种方法成功的关键始终是构建 v1 和 v2。如果您没有获得支持，并且您的老板满足于保留和运行 v1，那么您的团队会讨厌您。真的。没有人愿意无限期地陷入支持老旧的 v1 软件的困境。因此，请确保每个人都事先知道并理解计划。
衡量一切。 为了构建正确的 v2，您需要知道要构建什么。您的瓶颈在哪里？数据如何增长？没有这些数据，很难实现此模型的许多优势。确保在产品发布之前考虑您需要衡量什么，以及如何衡量它。
v2 将比 v1 花费更长的时间。 我个人已经看到这个过程在四个项目中演变（不，这不是一个很大的样本集），并且在每种情况下，v2 的创建和发布时间都是 v1 的两倍以上。当然，我发布的每个 v2 都有很多额外的功能，而且它们并不总是利用 v1 代码的很多部分。有些人认为 v2 会更快，因为“您以前已经构建过一次了”，但我没有发现是这种情况。
与您的客户保持紧密的反馈循环。 确保可以轻松了解人们使用什么、他们喜欢什么以及他们不喜欢什么——这样您就可以构建一个出色的 v2。
确保 v1 和 v2 受到同等重视。 有时，团队或公司庆祝一个功能的首次发布的方式比下一个版本更盛大。但在这种情况下，下一个版本是您发展业务所需的。它与 v1 同等重要，甚至更重要。确保您平等地重视它们中的每一个，否则人们会倾向于选择最受关注的项目，而不一定是适合他们优势和才能的项目。
对人们擅长 v1 和 v2 都要保持开放态度。有时我认为我已经了解了某人，然后他们证明我错了。要接受并非只有两种类型的人，有些人只是擅长一切。（我只是希望我是那些人之一！）
我希望这些想法中的一些对您和您的团队有用。如果有什么的话，让这个轶事激励您质疑您做事的方式，并批判性地看待改进软件构建方式的创新方法。
喜欢它，讨厌它？请告诉我们 [email protected]
Kate Matsudaira 是一位经验丰富的技术领导者。她曾在微软和亚马逊等大型公司以及三家成功的创业公司（Decide 被 eBay 收购，Moz 和 Delve Networks 被 Limelight 收购）工作过，之后创立了自己的公司 Popforms，该公司被 Safari Books 收购。她在早期职业生涯中是一名软件工程师，技术精湛，并在分布式系统、云计算和移动领域做出了领先的工作。然而，通过管理整个产品团队、研究科学家以及建立自己的盈利业务，她证明自己不仅仅是一位技术领导者。她是一位已出版的作家、主题演讲者，并荣获了西雅图 40 位 40 岁以下杰出人士等奖项。她担任 的董事会成员，并在 katemats.com 上维护个人博客。
© 2015 1542-7730/15/0500 $10.00
最初发表于 Queue 第 13 卷，第 8 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求的考虑，存在许多用于加密哈希的标准，但在非加密方面，存在一定的民间传统，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 实践
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直观地看，技术领导者普遍认为，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极低代码技术进行的实验室实验结果来研究生产力差异，从而提供关于该主题的新见解。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，在这个世界中，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在追求快速发展的过程中，它会受到时尚的支配，并且可能会忘记或忽略一些已证明有效的解决方案，以解决它面临的一些永恒问题。用例于 1986 年首次引入，并在后来普及，是这些已证明有效的解决方案之一。
© 保留所有权利。