Når hastighed er en konkurrence parameter.

En af de farer der lurer når man konkurrere på hastighed i software udvikling er hvad der i software arkitektur kaldes inkonsistens – men hvordan kan det være? Der er flere parametre man kan bruge hvis man skal have et overblik over om man har en god software arkitektur. Er software arkitekturen fleksibel, er den forståelig og er den til at finde og rette fejl i? Hvis man skal kunne svare ja til de 3 ting, er det nødvendigt er man har en konsistent omgang med sine begreber. Og det at lave software er bland andet at definere klynger af funktionalitet med et afgrænset men præcist og veldefineret potentiale for at bidrage til en samlet brugeroplevelse. Noget af det sjove er navngivning, hvad skal klyngen hedde? Den skal have et navn, for man skal kunne tale om den, ellers kan man ikke kommunikere effektivt omkring sin software arkitektur, og kan man ikke det, er man ude af stand til at definere sin organisation. Hvis man ikke kan navngive sine klynger er der noget der tyder på, at der er noget inkonsistent inde i midten af sin klynge af software funktionalitet – ansvarsområdet er blevet for bredt om man står med et multiværktøj, som hverken er en rigtig tang eller kniv. Og det er svært at sige om et multiværktøj er godt – for hvad mener man, kniven eller tangen? – det bliver svært at kommunikere. Det bliver også svært at finde fejl, af to grunde: For det første, af dem simple grund at man ikke kan kommunikere, og derfor ikke sige hvor fejlen er, den er i klyngen som har et navn der ikke dækker hvad den kan, for det andet, hvis der er to fejl er sandsynligheden for at den er i klyngen uden navn større, fordi den indeholder mere funktionalitet end den burde, og derved skal to mennesker til at rette i den samme kode. Det er svært, som at male et maleri to mennesker på samme tid. Det kræver koordination og sætter hastigheden ned fordi det umulig gør parallel udvikling.

Inkonsistens er noget der er nødvendigt at kunne kommunikere omkring sin software arkitektur, men det er i lige så høj grad noget med brugen af de klynger som har et veldefineret ansvarsområde. Og brug er noget folk med forstand på human computer interaction har forstand på. Og her en kobling som er værd at ligge mærke til. Nok bruger designere meget tid på at gøre ting smukke og brugervenlige, men det er præcis de samme egenskaber softwareingeniører leder efter når der skal laves softwarearkitektur. Klynger, klasse, moduler er brugsgenstande, som skal bruges i en kontekst, i dagligdagen og som skal være til gavn for mennesker, præcis som brugergrænseflader.

Brug og kontekst består af to ting, menneske og maskine adaption, og den sociale organisation hvori der arbejdes med software. Vi mennesker bruger sproget og vores kognitive evner som levende væsner når vi iagttager verden, også når det gælder software. Software ingeniører bruger begreber som klynger, klasser, moduler, interfaces, lag delt arkitektur og andre mønstre når vi skal beskrive hvordan softwaren vi bygger er tiltænkt at virke. Designere bruger lang tid på at gøre en genstand brugbar, så den passer til forståelse vi mennesker har umiddelbart når vi ser genstanden. Det er det der gør genstanden let at bruge og vi bliver glade fordi den virker som vi umiddelbart tror. Det samme er gælder software, en klynge af software klasser skal være navngivet så vi umiddelbart forstår hvad den kan, have et interface gør at klyngen fungere som vi umiddelbart tror. Og hvorfor? – der er tid at spare, det gælder i human computer action om at designe et interface sådan at det passer til den opgave brugeren står overfor. Og at grænsefladen hjælper brugeren med at udfører den opgave. På den måde reduceres fejl i betjeningen, opgaven bliver udført hurtigere og man får glade brugere der kommer igen. Igen gælder det samme for software, når en programmør sidder med en samling af klynger og skal lave ny funktionalitet, har det menneske et problem. Den samlede mængde af software håndtag der er til rådighed skal hjælpe den programmør med at løse opgaven, også så mængden af fejl reduceres.

