Хабрахабр

Agile — это не процесс разработки, а подход к созданию продукта

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

Как рождается идея перехода к эджайлу

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

А следом, возможно, и кончину компании. Чтобы закрепить мысли об эджайле, приглашают экспертов, которые прогнозируют пару-тройку сотен дней работы над продуктом, и, как следствие, «протухание» продукта, его кончину. Как не повторить их судьбу? В пример приводят HTC и Blackberry. Консультанты предлагают рецепт, которым воспользовались такие гиганты как Google, Amazon, Apple, — а именно гибкий эджайл.

Что обычно происходит при трансформации

И вот вы узнали все необходимые словечки и фразочки, чтобы иметь право носить гордое имя PMI Agile Certified Practitioner: «стендап, груминг, демо, команда, доска, стикеры, шли все лесом со своими согласованиями». Вы профессионалы своего дела, знаете, что и как работает, знаете все новые необходимые понятия, мероприятия и процессы. Осталось провести agile-трансформацию. Приведем список типичных ошибок.

  • Были отделы разработки, а сделали эджайл-команды.
  • Бесконечную очередь задач по запросам на изменение в Jira легким движением руки превратили в бэклог из RFC.
  • Если раньше на задачу централизованно выделялись ресурсы, то сейчас сделали распределение задач на разработчиков.
  • «Чем будет заниматься у нас этот разработчик? А давайте возьмем в бэклог вот эту задачу, он сможет ей заняться»
  • Вы поставили цель уйти от оценки задач в один месяц работы. В ответ разработчик говорит: «Окей, начнем делать в этом спринте, а в следующем закончим».
  • Задача не согласована со службой безопасности и юристами? Давайте введем нормативные каникулы и проигнорируем этот момент.
  • Задачи распределяет начальник? Тогда сделаем эджайл, плоскую структуру, но «я все равно буду начальник».

Что получаем в итоге?

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

Документации нет! Что делать — непонятно, как делать — непонятно. Они смотрят на сотрудников в команде словно пришли в зоопарк понаблюдать за поведением гиббонов в стае.
Скрам-мастер рассказывает про Definition of Ready и Definition of Done. Вся команда все время сидит на совещаниях, куда приходят старые прожженные технологи и программисты. Все же понимают, что это важно и нужно, почему же разработчики сопротивляются?

В этот момент как назло прилетает важная задача с прибитыми сроками от руководства, и молодой, еще некрепко стоящий на ногах эджайл погибает под натиском врагов и зомби.

А как надо?

Нельзя слепо следовать шаблонам успешных компаний. Здесь проще пояснить через аналогию — например, через футбол. Представьте, что вы тренер, ваша команда проигрывает, пять минут до конца матча. Есть пример безупречного плана, которым пользуется известный тренер Эрнесто Вальверде. Согласно ему, нападающий Луис Альберто Суарес врывается в штрафную, его сносят, судья назначает пенальти. К мячу подходит Лионель Месси и пробивает точно в дальний от вратаря верхний угол. Безупречный план. Но вы не Вальверде, и у вас в команде нет Суареса и Месси. Все. Вы проиграли.

Кроме того, мы начинаем цепляться за процессы, забывая, зачем мы их внедряем в своей работе. Поэтому я бы советовал сформулировать цель и повесить ее на видном месте. Как ставить цели, вы все знаете. Цель должна быть конкретной, измеримой, достижимой, значимой и со сроками. Что все это значит на практике?

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

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

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

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

Все это правда, основная сложность — это найти нужного вам человека. О том, каким должен быть владелец продукта, уже много сказано и написано. Вот что делает владелец продукта:

  • ставит цель;
  • описывает верхнеуровневый бэклог;
  • продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели; в том числе не забываем про счастливого клиента;
  • рассчитывает, как задачи из бэклога влияют на KPI.

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

В команде должны быть все компетенции, которые необходимы для достижения результата. Команда разработки — это ответственные люди, которые могут самостоятельно и независимо разрабатывать продукт. Однозначно не нужно делать команду с избыточными ролями. Внешними зависимостями нужно не управлять, от них нужно избавляться включением или обучением нужных людей в команде. Мысленно уберите роль из команды, станет ли без нее хуже? Чтобы договориться, команда должна быть как можно меньше размером.

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

Теперь, когда команда есть, она должна стремиться к тому, чтобы в конце спринта был прирост «добра» продукта с понятным бизнес-профитом.

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

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

Если подобные инициативы будут рождены снизу, то их поддержат на всех уровнях. Для развития инженерных практик нужно создавать не отдел, который будет навязывать правильные вещи вроде unit-тестов, а сообщество из заинтересованных в этом разработчиков.

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

Любые поля и процессы в Jira легко заменяет физическая доска с набором магнитов. И последний совет: используйте простые инструменты.

К чему мы пришли?

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

Показать больше

Похожие публикации

Добавить комментарий

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

Кнопка «Наверх»