User story (card)Начали внедрять у себя в проекте Scrum для QA команды и столкнулись с проблемой непонимания со стороны “новобранцев” одного из ключевых определений в скраме — юзер стори. Или даже правильнее было бы сказать, что проблема в черезчур прямолинейном понимании данного определения. Например, они целиком и полностью уверены, что под понятием user story скрываются исключительно задания, которые вносят новую функциональность в продукт. Но ведь это не всегда верно, ведь в списке задач есть такие черезвычайно сложные и трудоёмкие задачи как рефакторинг, нагрузочное тестирование или же интеграция модулей в приложении. Отсюда напрашивается первый вывод - user story в реальной жизни содержат не только описания нового функционала видимого клиенту. Мало того, данные требования в сложных системах могут быть всего лишь вершиной айсберга по сравнению с огромным количеством скрытых задач по созданию сложных алгоритмов и настройке безотказной системы.

К тому же выяснилось, что в некоторых случаях обычный task принимают за user story. Но как же отличить эти два понятия? С ходу напрашивается ответ, что юзер стори агрегирует в себя такси, а следовательно таск, в отличии от юзер стори, сущность атомарная. Это утверждение не идеально, так как понятие атомарности, как показала практика, у каждого своё. Например, тестеру нужно написать автоматизированные тесты для приёмочного тестирования, вот он и создаёт у себя в беклоге юзер стори “create selenium tests” с единственным таском, аналогичного содержания и даёт оценку этой задаче в 10 идеальных часов (при условии что юзер стори оценена в 2 story point-а, а 1SP = 5 идеальным часам). При этом он утверждает, что на более мелкие куски разделить просто на просто невозможно. Но стоит задать этому человеку несколько наводящих вопросов и мы увидим, что перед нами появиться список с 5-тью задачами и эстимейшеном в 13 часов.
Итак, мысль номер два — юзер стори не предназначены для точной оценки времени и ресурсов, требуемых для решения возникшей задачи.

И теперь перейдём к последнему пункту, который отличает, на мой взгляд, task от user story (US). Любая US обязана содержать в себе элементы приёмочного тестирования. И если для команды разработчиков приёмочными тестами будут автоматизированные тесты, созданные коммандой QA, то для самой комманды тестеров эту роль уже будет играть успешное прохождение всех созданных ими тестов на continuous integration сервере.

Выходя из всего вышеперечисленного, хотелось бы дать своё определение user story.

User story — общее описание задачи, которое позволяет выполнить предварительную оценку сложности разработки (реализации) и является основой для приёмочного тестирования.

На этом спасибо и до новых встреч. Данное определение будет помещено на страницу Scrum терминологии.