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

Привет, Хабр! Представляю вашему вниманию перевод статьи «User stories are not requirements» автора Пер Лундхольм (Per Lundholm).

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


А есть ли вообще смысл в написании подобной статьи? Разве сказанное выше не кажется очевидным? Нет, я полагаю, что нередко встречающиеся высказывания типа «требования в бэклоге» сигнализируют о том, что парадигма мышления осталась старой, просто вывески поменялись. Документ требований стали называть бэклогом, сами требования — пользовательскими историями, и вот мы уже «agile»…

Еще один признак возможного недопонимания — распространенная практика сохранения пользовательских историй в БД с присвоением уникального ID. Вполне возможно, так делается просто ради удобства, но не исключено, что это результат проявления устойчивой тенденции думать в терминах требований.

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

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

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

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

Получается, что требования нам не нужны? На самом деле это не совсем так. Ведь, так или иначе существуют ограничения. Например, медицинское оборудование обязательно должно соответствовать правилам FDA. Так давайте тогда и будем называть их ограничениями!

И все же, требования детально описывают Систему, возможно, в подобном описании есть какая-то ценность для нас? К примеру, как определить является ли некоторое поведение системы багом или нет, если у нас отсутствуют представленные в том или ином виде формальные требования? Здесь нам поможет техника «Specification by Example». Итак, принято решение, что некоторая функциональность должна быть реализована. Вы пишите бизнес — правила и серию примеров в таком виде, чтобы это было: а) удобно для восприятия; б) реализуемо. Из данного описания должно быть понятно, что должна делать Система. А так же, если что – то пойдет нет так вследствие внесения изменений — нарушение какого бизнес — правила явилось причиной данной дисфункции.

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

Контракт


(автор Маттиас Скарин)

Итак, что мы будем использовать вместо спецификации требований? Ведь нам нужно понимать реализовали ли мы именно то, что было нужно? Мы будем использовать agile – контракты. Agile — контракты — это возможность увидеть лес за деревьями, они позволяют сфокусироваться на сути проекта и совместном достижении цели, реализация которой удовлетворит потребности пользователей.

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

Резюме


  • Несмотря на то, что и слон и жираф имеют по четыре ноги, это — разные животные.
  • Пользовательские истории это не требования, а инструмент планирования.
  • Наиболее близкое к требованиям — Specification by Example.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 12

    +4
    Я понимаю, что это перевод, но…

    Во всей статье прямо-таки не разу не разъясняется, что вообще значит словосочетание «Пользовательские истории»! Нет сноски, что это не пользовательские истории вообще (ну типа, приходит пользователь и рассказывает историю… Не, ну а чего — сейчас все уже настолько в agile, что это очевидно? А я вот гуглил...), а термин agile-философии… Ссылочку бы на определение. Да и сама статья откровенно ни о чем.
      –3

      Как видите Ваш риквест дефиниции пользовательских историй показался анонимусу токсичным.
      PS. формально мой каммент написан на русском.

        +2

        Хорошо, что вы мне объяснили, плохо, что я ничего не понял… ;)

          0

          "Ваша просьба дать определения понятия "пользовательские истории" не понравилась неназванным пользователям хабра" (это судя по минусам Вашему камменту).
          Та же фигня с "пользовательскими историями" — неумение автора по-людски переводить термины заменяется прямым гуглепереводом и контекстом "ну все же знают".

            +1
            А, теперь понял… ) Я примерно так и предполагал, но…

            Я просто с телефона читал — там детально посмотреть сложно, а общая оценка была нейтральной.

            Ну, анонимусу виднее! ) Я свое мнение высказал: я считаю, что словосочетание «пользовательские истории» состоит из обычных общеупотребимых слов и если речь идет не об общем их применении, а о специальной терминологии из определённой области, то нужно давать сноску! А там может и правда я от жизни отстал и не понимаю устоявшихся выражений…
        0
        Коллеги, "пользовательские истории" — это вполне устоявшийся русскоязычный термин. Если вдруг он не знаком… ну вы сами знаете, как исправить эту ситуацию.
        +4
        Пользовательские истории — это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования… это решить все наперед, чтобы потом в этом увязнуть.


        Только хреновый аналитик пытается в требованиях решить все наперед. И таким можно и нужно давать по рукам, потому что требования не должны всегда описывать детали реализации, и должны также оставлять возможности.
          0
          Оно то так, только аналитики так делают не от хорошей жизни. Чем детальнее требования — тем тяжелее потом заказчику сыграть в 'misunderstanding' на этапе приемки продукта.
          Требования которые детально описывают желаемое поведение системы или ее части обычно очень тяжело проходят согласование с заказчиком, потому что тот — видя что читать требования двояко становится все сложнее — углубляется в детали предполагаемого поведения. Т.е. время в этом случае больше тратится на проработку требований и описание будущего решения а не на изменение того что уже имплементировано.
            0
            Ну это понятно. Компромисс всегда есть, какие-то вещи нужно зафиксировать — или реализовано будет совсем не то, что хотели.

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

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

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

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

          Однако, пользовательские истории упрощают диалог о продукте и дают всем участникам проекта возможность легко понимать его назначение. Ведь не все приложения — музыкальный плеер, или социальная сеть, где многие имеют личный опыт пользования. Это могут быть какие-то «суровые» приложения для производственного планирования, и тут без таких «обьяснялочек» в виде сценариев не обойтись. Ткнул в историю, и сразу всем ясен контекст. Упрощает, ускоряет коммуникацию.

            0
            Требования — это всё, что отражает потребности заказчика. Пользовательские истории это отлично делают, а значит это требования.

            Автора статьи, возможно, смутило то, что пользовательские истории как правило не достаточно конкретные, чтобы можно было начинать разработку.

            Есть несколько видов требований: бизнес требования (business requirements), требования заинтересованных сторон (stakeholder requirements), требования к решению (solution requirements). Функциональные требования (functional requirement) — это подкатегория требований к решению.

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

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

            Из IIBA BABoK:

            Need — a problem or opportunity to be addressed.

            Requirement — a usable representation of a need.

            Business requirements — statements of goals, objectives, and outcomes that describe why a change has been initiated.

            Stakeholder requirement — a description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.

            Solution requirements — describes the capabilities and qualities of a solution that meets the stakeholder requirements.

            Functional requirements — (a subcategory of solution requirements) describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.

            User story — a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

              0
              статья в стиле «Сон это не сон а не сон это сон». Пользовательские истории это не требования а один из форматов описания требований. Из них разработчик понимает контекст использования продукта. Например — не только требование сделать зеленую кнопку, но и то как ей будут пользоваться, как она может измениться и т.д.

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

              Самое читаемое