Людино-місяць брукс - міфічний людино-місяць або як створюються програмні системи

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

Мал. 2.1 Залежність часу від числа зайнятих - повністю разделімого завдання

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

Мал. 2.2 Залежність часу від числа зайнятих - нероздільна задача

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

Мал. 2.3 Залежність часу від числа зайнятих - нероздільні завдання, що вимагає обміну даними

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

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

Мал. 2.4 Залежність часу від числа зайнятих - завдання зі складними взаємозв'язками

З обміном даними справа йде гірше. Якщо всі частини завдання повинні бути окремо скоординовані між собою, то витрати зростають як n (n-2) / 2. Для трьох працівників потрібно втричі більше попарного спілкування, ніж для двох, для чотирьох - вшестеро. Якщо крім цього виникає необхідність в нарадах трьох, чотирьох і т.д. працівників для спільного вирішення питань, положення стає ще гірше. Додаткові витрати на обмін даними можуть повністю знецінити результат дроблення вихідної задачі і привести до положення, описуваного малюнком 2.4.

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