Visure-løsninger


Support
Tilmeld
Login
Start gratis prøveversion

Krav Status & Anmodningsændringer

Krav Status & Anmodningsændringer

Indholdsfortegnelse

Krav Status

For at være på toppen af ​​projektet skal du spore hvert krav gennem dets levetid. Du kan endda tildele en attributværdi for at gemme disse oplysninger for ekstra sikkerhed og nøjagtighed. Denne type statussporing vil hjælpe med at reducere det almindelige dilemma med softwareprojekter - fejlagtigt hævde, at det er "halvfems procent udført". Ethvert krav skal have en af ​​disse statusser inden for en given tidsramme:

  • Advokate (nogen støttede det kraftigt)
  • Godkendelsesprocessen var vellykket, og tildelingen er blevet placeret på en basislinje.
  • Efter omhyggeligt udformning, scripting og test af koden implementerede vi den.
  • Når kravet gennemgik og bestod sine tests, blev det verificeret for vellykket integration i produktet.
  • Dette krav vil blive opfyldt på et senere tidspunkt.
  • Du beslutter dig for at slette det og ikke implementere det.
  • Afvist (konceptet fik aldrig grønt lys)

Udover de førnævnte statusmuligheder kan andre statusser overvejes. Nogle kan vælge en "Reviewed"-status for at validere deres krav, før de tilføjer dem til baseline-konfigurationer. Alternativt kan organisationer bruge "Leveret til kunden" som et middel til at bekræfte, at de har frigivet kravet intakt og korrekt.

Hvis du spørger til en udviklers fremskridt, svarer han måske, at der er 87 krav til netop dette projekt. 61 er allerede blevet bekræftet, og 9 er på plads, men afventer stadig bekræftelse, mens 17 mangler at blive afsluttet. Det er dog vigtigt at bemærke, at disse anmodninger ikke alle stemmer overens, når det kommer til størrelse eller effekt på kundetilfredshed; de kan også kræve forskellige mængder af indsats. Som projektleder ville jeg ikke være i tvivl om, at vi havde en præcis forståelse af delsystemets størrelse, og hvor tæt det var på færdiggørelsen. Dette er meget mere effektivt end blot at sige "Jeg er omkring halvfems procent færdig". Med et overordnet billede af fremskridt kan jeg trygt sige "det ser godt ud!"

Skift anmodninger

For at opnå en vellykket kravstyring skal din organisation tage sig af hver enkelt kravtilføjelse, sletning og ændring. Dette vil gøre dig i stand til at spore status såvel som implikationerne af alle ændringsanmodninger. Du kan også bruge disse data til at besvare flere forespørgselsspørgsmål såsom:

  • Hvor mange anmodninger om ændring er der blevet fremsat inden for den angivne tidsramme?
  • Hvor mange af anmodningerne er blevet besvaret, og hvor mange er stadig uafklarede?
  • Hvad var godkendelsesgraden for anmodninger, og hvor mange procent blev afvist?
  • I hvilket omfang brugte teamet energi på at udføre hver autoriseret ændring?
  • Hvad er det typiske tidsrum, hvor anmodninger forbliver åbne?
  • Hvor mange elementer (f.eks. krav eller artefakter) påvirkes i gennemsnit af hver indsendt ændringsanmodning?

Sørg for, at du sporer eventuelle ændringer, der er foretaget under udviklingsprocessen, efter at du har angivet en basislinje for hver udgivelse. Husk, at én ændringsanmodning kan have en effekt på adskillige krav af forskellig art (brugerorienteret, funktionel og ikke-funktionel). For at vurdere, hvor mange ændringer der blev gennemgået i en bestemt periode, skal du dividere antallet af ændringer med det samlede antal krav forud for denne periode (som når du definerer din basislinje).

