黑暗面敏捷

细心的读者翻阅磁带，问一个问题：“关于敏捷的文字又是什么？”。 是的

本文介绍了流程，技术方面，以及有关敏捷生活和在Yandex.Money中如何实现的一些知识。 如果您至少走了一半的步伐来实现真正的敏捷，那么您可能会发现一些明显的东西，这很好。

当每个人都分散在团队中并享受生活时，在关于测试台的猫之下，将人们锁定在会议室中以及如何管理部门。

细心的读者会问：“为什么是阴暗面？达斯·维达有什么意义？” las，不，这将是人类所不知道的月亮的黑暗面，直到装置飞起来拍摄并将其展示给所有人。

当您实施敏捷时，您正在设计一个月球探索项目，却不知道
另一面是什么

一切始于尝试引入新的开发过程。

Scrum，看板，scrambana或其他一些本地自行车并不是那么重要。

古典开发部门通常由资源经理领导。 他对外界说：“不要去开发商，去我这里，我现在将所有东西分发到这里。” 这样的经理第一次分配流，因为出现了一些特殊的客户。 然后，公司内部和外部都有更多这样的客户，冲突开始，资源争夺，经理必须解决所有问题。 也可以通过线程分配。

Java-左，JavaScript- 右

这场比赛一直持续到某个关键时刻，之后公司接受了现在需要敏捷的想法。 之所以会出现产品团队，是因为对于PO而言，没有什么比专用资源和您自己的团队更有价值的了。 该产品很高兴，因为现场团队使对功能的回答更加轻松，并承担了PNL，流量和其他KPI的责任。

听起来是正确的，但在现实生活中，一切都有些错误。

在大多数经典开发部门中，使用整体组件会更有利可图。 在这种情况下，所有属性都将附加-3-4周内的发布周期，长时间的测试和组装。

有时整体是正常的

但是选定的团队却不能那样工作。 总的来说，由于每个人都开始转向小团队并在其中工作，因此微服务成为了世界。 是的，这导致代码“传播”并且所有内容变得更加难以控制。

另一方面，我们加快了产品发布的速度，更频繁地发布产品，但是我们遇到了测试问题。 而且它们还需要以某种方式解决。

测试改革

如果您只有一个团队和一个测试台-一切都井井有条，那么您就不必担心（或担心，但原因有所不同）。 在这种情况下，通常甚至不认为它很重要-例如，诸如邮件或公司聊天之类的附加工具。 每个人都在密切监视生产情况，他们也很好。

如果您已经飞过Edgile Moon，那么测试台将减慢整个过程的速度，这就是原因。

人生故事 ：在一家公司中，敏捷周围的熵开始变得过快。 在这一点上，测试人员进入了日历中唯一的测试台的时间表-他们将时间分成半小时，试图以某种方式控制混乱。

实际上，应该有20个团队使用看台，但不能使用，因为其中一个破坏了一切

关于测试台

从前，我们有几个整体，每个整体都有一个测试台，每个人都很高兴。 一旦完成了一个用于分离展位的复杂项目，便分配了团队，然后有20个展位。

现在有70个，但我们的目标是200个，这样每个人都可以免费，而且没有人得罪。

从与管理员的对话中：
-告诉我，部署自动化在哪里？
-每两周进行一次计算需要一个小时，在这里我应该如何自动化？

实际上，这是：（200个机架+产量）*（50个以上组件）=需要大量的部署工作。
现在，我们有50多个机器人可以部署的组件。 如果不适合他，那么每个人都会很糟糕。

在这个阶段，迈向敏捷的公司将拥有用于组装和交付生产的自动化系统，团队工作将逐步改善，性能也将提高-每周多达60-80个发布，每个组件每天发布2-3次。

在这一点上，每个人都知道该系统已经变得太大，以至于一个人都无法掌握它

在任何支持整体的团队中，肯定会有一些老朋友。 他们从一开始就在这里，记住所有时间的所有错误，记住企业正在出售的奇怪的逻辑决定。

人生故事：
“一般来说，敲一次客户3次是正常的，但是这个客户很特殊，我们会敲100次，有修正因素，不需要碰它，请碰它，不只是这样。”

花费太多的资源来维护工作台的工作，以至于该操作成为“黄金”工作-将整个服务器场乘以测试台的数量，增加产量，烦躁不安，最后打电话给管理员。

其他监控

管理员会说：“一切都受到我们监视的覆盖”。 很好，但是需要澄清的是-可以自定义监视。

“铁”指标，Java消耗的内存量，所有处理器的所有内核的温度-所有这些都是有用的，但是在发生客户事件时并不能总是有帮助。 如果您没有自定义业务指标，那么它们也将一无所知。 世界是复杂的-很少所有理想的客户端都理想地使用您的理想API。 人做一切，每个人都必须适应-有时客户适合您，有时您适合客户。

像核电站

生活故事 ：长期以来，我们一直在搜索并修复产品中的错误。 此后，其中一位客户中断了几个考虑了该错误的过程。

