Пользовательские истории — требования или нет?

В своей книге «Agile Software Requirements» Дин Леффингуэл сделал заявление, которое сбивает с толку не только приверженцев «лёгких методологий», но и опытных аналитиков.

Заявление выглядит так:

User Stories Are Not Requirements

Пользовательские истории — это не требования

Конечно, кажется странным, зачем детально описывать что то, что не является требованиями, в книге с названием «Гибкие требования». Но давайте попробуем разобраться, что же автор на самом деле имел в виду.

У понятия «требование к ПО» много определений. Пожалуй, общепризнанным является определение IEEE:

Требование — это условие или возможность, необходимое пользователю для решения его задачи или достижения цели.

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

В книге автор поясняет (перевод взят отсюда):

Несмотря на то, что user stories играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:

• Они не являются детальным описанием требований (то есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого)
• Они являются короткими и легко читаемыми, понятными разработчикам, стейкхолдерам и пользователям
• Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель
• Они относительно легко поддаются оценке, таким образом, усилия, необходимые для реализации, могут быть быстро определены
• Они не занимают огромных, громоздких документов, а скорее организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации
• Они не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок», что позволяет избегать слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения
• Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации.

И в этом перечне «тонких различий» мы не видим абсолютно ничего, что противоречило бы традиционному определению требований. Разве что самое первое утверждение заставляет вспомнить, что требования бывают разного уровня детализации. А все остальные больше похожи на борьбу с воображаемыми призраками: в каждом видится противопоставление каким-то ужасным методам разработки требований «по-старому», создающим множество проблем.

Неужели Дин Леффингуэл поддался веянию, характерному для некоторых адептов Agile: максимально дистанцироваться от накопленного до Agile опыта разработки, объявив всё старое плохим и неэффективным? Но он не был замечен в таком экстремизме, да и во всей книге это единственный момент подобного противопоставления.

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

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

Давайте посмотрим на эти критерии повнимательнее. В интернете можно найти разные перечни критериев хороших требований, но все они похожи друг на друга. Возьмём, например, список отсюда.

Опыт показывает, что наилучшим требованием считается такое, которое может быть охарактеризовано как:

• Корректное (с технической и юридической точек зрения)
• Полное (выражает утверждение или законченную идею)
• Четкое, однозначное (недвусмысленное и не сбивающее с толку)
• Совместимое, согласующееся (не конфликтующее с другими требованиями)
• Проверяемое (чтобы подтвердить, что результат соответствует требованию)
• Трассируемое (уникально идентифицированное и отслеживаемое)
• Выполнимое (может быть реализовано в рамках запланированного бюджета и сроков)
• Модульное, блочное (может быть изменено без чрезмерных последствий для всего проекта)
• Инженерно-независимое (не должно содержать описания конкретного решения)

Похоже, что пользовательские истории соответствуют не всем перечисленным критериям. Давайте возьмём один из примеров из книги Майка Кона «User Stories Applied: For Agile Software Development» и посмотрим, насколько он им соответствует.

Пользователь может просмотреть информацию о каждой вакансии, представленной в результатах поиска.

Пройдёмся по списку.

Корректно ли это требование? С технической точки зрения — наверное, да. С юридической точки зрения оно не может быть корректным или некорректным по определению: пользовательские истории не должны рассматриваться как договорные обязательства.

Можно ли назвать это требование полным? Не похоже. Например, о какой информации идёт речь? Майк Кон предлагает решить эту проблему добавлением уточняющих заметок вроде «Марко говорит, что нужно показывать описание, уровень зарплаты и город».

Чётко и однозначно ли оно? Это трудный вопрос. С одной стороны, цель пользователя выражена достаточно однозначно. Для разработчика контекст очевиден: он знает, что разрабатывает сайт для поиска работы, и сразу представляет себе, о чём идёт речь и как может выглядеть результат. С другой стороны, опытный аналитик знает, что нельзя полагаться на то, что кажется очевидным, и может задать массу уточняющих вопросов.

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

Вопрос совместимости с другими требованиями пропустим, потому что мы в данном случае о них ничего не знаем.

Проверяемо ли требование? Этот критерий тесно связан с критерием полноты: если требование неполно, то непонятно, как проверять его выполнение. Но для пользовательских историй используется особая практика выполнения этого критерия: в их состав включаются приёмочные тесты. При этом они не столько играют роль традиционных тест-кейсов, сколько фактически являются уточнёнными требованиями, так как используются в первую очередь разработчиками, а не тестировщиками.

Вердикт: мы считаем критерий проверяемости выполненным только после того, как в пользовательскую историю включены приёмочные тесты, являющиеся неотъемлемой частью требований. Это очень не похоже на традиционный подход, по которому тесты разрабатываются отдельно от спецификации требований, и вокруг них выстраиваются собственные процессы.

Трассируемость является не столько свойством самих требований, сколько особенностью процессов (или практик) и возможностью инструментов, используемых для работы с ними. Пропустим этот критерий, чтобы не уходить в сторону от темы.

Критерий выполнимости «в рамках бюджета и сроков» в традиционном виде вообще неприменим в Agile. Этот критерий нужен для того, чтобы в спецификацию не попадали требования, которые при реализации сорвут график или сломают бюджет проекта.

Этот критерий призван бороться с двумя рисками. Первый состоит в том, что некоторые требования могут оказаться в принципе нереализуемыми в рамках создаваемого продукта. Это чаще всего нефункциональные требования, к которым пользовательские истории не относятся.

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

Критериям модульности и независимости наша история вполне соответствует.

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

Всё это означает, что накопленный опыт может оказать медвежью услугу аналитику, если он попытается применять его в условиях Agile-разработки. Я думаю, именно эту мысль и хотел передать Дин Леффингуэл в своём заявлении. И, наверное, это одна из причин неприятия «старой гвардией» всё шире распространяющихся Agile-подходов.