Prije nego se bilo ko odluči raditi bilo koji zadatak, potrebno je da vidi da li je zadatak jasno definisan. Ako nije, onda neki od uslova svakako nisu ispunjeni i postizanje rezultata kroz optimalno rješenje vjerovatno neće uroditi plodom. O tome kako jasno definisati cilj i korake za njegovo postizanje pisalimo su članku: Znamo li šta hoćemo?

Definisanje spremnosti (Definition of Ready/DoR) je nešto što bi trebala da bude veoma dobra, pozitivna praksa. Definisanje spremnosti se ne može unificirati. Čak je nemoguće imati istu definiciju spremnosti za sve timove unutar jedne firme, ili unutar timova koji rade na istom proizvodu. Svaki tim ima svoje vlastite odgovornosti i treba da odlučuje šta je to za tim relevantno kao definicija spremnosti. Svakako, ako se nekome ko nikada nije pisao definiciju spremnosti kaže ovako nešto, takav vjerovatno neće biti u stanju napisati nešto što su dobre prakse. Zato, uvijek se treba truditi kod bilo koje priče da ona ne bude isprazna, šuplja, nego ponuditi konkretna rješenja i konkretne primjere, a što ćemo mi učiniti u nastavku.

Primjeri u nastavku su primjeri definicije spremnosti za svijet razvoja/proizvodnje softverskih rješenja.

Osnovni znak da se spremno početi raditi na zadatku je: Ah, da, shvatili smo! Sada tačno i precizno znamo šta treba napraviti.

Pri čemu to nije samo puka izreka, nego doista da se shvati problem i šta je potrebno da se uradi.

Primjer #1

• Zadatak je opisan u obliku priče (Story — Šta je i kako bi trebala da izgleda dobra priča pisali smo u članku: Dobra priča)
• Odnosi s drugim funkcionalnostima/dijelovima softvera su jasne.
• Moguće je procijeniti kompleksnost zadatka (Koliko je potrebno resursa i kakvih, koja je potrebna stručna sprema i vještine ljudi koji će raditi, koliko vremena, …).

Primjer #2

Izvršioci kojima se prezentuje zadatak jasno razumiju zadatak kroz neke od tačaka:

• Opis zadatka ima jasno definisane funkcionalne i nefunkcionalne kriterije prihvatanja (Acceptance criteria). Članak Dobra priča govori ponešto o tome.
• Opis zadatka sadržava slučajeve opisane jezikom razimljivim i tehničkim i ne tehničkim licima (Gherkin language). Pisali smo dva šaljiva članka na temu Gherkin jezika: Umotani — Behat i Jeste li znali da kornišoni imaju svoj jezik?
• Identifikovane su zavisnosti i procijenjeni su rizici.
• Nova funkcionalnost neće uništiti zavisnosti (backward compatibilities).
• Opis zadatka sadržava grafički prikaz onoga što treba da bude urađeno u grafičkom dijelu softvera (mockup, full (static) design, …).
• Tehnička i poslovna dokumentacija su ažurirane u skladu s zahtjevima zadatka.

Procjena kompleksnosti zadatka je vjerovatno najteži i svakako najkompleksniji dio kod definisanja spremnosti. O tome ćemo pisati u nekim posebnim člancima. Jedino šta možemo spomenuti ovom prilikom je to da svaki tim određuje vrijednosti kompleksnosti spram vlastitog iskustva. Jednom određena kompleksnost se nikada ne mijenja. Ako npr. tim nije upoznat s nekom tehnologijom i procijene kompleksnost s nekim oznakom K, tu vrijednost će zadržati uvijek, bez obzira što tim ima saznanja. Tj, ako se timu dogodi da na istom zadatku radi kroz neko vrijeme, procijeniće ga isto.

0

Hits: 0