Как мы починили свой процесс и стали меньше отвлекаться

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

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

1. Дежурный разработчик

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

Каждый день один из нас заступает на дежурство. Приоритетная и эксклюзивная задача дежурного разработчика — работа с обращениями службы поддержки. Нормально, если из-за наплыва заявок дежурный не написал ни строчки кода, но не комильфо, если оставил новые заявки на следующий день (они достанутся его коллеге).

Для простоты атрибуты власти дежурного (см. картинку) передаются каждый день по часовой стрелке следующему разработчику (никаких графиков дежурств).

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

2. Единая точка входа в команду

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

Это простое, даже капитанское правило защищает команду от гиперактивных менеджеров по работе с клиентами, желающих срезать углы и решить свой вопрос «по-быстрому», а заодно прокачивает продукт-оунера и службу поддержки.

3. Фиксированные дни для обсуждений

Любые обсуждения, в которых участвует команда, проводятся строго в отведенные дни недели (вторник и четверг в нашем случае). На эти же дни назначены регулярные обсуждения/оценка (груминг) новых фич с продукт-оунером, а также планирование следующего спринта.

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

4. Обсуждение — задача с оценкой

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

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

5. Резервы продукт-оунера

Мы используем Scrum с двухнедельными итерациями. Это означает, что с начала спринта список задач в нем фиксирован и в штатном случае не должен меняться.

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

Резерв выглядит как задача без описания, но с оценкой в story points. Количество резерва определяется продукт-оунером с учетом потенциальных потребностей. Его может не быть совсем, если в спринте не осталось места. Максимальное количество резерва ограничено, в нашем случае это три задачи с разной оценкой:

• XS (~3 идеальных человеко-часа) — 2 задачи
• S (~6 идеальных человеко-часов) — 1 задача

Неиспользованный продукт-оунером резерв за день до демонстрации превращается в тыкву сгорает. Этим гарантируется, что востребованный резерв можно успеть реализовать и включить в релиз. Команда использует сгоревший резерв на техническую задачу по своему усмотрению, либо удаляет его из спринта (в последнем случае story points не начисляются).

6. Done-консилиум

Раньше у нас были сложности с определением завершенности задачи (Definition of Done), особенно с пунктом «Вся команда согласна, что задача выполнена».

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

Done-консилиум гарантирует, что вся команда довольна итоговым решением задачи.

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

7. Передача кода

Когда Done-консилиум закончился, а автор внес необходимые правки, задача переходит другому разработчику. Он проводит code review и самостоятельно устраняет найденные замечания или проводит рефакторинг.

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

Автор: Роман Аверков

Источник ^[1]