↙️ 😤 🔓 每小时计划和其他Scrum事件优化 🔘 👰🏾 🤒

Pure Scrum就像音乐节上的独角兽一样：它似乎存在，每个人都在谈论它，只有没人能向您展示。在我们的团队中也是如此，我们将对此进行讨论。更具体地说，是关于我们如何减少开会时间，又不致于从会议中受益的问题。

当然，互联网上到处都是关于该scrum的形成者和培养方式，发生了什么以及没有发生什么的文章。我并不假装自己很独特，也没有读过所有东西，因为这类文章的作者多于我的空闲时间。但是，我想告诉我们Android开发团队中的人员如何构建（并且仍在构建）该过程，而实际上却没有浪费时间进行会议和讨论。事实证明，这是因为我的时间（我是PO）和团队的时间非常有限，并且我会尽一切努力避免为了流程而参与流程，同时保持高性能和透明度。

我会给自己一些想法，以便读者开始写一个故事的人物肖像。

我是Wrike的Android团队的产品经理。除此之外，我还担任过Scrum Master的光荣角色。

我们是一个卫星应用程序，大多数客户在办公室工作并使用产品的网络版本。我们每个季度大约发布3个主要版本，但是必须花费大量时间来支持Web版本的改进。由于网络的积极发展，我们每两周发布一次。该应用程序的功能是不失去与团队的联系并监视工作流程。您只能在Web版本中配置环境。产品开发策略是增加受众及其在移动设备上的活动。我们的团队由五名Android开发人员，两名质量检查人员，一名UX设计人员，一名产品经理组成。所有人都非常熟练。

既然读者对团队有了一些了解，我将继续本文的实质-过程。今天，我们将讨论以下Scrum元素：PBR，Retro，Planning，Daily。作为Scrum Master的主要目标是利用这些会议的价值，同时花最少的时间在这些会议上。除了在资源优化方面是合乎逻辑的事实之外，我们还有另一个局限性：我们的团队必须支持20个产品团队的变更。我们不支持所有更改，但是那些影响现有功能的更改需要我们的参与。在本文中，我将向您详细介绍我们花在这四种仪式上的时间以及这种时间框架带来了什么好处。

PBR

我在Internet上找到了这样一个定义：“ PBR（产品待办事项列表细化）是向待办事项列表中的项目添加零件，等级和订单的过程”。根据我自己的经验，我知道在这样的活动中，整个团队通常都会在场，以便提前看到任务，突出不明显的时刻。但是这样的会议需要很多时间，但是我们的团队却没有，因为网络版本带来了很多变化。因此，我们更改了会议的格式。

正如实践所示，乍一看，对于产品而言，存在一系列可能非常复杂或不典型的任务。在研究此类问题之前，我会召集所有人并讲述正在发生的事情的本质-这就是所谓的论坛。这种情况极少发生，但是，它使团队体面地团结起来，并激发了对该任务的兴趣，并且参与产品的开发会令人上瘾。正是由于它的不规则性，这种参与正在增长。这样的会议变得特别，不常规，因此意义重大。

对工作的分析如下：每个任务（故事）都是为一个人计划的（我们称他为“冠军”），并且他对需要完成的工作进行研究。添加一个描述，与UX设计器一起澄清在扩展坞中如果不足的情况下应该如何工作，请咨询后端并编写详细计划。实际上，结果类似于Spike。

由于以下原因，此方法已得到证明：

长时间从事一项任务可以使我们更好地理解其本质。对问题的深刻理解导致冠军可以发现设计中的错误。现在，我不仅涉及代码，还涉及想法本身。一种对有机性决定的检查。
对于我自己，我注意到团队的动力正在增长（没有幸福感，对不起的增长图）以及将任务付诸生产的渴望。
如果冠军的积极性很高，并且他理解问题的实质，那么他会提供一些建议，这些建议可以降低开发成本，填写积压的技术任务，提供UX报价。后者可以节省大量的程序员时间。

我要特别注意花费在此类研究上的时间。挑战需要深入研究，尤其是在遗留情况下。我认为这里有3种主要策略：

“我们会当场解决” –通常直到完成任务时，任务的结束才可见。
« » — : « , ». , .
« » — , , .

如果任务很繁琐，则研究通常与开发并行进行。正常的代码发现不超过一天，并且使您可以建立一个完全准确的开发计划。我想说的是，在所有任务中，约有10％尚待研究，其余的任务无需此过程即可投入工作。我们的性能秘诀是强大的开发人员，并且规则是将20％的资源分配给技术任务。该团队更了解如何以及在何处进行直接努力，以使代码保持健康状态。对我而言，这正是使您能够快速处理产品任务，使开发人员满意，使计划清晰且准时的工具。它发展了一种工程文化，并支持团队中成员的积极性。

