- разделить команду на несколько
- shift left разработчиков
- научиться планировать исходя из статистики
Продолжаем историю про команду из 15 человек.
Диагноз мы в таких случаях ставим:
• слишком много людей, выученная беспомощность, нет понимания «зачем». Но есть классные практики, которые помогут добиться результатов на горизонте двух месяцев - квартала.
- PBR в таких случаях сокращается больше чем в два раза
- Участие: с 3-4 человек до почти всех (это база когда вы делите большую команду)
- Планирование: попадание в спринт растет до ~70%
1️⃣ Разделите команду на две группы
Если вы хотите ротировать людей ходить на PBR / Planning, чтоб ограничить контекст - не надо!
Люди путаются, кто когда должен быть, контекст теряется.
Разделите группу конкретно:
- Группа А: 2 бэкенда + 1 фронт + 1 аналитик
- Группа Б: то же самое
- Скрам-мастер ходит в обе
Хитрый момент: Если боитесь «а вдруг одна группа станет круче другой из-за экспертизы?». Не надо. Просто распределяляйте задачи равномерно.
Результат: встречи станут короче, люди начнут говорить. Когда тебя 7 человек, а не 15 — у тебя больше эфирного времени. И больше ответственности(!).
2️⃣Сдвигайте разработчиков влево - но постепенно
я вообще за то, чтобы QA и аналитики скорее были ролями, контролирующими качество. А не писателями и проверяльщиками.
Нельзя сказать людям, которые никогда не работали с требованиями: «Теперь вы пишете критерии приемки». Даже если они сеньоры и вы этого от них ждете.
Сделайте по-другому:
• Месяц 1: Аналитик пишет всё сам. Команда приходит только сказать «ок» или «не ок» по критериям приёмки. Минимальное вовлечение.
• Месяц 2: Аналитик пишет черновик. Команда дополняет: «А что если пользователь сделает вот так?», «А этот кейс учли?»
• Месяц 3: Команда накидывает вопросы на старте. Аналитик оформляет. Приносит обратно — команда валидирует.
Хитрый момент: Главное правило — не допустить ситуации «товарищ-аналитик, всё не то, иди переделывай». Это его/её прибьёт. И поломает процесс.
Если команда только критикует и не предлагает — откатываемся на шаг назад. Сначала учимся дополнять, потом — предлагать.
3️⃣ Научитесь пользоваться статистикой (но не всем понравится)
«У нас нет нормальной статистики, мы не можем планировать».
Спрашиваю: «Сколько задач закрываете за спринт?»
— «Ну... 8-12 обычно».
Вот тебе и статистика.
А надо так: сильно упрощённо смотрим: за последние 6-8 спринтов закрывали по в среднем* 10 задач.
Значит, берём 10. Если задачи крупнее обычного — берём меньше.
Хитрый момент: «Но задачи же разного размера!»
Да. И пропускная способность это учитывает. Если у вас стабильно закрывается 10 задач разного размера — значит, в среднем* у вас получается 10 задач разного размера. Всё.
Пропуская способность — это факт. Он уже включает больничные, отпуска, тупняки, неожиданные баги.
*Лучше смотреть на 50 и 85 процентили, но давайте пока не усложнять.
❓А у вас эти приёмы как работают? :)