Što je agilna metodologija? Objašnjeni suvremeni razvoj softvera

Čini se da svaka tehnološka organizacija danas prakticira agilnu metodologiju za razvoj softvera ili njenu verziju. Ili barem vjeruju da vjeruju. Bez obzira jeste li novi u agilnom razvoju aplikacija ili ste razvoj softvera naučili prije nekoliko desetljeća koristeći metodologiju softverskog razvoja vodopada, danas na vaš rad barem utječe agilna metodologija.

Ali što je agilna metodologija i kako je treba primjenjivati ​​u razvoju softvera? Po čemu se okretan razvoj razlikuje od slapa u praksi? Koji je agilni životni ciklus razvoja softvera ili agilni SDLC? A što je scrum agile naspram Kanbana i ostalih agilnih modela? 

Agile je službeno pokrenut 2001. godine kada je 17 tehnologa izradilo Agile manifest. Napisali su četiri glavna principa za agilno upravljanje projektima, s ciljem razvoja boljeg softvera:

  • Pojedinci i interakcije nad procesima i alatima
  • Radni softver preko sveobuhvatne dokumentacije
  • Suradnja kupaca tijekom pregovora o ugovoru
  • Odgovor na promjenu slijedeći plan

Prije agilnosti: doba metodologije vodopada

Stare ruke poput mene sjećaju se dana kada je metodologija vodopada bila zlatni standard za razvoj softvera. Proces razvoja softvera zahtijevao je tonu dokumentacije unaprijed prije početka bilo kakvog kodiranja. Netko, obično poslovni analitičar, prvo je napisao dokument o poslovnim zahtjevima koji je obuhvatio sve što je poduzeću bilo potrebno u aplikaciji. Ovi dokumenti o poslovnim zahtjevima bili su dugački i detaljno su opisivali sve: ukupnu strategiju, sveobuhvatne funkcionalne specifikacije i vizualni dizajn korisničkog sučelja.

Tehnolozi su uzeli dokument o poslovnim zahtjevima i razvili vlastiti dokument o tehničkim zahtjevima. Ovaj je dokument definirao arhitekturu aplikacije, strukture podataka, objektno orijentirani funkcionalni dizajn, korisničko sučelje i druge nefunkcionalne zahtjeve.

Ovaj proces razvoja softvera vodopada konačno će pokrenuti kodiranje, zatim integraciju i konačno testiranje prije nego što se aplikacija procijeni kao spremna za proizvodnju. Cijeli postupak mogao bi lako potrajati nekoliko godina.

Od nas programera se očekivalo da znamo „specifikaciju“, kako se zvala kompletna dokumentacija, baš kao i autori dokumenata, a često smo bili kažnjavani ako bismo zaboravili pravilno implementirati ključni detalj naveden na stranici 77 200- dokument stranice.

Tada sam razvoj softvera također nije bio lak. Mnogi razvojni alati zahtijevali su specijaliziranu obuku, a nije bilo niti blizu otvorenih ili komercijalnih softverskih komponenti, API-ja i web usluga koje danas postoje. Morali smo razviti stvari na niskoj razini, poput otvaranja veza s bazom podataka i višestruke obrade podataka.

Za čak i osnovne aplikacije timovi su bili veliki, a komunikacijski alati ograničeni. Naše tehničke specifikacije bile su ono što nas je uskladilo, a mi smo ih iskoristili poput Biblije. Ako bi se zahtjev promijenio, provodili bismo poslovne lidere kroz dug postupak pregleda i odjave jer je komunikacija promjena unutar tima i popravljanje koda bila skupa.

Budući da je softver razvijen na temelju tehničke arhitekture, prvo su razvijeni artefakti niže razine, a nakon toga ovisni artefakti. Zadaci su bili dodijeljeni vještinama, a inženjerima baza podataka bilo je uobičajeno prvo konstruirati tablice i druge artefakte baze podataka, zatim programeri aplikacija koji kodiraju funkcionalnost i poslovnu logiku, a zatim je konačno prekriveno korisničko sučelje. Prošli su mjeseci prije nego što je itko vidio da aplikacija djeluje, a do tada su dionici postajali nervozni i često pametniji što zapravo žele. Nije ni čudo što je provedba promjena bila tako skupa!

Nije sve što ste stavili pred korisnike funkcioniralo prema očekivanjima. Ponekad korisnici uopće ne bi upotrebljavali značajku. Drugi puta je sposobnost bila široko uspješna, ali zahtijevao je reinženjering kako bi se podržala potrebna skalabilnost i izvedba. U svijetu slapova te ste stvari naučili tek nakon što je softver pokrenut, nakon dugog razvojnog ciklusa.

Povezani videozapis: Kako doista djeluje agilna metodologija

Čini se da svi govore o agilnom razvoju softvera, ali mnoge organizacije nemaju čvrsto razumijevanje kako taj proces funkcionira. Pogledajte ovaj petominutni videozapis da biste brzo ubrzali.

Ključ za agilni razvoj softvera

