Bitrix24 user stories
Как получать быструю, адекватную оценку стоимости проекта одновременно с готовой документацией
Знакомо ли вам это: вы обращаетесь в IT компанию с просьбой оценить стоимость разработки, а в ответ получаете отговорки в ключе: пришлите "нормальное" ТЗ и тогда мы посчитаем. Или завуалированное предложение щедро оплатить составление подробнейшей спецификации, а затем, на основании её уже сделать расчет стоимости?
При этом никто не может толком объяснить что такое "нормальное" ТЗ. А также никто не гарантирует, что стоимость разработки после составления такового, может оставаться приемлемой.
Так уже давно никто не делает.
При этом никто не может толком объяснить что такое "нормальное" ТЗ. А также никто не гарантирует, что стоимость разработки после составления такового, может оставаться приемлемой.
Так уже давно никто не делает.
“
После того как был описан метод представления требований бизнес уровня через user stories все остальное безнадежно устарело.
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
User Story не являются детальным описанием требований (то-есть детального описания интерфейса, реакций на действие), а представляет собой обсуждаемое представление намерения
Является короткой и легко читаемой, понятной разработчикам, стейкхолдерам и пользователям
Самое главное: каждая user story легко поддаётся эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены
User Story не являются детальным описанием требований (то-есть детального описания интерфейса, реакций на действие), а представляет собой обсуждаемое представление намерения
Является короткой и легко читаемой, понятной разработчикам, стейкхолдерам и пользователям
Самое главное: каждая user story легко поддаётся эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены
Ваша идеальная user story должна выглядеть так:
Как, <РОЛЬ пользователя>, я <что-то хочу получить ДЕЙСТВИЕ>, <с такой-то целью ЦЕННОСТЬ>
Критерии приемки:
Обработка ошибок:
Технические заметки:
Критерии приемки:
Обработка ошибок:
Технические заметки:
Роль
Это пользователи или группы пользователей
Например у вас в Системе их не очень много — Пользователь, Гость, Оператор и Админпстратор
Например у вас в Системе их не очень много — Пользователь, Гость, Оператор и Админпстратор
Действие
Это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать "авторизуется и выполняется поиск" или "указывает параметры поиска и выполняет поиск". Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение.
Ценность
Ваша история обязательно должна иметь ценность (результат), обязательно должна оказывать влияние на кого-то. Это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Возможно заменять понятия ценности (value) на влияние (impact).
Возможно заменять понятия ценности (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:
Тестируемая. Достаточные критерии приемки, чтобы проверить историю на соответствие им
Понравилась статья? Поставьте свою оценку, чтоб мы понимали о чем писать еще.
user stories для Bitrix24
Голосов: 57
, Рейтинг: 2.07
Не пропустите. Похожие публикации
- ЛІЦЕНЗІЙНА УГОДА НА ВИКОРИСТАННЯ ПО Банкінформ
- Как автоматизация всего одного основного процесса влияет на бизнес
- 5 стадий интеграции CRM-системы
- Умови конфіденційності при використанні ПО Банкінформ
- Пример технического задания с использованием USE CASES
- Importance of using progressive solutions in web development
- Пример технического задания с использованием BUSINESS RULES
- Прозрачные скидки на Битрикс24
- Bitrix24 решает проблемы крупного ритейла
- Операция.Расконсервация в Битрикс24 в апреле 2020