Изобретаем успех: софт и стартапы
75,72
рейтинг
6 декабря 2015 в 22:02

Разработка → Основные законы создания команд разработчиков

В EDISON часто обращаются инженеры, желающие добавить сотрудников в команду. Хочется «по-быстрому склепать задачку», воспользовавшись десятком дополнительных разработчиков. Работает ли подобный подход? К сожалению, не всегда. В программировании, как в физике, есть законы.


Собрать толковую команду — настоящее искусство

Закон Брукса


Ни одно обсуждение команд разработчиков не проходит без упоминания данного принципа:

«Добавляя людских ресурсов, мы задерживаем окончание программного проекта» (Брукс, 1975).

Бесчисленные команды разработчиков подтвердили постулат. Законы Брукса и Конвея составляют базу.

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

Свежий персонал нуждается в помощи не только в первую неделю. Часть авторов (например, Коплиен и Харрисон) предполагают годичный интервал до получения от новичка продуктивности. Не стоит придавать утверждению излишнего значения из-за влияния разных факторов. Разумно предположить, что часть сотрудников обойдется без помощи в первые три месяца.

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

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

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

Закон Брукса не означает полный отказ от расширения команд. Но рост объединения редко происходит быстро. Если команда решила расширяться, будет использоваться часть производительности для наращивания мощности.

Ричард Шеридан сделал смелое заявление:

Я рад сообщить, что закон Брукса может быть нарушен. Вся наша деятельность сфокусирована на том, чтобы сломать утверждение. Разделение людей на пары, перемещение между парами, автоматизация тестирования, управление кодом, наём, основанный не на героях, постоянные переговоры, открытая рабочая среда и видимые артефакты — всё, чтобы опровергнуть утверждение Брукса (Шеридан, 2013).

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

Методы, описанные автором, заслуживают доверия. Отлично, если закон Брукса будет нарушен.

Закон Конвея


Организации, проектирующие системы, … производят их, копируя структуры коммуникации, сложившиеся в этих организациях,
— Конвей, 1968

Люди и их организация играют значительную роль в определении архитектуры ПО, принимаемой разработчиками.

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

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

Взглянем на систему после 10-ти лет функционирования. Наблюдается обратный закон Конвея:

Предприятия, использующие программные системы… ограничены структурами коммуникации, которые копируют эту систему.

Закон Конвея сообщает о возможном копировании проблем предприятия в интерфейсе: в слоях, или в APL, или в модулях, или где-нибудь ещё.

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

Число Данбара. Природные ориентиры


«Экстраполяция на людей отношений среди обезьян даёт представления о размерах социальных групп. Около 150 особей — предел социальных отношений человека. Количество удостоилось названия «Числа Данбара»,
— Данбар, 2010

Частый вопрос от групп разработчиков: «Насколько большой должна быть команда?» Работа антрополога Робина Данбара дает интересные идеи при попытке ответить на вопрос.

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

Сообщества свыше 150 членов менее сплочённые, требующие повышенного контроля поведения и иерархии. В исследованиях и анализе подчёркиваются основные моменты в формировании групп. Параметр грамотнее назвать «Числами Данбара». Характеристики применимы к различным группам, входящим в состав крупных формирований. Меньшие команды крепче и по предположению опираются на числа с множителем 3.
Следуя тезису, у большинства людей круг близких друзей от 3 до 5 человек. Следующий уровень приятелей от 10 человек до 13–15 (при определенных усилиях). Очередная группа содержит от 30 до 50 — типичный боевой взвод. Популяция в 150 представляет минимальный независимый блок в военной компании и точку создания на предприятиях отдельных группировок.

Данбар предполагает существование формирования в 500 и 1500. Автор поддерживает Платона в определении идеального размера для демократии в 5300 единиц. Можно провести интересные параллели между размерами военных блоков.

Oрганизация Размер
Пожарная дружина 4 или меньше человек
Секция/Отряд 8–12 участников (несколько пожарных дружин)
Взвод 15–30 служащих (2 отряда)
Рота 80–250 солдат (несколько взводов)
Батальон 300–800 бойцов

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

Магическая семерка Миллера (кошелёк Миллера)


Принято считать мудрым выбором размер команды из 7 человек (± 2). Практического смысла в утверждении нет. Доказательства тезиса об оптимальном количестве членов команды в 5–9 человек отсутствуют.

Сторонники размера апеллируют к знаменитой статье Миллера 1956 года «Магическое число семь плюс минус два: некоторые ограничения нашей способности обработки информации». На практике большинство ссылающихся труд не читали.

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

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

Значимость магии числа 7 под вопросом.