Vi ønsker ikke helt at fjerne ustabiliteten i kravene. Når alt kommer til alt, er der ofte en legitim begrundelse for at ændre dem. Men samtidig skal vi sikre, at vores projekt kan håndtere ændringer og stadig opfylde sine forpligtelser. At komme tættere på færdiggørelse medfører ekstra omkostninger, når der ofte foretages ændringer; dette gør det svært at afgøre, hvornår du vil frigive dit produkt til verden! Efterhånden som udviklingen skrider frem, bør de fleste projekter blive mere modstandsdygtige over for ændringer; med andre ord, hastigheden for accept af ændringer skal gradvist falde, indtil den når nul, når udgivelsen er færdig. En iterativ tilgang giver teams flere chancer for at inkorporere forbedringer i senere iterationer, mens de stadig holder sig på sporet med hver cyklus tidslinje.

Hvis dit team bliver oversvømmet med ændringsanmodninger, er chancerne for, at udløsningsprocessen ikke var omfattende, eller at ideer fortsætter med at opstå, efterhånden som projektet skrider frem. Som sådan er det vigtigt at holde styr på, hvor disse ændringer kommer fra marketing, brugere, sælgere, ledelsesteams osv. At holde styr på disse oplysninger vil hjælpe dig med at bestemme, hvem og hvad der skal være opmærksom på for at minimere oversete krav og forhindre fejlkommunikation hen ad vejen.

Når ændringsanmodninger forbliver uløste over en længere periode, er det en klar indikation af, at din ændringshåndteringsproces har brug for opmærksomhed. Jeg har personligt været vidne til en organisation, der havde anmodninger om forbedringer, der var flere år gamle og stadig afventende. For at få projektlederen til at prioritere deres energi på de vigtigste poster i efterslæbet, bør dette team tildele specifikke åbne anmodninger til planlagte vedligeholdelsesudgivelser og konvertere andre langsigtede udskudte ændringer som afviste. På denne måde kan de lettere tage fat på det, der er væsentligt og presserende først, før de løser mindre presserende spørgsmål.

Tid og indsats

For at sikre optimal ydeevne anbefaler vi på det kraftigste, at du registrerer den tid, dit team bruger på kravtekniske opgaver. Dette omfatter udarbejdelse af kvalitetskrav og styring af ændringer, sporing af fremskridt, oprettelse af sporbarhedsdata og andre aktiviteter relateret til denne proces.

Folk spørger mig ofte, hvor meget tid og energi der skal dedikeres til et projekts fornødenheder. Dette svar afhænger i høj grad af størrelsen, teamet, organisationen, der bygger det, og dets formål. At holde styr på din indsats, der er investeret i kritiske opgaver til projekter som disse, kan hjælpe dig med bedre at planlægge fremtidige med nøjagtige skøn.

Hvis dit team tidligere har gennemført et projekt og allokeret 10 % af sin tid til kravene, har du måske ved eftertanke bemærket, at kvaliteten af ​​disse krav kunne forbedres meget. Hvis du står over for et andet lignende projekt, vil det være klogt for projektlederen at sikre, at der bliver ydet mere for at skabe grundige specifikationer - mere end ti procent af de samlede tilgængelige ressourcer burde være tilstrækkeligt!

Mens du indsamler og analyserer data, skal du sammenligne projektudviklingsindsatsen med et mål for produktstørrelse. Dine dokumenterede krav vil give en idé om dens samlede størrelse. For at være mere præcis kan du korrelere indsats for at tælle testbare individuelle specifikationer, use case-punkter eller funktionspunkter – hvad end der er proportionalt med dit produkts målinger. Ved at indsamle størrelsesrelaterede data for dit produkt og notere den tilhørende implementeringsindsats, kan du formulere nøjagtige estimater som forberedelse til lignende fremtidige projekter.

Frygt kan blive hængende i manges sind; frygt for, at udvikling af et softwaremåleprogram vil stjæle værdifuld tid fra væsentlige opgaver. Tværtimod kræver implementering af et effektivt og målrettet metrisk system ikke for meget indsats eller energi. Alt du skal gøre er at opbygge en grundlæggende infrastruktur til indsamling og analyse af data, samt opfordre dine teammedlemmer til at logge nogle relevante detaljer om deres arbejdsaktiviteter. Når du skaber en kultur baseret på målinger i din virksomhed, er det utroligt, hvad man kan lære gennem denne metode!

Glem ikke at dele dette opslag!

Top