规划和估算大型软件项目

这个周末我和一个朋友谈论我是如何在我以前的一份工作中计划和估计一个巨大的软件项目的。我的意思不是一个团队可以在一两个冲刺中完成的事情，而是需要几个团队，跨越几个季度的努力，涉及许多非工程团队成员的其他部门的事情。敏感的商业细节和公司名称显然不是真实的 - 保护有罪的人（等等，那是我！）无辜！ 😂 这将是一个很长的帖子，因为我们正在处理的项目可以很容易地达到员工工资的八位数。并成败整个公司。没有道歉。让我们首先解决这个问题：估算是软件开发中最困难的部分之一。它们从来都不是完全正确的——事实上，大多数时候它们并不比有根据的猜测更正确——这对于一个习惯于确定性工作的工程师来说是难以接受的。也就是说，我还没有在一家公司工作过，在那里他们不是必要的邪恶。工程不是在真空中工作的，并且有一些商业合同将在没有你参与的情况下签署，在高层。在您加入组织之前已达成一致的交易。与具有特定发布日期的其他公司“搭档”。营销和财务部门想知道他们何时需要花费 xm 来制作圣诞广告活动。整个团队的人，他们不是软件工程师，并且习惯于对他们领域的交付日期负责，他们希望你能够告诉他们你的项目部分何时可能完成。有很多关于如何为单个团队估计速度的信息——无论是通过计划扑克、故事点还是完全没有估计的积压故事跟踪，但这些都不适用于涉及多个团队和部门的大型项目。

如果你是领导——也许你是一名建筑师，或者是一名工程经理——你会被要求为主要项目做出估算，如果你的估算离目标太远，你应该被追究责任，因为你在提出它们时没有做尽职调查。您需要对需要构建的内容有所了解。在某些情况下——比如你正在建造的东西是大公司之间合同的结果——这可能包含在大量的合同文书、演示文稿和附录中。您可能很幸运有业务分析师与您合作（或阅读合同，或与客户合作！），或与您的用户合作的用户研究人员，或具有深厚主题专业知识的产品主管，他们可以大致告诉您需要构建什么.如果你不走运，你需要花很长时间和他们交谈，然后自己写下来。但必须写下来。在这个阶段，不要担心格式；我有 200 页长的 Google 文档、10,000 行长的电子表格、1.5Gb 的幻灯片和完整的用户故事书。稍后你会组织起来。你必须明白你被要求构建什么，否则你将盲目工作，之后你所做的一切都将是胡说八道。边走边问，以确保您了解要构建的内容。让为你获取这些信息的人保持亲密和快乐；你会需要他们在你身边，检查你的工作（和开发团队的工作！）每一步。估算复杂项目的第一条规则：您必须了解要构建的内容。

现在您明白了您被要求制定什么计划，这就是您作为技术领导者开始赚取报酬的地方。您之前阅读和理解的信息现在需要组合成连贯的“盒子”。我找到的最好的工具是物理索引卡 - 但也有数字替代品。一个实际的索引卡 - 编辑 - 我在分解最新项目时写的。左上角是“代码”，可用于规划软件以在将其分配给团队时引用此任务。顶部中心是对包含基本要求的原始电子表格的引用，右上角是颜色编码，表明我们所针对的 MVP 需要此功能。我将在此处和接下来的几个步骤中使用电子商务市场的示例。假设您在上一步的合同或电子表格中的某个地方有这些要点： 一个高效的敏捷实践者应该在这里提出一些问题。例如，她会抱怨“我们在发布时绝对需要折扣功能吗？”；在每一个机会中，您都应该尝试尽可能多地放弃范围。一般来说，这类大型软件项目是基于合同需求或产品发布——所以你应该在每个阶段尝试尽可能多地分解，以确保你只构建真正的 MVP。但是，假设您得到了“我们在合同中同意建造所有这些”的非常无益的答案（这种情况发生的比我希望的要多）。好的。假设在发布前所有这些都是必需的，您可以将它们组合在一起并编写以下索引卡： 希望您能看到您的工程技能如何开始发挥作用；以这种方式拆分需求有意义吗？

给定这些盒子中的每一个，工程团队是否能够将它们构建为不同的“事物”，并在“完成”时庆祝，每个人都可以构建可交付的功能，可以单独评估？是否存在您必须在两个或多个步骤中构建的跨领域问题，这些问题可能更适合拆分为早期需求？一位熟练的技术专家将利用她在这里的经验在早期阶段尝试避免依赖关系，并推回“厨房水槽”的要求，即使在早期阶段，公司也会通过缩小范围或开设一个来避免的陷阱。与客户对话。伟大的。现在您有一堆索引卡，它们组合在一起涵盖了原始非结构化需求中的所有需求。而且它们也采用您觉得舒服的格式，可以根据需要分发给工程团队！将它们与底层需求联系起来。把它们写在索引卡的背面，或者如果有太多的话，请参考最初获得要求的文件。旁白：本质上，您在这里所做的是生成工作分解结构、项目管理和系统工程工具。假设，在这一步，你已经推迟以确保你只剩下你绝对必须构建的东西，现在我们必须决定以什么顺序来做。

