{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Роль аналитика в команде Agile

Недавно задумался о роли аналитика в Agile.

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

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

Ценности

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

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

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

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

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

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

Роли

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

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

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

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

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

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

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

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

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

Итог

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

0
3 комментария
Andre J

Для того чтобы была более понятна роль Аналитика в команде Agile, скорее всего аналитика можно просто назвать зам PO

Ответить
Развернуть ветку
Анзор Балкаров

Зачем усложнять) Есть команда разработки, куда аналитик и входит, его нет смысла вычленять на отдельную роль. В рамках фреймворка ему место в dev.team

Ответить
Развернуть ветку
Михаил Фокеев
Автор

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

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда