Сравнение методов разработки пользовательских требований

Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.

Мы с вами познакомились с несколькими методами разработки пользовательских требований. На самом деле, методов было два: это Use cases (юзкейсы) и User stories. И плюс дополнительный метод — наверное, не столько разработки, сколько выявления пользовательских требований: персонажи. По-английски он называется Personas, а на русский язык его обычно переводят как «персоны» или «персонажи».

У нас была сравнительная табличка, когда мы сравнивали ролевые модели методов Use cases и User stories. Я здесь добавил ещё одну табличку. Иногда возникает вопрос: какой метод лучше применим в нашем проекте, каким из них воспользоваться? Для того, чтобы эту оценку правильно сделать, нужно сравнить их достоинства и недостатки. Мы о них говорили достаточно много в процессе курса, начиная с самых первых вебинаров, и более детально, когда мы изучали эти методы. Здесь, на этой табличке, подведен итог.

Если сравнивать юзкейсы и user stories, то, первое и, наверное, самое существенное отличие состоит в том, что метод юзкейсов требует достаточно долгой фазы предварительного анализа для проработки целей, которые мы будем автоматизировать, и разработки сценариев. То есть он приближает нас в чём-то к водопаду. Конечно, их тоже можно разрабатывать итерационно, но, тем не менее, в каждой итерации нужна отдельная большая работа аналитиков для того, чтобы эти юзкейсы для очередной итерации подготовить. Поэтому в тех местах, где используются юзкейсы как метод, итерации довольно длинные. От одного месяца до максимум трёх месяцев (если итерация длится больше 3 месяцев, то уже само понятие итерации утрачивает свой смысл). Но это не недельные или двухнедельные спринты, как в Agile. Это связано с тем, что здесь всё-таки требуется более глубокий и детальный анализ.

Отличие user stories в том, что, как правило, этот формат можно применять практически сразу. Не погружаясь в детализацию, потому что сам формат предполагает, что он будут использоваться для дальнейшего обсуждения. То есть мы сначала user story формулируем достаточно коротко, обсуждаем с заказчиком, и затем в команде обсуждаем детальную реализацию. И поэтому он такой, более лёгкий, более быстро его можно использовать в коротких итерациях, чем, собственно, практически все Agile-подходы и пользуются.

Второе отличие в том, что юзкейсы — это очень много текста, мы об этом тоже говорили. Каждый сценарий нужно описать, причём написать ещё массу альтернативных. Их надо хранить, ими нужно управлять, у них меняются версии. Они формируют модель продукта, и может оказаться в какой-то момент, что модель с этим продуктом расходится, потому что в юзкейсе написано одно, а в продукте реализовано другое. Это создаёт проблему сопровождения, в отличие от Agile-подходов, где применяются user stories. В самом радикальном варианте после реализации историю нужно выбрасывать, чтобы она нигде не хранилась. Но, в общем, даже если вы где-то её храните, она такого бремени сопровождения не создаёт.

Различия в модели требований, о которой мы тоже говорили с самого начала. Юзкейсы предполагают, что мы создаём практически полное описание нашего продукта в терминах юзкейсов, за исключением, может быть, каких-то его нефункциональных аспектов, которые не описываются сценариями. А user stories — это постоянно меняющаяся модель продукта. То есть мы каждый раз сосредотачиваемся именно на том, что нужно сделать в данный момент.

По поводу хороших требований. Мы, опять же, в начале курса говорили, что для user stories разработан фактически свой способ оценки качества историй: INVEST. А для юзкейсов применяется другой метод, больше похожий на те, что изначально было сформулированы для требований при их разработке в виде спецификации. Главное отличие — это полнота требований. Не буду повторяться, я просто подвожу итог: критерии качества для юзкейсов и user stories различаются, и я надеюсь, что у вас уже сложилось представление о том, почему это так, и почему не нужно набор критериев качества одного метода применять к другому.

И очень важное различие, которое иногда неочевидно для аналитиков, состоит в том, что при разработке юзкейсов большую часть работы выполняют те, кто разрабатывают сценарии, и эти юзкейсы потом можно как полную модель продукта передавать в команду, чтобы они их программировали. В случае с user story формат сам по себе — это только повод для обсуждения, и самые важные решения о реализации, о том, как эти user stories правильно реализовать в продукте, принимает команда разработки. Это её неотъемлемое право, и ей нельзя навязать какие-то определенные методы.