复古风

在这里，我不会吹牛，只是说团队有一个规则：与问题一起提供解决方案。团队中的人有责任感，他们希望工作良好，而又不会因为琐事而分心，因此他们对流程清晰，可靠的做法很感兴趣。

让我举一个Retro面临的问题（问题）的例子-我们忘记添加分析了。似乎它与PM无关，而不是与开发人员有关，但是，正如我所说的，团队中的成员都有动力，并希望做好自己的工作。由于有限的分析资源，因此理想情况下无法执行此过程，因为从一开始，我们就建立了特定的过程并在团队成员之间分担责任，以便每个人在特定阶段都能带来自己的利益。还要注意的一点是：如果一个小时内我们没有时间弄清楚如何解决问题，那么我们同意尝试提出的想法并逐步进行调整。

但是，在某些极端情况下，专业目标也会有所不同，并且团队成员之间可能会出现一些粗糙的地方，换句话说，工程师更加专注于技术部分，产品上的PM，而设计师则更加关注便利性和图形。但是，由于我们的主要共同目标是创造出优质的产品，因此，我们不会在团队成员的利益交汇处讨论问题。这里值得一提的是，我们习惯于坦诚相待。如果团队中的某人为表达自己的观点而感到尴尬，则很可能该团队存在不平等或存在潜在的冲突。只有系统中的平等才允许您开放。如果您对我们如何做到这一点感兴趣，请在评论中让我知道，但是现在，让我们继续。

规划

我最喜欢的Scrum部分。我喜欢它有两个原因：

很有趣;
它实际上不需要我的参与。

该过程如下所示：有一个我为sprint定义的任务列表。每个团队成员与其他成员一起决定在什么时候开始做点什么，什么更好，什么是任务的接受标准。团队成员自己设置UX，DEV和QA之间的依赖关系。有趣的是，正是因为他们同意他们的意见，为他们安排了自己的优先任务。他们讨论，开玩笑，他们作为一个团队，在这一刻团结一致。根据他们的计划/心情，他们了解自己想做什么和何时做，以及为此设置的时间和依赖性。事实证明，工作量之类的东西-规划不是基于任务，而是基于人员。

乍看之下，似乎有些混乱，但由于团队本身在计划，因此精通所发生的事情并及时进行更改

日常

首先，这是关于同步的，但是我想在此事件中单独强调我作为产品经理的角色。我已经说过，团队中的平等很重要。气氛应该使这些家伙感觉像一个团队，而不是个人贡献者。因此，作为产品经理，我告诉公司新闻，以及我在做什么，我认识到什么和等待我什么。我在团队面前没有秘密，尽管例外情况极少发生：有些事情需要保留直到正式宣布。但是，这样的公告与众不同。

总

以论坛形式参加为期1天的小会议+罕见的会议，向孩子们介绍不寻常的任务，使他们对我们要做的工作有很好的了解。规划只需要一个小时，而且可以自由进行，所有人都完全同意他们需要做的事情。Retro总是以一种格式进行，但是它的生产率很高，并且流程中的小事情会定期得到改进。产品经理在日常团队中的开放态度形成了对团队的平等和信任。

最终，对我而言，只有三个指标才有意义：团队对员工的满意程度，确保他们不会疲倦，产品质量和任务速度。

我们团队中的这些指标很高：

质量：版本发布后有2-3个错误（而且我们有大量版本）；
速度：我们由5名开发人员，2名质量检查和1名UX组成的团队支持20个Web团队创建的更改；
满意：在Wrike工作的五年中，一名开发人员和一名质量检查人员离开了公司。

蛋糕上的结冰

一点数学。对于两个星期的冲刺，结果是：

每天10次，持续15分钟；
每小时±2个论坛；
计划1小时；
复古1小时。

总计：4小时30分钟±2小时，为期两周，共80小时。

很明显，应该将此数字乘以团队中的人数，以了解事件Scrum花费了您多少小时。我的指标是5.6％±2.5％，团队规模为9人。团队越大，这个价值就越高。但是，请不要忘记Scrum团队拥有建议的规模，这意味着花费在团队活动上的时间指标也有合理的限制。

总的来说，现在。如果您分享数字，这将是理想的选择：您有多少时间参与事件Scrum。好吧，为了使本文更有价值，让我们讨论一下您认为这种优化可能带来的好处和坏处。

每小时计划和其他Scrum事件优化

PBR

复古风

规划

日常

总

蛋糕上的结冰

More articles: