Вспомним, что о Цели спринта (Sprint Goal) говорится в официальном руководстве по Scrum:
Sprint Goal — единственная цель на Sprint. Несмотря на то, что Developers привержены Sprint Goal, она обеспечивает гибкость с точки зрения выбора конкретной работы, необходимой для ее достижения. Sprint Goal также обеспечивает связность и сфокусированность, побуждая Scrum Team работать совместно, а не над отдельными инициативами.
Sprint Goal создается во время Sprint Planning, а затем добавляется в Sprint Backlog. Developers помнят о Sprint Goal в ходе работы над задачами Sprint. Если работа не соответствует ожиданиям, они взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках Sprint, не изменяя Sprint Goal....
В ходе Sprint Planning ... вся Scrum Team совместно определяет Sprint Goal, которая объясняет, почему Sprint ценен для заинтересованных лиц. Sprint Goal должна быть сформулирована до окончания Sprint Planning.
Можно определить несколько преимуществ от использования Цели спринта:
четкий фокус команды во время работы на достижении цели
критерий для внесения изменений в работу (помогут ли они достижению цели или наоборот помешают)
мотивирующий фактор в работе, побуждающий в том числе к взаимопомощи и командной работе
прозрачность работы команды для заинтересованных лиц (stakeholders)
критерий определения эффективности работы на обзоре спринта и ретро-сессии
Но определение цели на спринт может быть достаточно сложным для команды, многие команды испытывают трудности с этим. А ведь это регулярный процесс, на каждом планировании спринта приходится это делать (в среднем плюс-минус раз в две недели). Если сама команда не видит пользы от этого артефакта и считает формулировку цели пустой тратой времени, делать они это, скорее всего, не будут. В итоге, после нескольких начальных спринтов в проекте (по опыту, первоначального запала хватает от 1-2 мес до полугода) либо на это все забивают с аргументацией: "Мы не можем брать на себя такое обязательство, все эти строгие цели и дедлайны это не Agile", "В нашей команде это не работает", "Клиенту на эти цели пофиг, значит нечего тратить на них время"и т.п. Либо цель определяет владелец продукта / менеджер в приказном порядке (в командах, работающих на "ручном управлении").
Иногда цель спринта становится мульти-целью, когда команда не может определить что главное для клиента, какую пользу ему принесет этот инкремент, и включает в Sprint goal несколько пунктов. Не говоря уже о Цели 80-го Уровня: "Закрыть все эти чертовы таски за этот спринт!"
Отсутствие четкой цели на спринт может привести к тому, что команда потеряет фокус, что же важно сделать за спринт, каждый будет делать те задачи, которые ему кажутся сейчас приоритетными ("кто в багфиксинг, кто за техдолгом"). В итоге на спринт ревью и ретроспективе вместо обсуждения прогресса в достижении Цели спринта, члены команды откупаются ничего не значащими фразами "вроде всё норм, всё как всегда, замечаний нет". Про предлагаемые улучшения, которые в идеале должны быть по итогам ретро-сесии добавлены в бэклог, и говорить не приходится.
Встречал такие проекты и команды на практике, итог практически всегда предсказуем - расфокусировка команды, быстрая потеря мотивации у разработчиков, отсутствие улучшений в работе, постоянный перенос незавершенных задач на следующий спринт, поставка нового релиза раз в 2-3-4 месяца. И вот уже у вас вместо Скрама лишь пустой по сути карго-культ, и руководство ищет на замену нового менеджера или Скрам-мастера, потому что этот "поломался"...
Между тем, вместо того чтобы убеждать команду "старайтесь получше, чтобы сформулировать хорошую Цель спринта", можно обратить внимание, какие есть препятствия в формулировке релевантной Sprint Goal. Команда опасается негативных последствий в случае не достижения цели. Слишком короткие спринты. Владельцу продукта не хватает полномочий. Слишком много внешних зависимостей. Склонность высшего руководства или клиентов набрасывать "срочные очень приоритетные" задачи.
Не игнорируйте постановку цели на предстоящий спринт, это может быть очень полезным инструментом если использовать правильно. Вспомните, с чего начинается официальное руководство по Scrum:
Каждый элемент фреймворка служит определенной цели, необходимой для достижения общей ценности и результатов от применения Scrum. Изменение ключевых идей или структуры Scrum, исключение каких-либо элементов или не следование правилам Scrum приводит к сокрытию проблем, ограничивает преимущества Scrum и потенциально даже делает его бесполезным.
Не старайтесь убедить или заставить людей формулировать цель - лучше обратите внимание на выяснение и устранение препятствий на пути к этому.
Комментарии (17)
AlexunKo
17.09.2022 20:30+5Всегда любил абстрактные рассуждения в вакууме. Нужен ли человеку костыль. Давайте подумаем...
it_manager
17.09.2022 20:32+3Думаю, что разработчики хотят, чтобы им просто уже не мешали работать :)
tolyanski
17.09.2022 20:48+16Правильно ли я понял, что скрам - это такая штука, при которой в перерывах между митингами программистам разрешается немного поработать?)
GospodinKolhoznik
17.09.2022 23:15+4Как в сериале Офис в одной из серий появляется новенькая сотрудница, она спрашивает у бывалой, - Когда же вы работаете!? - Ну мы стараемся выкроить время в перерывах между закидонами нашего босса.
BasicWolf
17.09.2022 21:43+2Андрей, я вам очень рекомендую посмотреть это гениальное выступление Кевина Хенней под названием Agility ≠ Speed. А после - выступление Аллена Холуба: The Death of Agile. Они внесут немного хаоса в ваши взгляды и помогут посмотреть на знакомые вещи под другим углом.
SigSauer Автор
17.09.2022 23:08Судя по описанию, новой идеи там нет, то что например velocity очень условный показатель уже давным-давно все говорят, не надо начинать "управлять метриками"
Но в любом случае спасибо за ссылки
Wyrd
17.09.2022 22:06+5поставка нового релиза раз в 2-3-4 месяца
Аджайл церемонии на это не влияют от слова совсем. Чтобы релизы деплоились часто нужен не аджайл, а нормальная инфраструктура: автоматические ci/cd пайплайны, интеграционные авто-тесты, деплой в один клик без остановки сервиса, непрерывный мониторинг, возможность быстро откатить релиз назад. В идеале цикл «сделал маленькое изменение, пушнул, сбилдил, прогнал тесты, отправил на прод» - должен занимать 15 минут, тогда команда сама начнёт релизить на прод несколько раз в неделю, а то и в день без всяких скрамов и целей спринта.
JuryPol
17.09.2022 22:32+7тогда команда сама начнёт релизить на прод несколько раз в неделю, а то и в день без всяких скрамов и целей спринта
А куда девать свору аджайл-коучей? Да и кучу прочей околоайтишной братии? Если они начнут работу работать, никакие пайплайны не спасут…
SigSauer Автор
17.09.2022 23:15А вот и не согласен.
CI/CD, автотесты и т.п. - это инструменты.
Они ничего не дадут, если команде фиолетово какие там у клиента проблемы, и целью спринта считается закрыть все взятые в спринт таски.
Ну а релизить несколько раз в день конечно хорошо, главное релизить то что надо клиенту или пользователям, а это бывает не всегда )BasicWolf
17.09.2022 23:31+3А как вы узнаете, сделали ли вы "то что надо клиенту", или нет, не релизнув? :)
SigSauer Автор
18.09.2022 08:53-1Так это был ответ на посыл "можно релизить без всяких скрамов и целей"
Можно то можно, но на практике подход "просто дайте программистам работать, без скрамов и управлений проектами" работает редко :) Мне кажется весь этот Скрам-хайп уже прошел пик, дальше будет нормальное использование там где это уместно
tolyanski
17.09.2022 23:33+5Не забываем про технические задачи, польза от которых прямо сразу не видна заказчику, потому что функционально они ничего не добавляют. Но задачи эти делать надо, и выделять время на них надо прилично, чтобы потом со временем не начала проседать скорость введения новых фич по причине того, что команда погрязла в техническом долге, запутанном спагетти-коде, лавине багов и т.д. А в особо запущенных случаях на прод может незаметно просочиться то, что я называю "фатальный баг": неприятная поломка, спровоцировавшая цепочку негативных событий и приведшая к банкротству всей компании.
BasicWolf
18.09.2022 00:06+4Вы всё детально разложили по полочкам! Из личного - в зависимости от характера ПО, стоит объяснять заказчику что это не проект типа "сделал-запустил-забыл", а продукт "сделал-запустил-развиваю". И техническая составляющая - большАя часть этого развития, от которой никуда не деться.
P.S. тем паче, частые релизы помогают узнать, не сломалось ли что-то из технической составляющей.
varanio
18.09.2022 10:28+4С помощью скрама сделали высосанные из пальца дедлайны ("спринты"), к ним высосали из пальца концепцию "цель спринта", а теперь статья про успешный успех, как эти цели формулировать.
Если у продукт овнера реально есть важный фокус для команды, то он и так донесёт до разрабов: обычно это задачи с суперприоритетом. Но иногда (очень часто) бывает так, что одной цели нет: там подправить, там дописать доку, а тут поисследовать. И это нормально. Не надо натягивать сову на глобус, и всё впихивать в вымученную цель
auddu_k
18.09.2022 12:05+2Странная статья. Вроде бы правильные слова, но ни о чем. Непонятна ни цель написания и достигнутый результат
Важна же не цель и ее формулировка, важна работа команды с целью, научение команды этой работе.
funca
19.09.2022 00:17+1Цель спринта удобно использовать в качестве фильтра для того, чтобы брать в спринт только релевантные задачи и от этого строить приоритизацию. Приносит пользу если у вас много стейкхолдеров, либо PO склонен хотеть разного (обычно все и сразу).
Prion
Судя по минусу, разработчики (и не только разработчики) устали от Agile . Собственно в чем смысл этой статьи, вроде ничего нового нет?