Как правильно нарезать Фичи для Инкрементов Программы SAFe®

Мы выявили несколько опасных ловушек, которые могут подстерегать вас в ходе нарезки:

• Откладывание нефункциональных требований на потом — типичная модель нарезки фич, которая может привести к проблемам. Конечно, в ходе реализации Фичи мы можем приступать к работе с нефункциональными требованиями после разработки первоначального набора историй, но не следует проводить релиз Фичи, качество и производительность которой не дотягивают до требуемого уровня. Мы видели немало команд, которые имели серьезные трудности из-за того, что в гонке за количеством Фич в продукте переставали следить за качеством.

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

• Слишком ранняя нарезка – проводите нарезку только такой Фичи, которая 1) нужна в самом ближайшем будущем или 2) слишком большая (на текущий момент), чтобы эффективно встроиться в систему. Помните, что оценки реализации Фич постоянно меняются: то, что сегодня кажется слишком большим, в будущем может получить куда меньшую оценку.
• Слишком глубокая нарезка – нет необходимости нарезать Фичу на множество меньших фич за один присест. Обычно достаточно определить первые один-два кусочка, а к остальному вернуться после завершения их реализации.
• Нарезка по компонентам – мы заметили, что техническим специалистам бывает сложно сопротивляться соблазну нарезать фичи по архитектурным компонентам, подсистемам или слоям. Это тактическое решение, которое нередко применяется на уровне Историй, особенно в случае компонентно-специфических команд или с командами, которые всячески пытаются уместить свои истории в двухнедельный спринт. Это плохая привычка, и с ней нужно всерьез бороться, особенно когда вы имеете дело с более крупными компонентами, такими, как Фичи.
• Откладывание Тестирования Фичи — фичи нередко требуют дополнительного тестирования, сверх того, что необходимо для тестирования набора входящих в них Историй. Одна из ловушек, возникающих в ходе нарезки — откладывание тестирования на более поздний этап вместо того, чтобы включать необходимый объем тестирования как часть каждой из небольших Фич.
• Нарезка по операциям или шагам процесса — когда речь идет о реализации процесса, зачастую возникает соблазн разделить Фичу по шагам или по операциям, требующимся на каждом шаге. Например, можно определить входящий поток, обработку и выходные данные процесса в разные Фичи или еще проще — разделить процесс на создание, доступ, изменение и удаление элементов. При нарезке Фич это происходит довольно часто и является ошибкой, поскольку реализация только одного шага процесса практически не приносит бизнес-ценности. Сфокусируйтесь на каком-нибудь корневом поведении, присущем Фиче, и создайте максимально простое сквозное решение. Последующие дополнительные Фичи могут включать разные вариации поведения и прочие “рюшечки”, но добавлять их следует только после того, как базовая функциональность от начала до конца процесса успешно прошла релиз и уже находится в руках пользователей. Такая необдуманная нарезка зачастую приводит к ситуации, когда 90% Фичи уже готово, но решение не может удовлетворить ни одну из реальных потребностей пользователей. Они могут внести какие-то данные, найти какие-то данные, что-то поменять, но не могут физически завершить процесс, которому пытаются следовать.