Patterns vs. innovation, Arkitektur vs. agile udviklingsmetoder
Efter en dags tutorial med Frank Buschmann og Kevlin Henney er der to diskussioner, som står stærkest i min hukommelse.
Den første er jeg rimelig afklaret omkring. Det drejer sig om at man ikke får innovation ud af at bruge design patterns - at bruge en opskrift giver den samme kage hver gang, og dermed er der ingen innovation.
Lige præcis opskriftsanalogien gør at jeg ikke tror på den. Alle som har bagt en kage ved at man kan få både en god og en dårlig kage ud af den samme opskrift og nogen gange kan man give sit eget lille pift til opskriften og få noget helt fantastisk (det gør min kæreste i hvert fald ofte - madlavning er ikke lige mit domæne, så jeg har ikke førstehåndserfaring). Min konklusion er altså at brug af design patterns ikke udelukker innovation. Hvad siger du?
Den anden diskussion var den jeg lærte mest af i løbet af dagen, nemlig er det muligt at integrere en god designprocess i et agilt projektforløb? Jeg har set utrolig mange, der opfatter agile udviklingsmetoder, som en fritstillelse fra arkitekturelle overvejelser - det er jo ikke agilt og iterativt, hvis man sætter sig ned og laver en fornuftig arkitektur først. De projekter jeg har set, der har brugt en agil udviklingsmetode har levet med de arkitekturer de tilfældigvis er endt med uden nogensinde at redesigne det, når de er blevet klogere.
Her havde Henney og Buschmann et andet svar. De snakkede om iteration 0, hvor man laver en oprindelig simpel arkitektur, som man godt ved efterhånden bliver utilstrækkelig. Herefter arbejder man i korte iterationer, som vi kender dem fra agil udvikling med test først, morgenmøder og så videre og hvis en af udviklerne melder tilbage at han har et problem med arkitekturen, så holder man et redesignmøde og får lavet de ændringer, som kommer fra at man nu er blevet klogere. Og faktisk støtter agile udviklingsmetoder op omkring arkitekturredesign, fordi man har masser af test til at verificere, at man ikke knækker koden ved redesignet.
Selvfølgelig er det stadig en afvejning, hvor meget forarbejde man laver i forhold til at man ikke skal overdesigne en avanceret arkitektur, men heller ikke ende med spaghettikode. Arkitektur er svært.
Hvad siger dem med konkret erfaring med agile udviklingsmetoder udenfor undervisningslokalet' Er der nogle gode tricks til at få en tilstrækkelig god arkitektur' Eller er det nødvendigt at ignorere designet, når man bruger agile udviklingsmetoder? Som Onkel Bob sagde "First make it work - then make it right - then make it fast".
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
