Книгата „Митскиот човек-месец“ зборува за аспекти на софтверското инжнерство и упраување и раководење на проекти, но тоа што ја издвојува од сите останати, е што во неа технологијата е секундарна, наспроти човечките аспекти кои се во прв план. Во индустрија во која повеќето од книгите се бескорисни по неколку години или по неколку месеци, оваа книга може да се смета дека е праисториска. Првото издание е издадено во 1975 година, а овој приказ се однесува на нејзиното јубилејно 20-годишно реиздание, што само потврдува за вредноста која ја поседува.

Основната идеја во книгата е дека „додавањето повеќе луѓе во софтверски проект само повеќе го задоцнува (проектот)“. Оваа идеја денес е позната и како законот на Брукс (Brooks’ Law) и е еден од многуте цитати од оваа книга кои се водилки за многу менаџери на софтверски проекти. Авторот, книгата ја пишува како збирка од есеи за софтверското инженерство, со посебен аспект на управувањето на софтверски проекти, кои се негово лично искуство од работењето во IBM на оперативниот систем OS/360.

Ако одредена работа може да се заврши од десет луѓе за еден месец, тогаш кажуваме дека за таа работа се потребни десет човек-месеци. Со едноставна аритметика може да се пресмета дека ако алоцираме дваесет луѓе за истата работа, тогаш таа треба да се заврши за половина од времето. Оваа логика има смисла за градежни или некаков друг вид на проекти и како таква е доста позната во економијата. Меѓутоа во светот на софтверскиот дизајн, ова е само една голема заблуда. Ако една програма, еден програмер може да ја напише за два месеци, најверојатно за истата програма на двајца програмери ќе им се потребни три месеци да ја завршат. Уште во далечната 1975 година, кога софтверското инженерство било многу млада професија, авторот многу вешто увидел дека концептот за човек- месец не е ништо друго освен уште еден мит.

Проблемот со управувањето на проекти од софтверското инженерство во 70-тите бил што повеќето менаџери се обучувале во областа на економијата, наместо во компјутерската наука и повеќето теории кои тие ги знаеле едноставно не биле применливи на софтверските проекти. Всушност и не постојат еквивалентни теории за софтверски проекти. До ден денес, сè уште не постојат вакви теории и тоа што најголем број на софтверски проекти никогаш не завршуваат на време, е сериозна индикација за овој проблем, заедно со уште многу други на кои авторот се навраќа во оваа негова класика.

Книгата ја сочинуваат деветнаесет дела односно независни есеи. Наместо посебно разработување на есеите, во понатамошниот дел од приказот ќе бидат презентирани основните идеи од оваа книга.

Митскиот човек-месец

Најголем дел од софтверските проекти доцнат. Авторот ова го потенцира како основниот извор на сите проблеми во управувањето со софтверски проекти. Со разоткривање на митот за човек-месец тој се обидува да ги открие вистинските причини за ова. Како прва причина за доцнењето ја посочува неможноста прецизно да се предвиде времето потребно за завршување на проектот. Друга причина која ја посчува е многу слабото надгледување на прогресот на самиот проект (многу е полесно да се види зграда која е издградена до половина, отколку оперативен систем кој е половина готов). Оптимизмот како карактеристика на програмерите е уште еден извор на овој проблем. Компјутерите се доста млади, а исто и програмерите се често млади луѓе. Со младоста доаѓа и голема доза на оптимизам, но во процесот на програмирање во кој веројатноста да се погреши на одредена задача е голема, оптимизмот кога треба да се завршат многу задачи, точно и без грешки се покажува како неоправдан.

Комплексните програмерски проекти не може перфектно да се поделат на дискретни делови на кои може да се работи без комуникација помеѓу работниците и без да се воспостават многу комплексни врски помеѓу задачите и оние кои ги извршуваат. Така, додавањето на повеќе програмери на проект кој доцни ќе предизвика само уште поголемо задоцнување. Ова се случува затоа што ќе се потроши многу време новите програмери да се вклопат и да го научат проектот, а и дополнително ќе се зголеми нивото на комуникацијата помеѓу учесниците која одзема доста време. Околу оваа проблематика авторот прави интересна аналогија со деветте месеци потребни да се носи детето пред да се роди, без разлика колку жени ќе додадете. Кога N луѓе комуницираат помеѓу себе тоа се N * (N – 1) / 2 канали на комуникација, така што на тројца луѓе во проект им се потребни три пати повеќе канали за меѓусебна комуникација во однос на проект од двајца луѓе.

