Agile u IT-u: 8 metoda dekompozicije zadataka

Prva i možda najvažnija faza rada s Product Backlogom u Agile-u je dekompozicija zadataka, razbijanja različitih zahtjeva u čestične, razumljive korisničke priče (User Stories). Što su zahtjevi kvalitetnije podijeljeni, to je jasnije njihovo značenje i metode implementacije, ali i kako točnije planirati vrijeme rada na njima. Što je zadataka više, veće su šanse za postizanje ciljeva sprinta, a sadržaj izdanih inačica lakše će se predviđati.

Kako izvesti razvrstavanje zahtjeva u Product Backlogu? Razmotrimo 8 tehnika koje će Vam pomoći da učinkovito izvedete razdvajanje zahtjeva na User Stories. U radu s Agile-om, velika prednost bi bila istodobna upotreba nekoliko opcija razvrstavanja, pa je nužno predstaviti niz mogućih metoda.

Zašto i u kojem trenutku treba provesti dekompoziciju zahtjeva?

Zaustavimo se na trenutak na ovoj točki. Razvoj softvera je prilično nepredvidljiv proces i sadrži mnogo zadaća i međuovisnosti koje je teško precizno unaprijed procijeniti. Očekivano je da će u procesu implementacije neki zahtjevi zahtijevati više vremena nego što je izvorno bilo predviđeno. Utjecaj na izdavanje velikih i malih zadataka u ovom slučaju bit će različit:

  • Ako u okvirima iteracije (sprinta) radimo na nekoliko velikih i složenih zadataka, tada će, kao prvo, takve zadatke biti teško procijeniti ​​s velikom točnošću, a kao drugo, podcjenjivanje čak i jednog od njih može uvelike utjecati na postizanje ciljeva sprinta. Već ako izostavite 1 ili 2 od planiranih značajki, to je odmah -50% korisnog rezultata.
  • S druge strane, mali i čestični zadaci nemaju takav ozbiljan utjecaj na ciljeve sprinta, budući da su planirani za sprint (što znači da svaki ima manji doprinos) i njihova procjena će biti puno preciznija.

Dekompozicija zadataka može se provesti na početku predstojećeg sprinta tijekom njegovog planiranja, ali i tijekom sprinta, prilikom podjele zahtjeva za iduće iteracije. Poželjna je druga varijanta jer je bolje je ne povezivati dekompozicija zadataka s određenim sprintom, kako bi došli do planiranja istog s već gotovim backlogom koji je podijeljen u korisničke priče. U slučaju da postoje zalihe razdvojenih zahtjeva, onda:

  • Kao prvo, ne ograničavamo izbor zadataka za sprint (možemo raditi samo na onome što smo razvrstali).
  • Drugo, pri planiranju više nije potrebno trošiti vrijeme na podjelu i tim se može usredotočiti na formiranje sprinta na temelju prioriteta, raspravljati o međuzavisnostima i nijansama provedbe zahtjeva.

Dva glavna pristupa dekompoziciji.

Postoje dva koncepta, dva osnovna pristupa k razlaganju velikih zadataka u korisničke priče – „horizontalno“ i „vertikalno“ particioniranje:

  • U slučaju „horizontalne“ dekompozicije, zadaci su podijeljeni po vrsti posla (funkciji) kojeg treba odraditi a izvršavaju ga komponente koje su uključene u rad. U tom slučaju, prilikom razdvajanja zajedničkog velikog zadatka, programeru će se dodijeliti jedan dio, drugi testeru, tehničkom piscu treći i tako dalje. U biti, nijedan od dijelova ne dovodi do konačnog rezultata sam po sebi, kako bi se izdao gotov funkcionalan proizvod potrebno je realizirati cijeli niz povezanih zadataka od svih sudionika u procesu.
  • S druge strane, metoda „vertikalne”“ dekompozicije podrazumijeva raspoređivanje manjih zadataka, značajki i funkcija na takav način da se svaka takva korisnička priča može izvesti i izdati odvojeno od drugih zadataka. U tom slučaju, različite uloge mogu biti uključene u razvoj, a mogu biti uključeni i neki moduli i sustavi.

