Пользовательские истории vs Функции
Разработка новых функций, при помощи гибкого подхода, для корпоративных решений в крупных организациях является непростой задачей. Гибкий подход требует постепенно доставки в течение коротких итераций. Сообщество широко применяет пользовательские истории в разделении требований бизнеса на более мелкие фрагменты, имеющие смысл с точки зрения конечного пользователя. Пользовательская история отлично подходит для разработки «с нуля», но становится расплывчатой в сложном мире.
Часто внедрение простых изменений в пользовательский опыт конечного потребителя требует усилий по обновлению десятков серверных систем, распутыванию многочисленных зависимостей и проверке изменений, не создают ли они регресса системы.
SAFe в течение многих лет зарекомендовал себя как надежный фреймворк для крупных компаний, обеспечивающий гибкий подход, который ориентирован на клиента. Нам нужен способ разбить сосредоточенные на пользователе функции на более мелкие истории, которые наследуют все замечательные качества User Story и мотивируют разработчиков решать проблемы системного уровня, памятуя о конечном пользователе, а не просто выполняя технические задачи.
Несколько agile-команд объединены в Agile Release Train (ART) для предоставления ценных и ориентированных на потребителя функций, при соблюдении сложности системы, ограничений архитектуры, соответствия требованиям безопасности и других аспектов, выраженных на уровне User Story.
Примеры Agile-функций и противостояния функций с возможностями вы найдете в этом материале.
Гибкое управление продуктами
Scaled Agile Framework предполагает, что у нас есть специальная роль в продуктовом менеджменте, которая должна постоянно исследовать пользовательскую область, потребности клиентов и ожидания стейкхолдеров. Список приоритетных функций является ядром бэклога программы и ожидаемым результатом процесса исследования. Но как связать пользовательские функции с бэклогами продукта скрам-команд? Скрам-мастера должны обеспечить уточнение функций как совместный и хорошо организованный процесс, похожий на совещание для уточнения бэклога с использованием инструментария SAFe по уточнению функций и цели.
Почему процесс уточнение терпит неудачу
Анализ сложных ориентированных на пользователя функций часто приводит к отрицательному результату. Выделим самые распространенные причины:
- Многочисленные составляющие функции носят технический характер и не могут быть представлены в виде user story с точки зрения конечного пользователя;
- Непонятно, что именно входит в рамки и выходит за рамки функции;
- Мы теряем контроль над крупными функциями;
- Пробелы в общении приводят к повторной работе;
- Отсутствие стандартного описания;
- Потеря концентрации в обсуждениях.
Чтобы создать прочную базу знаний из функции, нам нужно поговорить о персонах, потребностях стейкхолдеров, контексте использования продукта, бизнес-домене, ограничениях, доступности данных и т. д. Многие важные аспекты могут ускользнуть от внимания разработчика, что приводит к переделыванию существующих функций вместо создания новых. Feature Canvas может помочь нам решить эти проблемы, сосредоточив команду Scrum на обсуждении с владельцем продукта более важных аспектов, чем просто критерии приемлемости.
Feature Canvas
Feature Canvas имеет четкую структуру и предлагает определенный ход обсуждения. Дизайн был вдохновлен User Story Canvas и адаптирован для контекста SAFe.
Коммуникационный блок. Первые шаги, отмеченные синим цветом, называются коммуникационным блоком. На первом этапе уточнения функции обсуждение должно быть сосредоточено на профиле конечного пользователя, который получит пользу от этой функции. Вместо того чтобы указывать общий профиль пользователя для каждой функции, нам следует определить конкретный (роль, возраст, демографические данные, ценности), который больше всего выиграет от использования новой функции. На втором этапе определяются нужные люди, которые помогут с экспертизой в предметной области. Шаги третий и четвертый определяют клиента, который платит за эту функцию, и стейкхолдеров.
Контекстный блок. Он вращается вокруг потребностей пользователей и описывает более широкий контекст потенциального использования новых функций. Внедрение критериев приемлемости функции дает некоторые результаты, но улучшение взаимодействия с пользователем способствует достижению бизнес-результатов. Также полезно подтвердить, что гипотеза о выгодах по-прежнему верна, учитывая общую цену решения.
Блок осуществимости решения. Зеленые шаги в canvas представляют блок решения. Обсуждение начинается с определения известных нам ограничений и рисков. Когда все ограничения будут обнаружены, начинается поиск потенциальных решений и подтверждение компромисса с владельцем продукта, что должно привести всех на общую страницу. Владелец продукта часто ожидает, что разработчики предложат несколько решений, от дешевых и забавных до комплексных. Документирование контекста использования, критериев приемки, ограничений и технического решения – вполне достаточно для проведения мозгового штурма кандидатов, способных реализовать функцию поэтапно в течение одного или нескольких спринтов: шаблон, пара решений и критерии приемлемости. Четко определенный контекст должен помочь выразить user story, которая положительно повлияет на пользователя.
Блок релиза. Последние шаги, выделенные фиолетовым цветом, фокусируются на обсуждении потенциальных последствий для процесса релиза. Разработчики могут считать user story завершенной, когда она соответствует критериям приемлемости и ее принимает владелец продукта. Каждая функция должна быть запланирована в доставке соответствующим образом, включая подготовку данных для многоэтапного тестирования, интеграцию с другими связанными функциями, метод сбора данных о применении и обратную связь пользователей. Вам необходимо понять, как автоматизировать сбор статистики применения. Возможно, разработчикам следует интегрировать эту функцию с Google Analytics или разработать собственное решение для отслеживания фактического использования новой функциональности.
Онлайн-фасилитация уточняющего совещания
Feature Canvas отлично работает в распределенной команде, которая проводит agile-совещания удаленно и в конференц-зале. Чтобы фасилитация была эффективной, вы можете попробовать следующее:
- Подготовьте доску в Mural или Miro. Добавьте на доску canvas с высоким разрешением;
- Обеспечение положительного восприятия Feature Canvas командой. Короткие сессии по обучению команды и практическая демонстрация, которая поможет людям увидеть преимущества.
- Процесс складывается из 4-х этапов по 10-15 минут. Вам понадобится от 30 до 60 минут, чтобы заполнить canvas, в зависимости от сложности функции и уровня подготовки.
- Для обсуждения каждой части canvas скрам-мастер или фасилитатор совещания устанавливает таймер на 10-15 минут. Когда время истекло, скрам-мастер собирает отзывы и переводит обсуждение на следующий этап.
ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE
Ближайшие сертификационные тренинги Agile.Live: Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E), Advanced Scrum Master with PSM II Certification
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live