Тим на хирурзи

Во една студија во која се мереле перформансите на група искусни програмери, разликата помеѓу најдобрите и најлошите перформанси само во рамките на оваа група се движеле во сооднос 10:1 во продуктивност. Односно, програмери кои се платени 20000 долари годишно, може да бидат и до десет пати попродуктивни во однос на програмери кои се платени 10000 долари годишно.

Проблемот кој се разработува е како да се создаде тим кој најефикасно и продуктивно ќе работи на голем проект. Притоа од една страна младите менаџари сакаат да управуваат со мали и силни тимови, но од друга страна за навремено завршување на големи проекти потребни се многу повеќе луѓе. Предлогот е тимот да биде органзиран како што се организира тим во хируругијата. Аналогијата е дека на главниот програмер му се доделува улогата на главен хируруг. Останатите членови од тимот се специјалисти во своите области и само му помагаат на главниот програмер. Притоа значително се намалуваат каналите на комуникација, со тоа што главниот програмер комуницира само со одредени членови од тимот, а тие се задолжени за комуникација со останатите. Ваквата организираност предизвикува крајниот продукт да е прозивод на еден до двајца луѓе, што се покажува како добра практика во софтверските проекти.

Концептуален интегритет

Концептуалниот интегритет значи дека системот кој се дизајнира треба да рефлектира една филозофија, а крајниот продукт кој е специфициран од корисникот да се евалуира од неколку умови. Ова се постигнува со јасна поделба на архитектурата од имплементацијата. Еден главен архитект (или мала група на архитекти), работат во име на корисникот и одлучуваат што ќе содржи системот. Тие треба да ја развијат идејата што треба да прави системот и да се обидат да ја пренесат таа визија на остатокот од тимот. Треба да се обидуваат да изградат систем со што е можно помалку функционалности, затоа што ако крајниот продукт е премногу комплексен, корисниците нема да имаат време да ги научат сите негови можности, а со тоа многу од нив ќе останат неискористени.

Ефектот на вториот систем

Ефектот на вториот систем, се однесува на вториот систем кој го дизајнира еден архитект. Според оваа идеја, овој систем е најопасениот кој архитектот воопшто ќе го дизајнира. Ова се случува затоа што тој ќе се обиде да ги вметне сите дополнителни работи кои не успеал да ги додаде (поради временските ограничувања) во првиот систем. Според тоа, секој инженер треба да пристапи разумно кон својот втор систем, со посебно внимание да не го направи премногу комплициран. Од аспект на менаџерот на проектот, ефектот на вториот систем може да се избегне ако се избере архитект на системот кој има работено на повеќе од два системи.

Тенденција кон неможноста да се намали бројот на грешки

По завршување на проектот и негова имплементација кај корисниците, се преминува во фазата на оддржување. Оваа фаза вообичаено може да чини до 40% од вкупната цена на проектот. Ако во хардверски систем одржувањето значи едноставно заменување на расипаниот дел, во софтверските проекти тоа вклучува додавање на нови функционалности и отстранување на неправилности и грешки. Меѓутоа со секоја една поправена грешка, постои значителна шанса од 20-50% да се предизвика нова грешка. Со секој два чекори напред, се враќаме еден наназад. Со оглед на ова авторот прави една интерсна обсервација дека во доволно комплексен систем постои одреден број на грешки кои не може да се намали. Секој обид да се поправат увидените грешки води кон појавување на други нови грешки.

Пишана спецификација - упатство за употреба

Главниот архитект на проектот создава детална пишана спецификација или упатство за употреба за корисниците на системот. Таа треба детално да ги опишува надворешните спецификации на системот, односно сè што гледа корисникот. Оваа спецификација треба постојано да се менува и секогаш да го рефлектира мислењето на тимот за имплементација и на самите корисници. Стилот на пишување треба да е конзистентен и концизен.

Пилот систем

