MoSCoW módszer

A MoSCoW módszer olyan technika, amelynek célja az igények vagy követelmények rangsorolása a projektmenedzsment és a szoftverfejlesztés támogatása szempontjából . A cél az, hogy a projektvezető és az ügyfél megállapodjanak a feladatok fontosságáról a határidők tekintetében.

A MoSCoW rövidítés nagybetűi a következőket jelentik :

• M  : ennek meg kell lennie, vagyis „meg kell tenni” (létfontosságú).
• S  : ennek meg kell lennie, ha csak lehetséges, vagyis lehetőség szerint meg kell tenni (elengedhetetlen).
• C  : ezt megteheti, ha ez nem befolyásol mást, megtehető mindaddig, amíg nincs hatással más feladatokra (kényelem).
• W  : nem lesz rá ideje, de a jövőben szeretné, ezúttal nem, de később (luxus, ez a költségkeret-optimalizálási zóna).

Az o-k a MoSCoW-ban csak azért vannak hozzáadva, hogy a betűszó kimondható legyen, és az esetek többségében kisbetűvel írják, jelezve, hogy nem felelnek meg a szavaknak. Néha azonban a MOSCOW írás, nagybetűvel írva.

Valamennyi követelmény fontos, de azokat prioritásként kell kezelni a tulajdonos érdekeinek garantálása érdekében. A fejlesztők az M, majd az S és a C. feladatokra összpontosítják munkájukat. Ha azonban a határidőket nem lehet betartani, akkor először a C követelményeket töröljük, majd az S követelményeket követjük.

A MoSCoW módszer előnye a betűszó jelentésben rejlik, amely érthetőbb, mint más prioritás-meghatározási technikák, például a magas, közepes és alacsony.

Történelmi

Ezt a prioritási módszert Dai Clegg találta ki, és az agilis dinamikus rendszerfejlesztési módszer (DSDM) projekt megközelítés részeként először széles körben alkalmazta .

A MoSCoW módszert gyakran használják időblokkokban , ahol a legfontosabb követelményekre összpontosítva határidőt szabnak. Ezért gyakran használják olyan szoftverfejlesztési megközelítéseknél, mint a Scrum , a gyors alkalmazásfejlesztés (RAD) és a DSDM .

Példa

Vagy egy képzeletbeli feladatkezelő szoftver, amely a következő funkciókat tartalmazza:

1. A felhasználók bejelentkezhetnek a szoftverbe.
2. A felhasználóknak képesnek kell lenniük arra, hogy e-mailben új jelszót kérjenek, ha elfelejtették.
3. A felhasználók feladatokat hozhatnak létre.
4. A felhasználó e-mailt küldhet a szoftverhez, és ez az e-mail a megfelelő feladathoz lesz csatolva.
5. Amikor a felhasználó rákattint a szoftverbe mentett telefonszámra, a szám automatikusan tárcsázásra kerül.

A projektmenedzser és az ügyfél közötti workshop a közös és közös megértést nyújtja a prioritásokról.

Például :

1. Must: kötelező hitelesíteni, figyelembe véve az ügyfél biztonsági házirendjét
2. Kell: nagyon kívánatos, hogy újracsatlakozzon az alkalmazáshoz, de ez nem része az alkalmazás funkcionalitásának kritikus útvonalának.
3. Kell: ez a "feladatkezelő szoftver" létjogosultsága!
4. Lehetséges: érdekes funkcionalitás, de ami továbbra is a kényelem területén van, anélkül is dolgozhatunk.
5. Nem: remek ötlet, de az alkalmazás egy későbbi verziójában lefedhető.

Minden kérdés szempontjából, de megpróbáltuk itt korlátozni magunkat, hogy 50% must érdekében, hogy képes játszani a többi prioritási szintekbe; egyébként az a kockázat, hogy minden kötelezővé válik , más szóval, hogy minden prioritás.

Hivatkozások

1. (in) Dai Clegg és Barker, Richard ügyben eljárás Fast Track: A RAD megközelítés , Addison-Wesley ,2004. november 9, 207  o. ( ISBN  978-0-201-62432-8 )
2. (in) Kurt Bittner és Spence, Ian, Használati eset modellezése , Addison-Wesley Professional,2002. augusztus 30, 347  p. ( ISBN  978-0-201-70913-1 , online olvasás )