Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!

КритерииГотовности(DoD)определяюторганизационнуюгибкость

Большие организации используют Скрам как движок гибкости. Но часто при запуске Скрама команды начинают гнаться за скоростью и для этого ослабляют Критерии Готовности. Сами того не зная, они уменьшают гибкость своей компании. Почему это происходит, разберём с помощью системных диаграмм.

DoD определяют частоту релизов

Может быть, мне просто не везло, но в больших компаниях я не встречался со Скрам-командами, которые могли бы сами выпускать функциональность на рынок от начала и до конца (end-2-end). Тому есть много причин, например, большое количество архитектурных компонентов, функциональное фрагментирование организации, культура узких специалистов.

Чаще всего начальные Критерии Готовности оказываются слабыми, а объём работы Undone, которая необходима, чтобы выпустить функциональность в релиз, велик. Команды проходят Спринт за Спринтом, закрывая элементы Бэклога (PBI) согласно текущим Критериям Готовности, но перед релизом останавливают разработку и проводят ряд активностей по подготовке, которые называют стабилизацией. Есть и другой случай — работу Undone могут выполнять другие (смежные) подразделения, например, отдел нагрузочного тестирования.
Критерии Готовности (DoD) определяют организационную гибкость

Чем сильнее Критерии Готовности, тем меньше времени нужно на стабилизацию, тем чаще Команда сможет выходить в релиз. Если стабилизация и работа Undone равны нулю, то Скрам-команда может релизиться каждый Спринт без задержек.

DoD определяют организационную гибкость

Чем чаще Команда может выходить в релиз, тем чаще Владелец Продукта может получать обратную связь от клиентов, тем больше знаний о рынке и доставленной бизнес-ценности. В соответствии с этими знаниями Владелец Продукта изменяет порядок элементов в Бэклоге. Это и есть организационная гибкость — когда мы устанавливаем интенсивный диалог между Скрам-командой и рынком.

Фактическая поставка ценности на рынок происходит только в момент релиза.

Благодаря тому, что усиление Критериев Готовности приводит к частым релизам и гибкости, Скрам-команда может бесконечно улучшаться, чтобы когда-нибудь начать поставлять фичи на рынок каждый день. Получаем усиливающую петлю:
Критерии Готовности (DoD) определяют организационную гибкость

DoD определяет качество обратной связи на Обзоре Спринта

Кроме выхода в релиз, Скрам-команда получает обратную связь от заинтересованных лиц на Обзоре Спринта. Но одно дело принести бумажный прототип и взять на него обратную связь, другое дело, когда функциональность демонстрируется на среде, максимально приближённой к боевой (Releaseable). Поэтому сильные Критерии Готовности и минимальный объём работы Undone напрямую влияют на получение знаний о рынке.
Критерии Готовности (DoD) определяют организационную гибкость

Выводы

Илья Павличенко Аджайл Коуч Unusual-Concepts

Поделиться
Вотсапнуть
Отправить
Ещё по теме
Общий DoD необходим для успешной работы больших продуктовых групп. Идеальные DoD обеспечивают полную прозрачность и готовность Инкремента к концу Спринта, помогают выявить проблемные места в работе команд (технический долг) и работать максимально эффективно с точки зрения бизнеса. Недавно я помогал стартовать группу из семи команд. На их примере я хочу разобрать, как создать общий DoD для большой группы. Как создать DoD для большой продуктовой группы

Узнайте, чего хочет бизнес

Часто разработчики даже не догадываются, что текущее состояние дел не ок для бизнеса. Дайте слово Владельцу Продукта. Пусть он обозначит желаемый уровень готовности в конце Спринта и желаемую частоту выхода в релиз. Владелец Продукта должен описать идеальное состояние, на что команды сейчас не способны. Он вполне может сказать: «Хочу, как „Фейсбук“, сто раз в день выходить в релиз». Зафиксируйте пожелания Владельца Продукта — этот артефакт я называю Perfect Vision. Perfect Vision отрезвляет, задаёт направление для совершенствования. Все члены Скрам-команды должны понимать, что и почему они делают с точки зрения бизнеса. Как создать DoD для большой продуктовой группы

Создайте несколько вариантов DoD

Чтобы создать максимально полные Критерии Готовности, попросите каждую команду создать на флипчарте свой список активностей и нефункциональных требований к Продукту. Пусть это будет исчерпывающий перечень всего, что нужно для выпуска Продукта в релиз. Может показаться, что бессмысленно делать несколько DoD, но это не так. В моей продуктовой группе было 50 человек, у каждого — своё понимание DoD. Чтобы их объединить в один и ничего не потерять, удобнее сначала создать несколько вариантов от команд, а затем сравнить их и дополнить. В фасилитации такой подход от частного к общему называется Diverge-Merge. Как создать DoD для большой продуктовой группы

Соберите самое важное в один DoD

Чтобы объединить все DoD в один, мы использовали технику Аквариум (Fishbowl). Сначала выставили все варианты DoD на флипчартах в ряд и попросили каждую команду выбрать по представителю. Затем представители обсудили между собой и скомпоновали информацию с разных флипчартов. Мы хотели вовлечь как можно больше людей в поиск решения, поэтому провели несколько раундов по 10 минут. В каждом раунде меняли представителей.

Обсудите то, что получилось

Следующий важный шаг — обсуждение финального варианта между всеми членами команд. Чтобы обсуждение не превратилось в балаган, мы использовали такую систему: волонтёр зачитывал по очереди каждый пункт из DoD, после этого я просил всех, кто хотел высказаться, поднять руку. Каждому желающему присваивали порядковый номер и очерёдность выступления. Когда выступал последний желающий, я спрашивал, хочет ли кто-то ещё выступить. Если желающие находились, то мы начинали новый круг обсуждения. Как создать DoD для большой продуктовой группы

