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

Устранение лишнего является тем моментом, на который делается акцент в сообществе Agile. Это мышление происходит от бережливости, как наиболее эффективный способ увеличить прибыльность любого бизнеса. Бережливое мышление учитывает, что поток создания ценности имеет два компонента: действия по созданию добавленной стоимости и муда (японское слово, означающее потери). Цель бережливого производства заключается в удалении муда или потерь из потока создания ценности. Потери, в свою очередь, подразделяется на две составляющие. Те действия, которые имеют ценность, но не вносят вклад в конечный продукт непосредственно, например, архитектурный план и те действия, которые вовсе не добавляют ценности. Целью является полностью удалить те мероприятия, которые добавляют стоимость на всё, и свести к минимуму те действия, которые не вносят вклад в конечный продукт напрямую. Вы можете начать устранение потерь в бизнес-анализе, путем разработки и ведения облегченной документации.

Следующие принципы являются полезными при работе для идентификации потерь в любом процессе бизнес-анализа:

• Избегайте создания документации, прежде чем она кому-либо понадобится.
• Всякий раз, когда ценность не доставляется вашим клиентам, возникают потери ожидания. Не позволяйте другим ждать вашу работу.
• Перенос информации между различными носителями не добавляет никакой ценности для разработки продукта. Постарайтесь выявлять, анализировать, определять и проверять требования по одной и той же модели.
• Анализ модели должен быть как можно более простым. Не включайте информацию, которая не несет непосредственной пользы заинтересованным сторонам.
• Незавершенная работа (Work In Progress, WIP) или запасы, являются прямым результатом перепроизводства и ожидания. Они склонны скрывать проблемы в процессе. Если вы видите это, попробуйте пустить их в процесс или устраните.
• Работать следует при тесном взаимодействии клиентов и команды разработчиков, потому что ненужные движения или согласования заменяющие разговоры лицом к лицу также являются потерями.
• Постоянно уделяйте внимание к техническому совершенству. Дефекты качества (например, неопределенные требования) приводят к переделкам и являются худшими потерями в процессе.

Упрощенная документация

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

Описание

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

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

Среда играет важную роль в количестве необходимой документации. Для некоторых проектов документация готовится внешними объектами (например, регуляторами). Документация также может быть необходима для ведения истории решений, принятых командой или функций, реализованных в приложении. Однако, эта документация может быть записана после того как программное обеспечение было разработано, что гарантирует, что оно фактически соответствует тому, что команда поставила.

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

Этот принцип следует непосредственно из манифеста Agile, в котором говорится «Работающее программное обеспечение вместо обширной документации». Это очень часто неправильно толкуется, в том смысле, что никакой документации и вовсе не нужно. Вместо этого документация должна быть минимально достаточной для удовлетворения потребностей команды.

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

Особенности использования

Преимущества

• Уменьшение времени, потраченного на создание документации.
• Уменьшение усилий, затрачиваемых на чтение и анализ документации.
• Сокращение числа документов.
• Все эксперты могут сосредоточиться на ключевых вопросах, а не на посторонних деталях.
• Обучение (передача знаний) осуществляется индивидуально, а не с помощью документации.
• Документация существует в виде автоматизированных примеров.

Недостатки

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

--

Усилиями членов IIBA и экспертами сообщества Agile был разработан черновик The Agile Extension of the BABOK, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.

Со своей стороны мы хотим привлечь пользователей системы управление проектами DEVPROM, участников команд, следующих принципам Agile, к активному обсуждению этих практик, их использованию и адаптации под встречающиеся задачи и условия.

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

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile