Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Develop Mentor - Agile

Razjašnjeni Agile (v.2)

Оktobar 2009 - Programerske novosti:Razjašnjeni Agile (v.2)

Kratko objašnjenje razvoja softvera Agile za menadžere


autor: Alen Keli- www.allankelly.net

U okviru razvoja softverske aplikacije, zajednica Agile napravila je malu zbrku. Termin postoji već oko devet godina, a ideja koju predstavlja čak malo duže. Međutim, mnoge IT menadžere i direktore i dalje zbunjuje pitanje šta je zapravo Agile. Ovaj rad će pokušati da razjasni te zabune.

Poslovna vrednost

Rasprava o tome da li Agile zaista donosi korist uveliko je okončana. Iako postoje projekti kojima Agile pristup ne koristi mnogo, ipak većini koristi. Gartner grupa je 2006. izjavila:

"Činjenica je da se agile značajno razlikuje od Waterfall projekta. Takođe je činjenica da agile metod pruža značajne prednosti odgovarajućim poslovnim procedurama. Razdvojiti te činjenice od fikcije koja okružuje razvoj agilea od ogromnog je značaja kako bi organizacija za razvoj aplikacija ostvarila te prednosti”.

Organizacije poput Instituta za projektni menadžment mire svoj pristup s Agile pristupom, dok je Institut Karnegi Melon za softverski inženjering krajem prošle godine objavio izveštaj koji pokazuje da su CMMI i Agile kompatibilni (Glazer et al., 2008). (Glazer et al., 2008).

U odnosu na prethodne tehnike - tzv. Waterfall ili standardne - agile razvojne tehnike pružaju brojne poslovne prednosti:
  • Bolja reakcija na potrebe kupaca jer su Agile metodi programirani tako da se prilagode promenljivim zahtevima.
  • Veći povraćaj po investiciji jer projekti isporučuju radni softver ranije u razvojnom ciklusu.
  • Smanjen rizik jer česte isporuke softvera amortizuju i otkrivaju rizike prisiljavajući ih da se smanje.
  • Bolji kvalitet jer visok kvalitet zapravo podupire Agile procese.
  • Bolje vladanje projektom jer je napredak na projektu vidljiviji. Model povećane isporuke omogućava neposredan uvid u projekat. Ako se za tim javi potreba, projekat se može ranije prekinuti i ipak isporučiti vredan softver.
  • Veća produktivnost. Agile metodi stvaraju visoko stručne timove. Yahoo izveštaj o usvojenosti Agilea ( Benefild, 2008) navodi da su se timovi poboljšali između 35% i 400%.

Standardni softverski projekti težili su da isporuče softver na kraju projekta u jedinstvenom izdanju ili po metodi velikog praska.  To je podstaklo profil novčanog toka prikazan na slici 1. U takvim projektima, troškovi nastaju tokom životnog veka projekta, a prednosti se realizuju tek na kraju projekta. I to je čak idealizovano, jer takve projekte obično prati faza “rešavanja programske greške”. Aplikacije se objavljuju korisnicima koji prijavljuju greške koje se zatim moraju ispraviti.

Nasuprot tome, slika 2 prikazuje sličan Agile projekat u kojem isporuka počinje dosta ranije. Iako prvobitnim izdanjima nedostaje funkcionalnost, ona sadrže dovoljno za korišćenje, pa time i prednosti počinju da se koriste daleko ranije.



Novi softver se izdaje redovno, povećavajući svoje prednosti iz meseca u mesec, sve dok se ne dostigne jednaki nivo prednosti kao u prethodnom dijagramu. U ovom slučaju broj dodatnih koristi teče. Uz upotrebu softvera, više je informacija na osnovu kojih se donose odluke o tome kojim funkcijama dati prednost pri implementaciji. To zauzvrat stvara veći sklad između poslovne potrebe i isporučenih funkcija.

Drugo, s obzirom na to da korisnici aktivno koriste softver, problemi se uviđaju mnogo ranije i mogu se rešiti pre završetka projekta. Vođe timova tada mogu da odluče da li će nove funkcije ili rešeni problemi pružiti veću poslovnu vrednost.

