Hej alle

Jeg kunne godt tænke mig at høre lidt fra folk med erfaringer med samspillet mellem agile udviklingsprocesser og design og arkitektur. Jeg arbejder til dagligt med SCRUM, men jeg har også en stor interesse i arkitektur og design af systemer. Jeg har fundet, at arkitektur og agile udviklingsprocesser ikke harmonerer alt for godt. Det er et problem, da vi som udviklere og arkitekter risikerer at levere systemer af ringere kvalitet end vi har lyst til.

Nu er agile processer jo meget oppe i tiden, og de er ikke bare en døgnflue. Og ja, at udvikle agilt gør os mere produktive. Jeg kan se en tydelig forbedring i min egen, og teammedlemmers performance, i de 8 år jeg har arbejdet i branchen, siden jeg begyndte at arbejde med SCRUM. Men vi skal passe på, at performance ikke bare måles på function points, eller endnu værre: lines-of-code. På kort sigt er det fint nok, men hvad når systemet bliver "voksent"? Når det skal vedligeholdes og udvides på sigt? Hvad med de gode, gamle kvalitetskriterier?

Min frygt, og også min erfaring efterhånden, er, at vi giver køb på kvaliteten til fordel for umiddelbar (udviklings)performance; det er alt for nemt at fokusere på det indeværende og næste sprint, men så ikke længere. SCRUM er en letvægtsproces. Yes, men problemet er, at den kan være for letvægt; det er meget svært at overbevise product owners, kunder, teammedlemmer, og sig selv(!) om, at vi er nødt til at fokusere på de mere langsigtede ting i et projekt. Alt for ofte griber jeg mig selv i at frygte langtidskonsekvenserne af de valg jeg træffer, idet de som regel er taget på et alt for løst grundlag - vi fokuserer jo kun på det næste sprint.

Og for lige at komme et par kynikere i forkøbet, så er det nemt nok at sige "Nu skal vi altså afsætte noget tid til det her arkitektur-halløj". Men på mit nuværende projekt har vi prøvet det, og det er meget hurtigt røget i glemmebogen igen (det tog nøjagtigt et enkelt sprint). Disse ting jeg bekymrer mig for, er heller ikke noget man bare lige kan afsætte tid til på planen, og så er den i skabet.

Nu skal det her indlæg ikke tages som en kritik af agile processer. Jeg er meget glad for at arbejde med SCRUM, men arkitekturovervejelser og fokus på fremtidige problemstillinger ligger bare meget indgroet i mig,; vi er jo alle interesseret i at give vores kunder/bruger noget for pengene, og jeg har alt for ofte set hvad der sker med projekter, hvor man "glemmer" at se ud over den umiddelbare fremtid. Det kan vi ikke være bekendt over for kunder og brugere, og IT-branchen kan risikere at ende i en dybere krise end hidtil.

Så jeg vil meget gerne høre nogle erfaringer fra folk, der arbejder både med agile processer, og med arkitektur og de mere langsigtede konsekvenser af designvalg i forbindelse med disse processer. Ja, i det hele taget er det her indlæg ment som et oplæg til debat, og et lille opråb til IT-folket.

Therese Hansen

Dette er netop også noget af det som jeg har overvejet. Jeg har indtil nu kun kørt 2 projekter efter agile metoder og i det ene havde vi review af arkitekturen i hver iteration, men det kan næppe være optimalt for større projekter.

Jeg skrev lidt om det her på version2 efter JAOO-konferencen http://www.version2.dk/artikel/4242 (undskyld det lidt rodede indlæg - det er meget svært at få overskud til at skrive mens man er på konference :-)) - kommentarerne er nok det mest interessante at kigge på.

  • 0
  • 0
Glenn Petersen

Hej Alle

Jeg holdt et indlæg på "Agile i praksis" - en konference afholdt af Dansk IT, hvor jeg var blevet inviteret til at snakke om Agile Arkitektur!

Umiddelbart er der, som der skrives, en modsætning mellem en defineret arkitektur (architecture by design) og den måde, som f.eks. XP i det mindste opfattes (architecture by evolution).

Mange af os har nok oplevet, at den gode arkitektur er blevet nedprioriteret til fordel for forretningsmæssig værdi - nu!

Men så kom jeg under mine forberedelser til at tænke på et besøg hos Systematic i Århus for nogle år siden. De formår at kombinere det at være CMMI niveau 5 certificeret med at benytte Agile metoder som SCRUM og Lean.

Min konklusion var:

"Man får først for alvor noget ud af at være Agile, hvis man har styr på sine processer".

Det, jeg mener, er, det selvfølgelig går galt, når man sætter 8 tilfældige udviklere sammen i et rum og giver dem besked på at køre XP.

