Одна из самых больших ошибок, которые могут сделать компании-разработчики программного обеспечения, заключается в том, что большее количество разработчиков приведет к более быстрым выпускам продуктов. Это не так. Это поначалу кажется нелогичным, однако закон убывающей доходности применяется к большинству отраслей. И в старой поговорке есть правда о том, что слишком много поваров …
Разработка программного обеспечения — необычный и сложный процесс. В отличие от других форм производства, существует бесконечное разнообразие результатов, и каждая часть процесса интегрирована. На первый взгляд сложные процессы могут быть быстрыми и простыми в реализации, тогда как простые функции могут иметь скрытую сложность.
Однако одна из главных причин, почему больше разработчиков! = Более быстрая разработка, заключается в том, что большая команда увеличивает сложность коммуникации. Когда компонент создается или изменяется, он оказывает влияние на другие части проекта. Например, предположим, что разработчик A пишет класс подключения к базе данных и решает внести простое изменение, например, поменять местами порядок двух параметров.
- В команде из 1 разработчик может внести изменения, не общаясь с кем-либо.
- В команде из 2 разработчик должен сообщить об этом еще одному человеку.
- В команде из трех человек, есть еще два, чтобы сообщить.
Поэтому в команде с N участниками разработчик должен связаться (N-1) с другими по поводу изменения. Поскольку любой член команды может внести изменения в любое время, должно быть N * (N-1) линий связи. Однако, поскольку разработчик A общается с разработчиком B так же, как B общается с A, мы можем разделить эту сумму на две части. Наше последнее уравнение:
C = N (N — 1) / 2
Где N — количество членов команды, а C — общее количество линий связи.
К сожалению, эти линии связи растут в геометрической прогрессии с каждым дополнительным участником. Команда из 5 человек, имеет 10 линий. Команда из 10 человек имеет 45 линий. Команда из 20 человек имеет 190 строк. И команда из 100 человек имеет 4950 строк.
Неважно, как вы используете свои каналы связи. Каждый разработчик должен решить, влияет ли изменение на их код, и соответственно выполнить обновления. Сложность разработки программного обеспечения поднимает другие вопросы:
- все получили и поняли изменения?
- Некоторые члены команды нуждаются в дальнейшей помощи?
- Должен ли разработчик А обосновать обновление другим членам команды?
- Проверено ли изменение во всех системах?
- приводит ли изменение к каскаду изменений в других компонентах?
Это не просто изменения кода. Любое проектное решение должно быть рассредоточено по всей команде.
Сложные проекты занимают много времени, а перерасход ресурсов по чрезмерному графику не обязательно поможет. Возможно, вам придется признать, что график не был реалистичным с первого дня.