Действительно ли существует связь между количеством людей, назначенных на проект, и количеством дефектов?

12

Вот цитата из учебного пособия по работе относительно SLIM и оценки программного обеспечения:

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

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

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

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

— Томас Оуэнс
источник

10

«добавление рабочей силы в поздний программный проект делает его позже» - Фред Брукс

— Одед

2

@ Oded Добавление людей поздно не упоминается вообще. Кроме того, в законе Брукса ничего не говорится о дефектах, а об увеличении каналов связи для принятия решений и информирования людей. Я подозреваю, что, как предполагает Карл Билефельдт, проблемы со связью могут привести к дефектам.

— Томас Оуэнс

@ThomasOwens - Да, цитата действительно об увеличении каналов связи (и, следовательно, о трудностях) с предположением, что это приведет к дефектам.

— Одд

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

— Морган Херлокер

@ironcode Количество разработчиков в проекте должно определяться размером и масштабами проекта, а также тем, как он организован. Наличие слишком большого количества разработчиков или добавление слишком большого количества разработчиков позже являются признаками плохого управления, возможно, маршем смерти.

— Томас Оуэнс

14

Моя интуиция звучит так:

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

И

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

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

Как примечание: ваши предположения, подчеркнутые ниже, являются ИМХО (к сожалению) довольно сильными, принимая во внимание состояние нашей профессии:

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

— Петер Тёрёк
источник

Я приписал график Макконнелла Thrashing / Process / Productivity, чтобы решить эту проблему. Если вы не знакомите с новыми людьми, вы рано привыкаете к коммуникационным накладным расходам, связанным с проектом, и поддержание надлежащего общения становится более простым и естественным. Это нарушает закон Брукса, когда вы добавляете людей в проект с опозданием, что равносильно введению процесса с опозданием в проект - увеличение каналов связи означает увеличение обмолота и обрыв связи, что приводит к дефектам. Я мог бы быть вне базы на этом, хотя. Ваше рассуждение может быть верным.

— Томас Оуэнс

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

— Джефф

@ Джефф О, у тебя есть смысл. OTOH, если каждый разработчик фокусируется только на своей сильной области, общение между ними может стать еще более проблематичным.

— Петер Тёрёк

1

Является ли общение более проблемным или просто становится необходимым?

— JeffO

@Jeff O, IMO, чем меньше они понимают области друг друга, тем больше требуется общения, и тем выше вероятность недопонимания и ложных предположений.

— Петер Тёрёк

5

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

— Карл Билефельдт
источник

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

— Томас Оуэнс

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

— Карл Билефельдт

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

— Томас Оуэнс

3

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

Поэтому на самом деле происходит то, что в крупных проектах больше дефектов, что неудивительно.

— PSR
источник

2

Это кажется нелогичным, предполагая хороший процесс и способных инженеров.

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

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

По моему опыту, негативные последствия проектов, загруженных разработчиками, значительно снижаются, когда проект очень модульный, и у вас есть только 1 или 2 человека на уровень. Мне все равно, какую систему управления версиями вы используете, потому что иметь 4 разработчика, которые автоматически объединяют проверки в один и тот же файл одновременно, вероятно, будет плохой идеей.

— Морган Херлокер
источник

Если единственный способ запретить 4 разработчикам работать с одним файлом - это ограничить размер команды до 3, у вас будут большие проблемы.

— Джефф

2

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

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

— Даниэль Б
источник

Для вашего примера с Windows, я уверен, что Windows также имеет больше возможностей для дефектов просто потому, что она больше. Если бы один разработчик написал систему с 10 SLOC и систему с 10000 SLOC, система с 10000 SLOC имела бы больше шансов на наличие дефекта (который включает опечатки, препятствующие компиляции, отсутствующие точки с запятой, логические ошибки и т. Д.) , Как правило, в более крупных проектах будет больше инженеров, но связь не между количеством людей и дефектами, а размером и дефектами.

— Томас Оуэнс

@ThomasOwens - да, это была моя точка зрения точно.

— Даниэль Б

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

— Джефф

@JeffO - Измерение его относительным способом совершенно нетривиально (как именно вы это делаете?). Возможно, первоначальное утверждение вырвано из контекста, но авторы редко называют сложные, рассчитанные результаты просто «дефектами». В таком случае я бы ожидал другое слово, такое как «качество» (что подразумевает, что некоторые вычисления были сделаны), или более длинную фразу, например «дефекты на назначенного инженера». Возможно, я немного циничен по отношению к авторам здесь :)

— Даниэль Б

@ Джефф Но вы бы сравнили дефекты по размеру и сложности, а не с количеством людей. Как размер и увеличение сложности, дефекты увеличить и количество людей увеличится. Так что да, хотя количество людей действительно увеличивается, это увеличение людей не увеличивает количество дефектов.

— Томас Оуэнс

1

Давайте на минуту отложим утверждение о количестве людей.

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

Поэтому, если вы предполагаете, что чем больше усилий вкладывается в проект, тем больше строк кода написано, то вы, вероятно, могли бы использовать усилие в качестве прокси для размера, чтобы предсказать количество дефектов. Корреляция между размером (например, LOC) и количеством дефектов неоднократно демонстрировалась в работах Уоттса Хамфри, Каперса Джонса и других.

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

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

— Майкл
источник

0

Я предполагаю, что это ограничено членами основной команды программистов, а не ситуации, когда есть такие специалисты, как: UI, UX, DBA и т. Д.

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

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

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

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

— JeffO
источник