Обновление скрам-гайда

Стало проще, и полезное добавилось. Для общего развития пригодится. Будете хотя бы понимать, где скрам, где не скрам.

Все еще не рекомендую брать скрам и прикручивать к себе «на изоленту», потому что SCRUM это цельная методология — в смысле неделимая, хотя и достаточно несложная. Добавлять — можно. Выкидывать части — нельзя, они несущие, их там и так немного.

Думаю, с этим моментом разберётесь, я уже несколько раз подробно об этом писал.

Авторы обновили гайд. Давайте ближе к делу: что поменялось-то.
От наиболее значительного к остальному, на мой вкус.

Цель продукта

Добавилось описание product goal. Предполагается, что итерации/спринты мы еще оцениваем по части того, насколько они приближают нас к цели. Соответственно, можно сравнить импакт, и постараться взять куски работы чутка полезнее.

Позволяет, в теории, изменить приоритеты так, чтобы уйти от всяких пустопорожних фрикций и «работы ради работы». Никто не говорит, что работа ненужная, просто в выборе фокусировки берем наиболее значительное.

Цели у каждого этапа

Они были, их просто нормально прописали. Теперь у продуктового беклога общая цель — это product goal, у беклога спринта — это sprint goal, у инкрементов/кусков работы это Definition of Done.

Все три — это именно артефакты. Они должны быть описаны, их можно посмотреть, почитать и потрогать. Соответственно, ожидание практического выхода, и обязательства в этой связи — то есть, коммитменты — также существуют именно в такой привязке (к PG, SG и DoD). Нельзя и неполезно коммититься на какие-то абстракции и фантазии: замучаетесь мерить.

Планирование спринта

Кроме вопросов «что делаем?» и «как делаем?» добавился третий вопрос «нахера делаем?», в смысле Why. Не в метафизическом смысле, а чего конкретно нам это дает из Product Goal и почему хотим сейчас именно это.

Why хорошая штука, которая позволяет нормально прописывать ADR (architecture decision records): что сделано, почему, как выбирали, и почему выбрали именно это.

Овнер и менеджер тоже часть команды разработки

Раньше было логическое отделение: вот типа люди от планирования, руководство, овнер и менеджер/мастер — а вон у нас рукопахари. Теперь нет, они все у нас Dev Team, иногда даже со смежными ролями. Все в одной лодке, ответственности у них общие.

Есть еще малое замечание, что человек который вносит значительный вклад в разработку, обсуждения или планирование, прям на техническом уровне — тоже считается частью команды разработки пофиг что он там себе сам считает. И к нему можно применять те же процессы и механики, для единообразия.

Это раскрывает вопрос «совмещения ролей». Хотите — совмещайте. Лишь бы делалось в полном обьеме.

Овнер и с/мастер и все остальные т.к часть scrum team, «предельный» размер увеличен ST до 10 человек. Но это вообще пофиг, это ограничение всегда было рекомендательным и само-очевидным, много людей = больше бардак.

Сокращение обязательных частей

В основном перенесли устоявшиеся «жесткие» механики в часть рекомендательных. Например, протокол ежедневной планерки — да планируйте вы там как хотите, главное чтобы был ответ на вопрос «что у нас происходит» и «что мы собираемся сделать прямщас».

Классическую скрам-планерку (что делал, что сделал, что буду делать, где затыки и кто мне нужен?) это не отменяет, но если вам удобнее по-другому, да кто бы спорил.

Само-управление вместо само-организации

Убрали лишний формализм. Не важно, как команда организована и структурно выглядит, лишь бы она нормально управлялась и работа делалась. Также на откуп команде отдали вопрос, кто конкретно над чем работает — выберите сами, не кипятите голову.

Это достаточно удобно, потому что прошлый скрам сильно пробуксовывал когда есть зависимости команд или проектные микро-команды, постоянные или ситуативные. Теперь просто формируйте как больше нравится.

Убрали привязки к циклу разработки

Разделение на проектирование, тестирование, сбор требований, системный блок итп теперь опциональное. Видимо потому что не везде было это применимо и в общем смысле избыточно.

Основная цель

Самое важное нововведение, единственное в своей весовой категории. Цель нужна для того, чтобы прикидывать и измерять её достижение. Вообще или в моменте. Остальные ее свойства именно сам скрам никак не затрагивает — например, оправданность, важность, ценность и так далее.

С точки зрения скрама, цель поставлена и первична, а дальше вы танцуете предложенные итерации механики и методологии, чтобы как-то поживее и поэффективнее до этой цели дойти.

Как соотносятся задачи в Product Backlog с основной целью — зона ответственности Product Owner.

Product теперь прописан более конкретно. Как механизм (который вы строите), который приносит заявленную ценность. You need to build an engine.

Из всего этого логически вытекает, что цель должна быть конкретной и измеримой. Конкретность определяется ценностью и набором изменений; а конкретнее по тексту, даже целевым состоянием: «a future state of the product which can serve as a target». Набор изменений от «сейчас» до «зашибись» собираются в product backlog.

Измеримость интереснее. Нужны либо цифры, либо наборы критериев. И в общем-то если спросить меня, то я тоже горячо рекомендую именно этого придерживаться.

• «захватить мир» — херовая цель, потому что вы нормально это не измерите (даже в моменте), а конкретики нет
• «захватить мир к октябрю» — не сильно лучше
• «получить вот тут показатель лучше конкурента» — уже что-то. Потому что измеримо, хотя и относительно
• «получить вот тут рост показателя на X» — измеримость появляется, можно сравнивать одно с другим
• «сделать вот такие и вот такие фичи» — конкретно, но не измеримо (потому что сделать можно по-разному)
• «сделать фичи по списку и получить вот такую целевую метрику» — конкретно, измеримо, но не факт что одно будет связано с другим
• «сделать AA чтобы получилось XX (достигаем вот этого), сделать BB чтобы YY (будет вот так)» — еще получше, появились связи, их проще дебажить и оценивать
• «сделать в продукте вот этот список, чтобы по нему последовательно получить вот такие улучшения, чтобы общие метрики стали вот такими» — уже близко к рабочему варианту, нормас (есть гипотеза, есть план, есть показатели)

Нигде не заявлено, что у вас не может быть несколько целей. Или что их нельзя менять в процессе. Методология гибкая, если вы в процессе понимаете, что надо менять планы — меняйте планы, тут вам не вотерфолл.

Ограничения — на одну итерацию цель должна быть зафиксирована (это раз), и продукт должен быть один (это два).

С несколькими продуктами скрам работает херово. Фокусировка микрокоманды разваливается. Этот момент был, и он не поменялся.

Hope that helps.