Признайте и ликвидируйте технический долг

После обсуждения мы получили исчерпывающий идеальный DoD, который обеспечивает полную прозрачность и готовность Инкремента к концу Спринта. Но нужно понимать, что идеальный DoD и тот уровень готовности, который команды могут обеспечить сейчас, различаются. Я попросил команды отметить на флипчарте реальный DoD. Всё, что оказалось ниже черты, — технический долг, который нужно ликвидировать как можно скорее.
На сегодняшний день большинство моих клиентов уже не удивишь понятием критериев готовности (Definition of Done). Вот список того, что организации знают о критериях готовности, причем, чем ниже по списку, тем меньше шансов, что это на самом деле практикуется:
  • команда осознает важность наличия критериев готовности
  • критерии готовности определены в команде
  • критерии готовности известны Product Owner-у
  • критерии готовности определены, видимы и команда (включая PO) ими активно пользуется
  • критерии готовности видимы и известны для всей организации
  • критерии готовности видимы и известны за пределами нашей организации (заказчик, пользователи, все, кто заглядывают на демо)
  • критерии готовности являются регулярным предметом разговора на демо
  • задокументирована пропасть между текущими критериями готовности и “В продакшн”
  • описан и известен всем заинтересованным лицам процесс преодоления пропасти
  • вся организация регулярно (хотя бы, раз в месяц) активно работает над вопросом, как уменьшить эту пропасть
Вот о последних трех пунктах мне и хотелось бы поговорить более подробно. Итак, обо всем по порядку.

Критерии готовности

Критерии готовностиЕсли мы занимаемся разработкой программного обеспечения, когда же наступает тот момент, когда разработчик может сказать “Готово”? Когда мы слышим “Готово! Работает на моей машине” - это готово или нет? Или “Готово! Unit test исполняется без ошибок” - это готово? Или “Готово! Работает в stage среде” - может быть, это настоящее готово? На картинке слева вы видите всевозможные комбинации “Готово”. По сути, критерии готовности - это просто список всего, что нам нужно сделать прежде, чем мы сможем сказать “Готово”. Нетрудно догадаться, что правильных критериев готовности не существует. Каждая организация вправе называть “Готово” свой набор определенных критериев. Кто-то сертифицирован по стандарту ISO 9001 и в их “готово” будет производство документации и занесение ее в центральное электронное хранилище, а кто-то просто довольствуется комментариями в коде.

Мерило критериев готовности

Хочется отметить, что некое мерило критериев готовности у нас все же есть. Ведь, если посмотреть на критерии готовности со стороны пользователя (заказчика), то единственное “готово”, о котором он печется, будет “Готово, я могу это потрогать в моем программном обеспечении, в той среде, где я и буду этим пользоваться”. То есть готово и находится в продакшн. Понятно, что далеко не всякая организация может добиться выхода в продакшн по окончании каждой итерации, однако, стремиться к этому все-таки нужно.

Документируем пропасть

Во многих организациях аджайл команды могут довольно быстро (1-4 недели) довести спринт бэклог до состояния готовности, согласно заранее согласованным Критериям готовности, и встать перед пропастью. Пропастью между тем, что мы называем “готово”, и тем, о чем заботятся конечные пользователи, а именно, готово в продакшн. Кое у кого процесс преодоления пропасти занимает от 3 до 6 месяцев. То есть, вот у нас все “готово”, но до того как наши пользователи смогут это потрогать, пройдет еще полгода. Если ваша организация является одной из вышеупомянутых и вы тоже (пока) не можете выходить в прод в конце каждой итерации, очень советую вам задокументировать свою пропасть. Подробно опишите, что происходит у вас с момента “готово” до момента “готово в продакшн”. Какие телодвижения надо предпринять? Кто их предпринимает? Каковы процедуры выполнения нужных шагов? Составьте этот список и повесьте его на видное место, рядом с Критериями готовности. Постарайтесь сделать эти два списка неразлучными. Идете на демо и несете с собой флип-чарт с Критериями готовности? Прихватите с собой и флип-чарт с “пропастью”. Это потребует определенной смелости, особенно, первый раз, но ведь аджайл это именно об этом. Помните Храбрость (Courage), как одну из аджайл ценностей? Само наличие подобного списка станет уже очень большим шагом вперед для вашей организации. Ведь теперь вы сможете им пользоваться, для того, чтобы очередной раз вывести в продакшн кусок готового функционала.

Работаем над пропастью

После того, как пропасть задокументирована и сделана видимой, все пойдет немного легче. Если вы сделаете список с пропастью видимым, обещаю вам, он гарантировано станет безмолвным инициатором не одного “трудного” разговора на всевозможных уровнях в вашей компании. Люди начнут задаваться вопросами: “Почему так?”, “Что мы можем сделать, чтобы было по-другому?”, “Как это можно ускорить?” и прочими, то есть, начнется настоящая работа. Работа по тому, как уменьшить пропасть. На каждом демо, на каждой ретроспективе вы сможете посвящать 10 минут тому, чтобы подумать, а как мы можем быть более “готовыми” в следующий спринт? Очень рекомендую целиком посвящать этому важному вопросу одну ретроспективу в год, собирая вместе всю организацию. Это станет для вас хорошим двигателем вперед (для кого-то вечным двигателем :)). А как у вас с Критериями готовности? На какой стадии остановились вы? Делимся в комментариях.
Комментарии
Подпишитесь на нас:
Телеграм Группа в фейсбуке