ALM – upravljanje radnim stavkama

Work Item ManagementOd početnog planiranja pa sve do održavanja nakon isporuke, softverski projekt prepun je zadataka koje treba obaviti, odnosno, kako se to u ALM terminologiji naziva, radnih stavki (work items). Radna stavka širi je pojam od pojma zadatak i predstavlja bilo koji jedinični ili skupni dio posla koji se obavlja na projektu.

U softverskom razvojnom procesu razlikujemo upravljanje zadacima, korisničkim i tehničkim zahtjevima aplikacija, upravljanje bugovima, testovima i testnim slučajevima koje treba testirati. Sve to spada u pojam upravljanje radnim stavkama. Ovisno o metodologiji razvojnog procesa, razlikuju se i definicije radnih stavki na projektu.

Zahtjevi korisnika prvi su artefakt s kojim se susreće jedan razvojni projekt. Tradicionalni razvoj softvera predviđa da se svi zahtjevi korisnika prikupe na početku projekta. Nove agilne metodologije prikupljaju zahtjeve korisnika tijekom cijelog procesa razvoja. Bez obzira u kojem se vremenu prikupljaju zahtjevi, upravljanje zahtjevima (requirements management) izuzetno je važno za uspjeh cijelog projekta. Kvalitetna definicija i obrada zahtjeva preduvjet su kvalitete i same krajnje aplikacije ili sustava. Svaka greška nastala u razvoju, radi krivo definiranih zahtjeva stvara višestruko veći trošak, nego da je dobrom razradom otklonjena na samom početku.

Definiranje i upravljanje novim zahtjevima na postojećim aplikacijama ili sustavima u produkciji često nazivamo upravljanje promjenama (change request management). Ako su ti zahtjevi za promjenama uvjetovani otkrivenim problemima na sustavu, onda se ta disciplina naziva i upravljanje greškama (issue managmanet) ili upravljanje bugovima (bugtracking management). Sve ove poddiscipline dio su sustava za upravljanje radnim stavkama (work items management system). Na tržištu postoje i odvojeni alati za neke od ovih disciplina. Najčešći su alati za praćenje bugova. Međutim bugovi samo su jedna vrsta radne stavke koju je potrebno pratiti na projektu.

Rad u brojkama

Definiranje bugu u Microsoft ALM sustavuŠto definira jednu radnu stavku? Kao prvo to je vrsta radne stavke. Već je spomenuto da radna stavka može biti bilo koji dio posla na projektu: zahtjev, zadatak, testni slučaj, bug i drugo. Svaki tip radne stavke ima točno definirane atribute kao što su naziv, opis, član tima kojem je trenutno pridružen, vremenska i logička kategorizacija radne stavke te ponekad procjenu vremena i novaca potrebnih za njihovu implementaciju. Vrste atributa se mogu mijenjati ovisno o pravilima na projektu i metodologiji rada. Osim definicijom polja, radna stavka određena je i workflowom, odnosno definicijom mogućih stanja i tranzicija između njih. Na primjer, bugpočinje stanjem „otvoren“, nakon čega je pridružen odgovarajućem članu tima i spreman za rješavanje. Kada se riješi, prelazi u stanje „riješen“, a nakon što se testira i potvrdi rješenje, prelazi u stanje „zatvoren“. Ovisno o metodologiji rada, stanja može biti i puno više. U strožim okruženjima, onima koja zahtijevaju bolju kontrolu, zahtjev za promjenama prolazit će kroz razna stanja odobravanja prije nego što dođe na implementaciju. Nakon implementacije takva radna stavka nastavlja svoj hod kroz razne validacije prije nego što se pusti u produkciju i zatvori. Konzistentnim korištenjem radnih stavki omogućuje se transparentnost na projektu, a to je jedan od glavnim ciljeva ALM-a.

Poveži sve sa svime

