Fokusområder for neste sprint
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.
Referat
Frå oppsummering frå ein runde rundt bordet:
- Eksterne avhengigheter var framleis eit problem i denne sprinten også
- Lappar var tidvis i fri flyt på tavla
- Vanskeleg å holde orden, det var mange saker som det var venting i, og som difor ikkje kunne flyttast. Dette gjorde også at ein holdt på med mange saker samtidig, så det var vanskeleg å holde orden i eige haue.
- Vi har framleis samme problema som vi har tatt opp på tidlegare retrospectiver.
- Forslag om å legge inn fleire typar avhengigheter på saker, basert på kor kritiske dei er.
Folk skreiv deretter opp kva som er viktigaste tema og hang i prioritert rekkefølge på tavla. Det som kom opp:
- Oppfølging av Pull-Requests (spesielt kommentarar)
- Følge opp tidlegare retrospectives
- Manglande testmiljø for integrasjonar, f.eks. AD og SAP. Ofte manglande tilgang til test-system. Uklart driftsansvar - kven eig miljøet.
- Eksterne avhengigheter. Korleis markere, prioritere, handtere?
- Studentane og standup
- Bedre markering av krav. Hvis en story har krav - så må det med i storyen.
- Standup - straff?
- Eksterne som kjem inn på rommet
- Færre småsaker på Sprint Review?
- Fokusfaktor
Vi starta deretter på toppen av lista og diskuterte så langt vi rekker. Fokuset var å komme med konkrete tiltak for forbedringar.
Oppfølging av Pull-Requests (spesielt kommentar)
Har utfordringar med at PRs vert hengande. Får ikkje med seg om nokon har kommentert, eller om nokon har oppdatert ein PR. Når ei sak går til Pull Request, er den i limbo fordi ingen eig den - vi treng avklaring kven som eig PR. Er i tillegg også ei utfordring med merging - ikkje alle kan merge, så stopper opp.
Forslag om å endre e-postvarslinga i Stash, ved å legge til den som oppretta branchen sitt brukarnamn i subject. Må sjekke om det er mulig. Kan då filtrere i eigen innboks så du finn kommentarar for dine pull requests. Burde kunne få noko visning av Pull Requests i Jira. Får altfor mykje e-post til at ein greier å følge med på kva som skjer der.
Ville også hjelpe å redusere antalet eksisterande PRs. Spesielt i Cerebrum-repoet ligg det no rundt 30 gamle PRs, som er vanskelege å ta seg av.
Har ikkje funne noko filter for å finne sine PR som har endra seg sidan "sist". Kanskje det finnast plugins for slikt, evt at vi bruker REST-grensesnittet direkte for å få til denne funksjonaliteten.
Diskuterte også å endre workflow - code review og prodsetting er to forskjellige ting, så burde ha eit skille på dette. Kom nokre forslag:
- Utviklarane bytter til å bruke branch dev, som betyr "approved by devs", mens master betyr "approved by PO". Dette gjer at vi må endre litt i måten vi utvikler på, men ikkje i prodmijløet.
- Vi kan begynne å lage PRs som ikkje går til master, men til eigne stable/CRB-XXX. Då kan vi få avslutta PRs ved å merge dei, mens PO kan deretter be om å få merga stable-branchen inn til master når det er blitt acka og klart for prod. Denne metoden gjer at funksjonalitet kan bli merga inn med mindre avhengigheter enn å bruke ein felles dev-branch.
Kom også eit forslag om å bruke statusfeltet i Jira/Stash for å markere kva som kan gjerast med PRs per sak.
Endte opp med tiltaka som er beskreve i Fokusområder for neste sprint lenger oppe.
Oppsummering frå Sprint Review
Saker som vart godkjende:
- DDF-69 - Utviklingsmiljø RHEL6
- DDF-91 - Staging-server
- CRB-691 - TSD: Vise subnett per maskin
- CRB-695 - Fjerne gamal ePhorte-kode
- DDF-92 - Feil navn på kontraktsvariant - men her kom det ein kommentar frå PO om at til- og frå-dato burde flyttast ut av tittelen. Dette er ei lita justering som bør gjerast.
- CRB-700 - EIS FAQ
- CRB-692 - EIS autotesting
- CRB-696 - Saksbehandler per enhet
- CRB-701 - SAP2BAS privatmobil
- CRB-702 - Glemt passord ansatte - brukerveiledning
- CRB-704 - person-info sist sett
- CRB-677 - NMH fagområdeendring
- CRB-698 - EIS designdokument - Godkjent, men Tobias frå Cerebrum meldte seg frivillig til å lese over dokumentet og komme med tilbakemeldingar.
- CRB-693 - Oppdatere roller i EIS
Saker som blir tatt med vidare:
- CRB-703 - Webside for nye - Savna lenke til designdokumenta til UAIT, og at portalen gjeld for heile UAIT og ikkje berre Cerebrum. Tek den med vidare i neste veke, så den er på plass før Simeonov kjem. Dagfinn frå Nettskjema tipsa oss også om deira dokumentasjonsoversikt, for å unngå at dokumentet dør ut.
- CRB-699 - EIS brukerdokumentasjon - Treng litt meir arbeid, inneheld litt TODOs som bør takast no.
- CRB-697 - EIS: Overlevering til drift
- CRB-694 - Oppdatere tilgangskoder i EIS - Feil på ePhorte-webservice-sida må fiksast. Gjenstår nok veldig lite arbeid frå vår side, men det må testast at det fungere.