Particioniranje zadataka pomoću „vertikalne“ metode više je u skladu s načelima Agile-a i njegova primjena je mnogo učinkovitija. Glavni razlozi su sljedeći:

  • S „vertikalnim“ particioniranjem, svaki zadatak može biti izveden, testiran i demonstriran klijentu/korisniku, što je za njih jasnije i mjerljivo za razliku od „tehničkih“ zadataka u „horizontalnom“ particioniranju.
  • S „vertikalnom“ metodom, svaka konačna korisnička priča ima poslovnu vrijednost, što znači da je takve zadatke lakše uspoređivati i odrediti im prioritetnost.
  • Budući da su u provedbu zadataka koji su razvrstani prema „vertikalnom“ načelu uključeni stručnjaci različitih uloga, njima je lakše prepoznati moguće poteškoće, međuovisnosti i rizike koji mogu nastati u procesu rada.

Sada, kada su jasne potrebe i načela dekompozicije, razmotrit ćemo različite načine podjele velikih zadataka backloga na manje korisničke priče. U svim ovim varijantama i tehnikama primjenjuje se načelo „vertikalne“ dekompozicije.

Tehnike dekompozicije zahtjeva u Agile-u

  1. metoda: Razbijanje na etape/faze poslovnog procesa.

Pomoću ove metode moguće je pokušati razbiti veliki zadatak koji opisuje poslovni proces u svoje sastavne dijelove i etape. Da bi se to ostvarilo, u ovom procesu potrebno je napraviti sekvencijalni lanac koraka koji se mogu implementirati i izvršiti neovisno jedan o drugom. Da objasnimo ovu metodu dekompozicije dati ćemo sljedeći primjer:

  • U backlogu imamo veliki zahtjev – implementirati klijentu funkciju kupovine putem online trgovine.
  • Unutar procesa kupovine možete izdvojiti, na primjer, sljedeće korake:
  • prijava na svoj račun
  • pregled proizvoda u „košarici“
  • formiranje računa za plaćanje
  • slanje računa poštom
  • različiti načini plaćanja: bankovni prijenos, kartica itd., potvrda o plaćanju.
  • Svaka takva faza može se identificirati i opisati kao zasebna korisnička priča.

Kao rezultat dobivamo to da podijelimo veliki poslovni proces u njegove sastavne etape. Pritom, u ovom slučaju neke etape mogu biti kritične i obvezne, a neke opcionalne. Takva dekompozicija omogućuje da:

  • U prvom redu prepoznate različite prioritete za svaku priču i usredotočite e prvenstveno na etape koje su najvažnije za poslovanje.
  • Drugo, kod takve vrste particioniranja razumljiviji je proces, njegovi koraci i sastavnice, te elementi koji zavise jedni od drugih među etapama.
  1. metoda: Podjela po pozitivnim i negativnim scenarijima

Zapravo, svaka funkcija ima ispravni/direktni scenarij korištenja, što dovodi do očekivanog/pozitivnog rezultata. Međutim, kada korisnik radi s ovom ili onom funkcionalnošću, može doći do odstupanja od ispravnog postupka: prenose se pogrešni podaci, nisu ispunjeni svi potrebni uvjeti, potrebni pristupni podaci nisu dostupni itd. Takva odstupanja od direktnog scenarija rada dovest će do negativnih rezultata (akcija neće biti izvršena, funkcija neće raditi na pogrešan način, itd.).

Sukladno tome, možemo izvršiti dekompoziciju za očekivani scenarij korištenja funkcije i za pogrešne, ali moguće i vjerojatne scenarije rada. Za svaki scenarij važno je izdvojiti zasebne korisničke priče:

  • Za pozitivan – implementacija pravilnog rada funkcije.
  • Za negativne – provesti odgovarajuće ispitivanje jedne ili druge moguće pogreške, razviti alternativni scenarij.

Kao primjer dekompozicije zahtjeva u pozitivne/negativne scenarije, ponovno razmotrimo funkciju kupovine putem online trgovine:

Pozitivan scenarij: korisnik se prijavljuje na svoj račun na web mjestu i kupuje plaćajući karticom. Ili u formatu korisničke priče: „kao klijent, mogu se prijaviti na svoj korisnički račun za kupovinu s plaćanjem karticom“.

Negativni scenarij 1: klijent pokušava izvršiti kupovinu bez odobrenja.

Negativni scenarij 2: korisnik pokuša izvršiti kupovinu, ali nema dovoljno sredstava na računu i uplata ne prolazi.

Negativni scenarij n: klijent pokušava dovršiti kupovinu, ali je njegov račun blokiran zbog netočnog unosa zaporke.

