Вы как команда не просто коллег, но единомышленников, должны рассмотреть результаты каждой отдельной истории, чтобы изучить и улучшить не только ваш продукт, но и способ планирования и манеру взаимодействия. Получая обратную связь и обучаясь у других групп, всегда учитывайте, что означает «достаточно» для них.
Учитесь у пользователей
На начальном этапе мы можем быть твердо уверены, что разработка идет в верном направлении, но, чтобы сохранять эту уверенность, очень важно тестировать программный продукт с участием пользователей.
Обратите внимание: я сказал «тестировать». Просто продемонстрировав пользователям программный продукт и рассказав о нем, ничему научить их не получится. Что толку, если пользователи увидят новые возможности, должны будут вообразить, как их использовать, и решить, нравится им это или нет. Это все равно что рассматривать новую машину в салоне и представлять себе, понравится ли вам ее водить. Понять, сможет ли новая функциональность помочь добиться целей, пользователи смогут только на тест-драйве продукта. Да и мы, команда, узнаем больше, наблюдая за тем, как пользователи работают с программой. Если вы и ваша команда проводили качественные обсуждения историй, то, наверное, говорили и о пользователях, о том, почему они могут оценить то, что вы разрабатываете, и как могут это использовать. Только наблюдение за ними может по-настоящему подтвердить или опровергнуть эти гипотезы.
Как только вы разработаете достаточно, чтобы позволить пользователям сделать что-то значимое для них, настало время для тестов. Тестировать можно не только совершенно новое. Вы можете, к примеру, проверить изменения или небольшие улучшения, внесенные в уже существующую функцию. Уделите немного времени наблюдению за пользователями, решающими с помощью вашего продукта реальные задачи.
Извлекайте уроки из пользовательских релизов
Вы создали небольшую часть программного обеспечения и рассмотрели каждый небольшой кусочек как команда. Периодически вы оценивали их с представителями бизнеса в своей организации, а также с заказчиками, которые купят ваш продукт, и с пользователями, которые будут с ним работать. Но на самом деле нас интересуют не программа, а результаты, которые мы получим после того, как приложение будет предъявлено пользователям, а они приступят к работе с ним.
Как только вы почувствуете, что создали достаточно и уверены в возможности получить эти результаты, настало время выпустить ваше произведение в свет.
Обязательно нужно запланировать, что вы изучите с каждым релизом. Пожалуйста, никогда не выпускайте программный продукт просто так, чтобы потом сидеть и ждать, пока заказчики и пользователи не начнут жаловаться. Эти жалобы – тоже результаты, но, как правило, эти индикаторы не совсем своевременно отражают впечатления ваших пользователей от работы с продуктом. После каждого релиза всей командой обсуждайте, какие параметры вы можете использовать и как организовать наблюдение за пользователями своего продукта, чтобы увидеть, удалось ли вам достичь запланированных результатов. Обсудите и придите к соглашению, как вы будете:
• встраивать в продукт показатели, которые позволят вам отслеживать использование новых функциональностей;
• планировать мероприятие, на котором будете наблюдать, как пользователи работают с вашим новым продуктом.
Регулярно обсуждайте всей командой, что нового вы узнали, а затем на основе своих идей предлагайте улучшения и составляйте больше историй. Возможно, кое-что из увиденного вами будет заслуживать немедленной реализации, а все остальное отправится в бэклог возможностей.
Результаты по расписанию
Работая с рядом компаний и рядом продуктов, мы можем позволить себе выпускать релизы по состоянию «достаточно». Но существует довольно много компаний и продуктов (если не сказать, что их большинство), где мы обязаны выпускать релизы в определенное время. Если в этом случае эффективно использовать релизную стратегию, то можно заложить крепкую основу в начальных, дебютных историях, разработать основную часть с помощью историй миттельшпиля, а когда придет время релиза, красиво разыграть истории эндшпиля.
А сейчас я должен напомнить вам несколько горьких истин о разработке программного обеспечения.
Программное обеспечение никогда не бывает законченным.
Вы закончили реализацию каждой истории, которые ваша команда взяла в разработку в очередном коротком цикле. Но, скорее всего, вы не закончили каждую историю, которую представляли себе на начальном этапе или считали необходимым реализовать по итогам изучения. Вы используете эффективную стратегию разработки, однако ваш продукт будет хорош настолько, насколько этого можно достичь в заданное время.
Результаты всегда непредсказуемы.
Независимо от того, сколько работы вы проделали, чтобы убедиться в том, что разработка идет в верном направлении, пользователи чаще всего будут вести себя совершенно не так, как вы ожидали. Поэтому планируйте, как извлекать уроки из каждого релиза. Планируйте изменения, которые вы внесете на основе того, что вам удалось узнать.
Улучшения, внесенные после релиза, самые ценные.
Самые удивительные открытия и самые полезные уроки вы извлечете, когда пользователи начнут решать реальные задачи с помощью вашего продукта. Если вы выделили время на то, чтобы увидеть и измерить реальные результаты, то будете вознаграждены за это, когда пользователи по-настоящему полюбят ваш продукт, а организация начнет получать прибыль.
Используйте карты для оценки готовности релиза
Вы продвигаете свой продукт к релизу – историю за историей. Как только намеченная вами дата релиза начинает угрожающе приближаться (а такая дата есть всегда), задайтесь вопросом о каждой основной пользовательской линии действий: «Если бы нужно было выпустить продукт прямо сейчас, какую оценку мы бы поставили сами себе?» Если вы используете буквенные оценки вроде тех, что приносят из школы мои дети, то в конце концов получите целый табель для своего продукта.
Например, если у вас продукт или функциональность с пятью основными линиями действий пользователей, а в табеле написано: A, A-, B+, D, B+[33], то, разумеется, за оставшиеся до релиза недели вам следует сосредоточиться на той части, которая получила оценку D. Если в конце релиза вы получаете только А и В, это довольно хорошо. Конечно, быть круглым отличником лучше, но уложиться в срок в мире разработки гораздо важнее.
По мере приближения к дате релиза регулярно все вместе оценивайте готовность продукта. Уверяю вас, это очень интересно.
Книга тоже подходит к концу. Если вы дочитали до этого места, то, наверное, можете высказать мнение и о ее готовности к релизу. Вы можете открыть оглавление и поставить буквенную оценку каждой главе. Затем сфотографируйте страницу на смартфон и отправьте мне – будет очень интересно увидеть, что получилось.
Конец или не конец?
Как и любой хороший программный продукт, на самом деле эта книга не закончена. На протяжении всего текста я приводил множество удивительных примеров, о которых узнал от своих друзей и знакомых. Они рассказывали мне замечательные истории использования историй и карт историй. Еще больше историй так и осталось на моем жестком диске, и я ужасно расстроен,