В заключении автор говорит: «Я чувствую, что мой рассказ здесь должен остановиться, т. к. он уже стал достаточно интересным». С публикации статьи Миллера прошло более 50 лет. По общему мнению, диапазон команды 5–9 человек удовлетворителен для управления изменениями. Снизу интервала оправдана необходимость проведения тестов и выполнение требований к команде специалистов. На верхней границе диапазона сложно осуществлять полный контроль системы. Поэтому число сотрудников от 5 до 9 человек имеет смысл.

Описанное количество не отменяет существование команд большего размера в зависимости от обстоятельств.

Размер команды в методологии Scrum


Как статья Миллера об объемах обработки информации человеческим мозгом может применяться к определению размера команды разработчиков ПО? Обратимся к методологии Scrum. В учебнике говорится: «Команда в Scrum должна быть семь плюс или минус два человека» (Димер и др., 2008). Одновременно в руководстве по Scrum за 2011 утверждается: «Команды из более девяти членов вызывают слишком много проблем в координации. Большие команды разработчиков заметно усложняют весь процесс» (Сазерленд и Швабер, 2013).

Учебное пособие гласит:

Роли владельца продукта и руководителя команды Scrum не включены в подсчет, кроме случаев, когда они включаются в работу для сокращения отставания в очередном спринте,
— Сазерленд и Швабер, 2013

Параллельно введение руководителя команды Scrum предполагает, что владелец продукта находится вне команды.

Другие источники дают различные рекомендации по определению членов группы и «просто участвующих».

Команды в диапазоне 4–8 человек видны повсеместно. Статьей Миллера рационально обосновать выбор размеров групп из 7 ± 2. Опыт подтверждает оптимальный предел численности. Количество может быть больше заявленного в источниках по Scrum.

Закон Паркинсона и Закон Хофштадтера


Работа заполняет все время, выделенное для ее выполнения,
— закон Паркинсона

Всегда потребуется больше времени, чем вы ожидаете, даже если вы знаете закон Хофштадтера,
— закон Хофштадтера, 1980

Попробуем ответить на вопрос: «Помните ли вы обучение в ВУЗе? В какой момент реализовывались задания?» Большинство читателей выполняли работу за несколько дней до дедлайна. Часть занималась проектом в ночь перед сдачей.

И подавляющее большинство укладывалось в срок.

Ученые подтверждают: люди плохо справляются с оценкой периода, требующегося на выполнение работы, но преуспевают с решением задачи к четко оговоренной дате (например, Buehler, Гриффин и Peetz, 2010).

При избытке времени на проект происходит чрезмерное расширение объема работ исполнителем.

На разработку программного обеспечения влияют законы Паркинсона и Хофштадтера. Выбирая дату дедлайна, неизбежно возникнет недооценка требуемого времени. В итоге сроки и объем работ увеличатся. Проведенное исследование (Бюлер, Гриффин и Питз, 2010) свидетельствует: оптимизм относительно даты выполнения задачи дает возможность осуществить работу раньше, чем при пессимистичной оценке сроков. Но общее время выполнения проекта оптимистом окажется дольше, чем у пессимиста. Срок дедлайна может быть важнее предполагаемого времени завершения проекта (Арили и Wertenbroch, 2002).

Закон Голла. Парнас и Александер


Сложная рабочая система неизменно получается из простой рабочей системы. Сложная система, разработанная с нуля, никогда не работает. И никакие улучшения не заставят ее работать. Начинать следует с простой рабочей системы,
— закон Голла, 1986

Закон перекликается со словами Дэвида Парнаса:

«Как правило, системы ПО не работают хорошо, пока они не были использованы, и не раз, в «боевых» условиях».

Авторы подчеркивают различные аспекты одного явления, называемого Кристофером Александером «органическим ростом».

При создании ПО, применяя технику под названием «ходячий скелет», рекомендуется сделать простой, базовый рабочий кусок кода. «Скелет», хоть и с определенным риском, но проталкивающий систему вперед. Создав базу, команда добавляет «плоть» — слой функционала.

Принцип может применяться к группам, к ПО:

«Эффективная сложная команда неизменно возникает из простого продуктивного аналога. Сложная команда, собранная с нуля, результативно функционировать не может. И никакие изменения не заставят ее работать. Дело стоит начинать с уже сработавшейся командой».

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

Очевидна связь с законом Конвея: построение «ходячего скелета» базируется на костяке команды. Для создания большого и сложного формирования используется равноценный скелет-костяк.

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

Законы Келли


Следует добавить пару полезных постулатов от автора статьи.

Масштаб ПО всегда будет увеличиваться пропорционально имеющимся ресурсам,
— первый закон Келли

Внутри каждого большого проекта в области разработки есть маленький побочный проект вне основной задачи
— второй закон Келли

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

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

Вывод


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

Второй постулат Келли подсказывает решение: избегайте большого, сосредоточьтесь на малом.

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

