INT Sprint Retrospective 2018-13

Tilstades

• jbr
• jsama (ref)
• sgs
• hanskfje
• fhl
• jokim (ref)
• hmo
• ae
• skh

Sak 1: Forrige Action Items

Tiltak frå forrige retrospekt:

Sak 2: Lean Coffee Retrospective

Vi utførte mager kaffe. Dette resulterte i saksliste:

• RENO: 12 stemmer

• EVALG: 8 stemmer

• Struktur på tilgangsgrupper for applikasjoner: 7 stemmer

• Teknisk gjeld, hvordan identifiserer vi den?: 6 stemmer

• Lønningspils: 5 stemmer

• Overtid: 2 stemmer

Referat fra diskusjon

• RENO

  • Spennende verktøy

  • Bra å ha release notes

  • Spesielt viktig med release notes for pybofh, siden pybofh brukes av sluttbrukere

  • Krever at vi benytter versjonering. Dette har vi for en del produkter, men det store hinderet er muligens Cerebrum

  • Kan det være en ide å knytte versjonsnummer i Jira mot produkter?

    • Usikker på hvor automatisk det kan gjøres i Jira

    • Ideen bak å bruke Reno er at Reno har all metainformasjon som ligger i repositoriet, dette får vi ikke automatisk med Jira

  • Kan muligens introdusere en del overhead i utviklingsfasen

    • Men hvis vi ikke skriver release notes så blir de bare ikke generert, release notes er ikke nødvendigvis en sperre

    • En release note er mer som en pull request en en commit

  • Primær målgruppe for release notes er alle andre en utviklere av det aktuelle system

  • Release notes kan gjerne publiseres som en del av dokumentasjon

• E-valg

  • Joakim har laget en plan

  • I planen er alle lagt inn i E-valg utvikling i full eller nesten full grad

  • Planen er basert på et regnestykke som skal få sakene ferdig til 1 april

  • Greier vi å jobbe full fart med E-valg? Kan vi parallelisere oppgaver eller er det ting som ikke kan parallelliseres?

  • Alt tankearbeid vi har gjort i forhold til E-valg3 er så å si forsvunnet

  • Grafisk utvikling er en mulig flaskehals

  • Vil Canvas-effekten oppstå? Vil vi prøve og feile oss fram i stedet for å ha en arkitektur som er bærekraftig

  • Vi prøvde å sette av en liten gruppe som hjernestormet frem arkitekturen, for så å avlevere den til andre som skal kode. Dette medfører begrenset innsikt i arkitekturen for de som ikke var med i definisjonen av den

  • Ferdigstillingsgrad er usikker. Vi har ikke en fullt fungerende flyt fra stemmegivning til opptelling

  • I hvilken grad vi kan konsentrere oss avhenger av hvordan det går med CanvasMS i produksjon

  • Parallelisering vil medføre at man får lokale eksperter som har veldig god innsikt i deler av systemet, men bør ikke alle ha god oversikt over hele systemet?

  • Full-stack utvikling medfører overhead. Mye skal læres

  • Dataporten står for døren

  • Ved forrige planlegging hadde vi ikke et komplett bilde over hva vi skal gjøre teknisk og hvordan vi skal gjøre det teknisk

• Struktur på tilgangsgrupper for applikasjoner

  • Vi har ingen god definisjon av struktur for tilgangsgrupper for applikasjoner

  • Vi bruker ofte gamle grupper til nye ting, dette medfører at noen mangler tilgang, mens andre som skal ha tilgang ikke får tilgang

  • Dette kan minne litt om tilgangsstyringsprosjektet, men vi trenger ikke automatikk, vi trenger en policy for organisering av grupper

  • Kan tilgangsstyringsprosjektet definere en policy for organisering av tilgangsgrupper?

  • Policy kan også være en anbefaling, ikke en befaling

• Teknisk gjeld, hvordan identifiserer vi den?

  • Vi har tatt opp teknisk gjeld når vi har laget nye ting, kan vi identifisere den?

  • Scripts som søker etter TODOs eller FIXMEs?

  • Kan vi lage saker på teknisk gjeld fortløpende?

  • Kan være vanskelig å finne argumenter for å skrive om noe slik at det blir bedre, når det ikke er ny funksjonalitet

  • Vi bør ha et slags tilbakeblikk på den tekniske implementasjonen av ting vi lager

• Lønningspils

  • Benjamin og TSD drar på Mastermind

  • Vi kan høre med ham om vi får lov til å bli med

  • Jonas vil Heller på MasterMind en Parken

  • Andreas bryr seg ikke om hvor vi drar så lenge det er mat på veien

  • Hans får dessverre ikke vært med men har sansen for at vi gjør dette oftere

  • Sivert har glemt å invitere KIA!

  • Jonas påpeker at det ikke er for sent å invitere til lønningspils

  • Lønningspils er inkluderende og legger til rette for synergisk DevOps-interaksjon

• Overtid

  • Åpnes for frivillig overtid for nyansatte

  • Vi har ubrukte lønnsmidler

  • Trangt år, vi vil få gjort mest mulig. $$$$$$ til arbeiderne

  • Vi kjører nok samme dose overtid på E-valg

  • Dialog om overtid er viktig, må holdes på bærekraftig nivå

  • Åpnes også for overtid i helgene, mer lukrativt!

  • Virket overtidspizza?

    • Det var bra den dagen det var en pizza

    • Gir et godt spark bak for å jobbe noen timer ekstra

    • Planlegges nærmere på planleggingsmøtet

• Ny senioringeniør, vi applauderer for Jonas!

Aksjonspunkter fra diskusjonen

• FHL begynner på Reno for PyBofh

• Vi lager eValg!

• FHL lager brukerhistorie om policy for applikasjonstilgangsgrupper

• SM booker workshop om kodekvalitet

• De som blir med blir med på lønningspils