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

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

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

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

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

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

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

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

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

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

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