Помните, эпики – это большие истории, размер которых может быть правильным с точки зрения бизнеса, пользователей или заказчиков, но не команды разработки. Поэтому поработайте вместе над их разбиением, но не откладывайте в сторону сам эпик. Он вам понадобится, когда вы станете обсуждать с другими людьми и его, и более детализированные истории, на которые он был разделен.
Если вы применяете электронную систему, которая поддерживает разработку Agile, то, скорее всего, там используется концепция эпика как большой родительской истории, на которой основаны более мелкие дочерние истории.
Группу историй организует тема
Используйте термин «тема» для описания историй, которые удобно объединить в группу. Разбив камень – разделив большие истории на части и организуя их в продукты, которые люди хотят получить и использовать, – вы получите множество маленьких историй. Я воспринимаю тему как мешок, в который можно сложить набор историй, связанных друг с другом. Я могу использовать этот термин также для набора историй, необходимых для следующего релиза, являющихся частью одной функциональности, соответствующих определенному типу пользователя или связанных каким-то иным образом. Но тогда моя метафора не совсем верна, так как одна и та же история может относиться к двум разным темам, а вот камень лежать в двух разных мешках не может.
Если вы пользуетесь одним из доступных сейчас инструментов, которые поддерживают объединение в группы историй Agile, возможно, в них поддерживается и организация историй по темам. Вы можете ссылаться на тему, какой бы она ни была: следующий релиз, функциональность или истории, соответствующие определенному типу пользователей.
Забудьте все эти термины и сконцентрируйтесь на изложении историй
Термины «эпик» и «тема» давно проникли в инструменты для управления жизненным циклом Agile, в некоторые подходы к разработке Agile со своими наименованиями, а также в общепринятый язык для обсуждения историй. По этой причине вы должны знать и понимать их.
Но сейчас давайте отойдем от этих терминов: забудьте, что я упоминал их, хотя бы ненадолго. Сделаем шаг назад и посмотрим на весь цикл разбиения камней. В этом цикле мы начинаем с великих идей, на которые можно смотреть как на большие камни, и проводим их по всему пути к небольшим фрагментам работающего программного продукта. Затем перебираем эти фрагменты программы в функциональности, продукты и релизы, которые нужны пользователям и заказчикам.
Вот как может выглядеть весь цикл разбиения камней.
А сейчас разберемся со всем этим подробнее.
Начните с возможностей
Странствие истории начинается с идеи. Это может быть мысль о новой функциональности или совершенно новом продукте. Это может быть какое-то изменение, улучшающее уже существующую функциональность. Это может быть проблема, которую нужно решить. Но я все же использую термин «возможность», поскольку у нас есть благоприятная возможность получить какие-то выгоды в результате этих действий. Предлагаю вам составить список этих возможностей – я называю его бэклогом возможностей.
Первое качественное обсуждение истории – высокоуровневая («Кто?», «Что?», «Почему?») дискуссия, ее основная цель – принять решение: «да» или «нет». Причем «да» не означает, что мы немедленно приступаем к разработке. Это значит: пойдем дальше, проводя углубленные обсуждения, чтобы полностью понять историю. Но я не хочу двигаться вперед и тратить много времени на разговоры, если выяснится, что идея изначально для нас не годится. «Нет» – вежливый способ сказать: «Ерунда». Поэтому давайте назовем этот этап «решение того, развивать идею или отбросить ее». Помните: нам всегда требуется разработать больше, чем мы способны, так что отбросить бесперспективную возможность прежде, чем она съест слишком много времени и сил, – стоящее решение.
Обсуждайте возможности, чтобы удостовериться в целесообразности решения проблемы и принять решение, развивать его или отбросить.
Найдите минимально жизнеспособное решение
После того как вы приняли решение двигаться вперед, настало время углубиться в исследования. Старайтесь узнать побольше, чтобы найти решение, достойное реализации. И не забудьте его всерьез минимизировать. Стремитесь как можно значительнее уменьшить объем требуемой работы, но при этом получить максимальный положительный эффект.
Во время исследования вы должны углубиться в следующие вопросы.
• Кто те заказчики или пользователи, которым, по вашему мнению, пригодится это решение?
• Как они решают свои задачи сейчас, пока продукта еще нет?
• Как изменится их мир, когда вы покажете свое решение?
• Какие внешний вид и способ взаимодействия должны быть у вашего решения?
• Сколько времени займет реализация?
Существует много практик, которые могут оказаться полезными в этой дискуссии, в частности карты историй. Они могут помочь вам осознать, как люди работают сегодня, а затем соотнести ваши идеи с состоянием всей системы после реализации решения.
Во время исследования очень важно проверить свои предположения и проделать работу по их подтверждению. Это можно сделать, глубоко проанализировав бизнес-правила или внешние предписания. Можно также поработать некоторое время непосредственно с заказчиками и пользователями, чтобы понять, как они это делают. В рамках этой работы прототипы вашего решения должны быть созданы и проверены на целевой аудитории. Кроме того, постройте технические прототипы для того, чтобы можно было выявить технические риски.
Изучайте и обсуждайте, чтобы найти небольшое и жизнеспособное решение.
Радуйтесь каждому пункту вашего решения, благополучно отправленному в корзину или обратно в бэклог возможностей, чтобы разобраться с ним в другой раз. Наши возможности могут представлять собой очень большие камни, но внутри этих камней порой таятся бриллианты и драгоценные металлы. Разбейте камни и извлеките оттуда действительно ценное, не обращая внимания на простую породу, а затем порадуйтесь, что отбросили все ненужное.
Во время исследования вы можете принять решение о создании небольших вещей, которые помогут вам в изучении, в частности прототипов архитектуры или графического дизайна.
Спайк – термин, используемый для небольших фрагментов программы или исследования, которые мы разрабатываем с целью изучить что-то конкретное. Своим происхождением он обязан сообществу экстремального программирования, где так называли работу, которая могла не войти непосредственно в создаваемый продукт. Используйте истории, чтобы описывать спайки, которые будет создавать ваша команда с целью что-либо изучить.
Когда вы уверены, что выделили небольшой набор историй, которые должны реализовать и предъявить пользователям и заказчикам, настало время подойти поближе к релизу. Список историй, реализация которых даст релиз полезного продукта, называется релизным бэклогом.
Погрузитесь в детали каждой истории во время разработки
Наши возможности поначалу могли быть похожи на большие камни. Исследовательские обсуждения разбивают их на части и отделяют пустую породу от ценных металлов. Но разработка может идти быстрее и эффективнее, если нам удастся разбить эти части на как можно более мелкие фрагменты (помня о том, что каждый фрагмент должен быть чем-то, что мы можем создать и таким образом нечто изучить). Чтобы сделать это, понадобится еще больше обсуждений, в ходе которых мы углубимся в подробности и детали.
Я нарисовал
