Avella | Smidig utvikling og selvstyrte team – skaper det bare fullstendig kaos?
Avella | Smidig utvikling og selvstyrte team – skaper det bare fullstendig kaos?
17426
post-template-default,single,single-post,postid-17426,single-format-standard,cookies-not-set,ajax_fade,page_not_loaded,,qode-theme-ver-10.1,wpb-js-composer js-comp-ver-5.0.1,vc_responsive
 
Teamwork

Smidig utvikling og selvstyrte team – skaper det bare fullstendig kaos?


Det er ingen tvil om at de fleste etter hvert ser verdien i en mer smidig utviklingsmetodikk, men derfra til å lykkes med en slik innføring kan veien være lang. En side ved vellykket innføring er at lederskapet er tilstrekkelig delegert og at man dermed er i stand til å jobbe både tverrfaglig og med tilstrekkelig myndighet i teamet. Dette er godt beskrevet i en artikkel fra Promis.

Hva kan gå galt med smidig utvikling?

En annen side ved smidig utvikling som bør tas hensyn til er IT-arkitektur og den systemporteføljen som allerede eksisterer.  Det er flere områder der det er lett å støte på problemer:

  • Legacy-løsninger er ofte forretningskritiske og lever i beste velgående. Disse sammen med dårlig IT-arkitektur hindrer leveranser som skaper verdi for kunden og dermed begrenser forretningsutvikling. Slike systemer og løsninger samhandler ofte veldig dårlig og gjør det veldig vanskelig å bygge gode løsninger på toppen av dem.

  • Ofte er det vanskelig å ta hensyn til andre løsninger og systemer når man utvikler og tester. Grensesnitt til systemer er ofte dårlig dokumentert, og er ofte vanskelig tilgjengelig for test med reelle data. Dette gjør ofte at DevOps-prosessene og raske produksjonssettinger ofte får helt unødvendige problemer og setter en stopper for mulighetene for raske og små produksjonssettinger.

  • Selvstyrte team forholder seg ikke til arkitektur-prinsipper og har individuelle og kortsiktige løsninger som er suboptimale i forhold til den enkelte oppgaven teamet skal løse. Dersom IT-arkitekturen ikke er innarbeidet godt nok, er tilpasset DevOps eller ikke spiller på lag med utviklingsteamene, virker den som et hinder og vil raskt forvitre over tid og medføre en kaotisk systemarkitektur.

Dette er problemstillinger vi har møtt på i flere anledninger, og som skaper utfordringer for mange organisasjoner.

Smidig utvikling må støtte opp under IT-arkitekturen

Det handler veldig ofte om å ta IT-arkitektur og integrasjon på alvor og sørge for at det støtter opp under utviklingsprosessene snarere enn å hindre dem. Det er helt avgjørende for å kunne lage vellykkede, mer lettbeinte løsninger som skal støtte forretningsutvikling. Gartner bruker blant annet bimodal organisering som et virkemiddel for å dele IT-organiseringen i legacy og nyutvikling, men dersom ikke samhandlingen mellom disse er god nok, vil dette skape enda en silo som skaper kunstige skiller i organisasjonen.

Det er ofte en forestilling om at en god IT-arkitektur er tung å implementere og forvalte. Det er ikke nødvendigvis riktig. Gjør grep som forbedrer IT-arkitekturen trinnvis, og få forbedringsområder inn på toppen av backloggen.

Kontinuerlig integrasjon og leveranser er et suksesskriterie

Sørg for at det er mulig å teste integrasjoner tidlig i prosessen. Ha klare grensesnitt og sørg for gode integrasjonsløsninger – også i utviklings, bygge- og testmiljøene – da får du en produksjonssetting som har alle forutsetninger for å gå smertefritt.

IT-Arkitektur må automatiseres som en del av kontinuerlig integrasjon og leveranser. Dette glemmer en ofte når en starter med DevOps. Til og med sikkerhet og infrastruktur kan og bør automatiseres inn så tidlig som mulig. DevOps i seg selv fungerer dårlig om en ikke tar med alt.

I tillegg til ledelse og organisering er det derfor snakk om å kunne håndtere integrasjon. Helt enkelt.

Avella hjelper deg med å legge til rette for å lykkes med prosjekter og smidig utvikling.