Konačno, IT upravljanje poboljšano je jer menadžeri imaju više stratešku kontrolu nad projektima. Ako bude neophodno zatvoriti projekat pre planiranog datuma završetka, prednosti će se i dalje gomilati jer je zaista nešto isporučeno. U standardnom projektu, rano zatvaranje projekta obično ostavlja realizovan tek deo, pun grešaka, softver koji nikome ne koristi (ipak, određeni sistemi u upravljanju projektima koriste Waterfall pristup i biće im potrebno ažuriranje ako se žele postići kompletne Agile prednosti.)


Slika 1 i slika 2 su opšti primeri, oba daju slične pretpostavke o troškovima
(õ0,000 per month) i prednostima (konačna korist od £ 2m).  Uz diskontnu stopu od 5% godišnje, to doprinosi neto sadašnjoj vrednosti od ü/span>1.318m za Waterfall projekat prikazan na slici 1 i nešto višu neto sadašnju vrednost od ü/span>1.354m za Agile projekat na slici 2.

Dodatu vrednost jasnije prikazuje interna stopa povraćaja po obračunu. Ovde Waterfall slika 1 ima internu stopu povraćaja od 20% ali s obzirom da prednosti počinju ranije da se koriste, Agile slika 2 ima internu stopu povraćaja od 100%.

Ovi obračuni ne prikazuju poboljšanje produktivnosti ili viši kvalitet koji će se kasnije pojaviti. Time prava vrednost postaje još veća..

Primenljivost

Agile metodi imaju široku primenu. Mnoge organizacije koje se bave proizvodnjom softvera mogu da usvoje Agile metode. Bolje je pitati kada je standardni Waterall program primenljiv?

Waterfall program zavisi od određivanja zahteva u ranijoj fazi ciklusa. Kada se odrede zahtevi, pristupa se analizi. Kada se analize završe nastavlja se sa programiranjem i ono se završava pre kodiranja. Kodiranje je obično najduža faza za kojom sledi testiranje. Na taj način odlaganje određivanja zahteva uzrokuje odlaganje svih faza projekta, dok izmene u zahtevima imaju značajan domino efekat.

Nasuprot tome, Agile metodi očekuju promenu i nastanak zahteva tokom projekta. Oni se tim pojavama prilagođavaju tokom preklapanja faza usvajanjem tačno na vreme pristupa analizama i programiranju.

(Zapravo, dok mnoge organizacije zahtevaju praćenje waterfall procesa, određivanje zahteva je izuzetno teško. Promene nastaju tokom celog perioda razvoja. Jedna od teškoća sa kojima se timovi susreću je i usklađivanje modela sa trenutnim dešavanjima.)

U vreme nastanka ovog rada, Agile metode su najviše koristile medijske kuće, Web 2.0 kompanije i nezavisni prodavci softvera. Agile metodi dobro funkcionišu i u bankama, telefonskim kompanijama i u drugim industrijama.

Činjenica da su mediji i Web 2.0 kompanije usvojile Agile, odražava njihov postmilenijumski interes za razvoj softvera. Pre 2000. medijske kuće nisu imale velikih potreba za razvojem složenih aplikacija kao podrške svog poslovanja. Razvoj takvih aplikacija, koji su preduzele medijske kuće i Web 2.0 kompanije, počeo je da se dešava otprilike u isto vreme kao i pojava Agile metoda.  S obzirom da nisu postojali nasleđeni razvojni procesi, bilo je prirodno da pomenute organizacije usvoje Agile.

Nedostatak nasleđenog koda i prakse učinio je da usvajanje Agilea bude lako. Za organizacije koje već imaju utvrđene timove za razvoj aplikacija, usvajanje Agilea mora da se posmatra kao izmena programa.

Najveći korisnici Agile metoda su IBM, BBC, Sky TV (evropska verzija Fox-a u okviru novog međunarodnog portfolia), Nokia i Yahoo. Druge kompanije koje imaju određene oblike Agile softvera jesu Google, Hewlett-Packard i Schlumberger. Mnoge banke eksperimentišu sa Agile metodama, a najmanje jedna engleska investiciona banka ide ka usvajanju ovog široko rasprostranjenog softvera.

Mnoge prakse iz Agile metoda postojale su i u zajednici nezavisnih prodavaca pre pojave Agilea, XP-a , Sacruma ili drugih metoda. Za razliku od kompanija koje razvijaju softver kao podršku svom stvarnom poslovanju, za nezavisne prodavce softvera je pitanje opstanka njihova mogućnost stvaranja softverskih proizvoda. Zato su oni već ranije koristili mnoge od takvih najboljih praksi koje su kasnije postale Agile.

