本文包括一个预格式化的电子表格，以帮助您开发敏捷发现评估. 它还包括一些信息，以帮助您跟随特色示例.你可以制作一个可编辑的副本 (File>Make a copy or File>Download) 从模板中 在这里.

在我组建团队或了解MVP需求之前，客户经常要求我提供敏捷评估. 在早期阶段, 我无法使用像速度这样的传统指标, 冲刺次数, 或者计算这些估算的团队成本. 但客户想要答案. 他们能在两个月或六个月内推出一款假想产品吗? 他们的预算(通常很低)是否可行?

进入敏捷电子表格.

电子表格是一种适合敏捷思维的选择，但经常被忽视. 他们 技术个性化的 鼓励协作的工具. 也就是说, 只要产品的成本和质量符合他们的要求，你的客户可能并不关心你的工具是否被“敏捷认可”. 电子表格的真正价值在于它们对所有经验水平的项目经理和利益相关者的可访问性.

许多专门的项目管理工具的学习曲线对于没有经验的用户来说过于陡峭. 所以对客户来说越容易, 产品负责人, 并且开发人员需要更新需求和人力成本, 你就能越快得出一个现实的估计. 使用预格式化的电子表格， 项目经理 能否调整值和参数以显示每个波动的资源或移动的时间轴的影响.

电子表格也是与同事分享知识的好方法. 的 电子表格 我用的是Toptal的同事, 我已经复制了一份，并根据我的需要进行了修改. 我鼓励你也这样做. 在本文中, 我演示了如何交付成功的发现评估，使客户和涉众能够在项目目标上保持一致，并继续进行开发. 以下是如何填补空白并交付您可以支持的早期评估.

首先处理产品愿景和路线图

假设你的客户想在固定预算下开发一个约会网站, 但是产品的细节是模糊的. 在不知道团队成本和速度的情况下, 产品愿景是最好的起点，因为它要求涉众就设计目标达成一致，并促进整个团队的透明度.

我喜欢 Scrum.org 产品视觉格式以其直观的叙事风格为主. 它看起来是这样的:

一旦设定了产品愿景，您就可以添加 产品路线图 在一个新的电子表格选项卡中，让客户了解长期的项目进度. 路线图应该列出每个产品路线图版本的目标、关键特性和截止日期.

计划路线图版本, 引导市场轨迹的面向消费者或客户的产品版本. 第一个路线图版本是您可以在市场上首次亮相的产品. 随后的路线图版本代表了具有与产品愿景一致的引人注目的新特性的市场发布.

以微软为例:Windows 8可能是一个路线图版本. Windows 10是另一个路线图版本，它有许多令人满意的新功能.

一旦产品愿景和路线图完成，就是时候让客户承诺MVP了.

用三重约束图协商MVP功能

此时，你可以使用三重约束图表来塑造客户对时间和费用的期望:

在瀑布方法中, 固定的特性决定了时间和成本, 并根据详细的项目计划进行开发. 相反, 敏捷的固定成本和进度决定了产品的特性, 并且这些特性会根据更灵活的项目愿景不断重新确定优先级.

三重约束图向客户表明，在第一个发行版中包含所有期望的功能将增加开发时间和膨胀成本. 而不是, 与客户合作，只为MVP选择“必须拥有”的特性，并为未来的版本列出任何剩余的特性.

电子表格可以很容易地将功能分组并重新分配到不同的版本, 释放, 根据客户不断变化的需求确定优先级, 它们会立即显示出这些变化的成本.

当你确定MVP功能时, 请您的主题专家(sme)根据他们所从事的类似项目列出项目的步骤. 您将使用以下步骤进行创建 史诗 晚些时候. 一旦你准备好了这些输入，你就可以开始估算了.

从t恤的尺寸开始

要开始第一个积压，请询问 产品负责人 获取产品功能的详细描述, 然后根据难度为每个特征分配t恤的尺寸.

t恤分级 会在您有任何绝对值之前显示每个开发任务的相对复杂性和持续时间吗. 随着项目计划的深入，我们将把这些相对大小转换为 故事点 工作时间.

例如, 如果你的客户想让你在约会网站上开发一系列弹出窗口, 这很耗时，但很简单. 您可以将任务复杂性描述为“小”，但工作量将是“中等”.你可以把它缩写为SM.“另一方面, 由于所有必需的文档和测试，为新API开发后端连接将是一项更复杂的任务. 为此所需要的技能和注意力可能会使它在努力和技能水平上都是“大”的.”

