Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон

Если я пользуюсь каким-то продуктом, который мне нравится, то, уверен, я не обращаю внимания на все его крохотные детали и стоящие за ними решения. Фактически, если программа работает неплохо, я вообще не обращаю на нее слишком много внимания. Я не замечаю, как мой смартфон теряет и затем восстанавливает соединение с Интернетом. Я не концентрируюсь на том, что, обновив какой-нибудь элемент в мобильном приложении для управления задачами, сразу могу увидеть эти изменения в веб-версии. Но все это очень важные атрибуты качества, и если их не будет, я непременно это замечу. Через вашу команду прошло огромное множество деталей, но, как ни парадоксально, вам не нужно, чтобы все они были замечены пользователями. Скорее, вам нужно, чтобы они их не замечали.

Основные знания вы получаете от представителей бизнеса в своей организации, заказчиков, которые купили ваш продукт, и отдельных пользователей, которые, получив ваше приложение, будут использовать его и смогут оценить, насколько оно помогает им достичь их целей.

Бизнес-партнеры. Для них может быть достаточно добавления функциональности, критической с точки зрения привлечения новых заказчиков. Или, возможно, им достаточно полученных вами сведений о деталях, которые обязательно нужно включить в эту функциональность для обеспечения конкурентоспособности.

Заказчики. Для них может быть достаточно добавления функциональности, которая обеспечит им реальную выгоду, когда они или сотрудники их организации начнут использовать обновленное приложение.

Пользователи. Для них может быть достаточно добавления функциональности, которая обеспечит достижение ими одной из их целей.

Если вы приложили достаточно стараний в процессе дробления камней, то должны были получить много маленьких, простых в реализации частей. Каждая из этих частей позволяет вам и вашей команде что-либо узнать, но если вы сделали все правильно, это может быть не так для других групп.

Я представляю, что мы складываем вместе эти маленькие кусочки программного продукта, как детали LEGO. Я складываю их на старомодные весы с двумя чашами и противовесом на одной стороне. В качестве противовеса выступает больший кирпичик LEGO, представляющий понятие «достаточно» – достаточно, чтобы позволить пользователю выполнить задачу или достичь цели, достаточно для заказчиков, чтобы извлечь какую-то выгоду для себя, достаточно для бизнес-партнеров, чтобы они ощутили реальную помощь в достижении организацией ее целей. Как только деталей становится достаточно и их кучка перевешивает, наступает время тестировать приложение с пользователями, давать его на оценку заказчикам или бизнес-партнерам.

Вы как команда не просто коллег, но единомышленников, должны рассмотреть результаты каждой отдельной истории, чтобы изучить и улучшить не только ваш продукт, но и способ планирования и манеру взаимодействия. Получая обратную связь и обучаясь у других групп, всегда учитывайте, что означает «достаточно» для них.

На начальном этапе мы можем быть твердо уверены, что разработка идет в верном направлении, но, чтобы сохранять эту уверенность, очень важно тестировать программный продукт с участием пользователей.

Обратите внимание: я сказал «тестировать». Просто продемонстрировав пользователям программный продукт и рассказав о нем, ничему научить их не получится. Что толку, если пользователи увидят новые возможности, должны будут вообразить, как их использовать, и решить, нравится им это или нет. Это все равно что рассматривать новую машину в салоне и представлять себе, понравится ли вам ее водить. Понять, сможет ли новая функциональность помочь добиться целей, пользователи смогут только на тест-драйве продукта. Да и мы, команда, узнаем больше, наблюдая за тем, как пользователи работают с программой. Если вы и ваша команда проводили качественные обсуждения историй, то, наверное, говорили и о пользователях, о том, почему они могут оценить то, что вы разрабатываете, и как могут это использовать. Только наблюдение за ними может по-настоящему подтвердить или опровергнуть эти гипотезы.

Как только вы разработаете достаточно, чтобы позволить пользователям сделать что-то значимое для них, настало время для тестов. Тестировать можно не только совершенно новое. Вы можете, к примеру, проверить изменения или небольшие улучшения, внесенные в уже существующую функцию. Уделите немного времени наблюдению за пользователями, решающими с помощью вашего продукта реальные задачи.

Вы создали небольшую часть программного обеспечения и рассмотрели каждый небольшой кусочек как команда. Периодически вы оценивали их с представителями бизнеса в своей организации, а также с заказчиками, которые купят ваш продукт, и с пользователями, которые будут с ним работать. Но на самом деле нас интересуют не программа, а результаты, которые мы получим после того, как приложение будет предъявлено пользователям, а они приступят к работе с ним.

Как только вы почувствуете, что создали достаточно и уверены в возможности получить эти результаты, настало время выпустить ваше произведение в свет.

Обязательно нужно запланировать, что вы изучите с каждым релизом. Пожалуйста, никогда не выпускайте программный продукт просто так, чтобы потом сидеть и ждать, пока заказчики и пользователи не начнут жаловаться. Эти жалобы – тоже результаты, но, как правило, эти индикаторы не совсем своевременно отражают впечатления ваших пользователей от работы с продуктом. После каждого релиза всей командой обсуждайте, какие параметры вы можете использовать и как организовать наблюдение за пользователями своего продукта, чтобы увидеть, удалось ли вам достичь запланированных результатов. Обсудите и придите к соглашению, как вы будете:

• встраивать в продукт показатели, которые позволят вам отслеживать использование новых функциональностей;

• планировать мероприятие, на котором будете наблюдать, как пользователи работают с вашим новым продуктом.

Регулярно обсуждайте всей командой, что нового вы узнали, а затем на основе своих идей предлагайте улучшения и составляйте больше историй. Возможно, кое-что из увиденного вами будет заслуживать немедленной реализации, а все остальное отправится в бэклог возможностей.

Работая с рядом компаний и рядом продуктов, мы можем позволить себе выпускать релизы по состоянию «достаточно». Но существует довольно много компаний и продуктов (если не сказать, что их большинство), где мы обязаны выпускать релизы в определенное время. Если в этом случае эффективно использовать релизную стратегию, то можно заложить крепкую основу в начальных, дебютных историях, разработать основную часть с помощью историй миттельшпиля, а когда придет время релиза, красиво разыграть истории эндшпиля.