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

12

Ось цитата з навчального посібника з роботи щодо оцінки SLIM та програмного забезпечення:

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

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

Це здається протиінтуїтивним, припускаючи хороший процес та здібних інженерів. Наприклад, мати більше людей означає більше уваги на всі артефакти (вимоги специфікації, конструкції, код, тести). Окрім того, що у мене більше очей, моя інтуїція підказує, що між зусиллями та дефектами проекту, який використовує відповідні методи якості, існує невеликий зв’язок.

Мені не вдалося знайти жодних документів, окрім тих, що стосуються моделі Putnam (яку використовує SLIM), які б припускали будь-яку відому залежність між дефектами та зусиллями або дефектами та кількістю людей у проекті. Чи відомі це стосунки, і чи є твердженням, що "більше людей = більше вад"?

— Томас Оуенс
джерело

10

"додавання робочої сили до пізнього програмного проекту робить це пізніше" - Фред Брукс

— Одід

2

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

— Томас Оуенс

@ThomasOwens - Так, цитата дійсно стосується збільшення каналів зв'язку (а отже, і труднощів), з припущенням, що це призведе до дефектів.

— Oded

Я б ще сказав, що коли навантаження на розробників кидається на проект, це часто свідчить про марш смерті.

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

@ironcode Кількість розробників проекту має диктуватися розміром та обсягом проекту та способом його організації. Занадто багато розробників або додавання занадто багато розробників пізніше - це ознаки поганого управління, можливо, марш смерті.

— Томас Оуенс

14

Моя інтуїція виглядає так:

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

І

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

Але це можуть бути лише мої міркування, я не маю жодних підтверджень.

Як зауваження, ваші припущення, наголошені нижче, IMHO (на жаль) досить сильні, враховуючи стан нашої професії:

Це здається протиінтуїтивним, припускаючи хороший процес та здібних інженерів . [...] моя інтуїція підказує, що між зусиллями та дефектами проекту, який використовує відповідні методи якості, мало співвідношення .

— Петер Тьорк
джерело

Для того, щоб вирішити це, я приписував графік McConnell's Thrashing / Process / Productivity. Якщо ви не знайомите нових людей, ви звикаєте до спілкування, що бере участь у проекті, а підтримка відповідного спілкування стає простішою та природнішою. Це підпадає під дію Закону Брукса, коли ви додаєте людей до проекту із запізненням, що було б таким же, як запровадити процес із запізненням до проекту - збільшення каналів зв'язку означає збільшення обмолоту та розрив комунікації, що призводить до дефектів. Я, можливо, не базуюсь на цьому. Ваші міркування можуть бути дійсними.

— Томас Оуенс

Але з меншою кількістю людей ви рідше дозволяєте їм дотримуватися своїх сил. Чи легше найняти декількох хороших розробників, які насправді можуть бути кращими, якщо вони можуть зосередитись на зоні, а не лише на одному гуру, який може все?

— JeffO

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

— Péter Török

1

Чи спілкування більш клопітке чи просто стає необхідним?

— JeffO

@ Джеф О, ІМО, чим менше вони розуміють сферу один одного, тим більше потрібно спілкування і тим вище шанси на непорозуміння та помилкові припущення.

— Péter Török

5

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

— Карл Білефельдт
джерело

Єдина проблема в цьому полягає в тому, що зміни (зокрема збільшення) у персоналі з часом не згадуються. Це просто говорить про те, що якщо у вас є проект з російськими людьми, у вас будуть m дефекти. Додавання людей вводить комунікативні проблеми та проблеми, але це (з того, що я можу сказати) виходить за рамки простого взаємозв'язку між людьми-вадами. Я погоджуюсь, що побічним ефектом затримки людей є не тільки збільшення каналів комунікації та потреба в навчанні людей та доведення їх до швидкості (Закон Брукса), а й потенційне збільшення дефектів. Але це поза рамками.

— Томас Оуенс

Додавання людей із запізненням - лише один із факторів, про який я згадав. Управління по раніше має тенденцію призначати більше людей вперед , щоб проекти , які вони передбачають бути більш ризикованим або складним.

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

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

— Томас Оуенс

3

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

Тому насправді відбувається те, що більші проекти мають більше дефектів, що зовсім не дивно.

