День 1914. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 6. Agile-требования не отличаются от других. Окончание
Начало

5. Итоговое оформление требований
В общем случае пользовательские истории похожи на сценарии использования. Разница лишь в том, насколько тщательно вы их детализируете и записываете ли информацию. В традиционном проекте бизнес-аналитик может разработать набор функциональных требований на основе сценариев использования. Agile-команды конкретизируют каждую пользовательскую историю, определяя критерии приёмки и тесты, которые покажут, правильно ли разработчики реализовали её.
Функциональные требования и соответствующие им тесты — альтернативные варианты представления одной и той же информации. Требования определяют, что создавать; тесты описывают, как выяснить, демонстрирует ли система ожидаемое поведение. Наилучшие результаты получаются, когда разные люди пишут требования и тесты на основе одного и того же источника информации, например сценария использования.
Можно прибегнуть к альтернативной стратегии — записывать детали пользовательской истории в форме приёмочных тестов, которые затем проверяет тестировщик. Когда создаётся несколько представлений требований, нестыковки между ними помогают выявить проблемы. Если вы создаёте только одно представление, то независимо от выбранного метода будете вынуждены доверять его точности.

6. Расстановка приоритетов
Расстановка приоритетов учитывает относительную ценность каждого требования для клиента по сравнению с усилиями, риском и стоимостью его реализации. Традиционные проекты могут определить приоритеты требований на раннем этапе и в дальнейшем почти не пересматривать их. В Agile-проекте задачи приоритизируются непрерывно. Вы должны постоянно выбирать, что добавить в ближайшие итерации, а что может быть вообще исключено. На самом деле все команды, а не только те, кто практикует Agile, должны управлять оставшимися задачами, чтобы как можно быстрее передать клиенту максимально ценный для него продукт.

Есть ли разница?
Большинству клиентов неинтересно, как создаются приложения. Они хотят, чтобы продукты отвечали их потребностям, были эффективными, удобными и легко расширяемыми, а также удовлетворяли другие ожидания в отношении качества. Большинство методов разработки требований и управления ими в традиционных проектах в равной степени применимы и к Agile-проектам. Любая команда должна адаптировать методы разработки, чтобы они соответствовали их целям, культуре, среде и ограничениям.

В Agile всякое изменение добавляет независимую часть функциональности. Продукт — это система, которую вы итеративно совершенствуете, извлекая уроки из неудачных изменений и отыскивая лучшие способы реализации каждой его части. Выделение небольших требований, каждое из которых определяет ограниченное и функционирующее изменение, — совсем другой вид анализа, отличающийся от дробления большого интегрированного решения на фрагменты, вписывающиеся в итерации разработки.

Процесс бизнес-анализа в Agile-проектах тоже несколько иной. Несмотря на то, что устаревшие методы бизнес-анализа все ещё находят применение (анализ заинтересованных сторон и бизнес-правил, моделирование процессов и многое другое), их интеграция в поэтапный гибкий процесс оказывается большой проблемой для многих бизнес-аналитиков.

Успешный переход требует развития нового мышления. Роль бизнес-аналитика в Agile-проекте заключается не столько в том, чтобы заранее определить, что будет сделано, сколько в постоянном пересмотре условий в процессе разработки. Происходит постоянная оценка того, что должна или не должна делать команда, — компромиссов, необходимых для максимизации доставляемой ценности.

Однако в целом сведения о требованиях, используемые в Agile-проекте, качественно не отличаются от сведений в традиционном проекте. Разработка требований по-прежнему сводится к выявлению и передаче точной информации, чтобы участники проекта могли благополучно создать определённую часть продукта.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.