是否可以对需要估计已花费时间和节省时间的项目采取灵活的敏捷方法？

作为以前在敏捷领域进行过有效工作的人，我正在努力说服我目前的雇主对它的好处。但是，管理层坚持认为我们保留进行前期估算的能力，以便评估项目的业务价值。

我的大多数客户都是内部客户，最近我受命去组建团队，并要求他们提供有关自动化业务流程的想法。然后，我要弄清楚这花了他们多少时间，计算出该解决方案将节省多少时间，并估计总的开发时间。这样，管理人员可以尝试根据节省的时间来衡量解决方案的有效性。

但是，在我看来，没有办法以“敏捷”的方式满足此要求。灵活的要求意味着不仅要花费的时间估算是错误的，而且可能节省的时间估算也将是错误的。我做了很多解释，解释了为什么它可能有问题，但被告知这是不可谈判的。

如何向（瀑布式）客户出售敏捷开发问题对如何将敏捷 “销售”给外部客户提出了一些有用的建议。我不是在试图将其出售给外部客户：我正在尝试找出如何在保持我认为很好的方法的同时，最好地调和内部管理的需求。

有什么方法可以灵活地完成这项任务，从而至少保留一些敏捷优势？

正如其他答案所表明的那样，管理层完全有权对项目进行预先的高水平估算。他们对于尝试确定ROI并非没有道理。

但是，我喜欢敏捷的一种方法是项目的范围不是固定的。最初可以在功能和Epic级别进行调整，然后企业可以根据最重要的功能确定ROI。花哨的UI可能具有较低的业务价值，但是用于处理索赔的工作流引擎具有较高的ROI。

当您将整个项目集中在一起时，与专注于所需的关键业务功能相比，实现投资回报更困难。

这是我执行此操作的一种方法：

记录您的WBS里程碑，并将每个里程碑变成可交付使用的功能

这使您可以将项目分类为具有不同业务价值的微型子项目。这些方面中的每一个都应该在商业价值上保持独立。

T恤尺寸，着重特色

这是一个很简单的方法，可以粗略了解某个特定功能可能有多大或涉及多少。如果低价值功能看起来很容易取胜，那么它们仍然具有很高的投资回报率。

将功能分解为故事

通过练习查找一个易于理解的小功能，并将其分解为故事。用点数估算这些故事。现在您有一个基础

小-> 40点

这将是与其他功能进行比较的基础

将故事点工作与所有功能相关联

将您的小功能与其他功能进行比较。例如，

中型专题Y感觉是小型专题X的大小和工作量（40个故事点）的两倍。

中等专题Y可能是80个故事点。继续进行此操作，直到所有功能的故事点都得到高估。

估算团队速度

查看您的开发团队，尝试确定该团队可以在给定的sprint中有效交付多少故事点。如果您之前有此团队的敏捷项目作为示例，那么这是一个很好的起点。如果您在团队中没有这样的历史记录，请与您的团队一起进行模拟Sprint计划，从中开始查看您已经详细介绍的Small功能。人们在这些故事上为自己的任务提供什么样的每小时估计？

根据团队认为他们在2周内可以完成的工作量，将总故事点数用作团队的平均潜在速度！

查找您的预计完成日期

如果您的模拟冲刺计划团队在一次冲刺中轻松传递25个故事点，并且您的项目的金色凯迪拉克版本的总积压看起来像300个故事点，那么您的团队最好花12个冲刺或24周来完成完成一切。

现在，将团队中的资源成本转换为每周美元变得微不足道，以获取ROI与业务价值的成本。可以就最重要的功能进行谈判，然后您的项目管理基本上就变成了背包问题。

这不是“管理”的问题。绝对要求能够在开始之前估算任何潜在项目的成本和收益。否则，没人会知道什么值得做（或尝试）吗？

那为什么要敏捷？

我认为使用敏捷方法不是选择不确定性。相反，敏捷是一个论点，即不确定性是不可避免的，而传统方法的详细规范和估计引入了错误的确定性，这可能会付出巨大的代价。

