(Tämä artikkeli on käännös Alistair Cockburnin englanninkielisestä artikkelista Methodology per project)

Tiivistelmä

Tarkastellessamme mistä menetelmä koostuvat ja mitkä yhteiset periaatteet löytyvät useiden menetelmien taustalta, havaitsemme miksi tarvitsemme erilaisia menetelmiä. Optimaalinen menetelmä on erilainen erityyppisille projekteille, mutta myös eri menetelmäarkkitehdeillä ja projektihenkilöstöillä on omat näkemykset, jotka pohjautuvat heidän kokemuksiin, pelkoihin ja periaatteisiin.

Kolme keskeistä huomioon otettavaa tekijää menetelmää valitessa ovat tiimin koko / hajautuneisuus, projektin kriittisyys ja projektin tavoitteet. Kansallisia ja tiimin sisäisiä kulturaalisia arvoja on vaikeampi kuvata, mutta niilläkin on vaikutusta.

Tämä kehys tarjoaa pohjan objektiiviselle keskustelulle siitä, mihin mikäkin menetelmä sopii. Keskeinen havainto on, että mikään tietty menetelmä ei ole "paras" vaan että on olemassa toimiva, toisenlaisen tapa työskennellä kussakin projektissa, kullekin projektiryhmälle. Tämä paperi esittelee kokemuksia projekteista, jotka hyödynsivät menetelmäkehystä ja kokemuksia, jotka johtivat "dynaamisesti kehittyvien" menetelmien tutkimukseen.

Avainsanat: metodit, menetelmä, sovelluskehitys käytännöt, soveluskehitysprosessi, ihmiset, kulttuurit, projektikokemukset.

Tällä hetkellä, loppuvuodesta 1999, menetelmät eivät ole kestävällä perustalla. Menetelmätutkimus yhä keskittyy luokitteluihin periaatteiden sijaan, kaupallisilla menetelmillä on "värityskirja-look", yritysjohto vaatii tiettyä toimintamallia tai muutoin edellyttää "yhtä oikeaa menetelmää", ja kiireiset sovelluskehittäjät naureskelevat kaikelle tälle. Ihmiset tarkoittavat menetelmällä eri asioita. Keskustelut menetelmistä ovat usein tunteikkaita, ilman yhteistä käsitteellistä pohjaa ja usein myös ilman tulosta.

Minä käytän termistä "menetelmä" sitä versiota, jota käytetään suurissa konsultointiyrityksissä ja joita minä kutsun "Iso-M"-menetelmiksi erotellakseni ne kevyemmistä versioista. Iso-M tarkoittaa kaikkien projektin jäsenten roolimääritelmiä, työkuvauksia ja aktiviteettien sekä siirrännäisten kuvauksia. Lyhyesti, se tarkoittaa kaikkea mikä liittyy projektiin, sisältäen istumajärjestyksen ja koulutuksen. On käynyt ilmi, että tällainen laaja näkemys tarvitaan, jotta voimme saada järkeviä ja käytännöllisiä tuloksia menetelmistä.

Yritän luoda reilua keskustelua ihmisten, joilla on erilainen näkemys, välille, luoda luokittelun menetelmille ja antaa alustavia suosituksia projekteille. Tämä tarkoittaa, että on löydettävä vastaus kysymyksiin mikä on "menetelmä"; onko menetelmiä yksi vai tarvitaanko useampia; jos useita, kuinka tiedämme, minkä menetelmän tai mitkä elementit valitsemme; onko joku menetelmä parempi kuin toinen; voidaanko näitä hyödyntää kiireisissä projekteissa.

Keskeisin havainto on, että menetelmiä on välttämättä useampia. Ne voidaan järjestää kahden olennaisimman akselin suhteen: projektin koko ja järjestelmän kriittisyys (luonnollisesti akseleita on useampia, mutta nämä kaksi tarjoavat hyvän alkuasetelman). Tässä menetelmäavaruudessa on helposti tunnistettavissa useita kymmeniä pisteitä. Tämän koko/kriittisyys -avaruuden sisällä menetelmäarkkitehdit valitsevat joukon käsitteitä, joita haluavat käsitellä: mitä rooleja, aktiviteetteja ja standardeja otetaan mukaan, ja mitkä jätetään ulkopuolelle. Sen jälkeen he työskentelevät omien uskomusten, aiempien kokemusten, pelkojen, toiveiden ja filosofisten periaatteiden pohjalta yrittäen optimoida projektin jonkun tekijän suhteen.

