Nedavno sam čuo za zbrku vezanu za nekoliko projekata. Radi se o sledećem:
- Želeli su da koriste agilni proces i izabrali Scrum
- Usvojili su skup Scrum postupaka, a možda čak i principe
- Nakon izvesnog vremena napredak je i dalje bio spor jer je kodna osnova bila haotična.
Ono što se dogodilo je to da nisu posvetili dovoljno pažnje unutarnjem kvalitetu svog softvera.Ukoliko napravite tu grešku, uskoro ćete doživeti da vaša produktivnost počne da opada, jer je dodati nove karakteristike mnogo teže nego što bi ste vi to želeli. Preuzeli ste sputavajuće Tehnički Dug i vaš scrum se jedva drži na nogama (Ukoliko ste bili u pravom scrumu*, znaćete koliko je to loše.)
Pomenuo sam Scrum zato što se čini da se, kada se susretnemo sa ovim problemom, Srum pojavljuje posebno često kao imenovani proces koji tim primenjuje. Za mnoge, ova situacije je pogoršana Scrumom iz tog razloga što je Scrum proces koji je usredsređen na tehnike projektnog upravljanja (project management) i namerno izostavlja bilo kakve tehničke postupke, nasuprot (na primer) Ekstremnom Programiranju.
U odbranu Scruma, važno je pomenuti da sama činjenica dao ne uključuje tehničke aktivnosti unutar svog okvira, ne treba nikoga da vodi ka zaključku da ih ne smatra važnim. Svaki put kada bih slušao istaknute Scrummere, oni bi uveki naglašavali da morate posedovati dobre tehničke postupke da bi bili uspešni u Scrum projektu. Oni ne navode koje bi to tehnički postupci trebalo da budu, ali su vam doista potrebni. Na kraju, projekti redovno doživljavaju teškoće zbog lošeg internog kvaliteta, i činjenica da su mnogi od njih Scrum projekti može biti više vezana sa činjenicu da je Scrum toliko popularan u tom trenutku, nego sa nečim što ima veze sa samim Scrumom. Popularnost i Semantičko Širenje imaju tendenciju da se javljaju zajedno.
I šta može da se uradi povodom toga?
Scrum zajednica bi trebala da udvostruči svoje napore da osigura da ljudi razumeju važnost kvalitetnih tehničkih postupaka. Sasvim sigurno, bilo koja vrsta projektne revizije trebala bi da uključi razmatranje vrste tehničkih postupaka koji su prisutni. Ukoliko ste uključeni ili povezani u takav projekt, oštro reagujte ukoliko je tehnička strana zanemarena.
Ukoliko očekujete da uvedete Scrum, vodite računa da posvetite dovoljno pažnje tehničkim postupcima. Često primenjujemo mnoge od onih iz Ekstremnog programiranja i oni sasvim dobro odgovaraju. Stručnjaci se često šale, donekle opravdano, da je Scrum samo XP bez tehničkih postupaka koje ga pokreću. Malicioznost na stranu, XP postupci čine dobru polaznu tačku – i sigurno su mnogo bolje nego ne činiti ništa.
Uvek volim da istaknem da nisu metodologije ono što uspeva ili ne uspeva, već je tim taj koji to čini. Preuzimanje procesa može da poboljša rad tima, ali na kraju je tim taj koji je bitan i snosi odgovornost da primeni ono što za njega funkcioniše. Siguran sam da će mnogi Mlitavi Scrum projekti koji se sprovode narušiti reputaciju Scruma i verovatno širu agilnu reputaciju takođe. Ali obzirom da semantičko širenje vidim kao neminovnost, nisam previše uznemiren. Timovi koji ne uspevaju verovatno neće uspeti bez obzira koju metodologiju (pogrešno) primene, dok će oni koji uspevaju graditi svoje postupke na dobrim idejama i uloga Scrum zajednice je da te ideje nadaleko širi.
Mnogi ljudi vide Lean kao sledeću veliku agilnu stvar. Ali što popularniji bude Lean postajao, sve više će se suočavati sa problemima sa kojima se Scrum sada suočava. To ne čini Lean (ili Scrum) bezvrednim, već nas samo podseća da su pojedinci i interakcije vredniji od procesa i alata.
*scrum: deo ragbi utakmice u kome igrači guraju jedni druge raspoređeni u krugu, sagnutih glava, pokušavajući da dođu do lopte
Prevod Članka Flaccid Scrum. Autor: Martin Fowler
