O kompaniji
184
Iskustva
98
Plate
Poslovi
Levi9 Technology Services logo

Levi9 Technology Services

4.3
22.07.2021.

Kako smanjiti NEPREDVIDIVOST pri razvoju softvera: Agile Release Planning

Helloworld

Razvoj softvera je nepredvidiva delatnost. Veliki broj tehnoloških organizacija pokušava da pronađe način da poveća predvidivost isporuke , što nije lak zadatak. Za razliku od Lean proizvodnje, gde je za svaki komad proizvoda potrebna ista, predvidiva potrošnja vremena i materijala, sa softverom to nije slučaj.

Kada razvijamo softver, mi konstantno radimo na novom dizajnu proizvoda i zbog toga postoji manjak predvidivosti, što neretko dovodi do haosa. Shodno tome, softver živi u empirijskom svetu što implicira da se oslanjamo na istorijske podatke kako bismo donosili odluke i predviđali razvoj. Što više istorijskih podataka imamo, šansa da naša predikcija bude tačna se povećava.

Kao profesionalci koji radimo u ovoj oblasti, imamo zadatak da nađemo odgovarajuće alate i pristupe kako bismo na struktuiran i iterativan način ceo proces optimizovali.

Kako može efikasnije?

Jedan od pristupa planiranju u razvoju proizvoda koji mi u Levi9 koristimo jeste tzv. Agile Release Planning.

Release planning nam omogućava da u manjim celinama definišemo kako će razvoj našeg proizvoda (ili dela proizvoda) da se odvija kroz vreme.

U praksi bi to značilo da ceo obim (scope) proizvoda koji želimo da isporučimo, zapravo podelimo na manje celine, po iteracijama (sprintovima). To nam omogućava da sa prilično velikom tačnošću odgovorimo na pitanja kao što su:

  1. Koliko će proizvod ili deo proizvoda da košta?
  2. Kada će određena funkcionalnost biti gotova?
  3. Šta sve može biti isporučeno u određenom vremenskom periodu?

Ovaj pristup nam pomaže da se efikasnije prilagodimo nepredvidivoj prirodi razvoja softvera i budemo spremni da u najkraćem periodu napravimo promene u samom planu (replanning).

Zašto baš Agile Release Planning?

Agile release planning, ukoliko se koristi na pravi način, može da donese veliku vrednost svim interesnim stranama u procesu razvoja proizvoda. Pri tome, pod interesnim stranama u ovom slučaju podrazumevamo sledeće:

  •  Klijent (Product Owner/Product Manager)

Jedan od osnovnih benefita jeste upravo taj da se release plan koristi kao komunikaciono sredstvo Product Owner-a ka interesnim stranama. Product Owner, na osnovu informacija koje mu plan pruža, interno usaglašava izvršenje posla sa ostalim departmanima (marketing, prodaja itd). Na osnovu ovoga, release plan pomaže da se interni procesi organizacije usklade u odnosu na očekivani datum puštanja proizvoda/dela proizvoda krajnjim korisnicima. Samim tim, kod produktne organizacije, prediktabilnost razvoja proizvoda raste, što utiče i na rast prediktabilnosti poslovanja.

Dalje, veoma je bitno definisati da li postoje tzv. itemi koji blokiraju dalji razvoj, kako bismo na vreme mogli da ih otklonimo. Zbog toga, release plan se koristi kao alat za upravljanje međuzavisnostima samih itema koji treba da se isporuče kako bismo dobili finalni proizvod.

  •  Razvojni tim

Osim za komunikaciju ka eksternim interesnim stranama, release plan može da se koristi i za komunikaciju o bitnim datumima, promenama u obimu posla, međuzavisnostima ka razvojnom timu.

Isto tako, kada se ceo tim uključi u proces donošenja odluka o tome kako na najbolji način napraviti proizvod, dolazi do organizacione inovativnosti, a samim tim i do poboljšanja kolaboracije između razvojnog tima i Product Owner-a/Product Manager-a.

Važno je napomenuti i da kada tim zna u kojoj su fazi razvoja proizvoda, koliki je obim preostalog posla, na koji način se menja obim proizvoda, prilagođavanje promenama je olakšano, a samim tim se pritisak na tim smanjuje.

  • Produktna organizacija