Menetelmät siten eroavat toisistaan tiimin koon, kriittisyden, laajuuden, optimoitavan tekijän ja menetelmäarkkitehdin perustavien uskomusten osalta. Menetelmiä voidaan siten vertailla keskittyen näihin ulottuvuuksiin ja niiden suhteisiin projektin tai organisaation tarpeisiin ottaen huomioon saatavilla olevat ihmiset ja heidän kulturaaliset luonteenpiirteet.

Lopulta, paperissa kerrotaan kuinka näitä ajatuksia käytettiin eri kokoisissa projekteissa eri maissa käyttäen eri teknologioita.

Sanasto

Menetelmistö: menetelmien tai tekniikoiden joukko.

Menetelmä tai systemaattinen proseduuri: synonyymi tekniikalle. Yksi tapa hahmottaa menetelmän ja menetelmistön ero on 1-2 henkilöä käyttävät menetelmiä työskennellessään yhdessä, 20 ihmistä tarvitsevat menetelmistön. Tärkein ero on kommunikointitarpeissa.

Menetelmistön koko: Ohjauselementtien määrä menetelmistössä. Jokainen standardi, aktiviteetti, laatumittari, menetelmäkuvaus, on ohjauselementti. Jotkut projektit ja menetelmäarkkitehdit suosivat pieniä menetelmistöjä, toiset suosivat suurempia.

Menetelmistön tiheys: Menetelmistön tarkkuus ja suvaitsevuuden aste. Suurempi tiheys merkitsee tiukempaa kontrollia ja "suurempaa seremoniallisuutta". Siten, toteaminen "menetelmistö vaatii käyttötapausten käyttöä" ei riitä. Jotkut projektit käyttävät hyvin vapaamuotoisia mallineita ja kevyitä katselmointeja, toiset tarvitsevat monisivuiset dokumentit useine katselmointeineen.

Menetelmistön paino: Käsitteellisesti, menetelmistön koon ja tiheyden tulo (vain käsitteellisesti, koska koolle ja tiheydelle ei aseteta numeraalisia arvoja). Kuinka monta elementtiä menetelmistö käsittää, kuinka tarkasti se esittää ne ja kuinka pienellä suvaitsevuuden asteella. Luultavasti jo aistit, että pienen, hauskan projektin pitäisi käyttää kevyempää menetelmistöä kuin suuren, kriittisen projektin.

Kriittisyys: Löytämättömien virheiden aiheuttamien vahinkojen luonne. Minä erittelen ne mukavuuden menetykseen, mahdolliseen rahan menetykseen, korvaamattoman rahamäärän menetykseen ja elämän menetykseen. Myös muut luokitukset ovat mahdollisia.

Projektin koko: Projektissa työskentelevien ihmisten määrä, tiimin koko. Ihmiset usein olettavat projektin koon kulkevan käsi kädessä ongelman koon tai monimutkaisuuden kanssa, mutta asia ei ole niin yksinkertainen, katso seuraava

Ongelman koko: Elementtien määrä ja niiden suhteiden monimutkaisuus ratkaistavana olevassa ongelmassa. Ongelman koolle ei voi olla yhtä absoluuttista mittaria. Usein uusi henkilö näkee tavan yksinkertaistaa ongelmaa. Ongelman koon asettamisen ongelma liittyy vastaavaan ongelmaan tarvittavien henkilöiden lukumäärän ja sopivaan menetelmistön painon asettamiseen. Paitsi että ei ole olemassa yhtä metriikkaa, jolla ongelman koko voitaisiin asettaa, ei myöskään ole yksimielistä käsitystä siitä, mikä projektin koko olisi optimaalinen millekin ongelman koolle. Siksi erittelen selkeästi projektin koon ongelman koosta.

