Agile INVEST – 6 отличных руководящих принципов для пользовательских историй

Агил использует пользовательские истории для выражения проблем, которые продукт или система должны решить. Руководящий принцип Agile INVEST — это набор рекомендаций, составленных Биллом Уэйком, чтобы помочь проверять и создавать высококачественные пользовательские истории (или, более общо, элементы продуктового бэклога), которые поддерживают эффективноеагил-менеджмент проектов.

СогласноAgile INVESTруководящему принципу, высококачественные пользовательские истории легко:

• понимать
• реализовывать
• тестировать
• показывать клиенту
• быть независимыми

Но давайте разберемся, что на самом деле означает аббревиатура INVEST.

Agile INVEST – Независимость

Это означает, что история может существовать как элемент продуктового бэклога (PBI) с собственным приоритетом, оцениваться независимо и не зависеть от других историй.

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

Agile INVEST – Переговорная

Хорошая пользовательская история отражает суть потребности клиента. Если возникают вопросы, команда обсуждает их с клиентом, чтобы определить правильную ценность истории. Команда разработки может вести переговоры с владельцем продукта и заинтересованными сторонами. Таким образом, взаимодействие между командой проекта (поставщиком и клиентом) создает превосходный продукт или услугу.

У агил-команды нет вопросов, потому что всё документировано в агил-истории пользователей? Тогда требования написал бизнес-аналитик.

Существуют некоторые непереговорные элементы (часто нефункциональные), такие как:

• Политики безопасности, связанные с учетными записями пользователей
• Требования к производительности, например, количество одновременных пользователей, которые система должна обрабатывать

Это нормально — при условии, что детали самой функциональности остаются открытыми и способствуют обсуждению.

Agile INVEST – Ценность

Ссылаясь на принципы агил, «ценность» означает, что мы можем продемонстрировать запрашиваемую функцию или функциональность клиенту на встрече по итогам спринта.

При разделении пользовательских историй команды должны делить их вертикально (также отражающее «V»), а не горизонтально. Это обеспечивает полную функциональность в конце спринта и увеличивает потенциально доставляемый прирост продукта.

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

Agile INVEST – Оценяемость

Хорошая пользовательская история должна быть оценочной. В гибкой разработке оценка является относительной — по сравнению с другими пользовательскими историями в бэклоге. Распространённые методы включают последовательность Фибоначчи, Размеры по типу футболок (S, M, L и т.д.), и другие.

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

Agile INVEST – Маленькая

Истории должны занимать от нескольких часов до максимум одного полного спринта. В противном случае возникают различные проблемы — например, скорость (как команда отвечает за выполнение пунктов доставки), сложность точной оценки и другие.

Agile INVEST – Проверяемость

В этом контексте «проверяемость» означает критерии приемки, определённые на этапе анализа.

Мы не можем считать пользовательскую историю «Готовой», если она не соответствует критериям приемки. Единственный способ узнать, что они выполнены, — это тестирование и проверка.

Критерии приемки не являются тестовыми случаями. Они отвечают на вопрос: «Как я узнаю, что закончил эту пользовательскую историю?»

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

Клиент может рассказать вам, как выглядит тестовая среда и условия тестирования, при которых команда считает пользовательскую историю ГОТОВА.