Как улучшить фичи в SAFe
Для начала важно понять, что такое фичи (features), прежде чем пытаться их улучшить. Фича — это функциональность решения, которая приносит ценность бизнесу, удовлетворяет потребности заинтересованных лиц и достаточно компактна, чтобы быть реализованной одной командой Agile Release Train в рамках одного интервала планирования (Planning Interval, PI).
Давайте рассмотрим проблемы, с которыми сталкиваются команды при работе с фичами.
Давайте рассмотрим проблемы, с которыми сталкиваются команды при работе с фичами.
Проблема масштаба
Подумайте о больших продуктах, разрабатываемых вашей компанией.
Можете ли вы предоставить конечному пользователю готовую ценность за день или два? Это и есть оптимальный размер пользовательской истории (User Story). А что если за две недели? Такой срок — это рекомендуемая продолжительность спринта. Если же User Story не помещаются в двухнедельный спринт, может возникнуть желание увеличить его продолжительность. Однако чем длиннее итерация, тем меньше команда получает обратной связи, что нарушает основные принципы Agile и SAFe. Решение заключается не в увеличении сроков, а в добавлении уровня агрегации — и здесь на помощь приходят фичи.
Фичи (features) приносят реальную ценность конечному пользователю и помогают разбить пользовательские истории на небольшие шаги, что позволяет быстрее получать обратную связь. Хотя каждая история сама по себе имеет ценность и может быть выпущена, это не всегда обязательно. Фичи становятся точками выпуска, объединяя несколько историй и предоставляя возможность выпускать их тогда, когда они составляют достаточно функционала для создания полноценной пользы пользователю.
Фичи (features) приносят реальную ценность конечному пользователю и помогают разбить пользовательские истории на небольшие шаги, что позволяет быстрее получать обратную связь. Хотя каждая история сама по себе имеет ценность и может быть выпущена, это не всегда обязательно. Фичи становятся точками выпуска, объединяя несколько историй и предоставляя возможность выпускать их тогда, когда они составляют достаточно функционала для создания полноценной пользы пользователю.
Потенциально освобождаемые точки (Releasable Points)
Готовность к выпуску: Фичи (features) должны включать все необходимые задачи для готовности к выпуску, включая обновление документации и подготовку внутренних материалов.
Комплексное тестирование: Все фичи должны проходить полное тестирование, включая проверку безопасности и сетевые стресс-тесты. Для этого необходимо использовать отдельную инфраструктуру, чтобы избежать проблем в основной корпоративной сети.
Проектирование дополнительных элементов: При проектировании фич важно учитывать ведение логов, сбор метрик и наличие точек для отладки. Это упростит поддержку и обслуживание продукта в будущем.
Definition-Of-Done (DOD): При планировании используйте DOD для создания пользовательских историй. Готовность к выпуску зависит не только от технической стороны, но и от бизнес-факторов, таких как маркетинговые кампании или праздничные дни.
Ценность функций: Фичи должны разрабатываться с учетом как внутренней, так и внешней ценности. Фичи-активаторы позволяют управлять рисками, строить архитектуру и быстрее создавать прототипы, что помогает быстрее приносить ценность конечному пользователю.
Комплексное тестирование: Все фичи должны проходить полное тестирование, включая проверку безопасности и сетевые стресс-тесты. Для этого необходимо использовать отдельную инфраструктуру, чтобы избежать проблем в основной корпоративной сети.
Проектирование дополнительных элементов: При проектировании фич важно учитывать ведение логов, сбор метрик и наличие точек для отладки. Это упростит поддержку и обслуживание продукта в будущем.
Definition-Of-Done (DOD): При планировании используйте DOD для создания пользовательских историй. Готовность к выпуску зависит не только от технической стороны, но и от бизнес-факторов, таких как маркетинговые кампании или праздничные дни.
Ценность функций: Фичи должны разрабатываться с учетом как внутренней, так и внешней ценности. Фичи-активаторы позволяют управлять рисками, строить архитектуру и быстрее создавать прототипы, что помогает быстрее приносить ценность конечному пользователю.
Ограничения функций
Ограничения планирования: Фичи подчиняются временным рамкам, установленным Agile Release Train (ART), которые управляют планированием и реализации того или иного проекта.
Размер функций: Не следует стремиться к созданию одной крупной функции, которая займет весь интервал планирования. Это может привести к задержкам и снижению ценности. Фичи должны быть среднего размера: не слишком большие, но и не слишком мелкие, чтобы не превращаться в отдельные истории.
Ценность отдельных историй: Если отдельные истории могут быть выпущены и каждая приносит ценность конечному потребителю, нет необходимости в их масштабировании в большую функцию.
Сотрудничество команд: В разработке сложных систем или платформ функции могут охватывать несколько команд. Для успешной реализации важно тесное сотрудничество между командами, особенно когда фича затрагивает различные подсистемы.
Размер функций: Не следует стремиться к созданию одной крупной функции, которая займет весь интервал планирования. Это может привести к задержкам и снижению ценности. Фичи должны быть среднего размера: не слишком большие, но и не слишком мелкие, чтобы не превращаться в отдельные истории.
Ценность отдельных историй: Если отдельные истории могут быть выпущены и каждая приносит ценность конечному потребителю, нет необходимости в их масштабировании в большую функцию.
Сотрудничество команд: В разработке сложных систем или платформ функции могут охватывать несколько команд. Для успешной реализации важно тесное сотрудничество между командами, особенно когда фича затрагивает различные подсистемы.
Жизненный цикл фичи
Теперь, когда мы поняли, что такое Фичи — потенциально выпускаемые элементы, которые приносят ценность клиенту, давай кратко рассмотрим путь, который они проходят, чтобы стать ценностью для конечного пользователя.
Запрос: Идея функции должна быть представлена в виде названия и выгоды/пользы, чтобы снизить барьер для внесения предложений. Возможно, добавляется начальная оценка, которая поможет в прогнозировании и составлении дорожной карты. На этом этапе не нужно больше деталей.
Готовность: Добавьте уточнения, чтобы подготовить функцию к PI Planning. Сосредоточьтесь только на функциях, необходимых для следующего PI Planning.
Приверженность идеи: на этапе PI планирования команды создают user stories, которые помогут реализовать фичу, и соглашаются с планом.
Предварительный просмотр: Старайтесь демонстрировать фичу как можно раньше. Это поможет собрать обратную связь и скорректировать направление ее разработки. Если демонстрация результата будет только в конце, это может замедлить работу, потому что не всё может оказаться ценным.
Принятие: Менеджер по продукту подтверждает, что функция удовлетворяет потребности бизнеса. Оцените ценность, а не объем выполненной работы — возможно, вы достигли цели, не выполнив все запланированные задачи, или процесс работы изменился в ходе реализации.
Выпуск: Важный этап, поскольку как только продукт достигает конечных пользователей, мы можем начать проверять гипотезы о преимуществах.
Успех: Гипотеза о выгоде доказана. Если метрики показывают, что успеха не было, этот результат также имеет ценность, так как позволяет понять, чего не хотят клиенты, и избежать ошибок в будущем.
Важно понимать, что этапы, через которые проходит фича, — это не процесс. Этапы универсальны и применимы для всех, но ваш процесс — уникален. В одном процессе может быть много шагов для перехода на следующий этап, в другом — всего один. Процесс должен развиваться, адаптируясь под вашу реальность, но основные этапы остаются неизменными. Обсуждая эти этапы, мы избегаем путаницы, связанной с разными трактовками процесса.
Готовность: Добавьте уточнения, чтобы подготовить функцию к PI Planning. Сосредоточьтесь только на функциях, необходимых для следующего PI Planning.
Приверженность идеи: на этапе PI планирования команды создают user stories, которые помогут реализовать фичу, и соглашаются с планом.
Предварительный просмотр: Старайтесь демонстрировать фичу как можно раньше. Это поможет собрать обратную связь и скорректировать направление ее разработки. Если демонстрация результата будет только в конце, это может замедлить работу, потому что не всё может оказаться ценным.
Принятие: Менеджер по продукту подтверждает, что функция удовлетворяет потребности бизнеса. Оцените ценность, а не объем выполненной работы — возможно, вы достигли цели, не выполнив все запланированные задачи, или процесс работы изменился в ходе реализации.
Выпуск: Важный этап, поскольку как только продукт достигает конечных пользователей, мы можем начать проверять гипотезы о преимуществах.
Успех: Гипотеза о выгоде доказана. Если метрики показывают, что успеха не было, этот результат также имеет ценность, так как позволяет понять, чего не хотят клиенты, и избежать ошибок в будущем.
Важно понимать, что этапы, через которые проходит фича, — это не процесс. Этапы универсальны и применимы для всех, но ваш процесс — уникален. В одном процессе может быть много шагов для перехода на следующий этап, в другом — всего один. Процесс должен развиваться, адаптируясь под вашу реальность, но основные этапы остаются неизменными. Обсуждая эти этапы, мы избегаем путаницы, связанной с разными трактовками процесса.
Жизненный цикл фичи
Не стоит воспринимать иерархию в SAFe буквально. Слишком строгий подход к диаграммам может создать проблемы в управлении продуктом. Например, владелец эпика может начать диктовать решения владельцу продукта, что приведёт к конфликтам. Ответственность за продукт всегда должна лежать на менеджере по продукту.
Владелец продукта работает в тесном взаимодействии с клиентами, создавая с ними команду для сбора идей, которые затем превращаются в функции, исходя из потребностей клиентов. Главные трудности в управлении продуктом чаще связаны не с иерархией, а с волей организации. Нередко назначается доверенное лицо вместо того, кто действительно отвечает за продукт, что затрудняет коммуникацию и принятие решений.
Эпик обозначает намерение изменить бизнес, а его владелец — это тот, кто передает это намерение. Команда по управлению продуктом должна определять функции, соответствующие целям Epic, и согласовывать запросы клиентов с видением портфеля для обеспечения жизнеспособности организации.
Согласно принципу SAFe № 8, работники умственного труда лучше знают свою работу, чем руководство. Лучшие функции создаются теми, кто непосредственно работает с продуктом и клиентами. Поэтому управление продуктом должно фокусироваться на глубоком понимании своего продукта и клиента.
Владелец продукта работает в тесном взаимодействии с клиентами, создавая с ними команду для сбора идей, которые затем превращаются в функции, исходя из потребностей клиентов. Главные трудности в управлении продуктом чаще связаны не с иерархией, а с волей организации. Нередко назначается доверенное лицо вместо того, кто действительно отвечает за продукт, что затрудняет коммуникацию и принятие решений.
Эпик обозначает намерение изменить бизнес, а его владелец — это тот, кто передает это намерение. Команда по управлению продуктом должна определять функции, соответствующие целям Epic, и согласовывать запросы клиентов с видением портфеля для обеспечения жизнеспособности организации.
Согласно принципу SAFe № 8, работники умственного труда лучше знают свою работу, чем руководство. Лучшие функции создаются теми, кто непосредственно работает с продуктом и клиентами. Поэтому управление продуктом должно фокусироваться на глубоком понимании своего продукта и клиента.
Свяжитесь с клиентом
Взаимодействие с клиентом, это важный шаг в создании ценности Business Agility, и он зависит от менеджеров и владельцев продуктов.
Функции могут иметь множество клиентов, включая:
- Пользователей: как внешних, так и внутренних.
- Регуляторов: если их потребности не удовлетворены, продукт не будет принят.
- Инженеров: они являются клиентами, поскольку используют результаты своей работы для разработки новых функций.
Необходимо фокусироваться на том, как взаимодействовать с клиентами и выявлять их потребности, несмотря на то, что не существует универсального подхода ко всем клиентам. Главное — выявить потребности всех клиентов.
Знай свой продукт
Feature Driven Delivery — это полезный подход, помогающий командам сосредоточиться на создании готовых к выпуску функций, ориентированных на потребности клиентов. Однако, если просто накапливать функции без учета их взаимосвязи, это приведет к проблемам.
Бывают случаи, когда команды ориентированные на функции, могут работать быстро и минимизируют взаимодействие, их независимая друг от друга работа может привести к беспорядку в внутренней структуре продукта.
Важно иметь четкое представление о своем продукте — как с точки зрения бизнеса, так и с технической стороны. Зная, как функции вашего продукта сочетаются и взаимодействуют между собой, вы сможете лучше организовать работу. Agile Release Trains требуют сотрудничества между командами, и для этого необходима общая стратегия, которая должна разрабатываться совместно.
Бывают случаи, когда команды ориентированные на функции, могут работать быстро и минимизируют взаимодействие, их независимая друг от друга работа может привести к беспорядку в внутренней структуре продукта.
Важно иметь четкое представление о своем продукте — как с точки зрения бизнеса, так и с технической стороны. Зная, как функции вашего продукта сочетаются и взаимодействуют между собой, вы сможете лучше организовать работу. Agile Release Trains требуют сотрудничества между командами, и для этого необходима общая стратегия, которая должна разрабатываться совместно.
Знай свой продукт
Design Thinking помогает собирать идеи для функций, которые будут проработаны перед следующим PI Planning. Те функции, которые не попали в план, могут подождать. Мы определяем включенные функции с помощью дорожной карты (roadmap) или оценки скорости (velocity).
Разработка функций лучше всего происходит через совместную работу и обмен знаниями. Группа управления продуктом и владельцы продукта опрашивают заинтересованные стороны и пользователей, чтобы понять их потребности. Это позволяет владельцам продукта активно участвовать и не быть простыми посредниками.
Также важна техническая информация по архитектуре, безопасности и пользовательским интерфейсам, лучше получать эту информацию на ранних этапах разработки. Это соответствует принципу "сдвиг влево" в Agile. Владельцам продукта нужно определить, кто еще должен участвовать в разработке функции.
Сотрудничество также включает обмен знаниями между техническими специалистами и владельцами продукта, что помогает понять, когда необходимо привлечь экспертов.
Разработка функций лучше всего происходит через совместную работу и обмен знаниями. Группа управления продуктом и владельцы продукта опрашивают заинтересованные стороны и пользователей, чтобы понять их потребности. Это позволяет владельцам продукта активно участвовать и не быть простыми посредниками.
Также важна техническая информация по архитектуре, безопасности и пользовательским интерфейсам, лучше получать эту информацию на ранних этапах разработки. Это соответствует принципу "сдвиг влево" в Agile. Владельцам продукта нужно определить, кто еще должен участвовать в разработке функции.
Сотрудничество также включает обмен знаниями между техническими специалистами и владельцами продукта, что помогает понять, когда необходимо привлечь экспертов.
Дело не в словах (It’s not the Words)
Функция — это завершенная и готовая к использованию ценность, основанная на понимании потребностей клиентов. Наличие стратегии продукта помогает понять, как функция интегрируется в общий продукт.
Сотрудничество в разработке должно учитывать все точки зрения — как деловые, так и технические. Применяйте принцип SAFe № 8: раскройте внутреннюю мотивацию сотрудников.
Владельцы продуктов должны сами находить функции, которые удовлетворяют потребности бизнеса, а не полагаться на диктовку портфеля. PO также должны наделять команды полномочиями для принятия решений.
Сотрудничество в разработке должно учитывать все точки зрения — как деловые, так и технические. Применяйте принцип SAFe № 8: раскройте внутреннюю мотивацию сотрудников.
Владельцы продуктов должны сами находить функции, которые удовлетворяют потребности бизнеса, а не полагаться на диктовку портфеля. PO также должны наделять команды полномочиями для принятия решений.
Намерение, а не решение
Не говорите командам, что делать. Если вы будете ставить перед ними задачи, они не смогут думать самостоятельно. Они будут следовать инструкциям, что приведет к возрождению старых процессов без преимуществ Agile.
Необходимо дать сотрудникам возможность решать проблемы. Они должны быть не просто исполнителями, а инженерами, способными находить решения. Функции представляют собой задачи, которые нужно решить.
Функции — это «Что», а «Как» определяется через PI Planning и создание историй, которые изменяют артефакты, такие как код или документация. Это связано с принципом SAFe № 8, который подчеркивает, что работники умственного труда знают больше о своей работе, чем руководство.
Если сотрудники не знают, как работать со своими рабочими артефактами, это сигнализирует об управленческих ошибках. Принцип № 9 SAFe — децентрализация принятия решений — подразумевает, что если команды знают, как выполнять работу, им нужно дать больше свободы в принятии решений.
Необходимо дать сотрудникам возможность решать проблемы. Они должны быть не просто исполнителями, а инженерами, способными находить решения. Функции представляют собой задачи, которые нужно решить.
Функции — это «Что», а «Как» определяется через PI Planning и создание историй, которые изменяют артефакты, такие как код или документация. Это связано с принципом SAFe № 8, который подчеркивает, что работники умственного труда знают больше о своей работе, чем руководство.
Если сотрудники не знают, как работать со своими рабочими артефактами, это сигнализирует об управленческих ошибках. Принцип № 9 SAFe — децентрализация принятия решений — подразумевает, что если команды знают, как выполнять работу, им нужно дать больше свободы в принятии решений.
Для кого это?
Как уже упоминалось в разделе о «связи с клиентом», функция может обслуживать несколько категорий клиентов, а не только одного.
Важно учитывать характеристики различных категорий клиентов. В описании этих характеристик следует включать заголовок, гипотезу о преимуществах и критерии приемки.
Важно учитывать характеристики различных категорий клиентов. В описании этих характеристик следует включать заголовок, гипотезу о преимуществах и критерии приемки.
Оценка
Оценка — это в основном психология (90%) и лишь частично процесс (10%). Команды стремятся к идеальным оценкам из-за страха, вызванного прошлым опытом, когда менеджеры строго реагировали на ошибки в оценках. Оценки должны помогать командам, а не ограничивать их в рамках жестких сроков при решении сложных задач, которые изначально имеют неопределенность.
Лучший подход — повысить уверенность команды, предоставив ей возможность самостоятельно решать проблемы, а не навязывая готовые решения.
Лучший подход — повысить уверенность команды, предоставив ей возможность самостоятельно решать проблемы, а не навязывая готовые решения.
Уровень детализации
Подготовка функций, например, к PI Planning, включает исследование проблемы и определение границ допустимых решений, не устанавливая конкретное решение. Это важно, поскольку Владельцы Продукта не являются экспертами в разработке решений; эту задачу выполняют Agile-команды.
Сосредоточьтесь на понимании проблемы и потребностей клиентов, а затем передайте эту информацию команде.
Сосредоточьтесь на понимании проблемы и потребностей клиентов, а затем передайте эту информацию команде.
Зависимости
Менеджер по продукту должен обсудить внутренние зависимости и связанные функции с другими командами для их разрешения.
Связанные функции могут быть обозначены простыми метками, указывающими на соответствующие функции в бэклоге другого ART. Эти метки инициируют обсуждения между командами и побуждают их взаимодействовать для уточнения статуса зависимостей.
Также важно обсудить внешние зависимости. Начните переговоры с другой стороной как можно быстрее, когда обнаружите зависимость, чтобы включить информацию в PI Planning. Если отложить это до завершения PI Planning, останется много нерешенных рисков.
Если другая сторона зависимости не применяет Agile, возможно, не удастся договориться быстро. Вы сможете получить лишь дату, когда зависимость будет разрешена. Agile Release Train может спланировать свою работу вокруг этой даты, указав ее на доске планирования PI.
Если дата не попадает в текущий интервал планирования, функции, связанные с зависимостью, следует отложить до того момента, когда проблема будет решена.
Если информацию получить не удается, рассмотрите возможность изменения условий договора с поставщиком для улучшения сотрудничества или ищите более отзывчивого партнера.
Если проблема внутри вашей компании, необходимо изменить организационные модели поведения. Важно помнить, что все работают на одну цель, и внутренняя конкуренция мешает достижению общих целей.
Связанные функции могут быть обозначены простыми метками, указывающими на соответствующие функции в бэклоге другого ART. Эти метки инициируют обсуждения между командами и побуждают их взаимодействовать для уточнения статуса зависимостей.
Также важно обсудить внешние зависимости. Начните переговоры с другой стороной как можно быстрее, когда обнаружите зависимость, чтобы включить информацию в PI Planning. Если отложить это до завершения PI Planning, останется много нерешенных рисков.
Если другая сторона зависимости не применяет Agile, возможно, не удастся договориться быстро. Вы сможете получить лишь дату, когда зависимость будет разрешена. Agile Release Train может спланировать свою работу вокруг этой даты, указав ее на доске планирования PI.
Если дата не попадает в текущий интервал планирования, функции, связанные с зависимостью, следует отложить до того момента, когда проблема будет решена.
Если информацию получить не удается, рассмотрите возможность изменения условий договора с поставщиком для улучшения сотрудничества или ищите более отзывчивого партнера.
Если проблема внутри вашей компании, необходимо изменить организационные модели поведения. Важно помнить, что все работают на одну цель, и внутренняя конкуренция мешает достижению общих целей.
Нарезка
Функции представляют собой бизнес-потребности клиентов. Чтобы достигать больших целей, необходимо двигаться поэтапно, начиная с небольших шагов. Поэтому функции часто разбивают на более мелкие и управляемые части. Нарезка функций напоминает создание историй, но каждая нарезка должна иметь ценность и быть готовой к выпуску.
При нарезке функций следует учитывать несколько важных моментов:
- Нефункциональные требования: Не откладывайте их на потом. Они должны быть включены в функцию и считаться частью ее ценности.
- Время нарезки: Нарезку следует делать только тогда, когда вы уверены, что полученный срез станет функцией на следующем PI Planning.
- Правильный размер: Не нарезайте функции, если они уже имеют подходящий размер для планирования. Хороший размер функции — это примерно две недели работы для команды.
- Вместо разделения: Не разделяйте функции на компоненты для распределения между командами, так как это разрушает ценность.
- Тестирование: Каждый срез функции должен включать тесты, подтверждающие его работоспособность, включая сквозное и нефункциональное тестирование.
- Определение готовности (Definition of Done): Используйте его как напоминание о том, что нужно учитывать при оценке и расчете нарезок.
Часто нарезка функций производится для создания более мелких единиц ценности, с помощью Weighted Shortest Job First (WSJF).
Выводы
Ценность, которую мы выпускаем, должна удовлетворять потребности клиентов и соответствовать стратегии продукта. Она разрабатывается в сотрудничестве со всеми заинтересованными сторонами. В соответствии с Design Thinking функции рассматриваются как проблемы, которые команды должны решать, это способствует развитию креативности и самостоятельного мышления у команд.
Статья вдохновлена материалами по ссылке.