Главная » Хабрахабр » Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода

Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода

Технический директор ivi Евгений Россинский (eross) хорошо знаком участникам наших конференций по докладам о технической стороне стриминга. Но сегодня пред вами расшифровка доклада Евгения на TeamLead Conf о том, как отражается Agile-трансформация на лидерах команд.

Не так давно в ivi прошли Agile-трансформацию и получили от неё хороший профит в плане:

  • бизнеса,
  • скорости разработки,
  • time to market;
  • других интересных метрик.

Но последствия этого креативного решения довольно серьёзно ударили по лидерам команд. Доклад как раз о том, как с этим справляться, и какие применять инструменты.

До трансформации

Для того чтобы понять, о чём я буду говорить, надо немножко познакомиться с нашим продуктом. Затем разберём, почему у нас такой формат команд и почему мы выбрали такой путь.

Разработка в ivi идет под пять крупных платформ:

  • iOS,
  • Android,
  • Web,
  • Smart TV,
  • Windows + Xbox.

И, конечно же, бэкенд, без которого никуда. До того, как мы решили провести трансформацию, наши команды формировались по компетенциям.

Ребята, которые знают, к примеру, Swift или Objective C:

  • сидят в одном помещении;
  • получают задачи от менеджеров продукта;
  • работают над ними и производят результат.

Вроде бы все хорошо, но есть одна проблема — платформы очень серьёзно отличаются с точки зрения продукта и потребления пользователем контента.

Например, пользователи web-приложения не очень любят платить, и потребление контента осуществляется посредством рекламной модели. Это значит, что в каждой команде стал появляться свой backlog и свои приоритеты. Smart TV характеризуются тем, что на них хорошо покупают, и проявляются особенности платной модели. Фичи, которые нужны для этой платформы, естественно появляются в backlog.

Менеджеры пропускают идеи через призму своего восприятия, возможно, что-то модернизируют и вставляют в свой план работ. Получается следующая ситуация: кто-то придумал гениальную идею, как улучшить продукт; написал множество тикетов, которые попадают к менеджерам продуктов, отвечающим каждый за свою платформу. А за год, полгода или всего несколько месяцев с продуктом может произойти всё что угодно — например, случится редизайн или изменение концепции, и эту фичу уже надо выкатывать, а она совсем непохожа на все остальные платформы. Проблема здесь заключается в том, что одна фича может релизиться на всех платформах больше года, потому что «я считаю, что она для моей платформы совсем не приоритетна».

Пользователь в такой ситуации начинает путаться, потому что у него нет единого пространства, в котором он чувствует себя уверенно. В результате, через какое-то время получилось, что на разных платформах у нас абсолютно разные продукты с разными коммуникационными сообщениями и бизнес-логикой. Всё зависит от размера экрана, от того, как люди потребляют контент. К тому же очень сложно строить гипотезы, так как не всегда понятно, на какой платформе какая функциональность лучше выстрелит. А выглядело это всё примерно так:

Гениальный продуктовик приносит идею, а разработчики на разных платформах воспринимают её довольно недружественно, за исключением бекенда, которому в целом не принципиально, что писать.

Итак, поскольку в компании было достаточно компетенций относительно того, что такое гибкие методологии, мы договорились с бизнесом, что нам нужно убрать барьер между:

  • продуктом,
  • бизнесом,
  • технологиями,

продуктивно взаимодействовать, и делать одно общее дело.

После трансформации

Это вылилось в архитектуру с выделенными Value Stream, в которой каждая команда занимается конкретным бизнес-направлением.

Чтобы сформировать новую структуру мы:

  • провели несколько тренингов;
  • определили, какие для нашего бизнеса главные направления;
  • в добровольно-принудительном разбили людей на value stream;
  • приступили к внедрению.

Правда перед этим мы сделали одну такую команду, на примере которой провели показательные выступления, запилив одну фичу на всех платформах с отличным time-to-market.

Таким образом у нас был пример, который показывал, что всё можно делать быстрее и лучше. К тому же фича была выбрана очень удачно и оказалась успешной на всех платформах. Это позволило все команде разработки из 130–140 человек понять, что можно работать по-другому.

Раньше они были основой всему в своём направлении, а теперь появись value stream и большее влияние бизнеса. Когда мы определили value stream, встал вопрос, что делать с тимлидами. Мы в каждый value stream собрали людей разных компетенций, как минимум по одному: Что мы сделали?

  • iOS-разработчику,
  • Android-разработчику,
  • JavaScript-разработчику,
  • специалисту по Smart TV,
  • верстальщику,
  • тестировщику.