一旦你完成了t恤的尺寸, 您将了解每个未来团队成员的相对工作量和技能需求. 然后，来自开发团队的技术专家可以帮助您将t恤的大小与时间范围和故事点估算联系起来.

设置参数

现在你已经准备好让你的电子表格工作并计算你的估计. 首先创建一个Parameters选项卡. 这将是你计算的关键, 您在这里输入的值将被输入到您的Backlog/User story和Estimate Summary by Release选项卡中使用的公式中.

以下是参数选项卡中需要的所有内容:

货币. 这是输入货币转换的地方. 例如, 如果客户的预算是巴西雷亚尔的话, 您可以输入美元或欧元的当前兑换率.

开始日期. 预期的开发开始日期将用于创建项目时间表. 在每个示例中，我们的开始日期都是10月25日.

最初的预算. 预算提供了约束条件，以显示是否所有MVP功能都符合预算.

t恤分级. 输入你的t恤尺寸作为表格, 并为每个规模组合分配故事点和时间范围. 在这个例子中，我们用一到两个小时来制作SS，用33到48小时来制作LL.

请记住，你的冲刺时间将限制你的最大t恤尺寸的小时数. 如果冲刺只有一周，最大的规模不能超过40小时. 这就是为什么在分配t恤尺寸时咨询中小企业是如此重要.

每小时收费. 使用此表记录每个角色的薪酬率. 如果后端开发人员的费率不同，则使用两者的平均值.

开销. 将项目总工作量的一定百分比分配给诸如状态会议之类的管理任务, 反馈会议, 项目修订. 10%(或每个参与者每周工作的四个小时)是一个很好的起点, 但是对于更复杂的项目，开销可能更高.