Jos "Iso-M" menetelmä tarkoittaa kuinka organisaatio toistuvasti tuottaa ja julkaisee järjestelmiä, se pitää sisällään keitä se palkkaa, mitä varten se palkkaa heitä, mitä ihmiset odottavat työtovereilta, mitä käytäntöjä he noudattavat ja jopa minkä tyyppisiä projekteja he suostuvat tekemään. Kun yritys laittaa lehteen työpaikkailmoituksen, ilmoitus on yrityksen menetelmistön tuote. Ilmoituksessa on tehtävän nimi, velvollisuudet ja työntekijältä odotetut taidot. Näiden perusteella muodostuu selkeä käsitys siitä, että palkattava työntekijä tulee käyttämään tiettyjä taitoja tehdäkseen tiettyjä aktiviteetteja tuottaakseen tiettyjä tuloksia ja olemaan tietyssä suhteessa muihin työntekijöihin.
Siten menetelmistö sisältää ainakin seuraavat asiat:

Roolit - Työkuvaukset, joilla etsitte usia työntekijöitä: projektipäällikkö, testaaja, ohjelmoija jne
Taidot - Taidot, joita työnhakijoilla täytyy olla hakiessaan työpaikkaa
Tiimit - Kuinka ryhmittelet ihmisiä ja asetat heidät eri rooleihin
Työkalut - Mitä työkaluja ihmiset käyttävät työssään, joko tietyssä toiminnossa tai valmistaessaan tiettyä tuotetta standardin mukaan
Toiminnot - Toiminnot, joita työntekijät tekevät työskennellessään: kokouksen fasilitointi, java-ohjelmointi, käyttötapaussuunnittelu jne
Aktiviteetit - Kokoukset, katselmoinnit, tarkastuspisteet ja muut yleiset aktiviteetit, joihin työntekijöiden on osallistuttava, luotava tai tehtävä. Jokaista projektissa tehtävää tuotosta vastaa aktiviteetti "tuotoksen tekeminen". Kiinnostavampia aktiviteetteja ovat tapahtumat, kuten katselmoinnit, jotka muodostavat aktiviteettien elinkaaren
Tuotokset - Mitä kukin henkilö tai tiimi tuottaa ja ojentaa seuraavalla henkilölle tai tiimille: käyttötapaukset, luokkasuunnitelmat, testitapaukset jne
Standardit - Mikä on sallittua tai kiellettyä tuotoksissa. Standardeja on monenlaisia: merkinnällisiä (sisältää ohjelmointikielen), hallinto- ja johtostandardeja ja projektikäytäntöjä. Menetelmistö voi jättää joitain kohtia auki määriteltäväksi projektin aikana.
Laatu - Mitä sääntöjä ja asioita seurataan kustakin tuotoksesta. Jotkut liittävät laatumääreet aktiviteetteihin, minä liitän laadun tuotoksiin. Kumpi tahansa valitaankin, menetelmistön on käsiteltävä laatukysymyksiä.
Arvot - Minkä eteen tiimi taistelee, kuinka he haluavat kommunikoida ja työskennellä. Erilaiset arvot tuottavat erilaisia toimivia menetelmistöjä.

Menetelmistö on sopimus siitä kuinka monta ihmistä työskentelee yhdessä. Yksin työskentelevä ihminen voi myös seurata täyttä menetelmistöä ja olla siten itse kaikissa rooleissa.

Luonnollinen johtopäätös on se, että menetelmistön laajuus määräytyy siitä, mitä rooleja, aktiviteetteja ja tuotoksia se käsittelee. Laajuus määräytyy kolmen kategorian perusteella:
elinkaaren kattavuus - mitkä projektin elinkaaren vaiheet menetelmistö kattaa
roolien kattavuus - mitkä roolit on menetelmistössä käsiteltyinä
aktiviteettien kattavuus - mitkä em. roolien aktiviteeteista on käsiteltyinä. Menetelmistö voi määritellä, kuinka käytetystä ajasta raportoidaan (tämä on luonnollinen jatkumo projektipäällikön monitorointi- ja aikataulutustehtävien hoitamiselle), ja voi jättää loma-anomukset käsittelemättä (jätetty menetelmistön ulkopuolelle koska se on osa yrityksen perustoimintoja).

