Создание удобного описания требований пользователей к продукту
Составляемый командой список невыполненных работ по продукту, как правило, содержит пользовательское описание функциональности для отражения потребностей и целей клиентов. На протяжении работы над проектом участники команды добавляют в описания функциональности подробные сведения, разбивают их на более мелкие описания, оценивают их и назначают им приоритеты и, наконец, реализуют их и поставляют результаты клиентам. Составляя удобные пользовательские описания функциональности и постоянно обновляя список невыполненных работ по продукту команда разработчиков может более эффективно удовлетворять потребности пользователей.
По мнению Билла Уэйка (Bill Wake), хорошее описание функциональности пользователя можно охарактеризовать аббревиатурой INVEST: independent, negotiable, valuable, estimable, small and testable — независимое, обсуждаемое, ценное, оцениваемое, небольшое и тестируемое. Дополнительные сведения см. на следующем веб-сайте: XPlorations. Майк Кон (Mike Cohn) рассматривает написание описаний функциональности пользователей в одной из своих книг. Загрузить соответствующую главу можно со следующего веб-сайта: User Stories Applied for Agile Software Development.
При создании описания функциональности пользователя команде следует убедиться, что оно представляет собой ценность для клиента, ответив на следующие вопросы:
кем является пользователь;
что нужно делать пользователю;
зачем пользователю нужно это делать.
В большинстве случаев для этого команде достаточно создать эффективный заголовок описания. Майк Кон предлагает использовать следующую форму: "Как <пользователю>, мне нужно <действие>, чтобы <причина>". Примером такого подхода является, например, заголовок "Как представителю службы поддержки клиентов, мне нужно обращаться к данным клиентов, чтобы я мог быстрее отвечать на их вопросы". Во многих случаях причина очевидна. Например, "Как вегетарианцу, мне нужно фильтровать результаты поиска, чтобы просматривать только вегетарианские блюда".
Кроме того, описания функциональности пользователей следует определять так, чтобы реализовывать их можно было в любом порядке. Однако на практике полная независимость описаний функциональности не всегда достижима. И у Билла Уэйка, и у Майка Кона описываются методики, которые команда может использовать, когда сделать описания функциональности независимыми оказывается затруднительным.
Описания функциональности, являющиеся ценными и независимыми (как описано выше), образуют список невыполненных работ по продукту. Их оценивают и назначают приоритеты, после чего команда приступает к работе над описаниями функциональности с наивысшим приоритетом. Чтобы команда приступила к реализации описания функциональности пользователя, описание должно обладать перечисленными ниже характеристиками. Владелец продукта работает над тем, чтобы описания функциональности с наивысшим приоритетом соответствовали этим критериям, прежде чем они будут вынесены на собрание по планированию спринта.
Объем описания функциональности позволяет реализовать его в течение спринта.
Описания функциональности пользователей должны быть достаточно небольшими, чтобы команда могла завершить их реализацию в течение спринта. Владелец продукта вместе с командой работает над разбиением слишком больших описаний на более мелкие. Например, описание "Как представителю службы поддержки клиентов, мне нужно обращаться к данным клиентов, чтобы я мог быстрее отвечать на вопросы клиентов" может быть слишком велико для реализации в течение спринта. Его можно разбить на такие описания, как "Как представителю службы поддержки клиентов, мне нужно находить имя клиента и результаты последнего звонка по телефонному номеру клиента" и "Как представителю службы поддержки клиентов, мне нужно обращаться к полному журналу звонков клиента, чтобы я мог детально разобраться в текущей проблеме".
Описание функциональности детализировано ровно настолько, чтобы можно было описать и оценить трудозатраты, необходимые для его реализации.
Перед включением в спринт описания функциональности пользователей оцениваются в баллах. Баллы представляют собой намеренно приблизительные оценки, используемые главным образом для управления списком невыполненных работ и для подготовки к спринту. После начала спринта команда разбивает описание функциональности на задачи, необходимые для его реализации. На собрании по учету невыполненной работы по продукту команда работает с владельцем продукта, чтобы определить, по каким из описаний необходима дополнительная информация, прежде чем их можно будет разбить на задачи для оценки трудозатрат. Владелец продукта может собрать эти сведения и записать их в описание функциональности.
При этом необходимо следить за тем, чтобы в описание не добавлялись ненужные подробности. Описание функциональности пользователя должно служить основанием для бесед и обсуждений с владельцем продукта и клиентом, которые продолжаются до тех пор, пока описание не будет полностью реализовано и принято. Излишняя детализация может негативно повлиять на обсуждение, создавая обманчивое впечатление точности.
Условия приемки определены.
В конце спринта клиенты или владелец продукта либо принимают описание функциональности пользователя как завершенное (полностью реализованное), либо отклоняют его. Перед началом спринта необходимо как можно более четко определить условия приемки клиентом. Конечно, описание функциональности может быть принято по причинам, которых никто не предвидел. Однако беседы команды с клиентами помогают определить условия приемки, что способствует пониманию командой ожиданий клиентов. Условия приемки можно использовать в качестве основы для приемочных тестов; это позволяет эффективнее оценить полноту реализации описания функциональности.
Эпопеи и темы
Часто говорится, что описания функциональности пользователей должны быть небольшими. Это относится к описаниям, которые готовы к реализации. В то же время описания с меньшим приоритетом могут быть более объемными. Более того, сразу разбивать их на более мелкие не стоит во избежание чрезмерного разрастания списка невыполненных работ. Разбивать описания функциональности на более мелкие следует по мере их приближения к верху упорядоченного по приоритетам списка невыполненных работ. Большие описания функциональности пользователей удобно рассматривать как эпопеи и темы.
Эпопеи — это очень большие описания функциональности, которые представляют собой значительные объемы работ. При разбиении эпопеи можно создать множество тем и других более мелких описаний функциональности.
Темы — это достаточно большие описания функциональности, обычно объема большего, чем можно реализовать в спринте. Прежде чем команда приступит к реализации темы, ее необходимо разбить на более мелкие описания функциональности.
При ранжировании списка невыполненных работ разбивают эпопеи и темы, находящиеся в верхней части списка, и назначают приоритеты новым, более мелким описаниям. По завершении ранжирования описания функциональности с наивысшим приоритетом должны быть достаточно небольшими, чтобы их можно было реализовать. Ниже в ранжированном списке можно найти гораздо больше подробных пользовательских описаний функциональности.
Пики
Иногда команде приходится выполнять работы, не направленные непосредственно на реализацию описания функциональности пользователя. Эти работы называются пиками. Три распространенных типа пиков — исследование, задолженность по ошибкам и улучшения процесса или инженерные улучшения. Для создания пика в Team Foundation создайте рабочий элемент "описание функциональности пользователя", выберите для него тип "Пик" и затем назначьте ему приоритет в списке невыполненных работ вместе с другими описаниями функциональности.
Исследование
Исследование проводят при наличии открытых вопросов по описанию функциональности пользователя, на которые необходимо получить ответ перед полным разбиением описания на задачи и его оценкой. Например, на собрании по планированию спринта команда рассматривает описание функциональности "Как часто летающий пассажир, я могу бронировать призовые билеты". После обсуждения этого описания остается больше вопросов, чем ответов. Команда создает описание функциональности, представляющее собой пик. " Как члену команды, мне нужно понять, что означает выражение "бронировать призовые билеты", чтобы я мог писать описания для включения в будущие спринты". Команда определяет, сколько часов можно посвятить этому исследованию, и записывает это количество в качестве временных рамок пика. Ни одно из описаний, написанных в ходе пика, не может реализоваться в течение той же итерации. Эту работу необходимо запланировать на одну из будущих итераций с помощью списка невыполненных работ по продукту.
Задолженность по ошибкам
Исправлять ошибку лучше всего непосредственно тогда, когда она найдена. Если не удается устранить ошибку в тот же день, когда она была найдена, один из участников команды должен создать рабочий элемент ошибки, чтобы не потерять ее из вида. Следите за тем, чтобы ошибки не накапливались. Если у команды накапливаются ошибки, создайте описание функциональности пользователя и свяжите ошибки с пиком, чтобы его можно было оценить и назначить ему приоритет вместе с остальными описаниями функциональности и пиками.
Улучшения процесса или инженерные улучшения
Команда может предпринимать действия по улучшению процесса или внесению инженерных улучшений, призванных помочь ей в достижении успеха. Необходимость в улучшениях часто выявляется на ретроспективном собрании по спринту и на ежедневных Scrum-собраниях. Например, команде может понадобиться улучшить покрытие кода модульными тестами или снизить время построения на сервере непрерывной интеграции.