Continuous Delivery Windows alustalla

Tuli taannoin paneuduttua syvemmälle Windows maailman varusteisiin ja lähtökohtiin koskien automatisoitua testausta, buildejä, test driven development käyttöä ja sensellaista. Suurena pettymyksenä tuli miten lastenkengissä siellä mennään, verrattuna esim. Java alustaan. Oli kaikenlaista härveliä joista suurin osa hyvin epävirallisia ja herkästi särkyviä jos visual studio versio vaihtui. Olen siitä asti ollut vähän haku päällä parempien varusteiden suhteen, jotka antaisivat keskittyä olennaiseen.

Ja niin törmäsin artikkeliin jossa tiimi tekee ihan perinteistä continuous deliveryä – windows alustalla.

http://java.dzone.com/articles/continuous-delivery-difference?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29

Muutama kohta jotka herättivät mielenkiintoa.. Ikuisuuskysymys on miten testaajat ja ylläpitäjät suhtautuvat ketterään tiimiin. Tässä on sulautettu ammattitestaajat osaksi tiimiä. Ja ylläpito hoituu omaa sydäntä lähellä olevalla DevOps tyylillä. Periaatteet kuten DevOps, TDD, ketteryys ovat arvostettuja ja hyviä, mutta vaativat toimiakseen myös välineet jotka hoitavat hommansa eivätkä tule tielle.

Eli tässä kombinaatiota: msbuild, TeamCity, NUnit, SpecFlow, PowerShell. Ja msi-pakettien sijaan zip-paketteja (Java maailmassahan ei juuri .exejä tuoteta muutenkaan).

Tuli sitten tuhlattua miljardi

Jep, tämä on jo vanha uutinen, mutta ehdin ajoittain lukemaan sähköposti-backlogiani ja yleensä muutaman viikon viiveellä kun aikaa löytyy, joten asia ehti käsittelyyn vasta nyt. Minä en siis tuhlannut miljardia, mutta jenkit tuhlasivat. Jälleen kerran on tehty massiivinen vanhanaikainen projekti jossa tehdään raskas esimäärittely, työmäärä-arvaus, asetetaan tiukka deadline ja budjetti, ja pistetään tuhlausjuna käyntiin. Puolessavälissä matkaa havaitaan että hups, ei tämä toimikaan. Business vaatimukset ovat muuttuneet, softa ei etene haluttuun suuntaan, softanteossa on ratkaisemattomia ongelmia. Hups, siinä meni miljardi veronmaksajien rahoja.

http://www.computerworld.com.au/article/442099/air_force_scraps_massive_erp_project_after_racking_up_1_billion_costs/

No, liiketoimintaahan tuokin on. Miljardi taalaa on ruokkinut monia suita matkan varrella mutta olisi toki mukavaa kun jotain tulisi tuutista uloskin vastineeksi, muuten kyse on vain verorahojen kierrätyksestä (joka sinällään on lähestulkoon ikiliikkuja, vain huonolla hyötysuhteella).

Tässäpä villi ajatus, mutta miten olisi, jos projektia olisikin vedetty etappeina ja välitavotteina? Priorisoitu se, että saadaan demonstroitavaa toiminnallisuutta toimitettua josta saadaan takaisin palautetta, ja saadaan tilaajakin ymmärtämään mitä tehdään ja meneekö se oikeaan suuntaan? Jos olisi menty peräti testit edellä varmentamaan että pienikin toimitettu osa toimii ja kestää kuormaa. No niin, eihän integraatio ja ERP hankintaprojekteja vain niin tehdä. Ei se ole realistista, ne on vain pakko vetää vanhan kaavan mukaan.

