Ce este metoda MoSCoW Knowledge compact - t2informatik

Care este metoda MoSCoW, ce categorii știe și care sunt avantajele și dezavantajele acesteia?

Prioritizarea cu patru categorii

Metoda MoSCoW este un proces de prioritizare în patru etape. Este utilizat în principal pentru a clasifica cerințele; în principiu, este, de asemenea, potrivit, de exemplu, pentru prioritizarea obiectivelor, activităților sau cererilor de schimbare. Dai Clegg este considerat inventatorul metodei MoSCoW, care a folosit prima dată metoda la Oracle în 1994 ca parte a așa-numitei metode de dezvoltare a sistemelor dinamice (DSDM). Astăzi MoSCoW - denumit și principiul MoSCoW, analiza sau stabilirea de priorități - este printre altele Utilizat în analiza afacerii, ingineria cerințelor, managementul proiectelor și dezvoltarea de software.

Literele majuscule individuale reprezintă patru categorii:

M. = M.trebuie (ai)
S. = S.ar trebui (a avea)
C. = C.ar trebui (a avea)
W. = W.on’t (have)

Adesea, un acronim este utilizat în cursul metodei MoSCoW; Deoarece literele minuscule sunt folosite doar pentru lizibilitate, acest lucru nu este în întregime corect, dar folosind o, principiul poate fi pronunțat ca capitalul rusesc.

Cele patru categorii de MoSCoW

Ce înseamnă exact cele patru categorii?

M.ust (have) - categoria pentru cerințele „trebuie”. Acestea sunt considerate inegociabile și nu ar trebui să intre în conflict cu alte cerințe obligatorii. Dacă utilizați Corpul de cunoștințe pentru analiza afacerii - BABOK pe scurt - acestea ar trebui să fie, de asemenea, complete, uniforme, corecte, implementabile, schimbabile, clare și testabile.

S.hould (have) - categoria pentru cerințele „ar trebui”. În mod ideal, cerințele care ajung în această categorie ar trebui, de asemenea, implementate. Cu toate acestea, deoarece prioritatea este mai mică decât cerințele „trebuie”, care trebuie, de asemenea, să fie implementate întotdeauna cu prioritate, poate avea loc implementarea în versiunile sau proiectele ulterioare.

C.ould (have) - categoria pentru cerințele „pot”. Ele pot fi implementate după ce au fost implementate cerințele „trebuie” și „trebuie”. Prin urmare, sunt denumiți și „plăcut să ai”. În cazul blocajelor de timp sau al conflictelor de resurse, aceste cerințe sunt primele amânate sau neimplementate.

W.on’t (have) - categoria reprezintă cerințe care nu sunt implementate. Alternativ, acesta va fi W. de asemenea ca W.ar putea - ar fi bine dacă ar putea fi implementat în curând - sau W.furnică - este dorită, dar interpretată într-un alt plan, proiect sau versiune. În general, se recomandă ca cerințele să fie documentate și în această categorie, deoarece acest lucru face posibilă înțelegerea dacă a fost deja înregistrată o cerință aparent nouă. În plus, cerințele documentate pot servi drept sursă în proiectele viitoare.

În practică, atât cerințele „trebuie”, cât și „trebuie” ajung, de obicei, în documente suplimentare, cum ar fi specificațiile cerințelor sau cazurile de afaceri. Cu toate acestea, cerințele opționale și cerințele care nu pot fi implementate rămân de obicei în restante interne, liste sau instrumente.

Avantajele și dezavantajele metodei MoSCoW

Metoda MoSCoW oferă câteva avantaje clare:

Există o clasificare simplă a cerințelor - ideal în coordonare cu părțile interesate. Utilizarea cuvintelor Trebuie, Ar trebui, Ar putea și Nu va oferi claritate în orice moment cu privire la semnificația categoriilor.
Clasificarea cerințelor (sau a obiectivelor, sarcinilor, cererilor de schimbare etc.) are ca rezultat o succesiune naturală de implementare.
Principiul din spatele metodei este foarte ușor de înțeles, astfel încât părțile interesate și dezvoltatorii pot găsi cu ușurință un numitor comun.

Pe de altă parte, metoda MoSCoW are și unele dezavantaje:

Sugestii:

Există o interpretare alternativă a minusculelor o: dacă sunt înțelese ca „sau” sau „sau”, apar două categorii opuse, adică M.ust Or S.ar trebui la fel de bine C.ar putea Or W.ould or. W.pe t.