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.

Презентация тест плана в начале каждой итерации

Давно используем одну интересную практику в наших проектах – на следующий день после планирования очередной итерации тестировщик презентует всей команде тест-план на данную итерацию.

Презентация проходит следующим образом. У тестеровщика в TestLink на каждую итерацию (версию) имеется свой набор тестовых сценариев. При этом каждая история из бэклога (если это SCRUM-команда) или каждый вариант использования из спецификации должен быть покрыт тестовым сценарием. Тестировщик рассказывает команде, как именно он собирается тестировать тот или иной вариант использования, перебирая по очереди все тестовые сценарии. При этом у команды возникает масса пожеланий на расширение тестовых сценариев, оговорок, а так же уточнений по функционалу. По результатам такого ревью тестировщик обновляет тестовые сценарии, а аналитик, если требуется, корректирует спецификацию.

Данная практика способствует тому, что вся команда (и product owner, если он присутствует) одинаково понимает, что именно будет сделано и в чём суть каждой задачи. Так же снижаются риски связанные с поздним тестированием.

Метрики – качество оценки

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

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

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