应急. 这表明了您估计中的潜在方差. 从偶然性为0%开始，你会看到最好的情况(1.e.(不太可能)预算和时间表给出你输入电子表格的值. 在后面的例子中, 我们将偶然性增加到50%的大致数量级(ROM)方差，以显示潜在的高成本和项目持续时间. 当你获得更精确的数字时，偶然性将会缩小.

在每个版本中添加史诗

我们从整个产品的大致尺寸开始，以确保我们不会浪费客户的时间或金钱. 这取决于规模与他们提出的预算和截止日期的接近程度, 客户可能决定放弃项目或投资于更详细的评估. 因为我们现在还没有太多的细节, 我们在Backlog/User Stories选项卡中输入主要特性作为史诗. 然后, 每一部史诗, 我们根据Parameters选项卡中的t恤尺寸表，输入sme和开发领导者为每个开发堆栈建议的小时数.

首先，选择“EPIC”列?，并确保只选中“Epic”.

下一个, 写出史诗描述，并为开发堆栈的每一列输入小时数. 例如, 史诗般的“安全连接和登录”将花费大约8个小时的UI开发, 后端40美元, 等等......。.

注意，在大多数情况下，“Point”列中的单元格显示为“34*”.，如果您返回到Parameters选项卡, 你会看到34个点对应于33到48小时之间的每小时范围. 如果我们的冲刺时间只有一周，那么这个时间就太长了.

一旦我们有更多的细节, 这些时间需要减少, 或者，史诗必须被分割成更易于管理的故事. 但是，由于时间的原因，我们将忽略Points列，继续进行粗略的估计.

现在转到估计摘要发布选项卡. 在电子表格的顶部, 您将看到在Parameters选项卡中定义的“开销”和“偶然性”值. 还有一个按钮，您可以选择显示史诗或用户故事的估计.

因为我们还没有要显示的用户故事，所以选中“Epic Mode”按钮.”

现在，您可以看到MVP的大致成本和时间表，以及未来版本(R3和R4)中不太紧急的特性和更新。. 在这个例子中, 第二个版本(R2)是空的，因为客户要求在第一个版本中发布所有MVP史诗.

现在可以看到最乐观的总成本是28,810美元. 这个数字是从MVP到R4的每个版本的成本总和.

我们还对产品交付的最短时间有一个估计, 哪个与R4开发堆栈中的最新完成日期相对应. 项目经理 将这些较慢的开发堆栈称为“关键路径”，因为它们决定了整个发布的速度.

在本例中，关键路径是前端开发，完成日期为1月31日.

现在是时候调整参数来模拟最坏情况的预算和最长的时间.

将偶然性调整为50%

相对而言，我们对产品的工作和专业知识需求仍然知之甚少, 所以我们将在参数选项卡中添加50%的ROM偶然性. 随着我们了解项目的更多细节，这种偶然性将会减少.

同样，这是在0%意外情况下的总项目估计.

这里是50%的偶然性.

这意味着整个项目的ROM概算在28 810美元至41 860美元之间. 在最好和最坏的情况下, 客户20美元,000美元的预算不足以包括他们愿望清单上的所有功能.

整个项目的完工日期为3月14日, 比0%应急完工日期晚6周.

与此同时，MVP将于1月10日准备就绪.

而不是放弃这个项目, 客户要求一个更详细的估计，看看它是否可能在更短的时间内接近他们的目标预算.

重新安排优先级以满足最后期限

假设客户端为MVP设置了12月25日的目标日期, 距离10月25日开赛还有两个月.

将目前的1月10日MVP完成日期提前, 客户同意将两个MVP史诗推迟到下一个版本(R2)。.

电子表格计算这种调整的级联效应. 在这种情况下，MVP时间表缩短到12月27日. 前端和后端开发是此模拟中的关键路径，因为它们将花费最长的时间来完成.

基于这些信息, 您可能会决定再增加两个开发人员，以使前端和后端完成日期与其他开发堆栈保持一致. 要做到这一点，将MVP“每周工作时间”一栏的工作时间从40小时增加到80小时.

前端和后端开发堆栈现在都将在11月完成, QA成为新的关键路径(完成日期为12月20日). 注意，成本不会改变. 这是因为每个堆栈中的总工作时间保持不变. 而不是一个开发者工作两周(80小时), 两名开发者工作一周(80小时).

电子表格还说明了全职和兼职工作之间的差异. 让我们假设UI开发人员是兼职工作. 我们可以将UI“每周设计小时数”改为20个，以模拟交付延迟.

在全职时间表上，UX/UI将在11月29日完成.

在业余时间，UX/UI将在12月27日完成.

再一次, 成本不变, 但UX/UI成为新的关键路径, 将MVP评选时间延长至12月27日.

您可以继续这种试错方法，直到在给定您的资源和客户的最后期限的情况下找到一个可接受的关键路径. 一旦确定了合适的截止日期，就该开始调整你的估算了.

用用户故事来完善你的评估

因为50%的应急预算超出了客户的预算, 细化变量是值得的，这样可以降低偶然性并获得更现实的估计.

要做到这一点，请与您的开发人员和中小企业合作，将您的史诗分解成细节 用户故事. 故事的定义比史诗更好，所以我们可以更准确地衡量它们.

接下来，根据任何新信息调整Parameters选项卡中的值. 例如, 您的中小企业和开发团队可能对每个角色有更准确的费率设置，并且可能还希望调整t恤的大小和点数分配. 有了这些新参数, 你可以对自己的计算更有信心，将偶然性降低到25%.

让我们看看我们是如何将史诗分解成更小更详细的用户故事的:

与需要手动输入每个堆栈的估计时间的大规模评估不同, 故事评估使用t恤大小作为快捷方式. 这就是您在Parameters选项卡中输入的t恤尺寸作为故事点计算器派上用场的地方.

在Backlog/User Stories选项卡中的“t恤大小”下, 输入您的开发人员和中小企业分配给每个故事的堆栈的大小组合. 然后是电子表格公式, 从敏捷的故事点估计开始, 将自动填充相应的小时从参数选项卡. 记住最大的尺寸, LL, 必须保持在34分以下，以确保它可以在你商定的冲刺时间内完成. 任何仍然得分34分或更高的故事都需要细分.

一旦你确保分配给所有故事的点数少于34个, 取消“史诗模式”按钮上的估计摘要发布选项卡，以便只查看“故事”.”

现在你会看到一组新的数字:

在详细说明了所有的任务之后，只坚持MVP的功能, 时间表和成本现在符合客户的要求. 因为余额完全在他们的预算之内, 客户决定继续使用MVP并在提交其他版本之前对其进行测试.

让它成为你的

电子表格使用起来很简单, 并具备一些公式的基本知识(不需要宏), 您可以使它们适应几乎任何敏捷项目评估需求. 如果你的Excel知识生疏，在线课程 Udemy 和 edX 会帮助你复习这些技能吗.

本文讨论了发现估计, 但是你可以使用相同的电子表格来生成燃尽/燃尽图表, 调整时间, 并根据后期阶段的速度和冲刺计算估算. 我使用自定义的电子表格作为敏捷评估模板来补充应用程序, 比如Jira, 体式, 和Trello, 并坚持认为它们是我的项目管理工具包中的强大工具. 我希望它们对你同样有用和通用.

比起现成的项目管理工具，您更喜欢自定义电子表格吗? 请在评论中告诉我们为什么或为什么不.