Пользовательские истории. Искусство гибкой разработки ПО (Паттон) - страница 172

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

Учитесь у пользователей

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

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

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

Извлекайте уроки из пользовательских релизов

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

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

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