Ketterän projektin työmääräarvio

Heh, otsikko on paradoksi itsessään. Ketterät menetelmät lähtevät siitä että työmääriä ei voi arvioida – projektin alussa tehdyn työmääräarvion tarkkuus on tutkimusten mukaan keskiverrosti niin kehno että on parempi puhua arvauksesta kuin arviosta. Ja arvaus voi mennä moninkerroin pieleen. Ainoa tilanne jossa arviosta voi puhua on kun tehdään tutun tiimin kera tutulle asiakkaalle projektia jonka kaikki komponentit ovat tuttuja ja josta on paljon kokemusta. Ja jos kukaan ei sairastu eikä yllätyksiä tapahdu. Kuinka usein olet muuten ollut sellaisessa IT-projektissa mukana?

 

Joka tapauksessa, tässä on kiintoisa yritys murskata agilen perusperiaate, eli excel taulukko jolla voi laskea Scrum projektin story pointsien perusteella työmääriä. Itseä pakkaa pikkasen huvittamaan, mutta tiedän paineen joka on ketterilläkin tiimeillä arvioida työmääriä alussa, joten ehkä tästä on jollekulle hyötyä. Arvailussa.

 

http://www.dzone.com/links/r/estimating_project_costs_and_resource_needs_using.html

Testauksesta ja Tomcatistä

No niin, tämä viikko sujuu sitten kiireen merkeissä joten ei ole paljoa uutta kirjoiteltavaa.. Mutta muutama asia on silti mielessä.

 

Olen miettinyt paljon yksikkötestauksen käyttöä ohjelmistokehityksessä Test Driven tapaan. Äärimmäisen harva sovelluskehitystiimi voi kerskua sillä että tekee TDD tapaan 100% kattavuudella eli yksikkötestaa tietokantakerroksen, liiketoimintakerroksen ja web käyttöliittymäkerroksen eristetyin testein joita on nopea ajaa, ja jotka kehitetään Test First periaattein, siten että testit toimivat suunnitteluvälineenä. Ei ole mitään estettä miksei tätä voisi teknisesti tehdä, mutta se on vain työlästä kun se tehdään oikein. Sensijaan integraatiotestit jotka testaavat moduulia ympäristössään ja ovat hitaampia ajaa, ovat myös halvempia tehdä ajankäytöllisesti, ja niitä voi rakentaa samoilla yksikkötestausvälineillä (JUnit ja Mockito ovat kovia tässä).

Oli miten oli, TDD ajatuksessa on kuitenkin jotain filosofisesti hyvin puhuttavaa. Testattava koodi on avointa ja tasarakenteista koodia, ja miten voisi paremmin tehdä funktion kuin ensin miettimäll ämistä tietää että se toimii? Ja mikä parasta, nimeämällä testit fiksusti testikoodi on melkeinpä luettavaa speksiä. Mockitoa koodatessakin käytännössä kirjoitetaan speksejä englanniksi – mutta näitä speksejä voi nappia painamalla tarkistaa milloin vain haluaa.

Ja tästä päästiinkin viikon linkkivinkkiin, eli http://www.dzone.com/links/r/10_steps_to_more_readable_tests.html

Toinen huomio: Tomcat 7 on saavuttanut enemmän tai vähemmän vakaan tason ja päässyt ulos betasta. Tomcat taitaa olla edelleenkin suosituimpia alustoja joissa java web sovelluksia ajetaan (huomioiden että JBOSS ajaa myös Tomcatiä), ja kun uusin versio on jälleen uusi Java EE 6 alusta, se herättää heti mielenkiinnon. Yksi muutos on Servlet 3.0 tuki – hyvästit XML:lle jos niin haluat. Tervetuloa asynkroniset kutsut. Lopulta Tomcat 7:ssä on myös korjattu aiempia muistivuoto-oireita, eli se tarjoaa kiinnostavan alustan testata myös vanhoille sovelluksille. EJB Lite ei valitettavasti onnistu vieläkään – mutta sitä varten on JBOSS 6…