То же самое могло произойти, когда я обсуждал свой торт с Сидни. Я мог представлять себе какой-то особенный торт, форм для которого у Сидни бы не оказалось, или украшения, которые невозможно сделать. Я не смог бы позволить себе такой торт, а Сидни не смогла бы обещать, что изготовит его ко дню рождения моей дочери.
В главе 7 я сказал, что, если решение, которое мы приняли, оказалось слишком дорогим, нужно сделать шаг назад и реалистично оценить проблемы, которые мы пытаемся решить, и результаты, которые надеемся получить. Затем нужно рассмотреть имеющиеся альтернативы. Таким образом, у нас будет торт поменьше или, может быть, просто пирог.
Если решение, описанное в истории, слишком дорого, рассмотрите другое, которое поможет вам достичь цели.
Но если мы все-таки способны реализовать решение, несмотря на его значительный размер, то в разбиении на более мелкие части особого смысла нет, не так ли? На самом деле не так. Последовательно выпуская небольшие части программного продукта, мы быстрее можем увидеть и проанализировать прогресс. Это позволяет людям, которые платят деньги, чувствовать себя чуть спокойнее. Кроме того, согласно стратегии Моны Лизы из главы 4, это помогает частично оценивать продукт на ранних этапах, чтобы понять, в правильном ли направлении мы движемся.
Если решение, описанное в истории, требует большого объема работы, но все же реализуемо, разбейте его на небольшие части, что позволит вам раньше оценить результаты и анализировать прогресс.
В разбиении больших историй на меньшие части есть небольшая хитрость, которая позволяет мне придерживаться аналогии с тортом. Если вы любите торты, то, наверное, у вас уже текут слюнки? Наверняка вы представляете себе какой-то особенно вкусный десерт. Простите меня за это.
Так вот, давайте представим, что наша история описывает создание очень большого торта, например многоярусного свадебного, которым будут угощаться несколько сотен людей. Если это так, то речь идет не о стаканах муки и сахара, а о мешках. Большинство людей разделит программный продукт на части аналогичным образом. Получатся не мелкие задачи по графическому дизайну, бизнес-логике и взаимодействию с базой данных, а огромные пласты работы. Но вспомните: программный продукт все-таки не торт. Отмерить два фунта муки ненамного дольше, чем два стакана, но создание 20 экранов пользовательского интерфейса займет куда больше времени, чем разработка двух. Поэтому если команда использует для разбиения подобную простую структуру, что на первый взгляд логично, то в результате получатся задачи на разработку бизнес-логики, интерфейса и прочего, каждая из которых требует нескольких недель труда. Прибегнув к такой стратегии, мы будем вынуждены ждать очень долго, прежде чем сможем, образно говоря, попробовать хоть какой-нибудь торт. Не поступайте так.
Не разбивайте большие задачи на большие части. Разбивайте большие задачи на мелкие части с компактными планами.
Сейчас наша аналогия немного затрещит по швам, но вскоре будет восстановлена. Способ, который сработает в отношении большого программного торта, – это разбиение его на множество маленьких капкейков[22]. Каждый из них является законченным продуктом, а кроме того, рецепты всех примерно одинаковы: немного сахара, немного муки, одно-два яйца и т. д.
Ладно, давайте наконец настроимся серьезно. Программный продукт не торт. Он может разрастись до невероятных размеров, потребовать огромных денежных затрат и вызвать серьезные риски. Работая над этим текстом, несколько минут назад я услышал в утренних новостях по телевизору историю о том, как пользователи не могли зарегистрироваться на правительственном сайте США по вопросам здравоохранения. Конечно, критиковать постфактум легко, но все-таки нетрудно понять, что никто не попробовал этот торт, прежде чем он был подан на воображаемой свадьбе, никто не знал даже примерно, каков он на вкус. В результате этот полусырой десерт провалил всю вечеринку.
Если вы когда-нибудь участвовали в разработке программного обеспечения традиционным способом, то, наверное, привыкли разбивать большую работу на большие задачи. У меня есть такой опыт. На первый взгляд кажется противоестественным разбивать что-то большое на небольшие части, которые не совсем похожи на конечный продукт, запланированный вами. Вы знаете, что для комбинирования всех этих частей в один продукт нужно будет немного поработать, слегка переписав и скорректировав каждый кусочек, чтобы их можно было объединить. Но помните: у этого подхода очень хорошие основы. Одна из главных, на которых базируется его выбор, – избегание рисков, связанных с тем, что вы видите, используете, пробуете новый продукт слишком поздно. Вы разбиваете продукт на много маленьких продуктов для того, чтобы начать изучение поскорее.
Если бы мне нужно было разбить на части большой торт, чтобы поскорей его попробовать и оценить внешний вид, мне отлично подошло бы изготовление маленьких капкейков, которые быстро дали бы результаты. Скажем, я испек бы несколько штук из разных видов муки, попробовал их все, отметил самый вкусный и был бы уверен, что сделал хороший выбор. Если бы меня волновали цвет и украшения, я хотел бы увидеть несколько капкейков, оформленных в разных стилях, и выбрал бы самый красивый из них.
В производстве программ капкейкам соответствуют порции работающего программного обеспечения, которые позволяют пользователям оценить, могут ли они эффективно решить свои задачи. Это могут быть фрагменты, позволяющие выявить технические риски. И каждая часть даст нам новые знания.
Но горка капкейков не может быть свадебным тортом… или может?[23]
Программный продукт не торт. Поэтому все кусочки программы, которые мы выпускаем, складываются в один большой работающий продукт, чего не получится в случае торта.
Мой друг Люк Хоуман привел забавную поговорку: «Половина готового торта и наполовину готовый торт – не одно и то же». Половины готового пирога может быть недостаточно для всех гостей на свадьбе, но ее хватит, чтобы все смогли отведать его и с нетерпением ждать добавки.
Глава 11. Как дробить камни
Изначальная идея историй очень проста: запишите что-то на карточке, обсудите это, согласуйте, что будете разрабатывать. А после завершения разработки закончите цикл анализом того, что у вас вышло и чему это можно научить. Вот и все – не правда ли, просто? Если вы хоть немного работали в сфере разработки программного обеспечения, то знаете, что ничего простого тут нет. Истории проходят долгий пусть с множеством обсуждений, вовлечением множества людей, чтобы сначала продвинуть идею продукта, функциональности или улучшения, а потом продвинуть этот продукт на рынке. Хорошая новость в том, что вы можете использовать истории и их изложение на протяжении всего пути. И я обещаю, что, положившись на метод историй, вы окажете себе значительную услугу.
Размер имеет значение
В предыдущей главе мы остановились на торте Сидни и идее разделения больших тортов на маленькие тортики. Но программный продукт – несколько менее осязаемая вещь, и, в отличие от торта, его нельзя измерить в дюймах, сантиметрах, унциях или граммах.
Изначальная идея заключалась в том, что пользователь или другое лицо, которое в чем-то нуждается, может записать свою потребность на карточке, а затем мы можем это обсудить. Тот, от кого поступил запрос, не заботился о том, много ли времени потребуется на решение его проблемы, – он просто сформулировал потребность как она есть.
С точки зрения пользователя размер истории верен, если он удовлетворяет его потребность.
Когда приходит время писать код, можно оценить значительные преимущества программирования, тестирования и интеграции программного продукта по небольшим частям. Если я смогу вскоре увидеть и протестировать маленькие части, значит, смогу и судить о том, как быстро продвигается наша разработка и каков ее уровень качества. Если я могу разделить что-то большое на много маленьких частей, членам моей команды легче брать в работу и выпускать эти части одновременно. Можно взять за правило делить истории на части такого размера, чтобы на их программирование и тестирование требовалось не более нескольких дней.
С точки зрения команды разработки, размер истории верен, если программирование и тестирование занимает не более пары дней.
Но с точки зрения бизнеса может быть более разумно предъявлять пользователям и заказчикам программное обеспечение, содержащее набор нескольких функциональностей. Если вы выпускаете совершенно новый продукт, первая версия может быть довольно большой. Эту версию я ранее называл минимально жизнеспособным решением, и основной целью его разработки было получение особых результатов от выделенной группы пользователей. В идеале бизнес должен стремиться к тому, чтобы почаще и побольше выпускать таких продуктов, размер которых оптимален для пользователей или для получения результатов, отвечающих потребностям бизнеса. Но если вашим продуктом пользуется большая разношерстная группа клиентов и у вас нет инфраструктуры или бизнес-модели, поддерживающей более последовательный процесс релиза, то, конечно, ваши бизнес-релизы могут быть довольно большими.
С точки зрения бизнеса размер истории верен, если он позволяет бизнесу достичь желаемых результатов.
Я мог бы сказать, что правильного размера историй не существует, но это не так. Правильный размер – тот, который соответствует проходящему обсуждению.
Эти большие истории содержат много меньших, которые, в свою очередь, содержат много еще меньших историй. В зависимости от того, с кем вы говорите, возможно, придется перевести обсуждение на более высокий уровень.