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

Вот так и работают истории. Сидни задала много вопросов «Кто?», «Что?» и «Почему?». Она осведомилась о контексте – где и когда будет подан торт, сколько человек приглашено. Во время разговора мы рассмотрели несколько разных вариантов. Мы беседовали достаточно долго для того, чтобы выработать единое понимание цели. А поскольку это далеко не первый торт, который мы заказываем у Сидни, у нас уже есть некоторое общее представление о виде и вкусе десерта, который должен попасть к нам на стол. Если бы этого не было, возможно, нам нужно было бы просмотреть несколько фотографий или попробовать несколько кусочков разных тортов, для чего телефона было бы, конечно, недостаточно.

Начните с рецепта

В ходе беседы Сидни обдумывала, как она будет делать торт. Это было необходимо, иначе она не смогла бы оценить вероятность успеть вовремя. Когда приходит время печь торт, у нее уже есть список шагов, которые нужно проделать: отмерить муку, сахар, масло, яйца, молоко и т. д. Сидни должна взбить, смешать, испечь, украсить и, наверное, выполнить еще много секретных действий, о которых я ничего не знаю. Думаю, у нее есть разные рецепты для разных видов тортов и перечень действий, которые надо выполнить для каждого торта, прежде чем он будет помещен в коробку с бантиком и готов к передаче заказчику. Если бы Сидни написала на бумаге, что ей нужно проделать, у нее получился бы рабочий план, состоящий из специфических шагов по изготовлению тортов.

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

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

Разделим торт на части

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

То же самое могло произойти, когда я обсуждал свой торт с Сидни. Я мог представлять себе какой-то особенный торт, форм для которого у Сидни бы не оказалось, или украшения, которые невозможно сделать. Я не смог бы позволить себе такой торт, а Сидни не смогла бы обещать, что изготовит его ко дню рождения моей дочери.

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

Если решение, описанное в истории, слишком дорого, рассмотрите другое, которое поможет вам достичь цели.

Но если мы все-таки способны реализовать решение, несмотря на его значительный размер, то в разбиении на более мелкие части особого смысла нет, не так ли? На самом деле не так. Последовательно выпуская небольшие части программного продукта, мы быстрее можем увидеть и проанализировать прогресс. Это позволяет людям, которые платят деньги, чувствовать себя чуть спокойнее. Кроме того, согласно стратегии Моны Лизы из главы 4, это помогает частично оценивать продукт на ранних этапах, чтобы понять, в правильном ли направлении мы движемся.