Вовсе не требуется, чтобы при пользовательском тестировании присутствовали все члены команды: пользователей будет смущать слишком большое количество наблюдателей. Но все-таки пользовательские тесты вызывают сопереживание – то, чего вы не сможете добиться никаким другим способом. Видеть пользователей, которые работают с вашим продуктом с трудом и без всякого удовольствия, хотя вы были уверены, что все хорошо, – мощнейший мотиватор. Если вы присутствовали при пользовательском тестировании, поделитесь с остальными тем, что видели, излагая им истории.
После такого тестирования вы составите перечень проблем, которые нужно исправить, а также улучшений, которые можно внести. Для каждого из этих элементов нужно приготовить карточку истории со своими идеями по усовершенствованию продукта.
Разрабатывайте, чтобы изучать
Если вы твердо уверены в том, что использование историй предотвратит создание вашей командой плохих программных продуктов, то вы правы по меньшей мере наполовину. И в самом деле, если несколько умных людей собираются вместе, концентрируются на осознании проблем пользователей и обсуждают, как решить их с помощью программного продукта, который они создают, – это огромный шаг в сторону значительного улучшения этого продукта. Но все-таки надо признать, что разработка программного обеспечения – не работа на конвейере. Вы не просто создаете одинаковые виджеты один за другим, штуку за минуту. Каждая история, которую мы создаем и затем реализуем в наших продуктах, представляет собой что-то новое.
Гуру разработки Agile, уже упоминавшийся здесь мой друг Алистер Коберн, однажды сказал мне: «В бэклог историй нужно отправлять не одну написанную тобой историю, а три».
На мой вопрос «Почему?» он ответил: «Просто делай это».
«Что же мне писать в двух других историях?» – спросил я.
«Не имеет никакого значения».
«Что ты имеешь в виду? – удивился я. – Мне же нужно там что-то написать!»
«Ну хорошо, – сказал Алистер, – если тебе так уж нужно, запиши то, что хочешь разработать, на первой карточке, а на второй напиши: “Исправить первую карточку”. Потом на третьей – “Исправить вторую”. Если ты не пройдешь этот цикл трижды для каждой истории, то никогда ничему не научишься».
В традиционном процессе разработки учебу принято связывать с расширением объема разработки или плохими требованиями. В процессе Agile учеба – это ваша цель. Нужно запланировать, что вы изучите при каждой разработке. Кроме того, нужно заложить в план то, что время от времени вы будете терпеть неудачу.
Стратегия Эрика, которую мы рассматривали в главе 3, помогла ему реализовывать небольшие решения и выполнять итерации до тех пор, пока они не становились жизнеспособными. Эрик получал новые знания с каждым выпуском.
Стратегия Моны Лизы, использованная Майком и Аароном из главы 4, помогла им разделить каждую историю на маленькие компактные части, которые, правда, нельзя было представить пользователям, но они позволяли ребятам обучаться быстрее и управлять бюджетом разработки, в результате чего работа была завершена вовремя.
Это две замечательные стратегии обучения. Попробуйте их. Изобретите собственную. Только, пожалуйста, не думайте, что вы правы всегда и во всем! Уверяю, вас ждет великое разочарование.
Не только программы
В 2011 году Кент Бек – создатель метода историй – начал одну из первых конференций Lean Startup с пересмотра манифеста Agile. Будь на его месте, например, я, это было бы, пожалуй, святотатством; но Кент, один из авторов манифеста, знал, что делает. Он пересмотрел принцип, касающийся работающего ПО, и отныне он читается так: «Эмпирическое обучение важнее работающего продукта».
Если вы помните из главы 3, эмпирическое обучение – важнейшая концепция, родившаяся из процессов Lean Startup. Ключевое слово здесь – обучение. Эмпирическое обучение означает, что сначала мы обсуждаем, что именно хотим изучить в процессе какой-то разработки, а затем возвращаемся назад и оцениваем результаты, по которым видно, узнали мы что-то полезное или нет. Кстати, как оказалось, совсем не обязательно для изучения разрабатывать программный продукт, но, как правило, что-то создать или предпринять какие-то действия все-таки нужно.
Мне нравится использовать истории для управления работой по созданию простых прототипов или планированием пользовательских тестов либо интервью. Мне нравится говорить о том, кто это делает, что нужно сделать и почему. Я люблю сначала договориться о том, что мы делаем, а уж потом приступить к работе. Закончив работу, я анализирую ее результаты, чтобы оценить, удалось ли изучить что-нибудь.
Попробуйте метод историй для организации любой работы независимо от того, касается она разработки программных продуктов или нет.
Планируйте изучение и учитесь планировать
Карты историй полезны для разбиения большого продукта или идеи функциональности на меньшие части. В главах 3 и 4 описано разделение этих меньших частей на фрагменты, удобные для разработки, притом что каждый фрагмент сконцентрирован на изучении чего-то. Но есть еще один способ дробления большого объема работы, вы должны познакомиться с ним и стараться держать его в голове. С помощью этого способа историю можно преобразовать в план работы, который в итоге обеспечит результат. Об этом мы поговорим в следующей главе.
Глава 10. Истории готовят как торты
Две недели назад был день рождения моей дочери и нам нужен был торт. У нашей семьи есть собственный кондитер, у которой мы заказываем торты всегда. Не сказать, что мы очень богаты или не умеем печь торты сами, просто Сидни, наш кондитер, делает удивительные, невероятно вкусные торты. Я не знаю точно, какой кулинарной магией она пользуется, чтобы создать такое чудо, но, когда ни спросишь моих детей, какой торт они хотят на день рождения, ответ всегда один: «Мы хотим торт Сидни!» – и от заказа уже не отвертеться.
Чтобы у нас появился торт, я звоню Сидни по телефону. Она всегда спрашивает, для кого торт и по какому случаю. Две недели назад я сказал ей, что Грейс скоро исполнится 12. «А чем она сейчас увлекается?» – спросила Сидни. Мы немного поговорили о Грейс, ее вкусах и интересах. После этого мы обсудили формы тортов, имеющиеся у Сидни, а также подумали, как можно украсить торт, чтобы он был готов вовремя. В этот раз мы остановились на торте в форме птички.
Вот так и работают истории. Сидни задала много вопросов «Кто?», «Что?» и «Почему?». Она осведомилась о контексте – где и когда будет подан торт, сколько человек приглашено. Во время разговора мы рассмотрели несколько разных вариантов. Мы беседовали достаточно долго для того, чтобы выработать единое понимание цели. А поскольку это далеко не первый торт, который мы заказываем у Сидни, у нас уже есть некоторое общее представление о виде и вкусе десерта, который должен попасть к нам на стол. Если бы этого не было, возможно, нам нужно было бы просмотреть несколько фотографий или попробовать несколько кусочков разных тортов, для чего телефона было бы, конечно, недостаточно.
Начните с рецепта
В ходе беседы Сидни обдумывала, как она будет делать торт. Это было необходимо, иначе она не смогла бы оценить вероятность успеть вовремя. Когда приходит время печь торт, у нее уже есть список шагов, которые нужно проделать: отмерить муку, сахар, масло, яйца, молоко и т. д. Сидни должна взбить, смешать, испечь, украсить и, наверное, выполнить еще много секретных действий, о которых я ничего не знаю. Думаю, у нее есть разные рецепты для разных видов тортов и перечень действий, которые надо выполнить для каждого торта, прежде чем он будет помещен в коробку с бантиком и готов к передаче заказчику. Если бы Сидни написала на бумаге, что ей нужно проделать, у нее получился бы рабочий план, состоящий из специфических шагов по изготовлению тортов.
То же самое происходит, когда кто-то приносит историю в команду разработки. Все вместе принимают решение, какой именно продукт нужно создать, и команда составляет план, содержащий много задач на разработку. В команду разработки, кроме программистов, входят тестировщики, графические дизайнеры, технические писатели и прочие специалисты, чьи навыки необходимы для создания программного обеспечения, поэтому далеко не все задачи связаны с написанием кода. Этот план никогда не составляется при обсуждении истории, так же как и Сидни ничего не планировала, пока не поговорила со мной по телефону. План появится после того, как члены команды ознакомятся с историей, сделают заметки, нарисуют эскизы и уточнят множество деталей. Во всяком случае, так все должно происходить.
Разговаривая с Сидни, я не рассказывал про стаканы сахара и муки. Я никогда не буду излагать истории процесса выпечки, если только не возьмусь разрабатывать духовку. Поэтому, когда вы составляете истории работы с программным продуктом и собираете перечень названий имеющихся историй, вы должны представлять, что ваш программный продукт уже готов. Сидни не погружалась в детали приготовления торта, а просто уточнила, для кого он, что любит моя дочка, сколько людей будет на вечеринке, и выяснила множество других подробностей, которые помогли нам вместе решить, какой торт подойдет лучше всего. Сидни не просто поинтересовалась моими пожеланиями – фактически мы работали вместе, чтобы решить, как сделать самый лучший торт. Это было самое настоящее обсуждение истории.
Разделим торт на части
Есть еще одна важная вещь. Проблемы возникают, когда, начав разговор с людьми, которые действительно способны воплотить в жизнь наши идеи, мы обнаруживаем, что программный продукт, описанный историей, очень большой. Да, карточка, на которой записана история, того же размера, что и другие, а цель, которую должны достичь пользователи, может быть не важнее остальных, но тем не менее при обсуждении выясняется, что реализация программного продукта, необходимого для достижения этой цели, займет очень много времени.