Получилась как бы независимая команда, но независимая она на словах и на красивых слайдах Agile-коучей. На деле все забывают про то, что остаётся что-то общее между людьми, умеющими писать на одном языке программирования, — это их программный код, посредством которого они должны каким-то образом общаться. Об этом почему-то многие умалчивают, но это действительно довольно большая проблема, о которой нужно помнить.

Есть релизный цикл и фичи, которые не должны мешать друг другу. Допустим, вы рассадили людей по разным этажам или комнатам, а код-то они пишут один и тот же. Возникает множество проблем.

Концепции

Мы приняли несколько базовых концепций:

В value stream ребята реализуют конкретную фичу, а в платформах находится тимлид — центр компетенций. У нас появились команды value stream и команды платформ. Внутри платформ тоже могут разрабатывать какие-то фичи, но это больше архитектурный взгляд на разработку программного обеспечения.

Разместив тех же самых iOS-разработчиков по разным комнатам, нам нужно было дать им формальный признак и даже неформальный, что они остались теми самыми iOS-разработчиками, а не только участниками value stream рекламного продукта, например. Мы ввели понятие «Гильдии». А дальше с этой гильдией нужно что-то делать и как-то учить людей общаться внутри.

На тех платформах, где можно выкатываться по мере того, как фича готова, вопросов никаких нет. Следующий вопрос состоял в том, что делать с релизными циклами. А в случае с iOS или Android, когда в силу специфики получения approve от Apple, невозможно два раза в день отправлять приложение на релиз, приходится накапливать некоторые пачки.

Завели специальный доступный всем календарик, где команда публикует дату feature freeze и дату релиза. Мы приняли решение, что каждую платформу, которую нельзя релизить сразу же, будем релизить раз в две недели. Успел — хорошо, не успел — ждёшь следующего поезда. Если, находясь в value stream, ты хочешь, чтоб твоя задачка стала доступна реальному пользователю, ты должен успеть до feature freeze.

Тимлид в новой схеме

Что же стало у нас с тимлидами? Они прошли по классической схеме осознания проблем, которые невозможно решить.

Потому что тимлид несколько лет собирал классную команду, каждого сотрудника взращивал, кого-то переманил у конкурентов. Сначала мы натолкнулись на отрицание. И этих специалистов теперь распределили на работы, которые не всегда соответствуют их ожиданиям.

Конечно, после отрицания был гнев.

Каждый приходил с вопросом: «Давайте у всех будет по-вашему, а у меня — как раньше, но я возьму маркер, напишу у себя „Agile“, буду ходить в футболке с этой надписью, но всё будет по-старому». Было много скандалов, после которых начался торг. Не получилось.

Я надеюсь, что поняли, хотя может, они и соврали. Но в итоге случилось то, чего я очень ждал, — люди поняли, для чего мы это делаем. Вдвое уменьшенный time-to-market позволил определить ориентир для всех. Тот самый первый успешный кейс показал действительное разительное отличие того, что было раньше, от того, как можно делать по-другому. Люди, принявшие новые правила, научились в них существовать и начали потихоньку пропагандировать эту «религию». Произошёл следующий шаг, который в классической модели психологии называется «стокгольмский синдром». Не могу сказать за всех тимлидов, но примерно 30% из них сейчас являются активными «проповедниками» этого направления.

Проблемы и трудности

Теперь постараюсь более структурно перечислить сложности, с которыми мы столкнулись:

На месяц стало очень тяжело, потому что раньше была возможность быстренько спросить соседа, например, от чего нужно наследоваться, и тут же получить ответ. Из-за того, что сотрудников рассадили в разные кабинеты, пропало вербальное общение. Чтобы задать кому-то вопрос, нужно написать в чате, а человек, который может ответить, ушёл — всё, ты предоставлен сам себе. А теперь ты сидишь в отдельный комнате, вокруг тебя люди, технологии которых тебе могут не нравиться, и посоветоваться не с кем.

Мы выяснили, что большое количество сотрудников не являются самостоятельными. У нас тут же начались проблемы с Code Review, которые я считаю не проблемами, а большим открытием. А когда он ушёл работать в value stream, почему-то стало 5-6 итераций. Допустим, был сотрудник, у которого по статистике review задачек проходил максимум со второго раза, обычно с первого раза всё было хорошо.

