For at styre Request for Changes (RFC)/ændringshåndtering på NSP er der vedtaget et proces forløb m.h.p. at sikre en struktureret NSP Change Managementproces. Processen er gengivet nedenfor. Beskrivelserne af processen vil løbende blive opdateret.
Processen gælder for alle ændringer til platformen. Driftmæssige problemstillinger (kritiske eller mindre < 10 timer), kan håndtes i et forenkelt flow, hvor de går direkte til operativ planlæging. Alle kan oprette RFC'er/ændringsanmodninger til NSP direkte fra NSPOP. Ændringsanmodning går automatisk til Operatør, der varetager initiel screening og håndtering i forhold til Change Advisory Board (CAB) bestående af SDS, Operatør og QA.
CAB rådgiver NSP forvalter om ændringsanmodningen skal sendes til udviklingsestimering hos leverandører/QA/Drift og igen efter udviklingsestimering om ændringsanmodningen skal sendes videre til planlægning/prioritering.
Processen forløber efter nedenstående flow.
Beskrivelse af proces
| 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" istedet 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. | Ugentlig RfC møde | Ansvarlig: Involveret: | Klar til CAB behandling | SDS-konto |
| Behandling af RfC på CAB - skal opgaven estimeres eller skal der laves analyse? | 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 assignes til RfC - automatisk QA funktion tager løbende kontakt til leverandørene, 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 igang | 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 driftleverandø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 | På CAB møde behandles RfC med estimater, og der kan som udgangspunkt være 3 outcomes:
SDS Productownere bør være involveret i denne beslutning (helst før eller på CAB møde) | Ugentlig CAB møde | Ansvarlig: Involveret: | Klar til planlægning | |
| Overordnet løbende prioritering af backloggen | NSP systemejer 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. | Ad-hoc / løbende | Ansvarlig: Involveret (input fra): | Klar til planlægning | |
| Prioritering/planlægning af RfCer indenfor leverandør og pr. komponenter | SDS productowner har ansvaret for at foretage prioritering indenfor produktet/komponenten SDS productowner har ansvaret for (sammen med involverede) at foretage planlægning af RfC'er Herudover skal der aftales dataoer (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 Leverandørs ressourcesituation, 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 igang | Når QA leverandør igangsætter QA aktiviteter på RfC'en, ændres status til "Under QA" | Ad-hoc | Anvarlig: Involveret: | Under QA | |
| 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æsentere 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 ekst. 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 - .... | |