Ipak, postoje mnogi prodavci koji mogu imati koristi od Agile metoda i mnogo njih koji mogu poboljšati svoj već sada odličan posao dodatnim tehnikama.

Višestrukost metoda i termina

Kao i druge IT grane, i pokret Agile ima obilje termina, metodologija i skraćenica: XP, Scrum, DSDM, Crystal, FDD itd. (duža lista se nalazi u rečniku u nastavku).

Slika 3 prikazuje kako se metodi i termini uklapaju. U svakoj metodologiji postoje određene prakse i rutine, od kojih su neke više, a neke manje preporučljive. Osim toga, svaka metodologija donosi svoju filozofiju, koncepte i vrednosti.

Od svih Agile metoda možda je najviše preporučljivo prvo izdanje Extreme Programming-a, XP skraćeno (Beck, 2000). Iako je Bek podvukao određene principe i vrednosti, originalni opis je bio visoko preporučen. U drugom izdanju (Beck i Andres, 2004) preporučeni element je bio smanjen, sa većom važnošću vrednosti i principa u odnosu na prakse.

Ipak, XP je tek jedan od nekoliko Agile metodologija. Dok se Crystal Clear manje preporučuje, i dalje je specifičan, kao i Scrum i DSDM.


Agile u celosti ujedno je i “kišobran” termin koji obuhvata sve te metode - koje su se prvobitno nazivale metodama lake kategorije - i okvir s alatkama. Agile okvir s alatkama sadrži mnoge preporučene prakse, a korisnik sam bira koje alatke će koristiti. Posledično, koncepti i vrednosti postaju važniji.

Lean, a posebno razvoj softvera Lean može se smatrati drugom Agile metodologijom sličnom XP-i ili Scrumu. Ipak, Lean je više brine o tome kako kompanije i timovi napreduju i usvajaju. Iako ima specifične prakse - kao što je vrednosno mapiranje toka - one se posmatraju zajedno sa poboljšanjem procesa. Lean nije toliko metodologija rada koliko je metod poboljšanja radne prakse.

Iz te perspektive, Agile je primena Lean razmišljanja. Mnoge ideje iz Lean proizvodnje, kao što su proizvodnja just in time i etos kvalitet je besplatan podupiru Agile pristup.

Originalni opis Leana stigao je iz proizvodne linije za motore (Womack et al., 1991), što bi moglo izgledati neodgovarajuće za apstraktniji rad u okviru softverskog inženjeringa. Na drugom mestu prikazano je kako je Toyota - i drugi - primenila Lean principe na dizajn i razvoj proizvoda (Kennedy, 2003, Cusumano i Nobeoka, 1998) dok su Meri i Tom Popendajk primenili te ideje direktno na softverski razvoj (Poppendieck and Poppendieck, 2003, 2007).

Konačno, sve ove tehnike bazirane su na idejama Organizacionog učenja i Organizacije učenja(Senge, 1990, de Geus, 1997, Argyris and Sch������1996, Kelly, 2008).  Organizaciono učenje može biti donekle akademsko pitanje, ono objašnjava kako te tehnike funkcionišu i pružaju uvid u upravljanje procesima.

Agile testovi

S obzirom da ne postoji jedinstveni kod za Agile, i s obzirom da postoji mnogo varijacija samog Agilea, sve je teže spoznati da li određeni tim praktikuje Agile ili ne. Jedan od mogućih pristupa je jednostavno pogledati prakse opisane Agile metodama i ispitati da li ih tim koristi ili ne. 

Ipak, ovaj pristup radije meri ono što je urađeno nego same rezultate, pa je time manje zadovoljavajući. Zaista je verovatno da se nekoliko Agile praksi može pronaći u svakom programerskom timu.

Savetnik Bas Vud izmislio je jednostavan test za Nokia timove kako bi procenio njihovo usvajanje. Ti testovi postavljaju
dva pitanja, svako sa nekoliko uslova:

1.    Dа li radite iterativni razvoj?
  • Vremenski ograničena ponavljanja na manje od 4 nedelje
  • Testiranje funkcija i rad na kraju svakog ponavljanja
  • Ponavljanje počinje pre završetka specifikacije

2.    Dа li radite Scrum?
  • Poznajete vlasnika proizvoda
  • Postoje zaostaci nedovršenog proizvoda: poređani su prema poslovnim vrednostima, sa procenama koje izvršavaju timovi
  • Timovi prave dijagrame spaljivanja i poznaju brzinu
  • Nijedan vođa projekta (niti iko drugi) ne prekida rad tima
