Каково идеальное соотношение ролей в agile-команде?

TL;DR

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

Размер команды

На этот вопрос нет единого канонического ответа. Многое зависит от организации, проекта и доступных ресурсов. Рекомендация большинства agile-практиков — 4-9 человек; Обычно я рекомендую команду из семи человек, плюс-минус два человека, в зависимости от размера или сложности проекта.

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

Учитывая следующее уравнение для определения количества каналов связи в команде (выраженное в виде кода Ruby):

# n * (n - 1) / 2
def channels people
  people * (people - 1) / 2
end

Вы можете быстро увидеть, что у команды из 7 человек есть 21 канал связи, а у команды из 9 человек — 36. Команда из 20 человек имеет 190 каналов, что обычно нарушает основной принцип Agile, который ценит «[я] людей и взаимодействия выше». процессы и инструменты». Вы обнаружите множество гибких командных процессов, которые плохо работают в больших командах; 15-минутный ежедневный стендап — лишь один из таких примеров.

Многофункциональность и самоорганизация

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

Кроме того, команды добиваются успеха или терпят неудачу как команда. Для этого команды должны иметь возможность самоорганизовываться. На практике это может означать, что Боб пишет документацию, а Алиса пишет код, а Мэллори пишет приемочные тесты, которые Джо запускает на сервере непрерывной интеграции. Однако Боб пишет документацию не потому, что он технический писатель; он пишет документацию, потому что сотрудничает с Алисой по какой-то функции и решает, что у него достаточно пропускной способности для написания документации, в то время как Алиса проводит технические тесты на уровне разработчиков для кода, который они вдвоем только что написали совместно.

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

Команды в переходный период

Для групп разработчиков программного обеспечения, находящихся на переходном этапе, я обычно выступаю за следующее:

• 5 разработчиков, которые работают в интерактивном режиме со всеми остальными, чтобы гарантировать, что спецификации TDD/BDD написаны, код задокументирован, а функции протестированы в соответствии с «определением готовности».
• 1 эксперт по контролю качества, разбирающийся в коде, который может работать вместе с разработчиками, помогая им писать более качественные тесты, и который может поддерживать сервер непрерывной интеграции.
• 1 разбирающийся в коде эксперт по техническому написанию, который может работать вместе с разработчиками, чтобы убедиться, что продукт документирован по мере его написания (а не постфактум), и что разработчики пишут документируемый код и обновляют комментарии к коду и документацию.

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

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

То же самое для документации.

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

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

Соотношение зависит от компании и от того, насколько команда менеджеров ориентирована на программное обеспечение и управление проектами.

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

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

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

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

Лично мне нравится следующее утверждение из руководства по Scrum .

Scrum не признает никаких титулов для членов Команды Разработки, кроме Разработчика, независимо от работы, выполняемой этим лицом; исключений из этого правила нет;

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

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