Akákoľvek diskusia o procesoch vývoja softvéru založená na niekoľkých klasických prístupoch k vytváraniu moderného softvéru. Musíme vytvoriť určitú kadenciu na dodávanie produktov s očakávanou frekvenciou s ohľadom na potreby trhu. Dĺžka iterácie by mala odrážať potrebnú rýchlosť adaptácie na zmeny produktového backlogu. Zdá sa, že prístup k riadeniu priorít je absolútne intuitívny a nemusíte mať hlboké pochopenie štandardizácie, aby ste ho mohli použiť vo svojom vývoji softvéru. Napriek tomu vytvorenie akéhokoľvek procesu znamená vyhlásenie všeobecných zásad pre každého člena tímu. Vždy je možné vymyslieť svoj vlastný systém priorít, ale to vedie k nevyhnutnosti vysvetľovania princípov vášho systému pre každého nového člena tímu. Ak je projekt veľký a máte veľa nových spolupracovníkov, dobre, to je problém. Preto je jednoduchšie použiť niektoré časovo testované medzinárodné štandardy alebo prístupy. V tomto článku by som chcel diskutovať o používaní metódy MoSCoW pre prioritizáciu vo vývoji produktov ako de facto najbežnejší spôsob, ako zjednodušiť prácu počas iterácií, ktoré poskytujú rýchle a merateľné výsledky. Ako ilustráciu poskytnem príklad vlastnej metódy prioritizácie a problémov, ktorým som čelil s týmto prístupom.Potom sa ponoríme do rozkladu metódy MoSCoW, aby sme zvážili každú prioritu s živými príkladmi. Článok môže byť užitočný pre produktových manažérov alebo každého, kto sleduje dobre fungujúci proces vývoja produktov. Bavte sa s prispôsobeným prístupom k prioritným položkám Pred veľmi dlhým časom, v jednom produktovom tíme, sme sa snažili vyriešiť problém s prioritami položiek v našich vývojových cykloch. Samotný proces bol veľmi nezrelý: termíny implementácie boli často porušené, tím musel pracovať nadčas a vydania produktov boli neuspokojivej kvality. V tej chvíli sme používali číselné priority 1-2-3-4 a vôbec nepomohli. Potom sme sa rozhodli zjednodušiť komunikáciu medzi členmi tímu a zaviedli sme dodatočnú prioritu „5“. Táto priorita by sa stala najvyššou prioritou, dôležitejšou ako „1“ a znamenala „showstopper“ - lístok alebo položka, ktorá by sa mala implementovať ASAP, napriek akejkoľvek inej úlohe v iterácii. Samozrejme, toto rozhodnutie vyvolalo 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. Samozrejme, metóda stanovovania priorít nebola všeobecným problémom v tomto procese. V prístupe k plánovaniu, riadeniu rizík a samotnej stratégii boli zásadné problémy. Ale ak máte na stole veľa výziev, vynález vlastnej nejasnej metodiky nevyzerá ako najlepšie rozhodnutie. Zavedenie prístupu „MoSCoW“ Niektoré normy sú prísne kodifikované v medzinárodných najlepších postupoch RFC od orgánov, ako je IETF alebo IEEE, zatiaľ čo iné sa stali štandardmi vo svojom vlastnom práve.Tá, ktorú by som chcel zaviesť, patrí do druhej kategórie. Tento prístup navrhol Dai Clegg v knihe " Názov „MoSCoW“ nemá žiadne spojenie so severným hlavným mestom a bol vytvorený ako skratka prioritizačných kategórií: ústa majú, bude mať, Ultrazvuk má, Tieto kategórie môžu byť spojené s číselnými prioritami 1-2-3-4 a pomáhajú jednoznačne určiť sekvenciu úloh alebo položiek v iterácii vývoja produktu. Jasný účel každej kategórie robí túto metódu takým klenotom a počas tohto článku by som chcel pokryť každú prioritu príkladmi v Agile vývoji. Prípadová metóda Fast-Track: Prístup RAD M S Co W Po prvé, je potrebné stanoviť príklad scenára pre použitie prístupu. Predpokladajme, že sme členmi produktového tímu, ktorý vyvíja B2B produkt. V tomto produkte môžu naši zákazníci ukladať a vymieňať súbory pre svoje projekty. Aby to bolo jednoduché, náš tím pridá niektoré základné funkcie, ako napríklad „Pozvánka používateľa“ - funkčnosť pridávania nového účastníka do projektu. Sľúbili sme našim zákazníkom, že túto funkciu implementujeme do určitého dátumu; máme záväzok. V tomto príklade nebudeme členov tímu segmentovať podľa špecialít (Dev, DevOps, QA) a predstavíme si náš tím ako kanonický univerzálny Scrum tím. V scenári používateľských pozvánok boli pripravené technické požiadavky, UX/UI. Funkcia už bola rozložená na zmysluplné položky, ktoré majú zmysel, a všetky tieto položky boli odhadnuté. Je najvyšší čas použiť prístup prioritizácie a bez ďalšieho znepokojenia, poďme kategorizovať tieto položky. Musí byť - 1 Priorita Must Have „1“ sa používa pre úlohy, funkcie, položky produktu, príbehy používateľov alebo chyby, ktoré musia byť zahrnuté do ďalšej iterácie vývoja. Napríklad počas plánovania sme si uvedomili, že niektoré úlohy by sa mali rozvíjať prostredníctvom dohôd so zákazníkmi alebo sú obchodne kritické z iného dôvodu. Hlavnou myšlienkou je, že tieto položky sú rozhodujúce a nemožno ich vyjednávať. Tím ich musí odhadnúť, prijať riziká a naplánovať ich. Ak je odhad viac ako dostupný čas, položky by sa mali rozložiť, kým sa počas iterácie nedá vytvoriť minimálny hodnotný produkt (MVP). Na základe príkladu novej funkcie produktu predpokladajme, že chceme implementovať funkciu „pozvať nového používateľa do projektu“. Kategória „Must Have“ odráža úlohy MVP a vytvára základnú funkčnosť. Výsledok iterácie musí poskytnúť zmysluplný scenár a vhodné úlohy pre prioritu „1“: 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. Mali by ste mať - 2 Druhá kategória je blízko k „Must Have“. Ale je to niečo, čo by sme mohli odložiť alebo dodať neskôr. Ak sa s klientom dohodneme na používateľských pozvánkach, funkcie MVP sa uvoľnia ako povinné možnosti v priorite „1“. Avšak vždy existuje veľa vylepšení, ktoré je potrebné implementovať, ale môžu byť vynechané v deklarovanom rozsahu. Napríklad v funkcii „Pozvánka používateľa“ by mal produkt pomôcť prijímať nových používateľov. V prioritách „Must Have“ tím vyvinie kritický scenár vytvárania a pozvánky. Ale je tiež dôležité odoslať spätnú väzbu správcovi, ktorý pozval nového používateľa, že sa úspešne prihlásil. Je možné použiť funkciu bez tejto spätnej väzby, ale s týmto oznámením je produkt určite lepší a správca bude vedieť, že všetko je v poriadku. Produktová chyba "Malo by to byť" je niečo, čo porušuje scenár, ale existuje nejaké rozumné riešenie, ktoré je k dispozícii pre bežného a netechnického používateľa.Je lepšie vždy opraviť tieto chyby počas iterácie, ale mohli by sa vyjednávať v blízkosti termínu, pretože je stále možné s nimi uvoľniť. Môže byť - 3 Táto kategória je o vylepšeniach alebo menších vizuálnych defektoch, ktoré robia rozdiel vo všeobecnosti a môžu zlepšiť celkový pocit produktu, ale nie sú momentálne kritické alebo hlboko voliteľné pre scenár. Bolo by pekné rozvíjať tieto veci, len ak sú zmiernené riziká priorít „Must Have“ alebo „Should Have“. Počas plánovania by mal produktový tím premýšľať o položkách „Could Have“ ako toto: prvá priorita musí byť vykonaná. Mali by sme vynaložiť maximálne úsilie na dodanie druhej priority. Ak je všetko v poriadku, očakávame rozvoj tretích priorít, ale ak sme zlyhali, nemalo by to ovplyvniť podnikanie. V prípade funkcie "Pozvánka používateľa" je tretia priorita niektoré ďalšie vylepšenia vo formulári pozvánky používateľa. Ako tretia priorita funkcia, správca mohol nastaviť automatické oznámenia, ak sa používateľ neprihlásil počas nasledujúcich troch dní. Správca projektu mohol poslať túto pripomienku manuálne, ak si všimli, že neexistuje druhé oznámenie o priorite, ale bolo by pekné implementovať automatické pripomienky na začiatku. Bez tohto vylepšenia produkt funguje dobre a spĺňa podmienky zmluvy, čo z neho robí "Mohol mať". Priorita "môže mať" ako produktová chyba je niečo o vzácnych funkciách alebo vizuálnych chybách, ktoré sa reprodukujú v niektorých nezvyčajných prostrediach. Tieto chyby by mohli byť opravené, ak nemáme nedokončené funkcie alebo produktové chyby iných kategórií. Tretie priority chyby by mohli byť presunuté do ďalšej iterácie bez dlhých rokovaní, pretože neblokujú vydanie produktu. Napríklad väčšina našej zákazníckej základne používa webové prehliadače na konkrétnom motore a máme zanedbateľnú chybu v nepopulárnom motore. Bolo by skvelé opraviť túto chybu, ale ak je každý zaneprázdnený dôležitejšími úlohami, nie je problém mať tento problém v vydaní. Nebudeš mať - 4 Užitočná kategória, ktorá ukazuje položky, ktoré sa počas iterácie rozhodne nezverejnia. Avšak je dôležité mať ich, ak zostane nejaká kapacita. Tím produktov mohol naplánovať iterácie a segmentové úlohy a chyby ako prvú, druhú a tretiu prioritu. A stáva sa, že úlohy sú jednoduchšie, než bolo plánované. Vývojári budú mať dodatočný čas, ktorý by mohol byť použitý pre štvrtú prioritu. Tieto položky sú vždy vyvinuté v pobočkách a nikdy nie sú určené na zlúčenie v aktuálnej iterácii, ale to uľahčuje veci pre ďalšiu iteráciu. Aké typy úloh sú vhodné ako backlog „Nemám“? Po prvé, existujú technické úlohy dlhu. Veľmi dôležité môžu byť aj priority „Must Have“ alebo „Should Have“, ale pravidelné vylepšenia kódu pre údržbu kódovej základne sú skvelým príkladom štvrtej priority. Vývojári majú príležitosť vylepšiť kód po obchodne dôležitých úlohách a použiť tieto vylepšenia v nasledujúcich iteráciách. Ak niektoré zmeny pretrvávajú a vyžadujú netypickú implementáciu QA, vykonávanie vylepšení pred novými iteráciami tiež poskytuje príležitosť na včasné vylepšenie. Je tiež užitočné pridať ako prioritu „Nemám“ niektoré položky, ktoré budú prvou prioritou „Must Have“ v ďalšej iterácii. Vieme, že po základnej používateľskej pozvánke by sme mali do tohto scenára integrovať podrobné nastavenia povolení používateľa, aby sme zjednodušili tok správcu. Táto funkcia bude MVP ďalšej iterácie. Ak máme nejakú kapacitu, je skvelé začať ju rozvíjať ako štvrtú prioritu; to zníži riziká v budúcnosti. Je lepšie, aby ste nemali produktové chyby štvrtej priority, pretože táto kategória ukazuje, že chyba nebude opravená počas iterácie a len vytvorí dodatočný neporiadok na doske backlog. Napriek tomu by sa priorita mohla použiť pre chyby, ktoré vyžadujú architektonické zmeny, ktoré sú nebezpečné pre aktuálnu iteráciu a ich testovanie by malo byť naplánované v ďalšej. Využitie prioritného prístupu Na začiatku tohto článku som urobil príklad prispôsobeného prístupu k prioritám so štyrmi kategóriami, ktoré nikto nepochopil a tím musí zaviesť piatu prioritu pre najdôležitejšie úlohy. Tieto pravidlá tiež slúžia ako referenčná hodnota tímu a pomáhajú ukázať problémy v prístupe plánovania tímu. Napríklad, ak tím nemôže vyvinúť všetky plánované položky prvej priority „Must Have“, nehovoriac o iných prioritách, ukazuje hlboké problémy v procese: Požiadavky na funkcie neboli také dobré a jasné. V rozložení sa vyskytla chyba. Tím nejako podceňoval zložitosť úloh. Niekto sa rozhodol zmeniť myšlienku počas iterácie. Tím musí poskytnúť retrospektívu a zistiť zdroj problému a nájsť riešenie na opravu zlomeného vývojového procesu. Zároveň stabilné dokončenie tretej a štvrtej priority tiež nie je také dobré. Znamená to, že sme dobrí v odhadovaní a riadení rizík, ale tiež ukazuje, že tím je dosť uvoľnený alebo nedostatočne zaťažený. Možno by sme mohli naplánovať ďalšie položky priorít „Must Have“ alebo „Should Have“. Vývojový proces vyžaduje rovnováhu a niektoré výzvy, aby všetci členovia tímu zostali ostrí a hľadali zlepšenia. Nevýhody prístupu V vyššie uvedenom príklade boli úlohy kategorizované podľa priority pre jednu konkrétnu iteráciu, ale to neznamená celkovú prioritu podľa podnikania spoločnosti. Úlohy, ktoré sú označené ako „Mohlo by“ v aktuálnej iterácii, sa môžu stať „Must Have“ v ďalšej iterácii a tieto zmeny vyžadujú dodatočný čas počas každej plánovacej relácie pre správcu iterácie. Okrem toho prístup stále má problém s postupnosťou úloh v jednej kategórii. Ak iterácia má málo položiek „Must Have“, ktoré z nich by sa mali vyvinúť ako prvé? Táto sekvencia by mala byť stále diskutovaná prostredníctvom plánovania iterácie a koordinovaná prostredníctvom špecifického softvéru. Pre celý vývojový proces nie je žiadna strieborná guľa, ale použitie prístupov ako MoSCoW pomáha zjednodušiť základné procesy. záver Existuje mnoho metód a prístupov k prioritizácii. Avšak myslím, že prístup MoSCoW je jedným z najjednoduchších na začatie so všeobecnými zlepšeniami procesu vývoja softvéru. Tento prístup je vhodnejší pre produkty na trhu B2B a vývoj produktov s jasne formulovanými úlohami a víziou. Je potrebné mať plán na následné iterácie, aby sa tento prístup používal správne. V chaotickom a rýchlo sa meniacom prostredí tento prístup môže zlyhať a vytvoriť toľko úloh s vysokou prioritou, čo ovplyvní predvídateľnosť vydania. Rovnaký problém sa môže objaviť bez správneho plánovania a odhadovacieho procesu. Avšak použitie tohto prístupu pomôže identifikovať všetky tieto problémy čo najskôr a spustiť iniciatívu na zjednodušenie a
