Знакомая ситуация: вы обращаетесь в ИТ-компанию с просьбой оценить стоимость разработки, а в ответ получаете отговорки вроде «пришлите нормальное ТЗ — тогда посчитаем». Или завуалированное предложение сначала щедро оплатить составление подробной спецификации, а уже потом, на её основании, сделать расчёт стоимости. Так давно уже никто не делает.
Почему «нормальное ТЗ» — это ответ ни о чём
При этом никто толком не может объяснить, что такое это самое «нормальное» ТЗ. И, что важнее, никто не гарантирует: когда документ наконец будет составлен, стоимость разработки останется для вас приемлемой. Получается странная сделка — вы платите за текст, который лишь потом покажет, по карману ли вам сам проект.
Нужен другой вход в разговор о деньгах: такой, где оценка и документация появляются одновременно, а не одно после другого.
После того как был описан метод подачи требований бизнес-уровня через user stories, всё остальное безнадёжно устарело.ANIART
Что такое user story
User story — это короткая формулировка намерения, которая описывает то, что система должна делать для пользователя.
- User story не является подробным описанием требований — то есть детального описания интерфейса или реакций на действие в ней нет. Это обсуждаемая подача намерения.
- Она короткая и легко читается — понятна разработчикам, стейкхолдерам и пользователям.
- Самое главное: каждая user story легко поддаётся эстимированию, поэтому усилия, нужные для реализации, можно определить быстро.
Как выглядит идеальная история
Ваша идеальная user story должна выглядеть так:
Как <РОЛЬ пользователя>, я <ДЕЙСТВИЕ>, <ЦЕННОСТЬ>.
А дальше к этой формулировке добавляются три блока:
- Критерии приёмки.
- Обработка ошибок.
- Технические заметки.
Роль
Это пользователи или группы пользователей. Например, в вашей системе их не так много — Пользователь, Гость, Оператор и Администратор.
Действие
Это суть истории, «что нужно сделать». Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать «авторизуется и выполняется поиск» или «указывает параметры поиска и выполняет поиск». Укажите то действие, которое вам действительно нужно.
Важно описывать историю на уровне «ЧТО?» делается, а не «КАК?». Это главное в истории. Опишите проблему, а не её решение.
Ценность
Ваша история обязательно должна иметь ценность — результат обязательно должен влиять на кого-то. Это влияние в итоге ведёт к цели, которая имеет для вас ценность. Понятие ценности (value) можно заменять на влияние (impact).
Примеры из реальных проектов
Ниже — примеры того, как выглядят пользовательские истории, взятые из реальных проектов.
Что вы получаете, подготовив истории
Подготовив user story, вы сформулировали бизнес-ценность для конечного пользователя. Но прелесть пользовательской истории ещё и в том, что она формулирует не только бизнес-ценность, но и требования для разработки и тестирования.
То есть тот же набор историй служит отличной документацией бизнес-уровня — чтобы быстро понять, что именно делает ваша система.
Оценка
Каждая история поддаётся эстимированию, поэтому усилия на реализацию определяются быстро — без предварительного многонедельного описания.
Документация
Готовые истории — это business level документация: из них видно, что делает система, без погружения в интерфейсы.
Требования к разработке
Формулировка намерения с критериями приёмки сразу ложится в работу команды разработки.
Основа для тестирования
Критерии приёмки дают то, по чему историю проверяют на соответствие — тесты пишутся до кода.
Советы по написанию пользовательских историй
- Лучше написать много небольших историй, чем несколько громоздких.
- Каждую историю в идеале стоит писать, избегая технического жаргона.
- Истории должны быть написаны так, чтобы их можно было протестировать. Тесты должны быть написаны до кода.
- Как можно дольше стоит избегать UI: история должна выполняться без привязки к конкретным элементам.
- Каждая история должна содержать оценку.
- История должна иметь конечную ценность — то есть приводить к конкретному результату или оказывать влияние.
- История должна помещаться в итерацию.
INVEST: критерии качества user story
Скрам-руководство предлагает шесть критериев, по которым проверяют качество истории. Вот они — и то, как мы читаем каждый из них в работе.
| Критерий | Scrum guide | ANIART |
|---|---|---|
| Independent | Reduced dependencies = easier to plan | Независимая. Максимально уменьшены взаимозависимости с другими историями. Историю легко выделить и реализовать. |
| Negotiable | Details added via collaboration | Обсуждаемая. Описание достаточно для понимания всеми участниками: после прочтения все готовы вносить дополнения. |
| Valuable | Valuable | Несёт понятную ценность. |
| Estimable | Too big or too vague = not estimable | Пригодная к оценке. Слишком большие или нечётко сформулированные истории сложно оценить конкретно. |
| Small | Can be done in less than a week by the team | Достаточно компактная, чтобы быть сделанной меньше чем за неделю при работе всей команды. |
| Testable | Good acceptance criteria | Тестируемая. Достаточные критерии приёмки, чтобы проверить историю на соответствие им. |
Как это работает на практике
- Формулируем намерение. Для каждой роли — Пользователь, Гость, Оператор, Администратор — записываем одно основное действие и ценность, к которой оно ведёт.
- Добавляем критерии приёмки. К каждой истории — условия, по которым её будут проверять, а также обработку ошибок и технические заметки.
- Проверяем по INVEST. История, которая не проходит по «Small» или «Estimable», разбивается на более мелкие.
- Оцениваем. Каждая история получает оценку — и из этих оценок складывается стоимость разработки.
