Привет, Хабр! Представляю вашему вниманию перевод статьи «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.
