КаксоздатьDoDдлябольшойпродуктовойгруппы
Общий DoD необходим для успешной работы больших продуктовых групп. Идеальные DoD обеспечивают полную прозрачность и готовность Инкремента к концу Спринта, помогают выявить проблемные места в работе команд (технический долг) и работать максимально эффективно с точки зрения бизнеса.
Недавно я помогал стартовать группу из семи команд. На их примере я хочу разобрать, как создать общий DoD для большой группы.
Узнайте, чего хочет бизнес
Часто разработчики даже не догадываются, что текущее состояние дел не ок для бизнеса. Дайте слово Владельцу Продукта. Пусть он обозначит желаемый уровень готовности в конце Спринта и желаемую частоту выхода в релиз.
Владелец Продукта должен описать идеальное состояние, на что команды сейчас не способны. Он вполне может сказать: «Хочу, как „Фейсбук“, сто раз в день выходить в релиз». Зафиксируйте пожелания Владельца Продукта — этот артефакт я называю Perfect Vision.
Perfect Vision отрезвляет, задаёт направление для совершенствования. Все члены Скрам-команды должны понимать, что и почему они делают с точки зрения бизнеса.
Создайте несколько вариантов DoD
Чтобы создать максимально полные Критерии Готовности, попросите каждую команду создать на флипчарте свой список активностей и нефункциональных требований к Продукту. Пусть это будет исчерпывающий перечень всего, что нужно для выпуска Продукта в релиз.
Может показаться, что бессмысленно делать несколько DoD, но это не так. В моей продуктовой группе было 50 человек, у каждого — своё понимание DoD. Чтобы их объединить в один и ничего не потерять, удобнее сначала создать несколько вариантов от команд, а затем сравнить их и дополнить. В фасилитации такой подход от частного к общему называется Diverge-Merge.
Соберите самое важное в один DoD
Чтобы объединить все DoD в один, мы использовали технику Аквариум (Fishbowl). Сначала выставили все варианты DoD на флипчартах в ряд и попросили каждую команду выбрать по представителю. Затем представители обсудили между собой и скомпоновали информацию с разных флипчартов. Мы хотели вовлечь как можно больше людей в поиск решения, поэтому провели несколько раундов по 10 минут. В каждом раунде меняли представителей.
Обсудите то, что получилось
Следующий важный шаг — обсуждение финального варианта между всеми членами команд. Чтобы обсуждение не превратилось в балаган, мы использовали такую систему: волонтёр зачитывал по очереди каждый пункт из DoD, после этого я просил всех, кто хотел высказаться, поднять руку. Каждому желающему присваивали порядковый номер и очерёдность выступления. Когда выступал последний желающий, я спрашивал, хочет ли кто-то ещё выступить. Если желающие находились, то мы начинали новый круг обсуждения.
Признайте и ликвидируйте технический долг
После обсуждения мы получили исчерпывающий идеальный DoD, который обеспечивает полную прозрачность и готовность Инкремента к концу Спринта. Но нужно понимать, что идеальный DoD и тот уровень готовности, который команды могут обеспечить сейчас, различаются. Я попросил команды отметить на флипчарте реальный DoD. Всё, что оказалось ниже черты, — технический долг, который нужно ликвидировать как можно скорее.
DoD определяют частоту релизов
Может быть, мне просто не везло, но в больших компаниях я не встречался со Скрам-командами, которые могли бы сами выпускать функциональность на рынок от начала и до конца (end-2-end). Тому есть много причин, например, большое количество архитектурных компонентов, функциональное фрагментирование организации, культура узких специалистов. Чаще всего начальные Критерии Готовности оказываются слабыми, а объём работы Undone, которая необходима, чтобы выпустить функциональность в релиз, велик. Команды проходят Спринт за Спринтом, закрывая элементы Бэклога (PBI) согласно текущим Критериям Готовности, но перед релизом останавливают разработку и проводят ряд активностей по подготовке, которые называют стабилизацией. Есть и другой случай — работу Undone могут выполнять другие (смежные) подразделения, например, отдел нагрузочного тестирования.
Чем сильнее Критерии Готовности, тем меньше времени нужно на стабилизацию, тем чаще Команда сможет выходить в релиз. Если стабилизация и работа Undone равны нулю, то Скрам-команда может релизиться каждый Спринт без задержек.
DoD определяют организационную гибкость
Чем чаще Команда может выходить в релиз, тем чаще Владелец Продукта может получать обратную связь от клиентов, тем больше знаний о рынке и доставленной бизнес-ценности. В соответствии с этими знаниями Владелец Продукта изменяет порядок элементов в Бэклоге. Это и есть организационная гибкость — когда мы устанавливаем интенсивный диалог между Скрам-командой и рынком.Фактическая поставка ценности на рынок происходит только в момент релиза.Благодаря тому, что усиление Критериев Готовности приводит к частым релизам и гибкости, Скрам-команда может бесконечно улучшаться, чтобы когда-нибудь начать поставлять фичи на рынок каждый день. Получаем усиливающую петлю:
DoD определяет качество обратной связи на Обзоре Спринта
Кроме выхода в релиз, Скрам-команда получает обратную связь от заинтересованных лиц на Обзоре Спринта. Но одно дело принести бумажный прототип и взять на него обратную связь, другое дело, когда функциональность демонстрируется на среде, максимально приближённой к боевой (Releaseable). Поэтому сильные Критерии Готовности и минимальный объём работы Undone напрямую влияют на получение знаний о рынке.
Выводы
- Критерии Готовности определяют возможную частоту релизов и организационную гибкость.
- Критерии Готовности определяют также качество обратной связи на Обзоре Спринта и, как следствие, полученные знания о рынке.
- Скрам-команда может бесконечно совершенствоваться, усиливая Критерии Готовности.
- Дизайн совершенства для Скрам-команды — поставка ценной функциональности для клиентов как минимум раз в Спринт без задержек.
- команда осознает важность наличия критериев готовности
- критерии готовности определены в команде
- критерии готовности известны Product Owner-у
- критерии готовности определены, видимы и команда (включая PO) ими активно пользуется
- критерии готовности видимы и известны для всей организации
- критерии готовности видимы и известны за пределами нашей организации (заказчик, пользователи, все, кто заглядывают на демо)
- критерии готовности являются регулярным предметом разговора на демо
- задокументирована пропасть между текущими критериями готовности и “В продакшн”
- описан и известен всем заинтересованным лицам процесс преодоления пропасти
- вся организация регулярно (хотя бы, раз в месяц) активно работает над вопросом, как уменьшить эту пропасть
Критерии готовности
Если мы занимаемся разработкой программного обеспечения, когда же наступает тот момент, когда разработчик может сказать “Готово”? Когда мы слышим “Готово! Работает на моей машине” - это готово или нет? Или “Готово! Unit test исполняется без ошибок” - это готово? Или “Готово! Работает в stage среде” - может быть, это настоящее готово? На картинке слева вы видите всевозможные комбинации “Готово”. По сути, критерии готовности - это просто список всего, что нам нужно сделать прежде, чем мы сможем сказать “Готово”. Нетрудно догадаться, что правильных критериев готовности не существует. Каждая организация вправе называть “Готово” свой набор определенных критериев. Кто-то сертифицирован по стандарту ISO 9001 и в их “готово” будет производство документации и занесение ее в центральное электронное хранилище, а кто-то просто довольствуется комментариями в коде.