Autor predlaže uopšteniji test: 

Ako tim može odgovoriti sa “da” na sledeća pitanja, može se smatrati da je taj tim Agile:
  • Da li tim odgovara na potrebe kupca? Da li isporučuje poslovnu vrednost?
  • Da li tim konstantno napreduje i uči? Naročito: tim bi trebalo da menja način rada kao rezultat sopstvenog prekovremenog učenja.
  • Kada se agent promene ֠ - npr. vođa projekta, savetnik - skloni, da li tim nastavlja da bude Agile? Ili se vraća na prethodne vrednosti?
Krajnje pitanje nije da li je tim Agile, već da li tim služi poslu ?  Suviše često se dešava da IT blokira sposobnost i promenu organizacije.

Kako Agile funkcioniše

Svi Agile metodi - XP, Scrum, Crystal itd. funkcionišu tako što smanjuju razvojni ciklus i što ga često ponavljaju. Svaki ciklus naziva se ponavljanjem (iteracijom) ili sprintom i traje između jedne i četiri nedelje. Novi softver se objavljuje na kraju jedne iteracije ili posle nekoliko. 

Oni zapravo skidaju elementarne jedinice problema veličine bajta pre nego što se njima u celosti bave. Rezultat je serija mini projekata u brzom nasleđivanju. Kako bi to postigao, tim mora da smanji i vreme podešavanja za ciklus i da skrati završnu fazu. 

Vreme podešavanja se smanjuje uz blisko učešće kupca - u čemu kupac može biti stvarni kupac, ovlašćeni kupac, poslovni analitičar ili menadžer proizvoda - i strogu prioritetizaciju. 

U svakoj iteraciji tim je usko fokusiran na nekoliko visoko prioritetnih stvari. One će se ispuniti u iteraciji i time omogućiti postavku novih prioriteta za sledeću iteraciju.

Većina softverskih proizvoda završava se test-popravka-test ciklusom čija dužina nije precizno određena. Da bi se to izbeglo, i time smanjila završna faza, Agile metodi usvajaju pristup kvalitet je besplatan i uvode brojne tehnike za povećanje kvaliteta kroz razvojni ciklus. Tehnike poput razvoja vođenog testiranjem (TDD), programiranje u paru, automatsko prihvatanje testova i neprestana integracija pomažu u očuvanju kvaliteta koda mnogo više nego u tradicionalnim projektima.

Neto rezultat je uklanjanje neodređenog test-popravka-test ciklusa. Kada se završe, pravi projekti su uvek u stanju pogodnom za objavljivanje. To omogućava mini projektima da završe na vreme sa isporukom.

Dodatne tehnike koriste se kako bi omogućile da se projekat izbori sa sistemskom arhitekturom, održivošću i dugoročnim planiranjem.
 
Agile mitovi

Agile prate brojni mitovi. Neki imaju programersko Agile poreklo, dok drugi pogrešno tumače nedostatak tradicionalnih procesa i artefakata kao nedostatak strogosti.

Jedna od kritika koje su se nepravedno nadnele nad Agile jeste i ta da je haotičan. Ustvari, Agile je visoko disciplinovan proces: zahteva pažnju o tehničkom kvalitetu, redovnu komunikaciju i planiranje.

Nažalost, pojedini haotični timovi nalaze izgovor za svoje ponašanje u tvrdnji da su “Agile”. Programeri koji odbijaju da pokažu napredak, prikažu radni kod, napišu jedinične testove ili poslušaju šta kupac želi, nisu Agile. Takvi timovi koriste neznanje drugih o Agileu kako bi našli izgovor za svoj neprofesionalizam.

Drugi mit je da je Agile anti-dokumentacija. Agile projekti proizvode onoliko mnogo ili malo dokumentacije koliko se od njih traži. Ipak, Agile timovi ne proizvode dokumentaciju radi dokumentacije.

Ostali su ispitivali primenljivost Agilea na sigurnosne kritičke sisteme. I to je mit. Na neki način, Agile je pogodniji za sigurnosne kritičke aplikacije zbog konstantnog naglaska na radni kod. U zdravstvu, farmaciji, ugrađeni i na drugim mestima, postoje Agile timovi koji rade na sigurnosnim kritičkim aplikacijama.

