7 принципов Agile из Agile Extension от IIBA

dd4e20898d750aef7b38a8ce47ed882f

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

Статья написана с точки зрения бизнес-аналитика, однако описывает те принципы Agile, которыми следует руководствоваться всем участникам Agile-команд для улучшения своей работы.

Статья является переработкой тех параграфов «Agile Extension to BABOK Guide», которые говорят про принцы Agile бизнес-анализа, и содержит небольшие дополнения и пояснения.

See The Whole

Первый принцип — видеть картину целиком — направляет бизнес-аналитиков к тому, чтобы создавать в команде коллективное видение ценности, которое решение принесёт бизнесу. Использование этого принципа поможет бизнес-аналитику ответить на вопрос «почему»: «Зачем клиенту нужен этот продукт?», «Почему делаем такую систему?»

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

Что такое Big Picture и как её создавать

Говоря о Whole важно пояснить, что это за зверь. Whole — или Big Picture — это контекст в котором происходит изменение (создается продукт, проект). Контекст создается не одним бизнес-аналитиком. Тут важно участие лидеров инициативы: проектного менеджера, Product Owner, Product Manager. 5 причин, ради которых БА создаёт общее понимание контекста:

  • чтобы команда знала куда и зачем идет проект;

  • чтобы было легче валидировать с заказчиком само решение и подходы к нему;  

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

Раздробленное видение негативно влияет на команду. Отсутствие контекста говорит о том, что разработчикам все равно, какие у клиента потребности; в команде нет налаженных процессов коммуникации, а сама команда не понимает, зачем и куда идёт проект.

Think As a Customer

«Думай как пользователь» поможет аналитику и команде услышать голос тех, кто использует продукт. Аналитик начинают с высокоуровневого понимания того, кто пользователь решения. Понимание усиливается по мере взросления инициативы, обрастая деталями того, какие нужды пользователей или бизнеса удовлетворяет команда создавая проект.

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

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

Принцип «Think as a customer» включает в себя изучение реакции пользователей на решение. В книге «Lean Startup» Эрик Рис писал о ускорении feedback loops. То есть о том, что важно понимать пользователей и то, как они используют продукт, быстро. IIBA пишет, что фокус на пользователе поможет организации принимать верные решения о продолжении или отмены инициативы и распределении ресурсов.

Analyze To Determine What Is Valuable

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

  • понимать смысл требований, которые приходят для анализа;

  • быть уверенным, что решение и компоненты даёт нужные бизнесу;

  • использовать последние данные: верные решения, принимаемые исходя из устаревшей информации, в итоге будут ошибочными.

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

Get Real Using Examples

Этот принцип схож с «генти генбуцу» — принципом из «Дао Тойота», который заставляет продакт-менеджеров «выходить из офиса», чтобы понять запрос пользователей. «Get Real Using Examples» помогает аналитикам в создании общего понимания запросов, которые удовлетворит решение.

`Examples` поступают постоянно из любого взаимодействия с пользователями — жалобы в поддержку, фидбек-тикеты от лидеров инициативы, аналитики или интервью с пользователями. Команда прорабатывает разные решения, которые удовлетворят запрос, создавая совместное понимание того, как решение удовлетворит нужды.

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

Understand What Is Doable

Этот принцип поможет бизнес-аналитику понять, какое решение применимо для удовлетворения нужды в контексте, где работает команда. Каждый раз задавая вопрос «Можно ли это сделать?» мы отвечаем и на вопросы «Есть ли смысл делать сейчас?» и «Надо ли вообще это делать?» Контекст включает в себя:

  • ограничения технологий, используемых в проекте;

  • навыки команды;

  • время за которое команда обязана доставить решение пользователям.

Учет контекста помогает переоценке приоритета задачи. Например, если из-за некоторых технических ограничений добавить на сайт кнопку займёт 3 месяца, то приоритетность кнопки упадёт и лидеры продукта предпочтут использовать время команды на задачи проще — так выше вероятность доставить больше ценности клиенту. Используя этот принцип, бизнес-аналитик выступает как советчик, который помогает лидерам принимать решения, основанные на качественной информации, оценивая качество и релевантность входящей информации.

Stimulate Collaboration and Continous Improvement

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

  • быть открытыми к изменениям (если между людьми много общения, то они и общаться начинают открыто, доверяя друг другу);

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

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

Avoid Waste

Хоть и кажется, что этот принцип о мусоре, на самом деле он о лишней работе и помогает аналитикам делать меньше, создавая больше ценности. «Avoid Waste» постулирует: «More outcome with less output».

Waste может появиться двумя путями:

  1. при помощи работы, которая создаёт ценность косвенно;

  2. при помощи работы, которая вообще не создаёт ценности.

Используя этот принцип, аналитик сводит к минимум первый способ создания waste и избавиться от второго. Чтобы избежать лишней работы, бизнес-аналитик должен:

  • использовать простые методы донесения требований (например: диаграммы вместо текстов);

  • не создавать слишком рано требования и тикеты в Jira (это грозит переполенным беклогом, который команда не выполнит);

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

  • использовать только свежие данные для коммуникации возможных решений (решения, принятые на плохих данных — это waste).

Заключение

Хотя принципы Agile бизнес-анализа и кажутся несложными, но в действительности ими тяжело пользоваться в практике. Коллеги, помните, что Agile из тех навыков, которые easy to learn, difficult to master и пользуйтесь мудростью IIBA, чтобы создавать больше ценности за меньшее количество действий.

© Habrahabr.ru