ivi技术总监
Evgeny Rossinsky （
eross ）在流媒体技术方面的报告方面非常熟悉我们的会议参与者。 但是今天，您获得了Eugene在
TeamLead Conf上的报告的笔录，内容涉及敏捷变革如何在团队领导者中体现。
不久前，在ivi中，我们经历了敏捷转型，并从以下方面获得了可观的收益：
但是，这一创造性决定的后果严重打击了团队领导。 该报告仅涉及如何处理此问题以及使用哪些工具。
改造前
为了理解我将要谈论的内容，我们需要对我们的产品有所了解。 然后，我们将分析为什么具有这种格式的命令以及为什么选择此路径。
ivi的开发有
五个主要平台 ：
- 的iOS
- 安卓系统
- 网页
- 智能电视
- Windows + Xbox。
当然，还有后端，如果没有后端，那就没有了。 在我们决定进行转型之前，我们的团队是由能力组成的。
知道例如Swift或Objective C的人：
- 坐在同一个房间
- 接收产品经理的任务；
- 对它们进行工作并产生结果。
一切似乎都很好，但是存在一个问题-平台在产品和用户对内容的消费方面有很大的不同。
这意味着
在每个团队中，其积压工作和优先事项
开始出现 。 例如，Web应用程序的用户不喜欢付款，并且内容通过广告模型消费。 该平台所需的功能自然会出现在待办事项列表中。 智能电视的特点是价格低廉，并体现了付费模式的特征。
事实证明，存在以下情况：有人提出了如何改进产品的绝妙想法； 我写了很多票给产品经理，每个人负责他们的平台。 管理人员通过他们的感知棱镜传递想法，也许他们将某些东西现代化，并将其纳入他们的工作计划。 这里的问题是，一个功能可以在所有平台上发布超过一年，因为“我认为它根本不是我平台的优先事项。” 在一年，六个月或短短几个月内，产品可能会发生任何事情-例如，重新设计或概念更改发生了，并且此功能已经需要推出，并且与所有其他平台完全不同。
结果，一段时间后，事实证明，
在不同的平台上，我们拥有完全不同的产品 ，它们具有不同的通信消息和业务逻辑。 在这种情况下，用户开始感到困惑，因为他没有一个让自己感到自信的空间。 另外，
很难建立假设 ，因为并不总是清楚哪个功能最适合哪个平台。 这完全取决于屏幕的大小，人们如何消费内容。 一切看起来像这样：
精巧的产品带来了这个想法，并且不同平台上的开发人员对它的看法相当不友好，除了后端（通常写什么都没关系）。
因此，由于该公司在灵活的方法论方面具有足够的能力，因此我们同意业务需要消除以下因素之间的障碍：
进行有效的互动，并做一件常见的事情。
改造后
这样就形成了具有专用
价值流的体系结构，其中每个团队都参与特定的业务领域。
为了形成一个新的结构，我们：
- 进行了几次培训；
- 确定我们业务的主要领域；
- 他们自愿迫使人们进入价值流；
- 开始实施。
没错，在此之前，我们成立了一个这样的团队，以我们为例
进行了演示 ，在所有平台上以极短的上市时间淘汰了一项功能。
此外，该功能的选择非常好，并且在所有平台上均成功。 因此，我们有一个例子表明，
可以更快更好地完成所有工作 。 这样一来，整个130-140人的开发团队就知道您可以以不同的方式工作。
当我们确定价值流时，出现了与团队领导者打交道的问题。 以前，它们是所有方向的基础，但现在有了价值流和业务的更大影响力。 我们做了什么？ 我们将具有不同能力的人员召集到每个价值流中，每个价值流至少一个：
- iOS开发人员
- Android开发人员
- JavaScript开发人员
- 智能电视专员
- 布局设计师
- 给测试者。
事实证明这是一个独立的团队，但
在语言和敏捷教练的优美幻灯片上都是
独立的 。 实际上，每个人都忘记了可以使用相同编程语言编写的人们之间仍然存在一些共同点-这是他们的程序代码，他们必须以某种方式进行交流。 由于某些原因，许多人对此保持沉默，但这确实是一个很大的问题，需要记住。
假设您将人们放在不同的楼层或房间，并且他们编写相同的代码。 有一个发布周期和功能，不应互相干扰。 有很多问题。
概念的
我们采用了几个基本概念：
我们获得了
价值流和
平台命令 。 在价值流中，这些家伙实施了一项特定功能，而在平台中，则有一个团队负责人-能力中心。 在平台内部，也可以开发一些功能，但这更多是软件开发的体系结构视图。
我们介绍了“
公会 ”的概念。 通过将相同的iOS开发人员放置在不同的房间中，我们需要给他们一个正式的信号，甚至是非正式的信号，以使他们仍然是相同的iOS开发人员，而不仅仅是广告产品价值流的参与者。 然后，在这个行会中，您需要做一些事情，并以某种方式教会人们在内部进行交流。
下一个问题是
如何处理发布周期 。 在可以随时使用该功能的平台上，没有任何问题。 对于iOS或Android，由于收到苹果公司批准的细节，不可能每天发送两次该应用以进行发布，因此有必要累积一些包装。
我们决定将每个不能立即发布的平台
每两周发布
一次 。 他们为每个人提供了一个特殊的日历，团队在其中发布
功能冻结日期和发布日期。 如果在价值流中，您希望真正的用户可以使用任务，则应该及时冻结功能。 有时间-好吧，没有时间-您正在等待下一趟火车。
新方案中的蒂姆利德
Timlids发生了什么事？ 他们经历了经典的认识到无法解决的问题的计划。
起初，我们遇到了一个
否认 。 因为团队负责人已经组建了一支很酷的团队多年，因此培养了每位员工，并吸引了竞争对手的人。 现在，这些专家已被分配从事并非总是能达到他们期望的工作。
当然，在否认之后，人们会
生气 。
有很多丑闻，之后开始
讨价还价 。 每个人都提出一个问题：“让每个人都有自己的方式，但是我会像以前一样使用，但是我要用记号笔在家里写上“敏捷”，我会穿上这条铭文的T恤，但一切都会像以前一样。” 无法解决。
但是最后，我真正期望的事情发生了-人们明白了我们为什么这样做。 我希望他们能理解，尽管也许他们撒谎了。 第一个成功的案例显示了以前的情况与如何以不同的方式进行处理之间存在着显着的差异。 一半的上市时间使我们能够为每个人设定基准。 下一步发生了，在古典心理学模型中，这被称为
斯德哥尔摩综合症 。 采纳新规则的人们学会了存在于其中，并开始慢慢传播这种“宗教”。 我不能说所有的蒂姆利德犬，但现在大约有30％的人是这个方向上的活跃“同志”。
问题与困难
现在，我将尝试从结构上更详细地列出我们遇到的困难：
由于员工坐在不同的办公室，导致口头交流丢失。
一个月的时间变得非常困难 ，因为在可以快速询问邻居之前，例如，您需要继承什么，然后获得答案。 现在您坐在单独的房间里，周围的人可能不喜欢您的技术，没有人可以咨询。 要问某人一个问题，您需要在聊天中写信，而可以回答的人不见了-如此，您将留在自己的设备上。
我们立即开始
对Code Review遇到问题 ，我认为这不是问题，而是一个重大发现。 我们发现
大量员工不是独立的 。 假设有一位员工，根据统计数据，第二次（通常是第一次一切都很好）复习问题通过了最大值。 当他离开工作时，由于某种原因，它变成了5-6次迭代。
他们开始理解，事实证明，控制，集中相对于他本人的所有信息流的团队领导者标志性人物的权威性意见并没有很好地影响开发人员的发展。
人们很懒惰 ，他们在所有问题上都寻求帮助并得到有力的答复。 因此，审核既快又酷。
为了独自
做出决定 ，许多开发人员必须独自
超越自身，才能做出同样的架构决策 。 没有人喜欢连续五次听到您的代码不是很好。 这很令人沮丧，它使您认为自己不是合格的员工，甚至可能导致沮丧或信念，即工作可能很糟糕。 但是关键是您需要查看自己，以了解在以前的操作模式中您并未考虑这些事情，但是现在您正在
开发并应该开始考虑它们 。
另一方面，在我看来，我们有一些非常有趣的事情对于代码审查来说是多余的。 其中一个团队有一条规则：为了使任务通过审核，所有团队成员都必须做出决定。 当他们都坐在一起时，他们或多或少都取得了成功，现在他们都坐下来了-有些人一次要举行每日站立会议，其他人要有其他事务-审查任务成为一个狭窄的瓶颈。 回顾一遍又一遍，他们了解到有些任务正在等待审查两个星期，并且被迫更改某些内容。
然后开始：
分离主义，歧视和嫉妒 。
以前，一个人以为他知道自己想做什么。 随着价值流和平台的分离，人们开始怀疑“邻居的口味更好”：任务更加有趣，增长更快。 第二个问题是，当一切都
以功能为中心时 ，
代码的
质量将大大
下降 。 您周围的人是想要快速获得结果的人们，并不是要以任何方式对其进行支持和现代化都应该是他们的任务，并且在新功能的帮助下，同事们应该没有遇到任何问题。
出现了这样的情况，即高开发速度具有相反的一面-
劣质代码 ，这种
代码开始大量增加。 当负责的团队负责人纠正这些错误并进行重构时，事实证明，他的生活变成了疏忽大意的雇员的垃圾。 开发人员很快就能得到所有东西，每个人都很高兴，而且他们没有注意到团队领导的艰巨工作，因此，事实上，一切都可以正常进行。 大约两个月后，每个团队负责人均对当前情况表示不满。
为了解决这些问题，我们首先与蒂姆利德犬（Timlids）举行了几次会议，然后与所有行会举行了几次会议，目的是向人们解释不同的工作是可能的。 如果您想尝试其他方法，则需要带领团队前进，并且可以轻松切换位置。 最主要的是要彼此同意。
灵活的方法论的强项是，每个人的事情如何发生都无关紧要，主要是人们同意并感到满意。
这是一方面。 另一方面，为了使谁参与重构以及谁在进行新功能方面具有公义性，团队负责人开始处理积压工作，我稍后再讲。
然后，
困难开始
于发布管理 。 价值流中有测试人员，平台中有测试人员，有些是自动化的，有些不是自动化的，您需要考虑如何进行一般回归。 还有条款。 我们自愿决定每两周释放一次，如果一个伴侣提出要求在明天之前做所有事情的请求（例如一袋钱），告诉他等待下一个周期怎么办？ 尽管如此，仍
必须寻求折衷方案 。 然后，发布的漂亮方案可能会发生很大变化。
一个很好的例子是FZ-54法律，根据该法律，在互联网上进行的所有购买都必须伴随向用户发送电子支票和税收。 您可以在会议上随意发言，也可以讨论灵活的方法论以及有哪些法规等内容，但是一旦有可能受到罚款的70％的罚款，您便会转向完全不同的机制，并确保不对公司罚款。 这种情况很少见，但确实有。 特别是，如果方案发生变化，我们必须进行第二级沟通。 这不容易，但是可能。
转型带来的下一个问题与
新员工有关 。 我认为，初学者应该沉浸在尽可能接近他所要工作的环境中。 在那里，由于环境的原因，他将迅速获得必要的知识。 但是我们将组成这种环境的专家拖到不同的楼层和房间中。 公司初学者的生活成为一项相当严肃的管理任务，必须考虑解决方案。
工具
这是我们使用的工具。
我将从新员工的
路线图开始故事。 不幸的是，这是我们尚未学会如何实现完全自动化的东西，实际上，根据每个员工的工作情况，分别考虑每个员工的想法。
有一个相当有趣的例子：我们需要发展一个
通用测试仪 ，该
测试仪能够测试广告流中的所有产品。 它们有很多共同点，但也有自己的特点。 精通测试Web应用程序的测试人员在使用工具（例如iOS）时会第一次迷失，这已不是什么秘密。 我们的质量控制总监为该测试人员绘制了特殊的路线图。 在这张卡上，每个能力的新员工都获得了两周的知识，参与了回归等等。 对于开发人员，实施情况大致相同。 因此，即使在面试中，我们也会发现念珠菌的吸引力和兴趣，并尝试选择发送他的方向。
当然，就我们而言，新员工第一次具有竞争力，即在平台团队中，然后已经可以迁移到我们所需的价值流中。 顺便说一句，路线图是好的，但也不必排除其适应性。
然后介绍了
公会同步-公会动作的同步 。
为什么需要这个？ 每个人都听了有关Scrum的演讲，其中谈到了每天举行站立会议的必要性，以便让您知道周围发生了什么。 但是，例如，我们的专家一方面是一名Android开发人员，另一方面是产品团队的成员。 如果他每天必须走路和交流两次，那么他将受到某种货运崇拜。 以这种速度，您可以将整个一生都花在开会上。 肯定会惹恼人们。
如果我们说我们基于以功能为中心的模型，那么每日站立会议在其价值流中更为重要。 但是同时，您可以摆脱行会中正在发生的事情。 为此，一些公会每周组织一次会议，有些公会每周两次。 在这里，团队负责人有条不紊地思考什么值得谈论。 这不应该转化为空话，它是技术团队的发展策略，这就是行会。 需要召开Guild Sync会议，以便每个人都了解公司将使用什么技术，关于该平台的战略决策。 在此基础上，对体系结构解决方案进行了部分审查。
在某些团队中，我们有多个团队领导。 通常，团队领导的定义非常模糊。 有些
意见领袖可以成为团队领袖，并负责解决某些组织问题。 一个团队中可以有几个具有管理技能的意见领袖。 然后他们可以组织自己，由谁负责。 例如，一位意见领袖可能会进入价值流。 在这种情况下，您需要同步您的架构决策，这将在将来决定整个技术平台的开发策略。
然后，我们开始在某些区域进行
内部和外部mitaps 。 通常，这是一个相当标准的部分人力资源案例，部分是团队建设案例。 对于内部会议，有时会就最有趣的主题进行投票，或者在公司内部寻找发言人，或者我们从外部邀请一个人，租一个特别的房间并讨论各个要点。 平均而言，我们每个月有两个内部mitap，但有时四个。 来自其他领域的人们可以来到这些混血儿，听听邻居的生活，看看他们是否想改变自己的专业。 这也会发生。
现在，在劳动力市场上有关开发商的事情上，一切都不是那么简单。 , , . , ,
, . , , .
. , , Agile- , Guild Sync .
, , , . , , Guild Sync , .
, , , ,
, . 10 .
—
. , , -. - , , , . - , , , . , - . , , , , , - .
. , . , , , , . , , , . , - , , , , , .. .
, « ». , , .
Guild , . - , , .
, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).
— , .
Teamlead —
, , -
.
,
. , , , , , , — .
, , , « ». , , , . , , , , value stream. , , .
, , .
24 25 . - Saint TeamLead Conf .
, 40 , — 10 .