Teknisk gjeld Tør vi å snakke om det? Econa

Transkript

1 Teknisk gjeld Tør vi å snakke om det? Econa Øyvind Reinertsen, Snefrid Hagberg og Richard Lees Antares Gruppen AS

2 Dagens tema Hva er teknisk gjeld? Hvordan hindrer det oss? Hvordan kan vi identifisere det? Hvordan oppstår det? Hva kan vi gjøre med det? Mål om å legge igjen noen gode råd knyttet til kartlegging, forebygging og tiltak mot teknisk gjeld

3 Åpenbar nødløsning laget i all hast

4 Åpenbar nødløsning laget i all hast Mangelfull plan B Dårlig design

5 Åpenbar nødløsning laget i all hast Mangelfull plan B Dårlig design Løsningen blir fort utdatert Var det verdt innsatsen?

6 Hva er teknisk gjeld?

7 Buzz Forbes Paul Chaffey

8 Oppmerksomhet i media

9 Hva er egentlig teknisk gjeld? Vanskelig å estimere Manglende kompetanse Store klasser Lav kodekvalitet «Spaghetti»-integrasjoner To do/fix me kommentar Rare parameternavn Misfornøyde kunder Mange kokker Gammel/dø kode Utdatert teknologi Fordyrende faktor Snarveier Vedlikeholdsetterslep Komplisert kode Ufullstendig kode Manglende oppgraderinger Kode som ingen tør å røre Endringer tar lang tid Dyrt å gjøre endringer Personavhengighet Leverandør lock-in

10 Metaforens far vår definisjon Ward er en amerikansk dataprogrammerer som bl.a fant opp wikikonseptet og som i 1994 startet programmeringen av WikiWikiWeb. Dette er forløperen til MediaWiki, som brukes blant annet på Wikipedia i dag. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation, objectoriented or otherwise. Ward Cunningham, 1993 Teknisk gjeld er alt det uferdige, unødvendig kompliserte, og utdaterte i løsningene våre som hindrer oss i å drifte, forvalte og videreutvikle så effektivt som vi burde være i stand til

11 Teknisk gjeld kan være et verktøy A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Ward Cunningham ( ). The WyCash Portfolio System

12 Hvordan hindrer det oss?

13 Show stopper

14 Israel Gat, Cutter consortium: «En ond sirkel» Source : theagileexecutive.com/category/technical-debt

15 Hvordan oppstår det?

16 Hva har dette bilde med teknisk gjeld å gjøre? Trenger de egentlig to biler? Er det kostnadseffektivt? Er det plass til en barnevogn? Heldigvis er det enkelt å bytte bil

17 4 faktorer som påvirker teknisk gjeld Prosess Arbeidsprosesser i utviklingsarbeidet Samhandling Samhandling mellom IT og fagavdelinger Teknologi IT-løsninger, arkitektur og integrasjoner Mennesker Kompetanse, motivasjon, ressurstilgang

18 4 faktorer - Prosesser Funn Prosjekter som er drevet av et rent moderniseringsbehov uten ytterligere forretningsverdi har en tendens til å mislykkes Forsøk på utskifting av virksomhetskritiske systemer har blitt stanset Tenker fort for stort. De som har forbedret kontinuerlig har ikke dette problemet Flaskehalser i IT organisasjoner (kapasitet - drift/utvikling)

19 4 faktorer - Teknologi Funn Vesentlige deler av egen systemportefølje var foreldet Usupportert Lite gjenværende kompetanse Medfører ustabilitet Umoderne oppbygning av systemene Store forskjeller i grad av modualisering Lite oversiktlig og vanskelig å endre Fragmenterte og omfattende integrasjonsløsninger Mange ulike teknologier samtidig Punkt-til-punkt-løsninger

20 4 faktorer - Mennesker Funn For person- og leverandøravhengige Rekruttere ressurser med riktig kompetanse Opplæring neglisjeres ofte i forbindelse med modernisering Kapasitetsmangel hos leverandører, og dette er den viktigste motivasjonen for offshoring Endringsmotvilje Mange «kokker»

21 4 faktorer - Samhandling Funn Vanskelig å få forretningssiden til å forstå utfordringen med å levere på tid og kost. Teknisk gjeld er en metafor som gjør dette lettere Alle opplever økte krav og forventninger fra forretningen Utfordringer som omfatter ansvar, roller og kommunikasjon ift. forretningssiden. Dette er en hovedutfordring Det er mulig å få midler til modernisering, men kun fra driftsbudsjettet, ikke av investeringsbudsjettet Modernisering gjøres enten «under radaren» i andre prosjekter, eller som «proaktivt vedlikehold»

22 4 faktorer som påvirker teknisk gjeld Prosess Arbeidsprosesser i utviklingsarbeidet Samhandling Samhandling mellom IT og fagavdelinger Teknologi IT-løsninger, arkitektur og integrasjoner Mennesker Kompetanse, motivasjon, ressurstilgang