Slično tome, netačno je da Agile zabranjuje distribuirane timove. Kao i drugi metodi, Agile daje značajno prvenstvo zajednički lociranim timovima, ali postoje i rasuti Agile timovi i oni odlično isporučuju.

Još jedan mit je da je Agile primenljiv samo onda kada su programeri veoma iskusni. Projekti sa veoma iskusnim, stručnim programerima imaju očiglednu prednost, ali Agile metodi su dokazali da mogu fino da rade i sa prosečnim osobljem.

Slično tome, tvrdilo se da je Agile pogodan jedino za novi razvoj, da nije pogodan za postojeće nasleđene aplikacije. Iako je tačno da nasleđene aplikacije predstavljaju sopstvene izazove, nije tačno da se Agile ne može upotrebiti za takav rad. Zaista, osnovni Agile pristup vuče korene iz održavanja postojećih aplikacija.

Šta nije Agile

Nedavni uspeh Agilea rezultirao je brojnim dobavljačima koji su tvrdili da su njihovi proizvodi, alatke i usluge Agile. To još više otežava shvatanje šta je zapravo Agile, a šta nije.
 
  • SOA (servisno orijentisana arhitektura), MDA (arhitektura vođena modelima) i virtuelizacija nisu sami po sebi Agile. Agile projekat može koristiti i čak isporučiti SOA, MDA ili virtuelizaciju ali korišćenje neke (ili svih) od tih tehnika ne čine neki projekat Agileom.
  • Web 2.0, Seas, (softver kao usluga), AJAX (asinhroni JavaScript i XML), REST, Mešavine: ponovo, Agile projekat može koristiti takve tehnologije, i ne mora. Njihovo prisustvo ne čini jedan projekat Agileom, niti ga sprečava da bude Agile.
  • Prvo testiranje ili razvoj vođen testiranjem jeste ključna Agile praksa ali sama nije dovoljna kako bi projekat bio Agile.
  • Programiranje u paru: Extreme Programming (XP) preporučuje da programeri rade u paru, poput pilota u avionima. Ta ideja ima veoma glasne navijače, ali još glasnije protivnike. Nažalost, rasprava o XP, ili Agileu uopšte, često se zaglavi u uparivanju.  Ako je tim spreman da isproba programiranje u paru - odlično, ako nije, prihvatite to i nastavite dalje.
Neuspesi

Agile nije garancija uspeha. Svi IT projekti, naročito razvoj aplikacija, iziskuju rizik. Ako je projekat oslobođen rizika, nije verovatno da će pružiti značajne koristi ili konkurentne prednosti. Agile može obezbediti projekat tako što će smanjiti mogućnost rizika, i time povećati povraćaj. Kompanije mogu prihvatiti tu prednost ili odlučiti da povećaju rizik u drugim oblastima.

Ipak, postoje brojni slučajevi u kojima Agile projekti konstantno doživljavaju neuspeh, što bi trebalo ispitati:
  Wagile: tim koji nastavlja da prati osnovni Waterfall projekat ali koristi Agile jezik i dodaje nekoliko artefakata ili praksi. Na primer, tim može predstaviti grafikon spaljivanja zajedno sa Gantovim grafikonom.
 
  ScrumBut opisuje tim koji tvrdi da prati Scrum, ali mu nedostaju različite prakse; na primer, “Mi radimo Scrum, ali nemamo vlasnika projekta”, ili “Mi radimo Scrum, ali menadžer proizvoda dodeljuje zadatke”. Takvi timovi normalno imaju dugačku “ali” listu i pokazuju malo napretka u njihovom uklanjanju.
 
  Hitting The Scrum Wall: Najpopularniji Agile metod u vreme pisanja ovog rada jeste Scrum, koji je zapravo tehnika upravljanja projektom. Acrum se normalno koristi sa mnogim drugim Agile tehnikama, obično User Stories tehnikom i tehničkim delovima iz XP-a (TDD, prerađivanje, konstantna integracija itd).

