Noter fra workshop med OS2

Transkript

1 Noter fra workshop med OS2 Exported on 12/10/2017

2 Noter fra workshop med OS2 1 Table of Contents 1 Table of Contents Overordnede noter: Beslutninger og noter til de enkelte kandidater: Kandidat 1: Skæl ind til benet Kandidat 2: Aktivering af de 80% Kandidat 3: Workflow - fælles forståelse og rettigheder Kandidat 4: Det gode issue Kandidat 5: Brugerstyring...6 Table of Contents 2

3 Sted Mandag 4/12 Dokk1, OS2 JIRA Workshop Deltagere aety Kristian Thomsen, Nils Ejby Buch, Rasmus Frey, Henrik Bojsen, Henrik Løvborg, Brian Graversen, Heidi Søndergaard Huber og Terese Lorentzen Årsag til workshop: Strømline brugen af JIRA platformen i OS2, gennemgå OS2 JIRA instans og identificere eventuelle muligheder for optimering Formål: At træffe beslutninger om standard til anvendelse af JIRA i OS2 regi. 2 Overordnede noter: Beslutning - Der skabes to standardmodeller for et JIRA projekt i OS2, ét til KanBan og ét til Scrum 2 x workflow 1 kanban m/backlog status 1 scrum projekter, som ikke passer i modellerne betragtes som unikke indtil videre. Beslutning - backlog oprettes til fremtidige ønsker, der kan besluttes af OS2 JIRA fagruppe Beslutning - Generelt ønske om beskrivelse af OS2 best practice og hvordan funktionaliteter i JIRA kan bruges optimalt. Brugerne ønsker infoside om centrale begreber i JIRA og valgmuligheder Confluence oplagt Ønske om vejledninger til, hvordan gode issues beskrives Ønske om info om, hvordan versioner kan bruges Forslag - Lave klart defineret beskrivelse af JIRA setup og guides med erfaringer fra tidligere projekter. Tænk ikke rigtig og forkert, men fordele og ulemper. Lille udvalg med lette beskrivelser. Cloud deployment: Oplever langsomme svartider særligt om morgen Bliver bedre på sigt, der skiftes til EU-datacenter post januar. Generelle udfordringer Der er ikke et fælles begrebsforståelse af workflow og issues af brugen af JIRA OS2 JIRA bruges både til vedligeholdelse af open source produkter, samt kunde specifikke tilpasninger, hvor der leverandørstyres efter specifik model. Confluence gennemgang blev fjernet grundet tidshensyn Videndelingsplatform i Wiki-format Tillader flere samtidige brugere Tæt integreret med JIRA Generel diskussion OS2 JIRA bruges til 2 formål vedligeholdelse af OS2 produkter her slutter processen med at der comittes til master branch på Github Styring af projekter, hvor OS2 produkterne er i drift hos en specifik kunde Her slutter processen når der er deployet hos en specifik slutkunde Giver behov for procespecifik leverandørstyring Begge scenarier skal kunne håndteres Overordnede noter: 3

4 Til backloggen Der foreslås at skabe JIRA projekttyper, som tager udgangspunkt i de forskellige kontrakter kunne være 3 forskellige modeller. Overvejelse om OS2 JIRA kun bruges til kunde leverandør kommunikation, hvor de tekniske opgaver fastholdes hos leverandøren. Der var argumenter for og imod. for Mindre krav til konfiguration af OS2 jira imod Med tiden skal der integreres til kodeværktøjer Mindre synlighed hos OS2 om leverandørens arbejde 3 Beslutninger og noter til de enkelte kandidater: 3.1 Kandidat 1: Skæl ind til benet Beslutning - how to verify ved transition fra gennemsyn til test, hvor accept kriterier også synliggøres Beslutning - fjerne overflødige felter fra relevante screens for at gøre OS2-JIRA mere uoverskuelig note: Der diskuteres blandt brugere om hvordan standarden i JIRA skal/bør være. Der virker til at være flere opfattelser /behov afhængige af brugernes respektive profession. Beslutning - Kitos udskilles pågrund af særlige behov Beslutning - Epic link, fix version, business value og bestiller kommune på opret screen Beslutning - oprettelse af et særskilt felt til accept kriterier Leverandører vil gerne have acceptkriterier meget detaljeret Udviklere som skal løse udviklingsopgaver, vil gerne have bedre definition af problem fra start, men det kan være vanskeligt at få defineret på tidlig stadie. Det er vigtigt at få defineret fejl klart med tydelige instruktioner om hvad der er galt og hvordan det reproduceres. 3.2 Kandidat 2: Aktivering af de 80% Beslutning - Mail handler og issue collectors forankres i særskilt project med samme navn bare med forlængelsen - brugerønsker Dette project indeholder simpelt workflow med tre statusser Guide skal udarbejdes om, hvordan et OS2 produkt kan få dette oprettet Eksempel oprettes. Differientieret behov. Nogle ønsker issue collector og nogle mail handler. Begge tilbydes til projekter. guide skal udarbejdes Beslutninger og noter til de enkelte kandidater: 4

5 3.3 Kandidat 3: Workflow - fælles forståelse og rettigheder Beslutning - produktion omskrives til leveret prompt for kommentar under transistionen Følgende ansvarlige roller er udpeget til de forskellige kolonner "Skal laves" - kunde "Igang" leverandør "Gennemsyn" leverandør "Test" kunde leverandør flytter til, kunde flytter fra "Færdig" PL/kunde betyder kunde har testet og godkendt Produktion - Kunde (omskrives til leveret) prompt for kommentar under transistionen betyder klar til produktion eller leveret till master branch Brugerne mangler en backlog status til KanBan Der er forskellige holdninger til behov forstatusser, men enighed om at fastlægge et minimum og så afvige når der opstår særskilte behov. Her kan det vurderes om et project skal udskilles til særskilt administration og håndtering. 3.4 Kandidat 4: Det gode issue Der er forskellige forståelser af hvornår en given issue type brugen? KT opsummerer findings fra interview og de opståede problemstillinger deraf Der diskuteres definitioner på tasks og stories. Der gennemgås alle felter og deres relevans udfordres Beslutning - Nedenstående issuetypes er OS2 standard Epic Bruges ikke i stor stil, men repræsenterer en større gruppe funktionalitet Story Bug Task Stories: opgaver med en forretningsværdi som slutbrugeren Tilføjelse af How to verify Opgaver der IKKE giver umiddelbar forretningsværdi. Typisk enablers á la dokumentationsartefakter, opsætning af servere, etc. Guide skal udarbejdes Beslutninger og noter til de enkelte kandidater: 5

6 3.5 Kandidat 5: Brugerstyring Beslutning - Implementering af persmissionskema med 4 roller og én se-alt gruppe Bruger gruppe se-adgang Leverandør Samme permissions som forretningsbruger Forretningsbruger alle ikke kritiske adgange Projektleder projektadministrative rettigheder start/stop sprints, osv. Project administrator Alle rettigheder Rollerne skal sikre at særlige behov kan implementeres fremadrettet uden et større redesign og oprydning. Beslutninger og noter til de enkelte kandidater: 6