SCRUM变得如此流行，以至于现在他们正尝试在几乎所有地方实施它。 在大型公司中，有时发现SCRUM的实现是出于报告的目的，或者是为了“进步”和“时尚”。 他们说，结果是，看起来像是负责任的经理的情况设置了下一个检查标记，他们有必要实施方法论-已实施，做得很好，但在输出上出现了所谓的“僵尸SCRUM”，而不是本质上的改进。 这是正式实施框架的时间，但是没有人能正常工作。 因此得名。
我的名字叫Oleg Egorkin，我是Rostelecom的敏捷教练，在这篇文章中，我将解释为什么一般会出现“僵尸僵尸”，如何避免这种情况以及如何确保公司已准备就绪可以成立一个Scrum团队。
现有的运行命令方法
有时，他们尝试从头到尾建立一个IT团队。 这是开发人员自己和部门负责人了解到的时候了，对于这个产品，我们需要伤痕累累。 优点是主动性来自主题中的人们。 减号-使用这种方法，不会涉及业务。 而且，如果不参与业务，则采用这种方法的组织结构本身要么变化很小，要么（通常）根本不变化。 结果，这种混乱变成“僵尸混乱”的可能性非常高。 当然，并不是在第一天一切都会出错。 但是大约六个月后，人们会意识到，启动时的所有缺点都没有解决。 因此，挫折感总是影响产品。
有一个相反的故事-从上到下。 也不是要争取的东西。 举例来说，请记住，几年前，在敏捷之初，根据高级机关的指示，“到夏天”到年底，在绿色银行中启动了50个新团队-到5000年。这是为了进行scrum的scrum的唯一方法。 在这种情况下会发生什么？ 人们急着跑腿。 在屏幕下方，所有未拧紧的东西都开始排成一行。 这个故事中的Scrum绝不是开发改进和新方法，只是经理KPI的一小部分。 结果就是“僵尸混乱”。
还有第三种方法-主动是上下同向的。 我们很幸运，就在Rostelecom。 在什么东西。 在最高管理层，团队中的所有转型方法都得到持续的帮助。 在这种情况下，没有人提出“雄心勃勃”的计划。
对于大型和超大型公司，这并不是完全熟悉的。 它的工作原理是这样的：我每月一次进行为期一天的敏捷基础培训。 IT员工和业务人员都参加了培训，该团队共有25人。 我试图尽可能广泛地谈论它。 经过一段时间（可能需要一个星期到几个月的时间），同事消化了所获得的知识后，提出了一个可以理解的要求，以组建一个Scrum团队。
关于清单
对我有两种类型的请求-作为现有产品转换的一部分来成立一个团队，或者针对新产品向团队提出要求。 为了处理这些请求，我编写了一个特殊的清单，在清单的帮助下，我检查了运行所需的所有条件。 如果该应用程序没有通过任何一点并且不满足初步要求，那么我们就不会运行该团队。 这是公认的需求-如果您坦率地获得至少一个分数并在没有它的情况下运营团队，那么它仍然不会带来结果。 好吧，除了事实并非如此，还可以激励所有参与者。
如果有IT部门的人来找我，我请他与企业交流，然后再回来。 因为敏捷是关键业务。 从这里我们有了第一个清单项目：
1.敏捷团队应该要创建业务
在这里，就像吸血鬼一样-他们不能随便进入房子，必须被邀请。 对于敏捷教练来说，同样的事情，必须改变。
来自商业和IT部门的人们注意到某些产品在困难的市场条件下可以工作，他们自己与我联系并说-方法需要改变。 在这里，如果您非常幸运，那么请求就在一开始就到达了，那时还没有团队，但是有一个想法，人们可以开始聚会。 同时，每个人都知道无法为产品形成清晰的规范，它会根据业务模型而变化，并且不清楚哪种模型有效，哪种模型无效。
通常，参与业务非常重要。
同样重要的是，这种参与的动机应该是切实的，而不仅仅是炒作。 因此，我检查业务动机大致可归纳为以下几点：
- 如果该指标太大，则缩短上市时间；
- 提高团队工作效率；
- 面对不断变化的优先事项，提高可管理性。
如果这三点中的任何一个都正确，那么一切都很好，这是一个肯定的信号，表明团队开始具有足够的期望。
2.必须有要发布的产品
首先，这是合乎逻辑的。 没有产品时，为产品运行一支产品团队是很愚蠢的。 而且，围绕产品或服务，我们所有人开始做什么都无所谓。
3.产品的所有者必须有发展的愿景和路线图
此外，提前一年的路线图是最小的，以对通常需要完成的工作具有最高级别的理解为形式。 即使一个人对自己将采用的商业模式有3-5个假设，但他仍想探索什么。 如果我看到有路线图，请继续。
4.企业必须有钱
即，一个跨职能团队的预算。 因为该产品应聘请专职团队使用，并且企业应该准备提前一年左右为该产品付款。 我确保所有步骤都完成了，我看看其中涉及哪个财务责任中心，以致无法确定有一个主意，想要组建一支团队但没有钱。
5.必须是公司的产品负责人
所有者。 不是业主。 一位所有者。
专门致力于此特定产品的人。 在某些情况下，有两位经理来说-我们想创造一种激励性和教育性的产品（对员工而言是一种内部事物）。 我告诉他们-很好，但是您有产品负责人吗？ 他们回答-是的，当然，产品的一位所有者是培训人员，而另一个-是动机。 该产品具有激励性和教育意义。
当时我要求思考并同意由谁负责整个产品。 事实证明，这是一件非常困难的事情，该团队仅在六个月后就被启动。
一种产品-一位产品所有者。 这很重要。
6.开发团队中的所有参与者也应100％分配给该产品。
如果开发团队中的某人以50％，30％，10％的价格工作-这不是马上的事情。 一个必须完全存在于产品中。 但是同时，我不需要在同一地点的团队。 在我们的条件下，是如此的稀有，Rostelecom很大，我们有很多子公司和分支机构（子公司分支机构），团队中的开发人员可以在其中工作。 它们可以分布在莫斯科，彼得，克拉斯诺达尔和我们庞大家园的其他城市。 在莫斯科快速组建一支团队有时很困难且很耗时，但通常根本无法正常工作。
因此，我继续前进，但是有一个相反的要求-团队在培训进行的前两天聚会，然后每六个月保持联系以保持个人联系并讨论当前问题。
7.产品付款方式
这也是一件重要的事情，以及与金钱有关的很多事情。 当产品所有者拥有预算时，可以根据需要支出。 也就是说，将传统知识写在订单上，对其执行情况进行评估，然后为这种情况分配预算中的资金。 听起来很简单。 但是有细微差别。
当您切换到自定义工作时，在订单执行结束时，应该有用于接受产品并将其转移到操作中的过程。 而且由于传统知识已经获得批准，因此对其进行更改非常困难。 任何修改都必须重新协商，批准。 这是一个非常复杂且缓慢的过程，与对变化的快速反应不兼容。
我们做了什么，以便不让自己沉迷于此并且不发疯。
签订合同并支付整个团队的时间后，您便可以从事“时间与材料”工作。 也就是说，有一个为产品所有者服务的团队。 她的服务每月或每季度支付一次。 但是在我们国家，由于官僚主义的限制，这不能以纯粹的形式完成。
因此，我们开始在季度订单级别上使用固定的路线图（不是TK）作为定制开发的一部分，而该订单未详细说明如何实施路线图。 产品负责人具有积压生成的灵活性。 当季度结束时，我们从饮食中卸载已完成的任务清单，并在此基础上形成已签署并已支付的行为。 事实是相同的时间和材料。
这里没有必要明确遵守传统知识，因为没有传统知识。 在检验假设之后不再有意义的需求根本无法满足。
8.除与产品相关的KPI之外，团队不应具有任何KPI
这一点很重要，因为开发人员是由子公司雇用的，子公司使用KPI设置其进行回收（这是开发人员必须经常忙于处理某些事情的时候）。 实际上，几乎所有集成商都是这样工作的-在同一开发人员的一个项目（或多个竞争项目）短缺的情况下，他们会在多个项目上绘画。 然后，为了使公司盈利，他们将开发人员置于KPI中，以使他始终至少要忙85％。 也就是说，他实际上具有一定的KPI，这促使他适应最大数量的项目，以便根据需要的数量调整其处置方式。
幸运的是，Scrum团队没有这种需求（事实上是100％）。 我确保团队除杂货店外没有其他KPI。
合计
这是我的清单。 据此，我在开始之前检查了所有车队，并且由于我们采用同向的方法，因此如果车队没有至少通过这些要点之一，我可以要求条件变更。 因此，输出的只是那些准备实施敏捷方法的价值的团队。
如果团队的申请通过了所有这些要点，则下一阶段开始-培训和启动团队。
我将在下一篇文章中讨论=）