SCRUM - 适当的非开发资源水平? [英] SCRUM - Appropriate non-development resource level?

问题描述

我们正在尝试为一个致力于在线应用程序的小型开发团队(三个半开发人员)运行 SCRUM，但我们无法从非开发资源(例如产品负责人、用户测试等

We are trying to run SCRUM for a small development team (three and a half developers) working on an on-line application and we are having trouble getting time from non-development resource e.g. product owner, user testing, etc.

我正在研究一个商业案例，以获取更多非开发资源，并更好地响应我们要求他们参与的请求.

I'm working on a business case for getting more non-development resource and for it to be more responsive to our requests for their involvement.

现状:

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

具体问题:

• 产品负责人(如果他们是一个人)每周应该在其产品负责人角色上花费多少时间?
• 您是否希望产品负责人每天全天"有空?
• 您希望每月有多少专门的测试/质量检查资源可用?

我试过在谷歌上搜索权威"答案，或者只是关于团队资源水平的任何报告，但没有找到任何东西.

I've tried Googling for "authoritative" answers, or just any reports on team resource levels, but have not been able to find anything.

有没有人知道这样的事情，所以我的商业案例不会只是我认为......"，而是可以参考专家意见和现实世界的统计数据?

Does anyone know of anything like this so my business case won't just be "I think...." but can have references to expert opinion and real world statistics?

推荐答案

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

How much time per week should the product owner (if they were a single person) be spending on their product owner role?

根据我与 15 名开发人员 + QA 和一名产品负责人的团队的经验，我认为平均每周大约一天应该没问题.我还强烈建议遵循代理产品所有者的方法，或者创建一个需求架构师(google Dean Leffingwell 需求架构师).这实质上就是我们所做的，因为我们的产品负责人没有足够的时间在项目上花费时间.

I would say that about a day per week should be fine on average based on my experience with a team of 15 DEV+QA and one Product Owner. I would also strongly suggest following the proxy product owner approach, or create a requirements architect (google Dean Leffingwell requirements architect). This is in essence what we did, as our Product Owner didn't have the bandwidth to spend that time on the project.

您是否希望产品负责人每天全天"有空?

Would you expect the product owner to be available "all day every day"?

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

of course thats the ideal. It also helps if there is a proxy that IS co-located. Without that, I would strongly urge to setup an SLA of time to answer questions related to current+next sprint via EMAIL. e.g. return by end of business day or something.

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

How much dedicated testing/QA resource would you expect to be available per month?

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

As answered above, it depends on the type of project and the amount of developers / BAs on the team. I would suggest having at least a 1:1 relation between BAs and testers, on the logic that the amount of QA required is a strong function of the amount of requirements specified. Since you are talking about an online application, I assume there isn't a very long regression/integration cycle, so a relation of 1:3 to developers can suffice. I see testers as an important influence on the requirements and usability not just bug fixing btw. Another factor is whether you intend to adopt Agile engineering practices e.g. TDD, Unit Testing, Continuous Integration, etc. If so, the testing resources will be much more focused on test definition, usability, performance/load testing, rather than regression.

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

One way to see what is the bottleneck is to adopt some sort of Kanban board which visualizes the workflow. On that board you can see where the bottleneck is. Whether its in the PO stuff, development, or testing. If you are using a single scrum team with a regular Task Board Chart, you can easily get this information by adding a column for "In Testing" and "In specification" (so overall you have - Pending -> In specification -> In DEV Progress -> In Testing -> Pending PO Approval -> DONE). If you see that too many of your sticky notes are stuck in a certain column/stage, you know where to look for a problem. Show this to your management, its empiric and much better than any information/rules of thumb seen in other projects, or at least a very good complement to that...

这篇关于SCRUM - 适当的非开发资源水平?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！