Page History
For at styre Request for Changes (RFC) eller /ændringshåndtering på NSP er der vedtaget et proces forløb procesforløb m.h.p. at sikre en struktureret procesNSP Change Managementproces. Processen er gengivet neden fornedenfor. Beskrivelserne af processen vil løbende blive opdateret.
Processen gælder for alle ændringer til platformen, med undtagelse af driftmæssige problemstillinger (kritiske eller mindre < 10 timer), der kan håndtes i et forenkelt flow, hvor de kan adresseres ved at rykke den direkte til planlæging. Driftsmæssige problemstillinger eller andre kritiske ændringer, der ikke kan vente på behandling på CAB-møde, kan håndteres i et forenklet flow. I så fald håndteres godkendelsen via Slack-RFC-kanal med kvittering fra hhv. SDS ARK og Arosii.
For supportsager der skal løses af NSP komponentleverandør gælder det, at Arosii opretter en RFC Jira til leverandør, mens dialog ift. tilbagemelding til indmelder og fortsat håndteres i Netic's Jira som vanligt.
Alle kan oprette RFC'er/ændringsanmodninger til NSP direkte fra NSPOP. Ændringsanmodning går autormatisk automatisk til OperatørSDS, der varetager initiel screening og håndtering i forhold til Change Advisory Board (CAB) bestående af SDS , Operatør og QA, der rådgiver NSP forvalter . CAB tager stilling til, om ændringsanmodningen skal kan sendes til udviklingsestimering hos leverandører/QA/Drift og igen efter udviklingsestimering om ændringsanmodningen skal sendes videre til planlægning/prioritering. Prioritering af ændringsanmodninger sker ikke på CAB men det sker løbende hos PO.
Når eksterne anvendere opretter en ændringsanmodning på NSPOP, som ender som en RFC , er det PO's ansvar at:
- Kontakte indmelder (reporter) om status med information om, at sagen er oprettet som RFC, hvem der er kontaktperson og hvad indmelder kan forvente ift. levering til test og produktion.
- Kontakte indmelder i så god tid som muligt ved væsentlige ændringer, herunder ændringer i funktionalitet og leveringsdatoer til test og produktion.
- Opdatere sagen med information hver gang indmelder er blevet informeret.
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 |
Nuværende Jira roller: Komponentleverandører
NSP suppliers
SDS systemforvaltning
Alle | Åben | SDS-konto |
| Validering/screening af RfC |
RFC går til den PO, der har ansvar for komponent. PO vurderer om formalia er overholdt, og om den skal behandles på CAB. |
Epic kan anvendes til at samle flere RFC'er. 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 der skal være restriktiv adgang til RfC, vælges en anden Security Level
Hvis opgaven er driftsrelateret og < x timer kan RfC flyttes direkte til status "Klar til planlægning" istedet for "Klar til CAB behandling"
PO 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. Driftsmæssige problemstillinger eller andre kritiske ændringer, der ikke kan vente på behandling på CAB-møde, kan håndteres i et forenklet flow. I så fald håndteres godkendelsen via Slack-RFC-kanal med kvittering fra hhv. SDS ARK og Arosii. | Ansvarlig: |
Ansvarlig:
NSP operatør
QA funktion
| 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. SDS ARK vurderer RFC-beskrivelse og noterer på sagerne inden mødet, om der er bemærkninger til indhold. Det er CAB-deltagerne der godkender, at RFC'er kan gå videre i flow. Processen gælder for alle ændringer til platformen. Driftsmæssige problemstillinger eller andre kritiske ændringer, der ikke kan vente på behandling på CAB-møde, kan håndteres i et forenklet flow. I så fald håndteres godkendelsen via Slack-RFC-kanal med kvittering fra hhv. SDS ARK og Arosii. | 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ørene, for at sikre fremdrift i estimeringsopgaven
SDS (det skal aftales med hver enkelt leverandør, hvor meget tid der skal bruges på estimering, og som ikke er en del af udviklingssprint) - Derudover skal praktikken aftales omkring estimeringsopgaver med hver enkelt leverandør
| Ugentlig CAB møde | Ansvarlig: |
SDS PO Involveret: |
systemejer |
QA funktion NSP komponentleverandør | Klar til udv. estimering | Leverandørkonto eller funktionskonto |
| Leverandør igangsætter estimering af udvikling |
Leverandøren skal have besked på mail, når der ligger opgave klar til udv. estimering
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 |
| vurderer estimat og solution sketch | Når QA påbegynder opgaven, ændres status til "Under QA/drift estimering", så det er synligt hvilke estimeringsopgaver der er |
i gang. "Klar til til godkendelse" sættes, eller der indledes drøftelse mellem QA og komponentleverandør. | Dagligt | Ansvarlig: |
NSP driftsleverandør
| Under QA/drift estimering |
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
Samlet estimat oprettes i standard Jira felt "Estimated Hours"
"Klar til til godkendelse" sættes
Ansvarlig:
QA funktion
Involveret:
NSP driftsleverandør
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. SDS ARK vurderer RFC-solution sketch og estimat og noterer på sagerne inden mødet, om der er bemærkninger til indhold. Det er CAB-deltagerne der godkender, at RFC'er kan gå videre i flow. |
På CAB møde behandles RfC med estimater, og der kan som udgangspunkt være 3 outcomes:
|
| Ugentlig CAB møde | Ansvarlig: |
SDS PO Involveret: SDS |
ARK QA-funktion NSP komponentleverandør | Klar til planlægning | |
| Overordnet løbende prioritering af |
| backlog |
SDS 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: |
SDS PO Involveret (input fra): |
SDS productownere
|
NSP
driftsleverandør | Klar til planlægning |
|
| Prioritering/planlægning af RfCer indenfor leverandør/kontrakt og pr. |
| komponent | SDS |
PO har ansvaret for at foretage prioritering indenfor produktet/komponenten |
. SDS |
PO har ansvaret for (sammen med involverede) at foretage planlægning af |
RfC'er |
Disse skal koordineres på tværs af de involverede
| Månedlig planlægningsmøde | Ansvarlig: |
PO Involveret: |
QA funktion | 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: |
PO Involveret: |
NSP operatør
arkitekt |
Komponentleverandør | 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: |
PO |
QA funktion | 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 PO | 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 |
oprettes release-sag til den eller de relevante RFC'er indeholdt i release. | 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. RfC kan også være analyse, dokumentation, eller ændringer til testværktøjer, der ikke passer til status 'i drift'. | 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 - .... |