Svaka rasprava o procesima razvoja softvera zasniva se na nekoliko klasičnih pristupa stvaranju modernog softvera. Moramo uspostaviti neku kadenciju za isporuku proizvoda sa očekivanom frekvencijom uzimajući u obzir potrebe tržišta. Dužina iteracije treba da odražava potrebnu brzinu prilagođavanja promjenama backloga proizvoda. Timovi treba da se pripreme za svaku iteraciju i usavršavaju stavke backloga. Čini se da je pristup upravljanju prioritetima apsolutno intuitivan i ne morate imati duboko razumijevanje u standardizaciji da biste ga koristili u razvoju softvera. Ipak, uspostavljanje bilo kojeg procesa znači izjavu o općim načelima za svakog člana tima. A ovdje leže komplikacije: kako objasniti bilo kojem članu tima što znači neka cifra ili riječ pored zadatka ili proizvoda? Uvek je moguće izmisliti sopstveni sistem prioriteta, ali to dovodi do potrebe za objašnjenjem principa vašeg sistema za svakog novog člana tima. Ako je projekat velik i imate mnogo novih kolega, pa to je problem. Stoga je lakše koristiti neke vremenski testirane međunarodne standarde ili pristupe. U ovom članku želim raspravljati o upotrebi metode MoSCoW za prioritetizaciju u razvoju proizvoda kao de facto najčešćem načinu za racionalizaciju rada tokom iteracija, koji pružaju brze i mjerljive rezultate. Kao ilustraciju ću dati primer prilagođene metode prioritizacije i problema s kojima sam se suočio s ovim pristupom. Članak može biti koristan za menadžere proizvoda ili bilo koga tko prati proces razvoja proizvoda koji dobro radi. Zabavite se sa prilagođenim pristupom u pogledu prioriteta stavki Veoma davno, u jednom proizvodnom timu, pokušavali smo da rešimo problem s prioritetima stavki u našim razvojnim ciklusima. Sam proces je bio vrlo nezrel: rokovi implementacije su često bili prekršeni, tim je morao raditi prekovremeni rad, a izdanja proizvoda bila su nezadovoljavajuće kvalitete. U tom trenutku smo koristili numeričke prioritete 1-2-3-4 i oni uopće nisu pomogli. Zatim smo odlučili da racionaliziramo komunikaciju između članova tima i uvedemo dodatni prioritet „5“. Ovaj prioritet bi postao najviši prioritet, važniji od „1“, i znači „showstopper“ - kartu ili stavku koja bi trebalo da se implementira ASAP, uprkos bilo kojem drugom zadatku u iteracijskom backlogu. Naravno, ova odluka je generisala desetak pitanja: 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. Naravno, metoda prioritizacije nije bila opći problem u ovom procesu. Bilo je temeljnih pitanja u pristupu planiranju, upravljanju rizikom i samoj strategiji. Ali ako imate mnogo izazova na stolu, izmišljanje vlastite nejasne metodologije ne izgleda kao najbolja odluka. Uvođenje pristupa „MoSCoW“ Neki su standardi strogo kodificirani u međunarodnim najboljim praksama RFC-a od tijela kao što su IETF ili IEEE, dok su drugi postali standardi u svom pravu. Pristup je predložio Dai Clegg u knjizi “ Ime "MoSCoW" nema veze sa sjevernim glavnim gradom i stvoreno je kao akronim kategorija prioriteta: uši imaju, Hoću da imam, Ultrazvuk je, Ove kategorije mogu biti povezane s numeričkim prioritetima 1-2-3-4 i pomoći da se nedvosmisleno odredi redoslijed zadataka ili stavki u iteraciji razvoja proizvoda. Jasna svrha svake kategorije čini ovu metodu takvim draguljem, a tokom ovog članka, želio bih pokriti svaki prioritet s primjerima u razvoju agilnog. Metoda slučaja Fast-Track: RAD pristup M S Co W Prvo, potrebno je uspostaviti primer scenarija za korištenje pristupa. Pretpostavimo da smo članovi proizvodnog tima koji razvija B2B proizvod. U ovom proizvodu, naši klijenti mogu da skladište i razmjenjuju datoteke za svoje projekte. Da bi to bilo jednostavno, naš tim će dodati neke osnovne značajke, kao što je „Poziv korisnika“ - funkcionalnost dodavanja novog učesnika u projekat. Obećali smo našim klijentima da ćemo implementirati ovu značajku do određenog datuma; imamo obavezu. Sada, tim mora da planira sledeću iteraciju kako bi objavio novu verziju proizvoda prije roka kako bi održao ugled kompanije. U ovom primeru, nećemo segmentirati članove tima po specijalnostima (Dev, DevOps, QA), i zamisliti našu ekipu kao kanonski univerzalni Scrum tim. U scenariju korisničkog poziva pripremljeni su tehnički zahtevi, UX/UI. Funkcija je već raskomadana u smislene stavke koje imaju smisla, a sve te stavke su procijenjene. Ovo je vreme da koristite pristup prioritizaciji, i bez daljnjeg uznemiravanja, kategorizirajmo ove stavke. Treba imati - 1 Treba imati „1“ prioritet koristi se za zadatke, karakteristike, stavke backlog proizvoda, korisničke priče ili bugove koji moraju biti uključeni u narednu iteraciju razvoja. Na primjer, tokom planiranja shvatili smo da neki zadaci treba da budu razvijeni putem sporazuma sa klijentima ili da su poslovno kritični iz nekog drugog razloga. Glavna ideja je da su ti stavci ključni i da se ne mogu pregovarati. Tim ih mora procijeniti, preuzeti rizike i planirati ih. Ako je procjena veća od raspoloživog vremena, stavke treba razgraditi dok se tijekom iteracije ne može stvoriti Minimalni Vrijedni Proizvod (MVP). Na osnovu primera nove funkcije proizvoda, pretpostavimo da želimo implementirati funkciju „pozvati novog korisnika na projekat“. Kategorija „Must Have“ odražava zadatke MVP-a i stvara osnovne funkcionalnosti. Rezultat iteracije mora pružiti smislen scenarij i odgovarajuće zadatke za prioritet „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. Trebalo bi - 2 Druga kategorija je blizu "Must Have". ali to je nešto što bismo mogli odgoditi ili isporučiti kasnije. Ako imamo dogovor sa klijentom o korisničkim pozivima, funkcije MVP-a bit će objavljene kao obavezne opcije u prioritetu „1“. Međutim, uvek postoji mnogo poboljšanja koja su potrebna za implementaciju, ali se mogu izostaviti u deklarovanom opsegu. Tijekom razvojne faze tim može suočiti sa nekim rizicima sa zadacima „Must Have“, a funkcije drugog prioriteta treba odgoditi jer nisu dio MVP-a. Na primer, u funkciji „Poziv korisnika“, proizvod bi trebao pomoći da se novi korisnici uključe. U prioritetu „Must Have“ tim će razviti kritični scenarij stvaranja i poziva. Ali takođe je važno poslati povratne informacije administratoru koji je pozvao da je novi korisnik uspješno prijavljen. Moguće je koristiti funkciju bez ove povratne informacije, ali uz ovo obaveštenje, proizvod je definitivno bolji i administrator će znati da je sve u redu. Tako se uspostavlja drugi prioritet - poboljšavamo glavni proces, nešto važno za poslovanje, samo imajući na umu da je ova funkcija dodatna. Buga proizvoda "treba imati" je nešto što slomi scenarij, ali postoji neki razumni izbor, dostupan za običnog i netehničkog korisnika.Bolje je uvek ispraviti ove greške tokom iteracije, ali one se mogu pregovarati blizu roka, jer je još uvek moguće osloboditi ih. Može - 3 Ova kategorija je o poboljšanjima ili manjim vizualnim nedostatcima koji čine razliku u cjelini i mogu poboljšati cjelokupni osećaj proizvoda, ali oni nisu kritični u ovom trenutku ili duboko opcionalni za scenarij. Bilo bi lepo razvijati ove stvari, samo ako su rizici prioriteta „Must Have“ ili „Should Have“ ublaženi. Tijekom planiranja, tim proizvoda treba razmišljati o „Moglo bi imati“ stavkama kao što je ovo: prvi prioritet mora biti učinjen. Trebali bismo uložiti maksimalni napor da isporučimo drugi prioritet. Ako sve ide u redu, očekujemo da ćemo razviti treće prioritetne stavke, ali ako smo propali, to ne bi trebalo uticati na poslovanje. U slučaju funkcije "Poziv korisnika", treći prioritet je nekoliko dodatnih poboljšanja u obrascu poziva korisnika. Kao treća prioritetska funkcija, administrator bi mogao postaviti automatske obaveštenja ako se korisnik nije prijavio u naredna tri dana. Administrator projekta mogao bi ručno poslati ovo podsjetnik ako primijete da nema drugog prioritetska obaveštenja, ali bilo bi lijepo primijeniti automatske podsjetnike u početku. Bez ovog poboljšanja, proizvod dobro funkcionira i ispunjava uvjete ugovora, što ga čini "Mogao bi biti". Prioritet "Možda ima" kao proizvod bug je nešto o rijetkim značajkama ili vizualnim bugovima koji se reproduciraju u nekim neobičnim okruženjima. Ove bugove možemo popraviti ako nemamo nedovršene značajke ili proizvodne bugove drugih kategorija. Treće prioritetne bugove možemo premjestiti na sledeću iteraciju bez dugih pregovora, jer oni ne blokiraju izdavanje proizvoda. Na primjer, većina naše baze klijenata koristi web pretraživače na određenom motoru i imamo zanemariv nedostatak u nepopularnom motoru. Bilo bi super popraviti ovu bug, ali ako je svatko zauzet važnijim zadatcima, nema problema imati ovaj problem u izdavanju. Neće biti - 4 Korisna kategorija koja prikazuje stavke koji definitivno neće biti pušteni tijekom iteracije. Međutim, važno je da ih imate ako je preostalo malo kapaciteta. Tim proizvoda mogao je planirati iteracije i segmentirane zadatke i greške kao prvi, drugi i treći prioritet. I događa se da su zadaci lakši nego što je planirano. Razvijatelji će imati dodatno vrijeme koje bi se moglo upotrijebiti za četvrti prioritet. Ovi stavci su uvijek razvijeni u granama i nikada nisu namjeravali da budu spajani u trenutnoj iteraciji, ali to olakšava stvari za sledeću iteraciju. Koje vrste zadataka su prikladne kao „neće“ backlog? Prije svega, postoje tehnički zadatci dugova. Vrlo važni mogu biti i prioriteti „Must Have“ ili „Should Have“, ali redovita poboljšanja koda za održavanje baze koda su odličan primer četvrtog prioriteta. Razvijatelji imaju priliku da poboljšaju kod nakon poslovno ključnih zadataka i koriste ta poboljšanja u narednim iteracijama. Ako neke promene prelaze i zahtijevaju netipično izvršenje QA-a, poboljšanja prije novih iteracija takođe pružaju priliku za pravovremeno uređenje. Takođe, korisno je dodati kao prioritet "Neće imati" neke stavke koje će biti prvi prioritet "Must Have" u narednoj iteraciji. Znamo da nakon osnovnog korisničkog poziva, trebamo integrirati detaljne postavke korisničkih dozvola u ovaj scenarij, kako bi se pojednostavio protok administratora. Ova značajka će biti MVP naredne iteracije. Ako imamo neki kapacitet, sjajno je početi razvijati ga kao četvrti prioritet; to će smanjiti rizike u budućnosti. Bolje je ne imati proizvodne greške četvrtog prioriteta, jer ova kategorija pokazuje da se greška neće popraviti tijekom iteracije i to će samo stvoriti dodatni nered na ploči za povratne informacije. Ipak, prioritet se može koristiti za greške koje zahtijevaju arhitektonske promene koje su opasne za trenutnu iteraciju i njihovo testiranje treba planirati u narednoj. Prednosti korištenja prioritetnog pristupa Na početku ovog članka napravio sam primer prilagođenog pristupa prioritetu sa četiri kategorije, koje niko nije razumeo i tim mora uvesti peti prioritet za najvažnije zadatke. Ova pravila takođe služe kao referentna točka tima i pomažu da se pokažu problemi u pristupu planiranju tima. Na primer, ako tim ne može razviti sve planirane stavke prvog prioriteta „Must Have“, da ne spominjemo druge prioritete, to pokazuje duboke probleme u procesu: Zahtevi za karakteristike nisu bili tako dobri i jasni. Došlo je do greške u funkciji dekompozicije. Tim je nekako potcenio složenost zadataka. Netko je odlučio da promeni ideju tokom iteracije. Tim mora pružiti retrospektivu i utvrditi izvor problema i pronaći rješenje za popravak slomljenog procesa razvoja. Istovremeno stabilno završetak trećeg i četvrtog prioriteta nije tako dobar ni. To znači da smo dobri u procjeni i upravljanju rizikom, ali to takođe pokazuje da je tim je prilično opušten ili ispod opterećenja. Možda bismo mogli planirati dodatne stavke „Must Have” ili „Should Have” prioriteta. Proces razvoja zahtijeva ravnotežu i neke izazove da bi svi članovi tima oštri i u potrazi za poboljšanja. Nedostaci pristupa U gore navedenom primeru, zadaci su kategorizovani po prioritetu za jednu određenu iteraciju, ali to ne znači ukupni prioritet prema poslovanju kompanije. Osim toga, pristup i dalje ima problema sa sekvencijom zadataka u jednoj kategoriji. Ako iteracija ima nekoliko „Must Have“ stavki, koji od njih treba da se razvije prvi? Ova sekvenca i dalje treba da se raspravlja kroz planiranje iteracije i koordinira putem specifičnog softvera. Ne postoji srebrna metka za ceo proces razvoja, ali korištenje pristupa kao što je MoSCoW pomaže da se racionaliziraju osnovni procesi. Zaključak Postoji mnogo metoda i pristupa za prioritetizaciju. Međutim, mislim da je MoSCoW pristup jedan od najlakših za početak s općim poboljšanjima u procesu razvoja softvera. Ovaj pristup je prikladniji za B2B tržište proizvoda i razvoj proizvoda sa jasno formuliranim zadatcima i vizijom. Potrebno je imati plan za naknadne iteracije kako bi se ispravno koristio ovaj pristup. U haotičnom i brzo se mijenjajućem okruženju ovaj pristup može ne funkcionirati i stvoriti toliko visokoprioritetnih zadataka, što će uticati na predvidljivost izdanja. Isti problem može se pojaviti bez pravilnog planiranja i procjene procesa. Ali ipak, korištenje ovog pristupa pomoći će identificirati sve ove probleme što je brže moguće i pokrenuti inicijativu za racionaliziranje i stvaranje dobro funkcionirajućeg razvoja proizvoda
