5 Načina kako da upropastite vaše User Story-je u Agilnom razvoju softvera

with No Comments

1. Što veće, to bolje. Veličina je bitna!

Za većinu ljudi koji dolaze iz marketinga i prodaje veličina User Story-ja je uvek dobra i ne treba je menjati. Zašto? Ako je njima i njihovom menadžmentu veličina prikladna, zašto ne bi bila i drugima? Što jednostavnije, veće, to je bolje. Razvojni tim? Snaći će se već oni.

Realnost nam govori drugačije, da nije sve crno ili belo. Koja je zapravo prava veličina jednog User Story-ja? Odgovor nije lak. Ukoliko bismo tražili univerzalnu veličinu, morali bismo da uložimo dosta vremena i truda, ali rezultati ne bi bili pouzdani. Veličina nije univerzalna konstanta, već ona odgovara mestu gde se diskusija oko User Story-ja dešava. Da, diskusija, a ne opis i tekst koji ste napisali u vašem dokumentu. Diskusija je važan faktor, kako bi videli i odlučili koja je to zapravo odgovarajuća veličina. Moja najveća zabluda je bila da se ovo dešava kroz jednu konverzaciju. Ovo se  zapravo dešava, kroz seriju konverzacija sa različitim ljudima koji će biti uključeni u razvoj jednog User Story-ja.

 

Slika preuzeta iz knjige „User Story Mapping“ strana 139

 

Jeff Patton je u svojoj knjizi „User Story mapping“ objasnio ovaj proces na principu kamena. Zamislite prvu diskusiju između Product Owner-a i stakeholder-a koji dolaze iz marketinga i prodaje. Njihova prava veličina User Story-a se može klasifikovati kao veličina jednog velikog kamena. Kako se diskusija privodi kraju (nadamo se uživo, a ne preko elektronske pošte) i priprema se predaja timu koji će raditi razvoj, User Story-i će ostati veličine velikog kamena. Tim koji će raditi na razvoju, sada mora da razbije taj veliki kamen kako bi izgradio razumevanje o zahtevima.  Kada se razbije veliki kamen, šta se dobija? Opet kamen, ali ovog puta više njih manje veličine. Da li je lakše podići jedan veliki kamen ili više manjih iz nekoliko puta? Kako se vreme za razvoj približava, razvojni tim će nastaviti da lomi kamenje, dobijajući kamenčiće koje će moći da isporuče brzo do mesta gde su oni potrebni. Poslednja rečenica ilustruje zadnji korak razbijanja User Story-ja na razvojne zadatke.

Slika preuzeta iz knjige „User Story Mapping“ strana 139

 

Za ovaj process je potrebno vreme i serija radionica. Da radionica, a ne sastanaka. Zašto? Radionice zapravo asociraju na rad i na kreiranje nekog ishoda, dok su sastanci danas postali sinonim za neproduktivne diskusije.

 

2. Zapišite User Story, nemojte ga ispričati.

Uradili ste vaš domaći zadatak. Napisali ste User Story koji je spreman za razvoj. Stanite! Samo ste ga napisali? Da li ste imali bilo kakvu diskusiju sa timom koji će zapravo raditi na razvoju istog? Verovatno, tokom stresa i ostalih „prioriteta“ zaboravili ste na jednu reč koja je krucijalni deo, STORY. Posledica tog zaboravljanja je verovatno da ste sebi postavili više puta ovo pitanje: „Stvarno ne razumem, sve sam zapisao, zašto je tako teško razvojnom timu da se obaveže na isporučivanje zahteva“. Naime, ljudi i story-ji imaju jednu zajedničku stvar. Verovali ili ne i jedno i drugo su žive stvari, vole da komuniciraju i da ispričaju dobru priču.

