2

假设您是拥有 2000 名用户和 7 名开发人员的内部企业 Web 应用程序的产品经理。您有一个包含 350 个未来功能的列表，每个功能都需要 5 到 150 个开发人员日的工作时间。

您如何选择要处理的功能，以及如何运行发布过程？

以下是我的想法：（如果无聊请跳过）

  • 发布过程。一次处理多个功能，准备好后单独发布每个功能。另一种选择（到目前为止我们一直在做的事情）是挑选出一组特定的功能，将它们指定为“一个版本”，然后一次性发布它们（通过群发电子邮件宣布）。

    更短的发布过程的好处是我们可以在完成开发后立即发布功能。更大流程的优点是更容易组织。

  • 功能优先级。将所有未来的功能放在一个电子表格中，其中包含功能、描述、评论、估计、收益、（您的）估计、（您的）收益的列。将副本提供给 2 名高级工程师、另一名高级项目经理和您自己。

    工程师估计所有功能（精确度如何？互相咨询？）。为了确定收益，每个人在未来特征之间分配分数（总分 = 10 * [未来特征数量]）（无需相互协商？），比较分数和平均值（？）。

    这里的另一个潜在策略是仅以绝对（例如）1-100 的比例对每个特征进行排名。拥有绝对排名很好，因为它使我们的功能列表更改时的优先级更容易（我们不希望每次有人提出新功能时都必须重新分配积分）。

你的策略是什么？是否有任何书籍/网站以这种详细程度来解决问题？

4

5 回答 5

3

有一本很棒的书可以帮助涵盖这个主题，称为Mike Cohn 的敏捷估计和规划。它有一些很好的方法来估计和计划发布。包括一个称为计划扑克的计划游戏，工程团队在其中收集卡片来估计用户故事。每个工程师打出一张牌 1,2,3,5,8,13 面朝下。高低牌解释，你再做一次。在 1 或 2 次重复之后，通常会在相同的估计上收敛。

还有《超越软件架构：创建和维持成功的解决方案》（Luke Hohmann），它可能有助于一些与产品管理相关的部分以及用于确定优先级的推理。我还没有读过这本书，但我参加了 Luke Hohmann 的演讲，他谈到了他书中的主题，我迫不及待地想读它。

我还建议阅读有关各种敏捷开发过程的书籍，例如 Scrum、Crystal Clear 和 XP。Ken Schwaber的Scrum 敏捷项目管理和Alistair Cockburn的 Crystal Clear：小型团队的人力驱动方法论。还解释了极限编程： Kent Beck 和 Cynthia Andres 的《拥抱变化》（第 2 版）。

至于功能优先级，通常由利益相关者完成。您需要处理满足利益相关者需求的功能，正如 Luke Hohmann 指出的那样，其中包括系统架构。

但是，最重要的事情之一是确保您在团队中就软件开发过程达成一致。如果你强迫一个过程而团队不相信，那么它就行不通。

于 2008-11-14T06:23:09.207 回答
0

当然，您没有 350 个独立的功能，有些必须依赖于其他功能。将它们全部放入一些任务管理软件中，该软件允许您定义哪些任务取决于哪些其他任务，您可能很快就会发现您的决策过程要容易得多......

于 2008-11-14T06:51:48.247 回答
0

至于发布过程，您可以在功能准备就绪时介绍这些功能，并通过公司博客通知用户，该博客在新功能完成时会更新。然后，这样的博客条目应该简要概述该功能、在哪里找到它、如何使用它等。
这不仅让您的用户保持好奇和回来，它还为潜在客户提供了一个很好的方式来查看您提供的进度。

至于优先考虑未来的实施：让客户也参与进来怎么样？查看 uservoice（它用于跟踪该站点的请求/错误）。它提供了一种让用户对最想要的事情进行投票的好方法，并显示正在处理的内容和计划中的内容。

于 2008-11-14T06:57:24.990 回答
0

“以绝对（例如）1-100 的比例对每个功能进行排名”

按顺序构建它们。

当你有（a）重要价值或（b）小东西的临界质量时释放它们。

始终按优先顺序工作。首先构建最重要的东西。尽快交付尽可能多的价值。

于 2008-11-15T03:07:12.613 回答
0

这里的一些人已经说过 - 让最终用户参与决定什么进入和等待什么的决策过程。毕竟，它不是关于什么对您有用，而是什么对您的最终用户有用。

也就是说，我不会将其留给“所有用户来决定”；应该有来自与您一起工作的用户组的代表（即高级用户角色）。

即使那样，您也不会说“您想要什么功能？” 对用户来说，你问他们接下来希望看到什么功能。你把它交给他们而不是让他们挑选一个庞大的单个功能电子表格的原因有两个：1）他们不知道依赖关系，2）你想收集一组功能以进行合乎逻辑的发布.

所以用户代表可能会说“我们需要让照片库接下来工作”。他们可能不知道照片库实际上与文件上传模块相同（它只是接受不同的文件类型）。

所以，在下一个发行版本中，你将照片库和文件上传打包在一起——考虑到文件上传已经完成了 75%，因为照片库模块中的工作，你为什么不这样做呢？

我不认为您必须首先研究最难的功能，它是用户更快需要的+您收集的其他功能以制作“逻辑包”。

在某种程度上，您也想清除功能日志。因此，例如，您可能具有以下功能和估计时间：

  1. 登记表 - 3 小时
  2. 照片库 - 8 小时（<- 客户说他们接下来想要这个）
  3. 文件上传 - 2 小时
  4. 投票/投票模块 - 7 小时
  5. 股票行情 - 5 小时

出于这些人为的功能，我不会接受。2（因为客户要求它），那么我不会。1和3。没有。3 因为它实际上是在画廊代码完成时完成的，而不是。1 纯粹是因为它是剩余特征中最小的估计。没有什么能让你或你的编码人员感受到你的项目取得进展的感觉，就像认真击败功能列表（尽管它可能会重新填充）。

至于让人们了解新版本及其内容，我会通过电子邮件（而不是通过博客或程序本身）进行。我会尽可能简短，要点，如下所示：

===

Blue Widgets 1.1 版刚刚推出，现在可供您使用。

添加了以下内容：

  • 照片库

  • 上传文件

  • 报名表格

系统内的用户手册包含有关这些功能如何工作的更多信息。

===

砰 - 完成，让人们尽可能容易。

  • LM
于 2008-12-05T23:30:15.303 回答