INT Sprint Retrospective 2018-13

Vi ser attende, på INT Sprint 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

Publisert 11. okt. 2018 14:38 - Sist endret 18. nov. 2018 21:44