Ako ste tek skočili na ovu stranicu, možda prije toga ipak da pročitate prethodne dijelove:
Dio I. Ideologija i stav
Agilnost
Pročitajte i o 17 odabranih.
Agilnost nikako nije jedna stvar! Ljudi od iskustva to veoma često spominju u svim prilikama. Ni Sandro nije ispustio da to još jednom ponovi. Agilnost je kombinacija metodologija i tehnika, u zavisnosti od konteksta, koja pomaže timovima i kompanijama da se stalno prilagođavaju prirodi softverskih projekata (ali i bilo kojih drugih gdje se agilnost pokušava implementirati) i da umanji rizike povezane s njima.
Agilne discipline i metodologije Sandro dijeli u dvije grupe i to:
- Procesno orijentisane discipline
- Tehnički orijentisane discipline
Ne može se raditi agilnost. Ili se agilano ili nije.
Agilnost ne rješava ni jedan problem – samo ga otkriva. A otkriva ga tako što se prave što je moguće kraće i povezane veze. Što je veza kraća to se prije može uočiti problem i postaje se fleksibilnije, prilagodljivije za djelovanje. Djelovanje koje može da bude “usput” kako cijeli proces skoro da ne bi ni osjetio da je negdje problema bilo. Važno je također u određenim fazama razvoja imati mnogo veza ka jednoj tački, kao što je saradnja s klijentima (krajnji korisnici, posrednici, menadžeri, kupci, prodavci, …)
Pravila igre su promijenjena (zauvijek)
Od kako je donesen Proglas agilnosti (Agile Manifesto) bio je opšteprihvaćen u cijeloj IT zajednici i to vidimo svuda. Tamo gdje se imalo mnogo dokumenata (čitaj dosadnih strogih procedura i pravila, bilo da su uspostavljena nekim certifikatom – ISO npr, ili pak internim zakonom), velike dizajne pravljene godinama i birokratiju, sada se ima softver koji radi već nakon prve sedmice. Gdje se prije bilo reaktivno na promjene, sada ih se prihvata.
Oznaživanje ljudi da prihvate nova pravila
Sandro ima jedno posebno pod-poglavlje posvećeno samo ovome, ali doduše veoma šturo objašnjeno. Stoga ćemo za ovu priliku staviti vezu ka naša dva druga članaka:
Dobro pisanje kôda je minimalna vještina koja se očekuje od softverskih stručnjaka. Testiranje, analiza, sposobnost razumijevanja posla, dobra komunikacija i ličnosti sklone ka otvorenosti i s velikim interesovanjima (ekstroventne ličnosti) postali su dio vještina koje su danas potrebne softverskim profesionalcima.
Agilni mahmurluk
Mnogi “agilni” projekti danas veoma ustrajno i iterativno proizvode smeće od kôda.
Sastanci su sada postali “stand-up” sastanci, ali se nerijetko održavaju opet u kancelarijama i znaju trajati satima.
Novi alati koji su itekako pomoć kod agilnih metoda (posebno jer su dobro razvijeni za Scrum i Kanban) nekako su odjenom postali novo oruđe i oružje za zloupotrebu. Mnogi menadžeri koji su “višak” u novoj strukturi uspjeli su da nađu svoje mjesto pod ovim suncem.
Menadžeri projekata (Project Managers) su svi redom pokupili certifikate za Skram majstore (Scrum Master).
Nestalo je pregrada u kancelarijama kakve smo viđali u američkim filmovima, a koji su zaista bili tu u ovom ili onom obliku. Pa čak i stvarni zidovi, podjele između kancelarija. Pojavile su se bijele table svuda okolo s mnogo samoljepivih papirića (post-it). Što su papići bili raznobojniji to su timovima davali veći osjećaj da su postali agilni.
Međutim, nakon godina i godina prilagođavanja i promjena firme su uviđale da još uvijek proizvode nestabilne softvere, nesigurne. Klijenti se žale kao i prije, a možda i više.
Mnoge firme u toku tranzicije u agilne timove/fime su jednostavno zaboravile da je cilj sam softver koji proizvode, a ne metodologija po kojoj rade.
Čak i razni treneri koji su koštali basnoslovne sume, a koji su bili unajmljeni da firmu pretvore u agilnu stvari su činili na pogrešan način. Oni su firmu i procese pokušali da pretvore u agilne, ali ne i sam tehnički proces do stvaranja softvera. Čak još i više. O tehničkim procesima, vještinama, znanjima gotovo niko nije ni govorio tokom tranzicije. Ili jednostavno rečeno, mnogi treneri firmama su pričali Toyota Dream.
Tojotina auta nisu prodavana zato što im je način proizvodnje promijenjen! Ne, nikada! Tojotina auta su prodavana samo i jedino zato što su bila kvalitetna, pouzdana, s veoma kvalitetnim i pouzdanim servisima, podrškom i uz pristupačnu cijenu.
Daleko je lakše prodati procese višem rukovodstvu nego ih uvjeriti u važnost tehničke izvrsnosti i sve napore koji su potrebni da bi se to postiglo. Stariji menadžeri zaista dobro razumiju procese, ali ne shvataju koristi od programera koji imaju veću ulogu od pisanja kôda. Takođe ne razumiju važnost obraćanja pažnje na kvalitet kôda koji proizvode programeri. Njih samo zanima je li radi ili ne radi.
Druga strana medalje
Ima trenera agilnih procesa izvrsnih. Onih kojih doista razumiju važnost tehničke strane. I kada takvi predlože da se počne raditi u Ekstremnom programiranju (Extreme Programming – XP) modu (najčešće se to misli dva programera za jednim stolom), menadžeri se počnu buniti, jer oni to vide kao rasipanje para. Ako uz to programeri posvjećuju više pažnje testiranju, menadžeri pogotovo ne razumijeu taj dio i ljute se. Vele, pa zašto imamo firme u Aziji za to, nego da testiraju?
Ima i mnogo programera koji uglavnom zbog vlastite sujete, osjećaja stida (jer možda nisu baš tako vješti programeri kako se prodaju) i slično ne žele da prihvate nove metode, pogotovo ne XP.
Naivan pristup softverskim projektima
Veli Sandro da je za sve godine iskustva koje ima vidio jako mnogo naivnih pristupa softverskim projektima. Nemali broj kompanija je smatrao (ili još uvijek smatra) da je neophodno prvo uposliti stručnjake za pisanje poslovnih zahtjeva, zatim razne tehničke vođe (koji uglavnom ne kôdiraju), crtanje raznih dijagrama i pisanja dokumenata. Smatrali su (ili nedaj Bože smatraju još uvijek), ako su ovi uradili dobro svoj posao (a vjeruju da jesu), onda mogu da zaposla nekoliko jefitnih programera da im to sve završe. Čak se išlo dotle da su firme prosljeđivale proces regrutacije novih ljudi trećim firmama (tzv. lovcima na glave). Posao programera se smatrao (i nažalost još uvijek smatra u mnogim firmama širom svijeta) kao nešto što se podrazumijeva. Oni će to začaš – ne znam šta se bune, imaju svu dokumentaciju.
Ali, nije sve tako loše
Imajući dobar proces, ali lošu sposobnost isporuke, neće dovesti do uspješnog projekta. Imati nevjerojatne programere koji mogu proizvesti visokokvalitetni kôd, ali imati proces koji im ne omogućava dobar rad, također ne vodi ka uspješnim projektima.
Važno je identifikovati gdje su problemi što prije i djelovati na njih. Nikad nije kasno da se stvari učine boljim – jednostavno postaje mnogo bolnije kada se odgodi.
Agilni pristup naspram Softverskog zanatstva
Mnogi misle da je Softversko zanatstvo “došlo” da zamijeni agilni pristup. No, to nije tačno. Oni se uopšte ne isključuju, nego nadopunjuju.
Agilnost je tu da promijeni procedure i način razmišljanja od početka do kraja u proizvodnji softvera. Da smanji nepotrebnu birokratiju, olakša ljudima (inžinjerima prvenstveno) lakše izražavanje i slobodu donošenja odluka.
Softversko zanatstvo govori o profesionalizmu u razvoju softvera. Softverskog zanatstvo pomaže i programerima i kompanijama da izvrše stvar na pravi način.
Zaključak
Da bi kompanije ostale konkuretne (čitaj, da bi preživjele) one moraju da isporučuju softver brže (mnogo brže nego ranije), ali i softver bolje kvalitete. Mnoge kompanije imaju tendenciju da povećaju pažnju na procese agilnosti, ali potpuno zanemarujući tehničku praksu.
Za potpunu transformaciju u agilni pristup, potrebni su i profesionalni programeri koji savladavaju tehničke prakse, tehnologije i alate. Potrebni su programeri sposobni da stalno isporučuju kvalitetan softver. Potrebni su programeri koji mogu isporučiti softver koji je u potpunosti testiran i koji se lahko koristi. Za potpunu agilnu transformaciju kompanije trebaju (ili moraju) prihvatiti softversko zanatstvo.
6Hits: 91
