三点估算与类比估算_通过将东西塞进盒子来估算

三点估算与类比估算

我已经开始使用一种用于软件项目评估的方法，到目前为止，该方法被证明是相当透明，快速和可靠的。我观察到，在合理的变化范围内，大多数团队似乎每个日历周要为每个开发人员完成一项“与用户相关的任务”。

在我的论点中有太多理论漏洞，试图掩盖所有观点是没有意义的。有趣的是，它似乎在实践中效果很好。而且它至少很脏而且很脏。我唯一要解决的是这些“用户相关任务”之一比典型的应用程序功能小。

最重要的是：大多数团队在第一次尝试时都做不到。否则他们会花太长时间镀金。或两者。

本文显示了一个估算虚拟项目的示例：“临时人员配置系统”。

高层范围

假设我们的组织提出了以下愿景：

对于希望将候选人与客户需求匹配的临时职业介绍所， 临时人员配置系统是一个交互式Web应用程序，可让他们注册并匹配候选人和职位。与竞争系统不同，这使我们可以与客户共享选择性信息。

我们通过应用程序提出以下流程：

一家新公司想雇用一名技术工人担任临时职位
管理用户将客户详细信息添加到系统
管理用户将客户端登录名添加到系统中（也许我们也应该让客户端使用LinkedIn等登录吗？）
客户登录到应用程序并完成新的职位描述，包括技能要求
临时代理商将工人添加到系统中
临时代理机构建议工人担任客户注册的职位（将来，工人可以自行注册！）
客户收到新提案的通知（通过电子邮件）
客户查看系统中所有未平仓头寸的状态
系统外部：客户面试应聘者，要求提供更多信息，并决定是否雇用
客户接受或拒绝系统中的工作人员
工人执行工作时，他们会在系统中注册时间
在开票期间结束时，系统会向计费系统生成开票信息
在工资期结束时，系统将工资信息生成到会计系统

这些步骤中的某些步骤可能只是一个用户故事，有些步骤可能很多。

待办事项顶部

我们选择范围中最重要的部分来创建积压的开始。为了适应学习过程，积压的初稿可能如下所示：

实验性创建空缺职位
实验清单位置
简化创建空缺职位
简化列表位置
完成创建空缺职位
完整清单位置

故事的“实验”版本是涉及技术所有部分的功能琐碎版本。对于这两个故事，也许我们让应用程序将登录的客户端保留为硬编码变量。这个故事可能只包括写一些职位领域，可能只是标题和描述。

简化版本可能会添加更复杂的属性，例如技能列表中的技能，或者可能会将过滤器添加到列表中。

完整的版本应该是我们准备摆在真实用户面前的东西。

通过重新访问这样的功能，我们有机会获得反馈，以在不进行镀金的情况下创建出色的功能。

继续积压

我们在待办事项列表中添加了足够多的其他故事，以涵盖该范围中一个有趣的部分：

…
基本创建客户帐户
完成创建客户帐户
基本登录管理员用户
基本登录客户端用户
完整的登录客户端用户
基本添加工人
完成添加工人
基本求职者职位
完成求职者的职位
完成确认工人的职位
基本输入时间表（在此版本中，临时代理商代表工人输入）
实验性帐单报告
基本帐单报告
基本工资报告

此功能应该足以发布一个试用版，其中新系统可以支持某些客户端和工作程序。或者，我们可以使用所有功能的完整版本，工作人员登录以及一个或两个功能的完整版本来完善待办事项列表。

添加非功能性任务

有些任务我们要计划一些额外的时间。我通常会发现其中许多任务是客户非常了解的任务：

…
参加CSS培训（团队对设计技能感到生疏）
网页的基本布局和样式
网页的完整布局和样式
精美的网页布局和样式（他们希望它真的很棒）
找到最慢的页面并进行一些性能改进
将解决方案部署到目标平台
将演示版本部署到更多的涉众
部署试用版
探索性测试全流程

规划项目

在这个示例项目中，我们有五个团队成员，外加一名教练/项目经理。由于我们的团队将成对工作，因此我们希望每周工作在三个职能领域。这样，我们可以避免巨大的合并冲突。团队同意每周计划五个故事，但计划第一周只计划三个故事，因为事情通常会变慢。这是完成的积压清单的顶部：

第一周：实验性创建空缺职位
第1周：实验名单位置
第一周：参加CSS培训
第2周：简化职位空缺
第2周：简化列表位置
第2周：基本创建客户帐户
第2周：网页的基本布局和样式
第3周：基本的登录客户端用户
第三周：将解决方案部署到目标平台
第3周：基本添加工人
第三周：基本求职者职位
第3周：基本输入时间表（临时代理商代表工人输入）
第4周：实验性工资报告
第4周：完整的网页布局和样式
第4周：完成创建空缺职位
第四周：完整名单上的职位
第4周：将演示版本部署到更多的涉众
…
第六周：对完整流程的探索性测试
第7周：部署试用版

提出计划

通过这份清单，可以为我们提供完整的时间表，完整的时间表仅需6个星期，即可获得该试用版的全部功能。为了涵盖现实生活，我们可能希望计划至少一周的松弛时间，甚至更多，这要取决于我们的承诺力度和犯错的后果。

这给出了一个计划，指示7周乘以5人，每周40小时，再加上50％的项目经理，每周20小时或总共1540小时。

我通常会发现，在试用版发布之前（甚至在发布之前），情况发生了很大变化。因此，我不会花很多时间来计划这个。

追踪发展

当您开始运行项目时，将显示出这样的计划的真正优势。每周，团队将报告他们完成了哪些故事。这使我们可以根据实际进度调整计划。

另一方面，每周计划由团队和客户共同决定故事的定义。 “基本加法器”的模糊性是设计使然！但是团队应该就“实验”，“简化”，“基本”，“完整”和“抛光”的含义达成共识。

结论

在本文中，我展示了一种快速准确的方法来进行项目预测，并提供时间和成本估算。很容易看到预测结果并对其做出React。

一些关键的批判性观察支持这种方法：

除了“在一天结束之前”或“在一周结束之前”，我从不相信开发人员的估计。（别跟我说几个小时！）
以小时为单位进行估算是获取项目成本的一种愚蠢的方法。任何基于小时的估算总会在神奇地转化为成本之前被提议和填充。而是估算功能部件的数量，每周的功能部件和每周的成本。
多次访问某个功能部件可降低总成本，这是因为镀金量较少以及在不为人所知的地区进行的投资。它还可以提高最终功能的成功率
功能的雄心壮志（即我们将访问它多少次）比开发人员的直觉更能可靠地反映成本

我在桌子上留下了许多问题，例如：关于架构？ “简化的”用户故事是什么意思？如何处理与预测的偏差？请随意在文章评论中为我提供详细信息。

“那要花多少钱？” 使用这种简单的方法逐周安排您的项目预测，下次有人问时，您可以给出更好的答案。

翻译自: https://www.javacodegeeks.com/2014/03/estimation-by-stuffing-things-into-boxes.html

三点估算与类比估算