Fokus for neste sprint
Kva vi kom fram til på retrospectiven:
- På labdag i morgon: Teamet definerer ei bestilling for ei arbeidsgruppe med mål å få Stash/PR til å flyte - få sett inn i ei løysing på problemet vi har.
- Teamet tar opp på tenestegruppemøtet i morgon:
- Autodeployering av Brukerinfo, WebID og alt anna Cerebrum-relatert som i dag gjerast manuelt.
- Definere prodsettingsrutiner om andre Cerebrum-tenester, td. Brukerinfo, WebID og jbofh.
- Burde vi hatt deploymentskøer for andre Cerebrum-tenester?
- Automatisk tagging i git ved prodsetting
- Teamet + SM samler deploymentsrutiner for dei ulike tenestene, for å få oversikt. Teamet involverer relevante partar der det er nødvendig i samlinga og ryddinga.
- SM endrer så alle utviklarane får skrivetilgang til master. Teamet er klar over konsekvensane med dette, at ein kan sjekke inn endringar der ved uhell. Du kan pushe direkte utan å måtte gå innom ein approved PR.
- Vi har fast labdagsaktivitet for å rydde i PRs og gamle branches.
Agenda
- SM oppsummerer sprinten, med kommentarar. 10 minutt
- Korleis det gjekk med forrige fokusområder? 30 minutt
- Resten av tida: Diskuterer det teamet meiner er viktigast.
Referat
Har utvida med 30 minuttar, sidan det har vore knapt med tid forrige rundar. Kan slutte før om folk vil det.
Oppsummering frå Sprint Review
25 stories, 20 vart godkjende, 2 vart ikkje godkjende og 3 må bli sett på i ettertid av PO, 80-90% fullført. PO seier at berre ein story ikkje vart godkjend, vi godkjenner stories som fell ut fordi bestiller velger å avslutte den, i dette tilfellet saka om obligatoriske felter.
Vi traff bedre enn dei to-tre siste sprintane.
Anna som kom innom sprinten: Opplæring, Cerebrum-bugs, Digeks-bugs, Trådlauskonto-bug, Personreg-møter, og ikkje minst Pull Request-dag.
Sprint Review gjekk over tida, vi vart ikkje ferdige med å demonstrere alle stories.
Innspel:
- Nokre stories var uklare, til dømes saka om python-warnings. Teamet kunne då sjølv vurdere løysinga, og var spesielt greit fordi det var ein tech story, men slike saker kan fort ta meir tid. Teamet må vere gode på å timebokse basert på oppgitt estimat.
- Vi er gode på å underestimere! Totalt sett er det likevel greit.
- Alle må komme tidsnok til standup!
- Flyten etter resolved er likevel ikkje heilt klar.
Fokus frå forrige retrospective
Bedre oppfølging/flyt av Pull-Requests:
- PO set av ein eller fleire dagar i neste sprint for å rydde opp i gamle PRs
- Teamet ser på korleis merge-flow på labdagen, og vurderer om ein skal teste det ut i neste sprint eller om vi treng ei utredningssak for det.
- Teamet ser på bruk av plugins, filter og/eller e-postutsending på labdag for å gjere det enklare å følge med PRs. Om det ikkje er kome opp noko, tek vi det opp på planleggingsmøtet for ei utredningssak.
- Teamet høyrer med Nettskjema og/eller sender ut e-post til utv-core. jokim sender ut e-post.
- Konkretisering: Det er den som oppretta ein PR som eig den fram til den er Resolved eller lukka, sjølv om folk har kommentert eller ikkje. Opprettaren må følge opp saka fram til den er merga eller lukka.
Fekk vi løyst dette?
Diskuterte mykje rundt dette:
- Pull-Request-dag fungerte bra, er få PRs att, og dei er mykje ferskare.
- Det løyser likevel ikkje varslinga til Stash.
- Joakim og drift burde vore tilstades heile dagen, for å kunne svare på spørsmål rundt mange saker, om dei kan mergast eller ikkje.
- Diskuterte spesielt at Stash har litt manglar. Ønsker bedre varsling og oversikt over PR
- Forslag om å tagge i Git ved prodsetting. Vi kan ta det opp på tenestegruppemøtet i morgon.
- Kom innspel frå Simeon, frå erfaringa å forke i staden for å branche, for å holde det "ekte" repoet meir reint, og unngå mange rotete branches i det offisielle repoet.
- Forslag om å ha fast labdagsaktivitet å rydde i PRs og gamle branches.
- Forslag om å bruke Stash meir, basert på innspel frå Nettskjema. Bruke det nesten som eit forum, eller som XMPP. Varsling fungerer framleis ikkje, så er litt skepsis til om det vil hjelpe, men vi prøver.
Action Items:
- På labdag i morgon: Teamet definerer ei bestilling for ei arbeidsgruppe med mål å få Stash/PR til å flyte - få sett inn i ei løysing på problemet vi har.
- SM endrer så alle utviklarane får skrivetilgang til master. Teamet er klar over konsekvensane med dette, at ein kan sjekke inn endringar der ved uhell. Du kan pushe direkte utan å måtte gå innom ein approved PR.
- Vi har fast labdagsaktivitet for å rydde i PRs og gamle branches.
- Teamet foreslår tagging i git ved prodsetting på tenestegruppemøtet i morgon.
Diskusjon
Vi forsøker "Lean Coffee Retrospective", som er omtrent det vi gjer, med litt reglar:
- Oppsett: To Discuss, Discussing, Discussed(?), Notes, Action Items (AI)
- Heng opp forslag, 3-5 min, maks 2-3 punkt per person
- Presenterer kvart punkt, 30 sekund per punkt
- Prioriterer punkta, 3 strekar per person
- Diskuterer kvart punkt i 8 min, evt. deretter 4, 2, 1 og stopp. Får evt. 5 min ekstra for å avklare Action Items på saka.
Fekk inn forslaga:
- Prodsettingsrutiner og CRBD, oversikt?
- Storskjermen, kva gjer vi med den?
- Resolved versus Approved
- Tematiske "bolker" på Sprint Review
- Størrelse på stories
- Meir tilrettelagt deployment av Personreg
- Versjonering i Jira - bruker vi det no? (affect-version, fixed version)
Nådde berre å diskutere første punktet. Fekk notatane:
- Endringar i rutinedokumenta må varslast. Dei er viktige og kan ikkje endrast utan at folk veit om det.
- Folk er usikre på kor og korleis prodsettingsinformasjon om andre tenester, som Brukerinfo, skal til drift.
- Korleis skal jbofh prodsettast?
- Burde vi hatt fleire deploymentskøer?
Og vart einige om Action Items:
- Teamet tar opp på tenestegruppemøtet i morgon:
- Autodeployering av Brukerinfo, WebID og alt anna Cerebrum-relatert som i dag gjerast manuelt.
- Definere prodsettingsrutiner om andre Cerebrum-tenester, td. Brukerinfo, WebID og jbofh.
- Burde vi hatt deploymentskøer for andre Cerebrum-tenester?
- Teamet + SM samler deploymentsrutiner for å få oversikt. Teamet involverer relevante partar der det er nødvendig.