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

 

Размер имеет значение

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

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

С точки зрения пользователя размер истории верен, если он удовлетворяет его потребность.

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

С точки зрения команды разработки, размер истории верен, если программирование и тестирование занимает не более пары дней.

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

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

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

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

 

Истории похожи на камни

Воспринимайте истории как камни. Если я возьму очень большой камень, положу его посреди комнаты, а затем разобью молотом на 30 осколков, мы назовем их 30 осколками камня. Если вы возьмете один из этих меньших камней и тоже ударите по нему молотом, он разобьется на более мелкие части. Мы и их можем назвать осколками камня. Или подойти творчески и употребить, скажем, слова «валун» или «щебень». Но я не знаю, когда именно что-то перестает быть валуном и становится просто камнем. Он, может быть, и выглядит как простой камень, пока не упадет вам на ногу – тогда-то вы и почувствуете, что это настоящий валун.

Мой инструмент для разбивания камней – большой молот. И он отлично работает.

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

Обсуждение – один из лучших инструментов для разделения больших историй на части.

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

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

 

Эпики – большие камни, которыми иногда кидаются в людей

Эпик – общепринятый термин (я не знаю, кто первым употребил его) для описания крупных пользовательских историй, так же как слово «валун» используется для обозначения очень большого камня. Буду с вами честен: мне понадобились годы, чтобы воспринимать важные вещи, которые мы разрабатываем, как истории, но сейчас я понимаю, почему они так называются. Термин «эпик» смущает меня до сих пор. Насколько я помню, учитель английской литературы объяснял, что эпические поэмы обычно повествуют о героях, борющихся со злом, – Беовульфе, Ахилле, Фродо – обычно с помощью какого-то волшебного оружия или при поддержке богов. Но, кажется, я отвлекся…

Эпик – это история, размер которой считают значительным, и, значит, она должна быть разбита на меньшие части.

Неплохо иметь специальное название для больших историй, но погодите немного. Термин «эпик» нередко используется в качестве оружия. Я нередко наблюдал, как член команды разработки убеждает представителя бизнеса, менеджера продукта, пользователя или кого-то еще, кто о чем-то просит, что его история – это целый эпик, а не просто история. Обычно это произносится таким тоном, словно автор истории сделал что-то не так и нанес члену команды разработки серьезное оскорбление. Поэтому, если вы член команды разработки, не используйте термин «эпик», чтобы кого-то пристыдить. Это плохое начало (и, вероятно, преждевременное окончание) того, что должно было быть продуктивным обсуждением.

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

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

 

Группу историй организует тема

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

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

 

Забудьте все эти термины и сконцентрируйтесь на изложении историй

Термины «эпик» и «тема» давно проникли в инструменты для управления жизненным циклом Agile, в некоторые подходы к разработке Agile со своими наименованиями, а также в общепринятый язык для обсуждения историй. По этой причине вы должны знать и понимать их.

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

Вот как может выглядеть весь цикл разбиения камней.

А сейчас разберемся со всем этим подробнее.

 

Начните с возможностей

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

Первое качественное обсуждение истории – высокоуровневая («Кто?», «Что?», «Почему?») дискуссия, ее основная цель – принять решение: «да» или «нет». Причем «да» не означает, что мы немедленно приступаем к разработке. Это значит: пойдем дальше, проводя углубленные обсуждения, чтобы полностью понять историю. Но я не хочу двигаться вперед и тратить много времени на разговоры, если выяснится, что идея изначально для нас не годится. «Нет» – вежливый способ сказать: «Ерунда». Поэтому давайте назовем этот этап «решение того, развивать идею или отбросить ее». Помните: нам всегда требуется разработать больше, чем мы способны, так что отбросить бесперспективную возможность прежде, чем она съест слишком много времени и сил, – стоящее решение.

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

 

Найдите минимально жизнеспособное решение

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

Во время исследования вы должны углубиться в следующие вопросы.

• Кто те заказчики или пользователи, которым, по вашему мнению, пригодится это решение?

• Как они решают свои задачи сейчас, пока продукта еще нет?

• Как изменится их мир, когда вы покажете свое решение?

• Какие внешний вид и способ взаимодействия должны быть у вашего решения?

• Сколько времени займет реализация?

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

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

Изучайте и обсуждайте, чтобы найти небольшое и жизнеспособное решение.

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

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

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

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

 

Погрузитесь в детали каждой истории во время разработки

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

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

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

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

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

 

Продолжайте обсуждать в процессе разработки

Машина семинаров по историям производит продукт для следующего аппарата на конвейере – машины разработки Agile. Здесь я нарисовал реальный процесс работы этой машины: с одной стороны мы загружаем в нее маленькие истории правильного размера, а с другой стороны получаем идеально работающий маленький кусочек программного продукта – или того, что описывает ваша история.

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

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

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

На протяжении процесса разработки не прекращайте обсуждения, чтобы уточнить детали и высказать свое мнение по поводу создаваемого продукта.

 

Оценивайте каждую часть

Как только готовые фрагменты работающего продукта выкатятся из машины Agile, всем, кто принимал решение, что создавать, и всем, кто создавал, следует взять паузу и внимательно оценить результат.

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

Остановитесь и реально оцените качество готового решения. Спросите себя, насколько эффективным было планирование. Создано ли то, чего вы ожидали? Заняло ли это намного больше времени, чем планировалось? Или, может, меньше? Или примерно столько, сколько вы наметили? Кроме того, откровенно обсудите, насколько хорошо работает «машина». Сейчас подходящий момент, чтобы внести корректировки или изменения в процесс работы, чтобы продукт стал более качественным.

Почаще оценивайте качество продукта, планирования и процесса работы.

Этот первый этап оценки в Scrum называется ревизией спринта или ретроспективой. Как бы вы ни называли моменты остановки, пересмотра и размышлений, главное, чтобы они у вас были.

 

Оценивайте с участием пользователей и заказчиков

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

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

Обычно «достаточно» означает готовый экран или последовательность экранов, которые дают пользователю возможность выполнить задачу или достичь значимой цели. И я не хочу разговаривать с пользователями. Я наблюдаю за ними не для того, чтобы сказать: «Это прекрасно». Я наблюдаю для того, чтобы изучать, и результат изучения, как правило, примерно такой: «Получилось не совсем верно» или «Сейчас, когда я использую это в реальности, то вижу, что будет лучше, если…»

Обучайтесь, тестируя законченные фрагменты продукта с привлечением заказчиков и пользователей.

 

Оценивайте вместе с ключевыми партнерами

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

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

Обеспечивайте наглядность процесса работы и улучшения качества для других заинтересованных сторон в своей организации.

 

Выпустите релиз и продолжайте оценивать

Я нарисую еще одни, последние весы. На одну чашу мы кладем части, которые проанализировали, протестировали с участием заказчиков и пользователей и продемонстрировали заинтересованным лицам в своей компании. Эта чаша очень похожа на ту, что упоминалась несколько шагов назад, на стадии тестирования с пользователями и заказчиками. А на другой чаше снова лежит слово «достаточно», но в этот раз оно означает «достаточно для предъявления заказчикам и пользователям и получения нужных результатов». Как только чаши сравнялись, выпускайте релиз.

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

Используйте измерения, общайтесь с пользователями, чтобы узнать, получены ли в действительности ожидаемые результаты .

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

Это и есть реальный жизненный цикл – во всяком случае, жизненный цикл истории.

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