Teknologiblogg

Migreringsprosjekter kan by på mange utfordringer da man skal fase ut et eller flere systemer,og erstatte det gamle med noe nytt. Utfordringer som dårlig datakvalitet fra det gamle systemet, hvordan man skal få med seg all funksjonalitet og hvordan man kan la de gamle og nye systemene leve ved siden av hverandre er kjente problemstillinger. Alt dette må man ta hensyn og planlegge med i et migreringsprosjekt. I dette innlegget vil jeg oppsummere mine erfaringer, og gi deg noen hint på vegen.

Først ønsker jeg å definere noen hoved-elementer i et migreringsprosjekt

• ”Overordnet produktkø”.  En kø som inneholder epics eller brukerhistorier som gjenspeiler det totale funksjonelle målbildet for systemet som skal utvikles. Er det snakk om migrering må med andre ord køen minimum inneholde brukerhistorier som dekker funksjonaliteten i det gamle systemet.
• ”AS-IS bildet” forteller deg noe om hvordan systemporteføljen din ser ut nå. Dette er et viktig bilde da det forteller deg noe om avhengighetene i det gamle systemet, og dermed noe om rekkefølgen du kan fase ut systemmoduler på.
• ”TO-BE bildet” forteller deg hvordan porteføljen skal se ut etter migreringen. Ofte er dette bildet lagt utover leveranser, hvor bildene viser hvilke systemmoduler du har i nytt og gammelt system til en gitt tid, og hvilken funksjonalitet de støtter.
• Migreringsstrategien viser hvordan du har tenkt å håndtere at du skal skifte ut et system.  Skal du gjøre hele migreringen på en gang, eller skal du la systemene leve ved siden av hverandre? Det kan godt hende at det nye systemet må benytte moduler i det gamle og visa versa en periode dersom du velger det siste. 
• Migreringsplanen er veien du må gå fra AS-IS til TO-BE, med andre ord en plan som gjenspeiler migreringsstrategien og den overordnede produktkøen. Planen må vise hvor mange leveranser du har tenkt å bruke på å levere produktkøen, og hvilke kø-elementer som tilhører en gitt leveranse. Videre må den vise hvilke deler av det gamle systemet som erstattes av det nye i hver leveranse.

Veien fra ”overordnet produktkø” til noe et team kan konstruere
Forretningssiden og arkitekter hos kunden er de som bør utarbeide den overordnede produktkøen. Køen må prioriteres, elementer grupperes etter funksjonalitet og du bør sette relative vekter på elementene slik at du har en måling på størrelse (benytt gjerne planning poker til dette). Når køen er på plass må du gjøre et stykke arbeid for å sikre komplettheten i køen. En måte å gjøre dette på er å mappe kø-elementer opp til moduler i det gamle systemet, noe som vil kunne sikre at du har dekt all funksjonalitet i det gamle systemet i køen. Er det nye systemet prosessdrevet (for eksempel et system for saksbehandling) kan du og forsøke å mappe kø-elementene opp mot prosessene det nye systemet skal dekke for å sikre at du dekker all funksjonalitet saksbehandlerne trenger. Når du da har en komplett overordnet produktkø må du komme deg til leveranser, og videre til noe scrum-teamene dine kan ta tak i.

Følgende punkter kan følges for å komme fra en overordnet produktkø til en kø som et scrum-team kan starte å jobbe på

1. Produkteiere og hovedarkitekter bestemmer hvilke elementer i den prioriterte overordnede køen som leveres i hvilke leveranser.  Dette kalles en leveransekø som må prioriteres slik at man alltid arbeider på de brukerhistoriene som er av høyest prioritet. Migreringsstrategien og ”AS-IS” bildet gir input her, da utfasing av et element i det gamle systemet kan kreve at du leverer flere moduler enn 1:1 mapping til en ny modul i det nye systemet. Dette pga avhengigheter mellom modulene i det gamle systemet. Kanskje kan de modulene i det gamle systemet som er avhengig av den som fases ut benytte den nye modulen i det gamle systemet i stedet?
2. Teamarkitekter, arkitekter fra kunden og forretningsarkitekter løsningsbeskriver leveransekøen. Løsningsbeskrivelsen bør resultere i følgende artifakter
1. Et overordnet design for leveransen. Ikke gå i stor detalj, men design nok til å ta bort store risiki.
2. Detaljering av leveransekøen slik at elementene er på et nivå som kan tas inn til et team. Benytter du Atlassian Jira er subtask et bra element å benytte til detaljering.

Videre til kontruksjon
Når dette er gjort kan man ta elementene inn til konstruksjon. I denne fasen er det teamene som skal levere, og det er derfor viktig at de får forme løsningen. Smidig sier at man i hver iterasjon skal benytte en viss del av tiden, kanskje rundt 10%, til å se fremover på kommende iterasjoner.  Benytt gjerne dette i workshops hvor teamarkitekter og de funksjonelle fra hvert team møtes for å

1. Se i leveransekøen på hva som skal leveres de to neste iterasjonene
2. Ta det overordnede designet fra løsningsbeskrivelsen, og detaljer det for de to kommende iterasjonene. Finner du da en skjult bombe, for eksempel to iterasjoner frem i tid har du litt tid på å løse problemet ved å gjøre noe i neste iterasjon.

Arbeidet i denne workshop kan timeboxes til 1 time med arbeid i hvert team, og 5 minutters presentasjon av arbeidet fra hver gruppe for de andre teamene. Dette bør hjelpe deg til å kartlegge eventuelle avhengigheter på tvers av teamene dine, og sørge for at arkitekter og funksjonelle ser totaliteten i det som leveres. I tillegg bør du sørge for å ha en ”feedback loop” som sikrer at feedback fra konstruksjon gjør at resultatet fra løsningsbeskrivelsen av neste leveranse blir litt bedre enn den forrige. Dvs. spør om teamene dine synes output fra løsningsbeskrivelsen var for detaljert, mangelfull etc.

Det siste jeg vil nevne er at den overordnede produktkøen din må være en levende og smidig kø. Etter hver leveranse i et migreringsprosjekt vil ”AS-IS” bildet endre seg, noe som kan endre prioritet i køen og/eller tilføre eller slette elementer i køen. I hver løsningsbeskrivelse kan det være en ide å løsningsbeskrive litt mer enn det du har kapasitet til, dette vil gjøre deg litt mindre sårbar for endringer i køen og sørge for at du har nok jobb når teamene virkelig får opp farten.

Lykke til ;-)