Всем привет! Продолжаю свой цикл статей. Одна статья - один вопрос для собеседования или аттестации на системного аналитика.
В этот раз поговорим о User story - пользовательская история.
Впервые заговорил о пользовательских историях программист Кент Бек (Kent Beck) в 1997г., а в 1999г. описал их в своей книге про экстремальное программирование "Extreme Programming Explained".
Что же это такое, эти ваши истории?
Пользовательские истории - это неформальное описание пользователя желаемого поведения системы.
Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта.
User story пришли в разработческую жизнь как что-то емкое, понятное, "свежее", в ответ на большие и сложные спецификации.
"A user story is a promise for a conversation." Alistair Cockburn, 1998
Пользовательская история - это обещание диалога.
Что почитать на тему? Интернет рекомендует книгу - Майк Кон: Пользовательские истории. Гибкая разработка программного обеспечения.
Пример user story
Гораздо понятнее в этой теме будет перейти сразу к примеру. Простыми словами: пользовательская история - это:
- Кто
- Что хочет
- Почему хочет
Если взять пример из моей статьи про use case, то в ней user story будет:
Я - юрист вашей маленькой компании. Мне приходится ходить на многочисленные суды с пользователями на одну тему: они не давали согласие на рассылку промокодов от компании N. Список компаний часто меняется. Мне нужны доказательства, кто, когда и на что дал согласие, чтобы я мог оперировать этим в суде и выиграть суд. Информация о компаниях должна быть открыта всем пользователям, чтобы я мог указать, что пользователь знал, на что соглашался.
Считаю свою юзер стори хорошей, не только потому, что я ее написала, а потому что она удовлетворяет принципам юзер стори.
Каким должен быть user story
Он должен удовлетворять критериям INVEST, автор которых Билл Уэйк
- Independent — независимость, истории могут реализовываться независимо друг от друга
- Negotiable — подлежит обсуждению, историю можно и нужно обсуждать с командой для того, чтобы обсудить критерии приемки
- Valuable — ценная
- Estimable — поддающаяся оценке
- Small — компактная, может быть сделана командой за одну итерацию, не требуется бить на подзадачи
- Testable — тестируемая (например, имеет критерии приемки)
Юзер стори также должна иметь критерии приемки, по которым можно оценить, что юзер стори сделана.
Когда пишут user story?
Когда планируете бэк лог задач. Или когда описываете стори для при планировании проекта.