我正在寻找一套好的入门数字（众所周知，度量标准可以解析为好，需要数字是在命令链上传达重要信息的方式！）可以了解某个版本中有多少功能太多，因此我们可以在发布日前两周之前开始推迟，因为仍有许多功能仍在积极开发中，并且有足够多的错误使泰坦尼克号沉没，等待编码人员开始他们。
不幸的是，我将为此需要硬数据，因为我们的大多数日程安排都是由客户驱动的，并且几乎没有任何用处-但我不想提供给管理团队的数据类型错误。
（如果有人对编码人员进行类似的测量有一些好的建议，我怀疑我们的开发团队会希望这样做-他们承受着同样的压力我们是，而且也太劳累了。）
好吧，这是史诗般的问题...
#1 楼
对于这种事情，需要结合多种技术。权衡方法
权衡方法（又称权衡三角形）需要达成共识并记录在案关键利益相关者。这是讨论和决定他们通常不愿谈论的事情的好方法。
权衡三角形概念化了资源，进度和功能是以下三个相互关联的要素的想法：任何项目，并且限制或增强其中一个或多个元素都需要权衡。三角形中未定义的元素是质量；但是，假设该常量是项目团队在项目开始时就在质量栏中明确表达的常量。例如，如果组织希望合并一组新的常量，解决方案中的功能，团队将不得不在进度，资源或其他功能之间进行权衡。并根据需要调整___________。
给定固定的时间表，我们将选择多少资源并根据需要调整已交付功能的数量。
您不能测试一切
计算机软件本质上是复杂的，甚至是在文本框中输入六个字符的用户名的简单操作。将自己限制为ASCII输入仍然需要127 x 127 x 127 x 127 x 127 x 127 = 4,195,872,914,689个测试用例。如果每个测试用例仅花费我们1秒钟的时间进行手动运行，那么在将用户名字段测试到密码文本框之前，它需要790万年的时间。问题，您应该从哪里开始以及应该进行多少测试才能确信自己可以发货？
确定在固定的时间表内要测试什么将您的测试用例转移到电子表格中，添加用于估计执行时间的列，数字等级表示1-5，其中（优先级越高）表示测试的优先级（相对重要性），区域对用户的可见性
然后将各列加在一起（在“重要性等级”列中，以提供测试的总体评分。如果您正在测试新版本的现有产品，您可能需要添加其他列来标识现有奶嘴区域的相对质量。
手握电子表格，您应该对其进行分发，并根据测试的优先级征求意见。甚至可能会更容易地针对每个区域（例如测试，开发，产品管理）提交带有一列的电子表格，并要求每个区域填写自己的数字集，这将使您可以对每个区域进行加权，说将PM投票提高至150％，并降低开发投票说75％。
假设您只有10分钟的测试，这就是它的样子。
完成评级后，您可以在电子表格中添加一列以汇总执行时间。然后，按照重要性等级列对电子表格进行排序，计算出您的时间表可以给您进行测试的时间，然后在估算的执行时间等于您可以使用的时间（即您的测试覆盖范围）时，在表格上划一条线。
跟踪进度
一旦所有预期均得到管理，而您正在进行中，那么我将使用以下指标跟踪我们的位置
活动的漏洞趋势-如果我只选择一个指标，就可以。我用它来处理关于发货日期的期望，以及当前发布中将修复的错误。
功能崩溃-如果正在进行测试，并且该软件看上去不错，但未添加新功能，则测试给出了错误的结论。这张图可以告诉我。不是开发商。该指标告诉我产品如何朝着经过测试的，可交付的，实际的完成状态发展。用这个来知道我们有多有效，我在这里寻找一条平坦的线，每天都远高于零。
通过所有这些指标，我每天都在交流我们如何按照已传达的计划进行进展并根据需要调整优先级。
#2 楼
老实说，发行版中的功能数量是最灵活的。质量永远不会受到损害，这是必然的。在大量客户需求下，最有可能的发布日期不会改变。因此，根据发布之前可用的工时，您受到限制（有时间限制）。因此，质量是有条理的，时间是有条理的，剩下的就是限制功能。确定发布是否太满的最佳衡量标准是将功能，错误和其他相关联发展活动要及时。研究过去的东西在某种程度上是可行的，但是每个功能，每个错误，每种情况都略有不同，因此，在检查过去以了解趋势是有帮助的同时，建立这种关系的最佳方法是展望未来，展望未来的时间可用。因此，要做一些建立这些关系的事情。
对于新功能和/或产品，希望您已经对所有必要的“剩余时间”进行了估算部署新功能的任务。您不能忘记一些“软”的东西，例如发行说明评论，自动测试运行和结果评论等，这些可能不是直接开发过程的一部分，但会受到新功能的影响。我不认为要做的事情是对发行版中添加的所有新错误进行相同的处理。以我的经验，这些地方最容易发生问题。除开发时间外，错误很少会获得“剩余小时数”的估计。对于每个错误修复，都需要执行类似的任务来进行测试，文档编制，回归分析等，因为这些错误也占用了工时。如果您无法测量每个错误的工时，您将很快用光时间。
需要估计未记录的和意外的“功能”。同样，根据我的经验，开发人员在使用一段代码时，看到可以改进的地方时，通常会进行调整和改进。虽然这很好，但是如果您对所有这些代码区域都没有足够的单元测试覆盖率或回归覆盖率（并且通过您的应用大小的声音，我敢肯定是这种情况），那么这些重构工作就很少需要将剩余的小时数扔掉。
常规维护任务也需要在剩余的数小时内记录下来。有分支的源代码库，创建文件备份，更新或升级工具，与任何开发或测试任务一起进行的所有“书面工作”，与SCRUM会议等任务无关的辅助文档任务等等。所有这些都花时间。的“剩余小时数”，然后是相关的燃尽图。然后，应将该图表与发布前的实际可用小时数进行比较，如果剩余时间超过发布所需的小时数，则您已达到“太满”的水平。
可能会发生您会得到“太满”的信息，不是因为添加了更多功能，而是因为“剩余小时数”的估算值被向上修正，此时需要重新确定优先级，并确定将什么推向下一轮开发。 br />
由于发布日期无法更改，并且直到发布日期的每个人每天的小时数不会改变（直到有人发明了时间旅行），比较这两个值将是您最好的决定因素关于发行版是否“太满”。
评论
+1这样可以全面了解估算中需要包含的内容。如果实际估算值大于预期值，为什么不尝试为团队增加更多资源呢？
– Aruna
2011年6月2日21:57
#3 楼
请查看文章软件质量指标：完整图片-http://blog.infostretch.com/?p=56
指标
测试用例执行时间-每个构建/每个模块
缺陷指标（在QA阶段确定的缺陷与QA之后确定的缺陷（UAT /产品）
基于资源的指标-花费的工作量/百分比工作已完成
评论
我唯一提出的建议是在问题中消除“好”一词，因为这会引起舆论……否则，这是一个很好的史诗性问题，我认为这对大多数商店都是挑战。@TristaanOgre您的评论暗示不欢迎意见。我个人认为标题没有任何问题，除了标题的长度。
并非不欢迎意见，只是寻找更多客观答案... :-)
也许“有用”会是一个更好的选择？有很多度量标准没有用，而且可能有害。 :)