Менеджеры в Agile проектах
Всем привет.
После бурной дискуссии о зарплатах менеджеров и девелоперов мне стало очевидно, что тема построения горизонтальных взаимоотношений в проекте заинтересовала многих и отклонилась от первоначального русла колонки Святослава. Поэтому я попробую раскрыть ее в своей колонке.
(Здесь была картинка для привлечения внимания, но я решил обойтись без нее).
Немного о себе: в IT с 2001 года, бывший девелопер, перешел в бизнес-аналитики, т.к. понял, что «interactions and people» мне интереснее и важнее «processes and tools». Сейчас работаю в Люксофт Украина. Подробнее, кому интересно, в LinkedIn.
Проект
Теперь о проекте, в котором я сейчас работаю: разработка крупной системы для clearing and settlement (C&S) сделок по ценным бумагам (конкретно, cash equities) в инвестиционном банке UBS Investment Bank. В детали системы и использующего ее бизнеса я не могу вдаваться из-за NDA, зато о процессах могу рассказать все.
Над проектом работает 120+ человек в 5 локациях, объединенные в 12 Scrum-командах (количество периодически меняется, т.к. некоторые команды реформируются, некоторые создаются, а некоторые — прекращают работу). Разработка идет
Чем наш проект интересен и показателен? Тем, что без жесткой вертикальной структуры менеджмента он сохраняет фокус спонсоров программы, показывает стабильные результаты с короткими циклами релизов и быстро адаптируется к изменениям требований.
Процесс
Команды кроссфункциональны, т.е., в каждой команде есть люди со скиллами BA, QA и development. Даже если роль BA или QA занимает выделенный человек, обычно он/она выполняет какие-то смежные активности. Это позволяет, во-первых, поддерживать всю команду во «включенном» состоянии (т.е., члены команды активно общаются), во-вторых, повысить Truck Number (количество членов команды, которых нужно «задавить грузовиком» для прекращения эффективной работы).
Согласно принципам Agile Manifesto, команды общаются с заказчиком (людьми из бизнеса) напрямую, причем делает это не только бизнес-аналитик, а и все остальные члены команды во время PBR (product backlog refinement workshops).
Команды, естественно, работают по какому-то плану, и этот план — product backlog (у нас их несколько, т.к. есть несколько направлений работы по продукту). У каждого бэклога есть Product Owner, над каждым бэклогом может работать одновременно несколько команд. Задачи распределяются по командам во время Joint PBR, на котором PO вкратце объясняет суть приоритетных задач и команды по очереди разбирают их для дальнейшего изучения, уточнения требований, взаимозависимостей и т.д.
Таким образом, к началу очередной итерации у каждой команды есть вполне актуальный sprint backlog, в котором для каждой user story есть:
- требования (причем, собранные самой командой)
- definition of done (что должно быть сделано в рамках user story)
- acceptance criteria (как именно это должно в итоге работать)
С технической точки зрения качество обеспечивается:
- TDD и, как следствие, 100% покрытием unit tests
- активным использованием BDD и specification by example, понятных бизнесу и легко транслируемых в behavioural tests
- работающими практиками continuous integration
А теперь о том, кто же это все менеджит.
Из четырех типов менеджеров у нас реально есть только две роли:
- account manager в нашей терминологии называется delivery manager и занимается как раз обсуждением новых проектов с заказчиком, утрясанием рейтов, people management (включая вопросы увольнения и повышения з/п; при этом, естественно, ориентируется на фидбэки коллег, заказчиков и т.д.)
- менеджер продукта — это как раз классический Product Owner, который знает пользователей, их приоритеты и экспертов в предметной области.
В принципе, часть функций «менеджера проекта» лежит на PO, но это касается только приоритизации требований и, частично, их декомпозиции (обычно вместе с командой). Разбиение на задачи, effort estimation и обновление burndown charts — задача команды (с которой они справляются). Естественно, в команде есть ScrumMaster, который следит за соблюдением процесса и, в нужный момент, может подсказать команде практику для более эффективной работы. С другой стороны, со временем необходимость в такой роли в большинстве команд отпала по ходу их совместной работы.
Кроме того, мы активно привлекаем внешних консультантов для анализа и улучшения наших процессов (таких, как Craig Larman, Portia Tung, Gojko Adzic и т.д.). Естественно, вопрос выделения бюджета на такие вещи, так же, как и на обучение/сертификацию/участие в конференциях решают совместно delivery managers со стороны как Люксофта, так и UBS. Но немаловажным фактором, влияющим на принятие решений, является, опять-же, фидбэк от команд.
Подробнее о проекте можно посмотреть в выступлении моих коллег на QCon London 2011.
Таким образом, мы подходим к шуточному вопросу, который я озвучил в комментариях к колонке Святослава: Должен ли у команды быть менеджер?
Я, конечно же, слукавил. Менеджер у проекта (не у команды!) быть должен. Но вот чего он не должен делать — так это «менеджить», а именно — «микроменеджить».
Задача хорошего менеджера, как и хорошего, например, админа, — организовать работу таким образом, чтобы он был не нужен в повседневных задачах и мог заниматься более высокоуровневыми задачами (для аутсорсинга — привлечение новых клиентов, для продуктовых компаний — участие в стратегическом планировании).
Как этого добиться? Подбирать правильных людей, учиться самому и учить их. Не жалеть средств на улучшение коммуникаций (от командировок до интерактивных досок). Слушать команды и слышать их. В общем, inspect and adapt!
Буду рад выслушать ваши комментарии и ответить на вопросы.
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
27 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.