关于时间估计的一些关键点：

• 整个项目中对需求的更改是不可避免的；敏捷考虑到了这一点，而不是假装没有改变。
• 详细的规范通常包含一些设计缺陷，这些缺陷直到进入项目时才被发现。这可能意味着传统项目比敏捷项目有更大的变化。
• 基于“我认为整个项目有多重要？”的时间估算 可能与将许多详细需求的估计时间相加一样准确。
• 导致进行良好估算的主要因素是估算，度量和审查的周期-可以将其应用于任何一致的过程。
• “节省的工作量”估计将由项目的主要需求而不是细节决定，因此我怀疑敏捷会严重影响估计能力。

更新：

需要澄清的是，您对老板的回答似乎是“我们无法估计使用Agile节省的时间或总的开发工作量，因为它很灵活。” 我认为这是错误的。我相信在使用敏捷过程时也可以做出这些估算，因为总有不确定性。当然，随着项目的进行，敏捷可以使流程更加灵活和响应迅速。

这无疑是引入敏捷最困难的部分之一

“管理层仍然需要时间估计”

我的方法是：

• 填充300％。当您无法在管理级别上真正敏捷时，300％的谚语很有用。也许这不是“敏捷方法”，但却是这种情况的折衷方案。您可以多次领先-但不要指望它！

• 要求根据在项目的“半途而废”点所取得的工作进行审查。根据完成的工作来预测何时完成。然后与管理人员进行讨论，并根据项目开始时的猜测确定时间是固定的，然后权衡他们应该牺牲的功能或质量。

• 确保您正在与管理部门协作完成的功能和质量，以便他们实际做出这些决定

• 按照这个项目的流程进行操作，并允许发生通常的事情-错过最后期限，质量下降，精疲力尽并承受离职员工的压力（甚至可能离职）。当下一个阶段的项目浮出水面时，讨论这些“副作用”。

• 关注并演示“真正的”敏捷方法的优点。谈论质量的提高。讨论在一天中的晚些时候进行变更的能力，直到变更生效为止。谈论较少的返工。谈论较少的技术债务，这些债务最终将使开发步履维艰。打个比方，例如，我们可以在任何一天推迟换油，但要推迟足够长的时间，这样发动机就会受苦，性能不佳并最终炸毁连杆。

• 保持您的履历表和LinkedIn个人资料为最新。如果您在几次提出申诉后仍无法获得管理支持，请继续。某些组织不会列出您的论点，因此请转到有此论据的组织。称之为达尔文主义就业；）

我认为您对敏捷开发做出了错误的假设。灵活性和不断变化的要求从字面上体现在“ 敏捷宣言”中。

即使在开发后期，也欢迎不断变化的需求。敏捷流程利用变更来获得客户的竞争优势。

灵活的（阅读：不断变化的）需求在敏捷中是受欢迎的。当然，如果您问大多数开发人员，他们会增加一个警告，即更改必须合理。要求团队制作3D游戏，然后将要求更改为“核反应堆控制系统”，这有点麻烦。但是添加，删除或修改项目范围内的需求是完全可以的。

问题是您如何应对不断变化的需求？典型的答案是使用短迭代，这样您就可以在浪费太多时间之前尽早进行课程调整。这也迫使团队将需求分解为较小的部分，以便每个人都能更好地理解它们并在合理的时间和精力下实施它们。

简单性-最大化未完成工作量的艺术-是必不可少的。

我也喜欢这种敏捷原则。通常认为，团队应该努力通过无情的效率仅交付那些必要的事情。例如：如果客户认为他们需要什么，但看起来有些腥，那就四处逛逛。也许最终用户真的没有用，所以不应该做这项工作。

但是，我认为您的问题触及了该原则的另一个方面。软件通常用于实现手动过程自动化的目的。该软件本身的存在是为了最大程度地提高最终用户未完成的工作量。