Pre nego što krenete u razvoj vašeg zahteva kroz format User Story-ja, zaista je bitno da iskoristite priliku za konverzaciju i da ispričate priču. Koji problem rešavamo našim zahtevom, za koga se razvija i koje je očekivano ponašanje su neke od smernica koje vam mogu pomoći. Hajde ovde da zastanemo na trenutak i da se vratimo par koraka unazad. Vi niste opis vašeg zahteva počeli tako što ste sve prvo napisali u Excel fajlu, zar ne? Počeli ste verovatno tako što ste svoju ideju podelili sa nekoliko najbližih saradnika iz vašeg okruženja, sve sa ciljem, da dobijete potvrdu da je vredno i razumno uložiti vreme da se ta ideja razvije. Tek onda ste je zapisali. Sličan princip rada treba da iskoristite i kada radite sa razvojnim timom. Pre nego što predate vaš zahtev u pisanoj formi, pričajte sa timom. Verujte mi, nije komplikovano, čak je i lako. Samo postoji mali trik, morate naći vreme da obavljate svoj primarni zadatak kao Product Owner, a to je posvećenost vašem proizvodu i timu koji ga razvija. Kada  postanete svesni vaših prioriteta i zadataka, pokušajte da koristite 3C princip „Card, Conversation, Confirmation“. Ova magična formula od Ron Jeffries-a reflektuje tri osnovna koraka kako da napravite jedan dobar User Story.

  • Card (Kartica): Da to je vaš napisan Story. Niste ipak radili vaš domaći zadatak uzalud.
  • Conversation (Konverzacija): Jedan od najbitnijih delova. Predstavite vaš Story timu. Kroz diskusiju opišite koji problem rešava, ko će ga koristiti i na koji način. Opišite ponašanje i očekivane ishode. Čujte njihova razmišljanja i komentare.
  • Confirmation (Konfirmacija): Vaše želje i ideje su kul. Verifikujte ih sa timom. Potvrditi da imate isto razumevanje.

Međusobno razumevanje dovodi do bržeg i efektivnijeg razvoja kao i dobijanja posvećenosti od strane tima. Cela problematika ovog poglavlja je predstavljena slikom ispod.

Slika preuzeta iz knjige „User Story Mapping“ strana XXXIII

 

3. Pošaljite svih 1200 User Story-ja u Excelu, izbegnite svaku dalju diskusiju.

Nedavno sam bio na treningu za tradicionalni projektni menadžment (eng. waterfall). Iako se ovde fokusiramo na agilnost, moram da istaknem da metodologija nudi super alate za projekte koji nisu kompleksni, već komplikovani. Na treningu sam upoznao koleginicu koja se bavi razvojem proizvoda koji je uključivao hardver i softver. Tokom razgovora, bila je vidno frustrirana činjenicom da nije mogla nikad da dobije konačnu procenu i posvećenost od strane softverskog tima za završetak proizvoda. Zaintrigiran saznanjima, nisam odoleo da povedem sledeću diskusiju.

  • Ja: Da li ste slučajno vaše zahteve poslali u vidu Excel fajla koji je sadržao 1200 kolona sa korisničkim zahtevima?
  • Koleginica: Zapravo jesam, fajl je bio baš kompletan. Dosta vremena sam uložila u njega.
  • Ja: Da li ste zahtevali procenu vremena za razvoj kompletnog proizvoda? Savetovali ste razvojni tim da se baziraju na excel fajlu? Da li ste bili dostupni za njih u slučaju pitanja?
  • Koleginica: Naravno da sam zahtevala procenu, kako bi u suprotnom izračunala datume lansiranja proizvoda? Bila sam dostupna za pitanja jednom nedeljno, jer imam mnogo obaveza. Bilo je potrebno naravno da zakažu sastanak unapred.
  • Ja: Ukoliko analizirate našu diskusiju, naći ćete odgovor na pitanje koje tražite. Ukoliko se držimo tradicionalnog načina komunikacije, verovatno nećete dobiti posvećenost od strane razvojnog tima.

 