Izumljena 1970. godine, slap metodologija bila je revolucionarna jer je unijela disciplinu u razvoj softvera kako bi se osiguralo postojanje jasnih specifikacija. Temeljila se na metodi izrade vodopada izvedenoj iz inovacija proizvodne trake Henryja Forda iz 1913. godine, koja je pružala sigurnost u svakom koraku u proizvodnom procesu kako bi se osiguralo da konačni proizvod odgovara onome što je specificirano.

Kad je metodologija vodopada došla u svijet softvera, računalni sustavi i njihove primjene bili su obično složeni i monolitni, zahtijevali su disciplinu i jasan ishod. Zahtjevi su se također polako mijenjali u usporedbi s današnjim danima, pa su napori velikih razmjera bili manje problematični. Zapravo, sustavi su građeni pod pretpostavkom da se neće mijenjati već da će biti vječni bojni brodovi. Višegodišnji rokovi bili su uobičajeni ne samo u razvoju softvera već i u proizvodnji i ostalim poslovnim aktivnostima. Ali krutost vodopada postala je Ahilova peta u eri interneta, gdje su bile potrebne brzina i fleksibilnost.

Metodologija razvoja softvera počela se mijenjati kad su programeri počeli raditi na internetskim aplikacijama. Puno ranog posla odrađivano je u startupovima gdje su timovi bili manji, bili su kolocirani i često nisu imali tradicionalno računalno podrijetlo. Bilo je financijskih i konkurentskih pritisaka da se web mjesta, aplikacije i nove mogućnosti brže izbace na tržište. Kao odgovor na to brzo su se promijenili razvojni alati i platforme.

To je navelo mnoge od nas koji radimo u startupovima da preispitamo metodologiju vodopada i potražimo načine da budemo učinkovitiji. Nismo si mogli priuštiti da radimo svu detaljnu dokumentaciju unaprijed i trebao nam je više iterativnog i suradničkog postupka. Još uvijek smo raspravljali o promjenama zahtjeva, ali bili smo otvoreniji za eksperimentiranje i prilagođavanje potrebama krajnjih korisnika. Naše su organizacije bile manje strukturirane, a aplikacije manje složene od naslijeđenih sustava poduzeća, pa smo bili puno otvoreniji za izgradnju u odnosu na kupnju aplikacija. Još važnije, pokušavali smo rasti tvrtke, pa kad su nam korisnici rekli da nešto ne radi, češće smo odabrali da ih slušamo.

Naše vještine i naše sposobnosti za inovacije postale su strateški važne. Mogli ste prikupiti sav novac koji ste željeli, ali niste mogli privući talentirane programere softvera sposobne za rad s internetskim tehnologijama koje se brzo mijenjaju ako biste ih tretirali kao podaničke kodere koji ropski slijede "specifikaciju". Odbili smo projektne menadžere koji su dolazili s krajnjim rasporedima koji opisuju što bismo trebali razviti, kada se aplikacije trebaju isporučiti, a ponekad čak i kako strukturirati kod. Bili smo užasni u postizanju tromjesečnih i šestomjesečnih rasporeda koje su voditelji projekata vodopada sastavljali i neprestano ih ažurirali.

Umjesto toga, počeli smo im govoriti kako treba dizajnirati internetske aplikacije, a rezultate smo davali prema rasporedu koji smo iterativno sastavili. Ispostavilo se da nismo bili toliko loši u isporuci onoga što smo rekli da hoćemo kad bismo se tome obvezali u malim intervalima od jednog tjedna do četiri tjedna.

2001. grupa okupljenih iskusnih programera okupila se i shvatila da zajednički vježbaju razvoj softvera drugačije od klasične vodopadne metodologije. I nisu svi bili u startupovima. Ova skupina, koja je obuhvaćala svjetiljke tehnologije Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber i Jeff Sutherland, smislila je Agile manifest koji je dokumentirao njihova zajednička uvjerenja u to kako bi trebao funkcionirati moderni proces razvoja softvera. Naglasili su suradnju oko dokumentacije, samoorganizaciju, a ne rigidne prakse upravljanja, i sposobnost da se uspijete konstantno mijenjati, umjesto da se zatvorite za kruti proces razvoja vodopada.

Iz tih se principa rodila agilna metodologija za razvoj softvera.

Uloge u agilnoj metodologiji

Agilan proces razvoja softvera uvijek započinje definiranjem korisnika i dokumentiranjem izjave o viziji o opsegu problema, mogućnosti i vrijednosti kojima se treba pozabaviti. Vlasnik proizvoda bilježi ovu viziju i surađuje s multidisciplinarnim timom (ili timovima) kako bi ostvario tu viziju. Evo uloga u tom procesu.

Korisnik

Agili procesi uvijek započinju imajući na umu korisnika ili kupca. Danas ih često definiramo s korisničkim osobama kako bismo ilustrirali različite uloge u tijeku rada koji softver podržava ili različite vrste potreba i ponašanja kupaca.

