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

Question

作为以前有效地与敏捷合作过的人，我正试图说服我现在的雇主相信敏捷的好处。然而，管理层坚持要求我们保留预先估算的能力，以评估项目的业务价值。

我的大多数客户都是内部的，我最近受命周旋团队，并询问他们关于业务流程的想法以实现自动化。然后，我要找出这花费了多少时间，计算出解决方案将节省多少时间，并估算出整个开发时间。这样，管理人员就可以尝试从节省时间的角度来衡量解决方案的有效性。

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

关于如何向外部客户“销售”敏捷，如何向(瀑布)客户销售敏捷开发有一些有用的建议。我并不是想把它卖给外部客户:我想找出怎样才能最好地调和内部管理的需求，同时保留一种我认为效果很好的方法。

有没有办法以灵活的方式处理这个任务，让我至少保留一些敏捷的好处？

Answer 1

正如其他答案所述，管理层完全有权在项目的前期获得高水平的评估。他们试图确定投资回报率并非不合理。

然而，我喜欢敏捷的方法之一是，项目的范围不是固定的。它可以在特性和史诗级别上进行初步调整，然后业务可以根据最重要的特性来确定ROI。也许花哨的UI具有较低的业务价值，但用于处理索赔的工作流引擎具有较高的ROI。

当您将整个项目合并在一起时，要满足ROI比将重点放在所需的关键业务功能上要困难得多。

以下是我这样做的一种方法：

将您的WBS里程碑转换为可交付的特性

。

这使您可以将项目分类为具有不同业务价值的小型子项目。在商业价值方面，每一个都应该是独立的。

t恤的尺寸-

特征的努力

这是一种非常简单的方法，可以大致了解某个特定特性的大小或涉及范围。也许低价值的特性仍然有一个伟大的投资回报率，如果他们看起来很容易获胜。

将一个特性分解为

故事

通过这个练习，找到一个被充分理解的小功能，并将其分解为最初的故事。用点来估计这些故事。现在你有了一个基础

小-> 40点

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

将故事点与所有特性联系起来，

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

中特征Y感觉它是小特征X的两倍大小和努力的40个故事点。

中位特征Y可能是80个故事点。继续这一点，直到你有一个高水平的所有功能的故事点估计。

估计您的团队速度

看看您的开发团队，试着确定这个团队可以在给定的sprint中有效地交付多少故事点。如果您有以前的敏捷项目作为这个团队的一个例子，那么这是一个很好的起点。如果您在团队后面没有这样的历史记录，那么与您的团队一起进行模拟，在那里您开始查看您已经详细介绍的小功能。人们在这些故事中为自己的任务做了什么样的每小时估算？

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

找到您的预计完成日期

如果您在模拟sprint计划中的团队感到轻松地在一个sprint中提供25个故事点，并且您的总积压看起来像是你项目的金凯迪拉克版本的300个故事点，那么看起来您的团队应该需要12次冲刺或24周的时间来完成所有工作。

现在，将团队中的资源成本转化为每周的美元以获得ROI相对于业务价值的成本是非常简单的。协商可以继续讨论最重要的特性，然后您的项目管理就变成了一个背包问题。

Answer 2

这不是“管理”的问题。在开始之前，绝对需要能够估计任何潜在项目的成本和效益。否则，怎么会有人知道什么是值得做的(或尝试)？

那为什么是敏捷？

我认为使用敏捷方法并不意味着选择不确定性。相反，敏捷是一种观点，认为不确定性是不可避免的，而传统方法的详细规范和估计引入了错误的确定性--这可能是相当昂贵的。

时间估计方面的一些要点：

• 在整个项目中，对需求的更改是不可避免的；敏捷考虑到了这一点，而不是假装没有变化。
• 详细的规范通常包含设计缺陷，直到深入到项目中才能发现。这可能意味着传统项目比敏捷项目有更大的变化。
• 基于“我认为整个项目有多大”的时间估计？可能与许多详细需求的估计时间相加一样准确。
• 导致良好估计的主要因素是评估、测量和审查的循环--这可以应用于任何一致的过程。
• “节省的工作”估计将由项目的主要需求(而不是细节)驱动，因此我怀疑敏捷将极大地损害评估这一功能的能力。

更新：

为了澄清，你对老板的反应似乎是：“我们不能很好地估计使用敏捷节省的时间或整个开发工作，因为它是灵活的。”我认为这是错误的。我相信，在使用敏捷过程时，这些评估也可以做得很好，因为不确定因素仍然存在。当然，随着项目的展开，敏捷允许一个更加灵活和响应性更强的过程。

Answer 3

这无疑是引入敏捷

最难的部分之一

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

我的方法是：

• 垫300%。当你在管理层面上真正敏捷的时候，300%这句老话是很有用的。这也许不是一种“敏捷方法”，但对于这种情况，它是一种妥协。你可以领先几次--但别指望它！
• 要求根据在项目的“中途”点完成的工作进行一次评审。项目时，您将完成根据所做的工作。然后与管理层交谈，看看他们要牺牲什么--功能或质量--因为时间是根据项目开始时的猜测确定的。
• 确保您正在与管理层协作完成特性和质量，这样他们才能真正做出这些决定。
• 跟随这个项目的流程，让通常的事情发生--错过最后期限，质量受损，精疲力竭，给离开的员工压力(甚至可能会离开)。当下一个阶段的项目出现时，讨论这些“副作用”。
• 集中并演示“真正的”敏捷方法的优点。谈谈质量的提高。谈论在一天晚些时候做出改变的能力，直到和超过它们进入生产阶段。他说不需要再工作了。谈论减少技术债务，这将最终使发展爬行。以现实世界为例，我们可以在任何一天推迟更换机油，但推迟足够长的时间，发动机就会受损，表现不佳，最终会击打一根棒子。
• 保持你的简历和linkedIn的最新资料。如果你不能得到管理支持后，提出几次你的情况，继续前进。有些组织将不会列出你的论点，所以转移到那些这样做。称之为达尔文主义就业;)