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

Практики Agile требований

Роль бизнес-аналитика в Agile проекте

Бизнес-аналитик (BA) играет ключевую роль в традиционном проекте в работе с пользователями для анализа и документирования требований до разработки. Однако, поскольку гибкое взаимодействие между проектной группой и пользователями максимально подчеркивает непосредственную личную связь с меньшим упором на требования, которые подробно описаны, потребность в бизнес-аналитике снижается, и роль, если таковая существует, сильно отличается.

В идеальной гибкой среде нет роли бизнес-аналитика. Владелец продукта несет непосредственную ответственность за выполнение требований и передачу их разработчикам в виде пользовательских историй. Однако в реальном мире это не всегда возможно:

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

Важные моменты заключаются в следующем:

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

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

Таким образом, если бизнес-аналитик используется в Agile проекте, основными функциями являются поддержка владельца продукта путем выполнения следующих действий:

  • Анализирует широко defined область и используйте функциональное разложение для определения эпиков высокого уровня и историй, чтобы создать хорошо организованную, управляемую стоимостью структуру, чтобы предоставить необходимую деловую стоимость в отставании продукта. Если сюжеты следуют логической функциональной иерархии, это обеспечивает механизм лучшего понимания взаимосвязи сюжетов и эпиков друг с другом и для удовлетворения общих бизнес-целей.
  • Пишет отдельные истории, которые являются очень четкими и краткими и являются легкими понять и осуществить проектной группой. Написание эффективных пользовательских историй – это умение, которое часто воспринимается как должное. В хороших историях часто упускается из виду пункт “почему” или “так что”, который выражает деловую ценность, которую призван предоставить рассказ. Хороший BA может обеспечить такую перспективу, которая является определяющим для разработчика.
  • Определяет связанные пользовательские истории и эпопеи, группируя их в логическую структуру по мере необходимости и документируя взаимосвязь и связанный бизнес-процесс flows по мере необходимости. Взаимосвязь между историями и эпиками пользователей должна быть хорошо понятна, и реализация историй в различных функциональных областях может потребовать определенного планирования и координации, с тем чтобы они были реализованы надлежащим образом. Эта общая структура может обеспечить механизм для простого выявления любых несоответствий и/или отсутствующих функциональных возможностей.
  • Интегрирует потребностей различных заинтересованных сторон для выработки общего решения. Это имеет более важное значение для крупных проектов или программ, где может возникнуть необходимость в интеграции потребностей соответствующих проектов, а также потребностей ряда различных заинтересованных сторон.

Практика Just Barely Good Enough

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

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

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

Отличие желаний от потребностей и “5 почему” (Differentiating wants from needs and the “five whys”)

Другой очень хороший практикой при разработке требований к гибким проектам – отличать желания от потребностей.

  • Желания обычно связаны с решением, которое предполагает клиент.
  • Потребности обычно связаны с проблемой.

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

Метод five whys является хорошим подходом для поиска клиента, чтобы добраться до корня проблемы. Идея в том, что, постепенно спрашивая “почему” снова и снова, вы в конце концов попадаете к первопричине проблемы. Ниже приведен пример того, как метод “Пять причин” может быть использован для получения корня проблемы:

  1. Почему наш клиент несчастлив? Потому что мы не оказывали свои услуги, когда говорили, что будем.
  2. Почему мы не смогли выполнить согласованные сроки или график поставки? Работа заняла гораздо больше времени, чем мы думали.
  3. Почему это заняло столько времени? Потому что мы недооценили сложность работы.
  4. Почему мы недооценили сложность работы? Потому что мы сделали быструю оценку времени, необходимого для его завершения, и не перечислили отдельные этапы, необходимые для завершения проекта.
  5. Почему мы этого не сделали? Потому что мы бегали по другим проектам. Нам явно нужно пересмотреть нашу оценку времени и процедуры спецификации.

Практика “Москва” (MoSCoW technique)

Практика "Москва" (MoSCoW technique)

Другой хороший метод определения приоритетности требований называется MoSCoW. Практика определяется следующим образом:

  • Должен иметь (Must have) – Требования, маркированные как «ДОЛЖНО БЫТЬ», придется включить в текущую поставку для клиента для успеха. Если даже одно требование “ДОЛЖЕН” не включено, то поставка по проекту должна считаться неудачной.
  • Следует иметь (Should have) – «ДОЛЖЕН» требования быть также очень важными для успеха проекта, но не необходимы в текущей поставке.
  • Мог иметь (Could have) – Требования, маркированные как «МОГ» быть менее важные и часто рассматриваются как хорошо бы сделать.
  • Не будет иметь (Won’t have) – «Не БУДЕТ» требования быть или наименьшим – очень важный, пункты самой низкой окупаемости, или не соответствующие в то время.