Аналитик · практикум · Развитие

Пользовательские истории против вариантов использования (User Stories Versus Use Cases)

Статья — участник конкурса от ITWorks!

Источник: https://www.bridging-the-gap.com/user-stories-use-cases/

Автор:  Laura Brandenburg

Вольный перевод: Анна Гасраталиева

От переводчика: на нашем практикуме в ITWorks начинающие аналитики постоянно спрашивают “Зачем нам эти варианты использования? Все уже давно пишут истории!” или “А мы должны и истории и сценарии писать? Чем они отличаются?”

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

  • Пользовательские истории — User Stories (в переводе будут сокращаться до US или “истории”)
  • Варианты использования (в русскоязычных статья достаточно хорошо прижилось сокращение ВИ) — прецеденты, сценарии использования, Use Cases (в переводе будут сокращаться до US или “сценарии”)

(строго говоря, сценарии и варианты использования это не совсем одно и то же, но мы оставим это за рамками статьи)

Итак, поехали.

Пользовательские истории против вариантов использования

(User Stories Versus Use Cases)

Если ваша команда работает по agile, пишете ли вы истории, сценарии или и то, и другое? Мое мнение (Лора — прим.переводчика), что пока вы не умеете думать сценариями, нужно писать их, чтобы убедиться, что вы имеете полное четкое представление о функциональных требованиях. Даже в agile команде. Вот почему мы продолжаем преподавать Use cases в качестве основного, фундаментального навыка в “Bridging the Gap” (название компании Лоры — при. переводчика).

(И просто напоминаю о том, что наш курс  Use Cases and Wireframes  был обновлен, расширен до 12 кредитов и теперь доступен по требованию. Более того, если вы присоединитесь сегодня, то получите доступ к 3 бонусным вебинарам по agile бизнес-анализу, где мы будем освещать важные темы, которые помогут вам добиться успеха в гибких преобразованиях, включая гибкое владение продуктом и гибкие методы анализа)

 

UC против US — обдумывание против обсуждения

UC используются на протяжении буквально нескольких десятилетий. Если бы я застряла на необитаемом острове и вы заставили бы меня выбрать всего один инструмент аналитика для описания требований, я бы выбрала именно их. UC — это самый первый инструмент, который я узнала; первая техника, которой я научилась; первый способ анализировать и документировать функциональные требования, с которым я познакомилась. Я убеждена, что являюсь сильным аналитиком из-за того фокуса, который получила  в начале своей карьеры, и из-за того, сколько UC я написала.

Это вовсе не означает, что я не могу писать пользовательские истории в рамках agile —  иногда их даже легче писать, чем UC.

Позвольте мне подробнее рассказать о том, как UC и US работают вместе, и почему я считаю, что UC так важны.

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

В этом процессе, в процессе продумывания и описания вашего UC, вам придется

использовать правильный язык, избегать пассивного залога (это очень важно — прим. переводчика), избегать употребления “перед этим” и “после этого”, двигаться пошагово и четко излагать последовательность действий, строго используя корректную терминологию.

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

Этот мыслительный процесс имеет решающее значение, особенно для начинающих аналитиков. Именно попытка выяснить:

  • что я должен поместить в свои пользовательские истории?
  • они закончены?
  • разве этого достаточно?
  • как они связаны между собой?

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

Именно в этом ценность Use cases, и именно поэтому я думаю, что они так важны (особенно начинающим аналитикам в процессе обретения навыков), даже когда мы движемся к более гибким средам разработки программного обеспечения.

 

Варианты использования и пользовательские истории – действительно ли мне нужно писать и то, и то?

Любопытно, что старшие аналитики часто говорят “Ну, Лора, на самом деле ты же не считаешь, что я должен написать UC, а затем разбивать их на пользовательские истории?»

Да, будучи старшим аналитиком (написавшем сотни UC, как и я) вам, вероятно, не всегда нужно писать вариант использования. Вы делали это так много раз, что можете думать об этом почти бессознательно.

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

Новоиспеченному аналитику будет трудно сесть и погрузиться в это состояние. Вот почему мы в “Bridging the Gap” до сих пор учим использовать UC; почему я думаю, что это так сильно важно; и почему мы видим, что у люди говорят «о, так вот как мне нужно указать требования к программному обеспечению!». Так я придумываю вопросы, которые даже не знала, что должна задать. Именно так я могу быть уверена, что не пропустила важных требований. Это важно для уверенности и развития навыков начинающего аналитика. Это фокусирует наше внимание на прецедентном мышлении (мышлении юзкейсами — прим. переводчика).

Это вовсе не означает, что пользовательские истории не важны. Я думаю, что сейчас во многих компаниях, если вы работаете с agile-командой разработки, то собираетесь разбить вариант использования на пользовательские истории. Совсем недавно мы переиздали наш курс «Use Cases and Wireframes course», и мы добавили урок о пользовательских историях, чтобы поговорить об этом процессе.

Может быть вы —  опытный аналитик, который пишет UC и пользовательские истории, или думает в UC и пишет пользовательские истории. А может, что более вероятно, вы все еще находитесь в более традиционной итеративной среде, которая пока недостаточно гибкая. Возможно вы просто пишете пользовательские истории — которые тоже хороши, пока вы работаете в этом итеративном отзывчивом режиме совместной работы (речь про agile-процесс — прим. переводчика), а не в водопаде, где шаг, еще шаг, затем следующий шаг, и передача, перебрасывание задач туда-сюда (часто это называют пинг-понгом — прим. переводчика). Истории — это отличный способ быть на одной волне с вашей командой (совместное общение, итеративность процесса и уверенность, что все одинаково понимают требования).

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

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

Итак, я Лора Бранденбург из “Bridging the Gap”. Что бы вы ни писали — UC или US —  я снимаю перед вами шляпу за то, что вы аналитик. Спасибо, что вы здесь.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *