Mītiskais cilvēkmēnesis
| 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 |
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.
Piedāvātās idejas
[labot šo sadaļu | labot pirmkodu]Mītiskais cilvēkmēnesis
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]Lai novērstu katastrofu, visām projektā iesaistītajām komandām jāuztur saziņa savā starpā cik vien iespējams dažādos 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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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
[labot šo sadaļu | labot pirmkodu]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.