Глава 2 цей міфічний «людино-місяць» - міфічний людино-місяць або як створюються програмні
Щоб приготувати смачну їжу, потрібен час. Якщо вам довелося чекати, то лише тому, що ми хочемо краще обслужити вас і доставити вам задоволення.
МЕНЮ РЕСТОРАНУ «АНТУАН» В НЬЮ-Орлеані
Програмні проекти частіше провалюються через брак календарного часу, ніж по всіх інших причин разом узятим. Чому ця причина невдач настільки поширена?
По-перше, слабо розвинені наші методи оцінок. По суті, вони відображають мовчазне і абсолютно невірне припущення, що все буде йти добре.
По-друге, наші методи оцінки помилково плутають досягнутий прогрес з витраченими зусиллями, неявно припускаючи, що швидкість виконання проекту пропорційна кількості зайнятих в ньому співробітників.
По-третє, оскільки менеджери програмних проектів не впевнені в своїх оцінках, їм часто бракує важливого впертості, як у шеф-кухаря ресторану «Антуан».
По-четверте, виконання графіка робіт слабо контролюється. Типові випробувані в інших інженерних дисциплінах методи вважаються радикальними нововведеннями при розробці програмного забезпечення.
По-п'яте, при виявленні відставання від графіка природною і загальноприйнятою реакцією є збільшення числа розробників. Це все одно, що гасити полум'я бензином. В результаті справи йдуть значно гірше. Чим сильніше полум'я, тим більше потрібно бензину, і в підсумку цей шлях призводить до катастрофи.
Контроль виконання графіка буде предметом окремої розмови. Розглянемо більш докладно інші аспекти проблеми.
Всі програмісти - оптимісти. Можливо, ця сучасна різновид чаклунства особливо приваблива для тих, хто вірить в хеппі-енди і добрих фей. Можливо, сотні невдач відштовхують всіх, крім тих, хто звик зосереджуватися на кінцеву мету. А може бути, справа всього лише в тому, що комп'ютери і програмісти молоді, а молодості властивий оптимізм. Як би там не було, в результаті одне: «На цей раз вона точно піде!» Або. «Я тільки що виявив останню помилку!»
Отже, в основі планування розробки програм лежить помилкове припущення, що все буде добре, тобто кожна задача займе стільки часу, скільки «повинна» зайняти.
Глибокий оптимізм програмістів заслуговує більш серйозного вивчення. Дороті Сейерс (Dorothy Cayers) в своїй чудовій книзі «Розум творця» ( "The Mind of the Maker") виділяє в творчої діяльності три стадії: задум, реалізацію, взаємодія. Відповідно, книга, комп'ютер або програма спочатку виникають як ідеальне побудова, існуюче не в часі і просторі, а лише в мозку свого творця. Реалізація ж в часі і просторі відбувається за допомогою пера, чорнила, паперу, або - проводів, кремнію і фериту. Творіння буде завершено, коли хто-небудь прочитає книгу, скористається комп'ютером або запустить програму, тим самим вступивши у взаємодію з розумом їх творця.
Це опис використовується Сейерс для освітлення не тільки творчої діяльності людини, а й християнського догмату Трійці, допоможе нам в нашій поточної задачі. Для людини, яка щось створює, неповнота і суперечливість ідей виявляються тільки при їх реалізації. Тому для теоретика виклад на папері, експериментування, виготовлення є невід'ємними частинами творчого процесу.
У багатьох видах творчої діяльність матеріал важко піддається обробці. Дерево колеться, фарби брудняться, електричні ланцюги «дзвенять». Ці фізичні обмеження звужують коло ідей, які можуть бути виражені, а також створюють несподівані труднощі при реалізації.
Реалізація, таким чином, вимагає сил і часу як через фізичного матеріалу, так і з огляду на неадекватність основоположних ідей. Більшу частину труднощів при реалізації ми схильні пояснювати недоліками фізичного матеріалу, оскільки він «чужий» нам - на відміну від ідей, якими ми пишаємося.
При створенні ж програм ми маємо справу з надмірно податливим матеріалом. Програміст здійснює свої побудови на основі чистого мислення - понять і дуже гнучких їх уявлень. Оскільки матеріал настільки податливий, ми не очікуємо труднощів при реалізації, звідси і наш глибокий оптимізм. Через помилковості наших ідей виникають помилки в програмах. Отже, наш оптимізм не має виправдання.
Для окремого завдання допущення, що все буде добре, надає на графік робіт імовірнісний ефект. Все може дійсно йти за планом, оскільки є деякий розподіл ймовірності для можливої затримки і існує кінцева ймовірність того, що затримки не буде. Однак великий програмний проект складається з безлічі завдань, частина з яких може бути розпочато тільки після закінчення інших. Імовірність того, що всі завдання будуть завершені в строк, нескінченно мала.
Друга помилка міркувань укладена в самій одиниці виміру, що використовується при оцінюванні та плануванні: людино-місяць. Вартість дійсно вимірюється як твори числа зайнятих на кількість витрачених місяців. Але не досягнутий результат. Тому використання людино-місяці як одиниці виміру обсягу роботи є небезпечною помилкою.
Мал. 2.1 Залежність часу від числа зайнятих - повністю разделімого завдання
Число зайнятих і число місяців є взаємозамінними величинами лише тоді, коли завдання можна розподілити серед ряду працівників, які не мають між собою взаємозв'язку (рис. 2.1). Це вірно, коли жнуть пшеницю або збирають бавовну, але в системному програмуванні це далеко не так.
Мал. 2.2 Залежність часу від числа зайнятих - нероздільна задача
Якщо завдання не можна розбити на частини, оскільки існують обмеження на послідовність виконання етапів, то збільшення витрат не впливає на графік (рис. 2.2). Щоб народити дитину потрібно дев'ять місяців незалежно від того, скільки жінок залучено до вирішення даного завдання. Багато задач програмування відносяться до цього типу, оскільки налагодження за своєю суттю носить послідовний характер.
Мал. 2.3 Залежність часу від числа зайнятих - нероздільні завдання, що вимагає обміну даними
Для завдань, які можуть бути розбиті на частини, але вимагають обміну даними між подзадачами, витрати на обмін даними повинні бути додані до загального обсягу необхідних робіт. Тому досяжний найкращий результат виявиться трохи гірше, ніж просте відповідність числа зайнятих і кількості місяців (рис. 2.3).
Додаткове навантаження складається з двох частин - навчання і обміну даними. Кожного працівника потрібно навчити технології, цілям проекту, загальної стратегії і плану роботи. Це навчання не можна розбити на частини, тому дана частина витрат змінюється лінійно залежно від числа зайнятих.
Мал. 2.4 Залежність часу від числа зайнятих - завдання зі складними взаємозв'язками
З обміном даними справа йде гірше. Якщо всі частини завдання повинні бути окремо скоординовані між собою, то витрати зростають як n (n-2) / 2. Для трьох працівників потрібно втричі більше попарного спілкування, ніж для двох, для чотирьох - вшестеро. Якщо крім цього виникає необхідність в нарадах трьох, чотирьох і т.д. працівників для спільного вирішення питань, положення стає ще гірше. Додаткові витрати на обмін даними можуть повністю знецінити результат дроблення вихідної задачі і привести до положення, описуваного малюнком 2.4.
Оскільки створення програмного продукту є по суті системним проектом - практикою складних взаємозв'язків, витрати на обмін даними великі і швидко починають переважати над скороченням термінів, що досягається в результаті розбиття завдання на більш дрібні підзадачі. В цьому випадку залучення додаткових працівників не скорочує, а подовжує графік робіт.
З усіх елементів графіка робіт найбільшого впливу з боку обмежень на послідовність виконання дій схильні до налагодження компонентів і системне тестування. Крім того, витрати часу залежать від кількості виявлених помилок і від того, наскільки вони «приховані». Теоретично, помилок бути не повинно. Через свого оптимізму ми зазвичай схильні недооцінювати дійсне кількість помилок. Тому в програмуванні дотримуватися графіків робіт зазвичай найважче при налагодженні.
Протягом ряду років при плануванні розробки програмного забезпечення я користуюся наступним емпіричним правилом:
1/6 - написання програм,
1/4 - тестування компонентів і попереднє системне тестування,
1/4 - системне тестування при наявності всіх компонентів.
Це правило має кілька важливих відмінностей з загальноприйнятим плануванням:
1. На планування відводиться більше часу, ніж зазвичай. І все одно цього часу ледве достатньо для розробки докладних і надійних технічних умов і недостатньо для проведення дослідницьких робіт або пошуку нових технологій.
2. Половина графіка робіт, відведена на налагодження закінченого коду, значно вище норми.
3. Та частина, яку легко оцінити, тобто написання коду, займає всього одну шосту загального часу.
Вивчаючи проекти, графік яких був складений традиційним чином, я виявив, що деякі з них відводили за графіком половину часу на налагодження, але на практиці в більшості випадків витрачали на неї половину фактичного часу. Багато проектів вкладалися в графік на всіх етапах, крім системне тестування. [2]
Особливо катастрофічні наслідки може мати недолік часу для системного тестування. Оскільки затримка відбувається в кінцевій частині графіка, ніхто не підозрює про те, що графік знаходиться під загрозою зриву аж до дня здачі продукту. Погані вісті, отримані пізно і без попередження, бентежать клієнтів і менеджерів.
Більш того, затримка на цьому етапі має особливо важкі матеріальні та психологічні наслідки. Проект здійснюється за повної
укомплектованості працівниками і максимальних фінансових витратах. Що важливіше, програмне забезпечення повинно забезпечити підтримку іншої ділової активності (поставки комп'ютерів, запуску нових виробничих потужностей і т.п.), і пов'язані із затримкою вторинні витрати дуже високі. На практиці ці вторинні витрати можуть бути вище, ніж всі інші. Тому дуже важливо в первісному графіку робіт відвести достатньо часу для системного тестування.
Боязкість в оцінках
Для програміста, як і для кухаря, тиск з боку господаря може визначати запланований термін завершення завдання, але не може визначати час її фактичного завершення. Омлет, обіцяний через дві хвилини, може успішно смажитися, але якщо через дві хвилини він не готовий, то у клієнта є дві можливості: чекати ще або з'їсти його сирим. Той же вибір встає і перед замовником програмного забезпечення.
У кухаря є ще одна можливість: додати жару. В результаті омлет часто виявляється безнадійно зіпсованим: горілим з одного краю і сирим - з іншого.
Я не думаю, що у менеджерів програмних продуктів менше хоробрості або твердості, ніж у кухарів або інших менеджерів в інженерних областях. Але липові графіки, націлені на бажану господареві дату, зустрічаються тут значно частіше, ніж в будь-яких інших інженерних областях. Дуже важко, ризикуючи втратити робоче місце, з енергією і люб'язністю відстоювати термін, який визначений без застосування будь-яких кількісних методів при нестачі даних і підкріплений, в основному, інтуїцією менеджера.
Поки методи оцінювання не отримають більш міцної основи, менеджерам залишається тільки мужатися і захищати свої прогнози, стверджуючи, що покладатися на їх слабку інтуїцію все ж краще, ніж грунтуватися на одних бажаннях.
Дії при зриві графіка
Що роблять, коли важливий програмний проект починає відставати від графіка? Природно, додають людей. Як показують малюнки 2.1-2.4, це не завжди допомагає.
Розглянемо приклад. [3] Припустимо, що трудомісткість завдання оцінюється в 12 людино-місяців, і три людини повинні виконати її за 4 місяці, причому в кінці кожного місяця є чотири контрольні точки A, B, C і D, в яких можна зробити виміри (рис. 2.5).
Припустимо тепер, що перша контрольна точка була досягнута лише після закінчення двох місяців. Які альтернативи є у менеджера?
1. Припустимо, що необхідно дотримати термін виконання завдання, і помилково оцінена була тільки перша частина завдання, тобто малюнок 2.6 вірно відображає становище. Значить, залишається 9 людино-місяців трудовитрат і два місяці, тому знадобиться 4Ѕ людини, і до трьом наявним потрібно додати ще двох.
2. Припустимо, що необхідно дотримати термін виконання завдання, і однаково занижена була вся оцінка. тобто становище відповідає малюнку 2.7. Значить, залишається 18 людино-місяців трудовитрат і два місяці, тому знадобиться 9 осіб. До трьом наявним потрібно додати ще шістьох.
3. Змінити графік. Мені подобається зауваження, зроблене П. Фагген (P. Fagg), досвідченим інженером з обчислювальної техніки: «Маленьких затримок не буває». Це означає, що в новому графіку повинно бути достатньо часу, щоб робота була виконана ретельно і повністю, і не довелося б знову переробляти графік.
4. Скоротити завдання. На практиці цим завжди і закінчується, коли команда виявляє, що не вкладається в графік. Коли дуже високі вторинні витрати, це єдине, що можна зробити. Менеджеру надається можливість офіційно і акуратно скоротити завдання, змінити графік, або спостерігати, як завдання мовчки урізається при поспішному зміні проекту і неповному тестуванні.
У перших двох випадках наполягати на тому, щоб завдання в незмінному вигляді була виконана за чотири місяці, загрожує катастрофою. Розглянемо, наприклад, відновлювальний ефект першої альтернативи (рис. 2.8). Двоє нових працівників, якими б обізнаними вони не були, і як би швидко не вдалося їх знайти, повинні вивчити завдання за допомогою одного з досвідчених розробників. Якщо для цього буде потрібно місяць, то 3 людино-місяці будуть витрачені на роботу, яка не враховується в вихідної оцінці. Крім того, завдання, розбита спочатку на три потоки, повинна бути тепер перекроєна на п'ять частин. Тому частина вже зробленої роботи буде втрачена, а системне тестування потрібно буде продовжити. В результаті в кінці третього місяця залишиться роботи істотно більше, ніж на 7 людино-місяців, а в розпорядженні буде 5 підготовлених людей і один місяць. Згідно малюнку 2.8 продукт буде запізнюватися так само, як якщо б жодної людини не було додано (див. Рис. 2.6).
Якщо розраховувати впоратися за чотири місяці з урахуванням тільки часу навчання, але не перерозподілу завдань і додаткового системного тестування, то в кінці другого місяця потрібно додати 4, а не 2 людини. Щоб компенсувати вплив перерозподілу завдань і системного тестування, будуть потрібні ще нові люди. Тепер, однак, команда складається не з 3, а, по крайней мере, 7 осіб, і такі питання, як організація команди і розподіл завдань набувають новий якісний рівень.
Вкрай спрощуючи, сформулюємо Закон Брукса:
Якщо проект не вкладається в терміни, то додавання робочої сили затримає його ще більше.
Це розвінчує міф про людино-місяці. Тривалість здійснення проекту залежить від обмежень, що накладаються послідовністю робіт. Максимальна кількість розробників залежить від числа незалежних підзадач. Ці дві величини дозволяють отримати графік робіт, в якому буде менше зайнятих розробників і більше місяців. (Єдина небезпека полягає в можливому устаревании продукту.) Не можна, однак, скласти працюють графіки, в яких зайнято більше людей і потрібно менше часу. Програмні проекти частіше провалюються через брак календарного часу, ніж по всіх інших причин разом узятим.