2018-01-24: О целях спринта
Материал из MaksWiki
Коллеги, здравствуйте! Я начинающий agile-коуч. Столкнулся с такой проблемой: команды программистов работают по Scrum над непрерывным совершенствованием уже работающего, пользующегося популярностью продукта. Scrum стали применять недавно, месяца 3-4. Задачи на спринт накидывают овнеры команд. Они разноплановые, решают очень разные проблемы функционирования продукта. Как определять цель спринта в такой ситуации? Может ли быть несколько целей? Насколько важно в такой ситуации вообще формулировать бизнес- или потребительские цели? Не достаточно ли того, что сформулированы юзер-сториз задач?
Я привожу свой ответ, а в посте идет активное обсуждение этой интересной темы.
Смотри, тут надо понимать насколько в этом продукте целесообразен релизный цикл, пакетирование новых фич, которые совершенствуют продукт, в релизы, выпускаемые каждый спринт. И насколько вообще релизный цикл связан со спринтами - потому что когда Scrum появился, 2-недельный релизный цикл был крутым, а теперь появились практики continious delivery, которые делают выпуск релизов непрерывным.
Может быть несколько разных вариантов, часть из них я перечислю.
- Развитие продукта - просто непрерывное добавление фич, которые поступают от пользователей, и Product Owner просто осуществляет арбитраж интересов стейкхолдеров. В этом смысле деление на релизы и, соответственно, итерации Scrum может быть техническим приемом, которые не имеет особого смысла. Это не значит, что надо отказываться от Scrum и переходить к Kanban или композитному ScrumBan (хотя возможно) - потому что Scrum с его мероприятиями хорошо обеспечивает принятие Agile mindset, а это может быть важно, особенно если команда перешла на Agile недавно. Но в этом случае к делению на итерации и релизы надо относиться технически и не заморачиваться. Хотя тут тоже может быть место целям, а именно - они должны давать ориентир команде, на какие задачи сделать акцент в том случае, когда что-то пошло не так и все задачи за спринт явно не успеть.
- Есть стратегия развития продукта, и каждый релиз сфокусирован на определенной группе пользователей, и должен достичь существенного приращения поставляемой им ценности, при этом для остальных категорий надо просто завязать немного бантиков (или решить проблемы). В этом случае у спринта появляется сфокусированная цель, связанная с конкретной группой пользователей, плюс некоторые задачи раскрашиваются как ориентированные на другие группы и по ним надо, например, сделать хотя бы одну для каждой группы.
- Промежуточный вариант, когда релиз включает в себя результат нескольких спринтов, и при этом у него есть направленность на определенные группы пользователей, но по каким-то соображениям (например, организация внешнего маркетинга и рекламы) это не делят на несколько релизов. Тогда внутри релиза можно ориентировать спринты на конкретные группы пользователей, формулируя их интересы относительно релиза и проверяя, в какой мере выбранный набор фич позволяет их достигать. И соответственно демо (sprint review по-современному) строить для них.
- Могут быть цели, не связанные с задачами, а нацеленные на совершенствование способа работы (из ретро). Например, выявлен тип задач, для решения которых команда хочет попробовать новые технологии или способ работы, и оценить результаты. Или выявлено узкое горло, связанное с недостаточной кроссфункциональностью - какие-то компетенции локализованы на определенных людях, и получается критическая зависимость в случае отпусков/болезней, или недостаточная производительность, если придут задачи только данного функционала - их придется брать неопытным сотрудникам тоже, и мы хотим эту ситуацию расшить.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.