Ova vrsta razgradnje omogućuje Vam da izolirate, analizirate i isplanirate obradu različitih izuzetaka i netočnih scenarija korištenja softvera, kojih će svakako biti.

  1. metoda: Razvrstavanje prema pravilima/uvjetima poslovnog procesa

Za razliku od prethodne metode, u ovom slučaju ne razbijamo proces na etape, već na logičke grane, tj. moguće varijante za izvođenje funkcija. Zapravo, definiramo skup scenarija pomoću kojih se proces može izvršiti kada se zadovolje određena pravila/uvjeti.

  • Da bismo ilustrirali ovu metodu dekompozicije, uzmimo isti primjer: potrebno je klijentu implementirati funkciju kupovine u online trgovini.
  • U tom slučaju možemo izdvojiti, na primjer, sljedeći skup pravila za kupovinu:
  • Određen se minimalni iznos, a ako je iznos kupovine manji od toga, kupcu se prikazuje odgovarajuća poruka.
  • Ako iznos kupovine premašuje određenu vrijednost, klijentu se nude dodatne opcije plaćanja.
  • Ako se ispostavljeni račun ne plati u roku od 2 dana, narudžba se automatski otkazuje.
  • Provedbu svakog takvog pravila može se staviti u zasebni zadatak

Ova metoda dekompozicije zahtjeva omogućuje sljedeće:

  • Identificirati i unijeti u zasebne korisničke priče različita pravila i ograničenja koja se mogu pojaviti u sklopu procesu/funkcije. Tako se umanjuje rizik da se zaborave ili da se dogodi propust oko nekih važnih uvjeta.
  • U pravilu, provedba određenih uvjeta u poslovnom procesu imat će različite prioritete: nešto je potrebno provesti u prvoj verziji proizvoda, a bez nekih drugih elemenata ćete moći raditi neko vrijeme. Dekompozicija jedinstvenog procesa prema uvjetima/pravilima omogućit će Vam da izradite redoslijed implementacije pojedinih korisničkih priča.
  1. metoda: Razvrstavanje prema vrsti operacije.

Postoji niz relativno standardnih operacija koje se često susreću u različitim funkcijama. Te operacije mogu se klasificirati kao „zadane“ radnje: stvaranje, čitanje, ažuriranje ili brisanje. Skraćeno, ta metoda se naziva CRUD – od riječi Create, Read, Update, Delete. CRUD operacije su vrlo česte u slučajevima kada funkcionalnost uključuje upravljanje predmetima, kao što su proizvodi, narudžbe, korisnici, datoteke itd.

Pomoću primjera opet one iste online trgovine možemo napraviti dekompoziciju funkcija za rad s karticom proizvoda:

  • Create – stvaranje novog proizvoda u online trgovini
  • Read – pregledajte opis proizvoda
  • Update – uređivanje/ažuriranje opisa proizvoda
  • Delete – brisanje proizvoda iz trgovine

Kad se funkcije razvrstavaju na ovaj način prilično je lako odgovoriti na sljedeća pitanja:

  • Koje operacije su stvarno neophodne za rad s ovim ili onim objektom? U pravilu, operacije su međusobno povezane i nema smisla stvaranje tog objekta bez mogućnosti da ga se pregleda. Međutim, razdioba operacija odredit će njihov prioritet.
  • Na koji način provesti svaku od operacija? Možda se jedno te ista operacija treba izvesti na nekoliko načina. U tom slučaju, dekompozicija se može nastaviti, a implementaciju svake od metoda staviti u zasebnu korisničku priču. Na primjer, moramo implementirati stvaranje novog objekta putem sučelja web aplikacije, putem administracijske ploče na prodajnom mjestu, dodavanjem podataka u bazu podataka itd.
  1. metoda: Dekompozicija ovisno tipu OS/platforme.

Ovdje je sve vrlo jednostavno – kriterij za raspodjelu zahtjeva na sastavnice je potreba za implementacijom jedno te iste funkcije na različite platforme, uređaje i operacijske sustave.

Na primjer, moramo razviti u web aplikaciji funkciju plaćanja neke kupovine od strane korisnika. U tom slučaju, možete napraviti dekompoziciju zahtjeva na zadatke za implementaciju funkcije kupovine:

  • Za različite platforme: osobna računala, tablete, pametne telefone.
  • Za različite OS: Windows, iOS i Android.
  • Za raditi u različitim browserima.

Razdvajanjem zahtjeva na ovaj način može vrlo lako naglasiti glavne prioritete razvoja proizvoda i usredotočiti se na njih. Na primjer, u početku se možete usredotočiti na razvoj mobilne inačice aplikacije, a desktop verziju ostaviti za kasnija izdanja.

  1. metoda: Raspodjela po vrsti podataka i parametrima.