Vlasnik proizvoda

Sam agilni proces razvoja započinje s nekim tko mora biti glas kupca, uključujući sve unutarnje dionike. Ta osoba izdvaja sve uvide, ideje i povratne informacije kako bi stvorila viziju proizvoda. Te su vizije proizvoda često kratke i jednostavne, ali unatoč tome daju sliku tko je kupac, kojim se vrijednostima rješava i strategiju kako ih riješiti. Mogu zamisliti da je Googleova izvorna vizija izgledala otprilike poput "Olakšajmo svima koji imaju pristup internetu da pronađu relevantne web stranice i web stranice s jednostavnim sučeljem vođenim ključnim riječima i algoritmom koji uvažavajuće izvore rangira više u rezultatima pretraživanja."

Ovu osobu nazivamo vlasnikom proizvoda . Njegova je odgovornost definirati ovu viziju, a zatim surađivati ​​s razvojnim timom kako bi je postala stvarnom.

Da bi radio s razvojnim timom, vlasnik proizvoda raščlanjuje viziju proizvoda na niz korisničkih priča koje detaljnije opisuju tko je ciljni korisnik, koji se problem za njih rješava, zašto je rješenje važno za njih i koja ograničenja i kriteriji prihvaćanja definiraju rješenje. Vlasnik proizvoda daje prioritet tim korisničkim pričama, a tim pregledava kako bi osigurao zajedničko razumijevanje onoga što se od njih traži.

Tim za razvoj softvera

Agilan, razvojni tim i odgovornosti njegovih članova razlikuju se od odgovornosti u tradicionalnom razvoju softvera.

Timovi su multidisciplinarni, a sastoje se od raznolike skupine ljudi koji imaju vještine za obavljanje posla. Budući da je fokus na isporuci radnog softvera, tim mora dovršiti cjelovite funkcionalne aplikacije. Dakle, baza podataka, poslovna logika i korisničko sučelje dijela aplikacije razvijaju se, a zatim demoiraju - a ne cijela aplikacija. Da bi to učinili, članovi tima moraju surađivati. Često se sastaju kako bi bili sigurni da su svi usklađeni s onim što grade, s time što tko radi i s točno određenim načinom na koji se softver razvija.

Uz programere, timovi za razvoj softvera mogu uključivati ​​inženjere za osiguranje kvalitete (QA), druge inženjere (kao što su baze podataka i pozadinski sustavi), dizajnere i analitičare, ovisno o vrsti softverskog projekta.

Scrum, Kanban i drugi agilni okviri

Mnogi agilni okviri koji pružaju specifičnosti razvojnih procesa i agilnih razvojnih praksi, usklađeni sa životnim ciklusom razvoja softvera.

Najpopularniji okretan okvir naziva se scrum . Fokusira se na ritam isporuke koji se naziva sprint i strukture sastanaka koje uključuju sljedeće:

  • Planiranje - tamo gdje su prepoznati prioriteti sprinta
  • Predanost - gdje tim pregledava popis ili zaostatak korisničkih priča i odlučuje koliko se posla može obaviti u trajanju sprinta 
  • Svakodnevni standup sastanci - tako da timovi mogu komunicirati s novostima o svom razvojnom statusu i strategijama)

Sprintovi završavaju demo sastankom na kojem se vlasniku proizvoda prikazuje funkcionalnost, nakon čega slijedi retrospektivni sastanak na kojem tim raspravlja o tome što je prošlo dobro i što treba poboljšati u svom procesu.

Mnoge organizacije zapošljavaju scrum majstore ili trenere koji pomažu timovima u upravljanju scrum postupkom.

Iako scrum dominira, postoje i drugi okretni okviri:

  • Kanban djeluje kao postupak obožavanja i obožavanja gdje tim izvlači korisničke priče s usisne ploče i usmjerjuje ih kroz fazni proces razvoja dok se ne dovrše.
  • Neke organizacije usvajaju hibridni agilni pristup i slap, koristeći agilne postupke za nove primjene i slap za naslijeđene.
  • Postoji i nekoliko okvira koji omogućavaju organizacijama da razmjenjuju praksu s više timova.

Iako agilni okviri definiraju proces i suradnju, agilne razvojne prakse specifične su za rješavanje zadataka razvoja softvera koji se izvode u skladu s agilnim okvirom.

Tako, na primjer:

  • Neki timovi usvajaju programiranje u paru, gdje dva programera zajedno kodiraju kako bi postigli kvalitetniji kod i omogućili starijim programerima da podučavaju mlađe.
  • Napredniji timovi usvajaju razvoj i automatizaciju temeljenu na testovima kako bi osigurali da osnovna funkcionalnost donosi očekivane rezultate.
  • Mnogi timovi također usvajaju tehničke standarde tako da interpretacija korisničke priče programera ne dovodi samo do željene funkcionalnosti, već udovoljava sigurnosti, kvaliteti koda, konvencijama o imenovanju i drugim tehničkim standardima.

Zašto je agilna metodologija bolja