Bitrix24 user stories
Как получать быструю, адекватную оценку стоимости проекта одновременно с готовой документацией
Знакомо ли вам это: вы обращаетесь в IT компанию с просьбой оценить стоимость разработки, а в ответ получаете отговорки в ключе: пришлите "нормальное" ТЗ и тогда мы посчитаем. Или завуалированное предложение щедро оплатить составление подробнейшей спецификации, а затем, на основании её уже сделать расчет стоимости?
При этом никто не может толком объяснить что такое "нормальное" ТЗ. А также никто не гарантирует, что стоимость разработки после составления такового, может оставаться приемлемой.
Так уже давно никто не делает.
При этом никто не может толком объяснить что такое "нормальное" ТЗ. А также никто не гарантирует, что стоимость разработки после составления такового, может оставаться приемлемой.
Так уже давно никто не делает.
“
После того как был описан метод представления требований бизнес уровня через user stories все остальное безнадежно устарело.
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
User Story не являются детальным описанием требований (то-есть детального описания интерфейса, реакций на действие), а представляет собой обсуждаемое представление намерения
Является короткой и легко читаемой, понятной разработчикам, стейкхолдерам и пользователям
Самое главное: каждая user story легко поддаётся эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены
User Story не являются детальным описанием требований (то-есть детального описания интерфейса, реакций на действие), а представляет собой обсуждаемое представление намерения
Является короткой и легко читаемой, понятной разработчикам, стейкхолдерам и пользователям
Самое главное: каждая user story легко поддаётся эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены
Ваша идеальная user story должна выглядеть так:
Как, <РОЛЬ пользователя>, я <что-то хочу получить ДЕЙСТВИЕ>, <с такой-то целью ЦЕННОСТЬ>
Критерии приемки:
Обработка ошибок:
Технические заметки:
Критерии приемки:
Обработка ошибок:
Технические заметки:
Роль
Это пользователи или группы пользователей
Например у вас в Системе их не очень много — Пользователь, Гость, Оператор и Админпстратор
Например у вас в Системе их не очень много — Пользователь, Гость, Оператор и Админпстратор
Действие
Это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать "авторизуется и выполняется поиск" или "указывает параметры поиска и выполняет поиск". Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение.
Ценность
Ваша история обязательно должна иметь ценность (результат), обязательно должна оказывать влияние на кого-то. Это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Возможно заменять понятия ценности (value) на влияние (impact).
Возможно заменять понятия ценности (value) на влияние (impact).
Выкладываем примеры, как выглядят пользовательские истории из реальных проектов
![](/upload/tilda/5471700/img/tild3035-3339-4564-b933-623533333933__11111111111111111.png)
Пример описания user story #1
![](/upload/tilda/5471700/img/tild3231-6665-4232-b830-663232656365__12222222222222.png)
Пример описания user story #2
![](/upload/tilda/5471700/img/tild3434-6238-4062-b734-366466623937__131111.png)
Пример описания 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:
Тестируемая. Достаточные критерии приемки, чтобы проверить историю на соответствие им
![](/upload/tilda/5471700/img/tild3331-3134-4638-a239-363565653835__headline-image.png)
Понравилась статья? Поставьте свою оценку, чтоб мы понимали о чем писать еще.
user stories для Bitrix24
Голосов: 57
, Рейтинг: 2.07
Не пропустите. Похожие публикации
- ЛІЦЕНЗІЙНА УГОДА НА ВИКОРИСТАННЯ ПО Банкінформ
- Как автоматизация всего одного основного процесса влияет на бизнес
- 5 стадий интеграции CRM-системы
- Cекретная распродажа Битрикс управление сайтом
- Пример технического задания на создание интернет-магазина. Часть #1
- Новые тарифы Битрикс24
- Пример технического задания на создание интернет-магазина. Часть #2
- Пример технического задания на создание интернет-магазина. Часть #3
- «Великолепная восьмёрка» в Битрикс24 - летняя акция 2019
- Пример технического задания с использованием USE CASES