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 на котором каждый рассказывает про то, как именно он реализовал, реализует и собирается реализовать тот или иной функционал (архитектура, подход и т.д.). Командное ревью архитектуры и кода. Длительность не более получаса. Привлекаем разработчиков и архитекторов из других команд. Заранее планируем, чтобы люди приходили (прокачиваем: качество кода, коллективное владение кодом, кросфункциональность команды).
  
• Деплойментом занимается каждый член команды по очереди и в паре с кем-то (прокачиваем: кросфункциональность команды).