myyttinen man-monthEdit

Brooks käsittelee useita syitä aikatauluhäiriöihin. Kestävin on hänen keskustelunsa Brooksin laista: työvoiman lisääminen myöhäiseen ohjelmistoprojektiin tekee siitä myöhäisemmän. Man-month on hypoteettinen työn yksikkö, joka edustaa yhden ihmisen kuukaudessa tekemää työtä; Brooksin lain mukaan mahdollisuus mitata hyödyllistä työtä ihmiskuukausina on myytti, ja on siten kirjan keskipiste.

monimutkaisia ohjelmointihankkeita ei voida täysin jakaa erillisiin tehtäviin, joita voidaan työstää ilman työntekijöiden välistä viestintää ja luomatta monimutkaisia suhteita tehtävien ja niitä suorittavien työntekijöiden välille.

näin ollen useamman ohjelmoijan määrääminen aikataulusta jäljessä olevaan projektiin tekee siitä entistä myöhäisemmän. Tämä johtuu siitä, että uusien ohjelmoijien tarvitsema aika oppia projektista ja lisääntyvä kommunikaatio kuluttaa yhä enemmän käytettävissä olevaa kalenteriaikaa. Kun n ihmiset joutuvat kommunikoimaan keskenään, kun n kasvaa, heidän tuotoksensa pienenee ja kun se muuttuu negatiiviseksi, projekti viivästyy entisestään jokaisen henkilön lisätessä.

• ryhmän interkommunikaatiokaava: n(n − 1) / 2
• esimerkki: 50 kehittäjää antaa 50 · (50 – 1) / 2 = 1225 viestintäkanavat.

Ei hopealuotia

Brooks lisäsi ”No Silver Bullet — Essence and Accidents of Software Engineering”—ja siihen liittyviä lisäpohdintoja, ”’No Silver Bullet’ Refired”—myyttisen Ihmiskuukauden vuosipäiväpainokseen.

Brooks painottaa, ettei ole olemassa yhtä hopealuotia — ”ei ole olemassa yhtä yksittäistä kehitystä, ei teknologiassa eikä johtamistekniikassa, joka itsessään lupaa edes yhtä suuruusluokkaa parannusta vuosikymmenen kuluessa tuottavuudessa, luotettavuudessa, yksinkertaisuudessa.”

argumentti nojaa satunnaisen kompleksisuuden ja olennaisen kompleksisuuden erotteluun, samaan tapaan kuin Amdahlin laki nojaa erotteluun ”tiukasti sarjallisuudesta” ja ”parallelizable”.

toisen järjestelmän vaikutusedit

toisen järjestelmän vaikutus ehdottaa, että kun arkkitehti suunnittelee toisen järjestelmän, se on vaarallisin järjestelmä, jonka hän koskaan suunnittelee, koska heillä on taipumus sisällyttää kaikki lisäykset, joita he eivät alun perin lisänneet ensimmäiseen järjestelmään luontaisten aikarajoitusten vuoksi. Niinpä kun insinööri ryhtyy käyttämään toista järjestelmää, hänen tulisi muistaa, että hän on altis suunnittelemaan sitä liikaa.

eksorsedit

kirjoittaja tekee havainnon, että sopivan monimutkaisessa systeemissä on tietty irreduktiivinen määrä virheitä. Kaikki yritykset korjata havaitut virheet johtavat yleensä muiden virheiden käyttöönottoon.

Progress trackingEdit

Brooks kirjoitti ”Question: How does a large software project get to be one year late? Vastaus: päivä kerrallaan!”Vähitellen lipsahdukset monilla rintamilla kasaantuvat lopulta tuottamaan suuren kokonaisviiveen. Pienten yksittäisten virstanpylväiden saavuttamiseen on kiinnitettävä jatkuvasti huomiota jokaisella johtotasolla.

käsitteellinen integrityEdit

jotta järjestelmä olisi käyttäjäystävällinen, järjestelmän tulee olla käsitteellinen eheys, joka voidaan saavuttaa vain erottamalla arkkitehtuuri toteutuksesta. Yksittäinen pääarkkitehti (tai pieni joukko arkkitehteja) päättää käyttäjän puolesta, mitä järjestelmään menee ja mikä jää ulos. Arkkitehdin tai arkkitehtiryhmän tulisi kehittää käsitys siitä, mitä järjestelmän pitäisi tehdä ja varmistaa, että muu tiimi ymmärtää tämän vision. Jonkun uutta ideaa ei välttämättä oteta mukaan, jos se ei sovi saumattomasti kokonaissuunnitteluun. Itse asiassa käyttäjäystävällisen järjestelmän varmistamiseksi järjestelmä saattaa tarkoituksella tarjota vähemmän ominaisuuksia kuin mihin se pystyy. Pointti on, jos järjestelmä on liian monimutkainen käyttää, monet ominaisuudet jäävät käyttämättä, koska kukaan ei ole aikaa oppia niitä.

manualEdit

pääarkkitehti laatii käsikirjan järjestelmäspesifikaatioista. Siinä pitäisi kuvata yksityiskohtaisesti järjestelmän ulkoiset eritelmät eli kaikki, mitä käyttäjä näkee. Ohjekirjaa on syytä muuttaa sitä mukaa, kun palautetta tulee toteutustiimeiltä ja käyttäjiltä.

