Dette indlæg er alene udtryk for skribentens egen holdning.

Patterns vs. innovation, Arkitektur vs. agile udviklingsmetoder

28. september 2007 kl. 01:4010
Artiklen er ældre end 30 dage

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.

Artiklen fortsætter efter annoncen

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".

10 kommentarer.  Hop til debatten
Denne artikel er gratis...

...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.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
14
4. oktober 2007 kl. 10:50

Uvidende omkring agile development mener jeg at kunne læse af debatten, at "Jo færre variabler, der er omkring det område indenfor hvilket man skal lave en løsning, jo bedre egner agile sig".

...men hvordan er en praktisk tilgang til agile development hvis opdraget er at lave en enterprise løsning der fordrer at løsningen skal indeholde en masse "-ilities" ? (se http://en.wikipedia.org/wiki/Ilities). -ilities har det ofte med at være uforanderlige størrelser/kvaliteter til enhver løsning der skal bygges. Her mener jeg, at Iteration 0, eller 0-- er påkrævet...

13
4. oktober 2007 kl. 01:19

Fornuftig tilgang med en simpel prototype til at vise en pointe og give et simpelt estimat.

Det kan til tider undre mig at it-branchen kan fungere med det niveau af tillid, som der er nødvendigt på de fleste niveauer.

Jeg har kigget lidt på begrebet "Planning Poker" http://en.wikipedia.org/wiki/Planning_poker i den sidste tid og jeg er lidt skeptisk. På JAOO fortalte Henrik Kniberg om undersøgelser, som viste hvor nemt det var at påvirke estimater, så de kom til at svinge fra 100-400 timer bare ud fra en enkelt bemærkning på forhånd. Men det er måske et generelt problem - altså at hvis man ved lidt om hvad kunden eller andre mener opgaven skal koste/skal tage af tid, så bliver man påvirket?

10
1. oktober 2007 kl. 00:19

Jeg kan se på dit indlæg, at vi er enige :-).

Jeg synes, det er spændende at høre om de modstridende kræfter i, at man ikke kan fuldstændigt definere et færdigt produkt fra starten og de 3 punkter du nævnte tidligere, at kunden vil have på plads tidligt i projektet:

  1. Scope
  2. Pris
  3. Deadline

På din blog skriver du jo netop, at kunden ikke ved hvad hun vil have, og altså kan 1. vel ikke fastlægges på forhånd. Dermed vil det vel følge at 2. og 3. bliver umulige at fastlægge.

Hvad gør man så? Vil man i praksis vurdere et projekt ud fra faste antagelser om en statisk verden? Tager man og ganger sine estimater med pi, phi eller e :-)? Hvad gør man for at få realistiske estimater? Hvordan deler man den endnu ikke definerede elefant op i mindre dele?

8
30. september 2007 kl. 02:07

Hej Jakob.

Rart at få bundet nogle konkrete erfaringer på diskussionen. Jeg har lige et spørgsmål til din sidste pointe med de frie rammer, som ikke fungerer i den virkelige verden, hvor ressourcerne og tiden ikke er uendelig.

Jeg har altid været lidt på vagt overfor at folk mener at agile udviklingsmetoder er "frie rammer" - for mig har projekter udviklet agilt krævet meget mere disciplin end at bruge vandfaldsmetoden. Det kræver kommunikation i liberale mængder, tilbageblik/retrospectives (for at fastholde det lærte i hver iteration) og disciplin i udviklingsprocessen med test-først-udvikling.

Er der ikke netop en masse mekanismer i de agile udviklingsmetoder, som tager højde for ressourcer og tid?

Arbejdsopgaverne prioriteres med de vigtigste først og hvis der så ved deadline er noget som ikke blev implementeret, så var det ikke vigtigt nok til at blive prioriteret. I vandfaldsmodellen ville man måske nok have nået til at implementere en oprindelig feature uden at vurdere om den var vigtig nok i forhold til de andre arbejdsopgaver (og evt. på bekostning af vigtigere features, som man ikke kunne forudse (på designtidspunktet) ville være vigtige). Jeg tvivler på, at man når længere i et projekt i vandfaldsmodellen end med en iterativ, agil proces.

Når det så er sagt, så er det under antagelsen af at hver udvikler koncentrerer sig om de konkrete opgaver og undgår "gold plating" og fokusering på egne kæpheste.