Timovi koji usvoje Scrum upravljanje projektom u početku vide poboljšanje produktivnosti i zadovoljstva kupaca. Ipak, bez tehničkih praksi, kvalitet je loš i tim udara o zid.  Jaz u kvalitetu onemogućava dugoročno održavanje tempa.
 
  Fake Agile: to se dešava kada tim sebe proglasi Agileom i krivi druge za svoj neuspeh u pravilnoj interakciji sa grupom. Takva grupa obično sprečava pisanje dokumentacije, slušanje poslovnih analitičara, menadžera proizvoda i drugih kupaca i diktira sopstveni raspored isporučivanja. U međuvremenu tim ne poboljšava kvalitet, ne usvaja razvoj na osnovu testiranja niti bilo koju drugu praksu koja im se ne sviđa.
 
  Potemkin Agile: nastaje kada tim usvoji i pravilno primeni Agile metod ali ne isporuči poslovnu vrednost. To je oblik odlaganja cilja, u kojem se tim radije drži procesa nego što isporučuje poslovnu vrednost kao kriterijum uspeha.
 
  Korisničko (poslovnog analitičara, menadžera proizvoda, vlasnika proizvoda) preopterećenje: na Agile projektu koji dobro funkcioniše, kupac ili ovlašćeni kupac pozvan je da uradi mnogo toga. On moraju da odluče o zahtevima, da postavi prioritete, da izvidi ispred projekta, poravna strategiju, radi sa programerima, testerima i menadžerima, a može imati i svoj redovni posao uz to. U najranijim XP projektima (“C3”), prvi poslovni analitičar skoro je doživeo nervni slom. Takvo preopterećenje je znak da projekat dobro funkcioniše, ali je takođe i ograničenje.
 
  Povlačenje: menadžment dovodi savetnike i ostale stručnjake koji će tim preokrenuti u Agile. Kada savetnici puste određene timove da se vrate svojim ranijim načinima rada. Savetnici mogu biti od velike pomoći u uvođenju Agilea, ali moraju izgraditi sposobnost razvojnog tima da nastavi da uči i da se razvija kada savetnici odu.
 
  Neuspešan napredak: Kako bi se što više povećale prednosti softverskog Agile razvoja, ljudi, procesi i organizacije koje rade sa Agile timom moraju da shvate Agile i da prilagode svoja očekivanja i tehnike rada. Agile nije slučajna tehnologija koja se može trampiti za drugi neuspšeni metod. Za izolovane Agile timove biće teško da budu u potpunosti Agile. Kada druge grupe usvoje prednosti Agilea, one se mogu proširiti i van softverskog razvoja.
 
  Еksplozivne kartice dešava se kada timovi ne shvataju u potpunosti tehnologiju sa kojom rade - bilo u rešenju ili u problemu. Rezultat je da mali radni paketi postaju veliki zadaci po sopstvenom pravu.
 
  Hiper promenljivi zahtevi: Osim Kanbana, skoro svi Agile metodi, naročito Scrum, drže ciljeve iteracije fiksnim nekoliko nedelja. Većina poslovnih sistema trebalo bi da je u stanju da održi ciljeve u tako kratkom periodu.

Ako se ispostavi da je nemoguće držati ciljeve i zahteve fiksnim čak i samo jednu nedelju, tada nešto nije u redu. U nekoliko slučajeva posao se istinski menja izuzetno brzo. Kada je to slučaj, timovima je bolje da koriste Kanban stil upravljanja nego Scrum pristup.

Hiper promene u ciljevima i zahtevima češće su znak da nešto nije u redu izvan tima. Moguće je da samoj organizaciji nedostaju strategije i ciljevi, ili vlasnik proizvoda ne ispunjava pravilno svoju ulogu.
 
  Krhko nije Agile: Neke od Agile tehnika, kao što je TDD, kada se loše primene, uz nedostatak razumevanja, mogu prikazati kratkoročne koristi i napraviti dugoročne probleme.
Neki od ovih neuspešnih modaliteta su jedinstveni za Agile, oni ponavljaju neuspešne modalitete za sve IT softverske razvojne projekte. Ovo ipak nije sveobuhvatna lista načina na koje Agile, ili druge razvojne aplikacije, može biti neuspešan.

Odakle početi

Usvajanje Agilea je više od jednostavnog proglašavanja tima za Agile tim. Ni menadžeri ni programeri ne mogu svojom odlukom nametnuti Agile. Usvajanje je proces učenja.

Idealno, usvajanje Agilea treba da bude obuhvatni pokret: menadžment bi trebalo da pruži deduktivnu podršku usvajanju putem treniranja, savetovanja i volje za sopstvenom promenom. Timovi za razvoj softvera trebalo bi da pokrenu induktivnu inicijativu kako bi promenili sopstvene prakse i metode rada. Obe strane moraju da se uključe u zajedničko učenje.

