Недавно, в ходе «курса молодого бойца коуча», который предполагает прохождение новыми сотрудниками всех тренингов компании ScrumTrek, я побывал на тренинге Управление требованиями в Agile-проектах. Ниже расскажу о впечатлениях, которые остались после тренинга.
Для начала немного о самом тренинге: он проходил в Москве в офисе компании ScrumTrek, длился два полных дня и был посвящен. Проводила тренинг Дарья Рыжкова — Agile Coach с серьезным опытом работы в качестве Product Owner в продуктовых софтверных компаниях.
Первое, что меня удивило и порадовало: порядка 50% участников приехали из различных городов России. Были люди из Ижевска, из северной столицы и даже с Урала. Значит, разработка ПО в России не сосредоточена только в Москве.
Второе, что мне понравилось — это игра, с которой начинается тренинг. Игра очень простая, но ярко иллюстрирует, что ТЗ, электронная переписка и т.п. — это «испорченный телефон», который плохо сказывается на результатах проекта.
Участники тренинга разделяются на несколько команд, в каждой выбирается один человек, который исполняет роль разработчика. Остальные несколько человек исполняют роль аналитиков, которые должны донести до разработчика требования к продукту. Нашим продуктом в игре был простой рисунок из геометрических фигур, который должен изобразить разработчик. Казалось бы, чего проще? Но аналитикам выставляется ограничение: они должны оформить задачу в виде письменного ТЗ, передать разработчику, и все дальнейшее общение с разработчиком должно происходить письменно. Все согласно «лучшим» корпоративным практикам…
В итоге, конечно, получаем что-то отдаленно похожее на то, что хотел заказчик. Как это знакомо, не правда ли?
Верхний рисунок — видение заказчика, нижний рисунок — результат исполнения ТЗ.
На втором этапе игры аналитикам и разработчику уже разрешается общаться устно. Итоговый результат в этой ситуации, как вы догадались, значительно отличается от предыдущего.
Верхний рисунок — видение заказчика, нижний рисунок — результат исполнения.
После игры, погружающей участников в основную проблематику, тренер и участники переходят к разбору основных принципов управления требованиями в Agile проектах. Кратко их можно собрать в следующие пункты:
- Разработка от общего к частному (от общего vision к конкретным фичам).
- Инкрементальность vs итеративность (каждый этап реализации дает прирост ценности для клиента/заказчика).
- Итеративная реализация (реализация/поставка осуществляется короткими итерациями).
- Коммуникации лицом к лицу.
- Передача бизнес-контекста команде важнее идеально написанных требований.
Далее фокус тренинга смещается на рассмотрение различных типов и способов коммуникации, которые можно использовать в команде, их эффективности, временных затрат на организацию того или иного способа.
Вводная часть отлично иллюстрирует одну из ценностей Agile: «Люди и взаимодействие важнее процессов и инструментов». Дальше тренер переходит к рассмотрению инструментов и подходов, которые используются в Agile для идентификации, фиксации и управления требованиями.
Программа первого дня насыщенная, в нее вошли: и краткий экскурс в Scrum Framework, и структура и свойства продуктового бэклога, и методы оценки бэклога, и принципы работы со stakeholders.
Мне как-то особенно запомнилась методика bulk estimation. Она позволяет в короткие сроки произвести оценку бэклога и систематизировать уровни планирования продуктового развития.
Второй день тренинга был посвящен практическим техникам: мы сформировали Vision и модели продукта с помощью Lean Canvas, построили портрет пользователя с помощью подхода Pragmatic Persons, занимались декомпозицией пользовательских историй, разобрали работу пользователя с продуктом на пользовательские истории с помощью Story Mapping и прочее.
Все эти техники шли в связке с построением модели продукта, над которой работали команды во второй день. Наша команда в итоге с гордостью презентовала модель продукта — «Быстронянь».
В целом тренинг прошел для меня продуктивно. Я рекомендовал бы пройти его не только тем, кто планирует стать Product Owner-ом, но и каждому участнику существующей или только планирующейся Agile-команды. В Agile проектах вся команда вовлечена в работу с требованиями, с самого начала проекта.
Что я бы посоветовал организаторам тренинга: добавить практики и примеры, как плавно перейти от традиционных подходов в работе с требованиями к их гибкому управлению.
ссылка на оригинал статьи https://megamozg.ru/post/25755/
Добавить комментарий