Tilbakeblikk på INT sprint 2016-8

Tilbakeblikk på det åttande løpet i 2016, der målet var å få Hendingsdreven AD-integrasjon for aktivering og deaktivering ut i pilot-prod. Sprinten var ein del av prosjektet UiO integrasjonsarkitektur.

Fokusområder frå retrospectiven

  • Sjekkeliste for subtasking
  • Sjekkliste for gjennomgang av brukerhistorier på planleggingsmøte
  • SM markerer ein story per sprint for at skal utførast med parprogrammering (eller pardrifting). Dette for å tvinge oss sjølv til å teste det ut.
     

Tilstades

  • hanskfje
  • tvl
  • fhl
  • sgs
  • jbr
  • jsama (ref)
  • hamar
  • raymonm
  • tgk
  • sis
  • jokim (ferie)

    Sak 1: Oppsummering

    SM tek ei kort oppsummering av sprinten og måla frå forrige runde. Vi tek deretter ein runde rundt bordet, der alle kjem med sine innspel til sprinten. Diskuterer det vi kjem over, og lager action items for neste sprint.

    Frå forrige sprint:

    1. SM ordstyrer strengt tekniske diskusjonar på Sprint Planning. Dette for å unngå å bruke for lang tid på planlegginga og estimeringa av stories, så det vert tid til å dele opp i subtasks etterpå.
    2. SM flytter møter til større møterom, med bedre luft!
    3. SM markerer ein story per sprint for at skal utførast med parprogrammering (eller pardrifting). Dette for å tvinge oss sjølv til å teste det ut.
    4. Ukevakta er ansvarleg for at andre også er med på å sjå på saker når Robert må fikse digeks-problem
    5. Team + SM forbereder Sprint Review bedre på førehand.
    6. SM les opp alle stories på Sprint Review.
    7. SM set opp timeboxing pr story til Review.
    8. Jonas spør om Done på Sprint Planning, for å sikre oss at vi har riktige kriterier, spesielt for saker som må unntakast frå dei vanlege Done-kritieria.
    9. SM skyver Sprint Review 15-30 minuttar, så vi får tid til å forberede oss. Dette fordi Danskebåten er opptatt rett før vi starter. (frå jokim: Denne var ikkje nødvendig ettersom vi flytta til eit anna seminarrom som ikkje var booka rett før Review)
    10. PO vurderer interessentmøter på Sprint Planning.

     

    Vi feilet på fokuspunkt 3. Fokuspunkt 3 tas med til neste løp.

    Runde rundt bordet:

    • Uvanlig sprint med mange eksterne som tok del
    • Bra at vi kommer igang med message queueing og sånn
    • Merker at det har vært vanskelig å finne saker mot slutten (gikk litt tom). Må ha flere små oppgaver med
    • Vanskelig å subtaske noen av de store sakene
    • Vel mye dokumentasjonsskriving
    • Vi må prøve å få med alle medarbeidere på demonstrasjonene / kompetanseoverføring innad i gruppen
    • Litt merkelig med eksterne utviklere vi ikke ser noe til. Ekstra ekstern avhengighet i de situasjoner det må gjøres valg
    • Hvis vi har eksterne utviklere med så ville det vært hyggeligere og mer praktisk om vi satt samlokalisert. Lettere kommunikasjon.
    • Av og til litt vanskelig å ta beslutninger mtp. api gateway og broker. Bør muligens inkludere IT-sikkerhet mer
    • Bomma på sprinten. Uheldig at vi ikke greier å gjennomføre. Dette må vi gjøre noe med.
    • Sleit veldig med eksterne hindringer
    • Vi må bli flinkere med å identifisere hindringer
    • Scrum master følger opp hindringer mer aggressivt, og eskalerer til produkteier

    Sak 2: Lean Coffee?

    Vi går gjennom og diskuterer innspel til kaffepraten.

    • Sjekkeliste for subtasking (5 stemmer):
      • Det er ønskelig å benytte en sjekkliste ved oppdeling av større saker
      • Forslag til sjekkliste:
        • Diskutere løsningsvalg eller andre tekniske valg?
        • Utrulling?
        • Dokumentasjon?
        • Automatisert testing?
        • Hva er hensikten med underoppgaven?
        • Skal det utøves kompetansedeling?
        • Skal det utøves parprogrammering?
        • Har denne underoppgaven noen hindringer?
      • Tiltak: Scrum-mester håndhever bruk av sjekkliste
    • Sjekkliste for gjennomgang av brukerhistorier på planleggingsmøte (4 stemmer):
      • Det er ønskelig å benytte en sjekkliste ved diskutering av brukerhistorier. Sjekklisten tar sikte på å behandle brukerhistorier på et mer overordnet nivå, slik at detaljert diskusjon forekommer ved oppdeling av historier i mindre deler. Således vil beregningen av en saks tidsforbruk være en to-stegs prosess, der man grovestimerer brukerhistorier, og verifiserer estimatets korrekthet ved oppdeling i mindre gjøremål.
      • Forslag til sjekkliste:
        • Parprogrammering?
        • Hvem er teknisk leder for oppgaven?
        • Automastisert testing?
        • Utrulling?
        • Brukerdokumentasjon?
        • Utviklerdokumentasjon?
        • Kompetansedeling?
        • Har vi brukt for mye tid på å diskutere denne brukerhistorien nå?
      • Tiltak: Scrum-mester håndhever bruk av sjekkliste
    • Publisering av meldingar ved prodsetting med twitter-feeden som vart levert for nokre sprintar sidan. Kan vi ta den i bruk? (3 stemmer):
      • Tiltak: Jo får lagt programmet passende sted, eller satt opp organisasjon i Twitter
    • Eksterne avhengigheter. Hvordan løse? (3 stemmer):
      • Tiltak:
        • Team identifiserer hindringer tidligere
        • Scrum-mester følger opp mer effektivt
        • Scrum-mester eskalerer til produkteier tidligere
        • Unngå eksterne avhengigheter
        • Passe på å kommentere i saken (Jira eller annet medium) om hva som er gjort med eksterne avhengigheter
    • Diskutere piroriteringsnivåene i Jira; hvordan brukes de, og er nivåene hensiktsmessige? (2 stemmer):
      • Ønskelig med upvote-funksjonalitet i Jira for å markere interesse for at brukerhistorier skal bli tatt med i sprintplanlegging for å diskuteres
      • Scrum-mester tar opp revisjon av global prioritetsnivå med passende personer
      • Tiltak: Scrum-mester håndterer
    • Samlokalisering med eksterne utviklere (1 stemme):
      • Viktig for å bli kjent og for å få fart i utvikling
      • Tiltak: PO samlokaliserer personell for økt synergieffekt og større samhandlingsrom

     

    Publisert 30. mai 2016 13:05 - Sist endret 26. sep. 2017 11:47