Menadžer koji želi da vide kako njihovi timovi usvajaju Agile, moraju da urade više od čistog propovedanja tehnika. Moraju da pruže timovima alatke i izvore koje moraju da promene. Takođe moraju i sami da se usko uključe u inicijativu za promene tako što će slušati programere.

Nije neohodno unapred odabrati koja metoda će se usvojiti. Svaka organizacija ima sopstvene potrebe, probleme i zahteve. Nijedna komercijalna metodologija neće tačno navesti potrebe određene kompanije, umesto toga timovi treba da stvore sopstvene metode iz dostupnih tehnika koje će uskladiti sa problemima. Ovaj pristup ima dodatnu korist u tome što će posejati seme kulture učenja neophodne za dugoročno poboljšanje.

Organizacija može, i to i radi, da usvoji Agile metode bez eksterne pomoći, mada je to spor i rizičan proces. Za brže usvajanje preporučuje se upotreba usluga Agile trenera koji će usmeravati proces usvajanja i voditi tim. Trening koji se odnosi na Agile metode i tehnički trening - naročito TDD - ključni su za ugrađivanje opšteg razumevanja pristupa i potrebnih veština.

Sve u svemu, programeri oduševljeno usvajaju nove metode i isprobavaju Agile. Menadžment mora da radi sa entuzijazmom, a ne da nameće deduktivne izmene procesa.
 
Аko želite da saznate više o razvoju softvera Agile, o tome kako vaša organizacija može imati koristi ako postane više Agile i kako da postanete Agile, kontaktirajte s autorom, Alenom Kelijem na +44 773 310 7131 ili allan@allankelly.net.

О аutoru
Alen je viši Agile savetnik u DevelopMentor-u u kojem pomaže kompanijama da pređu na softverski Agile razvoj pružajući treninge i savete kako bi podržao usvajanje Agilea i Leana i promene. On je autor DevelopMentorovog kursa “Temelji softverskog Agile razvoja uz upotrebu Scruma”.
 
Kao poznatog autora i govornika, Alenovu knjigu, Promene u softverskom razvoju: naučite kako da postanete Agile  objavili su Džon Vajli i sinovi u januaru 2008.

Alen je diplomirao kombinovane nauke (računarstvo) na Univerzitetu u Lesteru, a magistrirao na Poslovnoj školi Univerziteta u Notingemu, gde je nagrađen kao Najbolji ukupni student   svoje magistarske klase. Profesionalno, on je PRINCE 2 stručni menadžer proizvoda i završio je kompletan trening za menadžera proizvoda. Živi u Londonu.

Proverite našu Agile biografiju ovde.

