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