☰
✕

Bitrix24 user stories

Как получать быструю, адекватную оценку стоимости проекта одновременно с готовой документацией
Знакомо ли вам это: вы обращаетесь в IT компанию с просьбой оценить стоимость разработки, а в ответ получаете отговорки в ключе: пришлите "нормальное" ТЗ и тогда мы посчитаем. Или завуалированное предложение щедро оплатить составление подробнейшей спецификации, а затем, на основании её уже сделать расчет стоимости?

При этом никто не может толком объяснить что такое "нормальное" ТЗ. А также никто не гарантирует, что стоимость разработки после составления такового, может оставаться приемлемой.

Так уже давно никто не делает.
“
После того как был описан метод представления требований бизнес уровня через user stories все остальное безнадежно устарело.
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

User Story не являются детальным описанием требований (то-есть детального описания интерфейса, реакций на действие), а представляет собой обсуждаемое представление намерения

Является короткой и легко читаемой, понятной разработчикам, стейкхолдерам и пользователям

Самое главное: каждая user story легко поддаётся эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены
Ваша идеальная user story должна выглядеть так:
Как, <РОЛЬ пользователя>, я <что-то хочу получить ДЕЙСТВИЕ>, <с такой-то целью ЦЕННОСТЬ>

Критерии приемки:

Обработка ошибок:

Технические заметки:
Роль
Это пользователи или группы пользователей
Например у вас в Системе их не очень много — Пользователь, Гость, Оператор и Админпстратор
Действие
Это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать "авторизуется и выполняется поиск" или "указывает параметры поиска и выполняет поиск". Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение.
Ценность
Ваша история обязательно должна иметь ценность (результат), обязательно должна оказывать влияние на кого-то. Это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Возможно заменять понятия ценности (value) на влияние (impact).
Выкладываем примеры, как выглядят пользовательские истории из реальных проектов
Пример описания user story #1
Пример описания user story #2
Пример описания user story #3
Подготовив user story вы сформулировали бизнес-ценность для конечного пользователя. Но прелесть пользовательской истории еще в том, что она формулирует не только бизнес-ценность, но и требования для разработки и тестирования, служит прекрасной business level документацией для быстрого понимания что делает ваша система.
Советы по написанию пользовательских историй

  • Лучше написать много историй поменьше, чем несколько громоздких
  • Каждая история в идеале должна быть написана избегая технического жаргона
  • Истории должны быть написаны таким образом, чтобы их можно было протестировать Тесты должны быть написаны до кода.
  • Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
  • Каждая история должна содержать оценку.
  • История должна иметь конечную ценность — т.е. приводить к конкретному результату. Или оказывать влияние
  • История должна вмещаться в итерацию
Scrum guide
Критерии «INVEST» для оценки качества user story
Scrum guide:
Independent. Reduced dependencies = easier to plan
Aniart:
Независимая. Максимально уменьшены взаимозависимости с другими историями. Историю легко выделить и реализовать
SCRUM guide:
Negotiable. Details added via collaboration;
Aniart:
Обсуждаемая. Описание достаточное для понимания всеми участниками, после прочтения все готовы вносить дополнения
Scrum guide:
Valuable
Aniart:
Несет понятную ценность
Scrum guide:
Estimable. Too big or too vague = not estimable
Aniart:
Пригодна к оценке. Слишком большие или нечетко сформулированные истории сложно оценить конкретно
Scrum guide:
Small. Can be done in less than a week by the team;
Aniart:
Достаточно компактная чтобы быть сделанной менее чем за неделю при работе всей командой.
Scrum guide:
Testable. Good acceptance criteria;
Aniart:
Тестируемая. Достаточные критерии приемки, чтобы проверить историю на соответствие им
Что интересное мы делаем еще
Почему крупнейший интернет ритейлер продает на 210% больше
Как перенести успешные практики из офлайна в онлайн. Интеграция интернет магазина с ERP и CRM
Как мы делали проект национального масштаба
eCommerce