Bármely beszélgetés a szoftverfejlesztési folyamatokról néhány klasszikus megközelítésen alapul, hogyan lehet létrehozni a modern szoftvert. Meg kell állapítanunk egy bizonyos gyakoriságot, hogy a termékeket a várható gyakorisággal szállítsuk a piaci igények figyelembevételével. Az iterációs hossznak tükröznie kell a termék backlog változásokhoz való alkalmazkodás szükséges sebességét. Úgy tűnik, hogy a prioritások kezelésének megközelítése teljesen intuitív, és nem kell mélyrehatóan megértenie a szabványosítást, hogy a szoftverfejlesztésben használhassa. Mindazonáltal bármely folyamat létrehozása minden csapattag számára általános elveket jelent. És itt vannak a komplikációk: hogyan magyarázzuk el bármely csapattag számára, hogy mit jelent egy feladat vagy termék hiba mellett néhány számjegy vagy szó? Mindig lehetséges saját prioritási rendszert találni, de ez minden új csapattag számára szükségessé teszi a rendszer elveinek magyarázatát. Ha a projekt nagy, és sok új munkatársa van, akkor ez probléma. Ezért könnyebb használni néhány időt tesztelt nemzetközi szabványt vagy megközelítést. Ebben a cikkben szeretném megvitatni a MoSCoW prioritási módszer használatát a termékfejlesztésben, mint a tényleges leggyakoribb módszert az iterációk során végzett munka egyszerűsítésére, amely gyors és mérhető eredményeket eredményez. Illusztrációként egy példát adok a testreszabott prioritási módszerről és a problémákról, amelyekkel ezzel a megközelítéssel szembesültem, majd belevetjük magunkat a MoSCoW módszer lebontásába, hogy minden prioritást élő példákkal mérlegeljünk. A cikk hasznos lehet a termékmenedzserek vagy bárki, aki a jól működő termékfejlesztési folyamatot követi. Élvezze a személyre szabott megközelítést a tétel prioritása tekintetében Nagyon régen, egy termékcsapatban megpróbáltunk megoldani egy problémát a fejlesztési ciklusunkban a tételi prioritásokkal. Maga a folyamat nagyon éretlen volt: a végrehajtási határidőket gyakran megsértették, a csapatnak túlórát kellett dolgoznia, és a termékkiadások nem voltak kielégítő minőségűek. Abban a pillanatban numerikus prioritásokat használtunk 1-2-3-4 és egyáltalán nem segítettek. Aztán úgy döntöttünk, hogy racionalizáljuk a csapattagok közötti kommunikációt, és bevezettünk egy további prioritást „5”. Ez a prioritás a legmagasabb prioritássá válna, fontosabb, mint „1”, és azt jelentené, hogy „showstopper” - a jegyet vagy tételt, amelyet az iterációs backlog bármely más feladata ellenére Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. Természetesen a prioritási módszer nem volt az általános probléma ebben a folyamatban. A tervezéssel, a kockázatkezeléssel és a stratégiával kapcsolatos megközelítésben alapvető kérdések merültek fel. De ha sok kihívás áll az asztalra, a saját homályos módszertanának feltalálása nem tűnik a legjobb döntésnek. A „MoSCoW” megközelítés bevezetése Néhány szabvány szigorúan kodifikálva van a nemzetközi legjobb gyakorlatú RFC-kben az olyan szervezetektől, mint az IETF vagy az IEEE, míg mások saját jogukban szabványokká váltak.Az, amit szeretnék bevezetni, az utóbbi kategóriába tartozik.A MoSCoW módszertan nem az egyetlen megközelítés a feladat prioritására, hanem az egyik leghatékonyabb és univerzálisabb módszer a dolgok helyes elvégzésére. A megközelítést Dai Clegg javasolta a könyvben " A „MoSCoW” név nem kapcsolódik az északi fővároshoz, és a prioritási kategóriák rövidítéseként jött létre: A szájnak van, meg kell, A szarnak van, Ezek a kategóriák összefügghetnek a numerikus prioritásokkal 1-2-3-4 és segítenek egyértelműen meghatározni a feladatok vagy tételek sorrendjét a termékfejlesztési iterációban. Az egyes kategóriák egyértelmű célja teszi ezt a módszert ilyen drágakövessé, és ebben a cikkben szeretnék minden prioritást példákkal lefedni az Agile fejlesztésben. Case Method Fast-Track: A RAD megközelítés M S Co W Először is meg kell állapítani egy példás forgatókönyvet a megközelítés alkalmazásához. Tegyük fel, hogy egy olyan termékcsapat tagjai vagyunk, amely egy B2B terméket fejleszt. Ebben a termékben ügyfeleink tárolhatnak és cserélhetnek fájlokat a projektjeikhez. Ahhoz, hogy egyszerű legyen, csapatunk néhány alapvető funkciót fog hozzáadni, mint például a „felhasználói meghívó” - a projekt új résztvevőjének hozzáadásának funkciója. Megígértük ügyfeleinknek, hogy ezt a funkciót egy bizonyos időpontig végrehajtjuk; elkötelezettek vagyunk. Ebben a példában a csapat tagjait nem szakirány szerint osztjuk szét (Dev, DevOps, QA), és csapatunkat egy kanonikus univerzális Scrum csapatként képzeljük el. A felhasználói meghívó forgatókönyv előkészítette a műszaki követelményeket, az UX/UI-t. A funkciót már értelmes elemekre bontották, és mindezen elemeket becsülték. tudjuk, hogy mennyi erőforrást kellene befektetni ebbe a funkcióba. Itt az ideje, hogy prioritási megközelítést alkalmazzunk, és további gond nélkül kategorizáljuk ezeket az elemeket. Szükséges - 1 A Must Have „1” prioritást olyan feladatokhoz, funkciókhoz, termék backlog elemekhez, felhasználói történetekhez vagy hibákhoz használják, amelyeket a következő fejlesztési iterációban kell felvenni. Például a tervezés során rájöttünk, hogy egyes feladatokat az ügyfelekkel kötött megállapodásokon keresztül kell kidolgozni, vagy más okból üzleti szempontból kritikusnak kell lenniük. A fő ötlet az, hogy ezek az elemek döntő fontosságúak és nem tárgyalhatóak. A csapatnak meg kell becsülnie őket, vállalnia kell a kockázatokat és meg kell terveznie őket. Ha a becsült idő meghaladja a rendelkezésre álló időt, az elemeket fel kell bontani, amíg az iteráció során létre nem hozható a Minimális Értékes Termék (MVP). Egy új termékfunkció példáján alapulva tegyük fel, hogy egy „új felhasználó meghívása egy projektbe” funkciót szeretnénk végrehajtani. A „Must Have” kategória tükrözi az MVP-feladatokat és alapvető funkcionalitást hoz létre. Az iterációs eredménynek értelmes forgatókönyvet és megfelelő feladatokat kell biztosítania az „1” prioritáshoz: Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. Szükséges - 2 A második kategória közel áll a „Must Have”-hoz, de ez olyasmi, amit később elhalaszthatunk vagy átadhatunk. Ha az ügyféllel megegyezünk a felhasználói meghívásokról, az MVP funkciók kötelező opcióként kerülnek kiadásra az „1” prioritásban. Mindazonáltal mindig sok olyan fejlesztés van, amelyet végre kell hajtani, de ezek a kijelölt hatályban kihagyhatók. A fejlesztési szakaszban a csapat bizonyos kockázatokkal szembesülhet a „Must Have” feladatokkal, és a második prioritási funkciókat el kell halasztani, mert nem tartoznak az MVP-hez. Például a „felhasználói meghívó” funkcióban a terméknek segítenie kell az új felhasználók bejelentkezését. A „Must Have” prioritásban a csapat kifejleszti a létrehozás és a meghívás kritikus forgatókönyvét. De fontos továbbá, hogy visszajelzést küldjön a meghívó rendszergazdának, hogy egy új felhasználó sikeresen bejelentkezett. Lehetőség van a funkció használatára ezen visszajelzés nélkül, de ezzel az értesítéssel a termék határozottan jobb, és a rendszergazda tudja, hogy minden rendben van. Így alakul ki a második prioritás - javítjuk a fő folyamatot, ami fontos az üzlet számára, csak szem előtt tartva, hogy ez a funkció kiegészítő. A "Should Have" termékhibák olyan dolgok, amelyek megtörik a forgatókönyvet, de van néhány ésszerű megoldás, amely egy hétköznapi és nem technikai felhasználó számára elérhető. Jobb, ha ezeket a hibákat az iteráció során mindig kijavítják, de a határidő közelében tárgyalhatók, mert még mindig lehetséges velük felszabadítani. Lehet - 3 Ez a kategória a javításokról vagy kisebb vizuális hibákról szól, amelyek általában különbséget tesznek, és növelhetik a termék általános érzését, de most nem kritikusak, vagy mélyen opcionálisak a forgatókönyv számára. Jó lenne ezeket a dolgokat fejleszteni, csak akkor, ha a "Must Have" vagy a "Should Have" prioritások kockázatait enyhítik. A tervezés során a termékcsapatnak gondolnia kell a "Could Have" elemekre, mint például: az első prioritást meg kell tenni. Maximális erőfeszítést kell tennünk a második prioritás teljesítésére. Ha minden rendben van, várjuk a harmadik prioritási elemek fejlesztését, de ha kudarcot vallottunk, ez nem befolyásolhatja az üzletet. A „felhasználói meghívó” funkció esetében a harmadik prioritás néhány további fejlesztés a felhasználói meghívó formájában. Harmadik prioritásként a rendszergazda automatikus értesítéseket állíthat be, ha a felhasználó nem jelentkezett be a következő három napban. A projektadminisztrátor manuálisan küldheti ezt az emlékeztetőt, ha észreveszi a második prioritási értesítés hiányát, de jó lenne kezdetben automatikus emlékeztetőket végrehajtani. A "Lehet, hogy" prioritás a termék hibaként valami olyan ritka funkciókról vagy vizuális hibákról szól, amelyeket néhány szokatlan környezetben reprodukálnak. Ezeket a hibákat ki lehet javítani, ha nem rendelkezünk befejezetlen funkciókkal vagy más kategóriájú termék hibákkal. Harmadik prioritás hibákat lehet a következő iterációra mozgatni hosszú tárgyalások nélkül, mert nem blokkolják a termék kiadását. Például ügyfélbázisunk többsége webes böngészőket használ egy adott motoron, és egy nem népszerű motorban jelentéktelen hiba van. Nagyszerű lenne kijavítani ezt a hibát, de ha mindenki fontosabb feladatokkal foglalkozik, nincs probléma ezzel a problémával a kiadásban. Nem lesz - 4 Hasznos kategória, amely olyan elemeket mutat, amelyek biztosan nem lesznek kiadva az iteráció során. Azonban fontos, hogy rendelkezzenek velük, ha van még kapacitás. A termékcsapat az iterációt és a szegmensfeladatokat és a hibákat első, második és harmadik prioritásként is megtervezheti. És előfordul, hogy a feladatok könnyebbek, mint a tervezett. A fejlesztőknek további ideje van, amelyet a negyedik prioritásra lehet felhasználni. Ezek az elemek mindig ágaikban fejlesztettek ki, és soha nem szándékoznak egyesülni az aktuális iterációban, de ez megkönnyíti a dolgokat a következő iterációhoz. Milyen típusú feladatok alkalmasak a „nem lesz” backlog? Először is, vannak technikai adósságtevékenységek. Nagyon fontosak lehetnek a „Must Have” vagy a „Should Have” prioritások is, de a kódbázis karbantartásához szükséges rendszeres kódjavítások a negyedik prioritás nagyszerű példája. A fejlesztőknek lehetőségük van az üzleti szempontból kulcsfontosságú feladatok után a kódot javítani, és ezeket a fejlesztéseket a következő iterációkban használni. Az is hasznos, ha a „Nem kell” prioritásként hozzáadunk néhány olyan elemet, amely a következő iteráció első „Must Have” prioritása lesz. Tudjuk, hogy az alapvető felhasználói meghívás után részletes felhasználói engedélybeállításokat kell integrálnunk ebbe a forgatókönyvbe, hogy egyszerűsítsük a rendszergazdai áramlást. Ez a funkció lesz a következő iteráció MVP-je. Ha van némi kapacitásunk, nagyszerű, ha negyedik prioritásként kezdenénk fejleszteni; ez csökkenti a kockázatokat a jövőben. Jobb, ha nem a negyedik prioritás termékhibái vannak, mert ez a kategória azt mutatja, hogy a hibát nem fogják rögzíteni az ismétlés során, és ez csak további rendetlenséget fog létrehozni a backlog táblán. Mégis, a prioritást lehet használni a hibák számára, amelyek az aktuális ismétlésre veszélyes építészeti változtatásokat igényelnek, és tesztelésüket a következőben kell megtervezni. A prioritási megközelítés alkalmazásának előnyei Ennek a cikknek az elején példát készítettem az egyedi prioritási megközelítésről négy kategóriával, amit senki sem értett, és a csapatnak be kell vezetni az ötödik prioritást a legfontosabb feladatokhoz. Ezek a szabályok szintén a csapat referenciaértékeként szolgálnak, és segítenek a csapattervezési megközelítés problémáinak bemutatásában. Például, ha a csapat nem tudja kifejleszteni az első „Must Have” prioritás összes tervezett elemét, nem is beszélve a többi prioritásról, akkor mély problémákat mutat a folyamatban: A funkciók követelményei nem voltak olyan jók és világosak. Hiba történt az összetörésben. A csapat valahogy alábecsülte a feladatok összetettségét. Valaki úgy döntött, hogy megváltoztatja az ötletet az iteráció során. A csapatnak visszajelzést kell nyújtania, és meg kell találnia a probléma forrását, és meg kell találnia a megoldást a törött fejlesztési folyamat kijavítására. Ugyanakkor a harmadik és a negyedik prioritás stabil befejezése sem olyan jó. Ez azt jelenti, hogy jó a becslés és a kockázatkezelés, de azt is mutatja, hogy a csapat meglehetősen nyugodt vagy alulterheltek. Talán megtervezhetnénk a „Must Have” vagy „Should Have” prioritások további elemeit. A megközelítés hátrányai A fenti példában a feladatokat egy adott iteráció esetében prioritás szerint kategorizálták, de ez nem jelenti azt, hogy a vállalat üzleti tevékenységének megfelelően általános prioritás legyen. A jelenlegi iterációban „Lehet” címkével ellátott feladatok a következőben „Must Have” lehetnek, és ezek a változások további időt igényelnek az iterációs menedzser számára az egyes tervezési munkamenetek során. Továbbá a megközelítésnek továbbra is problémája van az egyik kategóriában lévő feladatok sorrendjével. Ha az ismétlésnek kevés „Must Have” eleme van, melyiket kell először kifejleszteni? Ezt a szekvenciát még mindig meg kell vitatni az ismétléstervezésen keresztül, és konkrét szoftvereken keresztül kell koordinálni. Nincs ezüst golyó az egész fejlesztési folyamatra, de az olyan megközelítések használata, mint a MoSCoW segít az alapvető folyamatok egyszerűsítésében. következtetés Számos módszer és megközelítés létezik a prioritások meghatározására. Mindazonáltal úgy gondolom, hogy a MoSCoW megközelítés az egyik legegyszerűbb a szoftverfejlesztési folyamat általános fejlesztésével kezdeni. Ez a megközelítés alkalmasabb a B2B piaci termékek és a termékfejlesztés számára, egyértelműen megfogalmazott feladatokkal és jövőképgel. Szükséges a későbbi iterációk terve, hogy ezt a megközelítést helyesen használják. Egy kaotikus és gyorsan változó környezetben ez a megközelítés meghibásodhat, és sok magas prioritású feladatot hozhat létre, ami befolyásolja a kiadás kiszámíthatóságát. Ugyanez a probléma előfordulhat megfelelő tervezési és becslési folyamatok nélkül. De mindazon