衡量软件将为最终用户节省的劳动量绝对是一个值得衡量的指标。我已经在自己的职业生涯中对此进行了衡量。实际上，它是成本/收益分析的关键组成部分：与最终产品将为最终用户节省多少精力相比，软件项目将花费多少精力来实施。

这与敏捷（或任何其他）开发理念绝对兼容，您的管理层绝对应该对此予以认可。

是的，敏捷有一些优势。

• 它允许商务人士在飞行途中改变主意。
• 它可以保护企业免受工程师永远的错误估计。
• 在实现最终愿景之前，它尽早且经常提供价值。
• 它为您节省了一些前期计划成本，但无论如何它们经常会产生糟糕的计划。
• 太酷了。对？

但是，您仍然需要给出合理准确的前期估计。

如果不这样做，您实际上是在要求企业投资您的产品，而没有任何证据表明您的产品甚至值得初始投资-在某些情况下甚至是任何东西。

我现在可以听到了。

我以前听过 我敢肯定我已经说过了：

哦-但是好！！HAOW只是像我这样的凡人，凝视着我的命运！只有神自己才能做的事情是神圣而直接的。凡人只能在最深沉的梦中梦见的事情，被白日梦忘了！哦，专横的管理类型，可以满足这样的要求！？

以过去的表现为指导并诚实。

• 与利益相关者和/或最终用户进行足够的对话，以确定产品和/或其主要组件相对于您开发的其他主要组件而言有多复杂。进行初始的相对点估计。
• 根据您过去看到的范围变化和漏洞影响的历史数量来增加该数字。
• 将您的历史速度应用于点估计，以得出大致的时间轴。并且，应用合理的不确定性锥。
• 重新审核您对项目的估计和理解。确信您愿意根据您的评估来决定如何处理项目。

最后，向利益相关者展示您的不确定性，陈述您的假设和疑虑，然后任其解决。

作为旁白，我还建议提出一个客观的点估计启发法，以合理地检查您和/或您团队的正常估计。

您可以在计划扑克期间将此估算用作第N次投票，或者如果您要独奏，则可以在验证您的私人估算时使用。例如，我的团队倾向于估计每分钟大约1点的关于一个故事的松散技术发现讨论。如果您的直觉告诉您一个故事是5分，但是这花了您20分钟的时间来了解需要做什么，这特别有用，它通常是一个很好的指示，表明仍然存在复杂性和误解。

我从未在任何能够持续提供良好时间估计的公司工作过，也从未与任何声称这样做过的人一起工作过。搜索将向您显示估计是整个行业尚未解决的问题。

我会尽力支持基于抽象故事点来衡量速度，如果您无法做到这一点，我将为您提供更多的估计。

敏捷是解决所有问题的好方法，但是尽管有些福音派人士提出了建议，但它不是唯一的解决方案，也不总是正确的解决方案。

您陈述的情况根本不是敏捷问题：

最近，我被派去巡视团队，并要求他们提供有关自动化业务流程的想法。然后，我要找出这花了他们多少时间，计算出该解决方案将节省多少时间，并估计总的开发时间。这样，管理人员可以尝试根据节省的时间来衡量解决方案的有效性。

您的任务是确定使某些业务流程自动化的成本和收益，这不是易更改的敏捷任务，它是特定解决方案的特定问题。您将生成一个具有任意数量的业务流程的列表，并且每个流程都会有一个估计的自动化成本，一个估计的非自动化成本和一个估计的自动化收益。管理层将使其与他们的预算，资源，需求和战略目标相匹配，并确定这些流程中的哪些（如果有）可以自动化。如果您很认真，那么您将突出显示选定的任务，这些任务本身可能会降低ROI，但会减少其他阶段的成本，从而提高总ROI。您可能还发现了实现自动化的不同方法，包括内部和外包定制开发（使用敏捷和/或瀑布技术），购买现成的解决方案，使用第三方服务提供商等等。整个流程在90年代被称为业务流程再造，非常时尚。