Люди ленятся, по всем вопросам обращаются за помощью и получают компетентные ответы. Начали разбираться, и выяснилось, что авторитетное мнение знаковой фигуры тимлида, который контролирует, централизует относительно себя все потоки информации, не очень хорошо влияет на развитие разработчиков. Оказавшись наедине с собой, многим разработчикам пришлось довольно существенно вырасти над собой, чтобы принимать те же самые архитектурные решения. И поэтому review проходит быстро и классно. Это расстраивает, заставляет считать себя недостаточно квалифицированным сотрудником, может даже приводить к депрессии или убеждению, что, может быть, работа плохая. Никому не нравится пять раз подряд слышать, что твой код не очень хорош. Но смысл в том, что нужно посмотреть на себя, понять, что в прежнем режиме работы ты не думал об этих вещах, а теперь развиваешься и должен начать о них думать.

В одной из команд существовало правило: для того, чтобы задачка прошла review, все члены команды должны принять её решение. С другой стороны, у нас были некоторые очень интересные вещи, которые, на мой взгляд, избыточны относительно Code Review. Они раз за разом на ретроспективе узнавали, что некоторые задачи висят в review по две недели, и были вынуждены что-то менять. Когда они сидели все вместе, у них это более-менее получалось, а теперь все расселись — у одних daily stand-up meeting в одно время, у других какие-то другие дела — и review задач стало узким бутылочным горлышком.

Дальше начались: сепаратизм, дискриминация и зависть.

А с разделением на value stream и платформы стало возникать подозрение, что «у соседа вкуснее»: задачки интересней и рост быстрее. Ранее человек думал, что знает, чем он хочет заниматься. Вокруг тебя сидят люди, которые хотят быстро получить результат, и не их задача подумать о том, что его нужно будет каким-то образом поддерживать, модернизировать, да и у коллег ничего не должно сломаться от новой фичи. Вторая проблема заключается в том, что, когда все становятся фича-центрированные, очень сильно ухудшается качество кода.

Когда ответственный тимлид берётся за исправление этих ошибок и рефакторинг, получается, что его жизнь превращается в подметание мусора за нерадивыми сотрудниками. Стали возникать ситуации, в которых высокая скорость разработки имела свою обратную сторону — некачественный код, который начал плодиться в нечеловеческих количествах. Примерно через два месяца каждый тимлид высказал недовольство сложившейся ситуацией. У разработчиков всё быстро получается, все довольны, и не замечают титаническую работу тимлида, благодаря которому на самом деле все работает.

Если ты хочешь попробовать что-то другое, то с этим нужно прийти к тимлиду, и совершенно спокойно можно поменяться местами. Чтобы решить эти проблемы мы провели несколько встреч сначала с тимлидами, а потом и со всеми гильдиями для того, чтобы объяснить людям, что можно работать по-другому. Главное договориться между собой.

Сила гибких методологий в том, что всем неважно, как всё происходит, главное, чтобы люди договорились и были довольны.

Это с одной стороны. С другой стороны, чтобы была справедливость относительно того, кто занимается рефакторингом, а кто делает новые фичи, тимлиды начали работать с backlog’ами, я вернусь к этому чуть позже.

В value stream свои тестировщики, в платформах свои тестировщики, что-то автоматизировано, что-то не автоматизировано, нужно продумать, как сделать общую регрессию. А дальше начались сложности с Release Management. Мы волюнтаристски решили релизиться раз в две недели, и что же, если придет партнёр с просьбой сделать все к завтрашнему дню (и мешочком денег, например), велеть ему подождать следующего цикла? А ещё есть сроки. И тогда красивая схема с релизами может сильно измениться. Все-таки нужно искать компромисс.

Можно сколько угодно выступать на конференциях и говорить про гибкие методологии и про то, что есть регламенты и прочее, но как только возникает риск получения штрафа на 70% твоей выручки, ты переходишь в совершенно иной режим и делаешь так, чтобы твою компанию не оштрафовали. Наглядный пример — закон ФЗ-54, по которому все покупки в интернете должны сопровождаться отправкой электронных чеков пользователям и в налоговую. В частности, нам пришлось сделать второй уровень коммуникации на случай изменений в схеме. Такие случаи нечастые, но бывают. Это непросто, но возможно.

На мой взгляд, новичков нужно погружать в среду, максимально близкую к той, в которой он будет работать. Следующая проблема, с который мы столкнулись в следствие трансформации связана с новыми сотрудниками. А мы же растащили специалистов, которые составляли эту среду, по разным этажам и комнатам. А там за счёт окружения он максимально быстро получит нужные знания. Жизнь новичка в компании становится довольно серьёзной менеджерской задачей, решение которой должно быть продумано.

Инструменты

Вот, какие инструменты мы используем.

