INT Sprint Retrospective 2018-15

Vi ser attende på INT Sprint 2018-15 og år 2018.

Tilstades

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

Referat

Vi utfører et uoffisiell tilbakeblikk, der vi snakker mer løst om året som har vært, og året som kommer. Prøver å løfte blikket litt.

 

  • Tusen takk for at dere har tatt meg så godt i mot her

    • Det var ikke med vilje

    • Utsagn støttes

  • 2019 kan nå nye høyder, høyeste årstall hittil!

  • Til neste år skal vi bli bedre med estimering, sier Sivert

  • Har vært forsøkt å finne tall på fremgang i Jira, det viser seg å ikke være mulig å finne tall på fremgang, selv om vi faktisk har hatt fremgang

  • I løpet av året hadde vi en målsetning om å arbeide mer med arbeidsmetoden vår

    • Har ikke fått gjort dette så mye

    • Er nok noe vi har bommet på når vi estimerer

  • Hvordan ønsker utviklerene å arbeide? Hvilken metode passer best for oss?

    • Virker ikke så bra å jobbe prosjekt- eller moshpit-basert

      • Mye tid rotes bort

      • Vi glemmer hva vi gjorde for et halvt år siden eller et år siden

      • Lettere å forholde seg til APIer som blir levert for sent

      • Vi får bedre tid til å ta viktige tekniske beslutninger og tenke på hvor og hva vi skal

    • Vi må være strengere på å få bedre spesifikasjoner av ønsket funksjonalitet!

      • Canvas var ikke så godt spesifisert

      • eValg spesifiserer vi selv

      • Integrasjon mellom TP og Exchange er :(

      • Bestiller bør være mer tilgjengelig for utviklere

      • JIT-spesifikasjon fungerer dårlig, være forsiktig med å benytte Lean- og Agile-konsepter som kommer fra en fabrikk som produserer ting

      • Vi trenger en verktøykasse for å spesifisere hva vi skal gjøre

      • Dårlig spesifikasjon leder til dårlig estimat som leder til forsinkelser og overtid

  • Virker som om de fleste ikke er fornøyd med historiepoengproduksjon

    • Historiepoeng kan medføre en automatisk performance-review (normal menneskelig adferd)

    • Hvordan bør man utføre en demo? Er det jeg eller er det vi som viser fram noe

    • Vi bruker muligens historiepoeng for konkret, vi fyller opp et løp når vi heller burde bruke magefølelsen

  • Hva med å ha mer fleksible ScrumBan-aktige løp?

    • Kalkulering av hva man planlegger å ha ferdig om 5 kvartal er uansett ikke pålitelig

    • Mer smidig

    • Muligens mindre overhead

    • Lavere terskel for å lage nye saker, små filleting relatert til det vi arbeider på får vi løst uten å gå gjennom unplanned-evaluering, samtidig som vi får vist hva som gjøres

    • Planleggingsmøter har blitt bedre, går raskere unna. Dette er bra og essensielt

    • Demonstrasjoner relatert til tema kan være verdt å tenke på, da mister vi ikke så mye tid i demonstrasjonen

  • Bør nok trekke fra mer på enkelt ting relatert til vedlikehold, som for eksempel eValg

Beslutninger

  • Vi snakker sammen på Sprint Planning 2. januar om hvilken metode vi bruker når vi jobber med eValg3.
Publisert 21. des. 2018 19:56 - Sist endret 13. jan. 2023 15:23