pilottijärjestelmä edit

uudenlaista järjestelmää suunnitellessaan tiimi suunnittelee heittojärjestelmän (aikooko se tai ei). Tämä järjestelmä toimii ”pilottisuunnitelmana”, joka paljastaa tekniikoita, jotka myöhemmin aiheuttavat järjestelmän täydellisen uudelleensuunnittelun. Tämä toinen, älykkäämpi järjestelmä pitäisi toimittaa asiakkaalle, koska pilottijärjestelmän toimittaminen aiheuttaisi asiakkaalle vain tuskaa ja mahdollisesti pilaisi järjestelmän maineen ja ehkä jopa yrityksen.

viralliset asiakirjat

jokaisen projektipäällikön tulisi luoda pieni virallisten asiakirjojen ydinjoukko, jossa määritellään hankkeen tavoitteet, miten ne saavutetaan, kuka ne saavuttaa, milloin ne saavutetaan ja kuinka paljon ne tulevat maksamaan. Nämä asiakirjat voivat myös paljastaa epäjohdonmukaisuuksia, joita on muuten vaikea nähdä.

projektin estimointimedit

projektin aikoja arvioitaessa on muistettava, että ohjelmointituotteet (joita voidaan myydä maksaville asiakkaille) ja ohjelmointijärjestelmät ovat molemmat kolme kertaa vaikeampia kirjoittaa kuin yksinkertaiset itsenäiset sisäiset ohjelmat. On pidettävä mielessä, kuinka suuri osa työviikosta todella kuluu teknisiin asioihin verrattuna hallinnollisiin tai muihin ei-teknisiin tehtäviin, kuten kokouksiin ja erityisesti ”stand up”-tai ”all-hands” – kokouksiin.

Kommunikaatiomedit

katastrofin välttämiseksi kaikkien projektissa työskentelevien ryhmien tulisi pitää yhteyttä toisiinsa mahdollisimman monella tavalla—sähköpostilla, puhelimella, tapaamisilla, muistioilla jne. Sen sijaan, että oletetaan jotain, toteuttajien pitäisi pyytää arkkitehti(t) selventää aikomuksensa ominaisuus he toteuttavat, ennen kuin jatkat oletus, joka voi hyvinkin olla täysin virheellinen. Arkkitehdin (arkkitehtien) tehtävänä on laatia projektista ryhmäkuva ja välittää se muille.

kirurgista tiimiä

paljolti niin kuin kirurgista ryhmää leikkauksen aikana johtaa yksi kirurgi, joka tekee kaikkein kriittisintä työtä, samalla kun hän ohjaa ryhmää auttamaan vähemmän kriittisiä osia, vaikuttaa järkevältä, että ”hyvä” ohjelmoija kehittää kriittisiä järjestelmäkomponentteja, kun taas muu tiimi tarjoaa tarvittavan oikeaan aikaan. Lisäksi Brooks miettii, että” hyvät ” ohjelmoijat ovat yleensä viidestä kymmeneen kertaa tuottavampia kuin keskinkertaiset.

Code freeze and system versiingedit

Software is invisible. Siksi monet asiat tulevat ilmi vasta, kun tietty määrä työtä on tehty uuden järjestelmän parissa, jolloin käyttäjä voi kokea sen. Tämä kokemus tuottaa oivalluksia, jotka muuttavat käyttäjän tarpeita tai käsitystä käyttäjän tarpeista. Järjestelmä tulisi siis muuttaa vastaamaan käyttäjän muuttuneita vaatimuksia. Tämä voi tapahtua vain tiettyyn pisteeseen asti, muuten järjestelmä ei välttämättä koskaan valmistu. Tiettynä päivänä järjestelmään ei saisi enää tehdä muutoksia ja koodi pitäisi jäädyttää. Kaikki muutospyynnöt tulee siirtää seuraavaan järjestelmään.

Erikoistyökalutedit

sen sijaan, että jokaisella ohjelmoijalla olisi omat erikoistyökalunsa, jokaisella tiimillä tulisi olla nimetty työkaluntekijä, joka voi luoda työkaluja, jotka ovat hyvin räätälöityjä tiimin tekemään työhön, esim.koodigeneraattorityökalu, joka luo koodia spesifikaation perusteella. Lisäksi järjestelmälaajuiset työkalut tulisi rakentaa yhteisellä työkalutiimillä, jota valvoo projektipäällikkö.

Ohjelmistokehityskustannusten alentaminen

ohjelmistokehityskustannusten alentamiseen on kaksi tekniikkaa, joista Brooks kirjoittaa:

• toteuttajat voidaan palkata vasta järjestelmän arkkitehtuurin valmistuttua (vaihe, joka voi kestää useita kuukausia, jolloin ennenaikaisesti palkatuilla toteuttajilla ei välttämättä ole mitään tekemistä).
• toinen tekniikka, jonka Brooks mainitsee, ei ole kehittää ohjelmistoa lainkaan, vaan yksinkertaisesti ostaa se ”hyllyltä”, kun se on mahdollista.