К сожалению, это то, что мы пока не научились полностью автоматизировать и, по сути, продумываем для каждого сотрудника отдельно в зависимости от того, чем он будет заниматься. Начну рассказ с маршрутной карты для нового сотрудника.

В них есть очень много общего, но имеется и своя специфика. Был довольно интересный пример: нам нужно было вырастить универсального тестировщика, который бы для рекламного стрима умел бы тестировать абсолютно все продукты. Для этого тестировщика наш директор по контролю качества выстроил специальную маршрутную карту. Не секрет, что тестировщик, который классно умеет тестировать веб-приложение, первое время будет теряться при работе с инструментарием, допустим, для iOS. С разработчиками ситуация с внедрением примерно такая же. По этой карте новый сотрудник в каждой компетенции набирался знаний по две недели, участвовал в регрессиях и прочем. Таким образом, еще на собеседовании мы выясняем, к чему тяготеет кандида и что ему интересно, и пытаемся подобрать, в какое направление его отправить.

Кстати, маршрутные карты — хорошо, но их адаптивность тоже не нужно исключать. Безусловно первое время новый сотрудник прокачивает компетенции, то есть, в наших терминах, находится в команде платформы, а потом уже может мигрировать в необходимый нам value stream.

Дальше мы ввели Guild Sync — синхронизацию действий гильдии.

Все слушали лекции по Scrum, в которых говорилось о необходимости daily stand-up meeting, позволяющем узнавать, что происходит вокруг. Зачем это нужно? Если он будет должен два раза в день ходить и общаться — получится какой-то Карго-культ. Но наш специалист, например, с одной стороны разработчик под Android, а с другой стороны — участник продуктовой команды. Однозначно, людей это будет раздражать. Такими темпами можно потратить всю жизнь на совещания.

Но при этом можно оторваться от того, что происходит в гильдии. Если мы говорим, что мы основываемся на фича-центрической модели, то daily stand-up meeting более важен в своём value stream. И тут тимлид методично продумывает, о чём стоит поговорить. Для этого какие-то гильдии устраивают совещания раз в неделю, какие-то — два раза в неделю. Встречи Guild Sync нужны, чтобы все понимали, какие технологии будет использовать компания, какие стратегические решения приняты относительно этой платформы. Это не должно переводиться в пустой разговор, это — стратегия развития технологической команды, которой является гильдия. На нём же происходит частичное review архитектурных решений.

Вообще, определение тимлида очень неоднозначно. В некоторых командах у нас не один тимлид. Лидеров мнений со скиллами менеджмента в команде может быть несколько. Есть лидеры мнений, которые могут быть тимлидами и нести на себе решение каких-то организационных вопросов. Например, один из лидеров мнений может уйти в value stream. И дальше они могут сами организоваться, кто за что отвечает. В таком случае нужно синхронизировать свои архитектурные решения, которые в дальнейшем будут определять стратегию развития всей технологической платформы.

В целом это достаточно стандартный отчасти HR кейс, отчасти кейс по тимбилдингу. Затем мы начали проводить внутренние и внешние митапы по определённым направлениям. В среднем в месяц у нас проходит два внутренних митапа, но бывает и четыре. Для внутренних митапов, иногда проводится голосование о том, какая тема интереснее всего, ищутся докладчики либо внутри компании, либо мы приглашаем кого-то со стороны, снимаем специальное помещение и обсуждаем разные важные моменты. Такое тоже бывает. На эти митапы могут приходить люди из других компетенций, чтобы послушать, как живут соседи, и посмотреть, не хотят ли они поменять свою специализацию.

А переучить хорошего, толкового парня с одного языка программирования на другой иногда бывает намного дешевле, чем взять подобного специалиста с рынка. Сейчас на рынке труда в вопросах разработчиков всё не очень просто. И внутренние митапы очень помогают, чтобы понять, а что из себя представляет это направление. Поэтому, если человек заскучал, мы приветствуем практику по переводу его в другое направление, которое ему интересно.

Я собрал небольшую статистику, на основе которой выяснилась, что при Agile-трансформации курящие люди оказались более осведомлены, а курящим и пьющим практически не нужны Guild Sync и другие совещания. Расскажу об еще одном интересном моменте.

У команд, в которых многие курят, Guild Sync нужен реже, потому что они и так всё обсуждают на перекурах. Люди, работающие вместе, не часто обсуждают общебытовые темы, так или иначе всё сводится к работе.

Правда в команде больше 10 человек такое уже не провернешь. Конечно, есть некурящие тимлиды, тогда они, например, практикуют совместные обеды, на которых все собираются вместе за одним большим столом.