Der er en vis mængde psykologi i det, for vi har med mennesker at gøre. Især mentale modeller er vigtige i software, fordi vi kommer med erfaring i bagagen og skal løse en software opgave, og hvis vi møder noget der udfordrer vores mentale model bliver vi skeptiske. Vi laver som regel to forskellige modeller når vi arbejder med software: En strukturel model og en funktionel model. Den strukturelle model er den vi laver når vi laver kasser, klynger osv. Den fortæller os hvad systemet består af, og hvordan strukturen er i systemet. Den funktionelle er hvordan vi bruger ting. De fleste ved ikke hvordan den strukturelle model er af en lommeregner, men de kan godt bruge den, for de har en funktionel model. Software arkitektur skal beskrive begge modeller. Når vi laver software som en organisation, bygger i sammen den mentale model i real tid. Det er derfor det er vigtigt at de er konsistens i software arkitekturen, og at der er kommunikation. Hvis ikke arbejder vi ikke sammen, og vi forstår noget forskelligt ved det samme. Den bedste måde at organisere det er ved at gøre det simpelt. Præcis som et dørhåndtag, det er simpelt alle ved det hvordan det skal bruges. Når noget bliver komplekst bruger vi refactoring, for hele tiden at arbejde med at gøre tingene simple.

Vores udviklingsmodeller skal tage højde for denne opbygning af den mentale model, ellers går det galt. Vandfalds modellen som jo for tiden bliver brugt som eksempel på det man aldrig må bruge, tager højde for det. Der er indbygget tid til at bygge den mentale model op, modsat Scrum hvor der ingen tid er, ej heller til at kommunikere den. I Scrum arbejder vi med hvad jeg vil betegne som halve systemer fordi der er en stor focus på vertikale features, og ikke focus på de lag som arkitekturen skal rumme for at kunne rumme de klynger af software der skal til for at løse det samlede problem. Scrum bliver let begrebstomt, og enhver tanke om at lave begyndelsen til en klynge af software moduler, kan for let slås ihjel med ”står det i backloggen?”, ”er det målet for dette sprint?”.

Romere og Lean

Sådan sagde Asterix og Obelix igen og igen, men faktisk var der mindst en enkelt mand der havde fat i noget omkring Lean. Cicero sagde; Quis? Quid? Ubi? Quibus? Auxiliis? Cur? Quomodo? Quando? Som oversat betyder: Hvem? Hvad? Hvor? Hvorved? Hvorfor? Hvordan? Hvornår? Disse blev siden kaldt de 7 filosofiske grundbegreber.

Matthew May har skrevet om Lean, “Lean requires a precise understanding of value - the Who, what, when, where, how, and why. Og den skarpe kan jo se at han mangler en, nemlig Hvorved?. Den vender vi tilbage til.

Toyota lavede en prius på 15 måneder, og det er et stykke software på hjul. Toyota bruger Lean, og konkurrere på hastighed, altså hvor hurtigt de er i stand til at producere noget nyt, som er helt nyt og markeds skabende.

At konkurrere på hastighed, er svært i software udvikling. Fordi det der slår hastigheden ihjel er, komplexitet, inkonsistens og overload. Og software er komplext, så hvad gør man? - man holder det simpelt. Og det gør man ved at have en fælles infrastruktur i sit software projekt. En fælles arkitektur som er forståelig, fælles navne konvention, fælles værktøjer.

Det starter som regel godt, for software er jo ikke komplext fra begyndelsen, når der ikke er skrevet en eneste linie. Det kan godt være at kravende er svært og komplekse, men softwaren er det ikke endnu. Det sander til efterhånden som man kommer mere og mere funktionalitet på, fordi ens arkitektur ikke er i stand til at bære det. Der er ikke tænkt igennem som et framework der virkelig skal understøtte de ændringer der er nødvendige for at nå i mål med sit produkt. Derfor kræver software som regel hvad vi kalder refactoring. Det byder sig selv, at har man meget af det, er man lige vidt. Hvis man hver gang der kommer et enkelt nyt krav skal skrive det meste om, er er igen noget der tyder på at ens arkitektur ikke er tænkt igennem. Derfor er fleksibilitet i software arkitektur vigtigt, men pointen er at det framework som skal bære den fleksibilitet ikke kan ændres undervejs. Der skal være tilstede fra begyndelsen, for hvis det ændres får man inkonsistens og dermed bliver den begrebs verden man har bygget op undervejs i projektet hele tiden revet ned - og det gør at man er så langt fra at være agile og lean som man overhovedet kan være.

