Размер команды и Agile мышление
Продолжаю размышления на тему применения agile практик в реальной жизни. Давайте обсудим зависимость от размера команды проекта.
до 4
В этом случае абсолютно неважно какому процессу или методологии следовать, это не окажет почти никакого влияния на результат. Тут и менеджер не нужен, от слова “совсем”. Это хакатон, стартап, что угодно, но не проект.
до 7 (±2)
В команде проекта пара разработчиков, один тестер, а также парт-тайм аналитик и дизайнер? Допустим, что вся команда около 7 человек. Тут оказывает влияние личностные качества ПМа и его умение работать с людьми. Использование легковесных Agile практик помогает, но еще не является критичным для успеха. В команде до 7 человек у ПМа есть время встретится с каждым и выслушать каждого отдельно, а команда еще не страдает от слишком больших коммуникационных потерь. В идеале всем надо сидеть вместе, но распределенные команды на этом уровне тоже работают при использовании соответствующих инструментов и с учетом культурных нюансов, если необходимо.
Количество социальных связей в группе считается по формуле
k = (n × (n — 1)) / 2
то есть если не брать в расчет внешние связи, с заказчиком, например, то мы имеем всего 21 социальную связь в нашей команде. Это относительно немного (согласно числу Данбара, мы можем поддерживать до 150). Понятно, что если нам надо будет общаться с несколькими людьми на стороне заказчика (пусть их 2) — и количество связей сразу становится 36.
Держите эту идею в голове по мере того как мы будем двигаться дальше в размерах.
9–15
Вот тут обитает большинство проектов и тут становится интереснее.
По предыдущей формуле, количество связей уже под сотню и потери на коммуникации значительны и оказывают существенное влияние на проект. В случае, если не удается синхронизировать видение проекта между участниками — то и критическое.
В этом размере важно не упустить естественное деление команды на подгруппы. Логично оно происходит по технологиям/специальностям, иногда по близости столов в офисе. Такие подгруппы могут строить внутри себя свои собственные правила, процессы и методы, ограничивая свое взаимодействие с другими участниками общей команды проекта. Это может привести к потерям важной информации, опыта и препятствовать выходу команды на синергичный уровень.
Если удается привлечь на свою сторону ситуативных лидеров и избежать явного деления на подгруппы, то с данным размером команды Agile подходы показывают свою наибольшую эффективность и хорошие шансы на успешное завершение проекта.
20–40
На этом этапе простые Agile методологии уже не работают как ожидается, количество социальных связей слишком велико, коммуникационные затраты уже значительные. Команда неизбежно разбивается на более мелкие подгруппы со своим управлением и правилами. Разбиться на такие подгруппы и договариваться про взаимодействие между ними стоит заранее, до начала работ по проекту, иначе подгруппы могут начать соревноваться между собой, ставя под угрозу весь проект ради политической выгоды внутри компании.
На сцену выходят эволюционировавшие из простых Agile практик вариации на тему масштабирования Agile — такие как SAFe (Scaled Agile Framework), DAD (Disciplined Agile Delivery), ну и Scrum-of-Scrums. Хотя на этом этапе они могут применяться выборочно и ограниченно — масштаб все ещё небольшой. Например, тот же DAD предлагает использовать только те элементы из его практик, которые необходимы. Происходит попытка перенести Agile принципы и методики на другие большие части проекта, кроме самой разработки. SAFe добавляет новые элементы для верхнего уровня (PSI Planning, HIP Sprints, System Teams и т.д), оставляя Scrum на уровне подгрупп.
Тем не менее, в большинстве компаний строят своё собственное казино с блекджеком и дамами— берется обычный Scrum и на него навешиваются все элементы контроля и управления, свойственные традиционному бизнесу. Появляются так называемые “бизнес-процессы”, которые регламентируют порядок действий, разрешительную систему, процесс эскалации и решения проблем. Значительно возрастает уровень бюрократии и пропорционально снижается “гибкость” подходов. Например, внезапно оказывается, что для внесения изменений теперь требуется оформлять дополнительное соглашение и получать сначала согласие руководства и потом ещё и письменное согласие заказчика, причем в строго определенной формулировке.
Проблемы этого размера во многом обусловлены недостатком менеджеров с опытом управления проектами, где применялся масштабированный Agile. В таком случае в попытке достичь нужного результата пробуют внедрять разные подходы, переходя скорее к процессу постепенного улучшения (кайзен), где масштабируемость — приятный бонус к повышению эффективности.
40–150
Все тот же масштабируемый Agile работает в этом размере, но уже с более сложной структурой, количеством правил и применяемым из рекомендуемых практикам. Выше требования к пониманию “гибкого” подхода и опыту в его применении. Бюрократия максимально, затраты на коммуникацию растут в геометрической прогрессии. В ход также могут пойти “тяжелые” корпоративные методологии, такие как PMI, Prince2, RUP и т.д, потому что на этом уровне мы имеем дело с большой корпорацией, длительным контрактом и большой суммой денег — в этом случае, как принято в корпоративном мире, ответственность надо размывать, каждое решение — подкрепить, обосновать и утвердить.
Проекты с количеством команды проекта в 150+ — это проекты, которые успешно делятся на подпроекты и управляются как портфель или программа.
