4

我们正在尝试为一个开发在线应用程序的小型开发团队(三个半开发人员)运行 SCRUM,但我们无法从非开发资源(例如产品所有者、用户测试等)那里获得时间。

我正在研究一个商业案例,以获取更多非开发资源,并使其更能响应我们对他们参与的要求。

现在的情况:

  • 产品负责人是一个5人的团队,其中一半是从开发团队跨大西洋而来(这比之前完全没有负责人的情况要好)
  • 产品负责人“团队”几乎每月只开两次会
  • 没有专门的用户测试或 QA 资源
  • 完成用户测试的最快时间是 3 周,大约需要 2 个工作日的测试
  • 我们正在努力实现每月冲刺

具体问题:

  • 产品负责人(如果他们是一个人)每周应该花多少时间在他们的产品负责人角色上?
  • 您是否希望产品负责人“每天一整天”都可用?
  • 您希望每月有多少专用测试/QA 资源可用?

我试过用谷歌搜索“权威”答案,或者只是关于团队资源水平的任何报告,但没有找到任何东西。

有谁知道这样的事情,所以我的商业案例不仅仅是“我认为......”,而是可以参考专家意见和现实世界的统计数据?

4

4 回答 4

2

产品负责人(如果他们是一个人)每周应该花多少时间在他们的产品负责人角色上?

根据我在一个由 15 名 DEV+QA 和一名产品负责人组成的团队的经验,我会说平均每周大约一天应该没问题。我还强烈建议遵循代理产品所有者方法,或者创建一个需求架构师(谷歌 Dean Leffingwell 需求架构师)。这实际上是我们所做的,因为我们的产品负责人没有足够的时间在项目上花费时间。

您是否希望产品负责人“每天一整天”都可用?

当然这是理想的。如果有一个位于同一位置的代理,它也会有所帮助。如果没有这个,我强烈建议设置一个时间 SLA,以通过 EMAIL 回答与当前+下一个 sprint 相关的问题。例如在工作日结束时返回或其他。

您希望每月有多少专用测试/QA 资源可用?

如上所述,这取决于项目的类型和团队中开发人员 / BA 的数量。我建议在 BA 和测试人员之间至少建立 1:1 的关系,因为所需的 QA 数量是指定需求数量的强大函数。由于您在谈论在线应用程序,我假设没有很长的回归/集成周期,因此与开发人员 1:3 的关系就足够了。我认为测试人员对需求和可用性有重要影响,而不仅仅是错误修复。另一个因素是您是否打算采用敏捷工程实践,例如 TDD、单元测试、持续集成等。如果是这样,测试资源将更加关注测试定义、可用性、性能/负载测试,而不是回归。

查看瓶颈的一种方法是采用某种可视化工作流程的看板。在该板上,您可以看到瓶颈在哪里。无论是在采购订单、开发还是测试中。如果您正在使用具有常规任务板图表的单个 scrum 团队,您可以通过添加“测试中”和“规范中”列轻松获取此信息(因此总体而言,您有 - 待定 -> 规范中 -> 在 DEV进度 -> 测试中 -> 待定采购订单批准 -> 完成)。如果您发现有太多便笺卡在某个列/阶段,那么您知道在哪里寻找问题。向您的管理层展示这一点,它的经验性和比其他项目中看到的任何信息/经验法则要好得多,或者至少是一个很好的补充......

于 2009-04-07T12:26:15.850 回答
0

我怀疑您会为这些问题找到任何权威答案,因为它们几乎完全取决于特定情况。

关于你的问题:

以我的经验,产品负责人可能会全职参与一个项目,每隔几个月召开一次简短的会议。

对于您的项目类型,根据您提供的详细信息,我不希望产品负责人每天整天都在场,更有可能他们每周左右参加一两次会议。(1 小时会议。)

测试的数量取决于项目在哪里,在它的生命周期中,但是这可能由其他开发人员、BA、项目经理和用户完成,因此这取决于您公司的流程。
对于您的规模团队,我会说 1 个全职 QA 资源可能有用。(取决于你的开发人员有多好。)

于 2009-04-07T11:12:54.607 回答
0

您不能拥有一个团队项目的所有者,因为您发现它根本行不通。你有几个选择,我最喜欢的是宣布独立——他们不想承担成为所有者的责任——你自己承担责任。你清楚地理解了问题,尝试控制,发送一些简明扼要的电子邮件,概述新结构 - 不要请求许可,只要这样做会让他们稍微动摇。

其他答案 - 您不会得到 24x7 的所有者,您必须围绕所有者的日程安排工作,但您可以要求提前知道该日程安排。

QA - 对于 3.5 名开发人员,我希望有 0.5 到 1 名 QA 人员,我希望在 0 到 1 之间,如果你找不到专门的测试人员,则更可能是 0。用户 - 你是新主人记住,建立早期 QA 用户的智囊团并颠覆组织。

顺便说一句 - 基于 20 个组织中的 50 多个项目的答案。

于 2009-04-07T11:38:15.887 回答
-2

我是经过认证的 SCRUM 大师,以下是我对您的情况的分析:

注意事项:

  • SCRUM 不允许“半个开发人员”的场景,开发人员应该专注于手头的项目。
  • 多个产品负责人是一个糟糕的情况。需要一个人对项目有清晰的愿景。您是否将客户视为产品所有者?
  • 如果你正在调整 SCRUM,那么你不是在做 SCRUM 而是在做 SCRUM-BUT。

建议性答案:

产品负责人(如果他们是一个人)每周应该花多少时间在他们的产品负责人角色上?

您可以在团队中拥有一名代理产品负责人,负责推动产品开发并在原始产品负责人和团队之间建立适当的沟通桥梁。

理想情况下,产品负责人应该是一个敬业的人,但根据您的情况,一些可以决定要纳入此 sprint 的任务(业务分析明确的要求),并在您给定的时间内为下一个 sprint 的任务做准备的人就足够了。

您是否希望产品负责人“每天一整天”都可用?

不一定,但应该出席以通过任何沟通方式解释对任务的任何疑问。

您希望每月有多少专用测试/QA 资源可用?

贯穿整个冲刺。在 SCRUM 中,每个人都被称为“开发人员”,并且应该在整个 sprint 中都在场,这增加了知识共享并提高了团队的整体绩效。

高温高压

于 2009-04-07T11:32:39.690 回答