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