(ссылка на оригинальную статью)
Инженерия требований – важнейшая часть разработки каждого программного продукта, вне зависимости от того, как вы подходите к управлению продуктами и их разработке. Качество вашей работы с инженерией требований и ее результаты напрямую влияют на неудачу или успех вашего подхода к управлению продуктами в проекте.
Здесь вопрос в том, как можно применить новое мышление, принципы, методы в Agile-среде управления продуктами. Что ж, самый верный и подходящий ответ на этот вопрос – это мост между инженерией требований и Agile. В это статье вы узнаете о мифах и реальности относительно инженерии требований в Agile-среде и о том, как извлечь из этого выгоду, создав мост между ними.
Существует множество мифов и заблуждений, связанных с инженерией требований и Agile. В этом разделе мы поговорим о распространенных мифах, которые, вы, возможно, ежедневно слышите в своих командах и компаниях. Давайте же рассмотрим их.
Миф 1: В Agile-среде не может быть авансов
Часто даже в зрелых продуктовых командах есть миф о том, что если вы хотите следовать Agile, то стоит забыть о любых предварительных активностях. Для реального мира Agile – это ошибочное суждение. Вам необходимо пройти несколько подготовительных этапов (например, разработать концепцию продукта), чтобы создать компас, который будет задавать курс разработке. Помимо написания кода и тестирования, вы можете формировать и использовать инженерию требований в Agile-итерациях.
Миф 2: Инженерия требований – это бумажная работа
Многие люди, работающие над продуктом, по-прежнему считают инженерию требований чем-то подобным документированию. Инженерия требований состоит из четырех ключевых деятельности: выявление, документация, согласование/проверка и управление. Профессиональные специалисты обеспечивают дисциплину для систематического выполнения повторных действий с Agile-подходом в различных итерациях. Помимо этого, обратите внимание, что каждая часть документации должна преследовать определенную цель. Если вы хотите задокументировать свои требования, целью может стать обеспечение соблюдения законодательства, сохранение ценной информации, содействие коммуникации или поддержка мыслительных процессов.
Миф 3: Пользовательских историй вполне достаточно
Команды Agile-продуктов, особенно те, которые работают по Scrum, привыкли работать с пользовательскими историями. В связи с тем, что Scrum – это фреймворк, он не предписывает и не обязывает команду использовать определенную технику для описания потребностей пользователя.
Таким образом, правда в том, что пользовательских историй во многих случаях оказывается недостаточно для описания каждого аспекта пути пользователя, текущего опыта, идеального будущего опыта, проблем, выгод и того, как превратить их в достаточно хорошую формулировку требований.
Реальность: Инженерия требований в Agile-среде
Когда продуктологи говорят об инженерии требований в Agile-средах, они почти всегда используют термин «Agile-инженерия требований». На самом деле, такое мышление неверно. Инженерия требований – совершенно отдельная дисциплина. У нее есть своя собственная философия, свои принципы и множество методологий. Поэтому вместо «Agile-инженерии требований» лучше использовать «Инженерию требований в Agile» или то, что IREB называют RE@Agile. В Agile-среде продуктологи должны рассматривать инженерию требований как непрерывный процесс. То есть это не просто набор предварительных подготовительных действий.
На самом деле, это комбинация предварительных и непрерывных действий во время итерации. Некоторые примеры предварительных действий в инженерии требований в Agile включают в себя определение видения продукта, бизнес-целей высокого уровня, выявление стейкхолдеров и области применения продукта. Кроме того, во время итерации все работы по инженерии требований будут выполняться продуктологами. Они будут включать в себя выявление требований, документацию, согласование/проверку и управление.
Применение этих основных видов деятельности – в основном работа владельца продукта или менеджера продукта. Но в этом должна участвовать команда, чтобы у вас получились хорошие и ориентированные на человека требования для разработки.
Для выявления требований в Agile продуктологи пользуются широким спектром методов. Например:
Качественные и количественные интервью;
Опросы;
Методы наблюдения;
Методы, основанные на артефактах (т. е. переиспользование, системная археология);
Креативные методы (например, Дизайн-мышление, Дизайн-Спринт).
Эти методы отвечают идее требований в формате пользовательских историй или Jobs-to-be-done, что является основой для структурированного обсуждения, а не предписанием для реализации.
Прежде чем документировать требования, вы должны определить цель каждого документа. В мире Agile документация рассматривается, как важнейшая деятельность, способствующая взаимодействию между разработчиками и стейкхолдерами. Рассматривайте документацию как непрерывную активность, где документы создаются для одной из следующих целей:
Юридические цели;
Цели безопасности;
Коммуникационные цели;
Мыслительные цели.
Когда вы определяете назначение документации, можно изучить методы и артефакты инженерии требований и Agile, чтобы за итерацию создать четкий и понятный документ.
Основной целью проверки и согласования требований является выявление конфликтов в требованиях, а также выявление отсутствующих, неоднозначных и неправильных требований. Agile основывается на эмпиризме и в особую важность имеют исследование и адаптация. Такое мышление позволяет создателям продуктов постоянно проверять обоснованность требований и адаптировать бэклог, основываясь на новых результатах. Agile-методы стремятся валидировать требования с помощью ранней и частой обратной связи о ценных инкрементах продукта, что помогает разработчикам сохранить время и ресурсы при разработке требований и получении результатов.
В отличие от традиционного управления требованиями, продуктологи используют бэклоги для хранения только последней и лучшей версии всех требований, которые должны быть реализованы в рамках итерации. Мероприятия по управлению требованиями, которые необходимо учитывать в бэклоге, включают в себя:
Определение приоритетов требований:
Продуктологи стараются любым способом расставлять приоритеты, основываясь на бизнес-ценности. Здесь ценность является наиболее важным аспектом, который и определяет расстановку приоритетов. Матрица Impact-Effort и MoSCoW – два распространенных метода определения приоритетов требований в Agile.
Оценка требований:
Agile-оценка – это не прогноз. Скорее наилучшее предположение, которое есть у разработчиков по отношению к какому-либо элементу невыполненной работы, который должен быть рассмотрен как завершенный. Поинты User Story и маечная система – два вида методов оценки, которые можно использовать в RE@Agile.
Все упомянутые виды деятельности, включая выявление, документирование, проверку/согласование и управление, необходимо учитывать в Agile-среде управления продуктами и разработкой. Выбор правильной техники для выполнения этих действий полностью зависит от менеджеров продукта и Agile-команды разработки, и в нем нужно отталкиваться от объема продукта, контекста, а также возможностей команды.
Перевод подготовлен в рамках старта набора на курс "Agile Project Manager".
(ссылка на оригинальную статью)
Всех желающих приглашаем на открытый урок «Как сделать ретроспективу в Agile полезной». На этом вебинаре разберём популярные заблуждения о ретроспективах и поговорим про набор полезных практик, чтобы команда радостно ждала нового ретро. Проведем очень иллюстративное упражнение для углубления понимания. Бонусом поговорим про более олдскульные практики проектного управления, которые помогут управлять ожиданиями.