Možda je bolje nazvati ovaj članak koje protjerao pripovjedanje, ali u nastavku ćemo čitaocu pokušati dati neke naznake, pa neka sam donese vlastite sudove.

Je li novac božanstvo?

Komercijalizacija je golem, svjetski, historijski, planetarni problem neviđenih razmjera. Naravno, komercijalizacija postoji oduvijek, ali uz savremni marketing ona dobija jednu novu dimenziju – veoma neetičku, brutalnu, kranje bezobraznu koja ne mari nizašta osim za profit. Sve je podređeno profitu! Baš sve! Pa čak i brak i djeca i roditelji, bližnji, prijatelji, na sve njih gledamo očima kakav profit i kakvu korist od svih njih možemo izvući, kako kraktoročno, tako i dugoročno.

Ista je stvar (na veliku žalost iskrenih, istinskih inžinjera) i s Informacionim tehnologijama, na prvom mjestu programiranjem, odnosno razvojem softvera (i sve ono što nije nužno programiranje, poput infrastrukture, mreže, sigurnosti, …, ali je u bliskoj vezi).

Ko je još čuo za XP?

Ako bi neko spomenuo XP u rečenici među informatičarima, nismo sigurni koliki broj ljudi bi bio hrabar pomisliti na nešto drugom osim verzije Windows XP (I to oni malko ili malo više stariji)!

Danas se priča samo i jedino o Agilnosti (Agile). U svim predavanjima i treninzima priča se o tome kako je nekada postojao princip vodopada (Waterfall) i kako se nekih 17 likova koji nemaju života, nego im kompjuteri vire iz očiju negdje sastalo u nekom zimovalištu i donijelo revoluciju – Proglas agilnosti (Agile Manifesto).

Naravno, kako već spomenusmo iznad, marketing odradi svoje!

Danas je ogroman broj ljudi ubijeđen da je dosita tako i bilo. A da li je?

Ustvari, između onoga što mi zovemo Waterfall i Agile Manifesto bilo je jako mnogo drugih pokušaja upostavljanja metodologije za uspješan razvoj softvera. Najznačajniji od njih je upravo onaj iz kog je agilna metodologija ROĐENA! A to je naravno XP – eXtreme Programming, odnosno kranje moguće ili ekstremno programiranje.

Šta nam je donio agilni pristup?

Iako je od sastanka u zimovalištu i proglasa agilnosti prošlo haman pa 20 godina mnogi ljudi koji se pozivaju na njega, odnosno na agilni pristup (nebitno da li je to tzv Scum, Kanban, Lean ili pak neki drugi), iz dubine duše vjeruju i osjećaju da je to ploča sa zadacima! U svijetu razvoja softvera tu svakako prednjači alat australijske kompanije Atlassian – Jira*.

To je tako iz mnoštva razloga, ali bićemo slobodni pa reći da je to najvećim dijelom zbog uticaja marketinga, mada nije mahane ni samim potpisnicima proglasa agilnosti.

Svi znamo svakako da je nam je agilnost donije neke nove stvari (ali ipak preuzete, većinski iz XP-a), kao što su:

Veličine i oblik timova
Scrum master
Menadžer projekta (A ne menadžer ljudi! Ovo nam nikada neće dosaditi ponavljati)
Backlog
Ograničeno (uslovno rečeno) trajanje iteracije
I druge manje ili više važne stvari

Agilni pristup je postao svjetski prepoznatljiv i naprosto sve firme su htjele da se okušaju u tome (tačnije da budu veoma uspješni prelazeći na agilni pristup, kao da je on neki čarobni štapić). Danas gotovo da ne poznajemo firmu (ozbiljnu i uticajnu na tržištu), a koja ne posluje po nekoj od agilnih metoda. I to je odlično! Vrijeme nam pokazuje da je odlično. Ali nam vrijeme, najbolja učiteljica – historija, govori da neke stvari ipak ne radimo dobro, a ne radimo ih prije svega zato što smo dobre prakse iz XP-a izbacili, a nismo ih ničim drugim, boljim zamijenili.

Šta nam je odnio agilni pristup?

