Mītiskais cilvēkmēnesis

Mītiskais cilvēkmēnesis: programminženierijas esejas (angļu: The Mythical Man-Month: Essays on Software Engineering) ir Freda Bruksa grāmata par programminženieriju un projektu pārvaldību. Darba galvenā tēma ir, ka "ja programmēšanas projekta beigu posmā piesaista papildu cilvēkus, tas aizkavējas". Tāpat tiek apskatīts otrās sistēmas efekts un aizstāvēta prototipēšana.

Mītiskais cilvēkmēnesis: programminženierijas esejas
Autors	Freds Brukss
Oriģinālais nosaukums	The Mythical Man-Month: Essays on Software Engineering
Valsts	ASV
Valoda	angļu
Žanrs	tehniskā literatūra
Izdevējs	Addison-Wesley
Izdota	1975., 1995.
ISBN	1. izdev. 0-201-00650-2 2. izdev. 0-201-83595-9
OCLC	1201368

Piedāvātās idejas

Mītiskais cilvēkmēnesis

Ja kāda programmatūras projekta izstrāde aizkavējas, tad projekta vadītājam ir vēlme piesaistīt papildu programmētājus, tāpat kā citu nozaru projektos pozitīvu rezultātu panāk, sasummējot cilvēkmēnešus. Brukss secināja, ka programmatūras projektos papildu programmētāju piesaiste projektu pat paildzina, jo pieaug saziņas apjoms dalībnieku starpā. Kad N cilvēki sazinās savā starpā (bez hierarhijas), ja N pieaug, viņu darba rezultāts M samazinās un pat kļūst negatīvs, t.i., kopējais dienas beigās atlikušais darbs ir lielāks nekā kopējais darbs, kas bija palicis dienas sākumā, jo tiek pieļautas kļūdas.

Kopējo sakaru kanālu skaitu grupā var aprēķināt pēc formulas n(n − 1) / 2. Piemēram, ja 50 programmētāji rada 50 · (50 — 1) / 2 = 1225 sakaru kanālu.

Bruks to ilustrē ar piemēru: ja sieviete bērnu var dzemdēt deviņos mēnešos, tad deviņas sievietes to nevarēs izdarīt vienā mēnesī. Tas ir tādēļ, ka grūtniecība norit secīgā procesā, to nevar sadalīt paralēlos procesos. Ja deviņas sievietes kļūs grūtas vienā laikā, tad pēc deviņiem mēnešiem viņas dzemdēs deviņus dažādus zīdaiņus.

Šī ideja zināma kā Bruksa likums.

Otrās sistēmas efekts

Otrā sistēma, kuru arhitekts veido, ir visbīstamākā viņa izstrādātā sistēma, jo viņš tajā cenšas iestrādāt visas tās iespējas, kuras nevarēja realizēt pirmajā sistēmā (laika trūkuma dēļ). Tādējādi sistēma bieži kļūst pārpildīda ar iespējām.

Tendence nesamazināties kļūdu skaitam

Autors ievērojis, ka pietiekami sarežģītā sistēmā kļūdu skaitu neizdodas samazināt. Jebkurš mēģinājums izlabot atklātās kļūdas izraisa jaunu kļūdu ieviešanos.

Konceptuālā viengabalainība

Lai izveidotu lietotājam draudzīgu sistēmu, tai ir jābūt konceptuāli viengabalainai, ko var panākt, atdalot arhitektūru no īstenošanas. Viens galvenais arhitekts (vai neliels skaits arhitektu), kas darbojas lietotāja interesēs, izlemj, ko iekļaut sistēmā un ko atmest. Jauna ideja var tikt noraidīta, ja tā neiekļaujas vienotā sistēmas dizainā. Lai nodrošinātu lietotājam draudzīgu sistēmu, jārealizē tikai dažas no iespējām, kuras iespējamas sistēmā. Ja sistēma ir pārāk sarežģīta lietošanā, daudzas tās iespējas netiek izmantotas, jo lietotājam nav laika apgūt to lietošanu.

Instrukcijas