Scrum mennesker vil nok råbe, og sige - jamen det er perfekt for Scrum er jo netop en process, som er i stand til at håndtere ændringer. Pointen er bare at det er ligegyldigt, hvis ikke din software arkitektur er i stand til at rumme ændringer. Så kan det godt være din process kan, men din software kan ikke også er det håbløst. Hvis du vil have noget der over tid til stadighed kan ændres, skal du have arkitektur der understøtter det og ikke en process der understøtter det. Hvis du kun har processen sander det til, og det er præcist det som Scrum gør igen og igen når det møder virkeligheden.

Setbased design, er et koncept fra Toyota. Det handler basalt set om at have så mange strenge at spille på hele tiden så muligt. Det vil sige, hele tiden arbejde med flere løsninger på engang og vente så længe så muligt med at tage beslutninger om hvilken der skal bruges. Det kræver selvfølig at man har folk nok, men prøv lige og tænkt på følgene eksempel fra som Mary poppendieck, hev frem da hun talte om “competing on basis of speed” ved google. En der laver software til printere, har et problem. Han marketing folk siger at hvis de skal sælge printere i stort antal skal de have “red eye reduktion”. Det lyder simpelt nok, red eye reduktion er en kendt teknik, men her ville de gerne have en automatisk red eye reduktion så den selv var i stand til at detektere om det var nødvendigt uden menneskelig indblanding. Manden der skulle lave det havde to algoritmer, en god, og en dårlig. Den dårlige kunne let implementeres og på den aftalte tid, den gode tog længere tid og krævede flere ressourcer. Nu var manden jo softwareingeniør, og vi har jo hang til gode algoritmer, men han viste ikke hvor han skulle få ressourcerne fra. Mary sagde så, jamen hør nu her, du siger til mig at hvis i har den her teknologi kan i sælger mange flere printere, også så spørger du mig om hvor du skal få ressourcen fra`? - jamen hvad er alternativet!. Vil i sælge mange printere, eller vil i ikke?.

At arbejde med flere løsninger på samme tid, kræver frihed. Frihed til at lege og blive specialist, fordi at det er netop det der gør, at man er klar når kravet kommer. Det kræver altså det vi engang kaldte udvikling!. Ikke bare at udvikle løsninger til kunden men også at blive specialist i på sit område, så man er foran kunden. Det er en organisation der er i stand til at håndtere ændringer.

Agile eller Kaos

Det var med spænding at jeg sad og så en video med David Douglas, som er kariere konsulent og co founder af Innovel og ledene træner i Scrum, Agile og Lean. Overskriften er ” We suck less” is not enough.




Endelig var der måske en der ville tage fat i problemerne med Scrum, Agile og hvorfor det fejler så tit. Faktisk kom de med eksempler på firmaer som var gået væk fra Scrum, efter at de faktisk havde haft noget succes med de starten, de var gået tilbage til en mere kontrolleret måde at gøre tingene på…det sagde han faktisk..

Det er David Douglas’s svar på problemerne man må undre sig over. Svaret er at ændre sin organisation – for det er derfor Scrum fejler. Organisationen følger ikke med udviklingen.

Problemet var ifølge de to herre, at de gamle stive folk sad tilbage i deres linie organisationer og ikke er villige til at give slip. Det er jo spændene taget i betragtning at vi i mange år har arbejdet i matrix organisationer.



Agile sander altså til hen af vejen fordi organisationen ikke følger med, eller som de siger ” Agile adoption without organisation change is unstable and is likely to regress and get unstable”. Af gode forslag er der eksempler på nogle der har organiseret sig efter team metaforen.

Men vi er lige nød til at overvejer hvorfor vi har organiseret os som vi har inden vi gik i gang med Agile og Scrum.

Min påstand er stadig at hvis du ikke organisere dig efter din software arkitektur så går det galt. Når du står med din komponent arkitektur, kigger ud over den, så har du din organisation. Mindst et team til hver komponent, og måske flere komponenter til et team. Men der kan ikke være en komponent uden team, for så bliver den bare ikke lavet.

En software komponent er typisk det man i dag vil kalde en service. Altså en samling af funktionalitet som tilbyder sig i et samspil med andre komponenter for at kunne udføre en given usecase til gavn for brugeren.

I Scrum er man organiseret i cross functional teams, for at kunne dække en given usecase i et sprint. Man laver altså et team, med en fra hver komponent som indgår i den usecase man ønsker at give liv. Problemet er jo bare at komponenterne ikke findes endnu, de skal først udvikles, og det er her det går galt. Hvis man skal noget med Agile skal man ikke gøre som de to herre foreslår. Man skal ikke have cross functional teams, hvor en mand sidder med en komponent. I stedet foreslår jeg at man organisere sig efter sin komponent arkitektur, samler teams til hver komponent. Det kræver naturligvis koordination mellem komponenterne, fælles mål at arbejde hen imod, men med respekt for de afhængigheder der er indbygget både inden i de enkelte komponenter, og komponenterne imellem – og det er jo derfor man laver en projekt plan, med afhængigheder.

Den arkitektoniske udviklings model har flere fordele, som vi i Agile har smidt væk, eller kommer til at gøre hvis vi følger det råd de to konsulenter foreslår. Hvor blev vores specialister af – og hvor kommer de fra?. Jo de bliver netop skabt i samspil med andre af samme race, altså af at side sammen med andre der laver det samme. I en Agile organisation som vist på tegningen, er specialisten væk, og alle er det samme, kan det samme og har lyst til det samme. Udvikleren bliver generalist, og det står enhver frit for at vælge en task på Scrum tavlen for der er ingen specialister mere.

Vi går på de kritiske stier.

Software projekt planer og parallel processering viser mange fælles træk. Feks skrev Amdahl i 1960’erne Amdahls lov, som på viser at de fleste algoritmer ikke opnår en lineær forbedring i køretid ved en tilsvarende stigning i antallet af processerings elementer. Altså en dobbelt så hurtigt CPU, udfører ikke algoritmen dobbelt så hurtigt – i mange tilfælde i det mindste.

I 1975 fik vi så brooks’s lov, som sagde ”tilføjelse af ressourcer til et forsinket software projekt gør det mere forsinket.

Egentlig udtaler de sig om det samme. Nemlig det faktum at der er afhængigheder i software, og at uanset hvad du finder på, kan du ikke optimere din plan ud over den kritiske sti, nemlig den tid det tager at skrive det stykke software som ikke kan paralleliseres i sin udførsel. Vores byggesten har i mange år været de samme, filer der kompileres – kalder hinanden på kryds og tværs og til sidst udgør et hele med den ønskede funktionalitet. Disse filer er en slags atomer, som på sin vis bliver det mindste det giver mening at arbejde på, for et menneske. Man har prøvet at lade flere mennesker arbejde på den samme fil, men det viser sig for det meste, at tiden med at koordinere arbejdet bliver højere end selve det at skrive softwaren. Størrelsen af atomerne i vores tilfælde filerne er delt op efter funktionalitet, hvad enten vi udvikler objekt orienteret eller i ren c. Funktionaliteten kommer fra beskrivelsen af domænet, altså virkeligheden.

Gustavsons lov fra 1988 redede parallel algoritmerne, og viste at jo der var noget at hente, hvis bare der var data nok at arbejde med. Men det reder desværre ikke vores projekt planer. Men den beviser at man lige så godt kan udvikle mere funktionalitet i den tid der alligevel bliver brugt på at udvikle den sekventielle del. Selvfølgelig forudsat at de ingen afhængigheder har til resultatet af den sekventielle del og dermed bidrage til et bedre og mere rigt produkt.

Netop derfor er vi glade når vi ser en software arkitektur som udgør et framework. Når først vi har et framework kan vi nemlig begynde at parallelisere vores opgaver i det uendelige. Web services er et godt eksempel – på hvordan alle glæder sig til at ”bare” at skulle lave nye services til et eksisterende framework og lave en mashup der trækker på de services der er nødvendige. Der er ikke noget nyt i det, ud over at vi går imod en større standardisering af vores løsninger, nemlig et fælles framework for hele verden. Men der er stadig afhængigheder mellem vores mash up og vores services, præcis som der altid har været, og vi skal stadig definere vores services, men vi bruger det som en IASP.

Nogle vil måske sige, hvad så med kreativiteten? – tja hvad skete der med industrien da man fik standarder på bolte, møtrikker og skruer? Jeg tror ikke man kan sige at den blev mindre kreativ, og materialerne bliver bedre og bedre og opfindelserne ikke mindre.

hjælp jeg er selvorganiserende

Vi har en flad selvorganiserende organisation var der en dag en der sagde til mig. Og jo, de lavede software. Man kan smage lidt på ordet selvorganisation. Hvad betyder det egentlig? – Ja det betyder at et system kan stige i kompleksitet uden at nogen eller noget har fortalt hvad retning det skal tage.
Sådan en organisation havde de altså – en organisation som ændrer sig til mere komplekse former uden grund, eller uden at nogen havde forlangt det. Scrum bruger tit ordet til at beskrive Scrum teams, og det er måske nok lidt overdrevet, at 5 til 6 individer skulle kunne blive til en mere kompleks organisation uden at nogen havde forlangt det. Som tidligere skrevet er organisation et spejl af din arkitektur. Så konsekvensen af en selvorganiserende software organisation må være en selv organiserende arkitektur. Hverken mere eller mindre – og det er spændene. For det betyder jo, at software arkitekter i den forbindelse, hvis de får lov, er en slags gud der giver tingene et design inden de udvikler sig, hvorimod den selvorganiserende software udvikler sig af sig selv. I naturen har det så vist sig at det når taget temmelig lang tid med sådanne selvorganiserende strukturer, også længere tid end kunden vil vente på et stykke software uanset hvor genialt det så måtte ende med at blive. Men faktisk tror jeg at vi i mange år i software udviklingens kunst, har lagt op til at de strukturer vi byggede skulle være selvorganiserende i et vist opfang. De fleste af de mønstre vi anvender, går jo netop på at afkoble de enkelte dele så de kan udvikle sig frit, under så lidt hensyn tagen til resten af projektet. Den service orienterede arkitektur er vel det sidste skud på sammen, hvor alle kan bidrage med services, som kobles på, kan findes, bruges og anvendes af andre. Men det betyder jo ikke at den enkelte service er lavet af en selvorganiserende projekt gruppe.
Selvorganisering virker nemlig ikke så godt når mennesker er blandet ind i det - vi tænker for meget – ligger for mange planer, og vil til enhver tid udnytte de svagheder et system har til vores egen fordel. Derfor tager Scrum og selvorganiserende teams ikke højde for den menneskelige psykologi, og da slet ikke at vi har forskellige evner. Prøv at stil dig selv spørgsmålet, hvilke rolle er der brug for i et Scrum team? – er det ligegyldigt fordi det finder de selv ud af, fordi de netop er selvorganiserende? Jeg tror ikke på det, for hvis et team skal være effektivt er det nødvendigt at der er lidt af hvert på det team, en med de gode ideer, nogle der kan kode, nogle der kan teste, en build manager der kan styre den side af sagen osv. Det er så rigtigt nok, at hvis man bare tager tilfældige folk uden at have en ide om hvad deres stærke og svage sider er, så er selvorganisering nok det bedste bud på den højst opnåelige effektivitet. Men vi ansætter jo ikke tilfældige mennesker (endnu), og vi ved godt at et effektivt team har medlemmer med forskellige roller, for vi vil gerne have at vores team har en performance der er bedre end hvad tilfældigheden kommer med. Jeg er træt af ordet selvorganisation og synes vi skal bruge ordet selvstyrende i stedet. Selvstyrende betyder jo at en lille organisation selv kan tilrettelægge arbejdet på den måde den finder bedst for at nå de mål organisationen står overfor. Det kan man desværre ikke i Scrum, der er regler der skal følges og en product backlog der definere målene med hvert eneste sprint. Så et team får et lille råderum på 3 – 4 uger, med tasks der maximalt er et vist antal timer. Det er ikke selvstyrende – og om det er selvorganiserende er også ligegyldigt, for det hjælper ikke.

Scrum fra dag 1..eller?

Software arkitektur handler om facon og form hørte jeg den anden dag. Hvor er faconen så henne – ja den ligger i de abstrakte base klasser. Og hvad kan man så bruge det til? – jo det er fra arkitekturen at projektplanen fremtræder. Det er her mellem streger og kasser at de parallelle spor findes. Det er her man får overblik over hvad der kan udvikles parallelt og hvor der er afhængigheder som udgør de kritiske stier som skal betrædes for at få det til at lykkedes.
Rækkefølgen hvor i hvordan software skrives er derfor ikke ligegyldig, det gælder om at starte det rigtige sted for at opnå parallelitet i projekt planen og dermed udnytte de hænder man har til rådighed bedst muligt. Svarende ligger i arkitekturen fordi vores traditionelle lagdelte arkitektur har afhængigheder. Enhver form for relation mellem software, hvad enten det er en webservice, et c modul, en java klasse giver en afhængighed. Så kommer spørgsmålet når man så tager sit første sprint, hvad skal vi lave? Det ved product owneren. Han har en plan med sprintet. Og vi tager den plan, laver vores backlog, bryder ned til tasks – men hvad skete der med paralleliteten?. Kan vores product owner gennemskue arkitekturen og se at her er et godt sted at starte fordi det betyder at vi om en eller to uger kan rampe up og starte en masse i parallel og give projektet fart. Næppe. Jeg har aldrig set en product owner der kunne. Kunden i den anden ende kan slet ikke. Og er sikkert også ligeglad, kunden forventer at vi gør hvad vi kan for at levere hans produkt så hurtigt så muligt. Derfor sander scrum til. Det er simpelthen langsommere at lave software på den måde, fordi vi ikke tager højde for at noget kan udvikles parallelt.

UML og scrum:
I UML findes der 6 forskellige måder at beskrive afhængigheder på i software. 4 omhandler kommunikation og 2 struktur.

De 4 der omhandler kommunikation er:
Afhængighed
Associering
Aggregering
Og komposition.

De 2 der omhandler struktur er:
Generalisering og realisation.

Afhængighed, ligner en association, så den tager vi bagefter.

Man laver en association ved at erklærer den man associerer til i sin egen klasse. Hvis det skal kompilere skal man altså mindst have et skelet af den man associere til, ellers er erklæringen ugyldig. Og hvorfor så lave sådan en? – jo typisk skal man jo bruge de metoder som den associerede klasse tilbyder, så hvis det skal kompilerer skal man altså også som minimum have metoderne i den klasse erklæret. Der er altså en rækkefølge ved denne type af afhængighed. Noget man er nød til at implementere før man kan bruge det.

Afhængigheden laves ved at gøre det samme, men nu er erklæringen af den man associerer til ikke i sin egen klasse, men derimod i en metode i sin egen klasse. Den er altså lokal og ikke som sådan en del af klassen selv. De er mere dynamiske og opstår runtime og forsvinder igen når metoden returnerer. Men igen er der en rækkefølge.

Aggregation, er en specialisering af association. Men i praksis har det ingen betydning. Koden er fuldstændig mangen til en association!.

Komposition er igen en specialisering af association. I C++ kan man se forskellen ved at den klasse man har en komposition til er erklæret som en variable og ikke en pointer. I Java er der ikke har pointere, er der igen ingen forskel på koden.

Fælles for disse er altså at noget skal findes før det kan bruges i andre klasser. Og det er man nød til at tage højde for i sin planlægning af sit projekt. Et rigtigt godt udgangs punkt er skelettet. Det gør at koden kan kompilerer, man kan hurtigt få sin struktur implementeret og teste om softwaren har det rigtige flow igennem den ”use-case” man ønsker, inden man fylder algoritmer og funktionalitet på.

Hvis man derimod går efter funktionalitet og begynder at fylde det ind, inden skelettet er på plads sker der tit det at de metoderne ikke bliver generelle nok til at håndtere andre use cases af lignede art. De andre udviklere på teamet går i stå, de kan ikke kompilere deres kode, fordi de mangler metoder. Når metoderne ikke bliver generelle nok skal der ”refaktorering” til. En metoder skal have en argument mere på, og det kan ikke kompilerer, da alle andre kalder den samme funktion med et nu forkert antal parametre. Det griber om sig.

De strukturelle afhængigheder som der findes 2 af i UML er følgende.

Generalisation er arv, det vil sige at man arver en del af de egenskaber en anden klasse har. I C++ er det bare et enkelt : og i Java, extends der gør det for en. Hvad man arver er forskelligt afhængig af hvordan den klasse man arver fra er skruet sammen. Men faktum er at klassen skal være der, før man kan arve. En finurlig ting ved arv er polymorphi, som kommer fra græsk og betyder at have flere former. Det basale er at hvis den klasse man arver fra har erklæret en metode virtual, ja så kan man overskrive den. Man skal dog holde sig til den samme erklæring, parametre etc. Man ser det mange steder i den virkelige verden, feks i banker hvor vi alle har forskellige kontoer med forskellige renter, som beregnes på forskellige måder.
Hvis man bare går efter en enkel funktionalitet, behøver man ikke bruge det. Man kan sagtens i sprint 1 lave en opsparings konto der kan beregne renter og i sprint 2 lave en real kredits konto der kan beregne renter.

Realisering er typisk brugt hvor man ønsker at gøre brug af det framework ens platform tilbyder. Feks på android er det flittigt brugt til interaktion, swipe, scroll etc. Hvor frameworket kalder din klasse og fortæller dig hvad der foregår mellem brugeren og skærmen, hvor man trykker og hvor hurtigt han flyttede fingeren. I Java er det simpelt, især med moderne editorer, man skriver implements også det interface man vil lytte til. I C++ er det heller ikke så svært, man laver en base klasse hvis metoder er pure virtual og nedarver fra den. Effekten er den samme, der er nogle metoder som man er tvunget til at implementere i sin egen klasse. Poly morphisme og realisation hænger nøje sammen. Feks kunne det betyde at man aldrig kan lave en konto klasse, der ikke kan beregne renter. Altså en sikkerhed for at et interface overholdes.

Det er åbenlyst at det er i disse beskrivelser af afhængigheder imellem de software komponenter, klasse eller moduler vi laver at nøglen til genbrugbarhed, fleksibiliteten til at udvide ligger. Men ved vores produkt owner det?, og kommer det til at stå i produkt backloggen? – næppe. Derfor kan man ikke køre Scrum fra dag 1.

Den Parallelle facon i software

Software arkitektur handler om facon og form hørte jeg den anden dag. Hvor er faconen så henne – ja den ligger i de abstrakte base klasser. Og hvad kan man så bruge det til? – jo det er fra arkitekturen at projektplanen fremtræder. Det er her mellem streger og kasser at de parallelle spor findes. Det er her man får overblik over hvad der kan udvikles parallelt og hvor der er afhængigheder som udgør de kritiske stier som skal betrædes for at få det til at lykkedes.
Rækkefølgen hvor i hvordan software skrives er derfor ikke ligegyldig, det gælder om at starte det rigtige sted for at opnå parallelitet i projekt planen og dermed udnytte de hænder man har til rådighed bedst muligt. Svarende ligger i arkitekturen fordi vores traditionelle lagdelte arkitektur har afhængigheder. Enhver form for relation mellem software, hvad enten det er en webservice, et c modul, en java klasse giver en afhængighed. Så kommer spørgsmålet når man så tager sit første sprint, hvad skal vi lave? Det ved product owneren. Han har en plan med sprintet. Og vi tager den plan, laver vores backlog, bryder ned til tasks – men hvad skete der med paralleliteten?. Kan vores product owner gennemskue arkitekturen og se at her er et godt sted at starte fordi det betyder at vi om en eller to uger kan rampe up og starte en masse i parallel og give projektet fart. Næppe. Jeg har aldrig set en product owner der kunne. Kunden i den anden ende kan slet ikke. Og er sikkert også ligeglad, kunden forventer at vi gør hvad vi kan for at levere hans produkt så hurtigt så muligt. Derfor sander scrum til. Det er simpelthen langsommere at lave software på den måde, fordi vi ikke tager højde for at noget kan udvikles parallelt.