— psr
джерело

2

Це здається протиінтуїтивним, припускаючи хороший процес та здібних інженерів.

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

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

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

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

Якщо єдиний спосіб запобігти роботі 4-х розробників над одним файлом - обмежити розмір команди до 3, у вас виникли більші проблеми.

— JeffO

2

Існує різниця між кореляцією та причинно-наслідковою причиною; Цитата, схоже, говорить про те, що загальна кількість дефектів, як правило, вища для проектів, де виділяється більша кількість інженерів. Це має ідеальний сенс для мене, я впевнений, що у MS Windows є більше дефектів, ніж у створених мною додатках, але це не означає, що мої програми відрізняються високою якістю.

Наведемо ще один, більш абстрактний приклад - якби ми взяли загальну кількість випадків смерті в країні та співвіднесли це із загальною кількістю лікарів у країні, я впевнений, що ми могли б сказати, що "країни з більшою кількістю лікарів мали більше смертей". Це не тому, що лікарі спричинили смерть, а, скоріше, велика кількість лікарів свідчить про велику кількість населення.

— Даніель Б
джерело

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

— Томас Оуенс

@ThomasOwens - yepp, саме це було моєю точкою.

— Даніель Б

Чому б помилки не порівнювались щодо розміру та складності проекту?

— JeffO

@JeffO - Вимірювання цього відносно зовсім нетривіально (як саме це робити?). Можливо, оригінальне твердження виводиться з контексту, але автори рідко посилаються на складні, обчислені результати просто як "дефекти". У такому випадку я б очікував іншого слова на кшталт "якість" (з якого випливає, що був зроблений деякий розрахунок), або більш тривалої фрази на зразок "дефекти на призначеного інженера". Можливо, я тут трохи цинічно ставлюсь до авторів :)

— Даніель Б

@Jeff Вони були б. Але ви б порівняли дефекти за розміром і складністю, а не за кількістю людей. Зі збільшенням розміру та складності збільшуються дефекти та збільшується кількість людей. Так, хоча кількість людей зростає, але кількість людей не збільшує кількість дефектів.

— Томас Оуенс

1

Відкладемо на мить твердження про кількість людей.

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

Отже, якщо ви припускаєте, що чим більше зусиль докладено до проекту, тим більше рядків коду написано, то, ймовірно, ви могли б використовувати зусилля як проксі для розміру, щоб передбачити кількість дефектів. Кореляція між розміром (наприклад, LOC) та кількістю дефектів демонструється в роботах Ваттом Хамфрі, Каперсом Джонсом та іншими.

Я не бачу, як підходить кількість людей, крім більшої кількості людей, що передбачає більше зусиль.

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

— Майкл
джерело

0

Я припускаю, що це обмежується членами основної команди програмування, а не ситуацією, коли є такі фахівці, як: UI, UX, DBA тощо.

Я думаю, що з цим потрібно добре керувати, але це непросто. Невеликі команди, які складаються з якісних розробників, можуть керувати собою. Більше шансів уникнути великих розділів коду, створених людиною з меншим талантом.

Наявність більшої кількості членів команди може полегшити розподіл обов'язків. Покладіть кращих або досвідченіших розробників на складні ділянки. Відсуньте від своїх кращих розробників деякі життєві або непрограмувальні завдання і дозвольте молодшим розробникам обробляти перешкоди. Це займе більше планування та роздумів, але надасть можливість використовувати свій талант.

Існує думка, що краще мати чудового розробника, якому потрібно взяти на себе новий навик, ніж нижчого середнього розробника, який це вже знає. Це чудово, якщо у вас є час. Можливо, причиною того, що більше проекту розробляється на проект, є кількість необхідної роботи та обмеження часу. У вас може бути хтось, хто може зосередитись на певній сфері та стати більш кваліфікованим. Чудово мати ці добре всебічні знання, але іноді з невеликим напрямком менший диявол може взяти якусь інструкцію і побігти з нею.

Реальність полягає в тому, що не так багато людей, які коли-небудь керували великою командою на успішному проекті. Навіть якщо вони всі талановиті, великим командам складно самостійно керувати. Чи заважають егої?

— JeffO
джерело