Grunden til, at det kan lade sig gøre hos Systematic er netop, at de har fuldstændig styr på sine processer og sin arkitektur. Så når de sætter 8 udviklere ind i et projektrum, ved projektdeltagerne præcis, hvordan de skal udvikle, hvilke artifakter, der skal produceres, og hvordan arkitekturen skal se ud. Derfor kan de koncentrere sig om funktionaliteten sammen med deres on-site customer.

Hvis man vælger at implementere Agile metoder i en virksomhed, er det derfor mit råd, at man FØEST skal få styr på sine processer og sin arkitektur. DEREFTER er der meget at hente ved at indføre XP, SCRUM, Lean m.m.

Med Venlig Hilsen Glenn Petersen, Partner i 7N

  • 0
  • 0
Kurt Frederichsen

Frank, du mener lidt filosofisk tilgang gør det - men du har selv et indlæg, hvor du påpeger at vi mentalt har svært ved at slippe gamle vaner - mon ikke det kræver mere end en filosofisk indgangsvinkel at ændre mennesker?! ;-)

Orgnaisationer der er modne - dvs. ved hvad de vil og kan gøre det - de rigtige kompetencer og færdigheder - tid, lyst, vilje og ledelse af forandring - og så lidt værktøjer, vil nok hjælpe lidt mere! ;-)

  • 0
  • 0
Frank Vilhelmsen

Ja hvad er det jeg mener Kurt?

Desværre tror jeg du har ret i at vi mennesker evner at holde fast på vor metoder og at vi nødigt slipper den arbejdesmetode hvori vi føler os trykke. Lad os se det i øjnene, kun få mennesker evner at adoptere den adrætte arbejdsmetode. Langt de fleste projekter jeg har været i forbindelse med hvori agile principper har været inddraget, har det kun været med et begrænset subsæt at det agile framework, om man vil.

Efter min mening handler ikke ikke så meget om at benytte SCRUM, XP og andet men mere om selve tankesættet bagved og hvordan det føles for den enkelte i processen. Jeg tror desværre at mange af os benytter de adrætte ord og værktøjer uden rigtig at vide hvad de betyder og hvilken tanker som ligge bag.

Til gengæld, hvis det føles rigtig, kræver det at være adræt ikke andet en en blyant.

Om det kræver de rigtige kompetencer er jeg ikke så sikker på. Jeg har set mennesker overraske totalt men jeg har også set det modsatte. På et projekt fik jeg spørgsmålet: Skal man være dygtig på et agile projekt? Og svaret er vel at der bør være dygtige folk på alle projekter. Og her ligger svaret også på at have styre på sine processer.

Lyst og vilje er nøglefaktorer :-)

  • 0
  • 0
Nicolai Buch-Andersen

Frank, jeg er meget enig i det du siger. Jeg forsøgte selv at sige noget lignende i tråden "Hvad er agil udvikling?" Og det ser ud til at Kent Beck er enig med os :)

Her er et citat fra et interview jeg fandt på InfoQ (http://www.infoq.com/interviews/beck-implementation-patterns):

"I think the easy part of XP is practice related, but there is 3 legs on the stool: practices, values and principles and I think people who are successful applying XP are paying attention to all 3. This gets back a little bit to some of my disenchantment with the direction of agile development in general, people are now asking the question: "How am I going to do agile development?" and agile development isn't a thing you do, it's an attitude, it's a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.

That is agility. Yes, there is a lot of practices that come out of that but to me that is where it starts, it's this attitude. If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and it's a disaster because you're acting out of harmony with what you really believe when you do that."

  • 0
  • 0
Kurt Frederichsen

Jamen, jeg kan da ikke være uenige i værdibetragtningerne! Dem har jeg også lagt stor vægt på hvor jeg har været med til at indføre agil udvikling!

Det er bare lidt for nemt at sige de bare skal være der! Så er der, som Frank filosoferer over, ikke mange steder man reelt kan arbejde agilt!

Heldigvis har jeg da også set at det er muligt at skubbe, trække, lokke, ... mange mennesker i den rigtige retning - omend ikke alle. Men det kræver helt klart fokus i organisationen - fokus der holder mere end 2 måneder! Det kræver en kerne, der kan deres kram og ved hvad metoden går ud på, hvad forandring går ud på, ... og selvfølgelig hvad deres faglige domæne går ud på! Det er muligt! Hvis man virkelig vil! Hvis man virkelig gerne vil have andre mennesker med på rejsen - selv om de er helt anderledes og starter et helt andet sted end én selv! ;-)

Så kom nu igang!

  • 0
  • 0
Janne Helweg Dam

Jeg undre mig over jeres oplægs indhold her. Kun en nævner lidt om kvalitetsikring mens alle jer andre snakker kun om arkitektur og udvikling - men for mig er det også vigtigt at vi anvender agil metoder til kvalitetssikring TDD eller pair programming - hvor er I i forhold til det? Kvaliteten kommer ved dialog med kunden, interaktion mellem alle på projektet og det at man løser opgaven sammen med god dialog om den ønskede leverance. Jeg ser testeren som en vigtig sparingspartner her. Det er her vinkler og kvalitet kommer ind i produktet om ikke kun så i hvert tilfælde også.

  • 0
  • 0
Rasmus Christensen

Ganske spændende tråd. Jeg har netop skrevet lidt i tråden: http://www.version2.dk/grupper/Agil-udvikling/forum/6632 Og ja nu vil jeg da dele lidt ud af mine erfaringer :) Jeg har været lidt i begge lejre, både der hvor der er styr på processerne inden man blev agile og så der hvor man ikke kender sine processer 100% og så prøver at blive agile.

Først nævnte er hos Systematic. Jeg har været der siden CMMI4 og et godt stykke efter det blev til CMMI5. Og lad mig slå fast at et process apparat kan være stort, men det er virkelig en solid rygrad og noget der fremmer det at arbejde mod at være agil. Jeg var også med da SCRUM ved indført og det er derfra jeg har mine erfaringer. Omvendt arbejder jeg lige nu hvor vi først og fremmest arbejder på at få styr på udviklingsprocesserne, men samtidig vil vi også gerne være agile. Det kan være noget af et dilemma at stå i, da man lige pludselig ikke kun skal fokusere på sig selv som udvikler/arkitekt, men ogaå kunder, productowner mm. Det er en størrer projekt kultur man skal indføre og ja, det sker ikke overnight :o). Ofte til stor frustration for en ung udvikler, der er født ind i buzzword bølgen. Hvis man ikke er 100% klar i spytten omkring sine processer, hvorfor så ikke smide det der er på porten og hive en agile process ind som SCRUM og så lade den påvirke hvordan man arbejder. Jeg tror bestemt heller ikke der er tale om en døgnflue, og det handler vel i bund og grund om at man findet et ståsted, og så kan man altid være med i den næste forandringsbølge Agile 2.0.

  • 0
  • 0
Thomas Gravgaard

Diskussionen er skredet lidt i forhold til første indlæg. Prøver lige at komme tilbage.

Jeg mener man skal huske at i hvert fald iflg XP tankegangen er Extreme Refactoring et must. Og det er det der holder din arkitektur smidig og klar til at udvikle sig hen mod næste ændring.

Det er helt korrekt at der er et naturligt clash mellem lang og kortsigtet arkitektur. Agile fokuserer på at hvis man er smidig nok så er problemet med at justere sin arkitektur et non-issue. Hvis man også fokuserer på at tackle de største arkitektoniske issues så tidligt som muligt mindsker man også risikoen tidligt i processen.

Personligt synes jeg ikke det betyder at man ikke må hæve blikket en smule over den korte horisont. Det er lige så vigtigt at fokusere på hvor man skal ramme efter alle sine sprints som hvad der skal komme ud af det enkelte sprint. Selvom vejen mod mål har ukendte sving skal man stadig over linien og ikke ende på tribunen. :)

  • 0
  • 0
Peter Nørregaard Blogger

Jeg læste i går et citat brugt af Martin Fowler: “Architecture is the decisions that you wish you could get right early in a project." Det giver da god mening, ikke?

Han overvejer videre og kommer frem til ”So you might end up defining architecture as ’things that people perceive as hard to change.’”

Hmm, ikke lige min definition: mens en arkitektur kan være svær at ændre, så er arkitektur også en del andet.

Men han har da en pointe. Nogle former for arkitektur er i praksis irreversible og når det er tilfældet bliver systemet komplekst som følge af at udviklerne skal til at arbejde på at omgå arkitekturen.

Thomas nævner at der er noget der hedder en langsigtet arkitektur og dér er jeg enig. En langsigtet arkitektur er krævende disciplin, som også nævnes i "Den nye holdbarhed": Design for change er mantraet. Den arkitektur som jeg pt. kan se giver de bedste forudsætninger for at kunne håndtere forandringer er et service orienteret infrastruktur, hvor services er udstillet og forbruges af processer og vises i portaler (det lyder som den gamle trelagsmodel, men det er det ikke - langt fra)

Og til min pointe: I et agilt forløb burde det være muligt at sætte nogle arkitektur-rammer op (architecture by design, som Glenn skriver), som det burde være muligt at følge uden at de nødvendige frihedsgrader fjernes fra den agile metode. Dermed bliver der ikke noget naturligt clash mellem kortsigtet og langsigtet arkitektur – den kortsigtede er blot underlagt rammerne som den langsigtede giver. Det kræver blot at den respekteres, på linje med at vedtage at bruge fx. C# som sprog uden at tillade sektioner med unsafe code.

Link: Who needs Architects: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Hvem vil dog investere i holdbar arkitektur?: http://www.version2.dk/artikel/6285

Den nye holdbarhed: http://www.version2.dk/artikel/6365

  • 0
  • 0