Статья является отрывком из новой книги Аллана Келли «Xanpan книга 2: средство производства». Будет доступна в конце 2015 года.

Автор: @ThomasAlva
Edison
рейтинг 75,72
Изобретаем успех: софт и стартапы

Комментарии (17)

  • 0
    Статья напомнила мне видео на канале Vsauce, в ютубе.
  • 0
    Насчет закона Мелвина Конвея, в оригинале звучит как: «organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations», т.е. эти организации вынуждены так поступать, а не потому что они этого хотят. В цитате из статьи почему-то это слово опущено.

    Организации, проектирующие системы, … (???) производят их, копируя структуры коммуникации, сложившиеся в этих организациях,
    — Конвей, 1968


    Т.е. как ни крути — а структура ПО всегда будет следствием порядков в организации. Поэтому это и называют «законом».

    Все это относится не только к ПО, об этом сам автор пишет в преамбуле к статье:

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

    www.melconway.com/research/committees.html


  • +12
    Только мне кажется что именно для таких статей создавался http://megamozg.ru/?
    • +5
      Просто в эдисоне этом понимают, что на мегамозге их рекламу никто читать не будет. А вообще за «случайное» размещение рекламы на хабре надо бы банить на пару месяцев.
      • +7
        У них корпоративный блог, а для корп. блогов правила немного другие.
        • –1
          Да, верно. Но по хорошему заголовок таких постов должен начинаться с «Реклама: Основные законы...», чтобы не обманывать читателей. Но проблема ведь в том, что без такого обмана (это ещё, кажется, называется «джинсой») число прочитавших статью будет намного меньше. Так что всё честно: читателей обманывают насчёт содержимого статьи, а они в ответ кидают в корпоративный блог помидорами.
          • 0
            За помидоры вам еще и карму сольют — мне два человека после поста заминусовали. Корпоративный дух. Команда крепкая, видимо.
            • +1
              Ну где-где реклама в статье-то? Там вообще ничего о фирме не нашел, кроме первой строки. Так можно вообще можно любую статью в корпоративном блоге называть рекламой (гугл описывает разработку хрома — реклама, пишет о поиск — реклама и т.д.). И, ИМХО, не стоит грешить на команду, я заметил, на хабре вообще не любят кидание помидорами в комментах, если статья совсем уж не провальная.
              • +2
                Рекламы как таковой нет. Упоминание компании в корпоративном блоге один раз — это нормально.
                Но статья начинается многообещающе: «к нам обращаются многие за помощью и вообще...» и я, например, ожидал, как минимум, примеров из опыта компании с собственными выводами.
                На деле оказалось что компания просто наняла копирайтера, который надергал цитат из книжек по менеджменту.
                Хочется заметить, что книжек на свете много и некоторые противоречат друг другу (а некоторые зачастую и самим себе). Про применимость к конкретным случаям я уж вообще молчу.
                Если бы статья была в форме «теория -> как это в нашей компании», то было бы гораздо больше смысла.
                Читать в очередной раз о законе Брукса в теории лично мне было разочарованием.

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

                Компании тоже можно понять — корпоративный блог надо поддерживать. Если он бесплатный, то в него надо сколько-то статей в год выдавать. Если платный — то просто так платить за него не хочется. Писать технари отказываются, а девочка-копирайтер умеет только про менеджмент.
            • +1
              Мне тоже два минуса прилетело :)
    • +2
      Ну все-таки грамотный подбор команды касается всех программистов в команде, а не только одного менеджера/директора. Особенно если в команде используется Scrum и т.п. методологии. Хотя я не менеджер, а программист (ну ладно, на данный момент не менеджер) мне почитать было довольно интересно. ИМХО, для team lead'ов и senior программистов статья должна быть интересной, поэтому ей вполне место на хабре (ИМХО, конечно).
  • 0
    оптимизм относительно даты выполнения задачи дает возможность осуществить работу раньше, чем при пессимистичной оценке сроков. Но общее время выполнения проекта оптимистом окажется дольше, чем у пессимиста.


    Как можно осуществить работу раньше, но при этом с большим общим временем выполнения?

    Срок дедлайна может быть важнее предполагаемого времени завершения проекта

    Чо?
    • +1
      Как можно осуществить работу раньше, но при этом с большим общим временем выполнения?

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

    • 0
      Как можно осуществить работу раньше, но при этом с большим общим временем выполнения?

      Я понял так, что оптимист и пессимист делают работу за одно время, но дают разные предварительные оценки сроков
      • +2
        Пессимист еще в процессе ноет как все плохо и всех этим достает.
        • 0
          Именно по этому оптимист не попадает в сроки: не учитывает возможные затраты на нытье пессимистов (и флуд пофигистов), которые отвлекут от работы.
  • +4
    На картинке неплохая команда. Но что насчет этой команды?
    image

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка