«Міфі́чний люди́но-мі́сяць або Як ство́рюють програ́мні систе́ми» (англ. The Mythical Man-Month) — книга Фредеріка Брукса про управління проєктами в області розробки програмного забезпечення. Центральною темою книги стало те, що привнесення в проєкт нових сил на пізніх стадіях розробки лише відсуває термін здачі проєкту. Ця ідея стала відома під назвою «закон Брукса». Книга була вперше опублікована 1975 року. Вдруге книга вийшла у вигляді ювілейного видання в 1995-ому, разом з коментарями автора та новим есе «Срібної кулі немає».
| | |
| Автор | Фредерік Брукс |
|---|---|
| Назва мовою оригіналу | The Mythical Man-Month |
| Мова | англійська |
| Тема | розробка програмного забезпечення |
| Жанр | есей |
| Видавництво | Addison–Wesley |
| Видано | 1975, 1995 |
| ISBN | 0-201-00650-2 (1975), 0-201-83595-9 (1995) |
| Наступний твір | Срібної кулі немає |
Спостереження Брукса спираються на його досвід роботи в IBM, який він отримав під час керування проєктом зі створення операційної системи OS/360. Для прискорення розробки він спробував залучити більше число працівників до проєкту, терміни по якому вже були зірвані. Ця спроба виявилась невдалою. Також Брукс помилився, зробивши припущення, що написання компілятора мови ALGOL потребуватиме шести місяців — незалежно від кількості людей, залучених до проєкту (насправді це зайняло більше часу).
Помітивши схильність менеджерів повторювати такі помилки, Брукс глузливо називав свою книгу «біблією для програмної інженерії»: «всі її цитують, дехто її читав, але одиниці живуть по ній!» Книга вважається класичною по опису людського чинника в програмній інженерії.
Основні ідеї Редагувати
Міфічний людино-місяць Редагувати
Час виконання проєкту не обернено пропорційний числу програмістів, принаймні з двох причин.
- У програмуванні, на відміну від, наприклад, збирання бавовни, робота не може бути довільно розділена на кілька незалежних частин. Частини проєкту залежать одна від одної, і деякі завдання можна починати виконувати лише після того, як будуть закінчені інші.
- Програмісти повинні витрачати частину часу на взаємодію один з одним.
Якщо є N програмістів, то кількість пар програмістів N(N-1)/2, тобто зі зростанням числа програмістів витрати часу на взаємодію ростуть квадратично. Тому починаючи з якогось N, зростання числа програмістів уповільнює виконання проєкту.
Якщо терміни закінчення проєкту зірвані, наймання нових програмістів уповільнює виконання проєкту і з іншої причини: новачкам потрібен час на навчання. У книзі сформульовано Закон Брукса:
Якщо проєкт не вкладається в терміни, то додавання робочої сили затримає його ще більше.
Якщо програмістів занадто багато, проєкт може бути взагалі ніколи не закінчений: через загальну плутанину, спроби виправити вади породжують нові, так що система не поліпшується.
Програма та програмний продукт Редагувати
Програмний продукт відрізняється від програми:
- максимально узагальненим діапазоном та видом вхідних даних;
- ретельним тестуванням, що є несподівано складним етапом;
- наявністю докладної документації.
Програмний продукт вимагає втричі більше витрат часу, ніж програма.
Ефект другої системи Редагувати
Програміст, який розробляє свою другу систему, схильний додавати всі ті можливості, які він не зміг додати в свою першу систему (через брак часу). Тому друга система часто виявляється перевантаженою можливостями.
Концептуальна цілісність Редагувати
Для забезпечення концептуальної цілісності системи необхідно відокремити архітектуру від реалізації. Один головний архітектор (або невелика група), вирішують, що повинно входити в систему, а що не повинно. «Дуже крута» ідея може бути знехтувана, якщо пропоновану можливість важко вписати в загальний дизайн системи. Простота дуже важлива; може бути корисним реалізувати лише частину можливостей, на які здатна система, оскільки якщо система занадто складна, частина її можливостей будуть залишатися невикористаними.
Головний архітектор повинен сформулювати свої рішення у вигляді керівництва для користувача.
Формальні документи Редагувати
Кожний менеджер проєкту повинен скласти невеликий набір формальних документів, що описують цілі проєкту, як, хто і коли буде їх реалізовувати, і скільки вони будуть коштувати. Ці документи можуть розкрити невідповідності, які інакше було б важко помітити.
Кожна група розробників отримує набір вимог до своєї частини системи, включаючи точний опис її функціональності та граничні вимоги до процесорного часу, пам'яті, місця на диску і т.д.
Взаємодія Редагувати
Щоб запобігти катастрофі, групи розробників повинні взаємодіяти одна з одною всіма можливими способами. Замість того щоб робити припущення з приводу функції, що він її реалізовує, розробник повинен ставити архітекторові запитання, оскільки припущення можуть виявитися геть невірними.
Пілотна система Редагувати
Перед тим як розробляти остаточну систему, необхідно розробити пілотну систему. Пілотна система виявить помилки в проєктуванні, після чого вона повинна бути повністю перероблена.
Хірургічні групи Редагувати
Розумно, якщо в групі розробників є один "гарний" програміст, який реалізовує найкритичніші частини системи, і кілька інших, що допомагають йому або реалізовують менш критичні частини. До речі так проводять хірургічні операції. Крім того, на думку Брукса, найкращі програмісти працюють в 5-10 раз швидше за інших.
Спеціалізовані утиліти Редагувати
Замість того, щоб кожний програміст писав власні утиліти, в кожній групі розробників повинен бути один програміст, відповідальний за написання утиліт для своєї групи (наприклад, генератор коду, що створює код згідно з якимись специфікаціями). Повинна бути також група, яка створює утиліти для всіх програмістів, що працюють над системою.
Версії та заморожування системи Редагувати
Під час створення системи, вимоги користувача до неї можуть змінюватись під впливом його досвіду роботи з незакінченою системою. Ці побажання користувача слід враховувати, але лише до певного моменту, інакше робота над системою ніколи не буде закінчена. Після цього специфікації заморожуються, і всі такі вимоги змін відкладаються до початку роботи над наступною версією.
Зниження вартості розробки Редагувати
Брукс пропонує 2 способи знизити вартість розробки програмного забезпечення:
- Найняти програмістів лише після того, як побудована архітектура системи. Інакше якщо ця стадія буде тривалою, наприклад розтягнеться в кілька місяців, програмістам буде нічого робити.
- Придбати частину програмного забезпечення у інших розробників.
Примітки Редагувати
Посилання Редагувати
- Сайт Фредеріка Брукса [ 24 грудня 2006 у Wayback Machine.]