Arhitektam sistēmas specifikācijas jāraksta instrukciju veidā. Tām detalizēti jāapraksta viss, ko lietotājs redz. Instrukcijas jāmaina, kad no programmētājiem un lietotājiem nāk atpakaļsaite.

Pilotsistēma

Kad tiek projektēja jauna veida sistēma, komandai jāizstrādā ārā izmetama sistēma (vienalga, vai to pēc tam izmetīs vai ne). Šāda sistēma kalpo par eksperimentālu iekārtu, kurā kristalizējas risinājumi, kuru rezultātā tiks pārstrādāta sistēma. Šāda otrā, pilnveidotā sistēma tiks piegādāta pasūtītājam, kamēr pilotsistēmas piegāde izraisītu neko citu kā pasūtītāja neapmierinātību un iespējams, sistēmas sabrukumu, iespējams pat kompānijas.

Formālie dokumenti

Katram projekta vadītājam jāveido neliels formālo dokumentu kopums, kuros definēti projekta mērķi, kā tie jāsasniedz, kas un kad tos sasniegs un cik daudz tas maksās. Šie dokumenti arī var atklāt neatbilstības, kuras citādā veidā grūti ieraudzīt.

Projekta novērtējums

Veicot projekta laika novērtējumu, jāatceras, ka programmproduktu (kuru pārdod pasūtītājam) ir trīs reizes grūtāk uzrakstīt par lietojumprogrammu. Ir jāsaprot, cik daudz laika prasīs tehniskais darbs un cik administratīvais vai citi netehniskie uzdevumi, piemēram, sanāksmes.

Savstarpējā saziņa

Lai novērstu katastrofu, visām projektā iesaistītajām komandām jāuztur saziņa savā starpā cik vien iespējams dažados veidos: e-pastu, tālruni, sanāksmēm. Tā vietā, lai izdarītu kādus pieņēmumus, izpildītājam jājautā arhitektam, lai noskaidrotu viņa uzdevuma nozīmi, pirms realizējis šos pieņēmumus, kuri var būt pilnīgi nepareizi.

Ķirurģiskā brigāde

Parasti ķirurgu komandu vada viens ķirurgs, kurš veic kritiskākos darbus, bet mazāk kritiskus uzdevumus uztic citiem grupas dalībniekiem. Līdzīgi arī programmēšanas projektos nepieciešams labs programmētājs, kurš izstrādā kritiskos sistēmas komponentus, kamēr pārējā komanda realizē pārējo. Bez tam Bruks atzīmē, ka labs programmētājs parasti ir piecu līdz desmit reižu ražīgāks par vidējo.

Koda iesaldēšana un sistēmas versionēšana

Programmatūra ir neredzama. Daudzas lietas parādās sistēmā tikai tad, ja jaunajā sistēmā paveikts noteikts darba apjoms, ļaujot lietotājiem to izmēģināt. Šie izmēģinājumi var izraisīt lietotāju vajadzību izmaiņas. Līdz ar to jāmaina sistēma, lai realizētu šīs izmaiņas. Tas ir pieļaujams tikai līdz noteiktam punktam, citādi sistēmu neizdosies pabeigt. Pēc noteikta datuma sistēmā nav pieļaujamas nekādas izmaiņas un kods ir jāiesaldē. Visi izmaiņu pieprasījumi ir jāatliek uz sistēmas nākamo versiju.

Specializētie rīki

Tā vietā, lai katram programmētājam būtu savs specializētu rīku krājums, katrai komandai nepieciešams rīku veidotājs, kas varētu izveidot rīkus tieši tam darbam, kuru veic komanda. Bez tam vispārējai rīku komandai jāizveido kopējie sistēmas instrumenti.

Programmatūras izstrādes izmaksu samazināšana

Lai samazinātu rogrammatūras izstrādes izmaksas, Bruks atzīmē, ka izstrādātāji jāpiesaista tikai pēc tam, kad sistēmas arhitektūra ir pabeigta (posms, kas var aizņemt vairākus mēnešus, kuru laikā iepriekš pieņemtiem izstrādātājiem nebūs ko darīt). Vēl iespēja ietaupīt ir nevis programmatūru visu pašiem izgatavot, bet nopirkt jau gatavus risinājumus, kur tas ir iespējams.