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

Если решение, описанное в истории, требует большого объема работы, но все же реализуемо, разбейте его на небольшие части, что позволит вам раньше оценить результаты и анализировать прогресс.

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

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

Не разбивайте большие задачи на большие части. Разбивайте большие задачи на мелкие части с компактными планами.

Сейчас наша аналогия немного затрещит по швам, но вскоре будет восстановлена. Способ, который сработает в отношении большого программного торта, – это разбиение его на множество маленьких капкейков[22]. Каждый из них является законченным продуктом, а кроме того, рецепты всех примерно одинаковы: немного сахара, немного муки, одно-два яйца и т. д.

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

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

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

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

Но горка капкейков не может быть свадебным тортом… или может?[23]

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