• 可以放慢脚步:BA效率不是通过击键来衡量的
  • 业务分析的通配符身份
  • 是的,您可以在Covid-19期间实际上有效地提出要求!
2015年2月9日,星期一15:00

平衡积压的产能计划

撰写者

 盖伦Feb10

托德·奥尔森 曾担任Rally Software产品副总裁多年。我是Todd,他是Raleigh-Durham地区6th Sense Analytics的联合创始人,那时​​我遇到了Todd。托德(Todd)的背景主要是软件工程师,但是在拉力(Rally)收购6th Sense之后,他也对产品的发展和管理也有了很好的认识。

不久前,Todd在我们当地的敏捷领导力网络小组中做了一个演讲。标题是: 治愈功能 它专注于与计划平衡的敏捷投资组合相关的平衡行为。

在本文中,我想将讨论深入到产品待办事项列表,并讨论与保持待办事项列表健康平衡相关的某些方面和技术。

特征-特征-特征(Feature3)综合征

当我看到Todd演讲的主题时,立即引起了我个人的共鸣。我经常使用一个术语来描述我在许多产品待办事项列表中经常看到的常见反模式。我称它为“特征-特征-特征综合症”。这意味着积压的所有故事(或项目)都是面向客户的功能-其中100%。这也意味着积压的情况令人难以置信。

是什么原因

好吧,很高兴你问。

原因之一是每个产品负责人或至少我遇到的每个采购订单所承受的持续业务压力。当今软件组织的一个一致性似乎是,交付的工作总是比工作人员(能力)要多。这种压力正好落在产品组织和单个产品所有者的腿上。

我并不是说这是好是坏,而是事实。

在Scrum模型中,产品所有者可以“管理”产品待办事项列表。他们天生就有权对其中的事情负责。但是,当功能压力不断增加时,许多人屈服于此,只会将利益相关者或面向客户的功能放在待办事项列表上。

对于短期的活动爆发并不一定有害,但是对于长期的产品生存能力而言,这可能是一个难以置信的短期策略。

那么什么是“平衡”积压呢?

再次,好问题。我的顾问想回答-“取决于”。

认真地说,我认为答案可能会更明确。产品积压需要包含 所有的工作 为客户创建产品或项目所需。它当然必须包含软件功能部件或功能性用户故事-这些是可证明的,否则,意义何在?

但是产品中除了功能本身之外还有一些东西,例如,基础设施开发,架构工作以及支持法规关注的测试活动。这是更平衡的待办事项中某些组件的更完整列表:

  • 开发基础设施
  • 测试基础架构
  • 测试自动化
  • 测试环境& Data support
  • 用户故事–研究峰值
  • 建筑前瞻或跑道活动
  • 设计活动
  • 错误修复(来自较长期的缺陷积压)
  • 用户体验设计
  • 测试可追溯性的时间
  • 系统或产品级别的UAT

我可能想要捕获的所有东西,并按积压中的功能确定优先级。通过在积压的工作中保留故事,您可以为这项重要的支持工作保留时间并使其透明。

这些项目通常不是来自利益相关者或客户,而是来自团队。在这种观点下,产品负责人正在吸收所有三方成员的反馈,并尽其最大努力来聆听和订购积压的产品。

谁是老板?

您采取平衡行动时要考虑的另一件事是,客户并不总是您的老板。是的,在敏捷团队中,您需要推动价值的实现,但是您还需要考虑团队的需求。这些需求通常表现在以下领域:基础设施,建筑和重构投资;以及用于自动化,测试和代码维护的工具。

这些投资通常可以加快上市速度并提高质量。但是他们也从团队中获得了良好的意愿和士气,因为他们认为您正在投资于他们的“健康”以及产品,并且您正在聆听他们的意见。

一个故事

