В процессе, известном как гибкое управление проектами Agile, команды разработчиков работают «короткими очередями», или «спринтами», разрабатывая рабочие версии продукта или отдельные программы в тесном сотрудничестве с заказчиком или конечным пользователем.
Взгляд на происходящее глазами вашего пользователя — ключ к успеху гибкого управления проектами, поскольку это позволяет оценить цели и процесс их достижения со стороны; для этого существует эффективный способ — создание «пользовательских историй». По сути, это краткие и доступные описания пожеланий и стремлений пользователя с его точки зрения. Они обеспечивают командам принятие клиентоориентированных решений, определяя потребности клиентов как основу управления проектами.
В этой статье мы объясним, как создаются и используются пользовательские истории, а также рассмотрим их преимущества и недостатки.
Понятие пользовательских историй
Термин “пользовательские истории” возник в конце 1990-х годов на основе гибкой методологии разработки программного обеспечения экстремального программирования (Extreme Programming, XP).
Пользовательские истории — простой способ определить необходимые клиенту функциональные возможности продукта. Клиент сотрудничает с командой разработчиков, чтобы создать пользовательскую историю, — и в итоге она написана с точки зрения клиента, а не разработчика. Это помогает персоналу понять ответы на вопросы, “кто?”, “что?” и “зачем?”, которые повлияют на цели проекта.
Пользовательские истории позволяют разработчикам и инженерам использовать свои опыт и творческий потенциал для создания наилучшего для клиента решения проблемы, вместо производства стандартного продукта “для всех и ни для кого”, для которого не нужен высокий уровень навыка. Подход помогает получить от инженеров максимальную отдачу и повысить их самооценку. Такой демократичный способ управления дает определенной преимущество по сравнению с традиционным «командно-административным» подходом к управлению проектами.
Пользовательские истории обычно связаны с разработкой программного обеспечения, но также могут использоваться другими проектными группами, такими как служба поддержки клиентов или финансовый отдел.
Эксперт по Agile-разработке Майк Кон, автор книги «Пользовательские истории. Гибкая разработка программного обеспечения» 2004 года выпуска, полагает, что пользовательские истории должны создаваться на основе следующего шаблона:
как [тип пользователя], я хочу [какая-то цель], чтобы [какая-то причина]
Например, предположим, что вам нужен веб-сайт для магазина садовой мебели. После обсуждения требований с разработчиком описание вашей пользовательской истории может выглядеть следующим образом: «Как покупатель, я хочу иметь возможность добавлять несколько товаров в свою корзину, чтобы сэкономить время».
Описание — это не вся пользовательская история, а только «начало разговора», которое затем обсуждается командой разработчиков на «летучках». “Летучки”, или “Scrum-встречи”, поощряют сотрудничество и информируют о проблемах, в частности, об изменении требований клиентов.
Пользовательские истории чаще всего записываются на карточках или стикерах, а затем размещаются на физической или виртуальной доске, чтобы все члены команды могли иметь к ним доступ и обсуждать их.
Пользовательские истории не следует путать со «сценариями использования» (user cases). Как и пользовательские истории, сценарии использования описывают взаимодействие между проектом и пользователем. Но там, где пользовательские истории представляют собой небольшие и краткие описания с точки зрения заказчика, сценарии использования имеют гораздо больший охват и сосредоточены на деталях и реализации работы, а не на ее результате или цели.
Создание пользовательских историй
В 2001 году Рон Джеффрис, один из соучредителей XP, описал компоненты истории пользователя с помощью своей модели «3 C’s», которая расшифровывается как карточка (card), обсуждение (conversation) и подтверждение (confirmation).
Карточка
Заказчик и команда разработчиков продукта согласовывают пользовательскую историю, и она записывается на каталожной карточке. Описание содержит достаточно информации для определения требований к проекту.
Консультант по программному обеспечению Билл Уэйк разработал рекомендации INVEST, описывающие, какими должны быть хорошие пользовательские истории:
- Независимые (Independent). Пользовательские истории должны быть самодостаточными и оригинальными, чтобы их можно было планировать и внедрять в любом порядке.
- Обсуждаемые (Negotiable). Пользовательские истории могут быть переписаны или согласованы во время разработки. В них должны быть отражены основные идеи, а дополнительные детали можно обсудить с заказчиком.
- Ценные (Valuable). Основой пользовательской истории должна быть ее ценность для клиента.
- Измеримые (Estimable). Успешная пользовательская история дает достаточную измеримость объема работ, чтобы клиент мог запланировать дату получения продукта.
- Небольшие (Small). Пользовательские истории должны быть небольшими, чтобы соответствовать объему работы, не превышающему нескольких недель. Если работа над историей требует больше времени, возможно ее придется разбить на фрагменты.
- Тестируемые (Testable). Пользовательская история должна содержать достаточно информации, позволяющей провести разработку тестов.
Обсуждение
Важно, чтобы команда разработчиков и заказчик продолжали обмениваться мыслями и идеями, возникающими в процессе работы. Любые дополнительные сведения, например, расширение описания, добавляются в карточку.
Разработчики также требуют, чтобы карточка содержала четкие «критерии приемлемости» — условия, которым должен удовлетворять продукт, чтобы быть принятым покупателем. Используя предыдущий пример, критерием приемлемости для покупателя, использующего веб-сайт, будет: «Оплату можно произвести картами банков А, Б и В».
Критерии приемлемости означают наличие элементов, которые могут помочь при создании приемочных тестов, на основе которых инженеры начнут разработки.
Может оказаться полезным оценить персонажей пользовательских историй и создавать истории для определенного типа пользователей, а не «для всех». Например, вашим конечным пользователем может быть менеджер по персоналу, специалист по смене профессии или случайный пользователь. Вы можете «конкретизировать» каждого клиента, указав такие детали, как его цели и вероятные повседневные проблемы.
Подтверждение
Заключительная глава пользовательской истории состоит в подтверждении заказчиком ее успешных разработки и внедрения. Проект может быть утвержден после того, как заказчик убедится, что критерии приемлемости и «завершения работ» определены.
Пользовательская история, включающая в себя множество функций и деталей, называется «эпопеей». В таком случае она обычно разбивается на несколько небольших пользовательских историй, каждая из которых может уместиться в один спринт. Набор историй, связанных друг с другом, называется «темой».
Преимущества и недостатки пользовательских историй
Пользовательские истории предлагают гибкий, основанный на сотрудничестве подход к управлению проектами, который расширяет возможности членов команды, использует их опыт и доходчиво доносит информацию до конечных пользователей. Они также обладают следующими преимуществами:
- Даже пользователям без достаточного опыта в разработке легко писать и понимать их.
- Краткая пользовательская история, записанная на карточке, побуждает проектную команду обсуждать идеи и сосредотачиваться на них, не отвлекаясь на посторонние детали.
- Пользовательские истории предлагают быстрый способ определения потребностей клиентов и подходящих способов реагирования, а содержащаяся в них информация доступна всем участникам проекта.
- Акцент на регулярные обсуждения и общение снижает вероятность ошибочного толкования и несогласованности действий.
Когда пользовательские истории должным образом сформированы, они очень эффективны и в них мало недостатков. Одно из ограничений заключается в том, что клиенты не всегда адекватно воспринимают эту концепцию. Они могут предположить, что пользовательская история — это всего лишь начальное описание. Но без дополнительных деталей, возникающих в результате обсуждений, и критериев приемлемости пользовательская история будет неполной.
Кроме того, учитывая совместный и договорный характер процесса, достаточно сложно предсказать дату завершения сложного проекта, основанного на пользовательских историях.