Kao što spomenusmo u prethodnom poglavlju, komercijalizacija ideje i marketing učinili su svoje i dobili smo što smo dobili. Tako se dogodilo da su dvije veoma važne stvari koje su bile u XP-u, (ne)namjerno izbačene ili potisnute u drugi, treći, n-ti plan, i to:

Pripovijedanje
Testiranje

Testiranje se još koliko toliko bori. Imamo jako mnogo ljudi širom svijeta koji promovišu testiranje i koji hoće reći kako je razvoj softvera bez testiranja sve osim istinskog razvoja. Oni snažno, s veoma snažnim argumentima, promovišu korištenje BDD (Razvoj softvera vođen ponašanjem – Behaviour Driven Development) i TDD (Razvoj softvera vođen testovima/testiranjima – Test Driven Development).

Pisali smo cijelu niz članaka iz knjige popularnog Software Craftsman-a, Brazilca Sandro Mancuso-a, o njegovoj knjizi The Software Craftsman – The: Professionalism, Pragmatism, Pride, a koja gotovo cijela govori o tom propuštenom, veoma dobrom i pouzdanom modelu razvoja softvera iz XP metodologije.

Međutim, ne nalazimo da se iko bori za pripovijedanje, koje također smatramo veoma važnim u razvoju softvera.

Pripovijedanje (Narrative)

Većina developera i svih onih okupljenih oko jednog agilnog tima, pomislila bi da se tu vjerovatno radi o scenariju (Scenarious). Međutim to nije isto. Sličnosti svakako ima, naravno.

Namjera pripovijedanja odnosno pripovijesti nije da se ponudi tehnička perspektiva, niti cjelovit opis onoga što je potrebno razviti, nego da to bude osnovna komunikacija imeđu SVIH zainteresovanih strana (preduzeća, analitičara, programera, testera, …).

Pripovijest bi trebala biti kratka, što kraća i konciznija to bolja svakako, no mora odgovoriti na tri pitanja i to:

Da bi se (In order to) – koja korist ili vrijednost treba biti proizedena?
Kao (As a) – kome je to potrebno?
Želim (I want to) – šta je osobina/svojstvo ili cilj?

Izvan okvira IT-a, recimo u okviru očivanja ove veb stranice – b(r)loga, nekakva pripovijest bi bila:

Pripovijest:
Da bi sačuvao svoj rad (da bi [se] - in order to)
Kao pisac b(r)loga (kao - as a)
Želim moći sačuvati objave/postove (želim - I want to)

Kao što se vidi iz priloženog, uopšte se nije govorilo ni o kakvoj tehničkoj perspektivi, kao što se to veoma često radi u Pričama (stories), niti posebnim tehničkim osobinama (features).

Također, valja znati da pripovijedanje nije isto što i zahtjev, da ne bi došlo do zabune. Dvije najvažnije stvari koje čine ključnu razliku između pripovijesti i zahtjeva su:

Preciznost
Planiranje

Preciznost

Pripovijesti ustvari favorizuju verbalnu komunikaciju. Pripovijesti su uslovno rečeno neka agenda na jednom prezentacionom slajdu. Nešto na osnovu čega se definiše zahtjev, obzirom da pisani jezik može itekako biti manjkav, posebno tehnički pisani jezik.

Možda nam se čini da nije tako, ali sjetimo se samo koliko puta smo napravili neki softver, o dizajnu da i ne govorimo, a ispostavilo se da je to veoma daleko od onoga što je traženo, iako se slijedila dokumentaciju.

Evo konkretnog primjera pisane riječi naspram usmene, verbalne komunikacije:

Natpis u restoranu može da bude npr:

“Predjelo može biti izbor salate ili pršute i hljeba.”

Inžinjerski, programerski gledano ili ne, ova izjava može imati dva značenja i to:

“Salata ili (šunka i hljeb)”
“(Salata ili šunka) i hljeb”

Kada konobar dođe da uzme narudžbu i usput sa sobom ponese hljeb te stavi na sto i upita: “Salata ili šunka?“, sve nedoumice nestanu u sekundi, zar ne?