Izuzetno značajan benefit u ovom slučaju iz ugla produktne organizacije podrazumeva i upravljanje projektnim trouglom (obim, troškovi vreme), ali i upravljanje protfoliom.

Kada produktna organizacija, u našem slučaju klijent, poznaje okvirne datume i troškove razvoja svojih proizvoda, poslovanje može da se planira na efikasniji način. Samim tim, na nivou proizvoda (epika), organizacija može da upravlja operativnim troškovima, gde po svojoj prirodi, release plan može da pomogne.

Koji su preduslovi za Agile Release Planning?

Kako bi Agile Release plan bio uspešno kreiran, potrebno je steći određene uslove i prikupiti određene setove podataka koji će omogućiti što precizniju izradu plana. Pre samog kreiranja Release plana, potrebno je predstaviti ideju klijentu i približiti mu benefite koje mu ovaj plan može doneti. Kako bismo izradili kvalitetan release plan, neophodno je da zajedno sa klijentom definisemo zahteve, rokove, prioritete, međuzavisnosti.

Krenimo redom:

  1. Backlog/User Story Mapping

Za početak, potrebno je poznavati zahteve, odnosno imati Backlog. U zavisnosti od toga šta se planira, to može biti Product Backlog, ili određeni Epic – nova funkcionalnost u okviru postojećeg proizvoda.

Ukoliko User Story Breakdown nije unapred poznat, potrebno je organizovati User Story Mapping sesiju, u cilju kreiranja Backlog-a. Neki zahtevi mogu biti razloženi u nekoliko jednostavnijih User Story-a, neki mogu biti manje poznati i kompleksniji, ali će vremenom postati jasniji.

Na samom početku je bitno naglasiti što više poznatih detalja, a naročito prepoznati međuzavisnosti određenih User Story-a.

2. Prioritizacija

Sledeći uslov jeste određivanje prioriteta Backlog-a, za koju je u najvećoj meri u našim slučajevima zadužen klijent kada pričamo o prioritizaciji vrednosti. Neretko, međutim, prioritizaciju u okviru vrednosnih celina diktira tehnička implementacija. Pri samoj prioritizaciji, akcenat se stavlja na one zahteve koji donose najveću poslovnu vrednost organizaciji (tzv. business value).

3. Estimacija Neophodan deo svakog planiranja je estimacija. U Levi9 najcesce koristimo tzv. indicative sizing tehnike kao sto su: planning poker, T-shirt sizing i sl.

Bitno je napomenuti da su inicijalne estimacije podložne promenama u vremenu, tačnije, tim može steći nova saznanja koja mogu uticati na promenu broja User Story poena – broj se može povećati, ali i smanjiti.

4. Scrum metrike Kako bi se broj Story poena mogao dovesti u vezu sa samim Sprintovima, koriste se određene Scrum metrike, koje se redovno prate, iz Sprinta u Sprint. Tačnije, potrebno je odrediti koje funkcionalnosti bi tim mogao da isporuči u toku određenog Sprinta, prikazano u Story poenima.

Velocity je metrika koja označava upravo taj broj. Računa se na osnovu dosadašnjeg iskustva sa timom, ali i određenih predviđanja; predstavlja prosečan broj Story poena koje je tim u stanju da isporuči u toku jednog Sprinta, imajući u vidu kapacitet tima za određeni Sprint.

Drugi slučaj je da imamo novi tim ili novi proizvod, i nemamo mogućnost da koristimo istorijske podatke za Velocity. Jedan od pristupa ovom scenariju je da određeni broj iteracija (praksa kaže do pet) tretiramo kao “warm-up” iteracije, na osnovu kojih ćemo doći do početne tačke za Velocity. Praktično, to bi značilo da ćemo Release plan da pravimo i pratimo od Sprinta 3 ili 5, zavisno od nivoa pouzdanja tima.

Pored toga, u dogovoru sa klijentom, određuje se procenat Story poena koji će se u toku Sprinta odnositi na sam Epic, u odnosu na druge zahteve koji bi tim trebalo da isporuči u toku Sprintova (technical debt, bugs, life cycle management).

