Роль бизнес аналитика в scrum

Вопрос достаточно актуальный, так как сейчас 90% компаний говорят о том, что ведут разработку по Agile, используют Scrum, рассмотрим именно эту конфигурацию.

Мысль подробнее разобраться в задачах аналитика в проектах Agile, первый раз меня посетила, когда только узнал о Scrum. Начнём.

Начнем с манифеста Agile.

«Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.»

Во втором пункте, сразу говорится что проектная документация не так важна, как работающий продукт.

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

В гибкой методологии, детальная проработка задачи аналитиком, заменяется обсуждением user story командой. Команда и определяет каким образом задача будет реализована. Притом не составляется подробная спецификация.

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

Теперь перейдем состава ролей Scrum.

1. Владелец продукта.
2. Scrum мастер.
3. Команда разработки.

Как видно из состава ролей, команда не делится по функционалу. Идеальная команда разработки для скрама, кроссфункциональная, а разработчики имеют прямой доступ к бизнесу.

Так где же место аналитика?

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

Тут и возникает идея в промежуточном слое, который позволит эффективно использовать разработчиков, но при этом не снижая качество общения с бизнесом.

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

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

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

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

Источник: vc.ru

Как бизнес-аналитику встроиться в гибкую среду?

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

Тот факт, что такой вопрос всё время задают, проистекает из руководства по Scrum. Scrum Guide определяет три роли в команде: команду разработчиков, Scrum -мастера и владельца продукта. Легко заметить, что здесь не упоминается о роли гибкого бизнес-аналитика. Нельзя сказать, что мы единственные, кто остался в стороне — также не определены роли для архитекторов решений, тестировщиков, группы обеспечения качества, менеджера развёртывания, дизайнера пользовательского интерфейса или технических писателей. Мы все каким-то образом попали в команду разработчиков.

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

Это все хорошо, за одним исключением: при организации работы по Scrum все задачи, реализуемые командой разработчиков, выполняются в рамках спринта. Однако работа бизнес-аналитика не основана на спринте.

Как бизнес-аналитик может справиться с этой противоречивой ситуацией?

3 обязанности бизнес-аналитика в Agile

Исходя из моего личного опыта работы бизнес-аналитиком в гибкой среде, иногда гибкие проекты включают Scrum-мастера или проектную группу, выполняющую его обязанности, но не всегда. Постоянными ролями обычно являются команда разработчиков, владелец продукта и бизнес-аналитик.

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

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

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

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

Выделяются три конкретных области, в которых гибкий подход определяет то, как я выполняю свою работу.

Коммуникации

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

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

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

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

Создание дорожной карты продукта

Дорожная карта продукта имеет первостепенное значение для своевременного развития и успеха любого гибкого проекта.

Дорожные карты помогают:

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

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

Сохранение команды на правильном пути

Фокусировка команд — ещё одна фундаментальная обязанность бизнес-аналитик. Он следит за тем, чтобы менеджеры, разработчики и пользователи были сосредоточены на конечной цели проекта.

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

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

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

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

Также по теме:

• Когда бизнес заодно.
• Обновление Scrum Guide
• Чем заняться в среду, 9 декабря 2015 года
• Готов ли бизнес к DevOps?
• Бизнес играет в ИТ

Источник: cleverics.ru

Бизнес-аналитики в Agile — зачем, почему, как

2015-06-10 в 13:25, admin , рубрики: agile, бизнес-анализ, Блог компании DataArt, управление проектами

Зачем вообще нужны бизнес аналитики

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

Поскольку и программисты, и заказчики — люди занятые, выяснение деталей проходит в форме раундов «вопрос — ответ», при этом нигде не фиксируется, когда и почему было принято такое решение или как оно изменялось со временем. Но главный минус такой коммуникации — разработчик спрашивает «как?», а заказчик может ответить только на «зачем?», а остальное его уже мало интересует. Более того, обычно, отвечая на «как?», заказчик заводит себя в тупик, потому что не может и не обязан знать, сколько вариантов существует для выполнения его потребности и какой оптимален. Программист же всего лишь делает, что ему сказали. В итоге складывается ситуация, когда недоуменный клиент спрашивает, почему приложение не вписывается в его картину мира, а недоуменный программист отвечает, что так и просили сделать.

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

