Чому додавання більшої кількості людей до пізнього проекту робить це пізніше?

Це досить поширена приказка, що додавання більшої кількості програмістів до пізнього проекту погіршить питання. Чому це?

Вступ накладні

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

Тому, чим більше нових розробників ви додасте до проекту, тим більше часу потрібно витратити, щоб довести їх до точки, коли вони можуть насправді внести свій внесок у проект.

Окрім інших відповідей: Ще одним фактором, який слід враховувати, є спілкування.

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

Проблема, про яку йдеться в книзі, яка спочатку оприлюднила цей закон, «Міфічний чоловік-місяць» , - це спілкування. Він починає, кажучи:

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

В якості проблеми він згадує навчання:

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

... але зазначає, що взаємодія є набагато більшим фактором:

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

Варто також зазначити, що у Фреда Брукса (автора) є основи, щоб знати, про що він говорить. Більшість книг базується на його досвіді управління проектом IBM OS / 360. Незважаючи на десятиліття прихильників, які проповідують усілякі "вдосконалені" методи управління, а деякі навіть придумують круті імена (eXtreme, Agile, Scrum тощо), коли ви переходите до цього, мало що з суті ^1, здається, змінилося з тих пір.

¹ Для визначення поняття "сутність" див. "Немає срібної кулі: сутність та нещасний випадок в інженерії програмного забезпечення" того самого автора, що увійшов до 20 ^- річного видання "Міфічного чоловіка-місяця" .

Це не просто прислів'я; це можна перевірити. Ознайомтеся з міфологічним місяцем людини Брукса .

Ось кілька думок з цього питання ...

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

Тепер додавання нових ресурсів для тестування може не бути поганою ідеєю ... це може пришвидшити процес тестування (якщо ваші тестові справи добре написані), і так, також використання інструментів тестування також допоможе.

Тому що програмування не є основною роботою на виробничій лінії. Швидкість роботи над програмним проектом потребує часу. Новим людям потрібно задавати багато питань, що призводить до негативної продуктивності (тобто, нова людина вчиться, стара людина навчає їх -> ніякої фактичної роботи не робиться).

Щоб спростити це, уявіть собі відносно простий проект для чоловіків, який планується тривати протягом 1 тижня: у четвер ви розумієте, що це не буде виконано вчасно, а для цього потрібен один програміст, як 6-7 днів з 5. Якщо в цей момент ви додасте іншого програміста, їм потрібно буде працювати з програмістом1 принаймні кілька годин або щодня або близько того, задавати багато питань, щоб швидко набирати швидкість тощо. Ви, мабуть, не отримаєте будь-яка чиста позитивна продуктивність протягом останнього тижня. Новий програміст, ймовірно, введе і деякі зайві помилки (оскільки вони не будуть знати існуючого коду, а також програміст1), так що це вибухне цикл впровадження та тестування ще через день або два. Проект легко триватиме цілих два робочих тижні замість оригіналу!

Фред Брукс написав цілу книгу "Міфічний чоловік-місяць", відповідаючи на це питання.

Ось швидка n-брудна версія:

1) Існує обмеження на те, скільки ви можете розбити проект на різні частини, щоб призначити більше програмістів.

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

3) Для кожної людини, яку ви додаєте до проекту, ви додаєте більше одного каналу зв'язку, який повинен переходити до команди. Це число зростає геометрично і збільшує кількість спілкування, яке має відбутися. Більше спілкування = Більше роботи.

4) Існує "J-крива", коли ви додаєте кожного члена команди. Тобто, наявні виробничі ресурси повинні витратити час на те, щоб нові люди швидко розвивалися, щоб вони могли витратити роботу над проектом. Зрештою, ви можете збільшити потужність, але це тимчасово сповільнює проект. Чим пізніше в проекті, тим більше потрібно дізнатися, тим сильніше виражений ефект.

Ще один фактор, про який я не бачив, - це те, що деякі завдання потрібно виконувати в певному порядку. Ви не можете виконувати завдання 4, поки завдання 3 не буде виконано, оскільки це залежить від 3. Це не приносить користі наймати когось, щоб він виконував завдання 4 одночасно, хтось виконував завдання 3. Часто в кінці проекту , ті завдання, які спочатку потребують інших речей, - це інші завдання.

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

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

Я б також запропонував "Народні засоби" від DeMarco та Lister.

І "Дедлайн" від DeMarco представляє це та ряд інших програм управління проектами захворювань та помилок легким та дуже читабельним способом.

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

Ці книги досить дешеві, я б пропонував вам їх придбати (у Амазонії чи Книгарні) і прочитати. Короткі відповіді тут справді не можуть справедливо відповідати на поставлене питання.

Тому що ніхто не витрачає час на продуманий, спланований, випробуваний процес: наймання, навчання, розробку та нагляд за програмістами, не кажучи вже про те, щоб привернути їх до того, щоб досягти певного проекту.

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

З якою швидкістю ви зможете отримати абсолютно нову установку машини для розробки та готову до роботи?

Ви коли-небудь тестували свою проектну документацію та характеристики, показуючи їх розробнику для іншого проекту? Чи переглянули вони це і чи визначили, що при необхідності можуть почати працювати над проектом?

Наскільки актуальний будь-який графік проекту?

Економте для дощового дня, бо коли проект відстає, це більше нагадує ураган.

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

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

Я хотів би зазначити щось повністю ігнороване іншими відповідями.

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

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

Люди наверху, очевидно, втратили віру в вас. Вони закликали великих хлопців компенсувати те, що ви зіпсували.

Чи будете ви все-таки мотивовані, щоб це досягти успіху? Або ... чи будете ви колись ще більш розчаровані, і хочете, швидше, побачите, як вся справа розбита?

Не поспішай :-).