Jeg er flere gange blevet mødt med spørgsmålet: “I det der agil udvikling, hvornår designer man så datamodellen?” Spørgeren kan tænkes at være en lettere forvirret løsningsarkitekt med en vandfaldsbaggrund. Derfor bunder deres bekymring typisk i vanen om, at man da altid analyserer og designer sine løsninger up-front.
Hvordan gør man så?
Hvis der er et og kun et scrumteam tilknyttet projektet, er svaret til at overskue. Da teamet er cross-functional og selv-organiserende, gør teamet det selv, mens de enkelte user stories implementeres. Det løser imidlertid ikke bekymringerne hos den forvirrede arkitekt. Jeg forsøger at dæmpe bekymringerne ved i samarbejde med en DBA, udviklingsteamet og den forvirrede arkitekt at komme frem til en let proces for håndtering af ændringer til datamodellen. Det gør, at prisen for datamodel-ændringer er så lav, at det ikke gør ondt at ligge designet af datamodellen under udviklingen af de enkelte user stories samtidig med, at det giver troværdighed, at en DBA nikker til metoden.
Komplikationer…
Men hvad nu hvis man har flere teams? Og hvad nu hvis nogle af disse teams er near-shore teams? I et projekt, jeg har været involveret i, er der netop near-shore-teams tilknyttet. Projektets mål er en re-implementering af en eksisterende række produkter, hvor man gør op med gamle fejl, brugerinterfaces og skaleringsproblemer. Der er flere forretningskrav, der kan besværliggøre designet af datamodellen:
Der er tale om et gammelt system, hvor bevæggrundene for flere kritiske beslutninger omkring forretningslogik og datamodel fortaber sig i fordums tåger.
For at mindske sandsynligheden for at dette sker igen, er det et forretningskrav, at viden og beslutningsgrundlag omkring datamodellen skal ende hos, og dokumenteres af, et team i onsite.
Der er et forretningskrav om, at eksisterende kunder kan skifte til det nye system med deres data intakt. Eller, i hvert fald så intakt som det kan være, når man flytter det mellem to systemer.
For at understøtte dette krav har man valgt at udvikle og vedligeholde et migreringsværktøj, der kan flytte data fra de gamle produkter til det nye. Gøres dette løbende har man muligheden for at indlæse eksisterende data løbende og have et realistisk datagrundlag at køre udvikling og test på.
Jamen, hvad så?!
Ovenstående skal sikres gennem hele udviklingen. Et fokuspunkt for mig er, at de valgte tiltag ikke må sløve de tilknyttede teams. En let brainstorming session gav mig følgende:
1. Ved release
Et onsite-team har en fast opgave i at vedligeholde migreringsværktøjet og at forstå og dokumentere datamodellen mellem hver release. Hvis man fx har release til produktion hver 3. måned, gør det, at teamet har travlt i de sidste sprints med at forstå datamodellen og opdatere migreringsværktøjet.
Fordele: De enkelte teams er ikke sløvet under almindelig udvikling. For review-teamet er der lidt mere pres på, når vi nærmere os et release.
Ulemper: Uhensigtsmæssigheder i datamodellen opdages ikke, før vi er meget tæt på release. Ændringer i datamodellen er dyrt på dette tidspunkt.
2. På bagkant
Et onsite-team har en fast opgave i hvert sprint om at review’e, forstå og dokumentere de ændringer, der er lavet til datamodellen i det forrige sprint. Herefter opdaterer samme team migreringsværktøjet.
Fordele: De enkelte teams er stadig ikke sløvet, dog kan der være lidt tilbageløb til user stories lavet i sidste sprint i forhold til datamodellen.
Ulemper: Det er svært at erklære en user story for lukket, når der stadig mangler en konkret opgave som review.
3. I sprintet
Opdatere Definition of Done for alle teams med et krav om, at alle datamodelændringer er reviewet af et teammember fra et onsite-team. Ligeledes skal migreringsværktøjet opdateres og testes af teamet, der laver ændringen til datamodellen.
Fordele: Nu er review-delen af datamodellen en del af udviklingen og en user story kan faktisk nå “done” i løbet af sprintet.
Ulemper: Onsite-teamet bliver en flaskehals. Det bliver svært at holde det implementerende team selvkørende. Der er et meget stort krav om forretningsspecifik viden omkring de gamle systemer.
4. På forkant
Onsite-teamet har en fast opgave i hvert sprint om at tegne de overordnede streger i datamodellen til næste sprint, samtidig med at migreringsværktøjet opdateres med ændringerne fra forrige sprint.
Fordele: De enkelte teams er ikke sløvet.
Ulemper: Detaljeringsniveauet for “de overordnede streger” kan nemt blive alt for detaljerede. Man ender i den situation, at teamet onsite har gjort tanker omkring user storien, som skal gøres igen af det implementerende team. Det er ikke sikkert, at de når samme konklusion.
Konkret har jeg erfaring med tilgang 1). Don’t do it! Ulemperne er store, og man bliver presset på kalendertid. Et andet projekt vakler lige nu mellem 2) og 4). Jeg glæder mig til at høste erfaringerne.
Givet de forudsætninger, der er sat for datamodelarbejdet her, hvad kan man ellers gøre?