<...> причина, почему все эти скрам-атрибуты теоретически могут появиться в командах, — это если сами команды нуждались в этом и ввели все осознанно. Но это какая-то фантастика, такого не бывает.
– Из статьи «Я убрал оценки задач, спринты, планирование и ретроспективы — и ничего не сломалось»
Или все-таки бывает?
Привет, меня зовут Рома. Я разработчик и последние 4 года я руковожу командами разработки в бигтехе и в пет-проектах. Сегодня я хочу рассказать, как в моих командах появляются атрибуты Agile-методологий и почему часть из них я считаю необходимыми.
Кто такой тимлид
Начать я предлагаю с вопроса: «А чем вообще тимлиды занимаются?» Обычно, под руководителями команды подразумевают менеджера, который ближе всего к команде исполнителей. Это последний менеджер в цепочке других менеджеров с которого можно спросить за выполнение задач. Выполнение обычно измеряется в каких-то понятных метриках: сделано/не сделано или показатель достиг значения Х. И важно, чтобы на эту метрику команда влияла напрямую, а эта метрика влияла на бизнес-показатели компании.
Зачастую, эти метрики ставятся тимлидом вместе с его руководителем и являются выполнимыми. Они представляют собой некоторый «компромисс» между тем, что приходит «сверху» и возможностями команды. Цель тимлида – так организовать команду, чтобы она выполняла поставленные задачи и делала это в срок на протяжении долгого времени.
И вот тут уже появляются все основные задачи тимлида: запланировать работу, оценить сроки, распределить задачи, мотивировать сотрудников и так далее.
Что такое Agile
Это набор практик в помощь руководителю, который помогает структурировать процесс разработки продукта. И вариаций этих практик, на самом деле, намного больше, чем Scrum и Kanban. Во всех них есть итеративность и инкрементальная разработка, за счет которых достигается гибкость процессов и продукта, ориентация на ценность для клиента и вещи вроде самоорганизации команд и непрерывной обратной связи.
Тут просто список ценностей и принципов из Agile манифеста
4 ключевые ценности Agile-манифеста:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
12 принципов Agile-манифеста
Удовлетворение клиента за счет ранней и бесперебойной поставки ценного ПО.
Приветствие изменений требований, даже на поздних стадиях разработки.
Частая поставка работающего продукта (раз в пару недель или месяцев).
Совместная работа: представители бизнеса и разработчики работают вместе ежедневно.
Мотивированные профессионалы: создание условий, доверие и поддержка.
Личное общение — самый эффективный способ обмена информацией.
Работающий продукт — основной показатель прогресса.
Устойчивый темп: возможность поддерживать постоянный ритм бесконечно.
Техническое совершенство и качественное проектирование повышают гибкость.
Простота — искусство минимизации лишней работы.
Самоорганизующиеся команды создают лучшие требования и архитектуру.
Регулярная рефлексия: команда систематически анализирует способы улучшения эффективности.
Эти ценности и принципы в настоящее время на 90+% выстраивают работу тимлида во всех крупных компаниях, потому что они затрагивают все задачи руководителя и помогают ему достичь его и командных целей.
Из набора принципов к эффективной работе
В Scrum «события» – планирования, дейли стендапы, ревью и ретро – появились из Agile манифеста довольно очевидным образом. Но что, если начать работать без этих ритуалов?
В прошлом году мы начали работать над «стартапом» и на его примере я и буду рассказывать. Стартап тут хорошо подходит как пример эффективного использования потому, что тут изначально никто не заставлял использовать все эти методологии. И это был мой эксперимент, когда я изначально не принес ни одного ритуала.
Когда нас было трое, все шло отлично и синхронизацию после первого обмена идеями мы успешно проводили в чатике: мотивированные скорым успехом, мы писали код, делились им и синхронизировали бэкэнд с фронтендом.
Но в какой-то момент идей и задач стало больше, чем рук, команда начала расти, чат в телеграмме превратился в суперчат с топиками. Чтобы понимать, кто над чем работает и когда что будет готово в команде из 6 человек появились таск-трекер, недельные спринты и еженедельные планерки, на которых мы за 30 минут делимся результатами, разбиваем задачи на подзадачи и оцениваем их сроки.
Таск-трекер оказался скорее моим инструментом для понимания прогресса и долгосрочного планирования, а планерка – инструментом, который появился по просьбе команды: чат перестал справляться, и людям стало важно видеть общую картину работы.
Больше встреч богу встреч!
Со временем добавились и другие практики. Ретроспективы мы начали проводить, когда заметили, что дедлайны стали постоянно сдвигаться, а разработчики часто ждали друг друга. Конкретно, когда бесконечное количество правок от фронтенда к бэкэнду остановили обе команды. Ретро помогли не только выявлять узкие места в процессах, но и выстраивать понятные договоренности внутри команды. В итоге они у нас раз в пару месяцев.
При этом у нас не прижился формат ревью или демонстраций. Я несколько раз предлагал устроить мероприятие, где бы каждый рассказал о своих наработках, идеях и принципах в основе существующих компонентов. Мне кажется, это было бы полезно для общей синхронизации команд и передачи опыта, но, видимо, пока запроса на это нет.
Появились и регулярные встречи 1-1. Они не часть каких-либо популярных Agile методологий (хотя по принципам очень даже подходят), но оказались полезными для мотивации и развития команды. Для нас, работающих над стартапом без финансирования, ради идеи, такие разговоры стали инструментом поддержки вовлеченности и личного роста.
Вообще 1-1 – это самые важные встречи, которые, я считаю, должен проводить руководитель в любой команде. Они могут заменить почти все остальные встречи (правда, увеличив нагрузку на самого себя). На них вы, как руководитель, занимаетесь мотивацией сотрудника, тут же вы создаете доверительные отношения, находите скрытые и личные проблемы. На этих же встречах вы индивидуально развиваете своих сотрудников.
Как не превратить хорошую идею в каторгу
Agile-методологии – это не набор галочек для менеджера, а список идей, которые должны делать команду и ее работу лучше. Дейли – не отчёт перед менеджером, а инструмент для синхронизации команды. Ретро – не просто обсуждение проблем, а поиск улучшений.
Если что-то из Scrum-ритуалов кажется ненужным, то:
либо они сейчас не нужны и их можно сделать реже или вообще отменить (но не бояться вернуть их через время);
либо они перестали работать в вашей команде (например, часто бывает, что после ретро руководитель ничего не делает с выявленными проблемами) и надо их реанимировать;
либо нужно напомнить словами, зачем проводится то или иное мероприятие и как оно повлияет на дальнейшую работу.
Любая гибкая методология – это не только про гибкость процессов разработки перед заказчиками, но и про гибкость самих Agile-подходов перед командой и ее потребностями.
____
Про развитие в People и Tech менеджменте и предпринимательстве я каждую неделю пишу в своем Telegram канале @DyPositary, подписывайтесь!
