Привет.
Решили, в рамках Agile Study Group освоить книгу Майка Кона - User Stories Applied: For Agile Software Development.
Долго выбирали, какую книгу взять, и решили взять классику по User Stories. Что понравилось: книга построена систематично, покрыты вопросы выявления и сбора требований, планирования итераций, изобилует примерами, и что немало важно, имеются упражнения для размышления и обсуждения.
Может возникнуть резонный вопрос: Для чего нужны эти Ваши User Stories?
Первое с чего начинается проект – это сбор требований к конечному продукту. Этот процесс подразумевает под собой взаимодействие всех членов команды. Основная проблема, с которой сталкивается команда в процессе сбора требований - это проблема коммуникаций. Проблемы возникают в том случае, когда происходит дисбаланс «лагерей»: бизнес «лагеря» и технического «лагеря». В такой ситуации преобладание одной из сил над другой отражается на проекте. Преобладание технической составляющей приводит к преобладанию технической составляющей в бизнес области, как пример, бизнес задачи описываются на техническом жаргоне.
Что такое user story - это просто история, продукт методологии. Путь создания этого продукта, причем правильный путь, как раз и позволяет соблюсти баланс сил и повысить качество коммуникации.
Каждая User Story содержит в себе небольшую часть функциональности системы и включает в себя три аспекта:
- написание истории
- обсуждение истории и указании напоминаний
- тестирование истории.
Пример User Story может быть такой:
Пользователь может отправить тестовую смс-рассылку.
Просто, не правда ли? Возникают резонные вопросы:
- А где же детали?
- Должен ли пользователь быть зарегистрирован и авторизован?
- Как выглядит тестовая рассылка?
Ответы на большинство этих вопросов, как ни странно, так же являются User Stories. Что же получается, мы разбиваем все наши большие истории на маленькие. Согласитесь, маленькую задачу проще и быстрее реализовать и получить feedback, нежели большую. Правда нет необходимости разбивать большие истории на маленькие до бесконечности, всему есть придел.
После принятия истории, мы можем указать какие либо напоминания, которые критичны для этой истории, и перейти к следующей. Главный конек этого процесса, заключается в том, что мы вернемся к деталям user story, тогда когда настанет час ее реализации. Получается простая, гибкая и удобная схема: бизнес выбирает историю на итерацию, разработчик берет историю и идет к заказчику, обсуждаются детали истории, с учетом измененных требований.
Если мы вспомним аспекты присущие user story, то вспомним третий пункт – тестирование. Помимо напоминаний, каждая карточка истории содержит приемочный тест для этой истории. Как правило тест записывается на оборотной стороне карточки. Тест помогает разработчику не уйти от основной линии функциональности и остановится в нужный момент – тест зеленый.
В начале статьи было отмечено, что у нас есть два «лагеря» - бизнес и it. Оба лагеря участвуют в сборе требований – мозговом шторме, но писать истории – это ответственность заказчиков. Все дело в том, если доверить написание истории it отделу, то мы получим историю, описанную техническим жаргоном. Такую историю будет тяжело понимать людям не связанным с технической областью.
После того как истории написаны, можно перейти к планированию релизов. К этому моменту, технический отдел выставил каждой истории стоимость(velocity). Бизнес отдел выставляет истории приоритеты (запрещается ставить приоритет без стоимости истории ) и принимает решение о том, какая история попадет в текущую итерацию. В зависимости от выбора историй, технический отдел может менять стоимость ( такая ситуация может возникнуть, когда стоимость истории была оценена с учетом истории, которая еще не выполнена).
Закончим наше начало на приемочном тестировании.
Приемочное тестирование это процесс проверки того, что user story реализована так, как задумывалась. Приемочное тестирование должен делать заказчик истории: только он обладает полной информацией об истории. Рекомендуется писать приемочный тест до окончания итерации. Раннее написание теста позволяет сократить доработки истории в будущем.
Подводя итоги, скажем о некоторых плюсах использования user stories:
- акцентируют внимание на живом общении, взамен письменному взаимодействию
- позволяют разбить реализацию на небольшие шаги, достаточные для построения плана проекта
- работают в итеративном процессе
- используются для планирования итерации.
В дальнейших статьях, постараюсь покрыть затронутые вопросы глубже.
Ссылка на подкасты
User Stories Applied - 1. Введение