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

Проблема была в том, что одна карточка могла представлять собой нечто, внедрение чего в продукт заняло бы у разработчика несколько часов. Или дней. Или недель. Или целый месяц – кто знает? Точно не я – во всяком случае, пока мы не начнем говорить об этом.

Начав обсуждение истории во время работы над своим первым проектом Agile, я невольно вызвал неприятный спор, когда оказалось, что история слишком велика. Мне хотелось, чтобы он был реализован в течение следующей итерации, но разработчики, с которыми я разговаривал, доказали мне, что это невозможно. У меня было смутное ощущение, что я что-то делаю не так. Разработчики выделили небольшую часть, о внедрении которой на следующей итерации можно было говорить, но я был раздражен тем, что нам не удалось поговорить масштабно, рассмотрев все в целом. На самом деле мне хотелось знать, сколько времени займет разработка большой функциональности, которую хотелось получить в итоге. Я надеялся, что дискуссия поможет мне оценить это, но ничего не вышло.

В 2001 году я покинул команду, где тогда работал, и начал изменять привычный ход событий. Я и моя команда пытались выработать такой подход к работе с историями, который позволял бы сконцентрироваться на полной картине. Мы разрабатывали общее видение нашего продукта, вместе находили компромиссы и соглашения. У нас было множество карточек с заголовками историй, с помощью которых мы организовывали свои идеи, а также разбивали большую картину на мелкие части, которые отправляли в очередь на разработку. В 2004 году я написал первую статью о таком принципе работы, но не употреблял термин «карты историй» до 2007 года.

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

Впервые я услышал определение паттерна от своей подруги Линды Райзинг: когда вы кому-то рассказываете о своей грандиозной идее, а он отвечает, что тоже придумал и использует что-то подобное, это значит, что вы не изобрели нечто новое, а открыли паттерн.

Карты пользовательских историй – это паттерн. К нему прибегают разумные люди, чтобы составить представление о целом продукте или о целой функциональности. Они также используют этот метод, чтобы разбить большие истории на меньшие части. Но если вы не пришли к этому самостоятельно, не расстраивайтесь! Скорее всего, вам бы это удалось. Но чтение этой книги сэкономит недели и месяцы бесплодных поисков.

Сегодня компании одна за другой перенимают идею карт пользовательских историй. Моя подруга Мартина, работающая в SAP, в письме, написанном в сентябре 2013 года, сообщила: «…К настоящему моменту было проведено более 120 заседаний рабочих групп по картам пользовательских историй. Они так понравились многим представителям заказчиков! Это отлично зарекомендовавший себя рабочий подход в SAP».

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

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

Несколько лет назад я познакомился с Гэри Левиттом. Гэри был бизнесменом и как раз запускал новый веб-продукт. Этот продукт и сейчас работает, он называется Mad Mimi, что согласно задумке Гэри означало «маркетинговый интерфейс музыкальной индустрии»[6]. Гэри музыкант, и у него есть собственная группа. Он самостоятельно занимался административными делами, а кроме того, помогал управляться с ними и другим, работал в музыкальной студии и делал записи для клиентов.

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

Гэри нужно было, чтобы кто-то разработал этот продукт, поэтому он сотрудничал с другим человеком, и этот другой человек работал в Agile. Он попросил Гэри написать список всего, что он хотел бы видеть в продукте, и расставить элементы списка по важности. Затем они бы обсудили верхние, самые важные элементы и начали создавать их один за другим. В Agile такой список функций обычно называется бэклогом, и, по мнению Гэри, было вполне разумно так и поступить: составить список и начать с самых важных вещей. Так он и сделал.

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

Я был знаком с человеком, работавшим с Гэри. Мой друг видел, что Гэри вне себя от беспокойства, и очень хотел ему помочь. Кто-то из наших общих знакомых спросил меня, не хочу ли я поговорить с Гэри и помочь ему организовать его идеи. Мы познакомились и договорились встретиться в его офисе на Манхэттене.

Беседа началась. По мере того как Гэри рассказывал, я записывал ключевые слова его идей на карточках. У меня есть что-то вроде мантры, я люблю ее повторять, когда составляю карты пользовательских историй. Она звучит как «говорите и пишите», что означает: не дайте словам пропасть втуне. Запишите их на карточки, к которым сможете обратиться позднее. Вы удивитесь тому, как взгляд на пару слов, записанных на карточке, вызывает в памяти целое обсуждение. Мы можем двигать карточки по столу, выстраивая их в разном порядке. Мы начинаем использовать полезные слова вроде «это» и «то», означающие записанное на карточках. Это экономит уйму времени. Я должен был заставить Гэри вытащить свои мысли наружу – это крайне важно для обеспечения общего мнения. Для него это было непривычно, но я без труда фиксировал идеи на карточках по мере того, как он их излагал.