Rečnik Agile pojmova
AD
Razvoj aplikacija
ASD
razvoj softvera Agile
Test automatskog prihvatanja
Testovi koje piše vlasnik proizvoda, možda sa testerom, a koji se mogu automatski pokrenuti iz softvera i sistema. Oni čine deo programske specifikacije.
Plavo-belo-crveno
Primer autorovog Agile sistema koji kombinuje elemente Scruma sa XP-om (Kelly, 2007, Kelly, 2008).
EVO entuzijasti tvrde da pokriva razvojne aspekte koje ne pokrivaju Agile metodi i da se može uspešno kombinovati sa Scrumom i XP-om.
FDD
Dizajn vođen funkcijom, metodologija Džefa de Luke i Petera Koada.
Iteracija
Kratak period tokom kojeg se vrši rad. Iteracije su vremenski ograničene time što imaju određen start i kraj, a sve iteracije su iste dužine. Rad se tada svodi na veličinu koja odgovara ograničenju iteracije.
Kanban
Najnoviji Agile metod: uveo ga je Dejvid Andersen oko 2007. Kanban neposrednije prikazuje ideje Leana. Što je neobično za Agile metod, najnapredniji Kanban timovi ne koriste vremenski ograničene iteracije niti daju procene (termin Kanban ima specifično značenje u Leanu i koristi se da imenuje metod koji izaziva blagu zabunu.)
Lean
Proisteklo iz Toyota proizvodnog sistema kao što je opisano u tekstu “Mašina koja je promenila svet”, autora Džonsa i Roo.
Razvoj softvera Lean
Primena Lean proizvodnje i razvoja proizvoda na polju softvera. Najbliže se povezuje sa Meri i Tomom Popendajk.
Organizaciono učenje
Grana teorije o menadžmentu koja se bavi razumevanjem načina na koji organizacija uči i menja se, i načina na koji se to može iskoristiti za informisanje o operacijama i strategijama. Najbliže povezano sa piscima kao što su Peter Senž, Ari de Gru i Kris Arigis.
Vlasnik proizvoda
Član tima odgovoran za određivanje onoga što je potrebno uraditi, kao i za određivanje prioriteta. Uloga se obično poverava poslovnom analitičaru ili menadžeru proizvoda, u korporativnim IT odeljenjima, kao i kod nezavisnih prodavaca.
Prerađivanje
Tehnička praksa koju koristi Agile tim da bi poboljšao dizajn softvera u toku rada na njemu.
Scrum
Metodologija koju su razvili Ken Švaber i Džef Saterlend. Scrum ne znači ništa, odnosi se na ragbi igru.
Scrum savez potvrđuje Scrum trening u oblastima kao što su Scrum Master i Scrum vlasnik proizvoda.
Scrum se više fokusira na upravljanje projektom, dok se XP više bavi razvojnim praksama. To upotrebu oba elementa čini prirodnom, kao i kod sistema plavo-belo-crveno (vidi gore).
Scrum Master
Scrum određuje novu ulogu Scrum Mastera koja je napravljena da pomogne timu da prevaziđe prepreke i da poboljša izvođenje. Scrum Master je delom Agile trener. Iako mnoge organizacije vide Scrum Master kao menadžera proizvoda, to nije način na koji je ta uloga određena. Scrum Master i menadžer proizvoda postavljeni jedan uz drugog mogu sami stvoriti tenziju.
Sprint
U Scrumu: iteracija ili skup nekoliko iteracija koje čine jedno izdanje.
TDD - Dizajn vođen testiranjem
Takođe poznato i kao: Razvoj prethodnog testiranja, Dizajn vođen primerima
Dizajn vođen testiranjem - u početku dao XP-a, sada tehnika koja ima široku primenu po sopstvenom pravu.
XP
Extreme Programming-metodologija koju su razvili Kent Bek (Beck, 2000) i Ron Džefris.  XP je prvobitno bila vodeća Agile metodologija. Tu poziciju sada zauzima Scrum.
 

Literatura
ARGYRIS, C. & SCH׎, D. A. (1996) Organisational Learning II, Addison-Wesley.
BECK, K. (2000) Extreme Programming Explained, Addison-Wesley.
BECK, K. & ANDRES, C. (2004) Extreme Programming Explained: Embrace Change, Addison-Wesley.
BENEFIELD, G. (2008) Rolling Out Agile at a Large Enterprise. Hawaii International Conference on Software Systems. Big Island, Hawii.
CUNNINGHAM, W. (1996) EPISODES: A Pattern Language of Competitive Development. IN VLISSIDES, J., COPLIEN, J. & KERTH, N. L. (Eds.) Pattern Languages of Program Design. Addison-Wesley.
CUSUMANO, M. A. & NOBEOKA, K. (1998) Thinking Beyond Lean, Free Press.
DE GEUS, A. P. (1997) The Living Company, Nicholas Brealey Publishing.
GILB, T. (2005) Competitive Engineering, Butterworth-Heinemann.
GLAZER, H., DALTON, J., ANDERSON, D., KONRAD, M. & SHRUM, S. (2008) CMMI or Agile: Why Not Embrace Both! Hanscom AFB, MA, Software Engineering Institute
KELLY, A. (2007) Blue White Red - an example agile process. ACCU Overload.
KELLY, A. (2008) Changing Software Development: Learning to Become Agile, John Wiley & Sons.
KENNEDY, M. N. (2003) Product Development for the Lean Enterprise, Richmond, VA,, Oaklea Press.
POPPENDIECK, M. & POPPENDIECK, T. (2003) Lean Software Development, Addison-Wesley.
POPPENDIECK, M. & POPPENDIECK, T. (2007) Implementing lean software development : from concept to cash, London, Addison-Wesley.
SENGE, P. (1990) The Fifth Discipline, Random House Books.
WOMACK, J. P., JONES, D. T. & ROOS, D. (1991) The machine that changed the world, New York, HaperCollins.
Published (Last edited): 20-12-2012 , source: http://www.develop.com/agiledemystified