Page History
...
| Aktivitet | Beskrivelse (aktivitet) | Frekvens | Roller | RfC status | Jira assignment automatisk |
|---|---|---|---|---|---|
| NSP aktør opretter Request for Change i SDS jira | Interessent opretter RfC i SDS Jira med nødvendige oplysninger | Ad-hoc | Alle | Åben | SDS-konto |
| Validering/screening af RfC | RFC går til den PO, der har ansvar for komponent. RFC'er uden komponent behandles af GNAI. PO/GNAI vurderer om formalia er overholdt, og om den skal behandles på CAB. Hvis flere komponenter nedbrydes RfC i flere RfC'er med oprettelsen af en overordnet Epic/Roadmap opgave. Hvis ikke komponent, så registreres Leverandør. Hvis flere leverandører, skal der oprettes flere RfC'er under en Epic/Roadmap opgave. Enten "component" og/eller leverandør skal være udfyldt - da vi skal anvende disse til vores filtreringer i boards. Hvis opgaven er driftsrelateret og < 10 timer kan RfC flyttes direkte til status "Klar til planlægning" i stedet for "Klar til CAB behandling" PO /GNAI sørger for, at RFC'er til CAB er sendt videre i flow senest 24h før CAB-møde. I særtilfælde kan sager gå på CAB, selvom de ikke er sendt videre inden for 24h. Det kræver direkte kontakt fra PO til ARK. | Ugentlig RfC møde | Ansvarlig: | Klar til CAB behandling | SDS-konto |
Behandling af RfC på CAB - skal opgaven estimeres eller skal der laves analyse etc.? Sager til behandling på CAB skal være i denne status min. 24t før mødet af hensyn til CAB-forberedelse. I særtilfælde kan sager gå på CAB, selvom de ikke er sendt videre inden for 24h. Det kræver direkte kontakt fra PO til ARK. | Formalia til RfC er overholdt, og klar til behandling i CAB. SDS ansvarlig skal identificeres og registreres (enten før eller på CAB mødet) Leverandøren (Lead på component eller "Leverandør") skal tildeles RfC - automatisk QA funktion tager løbende kontakt til leverandørerne, for at sikre fremdrift i estimeringsopgaven | Ugentlig CAB møde | Ansvarlig: Involveret: | Klar til udv. estimering | Leverandørkonto eller funktionskonto |
| Leverandør igangsætter estimering af udvikling | Når leverandøren påbegynder opgaven, ændres status til "Under udv. estimering", så det er synligt hvilke estimeringsopgaver der er i gang | Dagligt | Ansvarlig: Involveret: | Under udv. estimering | |
| Estimering af udviklingsaktivitet | Leverandøren af opgaven (enten Lead på component eller "Leverandør") skal lave et estimat på RfC. Dette påføres feltet "Original estimat" Løsningsforslag beskrives i Solution Sketch feltet Når leverandøren har udarbejdet leverandør estimat - flyttes den til "Klar til QA/drift estimering", og assignes automatisk til QA funktionskonto | Dagligt | Ansvarlig: Involveret: | Klar til QA/drift estimering | QA |
| QA igangsætter estimering af QA + drift | Når QA påbegynder opgaven, ændres status til "Under QA/drift estimering", så det er synligt hvilke estimeringsopgaver der er igang. | Dagligt | Ansvarlig: Involveret: | Under QA/drift estimering | |
| Estimering af QA + drift aktiviteter | QA leverandør skal foretage estimering af QA, og i evt. samarbejde med driftsleverandør foretage estimering af idriftsættelsesopgaver. Felterne QA estimat og Idriftsættelsesestimat påføres "Klar til til godkendelse" sættes | Dagligt | Ansvarlig: Involveret: | Klar til CAB godkendelse | SDS-konto |
Godkendelse / afvisning af RfC Sager til behandling på CAB skal være i denne status min. 24t før mødet af hensyn til CAB-forberedelse. | På CAB møde behandles RfC med estimater, og der kan som udgangspunkt være 3 outcomes:
SDS Product ownere bør være involveret i denne beslutning (helst før ellers på CAB møde) | Ugentlig CAB møde | Ansvarlig: Involveret: | Klar til planlægning | |
| Overordnet løbende prioritering af backloggen | NSP PO har ansvaret for at foretage overordnet forretningsmæssig prioritering af backloggen (alle RfC'er med status "Klar til planlægning") - hvilke produkter/komponenter har vigtigste prioritet i den kommende periode. Den overordnede prioritering af NSP ressourcer (haster og/eller vigtig)? Placering i kolonnen "Klar til planlægning" er afgørende for prioritering. PO har ansvaret for at orientere ekstern anvender om status, såfremt denne ikke har adgang til jira. | Ad-hoc / løbende | Ansvarlig: Involveret (input fra): | Klar til planlægning | |
| Prioritering/planlægning af RfCer indenfor leverandør og pr. komponenter | SDS product owner har ansvaret for at foretage prioritering indenfor produktet/komponenten SDS product owner har ansvaret for (sammen med involverede) at foretage planlægning af RfC'er Herudover skal der aftales datoer (klar til QA, leveret til drift, Test1, Test2 og I drift) Disse skal koordineres på tværs af de involverede | Månedlig planlægningsmøde | Ansvarlig: Involveret: | Planlagt | |
| Sprint planlægning | Med udgangspunkt i den kontraktuelle timeramme hos Leverandører, skal der foretages planlægning af, hvilke RfC'er som skal udvikles i det kommende sprint (med udgangspunkt i generel NSP prioritering, og prioritering indenfor hver komponent). Når RfC er aftalt skal udvikles i det kommende sprint, ændres status til "Klar til udv. i sprint". | Månedlig planlægningsmøde | Ansvarlig: Involveret: | Klar til udv. i sprint | Leverandørkonto eller funktionskonto |
| Start af aktiviteter | Når aktiviteter påbegyndes ændres status til "Under udvikling" I denne tilstand foretages der aktiv udvikling og løbende QA af løsningen | Månedlig planlægningsmøde | Ansvarlig: Involveret: | Under udvikling | |
| Levering til QA | Når leverance er klar til QA, flyttes RfC til "Leveret til QA". Der gives besked til QA funktionskontoen når dette er sket | Ad-hoc | Ansvarlig: Involveret: | Leveret til QA | QA |
| QA af leverance i gang | Når QA leverandør igangsætter QA aktiviteter på RfC'en, ændres status til "Under QA" | Ad-hoc | Ansvarlig: Involveret: | Under QA | |
| QA godkendt release i gang | QA leverandøren har godkendt en given RFC, men der afventes yderligere RFC'er før der kan laves en release til driften | Ad-hoc | Ansvarlig: QA funktion Involveret: SDS Product owner | QA Godkendt - afventer release | |
| Levering til drift | Når QA leverandør har accepteret leverancen og leveret leverancen til NSP driftsleverandør, ændres status til "Leveret til drift Der gives besked til NSP driftsleverandør når dette er sket | Ad-hoc | Ansvarlig: Involveret: | Leveret til driftsleverandør | NSP driftsleverandør funktionskonto |
| Deploy til Test1 | Driftsleverandør foretager deploy til Test1 | Ad-hoc | Ansvarlig: Involveret: | Deployed Test1 | |
| Deploy til Test2 | Driftsleverandør foretager deploy til Test2 | Ad-hoc | Ansvarlig: Involveret: | Deployed Test2 | |
| Idriftsættelse | Driftsleverandør foretager deploy til PROD | Ad-hoc | Ansvarlig: Involveret: | I drift | SDS-konto |
| ØVRIGE: | |||||
| Udført | Hvis RfC ikke repræsenterer en traditionel change (som skal leveres til driften) kan RfC afsluttes hvor som helst i processen, hvis det ikke giver mening at fortsætte (f.eks. en tilslutningsaftale eller lign). Der skal være en begrundelse registreret. | Ad-hoc | Alle | Udført | SDS-konto |
| Afvist | RfC kan til enhver tid i processen afvises med en begrundelse | Ad-hoc | Alle | Afvist | SDS-konto |
| På hold | Hvis der mangler afklaringer, og disse ikke er på trapperne kan sagen udskydes til et bestemt tidspunkt i fremtiden. | Ad-hoc | Ansvarlig: | På hold | SDS-konto |
| Afventer ekstern part | Anvendes kun i de situationer hvor der ikke længere er flow i opgaven pga. eksterne afhængigheder | Ad-hoc | Ansvarlig: Komponentleverandør | Afventer ekst. part - .... | |