Роль аналитика в команде Agile
Недавно задумался о роли аналитика в Agile.
Так как сейчас 90% компаний говорят о том, что ведут разработку по Agile, используют Scram, рассмотрим этот случай.
Мысль подробнее разобраться в задачах аналитика в проектах Agile, первый раз меня посетила, когда только узнал о Scram.
Ценности
Начнем с манифеста Agile.
"Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану."
Во втором пункте, сразу говорится что проектная документация не так важна, как работающий продукт.
Это противопоставляется водопадной модели разработки, где большой % времени проекта составляет написание документации. Практически вся она пишется аналитиком, либо с помощью аналитика.
В гибкой методологии, детальная проработка задачи аналитиком, заменяется обсуждением user story командой. Команда и определяет каким образом задача будет реализована. Притом не составляется подробная спецификация.
Agile рекомендует избегать документацию, которую заведомо никто не прочитает, использовать больше визуальных образов, схем, графических нотаций.
Роли
Теперь перейдем состава ролей Scram.
1. Владелец продукта.
2. Scram мастер.
3. Команда разработки.
Как видно из состава ролей, команда не делится по функционалу. Идеальная команда разработки для скрама, кроссфункциональная, а разработчики имеют прямой доступ к бизнесу.
Так где же место аналитика?
Большинство разработчиков не любят общаться с бизнесом, и в общении с ним больше уделяют техническим аспектам. Для успешного продукта важны так же и бизнес характеристики. Так же, на уточнение требований разработчики будут тратить много времени. Это может зависеть от бюрократии, нетривиальных моментов, не желании принимать ответсвеных решений и т.п.
Тут и возникает идея в промежуточном слое, который позволит эффективно использовать разработчиков, но при этом не снижая качество общения с бизнесом.
Аналитик будет связующим звеном, скрам команды и безнес заказчиков. И будет особенно нужен в случае недостатка времени у стейкхолдеров, или отсутствия владельца продукта.
Также, аналитик будет центр накопления знаний о предметной области продукта, контролировать качество продукта, проводить review продукта, подготавливать данные для уточнения бэклога и т.п.
Из личного опыта. В данный момент, обучаюсь по специальности руководитель проекта (РП) (частично затрагиваем и задачи владельца продукта (ВП)), замечаю, что функционал аналитика сильно пересекается и с РП и с ВП.
Итог
Несмотря что гибкие методологии напрямую не указывают на наличие аналитика в команде, выведение аналитика в отдельную роль несомненно будет плюсом.
На небольших проектах, аналитик может совмещать роль с ВП. На больших проектах, аналитик является связующим звеном между бизнесом и командой.
Недавно задумался о роли аналитика в Agile.
Так как сейчас 90% компаний говорят о том, что ведут разработку по Agile, используют Scram, рассмотрим этот случай.
Мысль подробнее разобраться в задачах аналитика в проектах Agile, первый раз меня посетила, когда только узнал о Scram.
Ценности
Начнем с манифеста Agile.
"Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану."
Во втором пункте, сразу говорится что проектная документация не так важна, как работающий продукт.
Это противопоставляется водопадной модели разработки, где большой % времени проекта составляет написание документации. Практически вся она пишется аналитиком, либо с помощью аналитика.
В гибкой методологии, детальная проработка задачи аналитиком, заменяется обсуждением user story командой. Команда и определяет каким образом задача будет реализована. Притом не составляется подробная спецификация.
Agile рекомендует избегать документацию, которую заведомо никто не прочитает, использовать больше визуальных образов, схем, графических нотаций.
Роли
Теперь перейдем состава ролей Scram.
1. Владелец продукта.
2. Scram мастер.
3. Команда разработки.
Как видно из состава ролей, команда не делится по функционалу. Идеальная команда разработки для скрама, кроссфункциональная, а разработчики имеют прямой доступ к бизнесу.
Так где же место аналитика?
Большинство разработчиков не любят общаться с бизнесом, и в общении с ним больше уделяют техническим аспектам. Для успешного продукта важны так же и бизнес характеристики. Так же, на уточнение требований разработчики будут тратить много времени. Это может зависеть от бюрократии, нетривиальных моментов, не желании принимать ответсвеных решений и т.п.
Тут и возникает идея в промежуточном слое, который позволит эффективно использовать разработчиков, но при этом не снижая качество общения с бизнесом.
Аналитик будет связующим звеном, скрам команды и безнес заказчиков. И будет особенно нужен в случае недостатка времени у стейкхолдеров, или отсутствия владельца продукта.
Также, аналитик будет центр накопления знаний о предметной области продукта, контролировать качество продукта, проводить review продукта, подготавливать данные для уточнения бэклога и т.п.
Из личного опыта. В данный момент, обучаюсь по специальности руководитель проекта (РП) (частично затрагиваем и задачи владельца продукта (ВП)), замечаю, что функционал аналитика сильно пересекается и с РП и с ВП.
Итог
Несмотря что гибкие методологии напрямую не указывают на наличие аналитика в команде, выведение аналитика в отдельную роль несомненно будет плюсом.
На небольших проектах, аналитик может совмещать роль с ВП. На больших проектах, аналитик является связующим звеном между бизнесом и командой.