hwechtla-tl: Ketterä kehitys

Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset

---

(nettipäiväkirja 07.11.2014) Olen ollut vähän huolissani ketterän kehityksen vesittymisestä. Monet nykyiset ketteriksi sanotut ohjelmistokehitystavat ovat oikeasti projektihallintomenetelmiä. Alkupuolen agile oli nimi, joka annettiin tietylle manifestille:

http://www.agilemanifesto.org/

Agilen ensimmäiset toteutukset olivat hyvin konkreettisia ja tarkkoja, esimerkiksi XP määritti oikeasti monia käytäntöjä, joita pitää noudattaa: http://en.wikipedia.org/wiki/Extreme_programming#Practices Vaikka tämä saattaa tuntua kankealta, se oikeasti esti kutsumasta ketteräksi ihan mitä sattuu. Nykyiset metodologiat, kuten (softakehitykseen sovellettu) kanban ja Scrum, eivät oikeasti estä tekemästä asioita hyvin, hyvin epäketterästi.

Minulla on oma listani suosikkisäännöistä. Keräsin sen XP-käytännöistä, muutamista suosikeistani ensimmäisessä wikissä (http://c2.com/cgi/wiki) sekä Joel Spolskyn 12 kohdan listasta (http://joelonsoftware.com/articles/fog0000000043.html).

1. Automatisoi kaikki, minkä voit
   -> automatisoi viimeistään kolmannella kerralla, kun teet saman asian
   -> automatisoi asioiden seuranta (testit, työnseuranta)
   -> automatisoi softan käyttöönottoprosessi
   -> älä pidä samaa tietoa kahdessa paikassa
   -> seuraa työajan kulutustasi ja automatisoi kaikki, mihin menee aikaa
2. Tee mahdolliseksi perua, älä mahdottomaksi mokata
   -> anna kaikille mahdollisimman laveat oikeudet
   -> huolehdi, että kukin voi hoitaa asiat itsepalveluna
   -> käytä versiohallintaa
   -> tee varmuuskopioita
   -> tee automatisoidut regressiotestit
3. Kaikkea on voitava kokeilla mahdollisimman varhaisessa vaiheessa
   -> suunnittele etenemisjärjestys niin, että tämä on mahdollista
   -> luonnostele käyttöliittymät
   -> rakenna prototyyppeja
   -> julkaise usein
   -> jonkin näyttökelpoisen saaminen aikaan ei saisi viedä monta viikkoa
4. Tee yhteistyö tarpeettomaksi
   -> huolehdi, että kaikki tieto on julkista
   -> määrittele rajapinnat ensin (ihmisten ja heidän tekemiensä komponenttien välillä)
   -> minimoi riippuvuudet ihmisten töiden välillä
5. Parikoodaa

• merkintä: 2014-11
• atehwa
• kategoria: päiväkirjamerkintä
• metodologia
• kaupallisen ja avoimen kehityksen eroja