Best practices check list

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

После того, как некое улучшение было выбрано, опробовано и одобрено командой, мы «обкатываем» его ещё пару-тройку спринтов. После этого, если это улучшение нам действительно помогает и нравится, то мы переводим его в разряд best practices и переносим в отдельный список в Confluence проекта, который называется «Что  прижилось и работает (продолжаем использовать)» =)

Т.к. best practices не являются священными и неприкосновенными, мы на каждой ретроспективе пробегаем по этому списку и:

1. Проверяем, что мы не забыли следовать практикам из этого чек-листа, а если забыли, то анализируем почему.
2. Обсуждаем (быстро-быстро), действительно ли каждая практика из этого списка всё ещё является «best» и если нет, то убираем её из этого списка.

Таким образом мы следуем принципам кайдзен, который, вообще говоря, «косо смотрит» на best practices в привычном их понимании.

Небольшой пример того, что у нас может попасть в список «Что  прижилось и работает (продолжаем использовать)»:

• Ограничить количество задач, которые могут находиться в состоянии WIP (N-1) - вынужденное парное программирование, нацеленность на скорейший резуьтат. Если фича в тестировании и найдена ошибка - переходит обратно в процесс, одна фича из процесса уходит (прокачиваем: уменьшение времени, необходимого для подготовки фичи к приёмки заказчиком на стейдже, коллективное владение кодом, кросфункциональность команды).
  
• Деплой не может начаться позднее 15:00. Т.е. если заказчик требует внести изменения после 15:00 или до 15:00 не даёт отмашку на деплой - выкат переносится на следующий день. Это согласовано с заказчиком. Мы, в свою очередь, уведомляем заказчика о реализованных фичах сразу после их исполнения.
  
• Дважды в неделю проводим технический standup meeting на котором каждый рассказывает про то, как именно он реализовал, реализует и собирается реализовать тот или иной функционал (архитектура, подход и т.д.). Командное ревью архитектуры и кода. Длительность не более получаса. Привлекаем разработчиков и архитекторов из других команд. Заранее планируем, чтобы люди приходили (прокачиваем: качество кода, коллективное владение кодом, кросфункциональность команды).
  
• Деплойментом занимается каждый член команды по очереди и в паре с кем-то (прокачиваем: кросфункциональность команды).

Бэклог улучшений

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

А что делать с теми улучшениями, которые набрали меньше голосов, но при этом являются так же важными и интересными? Мы стали их записывать в отдельный список в Confluence проекта. К этому списку имеет доступ вся команда (да и вся компания) и в любое время дня и ночи любой член команды может дополнить данный список любым своим предложением.

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

В чём плюс такого подхода. Людям не приходится на ретроспективе напрягаться и вспоминать, что именно им пришло в голову два дня назад во время коммита или когда упал автобилд. Как только кому-то приходит интересная идея – они заносят её в список улучшений и вспоминают о ней на ближайшей ретроспективе.

Небольшой пример того, что у нас находится в бэклоге:

• В дополнению к фокус-фактору и качеству кода добавить ещё один показатель для оценки процессов - субъективную удовлетворенность работой команды.
• Составлять план демо самостоятельно во время работы над спринтом каждым участником комманды.
• Тренировка действия в случаях крит. ситуаций на проде.
• Составить RoadMap по рефакторинга всего кода и выделению модулей из продукта.
• Расшарить знания по JS - вернуть уроки по JS.