Как сделать планирование спринта прозрачным и эффективным
Некоторое время назад я переводила статью Майк Кона о том, как правильно взаимодействовать программистам и тестировщикам и другим участникам Agile-команды.
Однако, после прочтения статьи меня несколько раз спрашивали о том, как же этого добиться. А порой я слышу о том, что в команде должен быть тот, кто распределяет задачи иначе как же понять кто над чем работает.
В этой статье я поделюсь с вами своим лайфхаком как я провожу планирование и учу проводить Agile-команды.
Начнём с самого начала — с формирования бэклога продукта. Как вы наверняка знаете, Владелец продукта, общаясь с заинтересованными сторонами получает множество всяких хотелок, которые, проводя через свой “внутренний” фильтр, он или заносит в бэклог продукта или выкидывает или урунирует, как любит этот процесс называть одна из моих команд.
После того, как у нас есть Бэклог продукта и мы готовый запустить спринт, как вы тоже уже знаете, мы идём с вами в планирование спринта и вот тут всё самое интересное и разнообразное, в зависимости от контекста вашей команды и компании.
Если представить входную дверь, в которую входит Владелец продукта на планирование, то входит он с предварительной целью спринта и выбранными элементами бэклога продукта, которые согласуются с целью спринта. На первой части планирования именно цель спринта и выбранные элементы бэклога продукта будут обсуждаться всей Scrum-командой. Да-да, именно всей, Scrum-мастер внимательно слушает и задаёт вопросы, которые остались не заданными developer-ами в сторону Владельца продукта и повисли в воздухе. На этой же части developer-ы оценивают элементы бэклога продукта, чтобы понять вместиться ли всё в спринт, а также выровняться по пониманию объёма и сложности работ.
После того, как developer-ы поняли над чем предстоит работать, переходим к самой “вкусной” части — вторая часть планирования спринта, совместное планирование того “Как будем достигать поставленную цель?”
Глядя на выбранные на спринт элементы бэклога продукта, developer-ы решают кто над чем будет работать, после этого планируют верхнеуровнево что надо будет сделать, чтобы выбранный элемент бэклога продукта был выполнен. Допустим, надо сделать что-то на бэке, что-то на фронте и конечно же протестировать. У ряда команд анализ уже был сделан и является элементом discovery, который идёт на спринт впёред, у кого-то анализ входит в цикл delivery, тогда будет и на него расписана работа (прим. такое встречается в Enterprise крайне редко).
Затем расписанные работы размещаем на временной шкале (timeline). Здесь важно понять, что мы не расписываем всё до мелочей, а узнаём когда начнутся работы, например, на бэке и когда они планируются завершиться. Делается это для того, чтобы команда увидела есть ли что под риском, нет ли случаем waterfall, ведь частенько в спринте можно увидеть 2-х недельный водопад.
На рисунке выше представлен пример того, как команда раскидывает задачи на временной шкале. В данном примере работы QC включают в себя исправление багов и команда понимает, что будет всего 1 день, значит надо и писать качественнее, и анализировать какие баги правим в спринте, а какие — в другой раз. Также можно увидеть, что второй элемент бэклога продукта находится под риском, так как работы по нему начнутся только на след. неделе спринта. Как такое могло произойти, если работы планируют 2 бэкендера? Это вполне возможно, если кто-то вспомнит, что он уходит в отпуск или что он ждёт другого, так как не знает что и как делать. У вас вроде 2 бэкендера, но это не совсем так …
также видно, что и тестировщик может попасть под раздачу, поэтому команда, возможно, ещё раз подумает, как лучше выстроить работу, а возможно, уже на ретроспективе решит как не попадать в такие ситуации (привет, StarMap)
Также на рисунке вы можете увидеть элемент бэклога под номером 4, который будет весь спринт анализироваться — т.е. будет проводиться discovery, в т.ч. может быть и согласование макетов. Важный момент, что завершение такого элемента бэклога продукта планируется к PBR (прим. уточнение бэклога продукта) и данный элемент отражает цель следующего спринта.
Итак, вы разнесли всё на временную шкалу, обговорили все риски, поняли где надо развиваться, в т.ч. писать автотесты и etc., что же дальше? А дальше у команды при создании в User Story sub-тасков появляется отличное представление доски спринта в Jira, по которой и будет проходить Daily, потому что дейли — это синхронизация по задачам, это не статус отчёт по людям, а также подобное представление — это отличный способ настройки прозрачности работ по элементу бэклога продукта.
После второй части планирования спринта developer-ы могут сказать Владельцу продукта, что по предварительной оценке взятые обязательства будут выполнены или же, что что-то не вмещается и под риском или, наоборот, возможно, останется местечко для маленькой работы.
Выходя из двери под названием “Планирование спринта” у Владельца продукта есть понимание того, над чем будут работать developer-ы, у developer-ов, есть бэклог спринта
Бэклог спринта = цель спринта + выбранные элементы бэклога продукта на спринт (user stories & tech stories) + план по достижению цели спринта (sub-tasks).
Вот такой маленький лайфхак :) Всем эффективного планирования :)
