https://mtsepkov.org/index.php?action=history&feed=atom&title=%D0%91%D0%BB%D0%BE%D0%B3%3A%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0%2F2018-01-24%3A_%D0%9E_%D1%86%D0%B5%D0%BB%D1%8F%D1%85_%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82%D0%B0 2026-10-20T02:19:21Z История изменений этой страницы в вики MediaWiki 1.26.4 https://mtsepkov.org/index.php?title=%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2018-01-24:_%D0%9E_%D1%86%D0%B5%D0%BB%D1%8F%D1%85_%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82%D0%B0&diff=3559&oldid=prev 2018-01-24T07:17:05Z

<p>Новая страница: «{{RightNote|[https://www.facebook.com/groups/agilerussia/permalink/1828121853928706/ Пост на Facebook]}} &lt;blockquote&gt;Коллеги, здравствуйт…»</p> <p><b>Новая страница</b></p><div>{{RightNote|[https://www.facebook.com/groups/agilerussia/permalink/1828121853928706/ Пост на Facebook]}}<br /> <br /> &lt;blockquote&gt;Коллеги, здравствуйте! Я начинающий agile-коуч. Столкнулся с такой проблемой: команды программистов работают по Scrum над непрерывным совершенствованием уже работающего, пользующегося популярностью продукта. Scrum стали применять недавно, месяца 3-4. Задачи на спринт накидывают овнеры команд. Они разноплановые, решают очень разные проблемы функционирования продукта. Как определять цель спринта в такой ситуации? Может ли быть несколько целей? Насколько важно в такой ситуации вообще формулировать бизнес- или потребительские цели? Не достаточно ли того, что сформулированы юзер-сториз задач?<br /> &lt;/blockquote&gt;<br /> <br /> Я привожу свой ответ, а в посте идет активное обсуждение этой интересной темы.<br /> <br /> Смотри, тут надо понимать насколько в этом продукте целесообразен релизный цикл, пакетирование новых фич, которые совершенствуют продукт, в релизы, выпускаемые каждый спринт. И насколько вообще релизный цикл связан со спринтами - потому что когда Scrum появился, 2-недельный релизный цикл был крутым, а теперь появились практики continious delivery, которые делают выпуск релизов непрерывным.<br /> <br /> Может быть несколько разных вариантов, часть из них я перечислю. <br /> # Развитие продукта - просто непрерывное добавление фич, которые поступают от пользователей, и Product Owner просто осуществляет арбитраж интересов стейкхолдеров. В этом смысле деление на релизы и, соответственно, итерации Scrum может быть техническим приемом, которые не имеет особого смысла. Это не значит, что надо отказываться от Scrum и переходить к Kanban или композитному ScrumBan (хотя возможно) - потому что Scrum с его мероприятиями хорошо обеспечивает принятие Agile mindset, а это может быть важно, особенно если команда перешла на Agile недавно. Но в этом случае к делению на итерации и релизы надо относиться технически и не заморачиваться. Хотя тут тоже может быть место целям, а именно - они должны давать ориентир команде, на какие задачи сделать акцент в том случае, когда что-то пошло не так и все задачи за спринт явно не успеть.<br /> # Есть стратегия развития продукта, и каждый релиз сфокусирован на определенной группе пользователей, и должен достичь существенного приращения поставляемой им ценности, при этом для остальных категорий надо просто завязать немного бантиков (или решить проблемы). В этом случае у спринта появляется сфокусированная цель, связанная с конкретной группой пользователей, плюс некоторые задачи раскрашиваются как ориентированные на другие группы и по ним надо, например, сделать хотя бы одну для каждой группы.<br /> # Промежуточный вариант, когда релиз включает в себя результат нескольких спринтов, и при этом у него есть направленность на определенные группы пользователей, но по каким-то соображениям (например, организация внешнего маркетинга и рекламы) это не делят на несколько релизов. Тогда внутри релиза можно ориентировать спринты на конкретные группы пользователей, формулируя их интересы относительно релиза и проверяя, в какой мере выбранный набор фич позволяет их достигать. И соответственно демо (sprint review по-современному) строить для них.<br /> # Могут быть цели, не связанные с задачами, а нацеленные на совершенствование способа работы (из ретро). Например, выявлен тип задач, для решения которых команда хочет попробовать новые технологии или способ работы, и оценить результаты. Или выявлено узкое горло, связанное с недостаточной кроссфункциональностью - какие-то компетенции локализованы на определенных людях, и получается критическая зависимость в случае отпусков/болезней, или недостаточная производительность, если придут задачи только данного функционала - их придется брать неопытным сотрудникам тоже, и мы хотим эту ситуацию расшить.<br /> {{wl-publish: 2018-01-24 10:17:05 +0300 | MaksTsepkov }}</div>

MaksTsepkov