同样，这是您作为工程师的技能以及您从事此类工作的经验将非常有用的地方。在建立结帐体验之前，您是否需要与支付提供商建立集成？也许，但不一定。您可以构建“除此之外的所有内容”并避免依赖性，让付款步骤成为页面上的一个简单按钮，暂时“绕过”它-但是这样做是否冒着必须返回并返工的风险而不仅仅是当您最终会集成支付提供商吗？请记住，您已经尽可能多地推迟，以确保您只是在构建 MVP；如果您必须在发布前整合支付提供商，那么何时进行整合最有效且风险最小？为了避免依赖，是否值得承担额外的风险？也许是——也许不是——但无论如何都要记下这种可能性，无论你决定什么。它可以稍后保存您的背面。在这个阶段，我占用了整个会议室几个星期。或者至少，一整面墙都涂上白板漆，然后用 blu-tac 将 myindex 卡贴在墙上。请记住 - 这个项目将耗资数百万美元，因此您可以证明接管一些空间是合理的。让我们回到上面的电子商务市场示例，添加几个项目——看看它是什么样的依赖关系图：你会注意到我已经写下了为什么存在一些依赖关系——因为很快我们就要让工程团队参与进来，我们想要挑战我们的假设——所以我们需要记住我们所做的假设！实际上，您应该为每个依赖项执行此操作。它将帮助您弄清楚如何在项目中稍后删除范围以避免将来出现依赖关系。

估算复杂项目的第二条规则：您必须始终让实际执行工作的人参与进来。在这里，您可以引入技术主管、首席工程师等。他们了解自己的团队，了解自己的能力，并且他们比您更熟悉已经在运行的系统您提议的功能将会触及。向他们介绍项目，然后让他们通过您的数字板 - 或物理墙 - 解释最顶层 - 卡片正面写的内容，而不是它背后的要求 - 边走边看。作为一个小组，确定哪个团队对您墙上的每张卡片具有主题专业知识或最佳经验。现在让每个团队负责人检查他们的卡片，参考源材料，并为整个团队分配一个以周为单位的估计。不要比 1 个团队周更精细，您也可以使用双倍量表 - 1 周、3 周、6 周、12 周。过多的 12 周估计值——或者任何你确定的最大值——都可能意味着太多的不确定性，所以在这些上做一个标记，然后在以后更详细地探索它们。旁白：土木工程使用了一系列价格手册，在英国，它根据之前所做的工作“确定”大规模土木工程项目的估算。软件工程是一门太年轻的学科，没有这种深度和严谨性，这是一种耻辱。这个时间盒。每张卡片最多需要 5 到 10 分钟，让他们填写周数，否则您的团队可能会迷失在细节中。在这个阶段，您希望在给团队足够的时间来理解粗略的需求与解决方案和“深入”需求之间取得平衡。

确保团队知道您对他们的估算承担责任，而不是他们，并向他们保证，您将确保它们被视为估算，而不是铁定的保证——然后在与管理层的对话中贯彻落实。你必须信任你的团队——如果你不给他们心理安全，他们会大大高估自己的保护。你的头牢牢地在护墙上方，在这里，而他们的不是——这应该是。出于这个原因，这里也需要您作为技术专家的技能；挑战让你感到惊讶的估计，并写下原因。我强烈建议你不要以此为契机来挑战你的团队以降低他们的估计，至少在这个小组设置中不是。相信你的团队领导和高级工程师——他们比你更了解实际执行这项工作将涉及的内容。但是一位优秀的技术专家将能够确定团队过于谨慎、误解需求或了解一些她不知道的领域，并且她将在稍后的一对一对话中探索这些领域。一位伟大的技术专家也会利用这个机会来检查她对依赖关系的假设；她将与她的高级工程师一起探索它们，并根据这些对话修改依赖关系图。精彩的。我们有一个依赖关系图——它可以兼作项目计划——我们知道哪个团队可能会做每一项工作，我们已经对每个项目进行了估计，以周为单位。来自天堂的玛娜是一位项目经理，如果你有一个好的人选，他们会很乐意从这里开始寻求帮助。

我接下来要做的是应用我在大学学到的一些基本知识； PERTchart 网络图上的关键路径分析。这并不新鲜——它来自 1958 年，导致了可怕的甘特图，并被广泛批评为软件项目要避免的东西。但我仍然发现从“我不知道这有多久willtake”到初始时间范围，并提供公司是否“配备”来执行项目的指示。再次，让我们以虚构的电子商务市场为例，看看节点关键路径网络图上的活动是什么样子：在这里，我们根据每个任务将花费的周数，将我们的估计添加到每个任务中一个团队来完成。我们添加了依赖项，并且添加了“开始”和“完成”框。现在我们需要填写其余部分，使用向前传球，然后是向后传球。底部中心列中带有零的活动（任务） - 我们的“松弛” - 表示关键路径。解释如何做到这一点本身就是一篇博客文章，但你可以在谷歌上找到很好的解释，比如这个。现在，我们有了红色的关键路径（那些具有“零”松弛/浮动的路径），以及我们可以在 22 周内完成该项目的最短时间（“完成”框的最早完成时间）。从本质上讲，它为我们提供了整个项目的 No EarlyThan 或 NET 日期。它还告诉我们这个虚构的、理想化的项目需要多少个团队周——即一个团队需要多长时间，持续工作，才能完成——通过将所有估计加在一起。 43 个团队周。