Za neke funkcije moguće je odabrati različite vrste podataka ili parametara koje moraju obraditi. Sukladno tome, možemo razdijeliti veliki zahtjev/značajku u niz malih korisničkih priča, gdje u okvirima svake moramo implementirati rad sa samo jednom vrstom podataka.

Za primjer uzet ćemo funkciju pretraživanja za online trgovinu. U tom se slučaju dekompozicija na podzadatke može provesti na temelju različitih upita s trake za pretraživanje, na primjer:

  • Pretraživanje pomoću teksta (naziv proizvoda)
  • Pretraživanje pomoću numeričkih vrijednosti (broj proizvoda)
  • Pretraživanje pomoću regularnih izraza

Prilikom korištenja ove metode dekompozicije možemo jasno odrediti važeće i nevažeće parametre za implementiranu funkciju (na primjer, funkciju pretraživanja). U tom slučaju, podrška za dio vrsta podataka/parametara može biti pružena odmah, dok se drugi mogu implementirati na pojednostavljeni način ili zabraniti za upotrebu.

  1. metoda: Particioniranje po ulogama/pravu pristupa

Mnogi poslovni procesi i funkcije često podrazumijevaju sudjelovanje/zajednički rad s klijentom u nekoliko uloga i korisničkih skupina. Svaka grupa korisnika s određenom ulogom i pravima pristupa može izvršiti samo određeni dio funkcija cjelokupnog procesa.

Prilikom podjele funkcija za rad s proizvodima u online trgovini na temelju korisničkih uloga možemo primjerice predstaviti sljedeće zadatke:

  • Vlasnik online trgovine:
  • Stvaranje/brisanje proizvoda iz online trgovine.
  • Pregled i uređivanje opisa proizvoda.
  • Administrator online trgovine:
  • Pregled i uređivanje opisa proizvoda.
  • Obrada zahtjeva/komentara kupaca.
  • Klijent/kupac:
  • Pregled opisa proizvoda.
  • Rezervacija/kupovina proizvoda u online trgovini.

Razdvajanjem cjelokupne funkcionalnosti na uloge koje bi trebale ispuniti svoje dijelove, jasnije ćemo razumjeti koje su funkcije potrebne i tko ima pristup za njihovo izvršavanje. U ovom slučaju, u početnim fazama moguće je odrediti prioritete i implementirati samo osnovne skupove funkcija za svaku ulogu, a zatim proširiti njihove mogućnosti.

  1. metoda: Razvrstavanje po testnim scenarijima/test-caseovima.

Ova strategija dekompozicije omogućuje Vam da velike korisničke priče razbijete pitanjem kako će se testirati ovaj ili onaj dio funkcionalnosti. Utvrđuje se koje scenarije je neophodno provjeriti, koji testovi se trebaju provesti kako bi se utvrdilo radi li ta funkcija. Kao rezultat, formirat ćemo skup testnih slučajeva, od kojih će svaki biti poseban zadatak. Svaki zadatak mora se provesti da bi testni scenarij bio uspješno završen.

Razmotrite primjer funkcije – klijent odabire proizvod u online trgovini i stavlja ga u „košaricu“ za kupovinu. U sklopu ove funkcije mogu se razlikovati sljedeći testni scenariji (u nastavku je primjer samo dijela mogućih test-caseova):

  • Proizvod je na skladištu i dostupan je za kupovinu.
  • Proizvod je na skladištu, ali je već rezerviran od strane drugog kupca.
  • Proizvod nije dostupan.

Koje su prednosti korištenja ove metode dekompozicije:

  • Ova strategija zapravo kombinira mnoge tehnike dekompozicije koje su ranije predstavljene. U procesu sastavljanja popisa testnih slučajeva automatski ćemo analizirati:
  • Uvjete poslovanja
  • Pozitivne i negativne scenarije korištenja funkcije
  • Formate podataka i parametara.
  • Prilikom analize testnog scenarija lako je shvatiti koliko je isti uobičajen i vjerojatan u uvjetima stvarne upotrebe proizvoda, a to omogućuje postavljanje odgovarajućih prioriteta.
  • S ovom metodom particioniranja dobivamo odmah opis za zadatak/korisničku priču i scenarij pomoću kojeg se može provjeriti uspjeh njegove implementacije.