Kako zapravo izgleda Release Plan?

Kada su nam dostupni podaci o ukupnom broju estimiranih poena, i velocity tima, možemo kreirati sam Release plan. Suština ovakvog plana je u tome da, iako je vrlo podložan promenama u toku vremena, on ne služi za precizno određivanje datuma kada će postavljeni zahtevi biti isporučeni, već je alat pomoću kojeg se na agilan način može pratiti progres tima ka ispunjenju cilja.

Ukoliko je cilj isporučivanje svih zahteva, i ne postoji određeni rok u smislu datuma, pratiće se promene planiranog datuma kada će zahtevi biti ispunjeni. Međutim, ukoliko postoji okviran, ili čak tačno određeni rok za isporuku, Release plan služi za određivanje obima koji može biti isporučen, što zahteva prioritizaciju od strane klijenta uz podršku razvojnog tima.

Važna napomena: Kako bi se pratio progres i moglo reagovati na vreme u slucaju odstupanja od planiranog, release plan je bitno azurirati nakon svakog sprinta.

Epic Burndown je prikaz preostalih User Story poena na Backlog-u, pomoću kojeg možemo predvideti nakon koliko Sprintova se može očekivati ispunjenje svih zahteva, uz pretpostavku da ne dođe do većih promena koje mogu uticati i na promenu datuma (Sprinta).

Na početku teksta smo naglasili da je razvoj softvera veoma nepredvidiv proces i da je zbog toga veoma bitno upravljanje očekivanjima interesnih strana. Pored toga, veoma je bitno i upravljati rizicima, konkretno rizikom isporuke proizvoda.





Jedan od načina da upravljamo i očekivanjima i rizikom isporuke jeste korišćenje “buffer-a”. U tom slučaju imamo dve opcije:

1. Schedule Buffer – Primenjuje se ukoliko imamo definisan scope koji je potrebno isporučiti, a koristeći Release Plan, predviđamo očekivani datum isporuke. Definiše se vremenski okvir (range), koji počinje od datuma kada bismo najranije mogli isporučiti definisan scope, a završava se datumom kada bismo ga najkasnije mogli isporučiti. 2. Feature Buffer - Primenjuje se u slučaju kada imamo jasno definisan datum isporuke, a Release Plan koristimo za određivanje scope-a koji može biti isporučen. Definišu se tri dela scope-a: prvi deo scope-a su oni zahtevi za koje, sa velikom verovatnoćom, možemo reći da će biti isporučeni do kraja roka; drugi deo scope-a su oni za koje smo umereno sigurni da će biti isporučeni u roku; a treći deo scope-a su zahtevi za koje nismo sigurni da će biti isporučeni do definisanog roka.

Obim buffer-a zavisi od pouzdanosti podataka koji se koriste za kreiranje samog Release Plana. Ukoliko raspolažemo većim brojem istorijskih podataka, Release Plan će biti više pouzdan, i samim tim će buffer biti manji.

Obrnuto, ukoliko nemamo veći set istorijskih podataka, potrebno je odrediti veći buffer. Buffer se računa koristeći multiplikatore koji se primenjuju na sam Velocity, a multiplikator zavisi od prethodno objašnjene pouzdanosti podataka (npr. 10%, 20%, 50%).

I za kraj...

Možda na prvi pogled ceo proces može izgledati suviše kompleksno i neostvarivo, ali verujte da nije tako. Trud koji je potrebno uložiti da se dođe do potrebnih ulaznih podataka gledajte baš tako, kao ulaganje, a ne kao trošak. Dobit je višestruka. S jedne strane, sve interesne strane znaju šta mogu da očekuju i da donose odluke u skladu sa time. S druge strane, kreirate atmosferu u kojoj je svim interesnim stranama jasno da je stvaranje softverskog proizvoda nepredvidiv proces. I da je, na sreću, uticaj te nepredvidivosti moguće kontrolisati.

autori:

  • Jovana Kaluđer, Delivery Manager Medior @ Levi9 Serbia
  • Vladimir Švonja, Delivery Manager Medior @ Levi9 Serbia

Posetite profil kompanije Levi9.

Galerija