Это, наверное, самое важное различие, из-за которого чаще всего, может быть, возникают недоразумения при попытке использовать определенный метод в другой среде. Каогда юзкейсы пытаются навязать Agile-команде, а у команды есть свои представления о том, как что-то должно быть реализовано. Или другой вариант, когда мы пытаемся использовать User stories в незрелых командах, где команда разработчиков не вполне ещё понимает, как устроен продукт, и что в нём надо реализовать. Например, в сложной банковской системе метод user stories вряд ли будет работать, потому что требования, передаваемые команде разработки, должны уже содержать проанализированные и обработанные знания, которыми сама команда не владеет. Они находятся обычно в головах бизнес-аналитиков и системных аналитиков.

Глядя на этот список, может быть, вы теперь более чётко представляете, в какой ситуации какой метод применим. По итогам курса это представление должно у вас уже окончательно сложиться: для каких ситуаций какие методы лучше подходят.

Можно сказать, что Agile-подходы явились вызовом для традиционных средств разработки. И один из отцов-основателей или авторов концепции Use cases, Айвар Якобсон, а вместе с ним соавторы, перечисленные в списке, заявили что юзкейсы хоронить ещё рано, и что они вполне применимы и в Agile-условиях. Они по этому поводу написали целую книжку небольшую: Use-case 2.0. Это электронная книга, которую вы свободно можете скачать с сайта Якобсона.

Что в этой книге предлагается? Как адаптировать метод юзкейсов для разработки в коротких итерациях, которыми, в первую очередь, и отличается Agile. Я несколько картинок просто приведу, потому что в двух словах объяснить это довольно просто. Ну, а если придётся применять это на практике, тогда, собственно, вот в этой книге и написано, как это лучше сделать. Сам Айвар Якобсон периодически проводит вебинары, на которых объясняет разные нюансы и суть этого метода.

Суть, в общем-то, довольно проста, и состоит она в том, что разработанный юзкейс в виде основного и альтернативных сценариев вполне можно реализовывать итерационно, и он для этого вполне предназначен. Юзкейс нарезается на так называемые слайсы (по-русски дольки). Сначала мы разрабатываем весь юзкейс, а потом его последовательно, дольками, реализуем. В первой итерации, например, реализуем только основной сценарий. Во второй итерации мы реализуем два-три дополнительных сценария. А, собственно, выбор того, какие части юзкейса нам нужно реализовать, делается на этапе планирования очередной итерации (в случае со скрамом — очередного спринта) таким же образом, как обсуждаются user stories. То есть после того, как сценарий описан, мы вполне можем его оценить методами Agile, включить часть юзкейса в бэклог (наиболее важную, которая принесет наибольшую ценность в очередной итерации), и потом эти слайсы наравне с userstories и другими форматами требований могут включаться в бэклог итерации.

Эту картинку я взял из интернета, с сайта одной компании, которая занимается популяризацией этого метода и представляет для этого какой-то инструмент. Здесь просто визуально показано, что при этом происходит. Когда мы формируем бэклог продукта, мы разрабатывают требования в разных форматах — функции (фичи), эпики (большие user stories), юзкейсы и слайсы. В бэклог релиза включаются user stories и слайсы, а потом команды уже сами их приоритезируют, выбирая на каждом спринте те кусочки, которые нужно реализовать. Я думаю, принцип этот понятен. В книге это более широко описано, хотя книга сама по себе небольшая. К сожалению, перевода на русский язык, по-моему, нет до сих пор.

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

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

Вот ещё одна табличка. Эта табличка у нас в курсе уже была, но я добавил в неё третью колонку. Здесь подытожено различие ролевых моделей при использовании юзкейсов, user stories и метода персонажей.

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

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

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

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

По поводу персон можно сказать, что это дальнейшее развитие метода user stories. Главная особенность или отличие в том, что персонажи появляются по результатам достаточно серьёзных исследований. Это, конечно, оправданно только в случае, если чёткое выделение этих персон даёт вам какую-то понятную выгоду при создании вашего продукта. Алан Купер постоянно говорит: если вы придумали персон без исследования, то это, скорее всего, будут стереотипы пользователей, что больше похоже на предыдущий вариант ролей в user stories.

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