23 Hvordan kan vi identifisere det?

24 Måling av teknisk gjeld Subjektive vurderinger gjort av ansatte i verdikjeden Overslag over mengde teknisk gjeld kan gjøres ved å Eksplisitt definere teknisk gjeld i back log Bruke automatiserte verktøy som Sonar, SQALE m.fl.

25 Israel Gat: «Husk på» Teknisk gjeld er ikke problemet Det er bare et symptom på et potensielt problem Still spørsmålet: hva er som fundamentalt går galt hos oss? Metodisk? Operasjonelt? Forretningsmessige prosesser?

26 Hva kan vi gjøre med det?

27 «Don t boil the ocean»

28 Indikatorer Mennesker Er det noen områder av koden som enkelte kvier seg for å jobbe med? Er det noen arbeidsoppgaver, produksjonssetting, systemtest eller daglig drift som ikke kan utføres hvis en ansatt blir syk, tar lengre ferie? (trikkefaktor) Tar det lang tid før nyansatte eller juniorer er produktive? (juniortesten) Er det lav toleranse for å gjøre feil i organisasjonen?

29 Mulige tiltak Mennesker Rullering av ansvar Opplæring Sørg gjerne for mye takhøyde i organisasjonen Ofte vanskelig å redusere stigma rundt det å gjøre feil, men husk at det åpner for enorm læring Parprogrammering Kompetanseoverføring

30 Indikatorer Samhandling Er det vanskelig å gi / få estimater for selv begrensede, godt definerte oppgaver? Klager brukerne på lang nedetid for retting av feil/mindre endringer? Er det stor distanse mellom det som ble kommunisert levert og det som faktisk leveres? Blir det dyrt å gjøre utvikling/endringer? Tar det for lang tid å komme ut med ny funksjonalitet?

31 Mulige tiltak Samhandling Sørg for beinhard prioritering Forståelse for hvorfor man må prioritere Sørg for at IT forstår verdien av det de skal levere (ROI) Benytt brukerhistorier for å beskrive oppgavene Vær tydelig på forventninger Kontinuerlig jobbe med kommunikasjon og tillit

32 Indikatorer Prosess Utviklere som jobber parallelt med flere oppgaver samtidig? I utviklingsprosjekt, blir lovet funksjonalitet ofte levert ufullstendig eller med liten grad av etterarbeid / polering? Krever lansering av nye versjoner mye tid eller arbeid? Er systemet uforholdsmessig vanskelig å drifte/bruke? Er det vanskelig å teste ny funksjonalitet utenom produksjon? Er brukerdokumentasjonen ufullstendig eller utdatert?

33 Mulige tiltak Prosess Reduser samtidige- og synliggjør antall arbeidsoppgaver du sitter på Sikre at IT forstår hensikt/verdi for hver oppgave Ha løpende kontakt med bestiller/sluttbruker Automatiser produksjonslansering i så høy grad som mulig Etabler Q&A og gjør kjent for alle hva IT sin Definition of Done betyr Innfør hyppigere lanseringer for å tvinge frem forbedringer

34 Indikatorer Teknologi Krever enkle endringer uforholdsmessig mye arbeid? Har dere gjentagende feil? Må samme endring gjøres på flere steder? Er koden er full av TODO, FIXME. Ol? Finnes det mye ubrukt kode? Er metodenavn, variabler og parameter navngitt slik at de gir en god indikasjon på hva de brukes til?

35 Mulige tiltak Teknologi Etabler en Definition of Done og kommuniser den ut til verdikjeden Refakturering er en utviklers ansvar og skal gjøres kontinuerlig Som en speider ville sagt: forlat aldri en bålplass, uten å gjøre den litt bedre Parprogrammeringsdager Automatiser, automatiser, automatiser

36 Tiltaksstigen Unngå å lage teknisk gjeld Jobbe med rammebetingelser, bestillingsrutiner, prosjektstyring og forventningsavstemming Endre systemene som skaper teknisk gjeld slik at teknisk gjeld oppstår i mindre grad enn før Fjerne teknisk gjeld Få aksept for proaktivt vedlikehold Gjennomføre større moderniseringsløft Bidra til forbedringer gjennom riktig skalerte tekniske løft Endret adferd Måling av forbedring i porteføljen Styrket prioritering av arbeidet, coaching Egne tekniske ressurser med ansvar for teknisk gjeld Over tid endre adferd gjennom tett og fortløpende coaching og oppfølging Økt bevissthet Fagsamlinger Diskusjonsmøter Kartlegge teknisk gjeld, gjerne periodisk 360-analyser Skape klima for å jobbe bedre med teknisk gjeld gjennom å øke organisasjonens kunnskap om problemet.

37 Oppsummering : «Geriljataktikk» mot teknisk gjeld

38 Takk for oppmerksomheten!