在我的许多产品所有权课程中,我都遇到了一个难题,以激发人们思考积压的积压工作。我提到了一个假设的团队,其中只有一小部分数据库工程师,一个是负责人,两个是实习生。领导将休产假两个月,她通常负责团队的所有复杂后端工作。尽管实习生具有一定的知识和技能,但考虑到三个人的生产率是2.5倍,那么她休假时的生产率是0.5。因此,从根本上讲,总体后端容量将大大下降。

作为产品负责人,您会根据能力和技能设置的变化来改变工作流程吗?即使企业(客户,您的老板,高级领导)正在推动您使用具有重大后端影响的更多功能?

还是仅仅因为那是正确的优先流程,您是否会独立于他们的能力来推动整个团队的工作?

就个人而言,我将更改流程,将其平衡为团队的新功能,然后等待首席工程师返回。是的,我将使其在整个组织中透明化。当然,如果有的话,我也欢迎一些经验丰富的替代者。

但是,即使面对不断增加的“价值压力”,我也会在积压中着重于平衡。我认为这项工作的重要部分是在压力和逆境中保持平衡。

什么是混合?

从本质上讲,有两种方法可以处理产品待办事项列表中的容量分配组合。您可以由每个产品所有者自行决定是否适当地“加载”他们的积压订单,或者您可以定义特定的目标组合。

如果产品负责人有权拥有自己的积压订单并投资于其产品的未来,我总是更喜欢前一种方法。但根据我的几乎所有经验,情况并非如此,绝大多数人都屈服于业务压力并创建Feature3积压订单。

为了解决这种缺乏授权平衡的问题,许多组织为积压的积压商谈了一个固定比率。我看到的一个常见的是80:20;那就是80%的功能和20%的其他领域投资(有时包括错误修复)。在我曾担任开发副总裁及其内部敏捷教练的几家公司中,我们利用这种混合来处理我们所有的积压工作。

有趣的是,有时我们很难填补20%的收入,这总是让我感到困惑。尽管他们不断抱怨企业对我们产品的背景投资,但似乎团队不愿写故事来描述20%的工作。

Salesforce.com

Salesforce有一个有趣的转折,或者至少在其中 2009-2011年时间表*。在他们的案例中,他们为自动化覆盖率至少达到70%的产品确定了20%的“罚款”,而这通常发生在收购新产品时。

这意味着什么?

假设他们会为自己的产品投入正常的组合,例如80:20。但是,如果产品缺乏足够的自动化覆盖范围,则他们将额外投资20%的积压订单,以使自动化按照其规范进行。更有趣的是,这是由管理层而不是团队自上而下推动的。

我特别喜欢这个故事,因为它可以放大Salesforce领导团队的敏捷成熟度。他们清楚地了解到,对自动化基础架构的投资是对其产品的长期投资。

安全 建议

转到另一个示例。 规模化敏捷框架 (SAFe)强烈建议在处理团队能力时采取平衡的方法。但不幸的是,SAFe并未就有效比率或平衡主张提出任何有力建议。他们只是让组织根据PSI做出决定。

虽然我了解这一立场,但SAFe中还有其他一些规定性的地方。我希望这是其中之一。这是容量分配的参考 安全 .

包起来

我希望本文至少能影响您对产品积压中容量管理和平衡的思考。如果您是产品负责人,请阅读,那么我想让您走开,因为这是您工作的重要组成部分,您的团队要依靠它来做好工作。

我的主要观点是您避免使用Feature3综合征。另一点是,需要坚定的决心,长远的眼光和勇气来保持健康的平衡-特别是在压力下。尽管这可能是一个巨大的挑战,但您的团队会尊重您的,如果您达到了这种平衡,您的产品将会更加成功。

最后,这是您的选择。

保持敏捷,我的朋友们,
鲍勃

不要忘记在下面留下您的评论。

* Salesforce在该时间段的几次会议演示中都提到了这一点。一个值得注意的例子是在敏捷2010年大会上。我相信史蒂夫·格林(Steve Greene)是联合主持人。

 罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。 &讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料 .

©BA Times.com 2020

麦格雷戈徽标白色网站