Jeg har også altid undret mig over at folk forbinder agile udviklingsmetoder med kaos i koden og at "hakke noget kode sammen hurtigt". Det er jo netop det test-først og parprogrammering skal undgå. God kode er der tænkt over på forhånd (da man skrev testen) og den er blevet kommunikeret og reflekteret over af flere.

Jeg har en enkelt gang prøvet at kode på storskærm med hele projektgruppen som publikum og der blev fanget mange fejl og overvejet mange løsningsmuligheder. Og så var det underholdende og gav fælles ejerskab over koden. Jeg er godt klar over at det ikke er muligt i hverdagen, hvor man skal være effektiv hver for sig, men det er en rigtig god måde for uerfarne udviklere at få noget feedback på deres kode og dermed blive bedre. Og det virker også godt mere flere uerfarne udviklere i gruppen - alle har jo deres styrker.

Men det var vist et sidespor :-)

7
30. september 2007 kl. 01:30

Jamen er det ikke netop den agile tankegang - at man laver en arkitektur, som passer med de krav man kigger på i den aktuelle iteration (evt. koblet med den viden man har om hele systemet på daværende tidspunkt) og så refaktoriserer, når man er blevet klogere? At man ikke bruger lang tid til at finde en arkitektur, der passer på alle tænkelige og utænkelige situationer, men løser opgaven ud fra første bid af elefanten og så redesigner, når man har defineret den næste bid og der er noget der mangler? (og dermed undgå "gold plating").

6
28. september 2007 kl. 14:49

Der er sagt meget om design patterns, men at de ligefrem skulle stå i vejen for innovation (troede kun det var marketingsfolk der brugte dette ord) har jeg godt nok ikke hørt før. At stille dem overfor hinanden er absurd. Design patterns udgør jo normalt kun en flig af et system, og man kan da sagtens være innovativ samtidig med at man bruger nogle kendte metoder. Hvorfor opfinde den dybe tallerken hver gang? Når du skal sortere en liste udvikler du vel heller ikke en ny algoritme hver gang? At du bruger en kendt algoritme er vel ikke udslagsgivende for om dit system er innovativt eller ej?

5
28. september 2007 kl. 11:21

Hej

Jeg tror at det kommer helt an på den opgave der skal løses. Hvis der udvikles imod et stort systemkompleks, hvor der indgår mange lag i infrastrukturen, er det nok en dårlig ide at håbe på at arkitekturen opstår af sig selv. Der skal man nok lave en iteration 0.

Hvis detderimod er en enkelt stående applikation som skal køre på sin egen server, er der nok ikke behov for arkitekturovervejelser men man kan tage det mere hen ad vejen efterhånden som problemerne opstår.

3
28. september 2007 kl. 08:43

Jeg forstår ikke hvorfor man stiller disse to udviklingsmetoder op imod hinanden. Min erfaring er at det som er mest effektivt er at blande metoderne. Tømre man en fast struktur sammen, så er risikoen at man finder ud af at man har tømret forkert og må begynde forfra. Bygger man ud i det blå og bliver ved med at udbygge og ændre strukturen, så er risikoen at man mister overblikket, og aldrig bliver færdig. Jeg tror at man bliver nødt til at erkende at software arkitektur/struktur meget sjældent er noget som man kan overskue fra starten. Man må lægge ud med et bud på en arkitektur og så må man være klar til at tilpasse og tænke om, når der opstår nye udfordringer.

2
28. september 2007 kl. 08:14

Pudsigt sammenfald. Blev den anden dag gjort opmærksom på nogle (andre) fyre fra Siemens som løst definerer forskning som det at transformere penge til viden og innovation som det at transformere viden til penge. For mig er patterns lig viden, og de kan derfor - hvis man køber definitionen - være ganske nyttige ifbm. med innovation.

1
28. september 2007 kl. 08:03

En af grundelementerne er at man ikke får stykket en arkitektur sammen, som afgrænser mulighederne fremover. Mary Poppendieck har udtrykt som "The last responsible moment" i hendes bog om Lean Software development.

Min personlige oplevelse er at transitionen fra vandfaldsmetoden til en agil process er krævende for udviklere. Primært fordi man skal vænne sig til at man ikke længere har det store gyldne design at implementere. I stedet man skal være villig til at ændre den implementering man en gang har lavet på et område, fordi designet ikke længere holder til det det skal kunne klare.

Med frekvente iterationer bliver dette dog nemmere, fordi man ikke skal trevle et halvt eller helt års udvikling op men kun 2 måneder, alt efter hvordan man har strikket sin proces sammen.

/Søren