З чого складається складність
«Міфічний людино-місяць» був написаний тоді, коли людство не мріяло про персональний комп’ютер у кожному будинку. Книжка наблизила цю можливість. З 1960–1970-х невиразні айфони та бездротовий зв’язок, проте принципи управління складними проектами, які сформулював у ті роки молодий вчений Фредерік Брукс, який працював тоді в передовій сфері кібернетики — створення OS/360 в IBM, — можуть бути корисними й донині. . Ми підготували саммарі цієї чудової книги із коментарями керівника розробки Smart Reading В’ячеслава Нікуліна.
У 1960-1970-ті роки не існувало різноманітного готового інструментарію віддаленої комунікації, спільної роботи над макетами та документацією, систем ведення та контролю поставлених завдань та використаних ресурсів. Хоча зараз усі ці технології активно використовуються, процес розробки та проектування програмного забезпечення лише ускладнюється. ПЗ розробляється для багатьох прикладних сфер життя, різні програми автоматизовано взаємодіють один з одним, помилки в оцінці трудовитрат на розробки таких систем мають те ж саме, що й 40 років тому.
Програма і програмний продукт — не те саме. Програмний продукт відрізняється від програми:
- максимально узагальненим діапазоном та видом вхідних даних;
- ретельним тестуванням, яке є окремим складним завданням;
- детальною документацією.
Створення програмного продукту потребує втричі більше часу, ніж програма. При цьому програмне забезпечення (ПЗ) – одне з найскладніших творінь людини, і з цією складністю нелегко впоратися. Потужним стимулом підвищення продуктивності ПЗ було широке використання мов високого рівня (дослідники приписують цьому чиннику п’ятикратне зростання продуктивності ПЗ).
Свою роль відіграли й уніфіковані середовища програмування. І все-таки ПЗ можна спрощувати лише до певної межі, яку ставлять чотири умови:
1) складність (велика кількість програмних конфігурацій ускладнює їх опис та тестування);
2) підпорядкованість формі (інтерфейси створюваного ПЗ повинні підпорядковуватися різноманіттю людських інститутів та систем, для яких і створюються);
3) мінливість (ПО функціонально, а функціональність – те, що найбільшою мірою схильне до змін у зв’язку з швидко мінливою реальністю);
4) невидимість (реальність ПЗ не вбудована у простір, її важко уявити тому сенсі, у якому, припустимо, Земля відбито на географічних картах, візуалізувати ПЗ без принципового спрощення важко).
Об’єктивні проблеми, проте, можна мінімізувати, якщо організувати створення ПЗ грамотно. Справа не в тому, як працюють комп’ютери, а в людях.
Як організувати колектив
Викриття людино-години
Головна причина, через яку провалилася більшість програмних проектів, — брак часу.
- Програмістів губить оптимізм: оскільки їхній продукт створюється не з глини чи фарб, але з чистих уявних абстракцій, вони часто впевнені, що в реалізації проекту не буде великих труднощів. Тим часом самі ідеї бувають помилковими, а це спричиняє помилки у програмах.
- Ми плутаємо докладені зусилля та рух уперед. Хід виконання роботи не залежить від людино-годин, люди та час не взаємозамінні.
Люди та місяці взаємозамінні лише тоді, коли не потрібно вибудовувати комунікацію між співробітниками. Збір бавовни? Ідея людино-годинник працює. Створення ПЗ? Ідея людино-годин провалюється, тому що різні етапи цієї роботи взаємозалежні і програмісти повинні витрачати час на взаємодію один з одним. Часу на налагодження комунікації завжди йде більше, ніж зусилля зі скорочення часу виконання окремих етапів роботи. Тому привнесення до проекту нових сил на пізніх стадіях розробки лише відсуває термін здачі проекту (закон Брукса) .
Брукс вивів правило визначення графіка робіт зі складання ПЗ.
Тут збільшена частка планування і значно збільшено час на налагодження коду — тому що саме в цій галузі програмісти не чекають великих труднощів, а вони трапляються повсюдно .
Через 20 років, у редакції 1995 року, Брукс вказав на вразливе місце у цій схемі: якщо вона реалізується лінійно, накопичення помилок неминуче та зі збільшеним на налагодження коду часом. У виданні 1975 Брукс наполягав на практиці пілотної системи, яку програмісти повинні створити перед тим, як розроблять остаточну модель. Пілот виявить помилки в проектуванні, а потім повністю відредагований. За 20 років підхід до створення програм змінився, і 1995-го Брукс визнає: принцип «Плануй викинути!» не працює. Він вказує на переваги інкрементної моделі — поетапної стратегії, коли різні частини системи розробляються в різний час та різними темпами, а якщо одна частина готова, її одразу інтегрують у систему. Але його базовий принцип залишився незмінним: додати робочу силу у проект, що відстає за графіком, — остаточно загальмувати процес.
Концептуальна цілісність
Концептуальна цілісність – ключова умова проекту. Згадаймо середньовічні собори Європи, які будувалися десятиліттями, але зберегли стилістичну єдність. До цього повинні прагнути розробники ПЗ. Відмінний приклад концептуальної цілісності – інтерфейс WIMP (windows, icons, menus, pointers – вікна, значки, меню, покажчики), нині відомий кожному користувачеві.
Концептуальна цілісність вимагає, щоб проект виходив від одного розробника (або кількох осіб, які діють в унісон). Цей розробник називається головним архітектором проекту. Діючи виключно на користь користувача, він вирішує, що має входити в програмний продукт, а що ні (це бачення втілено в довідковому керівництві проекту, про який нижче).
Зазвичай структуру організації представляють деревоподібної, що відбиває загальний принцип ієрархічного підпорядкування. Насправді вона радше схожа на мережу, що має безліч організаційних груп, комітетів.
Кожен підпроект такої мережі містить дві лідерські ролі: роль продюсера (він збирає команду, розподіляє роботу, визначає графік, шукає ресурси) та роль технічного директора або архітектора (він продумує дизайн і відповідає за концепцію). Іноді, особливо в малих командах, продюсер і директор можуть бути однією людиною. Однак у великому проекті кожна з ролей вимагає повного робочого дня, і в цьому випадку ролі краще розділити: продюсер може бути головою групи, а директор його правою рукою, і навпаки .
Архітектори та розробники
Задля більшої концептуальної цілісності системи важливо відокремити архітектуру від. Архітектура проекту визначає, що зроблено, реалізація як зроблено.
Простий приклад – годинник. Їхня архітектура складається з циферблату та стрілок. Ті, хто засвоїв цю архітектуру, ніколи не вчиться визначати час. Реалізація ж відповідає за роботу механізмів у корпусі. Від реалізаторів залежить співвідношення вартості до продуктивності товару.
Архітектори є аристократією проектів, але це не означає, що вони обмежують творчі можливості розробників. Ті можуть розпочати роботу, як тільки у них з’являються більш-менш чітке розуміння довідкового керівництва та критерії щодо вартості та продуктивності. Розробники можуть зайнятися дизайном потоків даних, концепцій упаковки та ін. Часто процеси створення архітектури, програмна та апаратна реалізація проходять паралельно, як і дизайн апаратного та програмного забезпечення.
У зв’язку з цим одне з найперспективніших технологічних рішень — розробка підходів та інструментів для швидкого прототипування систем як частини процесу розробки специфікацій. Прототипи симулюють задуманий програмний продукт, дозволяючи оглянути задану концептуальну структуру, перевірити її на зручність та несуперечність.
Архітектор проекту – аристократ, але не диктатор. Він має бути готовий як запропонувати спосіб реалізації своїх ідей, а й прийняти будь-який інший настільки ж хороший спосіб.
Хірургічна команда
Було б спокусливо залучити до створення проекту нечисленну команду першокласних геніїв, а не керувати сотнею-другою людиною. Спокусливо – і нереалістично. Але Брукс пропонує вихід: кожен сегмент великої роботи має виконуватися командою, організованою за принципом хірургічної бригади. Замість того, щоб кожен орудував скальпелем, потрібно дати ключовий інструмент в руки однієї людини, а решту йому асистуватимуть. Ролі розподілені так:
- «хірург» – головний програміст, який задає специфікації з функціоналу та продуктивності проекту, ключовий розробник дизайну, що безпосередньо працює з найбільш критичними частинами; «хірурги» — програмісти з найкращих, такі працюють у 5–10 разів швидше за інших;
- «асистуючий хірург» — менш досвідчений, але здатний виконати будь-яку частину роботи, що представляє команду в обговореннях проекту з іншими командами, який досконало знає весь код (він може навіть писати код, але при цьому не несе за нього відповідальність повною мірою);
- адміністратор , що розбирається з персоналом, робочим простором та ін;
- редактор – переробляє та править всю документацію, підготовлену «хірургом»;
- два секретарі – для адміністратора та редактора;
- діловод – відповідає за реєстрацію всіх технічних даних команди в бібліотеці програмного продукту;
- інструментальщик , що створює спеціалізовані утиліти, каталогізовані процедури, бібліотеки макросів, відповідальний за доступ до основних інтерактивних служб;
- тестувальник , що відповідає за банк тестових випадків, тестування роботи в процесі та на її фінальному етапі, що займається плануванням послідовності тестування;
- консультант у галузі мов програмування.
Ці 10 людина виконують суворо спеціалізовані ролі, що полегшує комунікацію з-поміж них і у результаті сприяє концептуальної цілісності роботи. Навіть якщо до проекту залучено 200 осіб, керівництву потрібно координувати лише 20 хірургів.
В ідеалі менеджери та технічні працівники повинні бути взаємозамінними настільки, наскільки дозволяють їх таланти та знання, а начальник повинен мати можливість легко переміщати співробітників між управлінськими та технічними ролями (без втрати престижу та окладу).
Довести до відома
Робота над проектом не повинна повторювати долю Вавилонської вежі. Як відомо, причиною її катастрофи є відсутність комунікації і, як наслідок, відсутність координації. Так і будь-який великий проект зазнає краху тому, що ліва рука не знає про дії правої і співробітники все більше розходяться один з одним у припущеннях. Команди повинні обмінюватися один з одним інформацією якомога різноманітнішими способами: і неофіційно, і на нарадах, і через робочу книгу проекту.
Довідковий посібник. В основі будь-якого проекту лежить довідкове керівництво, яке несуперечливо і ясно описує специфікацію продукту — кожну деталь того, з чим має справу користувач. Підготовка такого посібника проходить поетапно, у міру того як зворотний зв’язок від користувачів та розробників виявляє недоліки проекту. При цьому потрібно і формальне визначення дизайну (для точності), і неформальне, написане звичайною англійською (російською та ін.) мовою (для зрозумілості). Один із цих описів має бути стандартним, інший — похідним (так, мова програмування Algol 68 мала формальне визначення як стандартне і текстове — як похідне).
Поточні уточнення фіксуються на щотижневій конференції всіх архітекторів та офіційних представників розробників апаратного та програмного забезпечення. Цю зустріч веде головний архітектор. Пропозиції для обговорення поширюються серед учасників до наради, на якій присутні винаходять шляхи вирішення. Кожна пропозиція, перш ніж перетворитися на рішення, розглядається розробниками, чітко окреслюються його плюси та мінуси. Якщо досягти консенсусу не вдається, рішення приймає головний архітектор. Рішення передаються одному або декільком архітекторам для деталізації точно сформульовані пропозиції щодо зміни довідкового керівництва.
Згодом одні рішення не виправдовують себе, з іншими виникають непередбачені складності. Накопичені дрібні апеляції пропонується розглядати на щорічних «засіданнях суду» , які тривають зазвичай два тижні (можна проводити їх двічі на рік). Вони проводяться безпосередньо перед вирішальними датами заморозки довідкового керівництва, у них беруть участь як архітектори і розробники, а й менеджери з програмування, маркетингу. Головує менеджер проекту. У ході підготовки проекту System/360 на порядку денному знаходилося зазвичай по 200 пунктів. Заслуховували всі сторони та приймали рішення. Вранці кожен учасник виявляв на своєму робочому місці виправлене керівництво, до якого було внесено рішення, ухвалені напередодні.
У ході роботи у розробників виникає безліч питань щодо архітектури незалежно від того, наскільки точна специфікація. У такий момент кожен співробітник повинен мати можливість (і бажання) одразу зв’язатися з відповідальним архітектором, а не відкладати проблему у довгий ящик. Архітектор повинен вести спеціальний журнал, у якому фіксується кожне запитання та відповідь. Щотижня журнали кількох архітекторів об’єднуються та поширюються серед користувачів та розробників.
Ще одна гарантія надійної роботи проекту – група з тестування продукту та обов’язковий зовнішній аудит. Вона перевіряє машини та програми відповідно до специфікацій та виявляє всі можливі невідповідності. Кожен колектив потребує такого «адвокату диявола».
Робоча книга проекту. Робоча книга проекту – не документ, а структура, яка накладається на всю документацію проекту : цільові критерії, зовнішні специфікації, технічні стандарти, адміністративні меморандуми.
- Ця структура планується ретельно та завчасно.
- Своєчасне оновлення робочої книжки має важливе значення.
- Для співробітника, який знайомиться зі змістом робочої книги, важливо, щоб зміни, внесені до документа з моменту, коли він читав її востаннє, були явно виділені та була відзначена їхня значимість.
- Важливим є оперативне зведення змін у режимі «останні зміни видно насамперед».
- Частини робочої книги мають бути організовані так, щоб кожен співробітник міг бачити лише свою частину роботи.
Брукс всіляко переконує менеджерів не відливати від роботи з документами, хоч би нудною, а часом надмірною вона не здавалася. Насправді невелика кількість документів зосереджує критично важливу частину роботи. Регулярна фіксація ідей породжує чітку логіку рішень, роблячи їх явними всім, усуваючи можливі протиріччя. Необхідний комплект формальних документів кожного відділу має бути оформлений на самому початку роботи — ця інформація визначатиме напрямок процесу, кристалізуватиме обговорення проекту, забезпечить механізм спостереження за станом справ та попередження збоїв, послужить і контрольним списком, і базою даних.
Для проекту створення програмного забезпечення потрібні цільові критерії, довідкове керівництво користувача, внутрішня документація, графік, бюджет, організаційна схема, розподіл площ. Проект розробки комп’ютера може відрізнятися, але так чи інакше вся документація зводиться до базових питань: що? коли? скільки? де? і хто?
Відставання від графіка
Як виходить, що проект спізнюється цілих півроку? Все почалося з того, що колись проект запізнився лише на день, і цього ніхто не помітив.
Щоб уникнути такої проблеми, слід планувати графік, що складається з дат контрольних точок — конкретних, легковимірних подій. Чим вони чіткіші, тим важче їх пропустити .
Керівнику, що контролює графік робіт, знадобиться два види даних:
1) інформація про зриви термінів, що потребує безпосереднього втручання;
2) загальна картина справ – для обізнаності.
Босу важливо не плутати один тип інформації з іншим і не робити активних дій з проблем, які можуть бути вирішені його менеджерами в поточному порядку. Менеджери при цьому не повинні бути залякані постійним режимом готовності до авралу: начальнику варто частіше підкреслювати, що всі наради, звіти та конференції насамперед мають на меті вивчення поточних справ, а не пошук неявних недоліків, за яким настане неминуче покарання.
При цьому до графіка робіт варто звертатися регулярно, звіряючись із контрольними точками. Роботу з графіком варто доручити невеликій (до трьох осіб) групі співробітників, яка стане повноважним представником керівництва у колективі. Головне її повноваження — опитувати менеджерів про відповідність робіт прийнятим контрольним точкам та їх можливе перенесення.
Як оптимізувати продукт
Де межі оптимізації?
Скільки займе робота із програмування системи? Вище наводилося загальне співвідношення (1/3 часу – на планування процесу, 1/6 часу – на написання коду, 1/2 – на тестування окремих компонентів і всієї системи), але не можна точно скласти графік проекту, просто помноживши час, витрачений на написання коду, на коефіцієнти інших частин роботи. Варто враховувати, наприклад, що при використанні відповідної мови програмування високого рівня продуктивність розробки може бути збільшена вп’ятеро.
Оцінюючи продуктивність програмістів, дослідники зіткнулися з тим, що на програмування витрачалася лише половина робочого тижня — решту часу з’їдали наради, робота з документацією, дрібні корпоративні справи, хвороби. У великих проектах зустрічається ще одна небезпека: кожен співробітник оптимізує свою роботу для досягнення поточних цілей, у результаті програмісти перетворюються на роз’єднаних конкурентів, які не працюють на одну мету, а заробляють персональні очки. Цілісність проекту губиться, сумарний ефект для клієнта падає. Підтримка загального бачення та орієнтації на користувача має бути першорядним завданням менеджерів із програмування.
Тут особливо важливо пам’ятати про концептуальну цілісність проекту. Всі прагнуть покращувати, не замислюючись про те, до чого це призведе. В результаті на зміну витонченим і простим рішенням приходять явно надмірні, і виникає роздуте програмне забезпечення з масою додаткових функцій, на які йде непропорційно багато ресурсів системи (так званий ефект другої системи ). Брукс зізнається, як і легендарна OS/360 — приклад ефекту другої системи (і Windows NT — вже 1990-ті).
Як уникнути ефекту другої системи?
- Заздалегідь призначити суворі апріорні обмеження для різноманітних функцій системи у байтах та мікросекундах.
- Бути готовим відкинути видатну ідею, якщо та не вписується у встановлений дизайн системи. На першому місці — простота: краще втілити лише частину можливостей системи, ніж переускладнити її, залишивши частину можливостей, що ніким не використовується. Тобто архітектура, що проектується, повинна мати можливість розширення в логічних напрямках, але не повинна включати додатковий функціонал, який може і не знадобитися.
Ще один тонкий момент – супровід програмного забезпечення. Воно складається з виправлення помилок, які були виявлені користувачами, та обліку їхніх побажань, які виникли внаслідок роботи із ще незакінченою системою. Бажання клієнта — закон, але його слід враховувати до певного моменту, інакше робота над системою просто не буде закінчена.
Крім того, виправлення помилки має суттєвий (до 50%!) шанс внесення нової помилки. Проектувальники системи повинні обговорити момент, після якого специфікації заморожуються і всі побажання клієнта відкладаються до роботи над наступною версією.
Максимально ретельне визначення функцій та усунення функціональних надлишків зменшать кількість системних помилок, які виявляться під час тестування системи.
Оптимізація робочих інструментів
Робота над великим проектом має бути максимально оптимізована: всі необхідні інструменти повинні завжди бути під рукою.
- Кожному проекту потрібна база даних повна стандартних компонентів: хороших підпрограм або макросів для організації черг, пошуку, хешування, сортування.
- У кожній групі розробників має бути один програміст, відповідальний за написання утиліт для своєї групи. Повинна бути і група, яка створює утиліти для всіх, хто працює над певною системою.
- Для зниження вартості розробки керівники проекту можуть купити частину програмного забезпечення в інших розробників, не витрачаючи час та гроші на «винахід велосипеда».
Інші принципи оптимізації були півстоліття тому, коли Брукс та його колеги розробляли IBM System/360.
- Важливу роль оптимізації IBM System/360 відіграв логічний емулятор — придуманий IBM метод запуску програм, розроблених для старих пристроїв, на нових моделях (сьогодні, наприклад, емулятори дозволяють запускати Windows на комп’ютері Mac і навпаки). Замість розробки нових додатків для нових комп’ютерів така сумісність дала розробникам велику гнучкість у вирішенні завдань.
- Важливим нововведенням була бібліотека майстер-програм, розділена на кілька систем з різними правилами доступу. Весь протестований (або тестований) код зберігався в цій бібліотеці. Кожна робоча група мала свій майданчик, де співробітники зберігали копії своїх програм і тестові випадки. Тут вони мали повну свободу дій. Коли з’являвся налагоджений компонент, готовий для інтеграції у більшу частину, він передавався менеджеру більшого відділу, який поміщав цей компонент у підбібліотеку системної інтеграції, і автор не міг його змінити. У міру того, як система зростала, вона ставала готовою для ширшого використання і перетворювалася на підбібліотеку поточної версії. Формальний поділ та контроль були двома ключовими принципами, які успішно координували всю роботу. Актуальні вони й сьогодні.
- Найважливішими для системного програмування виявилися інструменти, які майже не використовувалися в розробці OS/360. Це мови високого рівня, що дозволяють описувати дані набагато коротше, ніж за допомогою машинного коду, та інтерактивне програмування (дозволяючи вносити зміни до коду, коли програма вже запущена, воно щонайменше подвоює продуктивність системного програмування).
Як уникнути дефектів
Задовго до того, як з’явиться код, специфікація має бути передана групі зовнішнього тестування для ретельного вивчення щодо ясності і повноти.
Кращою формалізацією програмування Брукс вважає низхідний дизайн Вірта, заснований на покроковому уточненні запланованої роботи : створюється грубий малюнок, що відбиває важливий результат, потім кожен пункт плану розбивається на конкретні кроки і кожне уточнення у визначенні завдання вноситься до алгоритму рішення та спосіб представлення даних. У процесі виявляються модулі даних, подальша робота з яких може проходити незалежно від цього, що сприяє гнучкості всього процесу. Помітивши помилку, розробники завжди можуть повернутися назад — низхідний дизайн позбавляє необхідності спішного «пришивання латок» у проблемних місцях проекту. Низхідний дизайн відбиває загальні принципи структурного програмування. Воно надзвичайно спрощує процес створення ПЗ, зводячи роботу над програмою до елементарних конструкцій (лінійна, циклічна, альтернативна). Програми стають менш складними та наочнішими.
Це, проте, не дозволяє нехтувати ретельністю налагодження системи. Вона, на відміну від налагодження компонентів, завжди займає більше часу, ніж очікується.
- Налагодження системи слід розпочинати лише після того, як співробітники переконалися, що всі частини системи працюють (на відміну від підходу «прикрутити всі разом і спробувати, чи спрацює»).
- Під час налагодження системи слід додавати по одному компоненту за раз — часто програмісти нехтують цим трудомістким методом, але чим послідовнішим є процес, тим менше помилок уникне уваги фахівців.
- Налагоджувальні «будівельні ліси» (перевірочний код) можуть займати до 50% продукту, що налагоджується, але воно того варте.
- Усі поточні зміни ретельно документуються. Важливо мати повні тестові випадки, тестуючи системи після додавання кожної нової частини.
Документація для користувача
Документація, що складається для користувача, не менш важлива, ніж програмний код машини. Вона відбиває те цілісне бачення товару, що було визначено основним архітектором. Для підтримки документації в актуальному стані важливо, щоб вона вбудовувалась у вихідну програму, а не зберігалася у вигляді окремого документа.
Структурний граф найвищого рівня може безпечно зберігатися як окремий документ (оскільки не схильний до частих змін), але може бути і вбудований у вихідну програму як коментар.
Часто документація для користувача страждає на зайву деталізацію та відсутність загального огляду. Складаючи її, слід йти від загального до приватного: від призначення програми (яка її головна функція) та середовища її застосування (на яких машинах, з якими конфігураціями апаратного забезпечення та операційних систем вона працюватиме) до реалізованих функцій (що саме вміє програма) та операційним інструкціям (включаючи поведінку за нештатних ситуацій).
Програма повинна постачатися з кількома тестовими випадками: частина з них – для допустимих вхідних даних, частина – для граничних вхідних даних та частина для явно неприпустимих вхідних даних. У документації, призначеної для модифікаторів програми, важливо прописувати не лише як працює програма, а й чому вона так працює.
Така документація містить п’ять пунктів:
1. Блок-схема чи граф структури підпрограми.
2. Повні описи використовуваних алгоритмів чи посилання такі описи.
3. Пояснення загальної схеми всіх файлів.
4. Огляд організації проходження даних – послідовності, в якій дані завантажуються, та опис того, що відбувається на кожному етапі.
5. Обговорення модифікацій, передбачених в оригінальному дизайні, та того, які модифікації можуть бути бажаними.
Небагато програм потребують більш ніж односторінкової блок-схеми. Блок-схеми алгоритмів надто переоцінені та неактуальні у зв’язку з розвитком мов високого рівня.
Скоротити зусилля щодо документування програми можна:
- більше використовуючи для документування обов’язкові частини програми (символічні імена та оператори оголошення);
- максимально використовуючи простір та формат для показу підпорядкованості та вкладеності (це полегшує читання документації).
Напуття крізь десятиліття
Ця книга почалася з тези про те, що головне у програмуванні — не машини, а люди . Брукс пише, що програмування – це творчість, як створення картин чи симфоній. У цій сфері є свої генії, і їх пошуку потрібно приділити найпильнішу увагу :
- систематично виявляючи найкращих розробників якомога раніше (пам’ятаючи при цьому, що найкращі — не завжди досвідчені);
- призначаючи наставників, які відповідатимуть за систематичну підготовку перспективних працівників (до неї входять ретельно підібрані стажування, курси тощо);
- забезпечуючи можливості максимальної взаємодії перспективних розробників.
На щастя, появі геніїв сприяє саме середовище, що принципово змінилося за останні десятиліття. Розробники 1970-х чекали від вчених таких інструментів, які були б:
- дешевими настільки, що до них могла б звертатися практично будь-яка людина;
- відповідними нашим творчим потребам.
І що ж? Саме це ми бачимо сьогодні, коли смартфон у кишені найпотужніший обчислювальний центр, що відправив перших людей на Місяць. Програмування, як і раніше, залишається одним із найскладніших інтелектуальних занять, але й людський геній не стоїть на місці. У цьому може переконатися кожен, звернувши увагу на гаджет, з якого читає цей текст.
10 найкращих думок
1. Час роботи над проектом не обернено пропорційно числу програмістів : час і зусилля витрачаються на координацію роботи та взаємодію співробітників.
2. Якщо проект не укладається у строки, то додавання робочої сили затримає його ще більше (закон Брукса).
3. У групі розробників має бути один найкращий програміст, який відповідає за головні рішення, та кілька інших, які допомагають йому. За таким принципом працюють хірургічні бригади.
4. Концептуальна цілісність – мета будь-якого проекту. Для цього архітектура проекту має бути відокремлена від його реалізації. Останнє слово – за головним архітектором.
5. Простота не менш важлива, ніж концептуальна цілісність. Слід уникати прагнення додавати до системи всі можливі можливості.
6. Кожен менеджер проекту повинен скласти набір формальних документів, що описують цілі, терміни, вартість та виконавців проекту. Ці документи стають частиною робочої книги – структури, яка визначає весь документообіг проекту. Завдяки цьому кожна група розробників має чіткий набір вимог щодо своєї частини системи.
7. Запізнення проекту на місяці починається із відставання на один день. Не допустити цього допоможе графік, що складається з дат контрольних точок – конкретних, легковимірних подій. Зазвичай, такий графік детально складається на найближчі 3–5 тижнів.
8. Групи розробників повинні взаємодіяти один з одним усіма доступними способами. Ніколи не слід нехтувати можливістю перепитати.
9. Робота з інструментами має бути максимально оптимізована. Купуйте частину програмного забезпечення в інших розробників. Призначте програміста, відповідального за написання утиліт своєї групи. Призначте групу, яка створює утиліти для всіх, хто працює над цією системою.
10. Побажання користувача слід враховувати лише до певного моменту, інакше робота над системою ніколи не буде закінчена.
Роль продюсера зараз називається teamlead.
Роль технічного директора на дрібному проекті виконує techlead.
Підхід почасти застарів. Найсучасніший підхід — група так званих Т-фахівців, максимально взаємозамінних співробітників, у якій кожен знає якусь частину функціоналу дуже добре, але може робити й інше.
Сучасні офісні календарі, пошта та месенджери зазвичай покривають усі потреби.
Сьогодні ця проблема зазвичай вирішується за допомогою Google-пошуку.
Комунікація команд і сьогодні є великою проблемою, особливо у великих організаціях, де в різних проектах часто вирішується синхронно одне й те саме завдання. І, зазвичай, кожен підрозділ знаходить власне рішення, що викликає подальші труднощі з уніфікацією.
Нині розробка значно прискорилася проти реаліями, описаними у книзі.
Сьогодні, згідно з методикою agile, прийнято вважати, що хороша комунікація важливіша за документацію (хоча і документація важлива).
Ефект другої системи — сьогодні ця проблема навіть посилилася, оскільки розробка постійно прискорюється і досвідчені розробники намагаються передбачити надто багато моментів на майбутнє, не усвідомлено ігноруючи ТЗ.
Зараз усе це зберігається у загальних репозиторіях у Мережі.
Для великих проектів це справедливо, але для більшості таких завдань зараз існують готові послуги, оренда яких коштує $5–10 на місяць.
Сьогодні є дуже функціональні інструменти покрокового виконання програми. Це полегшує пошук помилок.
Налагоджувальні «будівельні ліси» нині називають автотестами.
За час, що минув з моменту написання книги, вже настала епоха добрих, стандартних фахівців. Геніями дуже складно керувати, вони часто раптово залишають проект. Хоча, щодо пошуку та розвитку фахівців, поради Брукса цілком працюють і зараз.