burndown dijagramRadne stavke glavni su način kolaboraciju u razvojnom timu oslonjenom na ALM. Sve što se tiče razvoja počinje i završava radnom stavkom. Svaka promjena označava se radnom stavkom ili nekim njenim atributom. Ako se radi promjena u kodu, onda se ta promjena veže uz određenu radnu stavku. Skup promijenjenih datoteka koji se sprema u središnji sustav za verzioniranje koda naziva se changeset. Osim što sadrži sve promjene na izvornom kodu, changeset sadrži i poveznicu na jednu ili više radnih stavki. Time je zabilježeno da spremljene promjene čine rješenja ili su pak na bilo koji način povezane sa definiranim zadatkom, zahtjevom ili bugom. Svako testiranje aplikacije proizlazi iz definicije testnog slučaja, što je također radna stavka, a naiđe li se na grešku, stvara se radna stavka bug, koji se pridružuje testu kroz koji je utvrđen. Automatizirani dnevni build proces, koji se pokreće jednom dnevno na projektu, prikuplja informacije o svim radnim stavkama riješenim prethodnog dana, te na kraju svog procesa kreira izvještaj u kojemu su popisani bugovi, zadaci i druge radne stavke odrađene u tom periodu. Radne stavke nalaze se posvuda u ALM sustavu i konzistentno korištenje radnih stavki preduvjet je transparentnosti razvojnog projekta. Ne samo da time svi članovi tima točno znaju što su im zadaci, nego dobivaju i širu sliku stanja projekta i za sve što rade znaju kako to utječe na cjelokupni projekt.


Radne stavke kako ih definira MSF Agile 5.0 metodologija iz Microsoft ALM-a:

User Story – Opis funkcionalnosti kako ju definira korisnik. Svaki user story opisuje željenu funkcionalnost ili svojstvo iz perspektive korisnika. Pojam je preuzet iz Scrum procesa razvoja. Donekle odgovara opisu use caseaili scenarija u drugim metodologijama.

Task – Zadatak. Osnovna jedinica rada. Nakon definicije user storya, potrebno je definirati zadatke po kojima će se on implementirati, te takve zadatke dodijeliti članovima tima. U svakom trenutku jedan zadatak može pripadati samo jednom članu tima.

Bug – Greška koju treba ispraviti. Bugovi definiraju grešku i opisuju korake kako ju ponoviti. Može se povezati na određeni user story uz koji je logički vezan, a također i uz test case, koji opisuje korake testiranja kojim je utvrđena greška. Svaki bug pridružen je jednom članu tima, ima svoj prioritet, stanje i druge atribute. Stanja buga su: otvoren, riješen i zatvoren. Bug otvara onaj tko ga je pronašao, tester ili sam programer. Programer ga rješava i stavlja u stanje riješen, a zatim inicijator buga potvrđuje da je rješenje dobro i stavlja ga u stanje zatvoren ili ga pak reaktivira i stavlja natrag u stanje otvoren.

Issue – Opis problema koji treba riješiti da bi se mogao nastaviti rad na funkcionalnosti user storya. Issue se pridružuje određenom članu tima. Među atributima može se definirati i datum „due date“ – do kada problem mora biti razriješen. Svaki član tima ima uvid u svoju issue listu, u kojoj je popis problema za koje je on odgovoran da ih riješi.

Test Case – Opis testnog slučaja. Testeri ili druge osobe zadužene za testiranje prvo definiraju testne slučajeve, a potom ih prolaze prema koracima koji su dio definicije testnih slučajevima. Test case je osnovna jedinica rada testera tijekom testiranja. Test Case radne stavke pridružuju se određenom user storyui time definiraju što je sve potrebno testirati uz određenu funkcionalnost.

Shared Steps – Radna stavka koja se koristi kod manualnog testiranja za opis koraka testa koji se ponavljaju kod veće količine testnih slučajeva. Definirani Shared Steps može se pridružiti raznim test casovima i predstavlja segment testiranja koje je zajedničko svim pridruženim testnim slučajevima.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>