Аналитик в Agile

Сегодня в России и странах СНГ набирают популярность гибкие методологии разработки ПО. При рассмотрении возможности перехода на них (и даже в процессе перехода или начального использования), почти неизбежно встает целый ряд вопросов. Один из них состоит в необходимости участия бизнес аналитика в процессе разработки.

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

Проектная документация имеет тенденцию очень быстро устревать— в особенности в сочетании с Agile, где изменения — норма, а не форс-мажор.

В связи с этим в Agile-методологиях всячески советуется минимизировать документацию:

• ­Избегать write-only-документации, т. е. той, которую заведомо никто не прочитает.
• ­Писать лаконично, выделяя главное и опуская излишние детали, ибо детали меняются чаще.
• ­Использовать больше визуальных образов, схем, графических нотаций.

• ­­Тяжело вводить новых людей в курс проекта.
• ­Велика вероятность утери общей концепции и видения (проекта в целом и его частей).
• ­Сложно контролировать качество: непонятно, с чем сверять (в особенности это касается полнофункционального регрессионного тестирования, которое полностью автоматизировать очень тяжело).
• ­Сложно сопровождать и развивать старую функциональность: все уже забыли, почему и зачем именно так сделали.

Возможные функции аналитика в Agile

Связующее звено между разработчиками и заказчиками

В отличие от классической интерпретации функций аналитика, в Agile именно обеспечение эффективной связи между заказчиками (пользователями) и командой разработчиков играет, по сути, ключевую роль.

Т. е. аналитик оказывается человеком, которому доверяют и пользователи, и разработчики:

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

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

Контроль качества

Традиционно считается, что качество контролируют специальные люди, которые выполняют приемочные испытания по описанным методикам и программам. Однако кто проверит, что сделали то, что нужно с точки зрения бизнеса, и что пользоваться удобно?

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

Достаточно очевидно, что вместо (или совместно с) владельцем продукта эта почетная обязанность может быть возложена на аналитика

Схемы взаимодействия аналитик – команда

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

Владелец продукта — аналитик

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

Т. ч. можно решить: функции аналитика исполняет владелец продукта. Или, если угодно, наоборот — аналитик исполняет роль владельца продукта.

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

• ­Слишком многое зависит от одного человека — большая нагрузка и связанные с этим риски «бутылочного горлышка».
• Экстремальная незаменимость — а если в отпуске, а если заболел.
• Вряд ли получится плотно привлечь такого владельца продукта к сопровождению системы или активному участию в пилотных внедрениях.
• Есть вероятность, что владелец продукта будет откладывать решение каких-то задач не потому что у них низкий приоритет, а потому что он пока еще не успел как следует проработать постановку. Т. е. убивается вся идея приоритизации работ на основании потребностей бизнеса, а не исходя из внутренних или технических обстоятельств.

Аналитик — помощник владельца продукта

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

Однако, и у этой схемы есть недостатки:

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

Аналитик внутри команды

Можно пойти еще дальше и поместить аналитика внутрь команды. Что это значит:

• Аналитик сидит вместе со всеми, т. е. в одной комнате с разработчиками.
• Аналитик участвует в Scrum-митингах с остальными (рассказывает, что делал вчера и что собирается делать сегодня).
• Работа аналитика учитывается при планировании итерации.
• Аналитик может привлекаться к нехарактерным для себя работам, чтобы помочь остальной команде в непростую минуту — например, подготовить тестовые данные, прогнать часть ручных тестов.

Звучит здорово. И работает здорово! Однако бывают обстоятельства, при которых схема не подходит:

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

Так есть разница между аналитиком в Agile и не-Agile (например, в водопаде или другой тяжеловесной методологии)? Однозначный ответ — есть!

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

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

Аналитик в Agile — золотая середина между крайностями:

Источник: www.pvsm.ru