如果您是一家服务公司，如何使用关键跟踪器估算项目时数？
我是枢轴跟踪器的新手，我试着学习如何在我们的业务中最好地使用它。我们是一家应用程序开发咨询服务公司。正如你们所知道的，客户在签署任何合同之前都想知道总时间和成本。
你们是如何在关键时刻和时间线的基础上绘制项目的？有什么最佳做法吗？指针？
现在，我和我的团队已经把这个项目分成了几个故事(喜欢让我们在一个更低的层次上思考是多么的关键)，并且粗略地列出了点到几个小时。
- 1-1小时
- 2至2小时
- 3-6小时
- 5-10小时
然后我们基本上认为2是四分之一天，3是3/4天，5是一天或更长的一天。
然后我计算出多少个1s，2s，3s和5s，我们得得到一个总小时的粗略估计。Pivotal给了我一个基于默认速度的估计完成日期(我知道这可能会改变)。然后我向我的客户报告大致的总时数、费用和到期日。我确实明白，在事情发生变化的时候，这是敏捷和迭代的，但是当人们雇用你作为顾问时，他们想要的是预先成本。
回答 2
Software Engineering用户
发布于 2012-01-12 18:10:56
您正在尝试将敏捷项目规划工具重新定位为瀑布工具。
我不是专家，但这正是敏捷打算解决的问题，即：“按计划应对变化”。“敏捷化”涉及到某种程度上的权衡--为开发的灵活性和响应性付出的具体成本和最后期限。简单地说，顾客必须(小心地)被问到以下问题：
其中哪一个对你的业务、特点或交货/成本更重要？
注:这是一个普遍接受的经验法则的缩写，见Thomas在re:项目管理三角下面的评论。我选择了一种略带愤世嫉俗的倾向.
不可避免的是，客户两者都想要，但大批精疲力竭的开发人员/代理表明，预先评估很少符合执行的实际情况，这通常会导致可怕的加班或“迟到”交付和愤怒的客户。
敏捷的全部要点是，它试图将经验主义元素引入交付日期，用相对于“任务复杂性”的速度来衡量性能。我的问题是，你把故事的大小和每小时的估计相提并论。故事大小的意义完全取决于你如何分解它们，这就是为什么1-5还没有作为一个时间单位(不像典型的估计工具)。
如果他们绝对需要一个具体的评估，那么他们还没有做好敏捷关系的准备，所以请使用时间表之外的时间间隔方法，希望竞争对手比你投入更多的资源。
就像我说的，我不是专家，但我经历了你描述的经历，我也问了一个类似的问题：资助敏捷项目
编辑: JFTR -我衷心支持关键跟踪器，我们在我所做的上一个项目中广泛使用了它，但是对于管理/销售团队来说，让上面的线程说明他们的round...as是一个范式的转变，Agile不是那么容易在dev/enterprise社区之外销售。
Software Engineering用户
发布于 2012-04-24 00:00:38
基本上，您正在尝试同时执行敏捷和瀑布，这是一个坏主意。
这里有详细的内容：http://www.halfarsedagilemanifesto.org/
https://softwareengineering.stackexchange.com/questions/129795
复制相似问题
腾讯云开发者
