Какпривестипопугаевкобщемузнаменателю?
Хочу разобрать вопрос, который мне часто задают многие мои клиенты и участники тренингов, которые работают над одним продуктом несколькими командами. Вопрос звучит так: “Как нам синхронизировать единицы оценки между командами?” или в простонародье “Как привести попугаев к общему знаменателю?”. Дано: один продакт оунер, один продукт, один бэклог, несколько команд работающих над этим продуктом из общего бэклога (далее по тексту рассмотрим пример с тремя командами). В ситуации, когда команды только-только начинают работать вместе, возникает следующая дилемма. Если команды пользовались для оценок некими условными единицами измерения скорости разработки (стори поинтами, попугаями, сырными тортиками и тп) ясно, что эти единицы измерения нельзя просто взять и начать записывать в один бэклог. Это очевидно, если команды имели разные названия единиц (одна меряла попугаями, а другая сырными тортиками и ясно что сырный тортик не равен одному попугаю), и не так очевидно, если название единиц было одинаковым (например стори поинты).
На тренингах и в книжках про аджайл нас часто об этом предупреждают, что когда несколько команд работают вместе, то стори поинты одной не равны стори поинтам другой, и то, что одна команда делает 15 таких единиц за один спринт, а другая 25, никак не отражает реальной скорости сравниваемых команд.
Что же нам делать в данной ситуации? Очень хочется, чтобы единицы оценок, которыми оперируют наши команды, были одинаковыми. Это не так сложно сделать, все что нам потребуется, это один воркшоп и один день из жизни всех команд.
Архив стори поинтов.
Всем командам дается домашнее задание, принести с собой “Архив стори поинтов”. Это просто коллекция ранее выполненных пользовательских историй с их оценками. Достаточно выбрать по две истории каждого размера 1,2,3,5 и 8 стори поинтов. Итого архив содержит 10 пользовательских историй с их оценками.
Критерии выборки:
- история проста и понятна всем представителям команды
- все члены команды считают, что история имела верную оценку после планирования спринта, в котором она была выполнена и не содержала никаких сюрпризов
Истории из архива можно распечатать или написать на листах формата A5. Вообще иметь подобный архив стори поинтов в заламинированном виде, очень хорошая практика. Подобный архив можно принести с собой на Планирование спринта, повесить архив на стене, после того как команда произвела оценку очередной пользовательской истории при помощи покера планирования, или любым другим способом, которым ваша команда делает оценки, новую историю можно приложить к историями из архива и задаться вопросом, похожа ли эта история на истории такого же размера из нашего архива.
Рабочая сессия по синхронизации
Итак, имеем 3 команды (для простоты дадим им цветовые имена: голубые, зеленые и коричневые), которые принесли с собой по архиву стори поинтов. Все архивы вешаются на стенку друг рядом с другом и на стене получается примерно так как на картинке слева вверху, только истории каждого цвета висит по две. Понятно, что истории на 5 стори поинтов от зеленой команды, это не то же самое, что истории по 5 стори поинтов от коричневой команды и кроме цифр их ничего не объединяет.
Пришло время разбиться на маленькие временные рецензионные группы по 4-6 человек. Рецензионная группа (РГ) формируется по простым правилам, в ней должны быть представители каждой из команд (голубой, зеленой и коричневой), так чтобы в каждой рецензионной группе был бы человек, который мог бы дать комментарии по той или иной истории и объяснить о чем она.
Теперь рецензионные группы отправляются в путешествие вдоль стены, совместно обсуждая внутри РГ те истории, что висят на стене и сдвигая похожие по размеру истории, вверх или вниз, так, чтобы истории подобного размера получились на одном уровне по горизонтали. Любая РГ может передвинуть любые истории на стене.
Через некоторое время движение на стене прекратится, и там получится картинка наподобие той, что справа. Из которой становится видно, что то, что называлось у голубой команды 2 стори поинта, это примерно соответствует 1 стори поинту в зеленой, что тоже примерно равно 3 стори поинтам коричневой.
Теперь командам предстоит договориться, какие единицы измерения они примут за общие, выбрать этим новым единицам какое-нибудь новое общее название (если до этого это были груши, яблоки и апельсины, то можно совместно перейти на попугаи). И по прежнему работая в рецензионных группах, попробовать выбрать пользовательские истории, являющиеся типичными представителями новых единиц измерения, которые отныне будут служить архивом попугаем для наших команд (голубой, зеленой и коричневой).
Теперь у команд появилась новая общая единица измерения скорости, и они готовы начать работу над одним продуктом и делать оценки в общих попугаях.
Условия задачи
Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.Что происходит
Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
- возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
- стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
- рабочий процесс перестаёт быть прозрачным.
Решение
Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:- объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
- помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
- научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
- помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
- визуализировать поток работы. Прозрачность — залог успеха;
- устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
- объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Итоги
Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:- декомпозиция работы на небольшие PBI;
- визуализация потока работы в Спринте и поиск основных узких мест;
- устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
- планомерная ликвидация технического долга.