Привет, Хабр! Представляю вашему вниманию перевод статьи «User stories are not requirements» автора Пер Лундхольм (Per Lundholm).
А есть ли вообще смысл в написании подобной статьи? Разве сказанное выше не кажется очевидным? Нет, я полагаю, что нередко встречающиеся высказывания типа «требования в бэклоге» сигнализируют о том, что парадигма мышления осталась старой, просто вывески поменялись. Документ требований стали называть бэклогом, сами требования — пользовательскими историями, и вот мы уже «agile»…
Еще один признак возможного недопонимания — распространенная практика сохранения пользовательских историй в БД с присвоением уникального ID. Вполне возможно, так делается просто ради удобства, но не исключено, что это результат проявления устойчивой тенденции думать в терминах требований.
А вот практика включения пользовательских историй в контракт — это уже стопроцентный признак того, что пользовательские истории рассмат��иваются в качестве требований. Проблема здесь в том, что пользовательская история по определению не может быть такой однозначной, как требование, а это обесценивает контракт. Безусловно, требования иногда тоже можно достаточно свободно интерпретировать, но сама техника их написания изначально подразумевают устранение двусмысленности, чего не скажешь о пользовательских историях. Кроме того, требования устойчивы к изменениям, поскольку они входят в проектные контракты. Для того, чтобы изменить или добавить новые требования, их нужно провести через CCB. Другими словами, заинтересованные лица должны их сначала согласовать и одобрить. Подробнее о контрактах см. ниже.
Так что же такое пользовательские истории? Рассматривайте их, как инструмент планирования. С помощью пользовательских историй мы определяем приоритеты, оцениваем и принимаем решение в каком спринте будет реализована соответствующая функциональность. Все это — типичные признаки инструмента планирования, поэтому не стоит пытаться превратить их во что-то другое.
Сила пользовательских историй в том, что они дают начало диалогу. Вместо того, чтобы просто взять и передать коллегам спецификацию, которая интерпретируется сначала разработчиками, потом тестировщиками — мы начинаем обсуждение. Мы включаем в коммуникацию сотрудников с различными навыками. И так — по каждой новой фиче.
Поскольку пользовательская история, как таковая, не несет в себе много смысла, мы можем просто отбросить ее по факту реализации соответствующей функциональности. При желании можно тщательно вести статистику количества реализованных историй, но этим вполне можно и ограничиться.
Получается, что требования нам не нужны? На самом деле это не совсем так. Ведь, так или иначе существуют ограничения. Например, медицинское оборудование обязательно должно соответствовать правилам FDA. Так давайте тогда и будем называть их ограничениями!
И все же, требования детально описывают Систему, возможно, в подобном описании есть какая-то ценность для нас? К примеру, как определить является ли некоторое поведение системы багом или нет, если у нас отсутствуют представленные в том или ином виде формальные требования? Здесь нам поможет техника «Specification by Example». Итак, принято решение, что некоторая функциональность должна быть реализована. Вы пишите бизнес — правила и серию примеров в таком виде, чтобы это было: а) удобно для восприятия; б) реализуемо. Из данного описания должно быть понятно, что должна делать Система. А так же, если что – то пойдет нет так вследствие внесения изменений — нарушение какого бизнес — правила явилось причиной данной дисфункции.
Как я писал ранее, описание бага должно быть простым и четким. Баги – это нечто, разрушающее информацию, это то, что плохо независимо от того, есть ли у нас описание требования, покрывающее данный кейс, или его нет.
(автор Маттиас Скарин)
Итак, что мы будем использовать вместо специфик��ции требований? Ведь нам нужно понимать реализовали ли мы именно то, что было нужно? Мы будем использовать agile – контракты. Agile — контракты — это возможность увидеть лес за деревьями, они позволяют сфокусироваться на сути проекта и совместном достижении цели, реализация которой удовлетворит потребности пользователей.
Имейте ввиду, когда вы по ходу проекта вспомните о контракте с тем, чтобы проверить не нарушил ли что-нибудь ваш партнер, это уже означает, что что-то идет не так. Контракт должен укреплять доверие между сторонами, с тем, чтобы стало возможным выйти за рамки частностей, а не увязнуть в них.
Слоны – не жирафы, а пользовательские истории – это не требования. Они имеют и общие черты и общий контекст, однако это не ставит между ними знак равенства. Тем не менее, многие полагают, что пользовательские истории являются своего рода новым прочтением того, что традиционно называется требованиями к программному обеспечению — ведь, должны же быть требования на проекте, правильно? Так вот, я отвечу — нет, и еще раз нет. Во – первых, это не требования, во – вторых, требования — это не то, что нам на самом деле нужно. Пользовательские истории — это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования… это решить все наперед, чтобы потом в этом увязнуть.
А есть ли вообще смысл в написании подобной статьи? Разве сказанное выше не кажется очевидным? Нет, я полагаю, что нередко встречающиеся высказывания типа «требования в бэклоге» сигнализируют о том, что парадигма мышления осталась старой, просто вывески поменялись. Документ требований стали называть бэклогом, сами требования — пользовательскими историями, и вот мы уже «agile»…
Еще один признак возможного недопонимания — распространенная практика сохранения пользовательских историй в БД с присвоением уникального ID. Вполне возможно, так делается просто ради удобства, но не исключено, что это результат проявления устойчивой тенденции думать в терминах требований.
А вот практика включения пользовательских историй в контракт — это уже стопроцентный признак того, что пользовательские истории рассмат��иваются в качестве требований. Проблема здесь в том, что пользовательская история по определению не может быть такой однозначной, как требование, а это обесценивает контракт. Безусловно, требования иногда тоже можно достаточно свободно интерпретировать, но сама техника их написания изначально подразумевают устранение двусмысленности, чего не скажешь о пользовательских историях. Кроме того, требования устойчивы к изменениям, поскольку они входят в проектные контракты. Для того, чтобы изменить или добавить новые требования, их нужно провести через CCB. Другими словами, заинтересованные лица должны их сначала согласовать и одобрить. Подробнее о контрактах см. ниже.
Так что же такое пользовательские истории? Рассматривайте их, как инструмент планирования. С помощью пользовательских историй мы определяем приоритеты, оцениваем и принимаем решение в каком спринте будет реализована соответствующая функциональность. Все это — типичные признаки инструмента планирования, поэтому не стоит пытаться превратить их во что-то другое. Сила пользовательских историй в том, что они дают начало диалогу. Вместо того, чтобы просто взять и передать коллегам спецификацию, которая интерпретируется сначала разработчиками, потом тестировщиками — мы начинаем обсуждение. Мы включаем в коммуникацию сотрудников с различными навыками. И так — по каждой новой фиче.
Поскольку пользовательская история, как таковая, не несет в себе много смысла, мы можем просто отбросить ее по факту реализации соответствующей функциональности. При желании можно тщательно вести статистику количества реализованных историй, но этим вполне можно и ограничиться.
Получается, что требования нам не нужны? На самом деле это не совсем так. Ведь, так или иначе существуют ограничения. Например, медицинское оборудование обязательно должно соответствовать правилам FDA. Так давайте тогда и будем называть их ограничениями!
И все же, требования детально описывают Систему, возможно, в подобном описании есть какая-то ценность для нас? К примеру, как определить является ли некоторое поведение системы багом или нет, если у нас отсутствуют представленные в том или ином виде формальные требования? Здесь нам поможет техника «Specification by Example». Итак, принято решение, что некоторая функциональность должна быть реализована. Вы пишите бизнес — правила и серию примеров в таком виде, чтобы это было: а) удобно для восприятия; б) реализуемо. Из данного описания должно быть понятно, что должна делать Система. А так же, если что – то пойдет нет так вследствие внесения изменений — нарушение какого бизнес — правила явилось причиной данной дисфункции.
Как я писал ранее, описание бага должно быть простым и четким. Баги – это нечто, разрушающее информацию, это то, что плохо независимо от того, есть ли у нас описание требования, покрывающее данный кейс, или его нет.
Контракт
(автор Маттиас Скарин)
Итак, что мы будем использовать вместо специфик��ции требований? Ведь нам нужно понимать реализовали ли мы именно то, что было нужно? Мы будем использовать agile – контракты. Agile — контракты — это возможность увидеть лес за деревьями, они позволяют сфокусироваться на сути проекта и совместном достижении цели, реализация которой удовлетворит потребности пользователей.
Имейте ввиду, когда вы по ходу проекта вспомните о контракте с тем, чтобы проверить не нарушил ли что-нибудь ваш партнер, это уже означает, что что-то идет не так. Контракт должен укреплять доверие между сторонами, с тем, чтобы стало возможным выйти за рамки частностей, а не увязнуть в них.
Резюме
- Несмотря на то, что и слон и жираф имеют по четыре ноги, это — разные животные.
- Пользовательские истории это не требования, а инструмент планирования.
- Наиболее близкое к требованиям — Specification by Example.