Изначально самая большая проблема при всех трансформациях в том, что люди боятся спросить, а можно ли по-другому. Следующий инструмент для создания комфортной среды — это ротация. И только самые смелые и отважные идут и что-то меняют, а остальные задумываются о смене рабочего места, считая, что здесь их не ценят. Почему-то считается, что, если руководство сказало делать так, то надо делать так. Поэтому мы проводили ряд встреч и маленьких тренингов на тему того, что компании неважно, кто именно работает на том или ином месте, ей важно, чтобы и там, и там кто-то работал. Хотя они даже не сказали, что им что-то не нравится.

Есть задачи, которые очень сложно автоматизировать. А дальше мы начали применять различные мотивационные методы для привлечения исполнителей в непопулярные задачи. Этот партнёр постоянно присылает данные, много данных, которые нам нужно обрабатывать, в разном формате. Их никто не любит делать, но делать их надо, потому что это, допустим, сверка данных с одним из наших партнёров. Автоматизации такой процесс поддается плохо. Получается, что раз в месяц ты должен очень сильно расстраивать кого-то из разработчиков, потому что нужно не просто запустить скрипт, а понять, что там не так, поправить скрипт, запустить снова и т.д. И желающих сделать непопулярную задачку, стало больше, и цена вопроса невысока. В этом случае прекрасно выручают небольшие бонусы, этакая надбавка «за вредность».

Некоторые команды договорились фиксировать результаты каких-то договорённостей в общих чатах, чтобы не перегружать тикеты, регламенты и прочее. Guild Чате стал сильно востребован после того, как люди расселись.

Они стали методично им объяснять, что если те сделали 10 фич, и в определённом куске кода нужно будет что-то поменять, то это займет полгода, потому что изначально следовало бы учесть ряд особенностей. Самое интересное, наши тимлиды научились продуктивно общаться с product owner’ами в value stream. И в backlog’ах стали появляться задачи на рефакторинг и исправление своих собственных костылей. Положительным фактором является то, что product owner’ы восприняли подобные обращения нормально. Они убедились, что точно так же управляют этим процессом (не в плане менеджмента, а, скорее, в плане донесения до всех, как нужно сделать правильно). И тимлиды довольно серьёзно выдохнули, так как они поняли, что их команды остались их командами.

В моём понимании задача тимлида — это, прежде всего определение стратегии развития твоего программного продукта.

Teamlead — клей

Основной вывод, который мы для себя почерпнули, что по-хорошему провал или успех любой гениальной трансформации зависит от поверивших в неё людей.

Потому что придумать красивую картинку, с которой выступить на конференции очень легко, а сделать так, чтобы это работало, люди не разбежались и понимали, что это рабочая схема, — это непросто. Если вы затеете нечто подобное, то фокус вашего воздействия должен быть прежде всего на тимлидах.

Если раньше по всем, даже незначительным и не связанным с менеджментов или кодом, вопросам виноват был тимлид, то теперь при подобной схеме масштабирования по целому ряду вопросов к нему просто не приходят. Я, например, для себя уяснил, что после трансформации многие тимлиды избавились от большого количества «внутреннего бега». У тимлида стало меньше входящих, отвлекающих факторов, и это здорово. Тимлиду теперь не нужно отвечать на глупые вопросы, потому что их задают тому, кто разрабатывал эту фичу, к тому, кто отвечает за нужный value stream. Тимлиды стали спокойнее, у них перестали дёргаться глаза, и в целом их уверенность в себе стала выше.

Следующий слет по обмену тимлидскими премудростями назначен на 24 и 25 сентября. Встретимся в Санкт-Петербурге на Saint TeamLead Conf для обсуждения всевозможных проблем управления командой.

Программа уже начинает формироваться, в списке поданных докладов больше 40 заявок, и пока есть возможность добавить туда свою тему — Программный комитет принимает заявки до 10 августа.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Нейронные сети с нуля. Обзор курсов и статей на русском языке, бесплатно и без регистрации

На Хабре периодически появляются обзоры курсов по машинному обучению. Но такие статьи чаще добавляют в закладки, чем проходят сами курсы. Причины для этого разные: курсы на английском языке, требуют уверенного знания матана или специфичных фреймворков (либо наоборот не описаны начальные ...

Как не выстрелить себе в ногу из конечного автомата

Конечный автомат редко применяется мобильными разработчиками. Хотя большинство знает принципы работы и легко реализует его самостоятельно. В статье разберемся, какие задачи решаются конечным автоматом на примере iOS-приложений. Рассказ носит прикладной характер и посвящен практическим аспектам работы. Под катом вы найдете дополненную расшифровку выступления Александра Сычева ...