Živimo u dobu velike kompleksnosti i brzih promena korisničkih zahteva. Ako pošaljete samo zahteve u pisanoj formi, više vremena ćete potrošiti na pregovaranje i „peglanje“ problema nego na sam razvoj. Ukoliko je vaša odluka da i dalje komunicarate vaše zahteve kao na primeru  sa velikim excel fajlom, bez diskusije i vizualizacije, nikada nećete dobiti posvećenost. Ukoliko želite posvećenost od strane tima, prvo budite dostupni za diskusiju i odgovore na sva pitanja. Pokušajte da isečete vaš proizvod na delove, tako što ćete raditi stvari koje će vam doneti vrednost i potvrditi da su vaše pretpostavke tačne. Vizualizujte vaš proizvod timu i koristite 3C princip. Što se tiče procena u Agilnom razvoju softvera, to je jako zanimljiva tema koju ćemo pokušati da pokrijemo drugom prilikom.

Ukoliko se odlučite da promenite način rada i da imate diskusiju, najveći problem koji možete sebi dodatno napraviti je da pokušate da razgovarate samo sa ljudima koji neće raditi direktno na razvoju proizvoda. Uključite razvojni tim, odgovorite na njihova pitanja i nedoumice. Saslušajte ih. Izgradite razumevanje. Posvećenost neće izostati.

4. Tražite sve i odmah, nemojte postavljati prioritete.

Budimo iskreni, ne postoji srećniji trenutak nego kada imamo Product Owner-a koji zna šta treba da se razvije prvo, a da pri tome donosi učenje i poslovnu vrednost kompaniji. Možda on ili ona znaju, ali njihovi stakeholder-i nemaju jasnu ideju šta bi voleli da vide prvo. Tipična diskusija bi imala sledeći razvoj:

  • Stakeholder: Želimo da naš produkt bude dostupan kupcima u septembru.
  • Agilni evangelista: Nikakav problem, recite mi tačno koji obim treba da isporučimo do septembera?
  • Stakeholder: Želimo da naš produkt bude dostupan u septembru!

Praksa mi je pokazala da ljudi uvek imaju najviše pitanja u vezi tema koje nisu najjasnije i koje nose veliki nivo nesigurnosti. Za to postoji rešenje, isecite vaš produkt na delove. Ukoliko to uradite, desiće se magija. Tim će imati jasne prioritete i fokuse. Neće ih mučiti stvari koje ni vama nisu jasne. Dobićete posvećenost. Agilni razvoj softvera ne radimo zato što nam je sve jasno i poznato. Investirajte vreme u eksperimente za User Story-je koji vam nisu jasni, kako bi naučili o njima. Stavite prioritete na one User Story-je koji vam donose najveću vrednost i za koje imate predstavu kako bi trebalo da funkcionišu.

Između ostalog uvek imamo dovoljno stvari koje treba da napravimo i da razvijemo. Pokušajte da pojedete vašeg slona iz delova. Počnite od onih delova koji će vam doneti najveće uživanje i vrednost.

5. Nemojte da podelite Viziju svog proizvoda.

Za sam kraj bih voleo da vas podsetim šta se dešava ako ne podelite vašu viziju o proizvodu i User Story-jima.

 

“Dobri timovi imaju inspirišuću viziju proizvoda koju slede sa velikom strašću. Loši timovi su plaćenici” (B. Horowitz)

 

 

Slika u poglavlju tri preuzeta sa: https://www.pinterest.com/pin/26810560254951562/

Slika preuzeta sa: https://c1.staticflickr.com/3/2422/3981364314_d4b30cb739_b.jpg

Follow Ognjen Pejović:

Na početku studija odlučio da izbegne IT smer i okrenuo se biznisu, da ne kažemo menadžmentu. Gle čuda, par godina kasnije nalazi se u IT industriji. Spoznao je vrednosti Agila radeći u timu sa preko 15 različitih nacija, dve godine "napolju". Prvi kontakt sa projektnim menadžmentom je imao upravo sa Agilnom metodologijom, tako da nije "zatrovan" tradicionalnim pristupom. Mišljenja je da sve počinje načinom komunikacije i autonomijom koja se daje ljudima prilikom obavljanja zadataka.