Скрам следующего поколения: спринты не нужны
3 февраля 2023 г.Пришло время следующего поколения Scrum: спринты не нужны. Если вы представляете собой небольшую межфункциональную команду, стремящуюся быстро предоставить клиенту рабочую ценность, выберите то, что нужно бизнесу и пользователю номер один, и создайте его. Получите обратную связь, отрегулируйте и отпустите. Затем выберите следующий. Просто доставить. Не добавляйте туда все, что может поместиться в [временной ящик]. Это не контейнер — это период времени с наименьшим риском, которым команды пытаются управлять. Если вы считаете, что чем больше задач вы зададите, тем выше шанс выпустить — вы ничего не доставите.
Водопад
Планирование спринта и ограниченные по времени спринты можно понять только в том случае, если вы работали в чисто каскадном проекте, который длился, скажем, полтора года, прежде чем что-либо было выпущено. То, что выпускается в конце такого цикла, — это, по сути, новый продукт, почти полностью несовместимый с предыдущей версией.
Примечания к выпуску занимают пять страниц (которые никто не читает), и требуется еще год, чтобы существующие клиенты привыкли к новым версиям. Большинство клиентов вряд ли обновятся, потому что небольшие неудобства, которые устраняет новая версия, не стоят вложений.
Я помню одну из самых впечатляющих презентаций об Agile Transformations. Крупная компания по виртуализации предприятий. Раньше они выпускали новую версию раз в два года. Но среднее время, в течение которого клиент получал новую версию со своим запросом на изменение, составляло… подождите… четыре года. Потому что, как и корпоративные поставщики, корпоративные клиенты не отличаются гибкостью.
Это было впечатляюще, потому что им — поставщику — удалось трансформироваться и полностью перейти на Scrum после месяцев обучения и экспериментов. На момент презентации у них были команды, которые начали выпускать релизы напрямую для своих клиентов каждые две недели.
Хороший спринт
Четыре года вместо двух недель — в этом сила Scrum, если все сделано правильно и с правильными намерениями.
Каков правильный путь? Решите и зафиксируйте на всех уровнях.
Сверхспособности ограниченных по времени спринтов по снижению рисков основаны на простой математике и вере в судьбу. Чтобы это сработало, нужно быть немного суеверным.
Помните закон Мерфи: если что-то может пойти не так, оно обязательно пойдет не так.
Не поймите меня неправильно (непреднамеренно) — дело не в страхе. Это о том, чтобы быть разумным. Информационные технологии сегодня являются самой быстрой отраслью. Это одна из самых сложных экосистем. Agile-команды ежедневно сталкиваются с множеством зависимостей, большинство из которых незапланированы. Вам нужны практики, которые помогут вам продуктивно справляться с неизбежными ежедневными неожиданностями.
Есть еще один известный закон — недостаток любого из множества факторов обрекает начинание на провал. Следовательно, успешное предприятие (в соответствии с этим принципом) — это такое, в котором были устранены все возможные недостатки.
И вот вопрос: как долго вы можете избегать всех возможных недостатков, чтобы убедиться, что ваши усилия будут успешными?
Можете ли вы сделать так, чтобы все внутренние и внешние зависимости от вашего продукта и команды — люди, инструменты, ресурсы, мировая экономика — оставались стабильными и в состоянии, благоприятствующем вашим целям, в течение шести месяцев, одного года, двух лет?
Нет, нельзя.
Вот почему появился Scrum с его страховочной сеткой спринтов, ограниченных по времени. От одной до трех недель кажется предсказуемым, выполнимым и с низким риском.
Мы могли бы попытаться создать все условия, чтобы предоставить нашим клиентам высококачественные товары в течение двух недель или меньше. Звучит достижимо, правда?
У нас есть время, чтобы рассмотреть риски и постоянно получать отзывы об основных потребностях клиентов. Разработчики подтверждают, что они понимают эти главные приоритеты и имеют все необходимое для реализации и предоставления ожидаемых результатов.
Ожидается, что он сработает и получит его раньше, чем через четыре года.
Выпускайте раньше и выпускайте чаще. Спринты вообще обеспечивают непрерывную доставку. Как только вы освоите это, уберите спринты и выпускайте раньше и чаще — например, несколько раз в день.
Скрам и Планирование Спринта — это хороший шаг к ограничению и предотвращению рисков задержек, невыполнения вообще, переделок и потерь, а также выбрасывания месяцев работы в мусорное ведро, потому что ни один клиент не получит ее. Что еще печальнее, если бы не было спринтов, это могло бы уже не понадобиться заказчику на тот момент, когда мы его выпускаем.
Плохой спринт
Проблемы со спринтами начинаются, когда мы начинаем смешивать время и пространство. И вместо того, чтобы воспринимать «тайм-бокс» как предел времени, мы интерпретируем его как контейнер для задач и начинаем кидать в «коробку» столько задач, сколько влезет и еще сверху на случай, если какие-то закончим раньше. Как будто это когда-либо случалось.
И вот когда наш Scrum терпит неудачу.
Инженеры не суеверны. Они оппортунистичны. Они верят, что ничего не может пойти не так, как надо, и их планы надежны. Они не верят в риск. Именно это позволяет им продвигать мировые инновации и технологии, но у такого подхода есть и недостатки.
Самое худшее, что мы можем сделать при планировании спринта, — это начать его с вопроса «Сколько задач мы можем уместить в этот спринт?»
Это коренная причина всего зла, которое мы наблюдаем в настоящее время в управлении продуктами и разработками.
Неважно, сколько задач ваша команда, думает, может выполнить за один спринт. Важно то, какую задачу они смогут выполнить и которую ваш клиент сможет начать использовать в конце спринта.
Если у вас нет сильной Цели продукта, превращенной в Полезную, Значимую, Осуществимую, Готовую к выпуску описание потребностей пользователей, которые ваша команда может выполнить в первую очередь с помощью высокое качество, и если у вас нет четкого видения и механизмов, как справляться с незапланированными недостатками, которые неизбежно возникнут во время спринта, ваше планирование спринта бесполезно и является пустой тратой времени .
Бросание десятков предметов в эту коробку не увеличивает шанс по крайней мере выпустить что-то.
Наоборот, это верный путь к провалу и деморализации команды.
Есть два сценария плохих спринтов. Вышеупомянутый вариант является наиболее распространенным: попытка добавить столько рабочих элементов в спринт, сколько предполагает скорость. Вы заметили, что мы никогда не планируем столько историй, сколько составляет средняя скорость, несмотря на диаграммы скорости? Мы всегда добавляем больше.
Я не могу сосчитать, сколько раз я слышал:
"О, у нас есть вместимость для еще нескольких сюжетных очков. Какие задачи добавить?»
"Давайте оставим немного мощности для исправления ошибок".
"Нет, давайте запланируем весь спринт, и мы всегда сможем удалить те, что внизу, если увидим, что не можем завершить их в подготовительная встреча.”
Угадайте, чем закончится спринт. Нам почти удается выполнить пару задач, 18 историй перемещены в следующий спринт, а 6 – обратно в бэклог.
Вот почему это называется невыполненной работой — это журнал всего, что мы вернули назад.
Другой сценарий неудачного планирования спринта — это когда незавершенная работа над продуктом почти пуста. На самом деле это лучше всего, если это делается специально, но когда это происходит потому, что менеджер по продукту делает все, кроме определения наиболее важных функций, исправлений и улучшений, которые мы должны сделать в первую очередь, чтобы оправдать ожидания клиентов, расширить наши возможности. бизнеса и продвижения с помощью наших технологий, это симптом выгоревшего менеджера по продукту, потраченных впустую командных усилий и мотивации, а также раздражения заинтересованных сторон. Это когда увольняют менеджера по продукту.
Скрам следующего поколения
Нам нужна новая терминология Scrum для редакции 2025 года, чтобы люди ее поняли. Давайте попробуем переосмыслить Скрам следующего поколения:
* Timebox становится высокоэффективным с низким уровнем риска — оптимизированным. Например, ежедневные встречи оптимизированы. * Спринт становится старой доброй итерацией, потому что с помощью спринтов мы забываем итерировать — строить и получать отзывы, а затем снова строить и получать отзывы, пока пользователь не будет доволен, и мы мы достигли наших целей. Например, какую ценность для клиента мы собираемся предоставить в этой итерации?
Вместо спринта (буквально в спешке, потому что это огромная история) и написания кода для пяти спринтов и, в конце концов, заботы о том, чтобы получить обратную связь. Это не agile.
* Бэклог Продукта должен быть приведен в соответствие с Приоритетами, потому что, очевидно, недостаточно повторять тысячу раз, что Бэклог Продукта должен быть упорядочен по приоритетам. Поэтому стоит начать говорить только о Приоритетах Продукта (Бизнеса, Клиента). Это подразумевает размышления о том, что наиболее важно и меняет правила игры для бизнеса по сравнению со списком дел со случайными заметками. Например, каковы наши главные приоритеты как компании?
Без спринтов. Просто доставьте.
Теперь мы пояснили, что все, что имеет значение, — это стратегические цели компании, планы развития бизнеса, потребности клиентов, развитие технологий и видение продукта — Приоритеты — мы должны только начать. работаем над ними.
Какой выбрать? Какой из них является главным приоритетом? Мне нравится идея того, что будет иметь самое существенное значение — и в качестве, и в количестве.
Тот, который обеспечит самый высокий рост. Тот, который откроет самую большую рыночную экспансию. Тот, который принесет больше клиентов. С точки зрения качества это называется Функциональная пригодность (соответствие, полнота, правильность).
Тот, который удержит всех клиентов и повысит надежность вашего продукта (зрелость, доступность, отказоустойчивость, возможность восстановления) и эффективность работы. Если в прошлом месяце у вашей системы был значительный простой, вам необходимо инвестировать в свою инфраструктуру, а также в надежность.
Тот, который разгрузит команды по работе с клиентами, чтобы они могли сосредоточиться на успехе, а не на поддержке. Качеством, обеспечивающим это, является Юзабилити (обучаемость, работоспособность, защита от ошибок пользователя).
Тот, который сделает продукт Поддерживаемость (модульность, возможность повторного использования, анализируемость, модифицируемость, тестируемость) более эффективным. Именно он сократит затраты на исправление ошибок, снизит риск регрессии и ускорит выпуск выпусков за счет обеспечения непрерывной доставки.
Возможно, последняя большая функция была сильно задержана из-за непредвиденных проблем с регрессией. Тогда вам, вероятно, следует отдать приоритет очистке технического долга и серьезному рефакторингу. Это снова повысит удобство обслуживания.
В этом списке приоритетов будет несколько пунктов, которые одинаково важны. Стратегии расстановки приоритетов различаются в зависимости от текущего бизнес-контекста. Возможно, к вам в дверь стучится крупный покупатель рыбы. Тогда вы пойдете с новой большой функцией, которую они ждут. Это функциональная пригодность вашего продукта. И вся команда должна начать работать над этим вместе.
Какой бы ни была ваша текущая ситуация с продуктом, учитывайте ее и всегда полагайтесь на то, что повышает качество вашего продукта и услуги. Это всегда правильный выбор.
Как только вы определитесь со своими целями, все станет легко. Соберите вместе всю команду и позвольте им творить. Пусть они думают и придумывают, пусть рисуют и царапают, пусть они кричат, пусть играют, пусть создают функции, которыми они гордятся, которыми гордитесь вы и которые рекомендуют ваши клиенты. Позвольте им доставить ваш пятизвездочный продукт тысячам довольных клиентов.
Для этого вам не нужны спринты. Вам нужно четкое видение и приоритеты.
Решать. Совершить. Успех.
:::информация Также опубликовано здесь.
:::
Оригинал