Пользовательские истории против вариантов использования
User Stories Versus Use Cases
User Stories Versus Use Cases
Начинающие аналитики постоянно спрашивают «Зачем нам эти варианты использования? Все уже давно пишут истории!» или «А мы должны и истории и сценарии писать? Чем они отличаются? Что более высокоуровнево?»
Я планировала написать свою статью по этой теме, чтобы не объяснять это каждый раз, но тут наткнулась на статью от Лоры, которая достаточно четко выразила главную причину, почему так важно понять оба инструмента. В переводе ее статьи я буду использовать сокращение UC и US, но если вы все еще путаетесь в этих терминах, то вот расшифровка:
Итак, поехали.
Источник: https://www.bridging-the-gap.com/user-stories-use-cases/
Автор: Laura Brandenburg
Вольный перевод: Анна Гасраталиева
Я планировала написать свою статью по этой теме, чтобы не объяснять это каждый раз, но тут наткнулась на статью от Лоры, которая достаточно четко выразила главную причину, почему так важно понять оба инструмента. В переводе ее статьи я буду использовать сокращение UC и US, но если вы все еще путаетесь в этих терминах, то вот расшифровка:
- Пользовательские истории — User Stories (в переводе будут сокращаться до US или «истории»)
- Варианты использования (в русскоязычных статья достаточно хорошо прижилось сокращение ВИ) — прецеденты, сценарии использования, Use Cases (в переводе будут сокращаться до US или «сценарии»)
Итак, поехали.
Источник: https://www.bridging-the-gap.com/user-stories-use-cases/
Автор: Laura Brandenburg
Вольный перевод: Анна Гасраталиева
Пользовательские истории против вариантов использования
User Stories Versus Use Cases
Если ваша команда работает по agile, пишете ли вы истории, сценарии или и то, и другое? Мое мнение (Лора — прим. переводчика), что пока вы не умеете думать сценариями, нужно писать их, чтобы убедиться, что вы имеете полное четкое представление о функциональных требованиях. Даже в agile команде. Вот почему мы продолжаем преподавать Use cases в качестве основного, фундаментального навыка в «Bridging the Gap» (название компании Лоры — при. переводчика).
UC против US — обдумывание против обсуждения
UC используются на протяжении буквально нескольких десятилетий. Если бы я застряла на необитаемом острове и вы заставили бы меня выбрать всего один инструмент аналитика для описания требований, я бы выбрала именно их. UC — это самый первый инструмент, который я узнала; первая техника, которой я научилась; первый способ анализировать и документировать функциональные требования, с которым я познакомилась. Я убеждена, что являюсь сильным аналитиком из-за того фокуса, который получила в начале своей карьеры, и из-за того, сколько UC я написала.
Это вовсе не означает, что я не могу писать пользовательские истории в рамках agile — иногда их даже легче писать, чем UC.
User Stories Versus Use Cases
Если ваша команда работает по agile, пишете ли вы истории, сценарии или и то, и другое? Мое мнение (Лора — прим. переводчика), что пока вы не умеете думать сценариями, нужно писать их, чтобы убедиться, что вы имеете полное четкое представление о функциональных требованиях. Даже в agile команде. Вот почему мы продолжаем преподавать Use cases в качестве основного, фундаментального навыка в «Bridging the Gap» (название компании Лоры — при. переводчика).
UC против US — обдумывание против обсуждения
UC используются на протяжении буквально нескольких десятилетий. Если бы я застряла на необитаемом острове и вы заставили бы меня выбрать всего один инструмент аналитика для описания требований, я бы выбрала именно их. UC — это самый первый инструмент, который я узнала; первая техника, которой я научилась; первый способ анализировать и документировать функциональные требования, с которым я познакомилась. Я убеждена, что являюсь сильным аналитиком из-за того фокуса, который получила в начале своей карьеры, и из-за того, сколько UC я написала.
Это вовсе не означает, что я не могу писать пользовательские истории в рамках agile — иногда их даже легче писать, чем UC.
Позвольте мне подробнее рассказать о том, как UC и US работают вместе, и почему я считаю, что UC так важны.
Когда вы работаете над UC и продумываете один из них, вы продумываете, как пользователь и система взаимодействуют друг с другом. Вы также думаете о том, где именно могут происходить изменения, где могут происходить исключения, что должно случиться, прежде чем начнется выполнение UC и что будет по его завершению.
В этом процессе, в процессе продумывания и описания вашего UC, вам придется
использовать правильный язык, избегать пассивного залога (это очень важно — прим. переводчика), избегать употребления «перед этим» и «после этого», двигаться пошагово и четко излагать последовательность действий, строго используя корректную терминологию.
Пройдя через все это вы вдруг обнаруживаете, что всплыли вопросы, о которых вы раньше не думали, а также появляются все новые и новые требования.
Этот мыслительный процесс имеет решающее значение, особенно для начинающих аналитиков. Именно попытка выяснить:
- что я должен поместить в свои пользовательские истории?
- они закончены?
- разве этого достаточно?
- как они связаны между собой?
Варианты использования и пользовательские истории — действительно ли мне нужно писать и то, и то?
Любопытно, что старшие аналитики часто говорят «Ну, Лора, на самом деле ты же не считаешь, что я должен написать UC, а затем разбивать их на пользовательские истории?»
Да, будучи старшим аналитиком (написавшем сотни UC, как и я) вам, вероятно, не всегда нужно писать вариант использования. Вы делали это так много раз, что можете думать об этом почти бессознательно.
Когда вы пишете свои пользовательские истории из всего потока функциональности, то все равно думаете о UC, и у вас есть все, что нужно, потому что все это — в вашей голове. Это работает, когда вы делали это в течение некоторого времени, когда вы уверены в своих навыках и когда у вас есть другие способы управления такого рода информацией.
Новоиспеченному аналитику будет трудно сесть и погрузиться в это состояние. Вот почему мы в «Bridging the Gap» до сих пор учим использовать UC; почему я думаю, что это так сильно важно; и почему мы видим, что у люди говорят «о, так вот как мне нужно указать требования к программному обеспечению!». Так я придумываю вопросы, которые даже не знала, что должна задать. Именно так я могу быть уверена, что не пропустила важных требований. Это важно для уверенности и развития навыков начинающего аналитика. Это фокусирует наше внимание на прецедентном мышлении (мышлении юзкейсами — прим. переводчика).
Любопытно, что старшие аналитики часто говорят «Ну, Лора, на самом деле ты же не считаешь, что я должен написать UC, а затем разбивать их на пользовательские истории?»
Да, будучи старшим аналитиком (написавшем сотни UC, как и я) вам, вероятно, не всегда нужно писать вариант использования. Вы делали это так много раз, что можете думать об этом почти бессознательно.
Когда вы пишете свои пользовательские истории из всего потока функциональности, то все равно думаете о UC, и у вас есть все, что нужно, потому что все это — в вашей голове. Это работает, когда вы делали это в течение некоторого времени, когда вы уверены в своих навыках и когда у вас есть другие способы управления такого рода информацией.
Новоиспеченному аналитику будет трудно сесть и погрузиться в это состояние. Вот почему мы в «Bridging the Gap» до сих пор учим использовать UC; почему я думаю, что это так сильно важно; и почему мы видим, что у люди говорят «о, так вот как мне нужно указать требования к программному обеспечению!». Так я придумываю вопросы, которые даже не знала, что должна задать. Именно так я могу быть уверена, что не пропустила важных требований. Это важно для уверенности и развития навыков начинающего аналитика. Это фокусирует наше внимание на прецедентном мышлении (мышлении юзкейсами — прим. переводчика).
Это вовсе не означает, что пользовательские истории не важны. Я думаю, что сейчас во многих компаниях, если вы работаете с agile-командой разработки, то собираетесь разбить вариант использования на пользовательские истории. Совсем недавно мы переиздали наш курс «Use Cases and Wireframes course», и мы добавили урок о пользовательских историях, чтобы поговорить об этом процессе.
Может быть вы — опытный аналитик, который пишет UC и пользовательские истории, или думает в UC и пишет пользовательские истории. А может, что более вероятно, вы все еще находитесь в более традиционной итеративной среде, которая пока недостаточно гибкая. Возможно вы просто пишете пользовательские истории — которые тоже хороши, пока вы работаете в этом итеративном отзывчивом режиме совместной работы (речь про agile-процесс — прим. переводчика), а не в водопаде, где шаг, еще шаг, затем следующий шаг, и передача, перебрасывание задач туда-сюда (часто это называют пинг-понгом — прим. переводчика). Истории — это отличный способ быть на одной волне с вашей командой (совместное общение, итеративность процесса и уверенность, что все одинаково понимают требования).
Я хотела поделиться своими мыслями о UC и пользовательских историях и услышать ваши мысли. Ниже вы найдете споры по этой теме в рамках профессии аналитика, а также в рамках agile-сообщества. Это очень важная тема. Я думаю, нам нужно говорить об этом, мы должны это понимать — почему мы учим разным техникам, и как все они работают вместе.
Может быть вы — опытный аналитик, который пишет UC и пользовательские истории, или думает в UC и пишет пользовательские истории. А может, что более вероятно, вы все еще находитесь в более традиционной итеративной среде, которая пока недостаточно гибкая. Возможно вы просто пишете пользовательские истории — которые тоже хороши, пока вы работаете в этом итеративном отзывчивом режиме совместной работы (речь про agile-процесс — прим. переводчика), а не в водопаде, где шаг, еще шаг, затем следующий шаг, и передача, перебрасывание задач туда-сюда (часто это называют пинг-понгом — прим. переводчика). Истории — это отличный способ быть на одной волне с вашей командой (совместное общение, итеративность процесса и уверенность, что все одинаково понимают требования).
Я хотела поделиться своими мыслями о UC и пользовательских историях и услышать ваши мысли. Ниже вы найдете споры по этой теме в рамках профессии аналитика, а также в рамках agile-сообщества. Это очень важная тема. Я думаю, нам нужно говорить об этом, мы должны это понимать — почему мы учим разным техникам, и как все они работают вместе.
Это нужно не только для организации эффективного процесса разработки программного обеспечения, но и для организации процесса анализа, который гарантирует, что каждый участник процесса понимает бизнес-задачи, которые мы пытаемся решить. Мы должны понимать, как мы решаем эту проблему с помощью технологий, какой набор инструментов у нас есть, чтобы бизнес мог понять, проверить и одобрить требования, чтобы мы строили то, что нужно бизнесу и все получили выигрыш от использования программного обеспечения.
Итак, я Лора Бранденбург из «Bridging the Gap». Что бы вы ни писали — UC или US — я снимаю перед вами шляпу за то, что вы аналитик. Спасибо, что вы здесь.
https://www.bridging-the-gap.com/requirements-prioritization/
https://z5h64q92×9.net/proxy_u/en-ru.ru/https/www.bridging-the-gap.com/requirements-prioritization/
Итак, я Лора Бранденбург из «Bridging the Gap». Что бы вы ни писали — UC или US — я снимаю перед вами шляпу за то, что вы аналитик. Спасибо, что вы здесь.
https://www.bridging-the-gap.com/requirements-prioritization/
https://z5h64q92×9.net/proxy_u/en-ru.ru/https/www.bridging-the-gap.com/requirements-prioritization/
В самое ближайшее время мы, Школа системных аналитиков, планируем провести воркшоп по этой теме
Не пропустите!
Не пропустите!
Анна Гасраталиева
Руководитель школы, ведущий системный аналитик