Vai onko? Pitäisiko kuitenkin tehdä jotain?`

http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments

http://www.quickstonesoftware.com/blog/2011/06/22/erp-and-agile-a-good-match-for-success

https://community.dynamics.com/product/nav/navnontechnical/b/erpsoftwareblog/archive/2012/11/08/why-is-agile-project-management-better-for-erp-projects.aspx

Olisiko kuitenkin arvokasta saada palautetta tilaajalta, linjata tekeminen siihen mitä halutaan ja etenkin tarvitaan? Olisiko mukavaa varmistaa että valitut teknologiat sopivat tehtäväänsä? Ei ole helppoa soveltaa ketteryyttä massiivisiin järjestelmämuutoksiin tai hankintoihin, joissa yhden asian muuttaminen vaikuttaa potentiaalisesti moneen muuhunkin asiaan, ja jossa testausympäristön aikaansaaminen voi tuntua valtavalta/mahdottomalta tehtävältä. Kuitenkin, perinteisetkään lähestymistavat eivät sanottavammin toimi. Olisiko aika ottaa inspiraatiota ketteryydestä?

Toki muistaen että ketteryyskin voi epäonnistua yhtälailla, ja siinä on omat riskinsä. If it was easy we wouldn’t be getting paid to do it 😉

Mietin hetken pistänkö tätä mietiskelyä liikkeelle, koska projektin läpivientimalli on niin herkkä aihe meille monelle, ja koska epäonnistumisen syyt ovat aina moniselitteiset, ei niitä yksistään projektimalli useinkaan selitä. Ja usein voi tuntua että suurikokoisia hankkeita on vaikea, suorastaan mahdoton mitenkään tehdä ketterämmin. Mutta kuitenkin, tuntuu käsittämättömältä että taas on uhrattu miljardin verran rahoja suorastaan kankkulan kaivoon, kun järki sanoo että jotain tulosta pitäisi saada aikaan kausittain. Ellei kuukauden välein, edes kerran kvartaalissa uudelleensuuntaus etappia. Tuossa jenkkihankkeessakin niitä oli muutama mutta selkeästi liian vähän tai vääränlaisia.

Kerran neljässä tai kahdeksassa viikossa tilaajalle tai asiakkaan edustajalle demonstroitavaa toimintaa parantavaa toiminnallisuutta. Liikaa vaadittu?

Tampere Goes Agile!

Kävin pitämässä lightning talkin Tampere Goes Agile tapahtumassa aiheesta Agile Enabler: Grails, eli aiheena miten aikainen prototypointi auttaa saamaan aikaan sen mitä asiakas todella TARVITSEE eikä sitä mitä HALUAA. Want ja Need voivat joskus johtaa samaankin asiaan, mutta ne eivät itseisarvoisesti ole sama asia – jonka ketteryyttä tuntevat toki hyvin tietävätkin.

Java alustalla toimiessa ja projektia aloittaessa iskee usein valintahalvaus: vaihtoehtoja on lukemattomia tehdä sama asia. Spring? Puhdas Java EE ja JSF? GWT? Kun valinta on tehty, valitaan lisää. JDBC vai JPA? SQL vai NOSQL? Log4j vai util.logging? Maven vai Ant? Matka siitä kun tuoteidea on päätetty toteuttaa ja alusta valittu siihen kun on jotain mitä voi prototypoida ja demota on pitkä, pahimmillaan kuukausia.

Ongelma ei ole sama kun tietää mitä tekee, valinnat on tehty ja yhdistelmästä on kokemusta ja apuvälineet rakennettu. Mutta silti, miten pitkään menee ensimmäiseen toimivaan prototyyppiin? Josta siis saa arvokasta palautetta siitä mennäänkö oikeaan suuntaan, ja siitä mitä suuntia on edes tarjolla. Kuukausia? Viikkoja? Päiviä?

Grailsillä vastaus on minuuteja. Ja customoidessa yksityiskohtia ehkä tunteja. Koska prototyypit ovat pystyssä heti, muutokset reaaliaikaisia, oletuksia paljon, ja valinnat jo tehty, alusta on äärimmäisen tuottava. Tein seminaari-ilmoittautumisjärjestelmän parissa tunnissa. Ja verkkokoulutusjärjestelmän parissa päivässä. Nopeita iteraatioita, nopea palautesilmukka.

P.s. seminaarikahvi on TODELLA asiallista… :p

image

Väärä ketteryys ja oikea ketteryys

No niin, tämä teema on kypsynyt jo hetken aikaa mietintämyssyn alla, on tehnyt mieli kirjoittaa omia ajatuksiani tästä. Osittain kypsyttelyyn on vaikuttanut se, että olen työstänyt kollegan kanssa Agile Engineering Practises koulutusta osana Certified Scrum Developer koulutusta, jossa pyritään parantamaan valmiuksia tehdä sitä oikeaa Scrummia, käytännön tasolla ongelmia ratkaisten siis. Powerpoint kalvojen sijaan tällä kurssilla tuotetaan ja testataan jatkuvasti sitä toimivaa softaa siis, sikäli ei riitä että osaa puhua, vaan tässä pitää osata soveltaa.

Olen törmännyt asiakkaiden kanssa yllättävän usein siihen että ollaan olevinaan ketteriä, tai ollaan tekevinään Scrummia tai Leaniä, ja kuitenkin ollaan katkeria menetelmää kohtaan ja koetaan että se ei toimi. Tässä ei toki ole vielä ihmeellistä, ei kaikki toimi kaikille, mutta kun olen udellut lisää syitä tyytymättömyyteen, paljastuu pian etteivät he usein ole tehneet tosiasiassa mitään ketterää ollenkaan, vaikka sertifikaatit on taskussa ja johdon siunaus. Ei ihme että on tyytymättömyyttä kun odotukset ja tulokset eivät kohtaa. Joten mietitäänpä paria oikean ja väärän agilen tunnusmerkkiä.

1. Manuaali kädessä

Ensimmäinen mieleentuleva tunnusmerkki väärästä ketteryydestä on lähteä toteuttamaan sitä manuaali toisessa kädessä otsa rypyssä. Tai vaikka tämä artikkeli käteen printattuna. Tämähän on ketteryyden irvikuva ja paradoksi. Ketteryyden ydin on sopeutua ja kehittyä, ei toistaa vanhaa. Oikea ketteryys ei lähde vanhan toistamisesta (tosin se voi olla tarpeen opiskeluvaiheessa), vaan jatkuvasta kehittymisestä ja eteenpäin menosta, ja sopeutumisesta. Tässä piilee toki yksi sudenkuoppa: monet agile menetelmät ovat jopa vaarallisia jos valikoi vain piirteen sieltä toisen täältä, koska piirteet tukevat toisiaan. Mutta on silti väärä lähtökohta pyrkiä toteuttamaan niitä fanaattisesti ja itseisarvoisesti sokkona toistellen – ei ole sellaista kuin täydellinen menetelmä, kehittymisen varaa on aina.

Oikea ketteryys? Se lähtee siitä että myönnetään että ihmiset voivat tehdä virheitä, etenkin alueille jotka ovat entuudestaan vieraita, tuntemattomia. Rakennetaan sisään itsetarkistelu ja jatkuva kehittyminen niin että se on yhtä arkipäiväistä kuin hengittäminen. On ok tehdä virhe, on väärin toistaa sitä. Tehdään jatkossa aina paremmin, tehokkaammin, fiksummin. Projektimenetelmän nimellä ei ole väliä. Onko se Scrum, Lean, Kanban, vai jotain mitä tulee tulevaisuudessa, se ei merkitse. Se mikä merkitsee on sisäänrakennettu kyky toipua ja kehittyä.

2. Scrummerfall

Suurin murhe ketterillä tiimeillä on perinteinen Scrummerfall – aloitetaan jäykästä vesiputousmallisesta projektista jossa on tiukka budjetti ja deadline, ja tiukka lista ominaisuuksia joista ei voi tinkiä. Tehdään raskas upfront määrittely – suunnittelu – ja paljon handoffeja ja tarpeetonta dokumentaatiota – ja sitten toteutusvaiheessa sanotaan: ok, aloittakaa Scrum. Siinä ei paljon sopeuduta, iteroida, priorisoida, eikä olla ketteriä. Näissäkin oloissa voi saada aikaan jotain, mutta lähtökohtaisesti ketteryyden hyödyt on jo menetetty ennen kuin peli on edes käynnistynyt. Ongelmana on että ketteryyden ostaminen vaatii näkemystä ja osaamista myös, ja vasta viime vuosina on esim. Product Owner koulutuksista tullut kovia hittejä. Lisäongelmana on ketteryyden kilpailuttaminen – mitä muuta siinä voi käyttää kriteerinä kuin referenssejä ja uskottavuutta? Tai tuntihintaa? 😉

Oikea ketteryys? Se lähtee osaavasta product ownerista jolla on selvillä tarpeet, ja kyky tai tuki priorisoida ne siten että aloitetaan tärkeistä ja edetään kohden vähemmän tärkeitä. Jos tarpeet ovat liian suuria on aika paloitella ja priorisoida lisää. Jos tuntuu että kaikki tarpeet ovat ykkösprioriteetin tärkeitä niin varmaan on syytä joustaa aikataulussa ja budjetissa sitten sen mukaan, ja puhua vaiheista – eikä big bang päivityksistä. Oikea ketteryys priorisoi ja tuottaa jatkuvasti demonstroitavaa liiketoiminnallista arvoa. Näin pidetään ostajat tyytyväisenä ja sitoutuneena ja päädytään siihen vähemmistöön it-projekteja jotka onnistuvat.

Vesiputousmallista tulikin mieleen: Katsokaapa wikipediasta anti-patterns artikkeli, ja katsokaa mitä waterfall projektimallista sanotaan 😉

3. Jätetään suunnittelu ja dokumentointi pois, mutta ei myöskään testata tai toimiteta

Ok, nämä ovat aika ilmeisiä heikkouksia. Otetaanpa vaarallisempia mukaan. Yksi helmasynti on mennä käsikirjan mukaan pitämään pystypalaverit aamuisin, iteroimaan vähän, ja keventää suunnittelua ja dokumentointia, kerätä kivoja velocity raportteja, ja kuvitella tekevänsä Scrummia. Kaikki nämä ovat hyvästä, mutta mikään niistä ei oikeastaan ole sellaista mitä ei voisi vesiputouksessakin tehdä, ja mikään näistä ei ole ohjelmiston tilaajan kannalta olennaista. Näitä usein tehdään koska ne on helppoa ottaa käyttöön, niihin ei liity muutosvastarintaa paljoakaan, ja eivät vaadi teknistä osaamista juurikaan. Kun hyödyt ja kustannukset laitetaan puntariin, molemmat ovat vähäisiä. Ei se Scrummia ole.

Oikea ketteryys hyökkää vaikeampien asioiden kimppuun, tässä pari oikean ketteryyden tunnusmerkkiä: Projekti toimittaa joka Sprintin aikana loppuun asti tehtyä, demonstroitavaa toiminnallisuutta jolla mennään eteenpäin. Näin säilytetään sitoutuminen, usko, visio ja mielenkiinto. Sovelluskoodi on kauttaaltaan testattua, ja testejä voidaan ajaa milloin vain, toistuvasti, koko ajan. Testikattavuutta ja testiraporttien historiaa voidaan helposti seurata. Testaus kattaa yksikkötestausta, integraatiotestausta, hyväksyntätestausta, ja suorituskyky-, kuorma-, ja toipumistestausta. Testit toimivat koodin dokumentaationa suurelta osin. Miksi näin ei tehdä? Tämä vaatii osaamista, ohjelmistoja, ja harjoittelemista ja soveltamista. Se on investointi. Investointi antaa takaisin varmuutta ja rohkeutta tehdä muutoksia ja korjauksia. Ääripäässä käytetään TDD menetelmää, joka ei ole enää testausta vaan suunnittelua, se ei siis ole testaajan osaamista vaan jokaisen tiimin sovelluskehittäjän. TDD on niin hieno ja monelle myös vaarallinen juttu että se taitaa ansaita joskus ihan oman artikkelin.

Kuulin muuten jenkkiprojektista jossa oli neljä sprinttiä vedetty läpi ilman että oli kertaakaan pystytty toimittamaan ulospäin yhtään mitään. Tässä kannattaisi ehkä vetää hätäkahvasta ja pistää homma seis ja tiimi opiskelemaan lisää. Ketteryys ei ole tekosyy osaamattomuudelle vaan se oikeastaan vaatii osaamista ja itseohjautumista. Se ei myöskään sovi kaikille.

Scrum ja kumppanit ei ole maaginen ratkaisu kaikkiin sovelluskehityksen kiputiloihin. Jos mitään, ne ovat välineitä joilla kivut pyritään nostamaan esille jotta ne voidaan ratkaista ja kehittyä.

4.Cowboy coding

Edelleen yksi kipeimpiä väärinymmärrettyjä ketteryysteemoja on sekoittaa ketteryys cowboy koodaukseen. Olen törmännyt joskus tilanteeseen missä tiimi iloisesti hyväksyy että dokumentointia vähennetään ja keskitetään, suunnittelua ei tehdä raskaasti etukäteen vaan matkan varrella, mutta on jätetty esim. testaus pois tai hunningolle tai projektityön jälkeiseksi ei-kuulu-meille asioiksi. Sitten alkaa cowboy koodaus: Tehdään suttuista spagettikoodia juuri tarpeeksi että saadaan ns ’happy scenario’ manuaalisesti testatuksi läpi, miettimättä virhetilanteita, uudelleenkäytettävyyttä, ylläpidettävyyttä, arkkitehtuuria, jne. Ketteryys ei ole tekosyy unohtaa näitä asioita, se vaatii osaamista pohjalleen. Muuten meillä on tiimi tuuliajolla ulapalla vailla suuntaa tai taitoja. Siitä ei ketteryydenkään nimessä hevillä selvitä.

Eli oikea ketteryys rakentuu kohtuulliselle osaamiselle ja riittävälle arkkitehtuurille. Itse suosin kovasti Architectural Spike termiä jossa tehdään kevyt arkkitehtuuri alussa jonka uskotaan riittävän projektin vaatimuksiin. Mieluiten pieni POC tueksi poistamaan tekniset riskit jos arkkitehtuuri on kovin uusi. Sen jälkeen astuu peliin Emergent Architecture jossa voidaan muuttaa arkkitehtuuria tarpeen mukaan. Käyttäisin tässä itse esimerkkinä Eiffel-tornin rakentamista ketterästi. Voi kokeilla rakentaa vastaavaa kapistusta metri kerrallaan ketterästi, oppien matkalla virheistä ja tehden aina paremmin, mutta mahtaako siitä tulla mitään? Olisiko sittenkin parempi alunperin karkeasti arvioida tornin korkeus, rakennusmateriaalit, tehdä pari lujuuslaskelmaa? Vai sopiiko ketteryys ollenkaan jos projektin muuttujat ovat jo tiedossa ja kokemusta on? Kuitenkin, spike vaihe ei pitäisi olla liian raskas, tai liian pitkä, muuten riskeerataan jatkuva toiminnallisuuden toimitus ja sitä myöden sitoutuminen.

Pelkkä emergent design ei mielestäni riitä, vaan alkuarkkitehtuurin tulee olla riittävä että sillä voidaan edetä jonkin matkaa ja että se ei välittömästi mene uusiksi. Muuten haaskataan taas aikaa ja energiaa. Good enough siis.

5. Tuuliajolla muuttuvien vaatimusten kanssa

Vielä yksi väärän ketteryyden tunnusmerkki joka tulee mieleen on product ownerin kykenemättömyys sitoutua mihinkään suuntaan. Ideana olisi kuitenkin edetä kohden visiota, vaikka yksityiskohdat voivat muuttua. Jos hankkeella ei ole visiota tai matkan varrella se muuttuu rajusti, tulee aika kallis hanke jonka tyytyväisyys ei ehkä ole huippuluokkaa. Tämä vaatii ammattitaitoa ostajalta, product ownerilta, mutta tarpeen vaatiessa myös Scrum masterilta. Vastuu onnistumisesta on yhteinen, ja jos muutos itsessään muodostuukin riskiksi, sitä pitäisi hallita iteraatioissa.

Eli pähkinänkuoressa:  Väärän ketteryyden tunnusmerkkejä ovat:

– hallitsematon muutos

– vajavainen tai puutteellinen testaus

– puutteellinen arkkitehtuuri

– puutteellinen visio

– kyvyttömyys sitoutua ketteryyteen työtapana

Tässä oli omia näkemyksiä siihen miten niitä voisi korjailla, mutta meikäläisen näkemykset eivät ole tärkeitä. Se mikä on tärkeää on oma halu kehittyä ja olla taitavampi joka päivä.

Ja tässä piti tietysti puffata tätä uutta kurssia, mutta enpä puffaisi sitä ellen uskoisi että se on hyödyllinen 😉  Sitäpä ei enää tälle vuodelle ehtinyt toteuttaa, mutta ensi vuosi on uusi vuosi ja uudet kujeet.

http://www.tieturi.fi/kurssit/kurssi.html?course=83904030&category=Ketteryys%2B%2528Agile%2529&city=Helsinki&training=21.03.2012

Ja tietysti muita ketteriä koulutuksia:

http://www.tieturi.fi/kurssit/koulutus.html?&category=Ketteryys+%28Agile%29

 

Tiedätkö jotain muita ketteryyden sudenkuoppia? Aihe on kiinnostava ja siinä on kehittymisen varaa. Blogihan on siitä kiva että sitä voi helposti kommentoida.

JFokus 2/4 – tarinoita Tukholmasta

No niin, edelleen ollaan siis Tukholmassa ja JFokus konferenssissa. Osallistujia täällä on hieman yli 1100, joista se satakunta tuli Suomen puolelta aamulautalla.

Aamun avasi räväkästi Henrik Ståhl Oralelta, ja mitä keynoteihin tulee tämä oli piristävää vaihtelua. Henrik puhui Oraclen ahneudesta ja arvosteli Oraclen toimintaa Machiavellin silmin 😉 Toden sanoakseni esitys oli hyvin huumoripitoinen, yllättävänkin suora ajoittain, ja siinä vastattiin taas hyvin kysymyksiin joita Java kehittäjät ovat pohtineet ja myös julkisesti ruotineet. Javan ja Oraclen näkymiä luotailtiin kolmesta näkökulmasta: Niccolo Machiavellin, Duken, sekä rahan jumalan Mammonin.

Machiavellillä on muuten ollut jo aikanaan PR puoli hyvin hallussa, monet viisaudet pätevät (entistä enemmän) tänä päivänä. Pelottavaa.. Oli miten oli, aamu oli kiintoisa ja rentouttava. Esityksen lopussa tuli myös esille roadmap ajatuksia aina Java 9:ään asti. Nyt kannattaa kaikkien kynnelle kykenevien pistää ehdotuksia HotSpot + JRockit JVM yhdistelmän nimeksi, tai muuten sen nimeksi tulee Fusion JVM 😉

Esityspuolelta mieleen jäi Oraclen standin Brainwaves peli jossa piti aivonsa alfa aallot rentouttamalla saada kuula leijumaan ilmassa mahdollisimman pitkään. Tiedä sitten onko hyvä asia mutta kun pistin anturit päähäni kuula pomppasi melkein samantien kattoon, liekö sitten tuo aivojen tyhjentäminen vahva puoleni. Valitettavasti kuulan liikkeistä innostuminen toi aktiviteetia ja tipautti kuulan maahan. Paikallinen ennätys oli 22 sekuntia leijuntaa (eli tyhjä pää), ja kuulemma joiltakuilta onnistuu pari minuutiakin. Itseä kun nuo UI puolen asiat aina kiinnostavat, ja kun en usko että monitori, hiiri ja näppäimistö on se lopullinen ratkaisu tietokonetta käskyttäessä, niin tällaiset poikkeukselliset ratkaisut kiinnostavat. Tuossa linkit vielä Neurosky laitteeseen ja yleensä aiheesta: http://www.neurosky.com/ http://gajitz.com/mind-games-four-games-you-control-with-your-brain/

Brainwaves anturien oikea käyttö on liikkumisrajoitteisten ihmisten käyttöliittymissä, ja keskittymällä kuulaa pystyikin ohjaamaan. Kontrolli oli vielä omasta yrityksestä kaukana mutta eiköhän tuossa muutamassa päivässä olisi jo vauhdissa. May the Force be with you!

Sieltä sitten takaisin maan pinnalle. Eric Evans puhui ketterästä DDD:stä, Domain Driven Developmentista, ja sen sudenkuopista ja parhaista käytännöistä. Toistuvana kaavana suomalaisten firmojen kanssa olen aika ajoin kuullut miten ketteriä menetelmiä kuten Scrum:ia kirotaan alimpaan manalaan ja haukutaan miten ne eivät toimi. Useimmiten kun kuulen tällaista ja kyselen lisää, selviää kaksi asiaa aina toistuvasti: 1) Projektissa ei olekaan Product Owneria ja piirteiden priorisointia, vaan kyseessä onkin Scrummerfall eli on tehty speksit, on tehty suunnittelu alussa, ja sitten ohjelmoijatiimille sanotaan että olkaa ketteriä. Ja 2) on aamupalaverit ja iteraatiot, mutta toteutuksen osalta on lähinnä omaksuttu että ei suunnitella, eikä dokumentoida varsinkaan, eli jätetään suunnittelu ja testaus kokonaan pois iteraatiosta ja hakataan vain päätä seinään tekemällä lyhytnäköistä koodia jota ei ehditä saamaan iteraatiossa edes valmiiksi. Tässä esityksessä ei suoranaisesti menty Agile menetelmiin tai prosesseihin, vaan käytiin läpi miten DDD:tä voi tehdä hyvinkin luonnollisesti keskustelujen kautta.

Tähän väliin hieman kehuja Vaadin frameworkille tehdystä seminaarin aikatauluohjelmasta, ainakin vielä osoitteessa http://www.jfokus.se/jfokus/page.jsp?id=vschema ja http://code.google.com/p/devoxx-schedule-2010/ – varsin näppärä ja toimiva kontrolli ja sovellus. JFokushan fiksusti julkaisi REST rajapinnat joilla seminaaritietoja saa esille.. Ihan piruuttani koodasin itsellenikin niiden varaan Android mokkulan, joskin jaossa oleva virallinen versio on huomattavasti parempi. Mutta oma on aina oma vaikka onkin ruma.

Hupaisa yksityiskohta: IPhonellekin oli tehty seminaarisofta, mutta se ei ole ehtinyt hyväksyntäprosessien läpi vielä joten iPhone mistajat… sorry! 😉 Henrik Ståhl muuten lipsautti aamun keynotessaan miten Javan tavoite on pyöriä myös iPhonessa tulevaisuudessa, saapa nähdä oliko tässä konkretiaa vai unelmointia..

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

Maven ja Artifactory

Mavenin kanssa peuhatessa tuli mieleen halu pystyttää oma repository Mavenille. Tähän on monia syitä.

Oma repository toimii kätevästi proxynä julkisille repositoryille: kun lataat sen kautta pluginit, ne täytyy ladata vain kerran, ja sitten ne löytyvät läheltä paikallisesti, vaikka koko tiimille tai yritykselle. Kun internet on epävarma nykyisellään aika ajoin, ja kun maven central repositoryt kuten repo1 ovat ylikuormitettuja, tämä voi pelastaa päiväsi.

Toinen syy on tietysti että on mukavaa kun maveniä käyttäessä on julkaisuja varten oma tiimirepository, jossa valmiita snapshot ja muita releaseja voi jaella. Voittaa levynnurkan!

Vertaillessa eri vaihtoehtoja esiin nousi selkeästi kova repository nimeltä Artifactory – sitä löytyy tuen kera kaupallisena, ja avoimen lähdekoodin community editiona. Asennus on helppo: lataat zipin, purat sen haluamaasi paikkaan, ja ajat bin-kansiosta artifactory.bat:in – tai sh:n.

Mitäs sitten? Nyt olisi repository pystyssä, ainakin hetken. Pidemmäksi aikaa sen saa päälle asentamalla sen serviceksi. Tätä ennen on kuitenkin myös syytä asettaa ARTIFACTORY_HOME ympäristömuuttuja, osottamaan johonkin sopivaan olemassaolevaan kansioon. Muuten artifactory luo asetukset ja muut käyttäjäprofiilisi alle. Kun olet tyytyväinen artifactoryn toimintaan, löytyy bin-kansiosta ytimekäs installservice.bat jolla saat ratkaisun pyörimään windows-palveluna (Linux käyttäjät, sorry, joudutte järkeilemään tämän itse, kun omassa koneessani on vain windows 7. Olisiko apua install.sh scriptistä? 😉

Seuraavaksi on syytä kertoa Mavenille että käyttää kaikkiin pyyntöihin vain ja ainoastaan tätä omaa artifactory repositoryä. Tämän voi tehdä käyttäjäkohtaisessa settings.xml tiedostossa profiilien alla, mutta varmaan helpointa on lisätä pom.xml tiedostoon jotain tämäntapaista:

<repositories>
  <repository>
    <id>central</id>
    <url>http://http://localhost:8081/artifactory/repo</url>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </repository>
  <repository>
    <id>snapshots</id>
    <url>http://http://localhost:8081/artifactory/repo</url>
    <releases>
      <enabled>false</enabled>
    </releases>
  </repository>
</repositories>
<pluginRepositories>
  <pluginRepository>
    <id>central</id>
    <url>http://http://localhost:8081/artifactory/plugins-releases</url>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </pluginRepository>
  <pluginRepository>
    <id>snapshots</id>
    <url>http://http://localhost:8081/artifactory/plugins-snapshots</url>
    <releases>
      <enabled>false</enabled>
    </releases>
  </pluginRepository>
</pluginRepositories>
Ja tuossapa tietysti pidemmän päälle localhostin tilalle todellinen palvelinosoite kun saat sen pysyvämmin pystyyn. Tämä ylikirjoittaa mm. central repositoryt siten että aina mennään artifactoryn kautta. Lisäksi voisit vielä pistää settings.xml tiedostoosi tällaisen:
<mirrors>
  <mirror>
    <id>artifactory</id>
    <mirrorOf>*</mirrorOf>
    <url>http://localhost:8081/artifactory/repo</url>
    <name>Artifactory</name>
  </mirror>
</mirrors>

Ehkä ekstravarovaisuutta – mutta tuo tekee kaikkien osoitteiden eteen taas mirrorin joka menee artifactoryn kautta. Nyt voit kokeilla ottaa käyttöön uuden pluginin ja seurata mavenin log-viestejä: Pyynnöt menevät nyt artifactory proxyn kautta.

Vaihe 2

Kun haluat julkaista tuotoksesi artifactoryyn oman levyn sijasta voit lisätä pom.xml tiedostoon nämä tiedot:

<distributionManagement>
  <snapshotRepository>
    <id>asantala_w7</id>
      <name>asantala_w7-snapshots</name>
      <url>http://localhost:8081/artifactory/libs-snapshots-local</url>
  </snapshotRepository>
  <repository>
    <id>asantala_w7</id>
    <name>asantala_w7-releases</name>
    <url>http://localhost:8081/artifactory/libs-releases-local</url>
  </repository>
</distributionManagement>

Selvää kuin pässi, eikö? Säädämme siis julkaisu-repositoryksi snapshoteille ja aidoille julkaisuille Artifactoryn. Nyt voit tehdä esim.

mvn deploy

Ja katsoa miten projekti paukkuu paikalleen. Repository hallinnasta voi katsella miten omat tuotokset ja proxyn kautta ladatut plug-init siellä muhivat. Jos repository vaatii autentikointia, voit vielä lisätä settings.xml:ään määrityksen em servereille. Tarkista että serverin id täsmää edellämainittuihin säätöihin, ja aseta tunnus ja salasana siten miten olet ne artifactoryssä säätänyt (ethän käytä oletussalasanoja missään palvelimessa, ethän…?)

<servers>
  <server>
    <id>asantala_w7</id>
    <username>admin</username>
    <password>password</password>
  </server>
</servers>

Ensi jaksossa kirjailen siitä miten Maven, Subversion, Artifactory ja SCM plugin ja Release plugin toimivat yksiin – jotta saat automaattisesti snapshoteista julkaisuversioita ja versionumeroita päiviteltyä ilman että täytyy käsin muutella POM tiedostoa joka kerta. Tämä on Maven 2:sen uusi ominaisuus.