在这种情况下，您必须添加自定义监控，因为如果不隔离特殊情况和汇总，它将根本无法工作。 因此，顺便说一下，他们经常谈论和撰写有关机器学习和定义问题而不是人员的复杂系统的文章。

每六个月一次，您必须进行监视审核，因为业务期望会随着时间的推移而增加。 发生这种情况-一切都在公司内部建立和控制，并且业务带来了需要SLA数量级高的新客户。 整个故事结束了。

如果克服了这个问题，那么该系统将在所有情况下都能正常运行，除了“伞”项目。

伞项目

例如，这就是54-FZ的引入，当时该州说：“并重组该国的所有现金流程。” 或者，当市场营销为该项目付费时，该产品仍然必须正常工作，而且最后期限是真实的，然后他们会为此进行拍摄。 或者，当高层管理人员进来时，无论什么原因都没关系，他还有一个有期限的项目。

剧透-市场上很少有人了解如何制作它们。 您可以通过scrum和看板购买不同的加载项，可以阅读成功案例，但实践表明，从理论上讲，进行此类项目的成本更高。 此外，所有这些SAFE和LEAN在管理上和资源上都是昂贵的，并且它们还需要市场上没有的昂贵且复杂的能力。

人生故事： Spotify是敏捷公司的典范之一。 在某个时候，他们提出了家庭订阅，但是由于在拥有自己的路线图和计划的团队之间进行同步和计划时遇到了困难，因此无法实现。 一年后，谷歌和苹果推出了家庭订阅。

同步和调度冲突

总括项目的主要问题是所有参与团队的同步。 这与人们不喜欢谈判这一事实有关。

当人们无法在一个资源部门的框架内达成一致意见时，这在许多事情上都表现出来，从混乱开始。 在敏捷中，您必须同步和协调多个团队发生的所有事情。 而且，如果在某个时候您不再要求每个人都在一起工作，那么每个团队都会回到自己喜欢的黑暗角落并独立工作。 这导致失败。


生活骇客
如果在下一项法律颁布之前，广告宣传活动之前或老板要求之前还有两个月的时间，则将4个团队的人员带入一个房间，提供食物，水和控制权。 这很粗鲁，但是可以。 因为如果您尝试在有限的时间内进行同步，则将使项目失败。

通常，需要同步，没有同步，您将无法继续。 它使具有明确截止日期和高关键性的项目的生活复杂化-截止日期介于10％到50％之间，这通常是不可接受的。

如何处理？

分布式部门的经典领导者不了解他的角色，因为他被教给了范式“我向所有人分配任务”，并且我不得不与“我根本没有人，为什么我在公司里工作？”一起工作。



对于控制狂来说，最糟糕的事情是他们不会错过部门解决的一项任务，安排两次公共代码审查并真正控制一切。 当人们被分配到团队中时，他们会问一个问题：“我为什么在这里？”。 答案是，所有团队的开发人员都可以交换信息，在一个方向上同步增长，并且系统不会爬行。

通常，当听到这样的问题时，需要更换或教导领导者。

进行教学是因为许多领导者（包括我们）都是从工程师中成长出来的，而且从未有人教过他们软技能。 我们认为这很重要，并且一旦进入人力资源部门并要求为管理人员开设为期两年的大型课程-从基础到绩效和非财务动机。

IT文化

在组织团队方面，敏捷还有另一个微妙之处。 当开发人员在团队中达成共识时，他们可以开始捍卫团队的利益，而忽略了公司的利益。



理想情况下，当人们了解到他们的Ajail月球周围还有其他人时-一种具有自己要求的安全服务； 不仅是发明的架构； 需要考虑其利益的其他团队。 我们努力识别，培育和鼓励这种行为。

敏捷-冰山一角

该路径具有重要的特征。
好久不见 例如，DevOps于五年前投放市场，根据公司的规模，其实施现在需要1-2年。 如果您在测试台上有排队时就开始处理它，那么可以保证六个月的地狱，因为管理员会在所有事情之间陷入困境。

贵的 只有拥有强大的业务和强大的公司，并且您了解到将来您仍然需要成长，您才能实施敏捷并沿着这条道路前进。

没有人 敏捷需要新的能力，而人们没有那么多。 事实证明，这是一个恶性循环-没有人->一切都做得不好->没有钱->没有人可以带走。

三个结论

1. 不要触摸不需要的“经典”开发部门。 Yandex.Money中使用了一个混合系统-有一个产品团队，但是有些部门可以在没有敏捷的情况下有效地工作。
   
2. 如果您没有重建整个公司的任务，但是有使用新方法更快地生产新产品的愿望或需求，则有时可以更轻松地聘请从事敏捷工作的外包商并为产品提供外部资源。
   
3. 如果不可避免地要进行IT转型，那么最好就“岸上”的一切达成共识。 与领导者达成一种“绅士协议”是值得的-将有预算用于硬件，人员（用于系统管理员，测试人员和开发人员的新职位）。 在这种情况下，可以定期返回此协议并讨论所做的事情和如何做。
   

以上所有都有一个麻烦。 一路走！=走向成功。 不通过=保证失败。

但是，如果您在路上-祝您好运！