Drugi primjer je onaj informatičke prirode, kada se recimo traži da korisnik koristi ime od 16 znakova i 8 znakova za šifru prilikom registracije. Da li se tu misli na konkretan broj 16 i 8, najmanje 16 i 8 ili pak najviše 16 i 8? Ovakve primjere srećemo gotovo svakodnevno u razvoju softvera.

Planiranje

Da bi i planiranje imalo nekakvu svoju strukturu, ljudi “bolesni” od pravila i procedura dosjetili su se da napišu čak i standard za to, koji nosi oznaku IEEE 830.

Pripovijest nije isto što i zahtjev

Već prije spomenusmo, ali želimo naglasiti ponovo: pripovijedanje nije isto što i zahtjevi! Svakako, najbolje je uvijek objašnjavati kroz primjere, pa evo jednog:

- Proizvod mora imati najmanje 4 točka
- Proizvod mora imati upravljački mehanizam
- Proizvod se napaja električnom energijom
- Proizvod se mora moći proizvoditi u različitim bojama

A sada da vidimo kako izleda pripovijest, koja bi trebala biti napisana prije pisanja zahtjeva. Pripovijest koja će nam promijeniti u potpunosti sliku onoga što treba napraviti (na osnovu ovoga iznad):

Pripovijest:
U cilju zabave za djecu
Kao roditelj
Želim mali automobil

Ko i kada piše pripovijesti?

Svako bi trebao razviti praksu pisanja pripovijesti bez obzira na kojoj poziciji se nalazi. Pripovijesti će pokreniti lavinu pripovijedanja iz kojih će se izroditi mnoštvo zahtjeva koji će voditi ka konačnom cilju. Pripovijesti također snažno pomažu kod BDD, jer se stavlja žiža (fokus) upravo na ponašanje (Behaviour). One se također mogu i trebaju pisati kada god se rodi neka nova ideja, posebno u timovima s snažno orijentisanim agilnim metodama rada. U tom slučaju pripovijesti neće pisati “samo” Menadžer projekta (Project manager), nego i svi članovi jednog agilnog tima, a onda će o svakoj od pripovijesti u skladu s razvojem projekta pričati pripovijesti i praviti zahtjeve na sastancima za planiranja, brain-storming, možda čak i retrospective i drugi.

Pripovijest vs User story

Nakon proglasa agilnosti i pokušaja da firme pređu na agilnost u razvoju softvera razvila se jedna nova stvar naziva Korisnička priča (User story), a koja je po svoj prilici baš modifikovani, unaprijeđeni oblik pripovijesti iz XP-a. No daljnjim “razvojem” agilnosti, posebno Scrum-a, priča, odnosno Story u potpunosti je izbačen iz bilo kakve terminologije i još gore prakse, pa sada imamo samo i jedino Backlog item, i svaka “kartica” na ploči se naziva item, bez obzira da je li je to story, ticket, spike, ili pak neka druga vrsta ili kategorija “kartice”. Time se, (ne)namjerno, opet izbacila veoma dobra praksa iz prošlosti. Pitanje je zašto? I još je veće pitanje, da li je možemo vratiti nazad? Neki će vjerovatno reći, ako je izbačeno, znači da nam ne treba! Jer da je trebalo, ne bi bilo izbačeno!

Možemo li isto reći i za testove, koji se ponovo vraćaju na scenu nakon što su bili izbačeni (jer ne trebaju!?) nekih 15-ak godina?

* Jira – jako mnogo ljudi širom svijeta ne izgorava pravilo ime ovog alata. Naime, alat je dobio naziv po japanskom bendu koji se zove Gojira, a što je ustvari japanski naziv za Godzilla – također japanski film iz 1950-ih. Gojira se izgovara kao Go-dzi-ra, ali obzirom da slovna oznaka za glas DZ (ako uopšte čitalac može da izgovori ovakav glas gdje su glasovi D i Z skupa i čine jedan glas) ne postoji gotovo nigdje u svijetu izuzev u Japanu, to se pristupilo korištenju glasa DŽ, odnosno glas između DŽ i Ž. Tako da je ispravno izgovaranje naziva alata Jira ustvari Džira (Žira) ili s dugim I, ali ne predugo, kao dva glasa I, odnosno Džiira, (Žiira).

Gdje se izgubilo pripovijedanje?