On epätodennäköistä löytää menetelmistö, joka yrittäisi käsitellä kaikkien roolien kaikki aktiviteetit. Joillakin yrityksillä on kuitenkin menetelmistöjä, jotka kattavat koko projektin elinkaaren ensivaiheen myyntioperaatioista aina ylläpitoon saakka, ja missä kaikilla rooleilla on projektirahoitus.

Viime vuosina on julkaistu useita kirjoja, jotka keskittyvät vain yhteen rooliin, suunnittelija/ohjelmoija. Näissä kirjoissa esitetään kuinka rakenteista tai oliosuunnittelua pitäisi tehdä, keskittyen muutamaan toimintoon ja piirrosstandardiin. Liittäessämme nämä menetelmistökehyksiin ymmärrämme, miksi kiireiset ohjelmistokehittäjät turhautuvat kun näitä kutsutaan "menetelmistöiksi". Tietty suunnittelutekniikka tai piirtostandardi on vain pieni asia heidän elämässään, eikä millään tavalla kriittinen projektin lopullinen onnistumisen kannalta, joka on kuitenkin tärkein tavoite.

Täysin määritelty menetelmistö on väkisinkin raskas, kuten seuraava esimerkki osoittaa. Oletetaan että menetelmistössä on määritelty yhdeksän roolia, kullakin on neljä tuotosta, kullekin tuotokselle yksi standardi ja kolme tarkastuspistettä, kuten katselmoinnit ja julkaisu. Näistä muodostuu 63 elementtiä määriteltäväksi. Eikä tässä ole edes raapaistu käytäntöjä, laatukysymyksiä eikä muita aktiviteetteja.

Kuinka tällaisesta menetelmistöstä jäljitetään virheitä? Se on tyypillisesti uusi tuotos, kulttuurisensitiivinen sellainen, jossa on virheitä, jotka havaitaan vasta pitkän ajan kuluessa. Siinä vaiheessa kun seuraava projekti alkaa, on käytettävä teknologia saattanut jo muuttua, samoin kuin yksilöiden ja organisaation tarpeet. Menetelmistöjen virheenjäljitys ei kuulu menetelmistöavaruuden kartoitukseen, mutta on tärkeä joskin vaikea asia.

Periaatteet

Olisi mukavaa löytää periaatteet, jotka ovat yhteisiä kaikille menetelmistöille. Minä esitän neljä, jotka olen kokenut tehokkaiksi ja tarkoiksi. Kuitenkin, menetelmistö noudattelee eniten menetelmäarkkitehdin periaatteita. Mistä nämä periaatteet tulevat? Ne tulevat arkkitehtien henkilökohtaisesta taustasta - onnellisista ja onnettomista kokemuksista, ja periaatteista joita he muodostivat niistä, olivatpa ne oikeita tai vääriä. On valitettavaa, että näiden periaatteiden perintö ei ole näkyvissä, vaan piileskelee menetelmistön esittelevien tekstirivien välissä. Vaikka olen tarkastellut useita kymmeniä projekteja kahdeksassa eri maassa vuodesta 1991 ja muodostanut useita hypoteeseja, joilla uskon olevan laajaa käyttöä, on yhä kuitenkin niin, että omat abstraktioni kokemuksistani, peloista ja onnistumisista, päättävät suurimman osan menetelmistön muodosta.

Seuraavassa on ne periaatteet, joihin minä suhtaudun luottavaisesti

Periaate 1: Suurempi menetelmistö tarvitaan kun projektissa on enemmän ihmisiä. Suurempi tarkoittaa enemmän ohjauselementtejä. Kuvaa viisi luetaan näin: kommunikaation tarve kasvaa kun ihmisten määrä kasvaa. Yksittäisen ihmisen tehokkuus laskee kun kommunikoinnin tarve kasvaa. Koska menetelmistön tehtävä on koordinoida ihmisiä ja kommunikointia, sen koon on kasvettava kun roolien ja eri tuotosten lukumäärä kasvaa.
Tämä periaate kertoo, että ei kannata olettaa suurella tiimillä toimivan menetelmän toimivan pienellä tiimillä tai toisinpäin.

(Lisää tulossa toukokuun aikana)