项目管理中有很多书都是关于使用这样的图表时可以收集的其他见解 - 以及要避免的陷阱 - 但那是另一次了。我们已经从零变成了某物，并且我们在获得这个“某物”方面做了相当多的尽职调查。这很好，不幸的是，这比大多数大型软件项目似乎得到的要多。我们还没有对现有团队进行任何甘特式分配——我不会打扰（如果她愿意，CEO 可以聘请项目经理来做这件事），所以“不早于”日期是确实是项目最早完成的日期——它很容易延长两到三倍。令人沮丧的常见、不可能的情况：您的 NET 日期接近您的截止日期，无论是在之前还是之后，或者您的“总团队周”接近可用时间的 100%。在简单的情况下，您只需要确保您的总团队周数是您当前人员配备水平的 50% 左右，并且您应该可以轻松地与您的 CEO 进行轻松交谈。如果不是，你可以就招聘进行讨论，考虑到新团队成员入职的大量开销和时间滞后，以及团队成长中固有的收益递减。在更困难的情况下，即使在最早、最虚构的估计版本中，您也远远超过了您，并且您必须与您的首席执行官（可能还有您的销售总监）进行艰难的对话，在那里您必须谈论削减范围、延长截止日期或让客户失望。至关重要的是，您正在使用触手可及的实际数据并进行实际尽职调查。你不是“直觉”它。你不会“像其他工程师一样抱怨最后期限”。你说的是冷酷的事实，希望你在项目截止日期之前做得很好，所以还有时间做出改变。

但在不可能的情况下......我们已经成功地将自己困在一个角落里，因为现在任何人看到这些数字都可以做到这一点，而你将不得不在大头针上保持平衡以免被迫陷入不可能的境地。与您的团队仔细检查您的所有估计。由于估算的本质是不完美的并且通常低于现实，因此您可能会发现您没有考虑的事情会推高估算，而现在您处于我上面描述的更难但并非不可能的情况。这不是作弊——如果你对完美的、球形的真空估计如此严格，那么你需要重新检查你的假设。现在是时候更深入地进行估计了，与您的团队成员交谈，在每项任务上花费超过最初的 5-10 分钟。考虑您可以对基础项目结构进行的任何更改。我曾经提出 - 作为“核选项” - 分叉一个项目，以便可以在不迁移现有数据的情况下实现一组客户要求。正如开始时所解释的那样，作为此选项的结果，在项目结束时重新整合更改需要 -6 个月，但这是正确的商业决策。您能否接受任何经过深思熟虑的适当技术债务以加快速度，同时提供有关何时需要解决该债务以及解决该债务将花费多少的背景信息？考虑您的任何任务是否可以由顾问承担或购买“现成的”，但要注意所涉及的开销。真正考虑其他正在进行的工作，以确定您的“总团队周”与“可用团队周”是否可行——您的团队真的有 50% 的时间来处理这个项目吗？

在较低级别挑战范围 - 与主题专家和原始需求作者一起 - 看看某些部分是否可以在以后删除或推送。不知不觉中，您还制定了一个项目计划，这意味着现在可以为工程团队分配任务以进行探索、充实和构建。这意味着您的团队现在可以开始构建零依赖项，并且您更有信心他们不会遇到阻碍。熟练的技术专家还可以使用它来解释和探索与她的团队的完整要求，确保他们感到知情、信任、了解整个计划，并鼓励他们谈论他们正在做的事情，这将产生影响。她的团队会觉得他们正在齐心协力朝着更大的目标前进，并且会看到他们所做的工作与其他人所做的工作有何关联。我坚信这样的方法与敏捷方法并不矛盾。请注意，我用小写的“a”来表示“敏捷”——敏捷™、SCRUM、安全或 XP 实践者可能不会在这样的环境中享受自己。如果你有一个已经启动的 SaaS 平台，并且你有很多可以使用的功能，即使没有不祥的、迫在眉睫的截止日期，拥有这些功能的依赖关系图将有助于优先考虑哪些功能对公司的最大价值。同样的功能，如果我们知道我们可以立即进行处理，那么比我们知道由于我们没有支付系统而无法在 6 个月内进行处理的情况更有价值。旁白：这类似于“货币的时间价值”的会计概念，这是一种推测性金融会计，它说“现在收到一笔钱比以后收到一笔钱有更大的好处”。计算功能的“净现值”是最好留给产品所有者的练习😉我们在这里制作的只是一个路线图，产品和工程团队可以使用它来确定下一步的优先级。有时，您会发现它没有任何依赖性；太好了，现在您可以根据纯用户价值确定优先级，而无需考虑任何工程问题！

Continue to de

......