OSLO/MYRENS VERKSTED (digi.no): Drøyt ti år etter at det berømte manifestet ble nedfelt er ikke smidig eller agile utviklingsmetodikk lenger et moteord.
Smidige metoder som Scrum har for lengst etablert seg som den nye gullstandarden innen programvareutvikling. Kort fortalt handler det om å dele prosjekter inn i etapper som kan settes i produksjon fortløpende, i og kontinuerlig og nær kontakt med brukerne av systemene.
Det glemtes kunst
Simon Brown mener problemet nå er at pendelen har svingt for langt. Viktige ingeniørprinsipper er glemt i iveren etter å jobbe smidig. Han er bekymret over utviklingen, og frykter at programvaren som utvikles har blitt mindre solid de siste årene.
_logo.svg.png){kind=logo}
– Mange er for opptatt av å levere nye funksjoner og tenker i for liten grad på arkitektur, sier den britiske IT-konsulenten og kursholderen til digi.no.
Selv har han femten års fartstid som utvikler og teknisk prosjektansvarlig, og er hanket inn som ekspert på området av Bouvet. Foruten kursing hjemme i London, flyr han ofte til Norge for å lære opp både deres og konkurrentenes utviklere.
- Han har truffet en nerve i IT-bransjen. Kursene hans er svært populære, sier avdelingsleder Simen Sommerfeldt i Bouvet.
Ifølge Brown er det to viktige risikoer ved ikke å tenke arkitektur i smidige prosjekter.
– Det første er at utviklerteamet ikke sørger for et solid fundament. Jeg har sett flere eksempler på de som endrer arkitekturen underveis, og bruker mer tid på det enn å levere ny funksjonalitet. Det forteller meg at balansen er feil.
Den andre faren han påpeker gjelder mindre erfarne utviklerteam, som forsøker å være smidige, men går glipp av vesentlige forhold underveis.
– I team med mindre erfaring er det en tendens at folk ender opp med å jobbe i siloer. Hvem sørger for å holde orden på helheten? Noen ganger vil sikkerhet, ytelse, skalerbarhet, alle ikke-funksjonelle egenskaper ved prosjektet lide som følge av dette.
Det gjelder å legge til en rolle som har et overordnet teknisk ansvar. Denne rollen kan ikles en person, noe som gjerne er en fordel i mer kaotiske prosjekter. Eller rollen kan deles i bevisstheten blant deltakere i mer selvorganiserende grupper, sier han.
Å bygge arkitektur inn i smidige prosjekter er ifølge Brown ikke det samme som å gå tilbake til den gamle fossefallsmetoden – med en lang analysedel i forkant av arbeidet som skal gjøres.
– Å kunne arkitektur-håndtverk samtidig som du kan smidige teknikker gjør deg i stand til å vurdere hva som er riktig å gjøre i hvert tilfelle - å hente de rette verktøyene opp fra verktøykassa når du trenger dem. Du kan ikke stole blindt på hva en guru har sagt i et seminar eller en bok. Du må tenke selv!
– Agile var en reaksjon på en oppsvulmet og for tung arkitekturtenkning. Vi ønsker oss ikke tilbake til gamledager, men prøver å finne en mellomvei, fremholder Brown.
– Løsningen er å introdusere arkitektur-prinsipper inn i en smidig setting. Det er det han forsøker å lære bort, skyter Bouvets Simen Sommerfeldt inn.
Deler av verktøykassen hentes fra kunnskap som tidligere var en naturlig del av informatikkutdannelsen: Prosessrammeverket RUP (Rational Unified Process), som ifølge Sommerfeldt dessverre ingen lærer lenger.
– RUP har arkitektur og risikoreduksjon i kjernen. Det handler om å avdekke hva hovedrisikoene dine er, redusere dem og gå videre. Men RUP har gått av moten fordi folk tror det er for stort og tungt. I dag fokuserer man på ren kode, DDT (design driven testing) og alle moteordene man hører rundt smidig, men de kikker ikke på tingene man lærte før i tiden. Derfor sliter folk nå med arkitektur i smidige prosjekter, sier Brown, og fortsetter.
– Det er ikke ønskelig å bruke et halvår på arkitektur, og deretter begynne med smidig. Vi må forsøke å mikse dem. Det handler om å gjeninnføre noen av ingeniørteknikkene.
– Hvordan bygger du arkitektur inn i smidige prosjekter?
– Det må være akkurat nok. Det handler om at teamet må ta et bevisst valg og identifisere hvor mye de er nødt til å gjøre. De må typisk kikke på hvor kompleks en løsning er, hvor erfarne teamet er, hvorvidt det er kompliserte ikke-funksjonelle krav, for eksempel høye krav til sikkerhet. Det handler også om å legge ned en visjon. Alle som utvikler sammen må ikke nødvendigvis bidra til visjonen, men de må forstå den. Det er en avgjørende del av arkitekturrollen. Jeg er en sterk tilhenger av at dette kan gjøres på en enkel måte, som likevel matcher smidig utvikling bra, sier Brown.
Bouvet trekker frem to hoveddeler når vi spør hvilke RUP-teknikker han henter fram.
- Analysen av høyrisikokravene, og hvordan en lager en «proof-of-concept» som gjør prosjektet i stand til å teste ut om de kan kjøre opp dette i stor skala og samtidig klare kravene. Dette vil også føre til at estimatene blir mer treffsikre.
- Han fokuserer på modelleringsteknikkene og metodene – som igjen ofte er forskjellige UML-modeller (Unified Modeling Language). UML er et kraftig kommunikasjonsmiddel fordi skjemaene har en utvetydig betydning. Mange lager bare bokstegninger i dag. Dersom det kommer nye folk inn på prosjektet klarer de ikke å forstå dem fordi notasjonen er tilfeldig.
Dyrt å spare seg til fant
- Planlagt arkitekturarbeid kan virke fordyrende ved første øyekast, men vil lønne seg i det lange løp. Dårlig fundamenterte prosjekter vil forsinkes fordi de feiler når de skal settes i drift. Som Tom Gilb sier: Hvis du ikke aktivt angriper risikoene først, vil de de aktivt angripe deg siden, avslutter Simen Sommerfeldt.
Les også:
- [29.11.2011] Jobber med smidig-avtale