Кога се дизајнира нов вид на систем, тимот ќе дизајнира систем кој ќе се фрли (без разлика дали има таква намера или не). Овој систем е еден вид на „макета“ која ги открива техниките и грешките кои подоцна ќе предизвикаат целосен редизајн. Вториот, понапреден систем, треба да е оној кој ќе му се предаде на корисникот. Имплементирање на пилот системот кај корисниците може да предизвика само агонија кај нив, а може да го наруши и угледот на компанијата.

Формални документи

Секој проект менаџер треба да направи мала збирка на основни формални документи кои ги дефинираат целите на проектот, како ќе се постигнат тие, кој ќе ги имплементира, кога ќе се постигнат и колку ќе чинат. Овие документи може да ги посочат некои од неконзистентностите кои, инаку многу тешко може да се увидат.

Естимација на проект

Ако проценката на времето да се заврши одредена задача е едноставно, истата методологија не може така лесно да се прошири на голем проект составен од многу мали задачи. Кога се прави проценка на времето потребно за изработка на проектот, треба да се запомни дека програмерските продукти (што се продаваат на корисници кои плаќаат) и софтверските системи се најмалку три пати потешки да се напишат, во споредба со интерните програми. Треба да се има на ум колку време во текот на неделата ќе се потроши за конкретни технички проблеми во однос на времето кое ќе се потроши за административни и не- технички задачи, како што се на пример, состаноците.

Комуникација

За да се избегне катастрофа, сите тимови кои работат на проектот треба да останат во контакт помеѓу себе, на што е можно повеќе начини: електорнска пошта, состаноци, потсетници итн. Наместо да се прават претпоставки кој што работи или треба да работи, луѓето од тимот за имплементација треба да ги прашуваат архитектите, кои треба јасно да им ја објаснат целта на она што се обидуваат да го имплементираат. Претставува голем ризик ако продолжат со работа врз основа на некоја сопствена претпоставка, која подоцна може да се покаже целосно неточна. Архитектите се тие кои се задолжени за формирање на групната слика на проектот и комуникацијата со останатите.

Замрзнување на кодот и верзионирање на системот

Софтверот е невидлив и постојано се менува. Така, многу од работите стануваат очигледни кога ќе се сработи одреден дел од системот и ќе им се овозможи на корисниците да го тестираат. Ова искуство ќе вроди со многу вредни информации, кои ќе ги променат барањата на корисниците или нивната перцепција за системот. Притоа, системот треба да се промени за да ги исполни овие. Меѓутоа, ова може да се случува само до одреден момент, инаку системот никогаш нема да биде завршен. После одреден датум, не треба да се прифаќаат повеќе измени и системот и кодот треба да бидат замрзнати. Сите барања за измени треба да се одложат до наредната верзија на системот.

Специјализирани алатки

Добриот мајстор се познава по неговите алатки. Иако малку застарена во однос на начинот на кој се развиваат и користат денешните алатки, идејата која ја презентира авторот е наместо секој програмер да има свои сопствени специјални алатки, секој тим треба да има дизјанирано соодветен креатор кој ќе помага во создавањето на алатките кои се соодветни за работата што ја извршува тој тим.

Намалување на цената на развој на софтвер

Постојат две техники за намалување на цената на развој на софтвер за кои пишува авторот: може да се вработат луѓе за имплементација на проектот откако ќе биде готова архитектурата на системот (чекор кој може да трае неколку месеци, во кои прерано вработените имплементатори нема да имаат никаква работа); другата техника е да не се развива софтвер воопшто, туку едноставно да се купи готов софтвер, секако ако е тоа возможно.

Заклучок

Мал број книги од софтверското инженерство и воопшто од компјутерската наука се влијателни како што е книгата „Митскиот човек-месец“. Најголемата вредност на оваа книга е во нејзината релевантност и значајност, и по триесет години од нејзиното издавање и тоа во област во која на неколку години се создаваат нови и исчезнуваат старите технологии. Причината за ова е што во оваа книга не се зборува за технологија, а само инцидентно за софтвер. Многу повеќе се зборува за тимови од луѓе кои создаваат нешта. Книгата е интересна и вреди да се прочита и од аспект на правото, економијата, психологијата, социологијата и останати науки во кои луѓето, нивната интеракција и организација се во прв план. Или како што самиот автор ја објаснува безвременската димензија на книгата „Човечката историја е драма на сцена која постојано се менува, сценариото на приказните се менува со менувањето на културата, а суштината на приказната секогаш останува иста“.14