Как лучше распределить работу между разработчиками?

Моя команда и я перестраиваем сайт, который мы разработали около десяти лет назад, и мы хотим сделать это в Agile.

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

Я буду более конкретным и скажу, что сайт разделен на отдельные модули, которые не сильно интегрированы между собой.

Каков наилучший / наиболее приемлемый способ разделения работы между разработчиками?

• Предоставление каждому человеку отдельного модуля для работы.
• Назначьте всех разработчиков одному модулю и распределите работу по разным частям модуля (UnitTesting, DAL и Mapping, Logics, UI)
• Назначьте всех разработчиков одному модулю и разделите работу по разным логикам (например, каждый разработчик отвечает за определенную логику (возможно, метод в BL) и это UnitTesting, DAL, Mapping и UI ...

Или может быть что-то совершенно другое?

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

• Разделение разработчиков на модуль:

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

• Все работают на одном модуле одновременно

  • Мы попробовали это для одного релиза, когда руководство решило, что они навязывают гибкую команду всей команде, и это будет полностью на их пути. Это как абсолютная крушение поезда. У нас была команда из 9 разработчиков, предоставляющих в год то, что обычно делал бы 1 разработчик. (Я мог бы преувеличивать здесь, но не намного).
  • Никто не чувствовал, что там была передышка. Те, кто не заботился о программном обеспечении, чувствовали себя как дома, потому что, будучи частью большого пакета, они просто растворяются в группе. Те из нас, кто имел страсть к программному обеспечению, чувствовали себя абсолютно удушенными, так как не было свободы передвигаться или выходить за пределы, о чем договорились 9 человек.
  • Все встречи дошли до того, что я захотел застрелиться. Слишком много людей с мнением в одной комнате вынуждены работать над одной и той же чертовой DLL. Ужас.
• В последнем выпуске мы решили попробовать что-то другое
  • Прежде всего, разбейте группу разработчиков на более мелкие команды из 3-4 разработчиков. Каждая команда работала в относительной изоляции друг от друга, но внутри команды люди работали гораздо сплоченнее
  • При таком подходе ожидания выполняются быстро, а встречи по планированию занимают 1-2 часа, а не 4 часа.
  • Каждый чувствует себя заинтересованным, потому что каждая команда обсуждает только то, что заботит разработчиков в этой команде.
  • Технический руководитель каждой команды периодически беседует с другими техническими специалистами, чтобы убедиться, что весь проект идет в ногу.
  • Вместо того чтобы делать людей «владельцами» определенного модуля, мы распределяли области знаний между людьми, поэтому, когда мы впервые запускали проект, у людей возникало ощущение, что у них есть свой собственный модуль, но через несколько месяцев разработчики начинают рассматривать код друг друга как области начали перекрываться.
  • Обзоры кода необходимы. Это был второй выпуск, где у нас была строгая политика проверки кода, и все в команде их любят. Эксперт в определенной области всегда находится на рассмотрении кода, когда кто-то другой изменяет этот код.
  • Благодаря обзорам кода у нас есть масса обмена знаниями, и вы можете видеть общее улучшение качества кода наших команд. Кроме того, поскольку код пересматривается так часто, когда люди попадают в чужую область знаний, есть вероятность, что он уже видел код, по крайней мере, несколько раз.
  • Большая часть каждой команды вовлечена в совещания по рассмотрению проекта, поэтому, даже если они никогда не видели код, все знакомы с общим потоком всех модулей, за которые отвечает их команда.
  • Мы занимаемся этим около 10 месяцев, и кажется, что мы начали с подхода изолированного модуля и превратились в то, что все работают над всем. Но в то же время никто не чувствует, что они стеснены или ограничены. И чтобы ребята все еще чувствовали какой-то авторитет, мы оставили их в качестве экспертов, хотя сейчас это в основном формальность.

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

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

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

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

Наконец, и это очень важно и всегда упускается из виду. ВЫ НЕ ПОЛУЧИТЕ ЭТО ПРАВО (если вы не супермен или, по крайней мере, Бэтмен). Регулярные ретроспективные встречи чрезвычайно важны. Когда мы развернули ретроспективы, они были сделаны книгой, и это было похоже на еще один процесс, через который вам пришлось пройти. Это не то, что ретроспектива для. Это для того, чтобы выслушать вашу команду, определить области, которые вызывают наибольшую боль, и исправить их, чтобы каждый мог продолжать свою работу. Очевидно, что разработчики программного обеспечения в целом, такие как предоставление продуктов и функций, и самое важное, что нужно ретроспективному собранию сообщений, - это то, что это исключительно для их выгоды. Вы хотите идентифицировать и преодолевать препятствия, начиная с самых больших (или самых простых, там

Проведите встречу с командой, покажите им список дел и спросите, кто и что хочет делать.

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

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

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

Хотя я согласен с ответом Дэвида, я чувствовал, что он может извлечь пользу из некоторых уточнений:

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

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

Самый простой подход часто самый лучший.

Я бы не стал делить задачи на группы, такие как testing / log / UI / etc, если вы не можете определить очень хорошие и понятные причины для этого. Я рассуждаю так: когда вы позволяете программистам работать за пределами их обычных областей знаний, это может сделать их более интересными и сложными для них, а также позволить им развиваться и расти в своей области. Если вы чувствуете, что временные ограничения требуют от вас разделения работы на основе опыта, как минимум убедитесь, что каждый разработчик по-прежнему обязан проводить свое собственное модульное тестирование, и использовать проверку кода и приемочное тестирование для выявления проблем. Написание собственных тестов очень гибко, и ожидание времени, когда тестеры станут доступными, может быть очень расточительным.

Столкнувшись с такой же дилеммой, я применил следующий подход:

• Сфера проекта. Дайте себе представление о том, во что вы ввязываетесь, и разработайте список функций, разбив проект на ряд задач.

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

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

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

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

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

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

Ни одно организационное обсуждение команды разработчиков не будет полным без упоминания хирургической команды доктора Фреда Брукса .

Основная формула: одна хирургическая бригада на единицу работы

Определение хирургической бригады

Концепция хирургической бригады основана на двух фундаментальных идеях:

1. Меньше разработчиков лучше на единицу работы, потому что перекрестные разговоры убивают производительность.
2. Разработчики с высоким выходом обгоняют разработчиков с низким выходом (и, по словам Брукса, не существует такого понятия, как разработчик со средним выходом), поэтому вам лучше дать им самую важную работу и ограничить их отвлекающие факторы.

Хирургическая бригада состоит из 3-10 разработчиков:

1. Главный программист Высокопроизводительный разработчик, который выполняет большую часть реального программирования.
2. Второй пилот. Другой высокопроизводительный разработчик, который занимается программированием, а также выполняет некоторые административные задачи, такие как посещение собраний и сбор требований.
3. 1 - 8 помощников. Брукс описывает их как разработчиков, ответственных за такие вещи, как документация, очистка кода, исследования, написание инструментов / алгоритмов, тестирование и т. Д. В 60-е годы Брукс предложил ровно 8 ролей, но с современными инструментами вам может понадобиться всего 1 или 2, и должно быть назначено в зависимости от потребностей вашего проекта.

Определение единицы работы

Итак, теперь, когда мы можем собрать команду, что мы им назначаем?

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

Вы должны увидеть три основных приемлемых шаблона:

1. Ровно 1 подгруппа для каждого уровня (пользовательский интерфейс, DAL и т. Д.)
2. Ровно 1 подгруппа для каждого модуля (домашняя страница, сайт поддержки, магазин)
3. Сочетание этих двух факторов (команда разработчиков низкоуровневого фреймворка и команда, ориентированная на пользовательский интерфейс для каждого модуля)

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

Конечно, это не всегда работает ...

Вот что я бы сделал:

Если все модули маленькие, то вы можете дать каждому модулю для работы. В противном случае сделайте это:

1. Определите размер каждого модуля, сложность, навыки, необходимые для этого.
2. Определите навыки каждого члена команды.
3. Определите, какие люди хорошо работают вместе, а какие плохо работают с другими.
4. Назначайте большие модули командам людей, которые хорошо работают вместе, основываясь на требованиях к навыкам модуля и навыкам команды.
5. Назначьте оставшиеся модули людям, которые не могут хорошо работать с другими людьми, исходя из требований к навыкам модуля и навыков работы в команде.

Вышесказанное не сработает, если люди, которые не любят работать с другими, являются наиболее опытными, и это распространенный случай, поэтому сделайте исключение из 4 и 5 соответственно.