Как создать Фичи правильного размера на Интервал Планирования?
Автор статьи: Ian Spence, SPCT, Chief Scientist, Ivar Jacobson International
Данная статья не является официальной частью фреймворка. При этом статья, по нашему мнению, заслуживает внимания, поскольку базируется на опыте практикующих экспертов.
Тщательная предварительная подготовка Фич к мероприятию «PI Планирование» поможет вашему Релизному Поезду (Agile Release Train, ART) успешно выполнить работу и достичь поставленных целей за Интервал Планирования (Planning Interval, PI). И одним из важных аспектов этой подготовки является декомпозиция больших Фич, намеченных для разработки в ближайшем PI, на более мелкие. Фичи должны быть такого размера, чтобы их разработка не выходила за рамки одного интервала.
В этой статье мы поделимся нашим опытом по декомпозиции фич на более мелкие.
Не являются ли Фичи просто большими Историями?
У Менеджеров Продукта и Владельцев Продукта часто возникает желание относиться к фичам как к гигантским пользовательским историям. В результате этого некоторые из них применяют к фичам те же методы декомпозиции, которые они используют для «нарезки» пользовательских историй. Также, по нашим наблюдениям, не является хорошей практикой применение к фичам техники, которая используется для написания историй и называется «голос пользователя». Таким образом, то, что хорошо для пользовательских историй, не всегда хорошо для фич.
В SAFe проводится четкое различие между целью, структурой и содержанием фич. Это же относится и к историям (включая Энейблеры). Например:
- Фичи — это видимые «елементы» бизнес-намерения, на которые обращает внимание и ценит клиент. И именно на этом уровне детализации клиент может расставить приоритеты в своих потребностях.
- Фичи могут охватывать несколько пользовательских ролей, историй и вариантов использования.
- Для ускорения доставки над одной и той же фичей могут работать несколько команд.
- Несмотря на то, что разработка фич может занять несколько итераций, они все должны легко умещаться в рамки Интервала Планирования (PI). Помните, что фичи также работают внутри PI, как истории внутри итерации.
- Истории используются для инкрементальной реализации новых фич и доставки новой функциональности. Истории помогают команде (и заинтересованным лицам) изучать, обсуждать, согласовывать и упорядочивать работу, которая, по их мнению, необходима для доставки фичи.
- Истории должны быть такого размера, чтобы работа над ними умещалась в одну двухнедельную итерацию.
- Истории могут существовать без родительских фич, что позволяет командам принимать локальные решения.
Существует несколько способов декомпозиции историй. Больше всего нам нравятся 2 варианта: метод, опубликованный Ричардом Лоуренсом, и подход Дина Леффингвелла, основателя SAFe. Эти техники помогают командам идентифицировать и декомпозировать истории, а также определить последовательность выполнения историй для реализации фичи. Однако при «нарезки» фич эти подходы не помогают.
Например, мы не рекомендуем выносить требования к производительности в отдельную фичу, когда мы можем реализовать эти требования внутри этой фичи, сформулировав их в виде отдельных «историй производительности». Аналогичная логика должна применяться к обработке возможных ошибок данных, CRUD (Create, Read, Update and Delete operations) и вариативности в самих данных. Мы можем отложить истории, реализующие эти важные атрибуты фичи, до конца ее разработки, но мы не должны выносить эту работу в отдельную фичу.
При «нарезке» фич важно помнить, что ее внедрение всегда должно обеспечивать надежное, удобное решение для конечных пользователей. Фичи будут создаваться поэтапно, история за историей. Однако решение, работа над которым завершена и которое пригодно к использованию, означает, что «ничего не упущено», а не то, что все возможные истории были реализованы.
Декомпозиция Историй против Нарезки Фич
Есть еще одно важное различие между декомпозицией историй и нарезкой фич. Когда мы разделяем историю, это обычно приводит к набору новых историй, которые в сумме заменяют исходную историю. При нарезке фич мы обычно просто находим самые важные срезы (MMF), а остальное оставляем на потом.
Хорошая декомпозиция Фич
Итак, давайте представим, что команда только что определила размер фичи (обычно в сторипоинтах) и обнаружила, что она слишком велика, чтобы уместиться в Интервал Планирования (PI). Чтобы разделить эту фичу, команде нужно будет использовать метод декомпозиции, который позволяет выделить и отложить часть менее приоритетного функционала для более поздней реализации. После того, как фича будет декомпозирована, команды будут реализовывать в первую очередь ту часть, которая на раннем этапе обеспечивает бОльшую ценность для клиентов.
Какие стратегии по декомпозиции вы можете использовать? Мы выделили десять полезных шаблонов для нарезки фич:
- Принцип проектирования KISS. Сделайте фичи максимально простыми, избегайте усложнений. (Keep it simple, stupid; KISS). Стремитесь к максимально простой реализации фичи, которая может быть выпущена без ущерба для нефункциональных требований, таких как производительность системы и т. д. Часто это самый эффективный способ, подразумевающий только базовую обработку ошибок. Отложите добавление «наворотов» (дополнительных возможностей) на более поздний срок, когда большинство основных элементов решения выполнено, и вы формируете высококачественное целевое решение.
- Отложите работу над дополнительными (необязательными) вариантами поведения. – Включает ли эта фича множество необязательных вариантов поведения? Подумайте о том, чтобы сделать отдельные фичи под такие опции. И реализуйте такие фичи уже после того, как основная функциональность решения будет доставлена клиентам, и вы получите дополнительные знания, обратную связь от клиентов. При этом вы можете обнаружить, что эти необязательные варианты поведения уже и не нужны.
- Разделите по способам ведения бизнеса. Можно ли инкрементально выпустить эту фичу для разных областей бизнеса? Начните с самого простого бизнес-варианта, чтобы получить быструю обратную связь. Например, можем ли мы сделать простое решение для розничного банкинга, прежде чем улучшать его для инвестиционного банкинга, трейдинга и других банковских областей? Кроме того, учитывайте географические различия — во многих странах Северной Америки, Европы и Азии существуют разные бизнес-правила для разных областей бизнеса. Возможно, фича может быть выпущена в одном регионе, прежде чем добавлять поддержку других локаций с помощью дополнительных фич.
- Разделите по разным каналам. Можно ли выпустить эту фичу инкрементально для поддержки разных каналов, способов выхода на рынок или технологий? Например, разные операционные системы или разные каналы для розничного банкинга, мобильного приложения и банковского обслуживания в отделениях. Логически рассуждая, это одна и та же фича. Однако реализация для каждого канала может быть нарезана на отдельные фичи (а в некоторых случаях может вообще не понадобиться).
- Разделите по разным группам пользователей. – Разным группам пользователей нужны разные типы функциональности? Например, какая-то фича может быть востребована разными демографическими группами, однако каждая группа может захотеть использовать эту фичу по-своему. В этом случае, разделение фич на способы использования каждой демографической группой может позволить в первую очередь реализовать эту фичу для наиболее важных клиентских сегментов.
- Подумайте о том, чтобы увеличивать использование данных инкрементально. Все ли данные действительно необходимы для предоставления какой-либо выгоды клиентам? Возможно, сложность использования данных может возрастать инкрементально или существует возможность использовать «более легкие» вторичные источники?
- Отделяйте специальные (дополнительные) сценарии. Сначала сосредоточьтесь на популярных и частых сценариях, а затем добавьте более специализированные кейсы с помощью дополнительных фич. Вы можете обнаружить, что ценность дополнительных сценариев невелика и их не следует реализовывать.
- Выносите отдельно общие Энейблеры. Бизнес-фичи часто опираются на одно и то же базовое поведение системы, из-за чего реализация первого набора фич кажется большой и сложной задачей. Разделение функциональности на бизнес-фичи и энейблеры может снизить риск и уменьшить размер фич.
- Выделите группу наиболее ценных Историй. Помните, что правило Парето применимо и к фичам. 80% выгоды для бизнеса, скорее всего, будет получено от 20% историй. Найдите эти истории и относитесь к ним как к отдельной фиче.
- Выделяйте Спайки. Иногда у вас недостаточно знаний, чтобы определить фичу или разбить ее на более мелкие части. В таких случаях используйте исследовательский энейблер (спайк), чтобы выяснить, что необходимо.
Плохая декомпозиция Фич
Также важно понимать антипаттерны декомпозиции фич и избегать практик, которые подвергают ваше решение риску.
Помните о следующих антипаттернах при нарезке или разработке новых фич:
- Откладывать реализацию нефункциональных требований на более поздний срок. Избегайте выпуска фич, которые выполняют основные бизнес-функции, но при этом имеют неприемлемый уровень качества и производительности. Мы видели, как многие команды попадали в неприятную ситуацию, принося в жертву качество разработки, чтобы добавить в продукт все больше и больше фич. Встраивайте качество вместо того, чтобы полагаться на пост-проверку для последующего повышения качества.
- Создавать долг по фичам. Иногда появляются объективные причины, по которым выпускаются не полностью выполненные фичи для ограниченного круга пользователей, которым не так важно соответствие отдельным нефункциональным требованиям. В таком случае необходимо дополнительно позаботиться о том, чтобы эта фича впоследствии не была выпущена для всех, без добавления недостающей функциональности, важной для более широкой группы пользователей.
- Декомпозировать фичи слишком рано. Нарезайте фичу только тогда, когда вы уверены, что она понадобится в ближайшем будущем, и при этом она слишком велика, чтобы быстро пройти через систему. Помните, что оценки меняются с течением времени: то, что кажется слишком большим сегодня, по мере накопления знаний может иметь гораздо меньшую оценку в будущем.
- Чрезмерная нарезка. Избегайте разделения фичи на множество более мелких фич за один раз. Как правило, лучше в первую очередь определить один или два ключевых среза (фрагмента), которые необходимо реализовать, и отложить остальную функциональность до тех пор, пока не будет получена обратная связь по начальным срезам.
- Декомпозировать по операциям или шагам рабочего процесса. Часто возникает соблазн разделить фичу на ряд более мелких фич, чтобы выполнить какие-то операции или шаги рабочего процесса. Однако для бизнеса нет никакой ценности в том, чтобы выполнить только один шаг. Вместо этого сосредоточьтесь на определении основного поведения и создании простейшего сквозного решения. В противном случае вы можете обнаружить, что 90% фич завершены, но пользователи все еще не могут решить свою задачу или завершить процесс, который они пытаются выполнить.
- Декомпозировать по компонентам. Мы обнаружили, что технические специалисты любят разделять фичи по архитектурным компонентам, подсистемам или архитектурным уровням. Это плохая привычка, и она имеет те же проблемы, что и нарезка фич по операциям или шагам рабочего процесса.
- Забывать о тестировании на уровне Фичи. Фичи часто требуют дополнительного тестирования, помимо того тестирования, что необходимо для завершения историй. Не забудьте протестировать каждый срез фичи, а также намерение более крупного решения для исходной фичи. Критерии приемки фичи легко теряются после того, как фича разбивается на более мелкие части.