Zdi se, da vsaka tehnološka organizacija danes izvaja agilno metodologijo za razvoj programske opreme ali njeno različico. Ali vsaj verjamejo, da vedo. Ne glede na to, ali ste nov v agilnem razvoju aplikacij ali ste se že pred desetletji naučili razvoja programske opreme z metodologijo za razvoj slapov, danes na vaše delo vsaj vpliva agilna metodologija.
Kaj pa je agilna metodologija in kako jo je treba izvajati pri razvoju programske opreme? V čem se gibčni razvoj v praksi razlikuje od slapa? Kakšen je gibčni življenjski cikel razvoja programske opreme ali gibčen SDLC? In kaj je scrum agile v primerjavi s Kanbanom in drugimi gibčnimi modeli?
Agile je bil uradno predstavljen leta 2001, ko je 17 tehnologov pripravilo Agile Manifesto. Napisali so štiri glavna načela za agilno vodenje projektov s ciljem razvoja boljše programske opreme:
- Posamezniki in interakcije med procesi in orodji
- Delovna programska oprema nad obsežno dokumentacijo
- Sodelovanje strank pri pogajanjih o pogodbi
- Odziv na spremembo glede na načrt
Before agile: Obdobje slapovske metodologije
Starci, kot sem jaz, se spominjajo časov, ko je bila slapovska metodologija zlati standard za razvoj programske opreme. Proces razvoja programske opreme je zahteval veliko dokumentacije vnaprej, preden se je začelo kodiranje. Nekdo, običajno poslovni analitik, je najprej napisal dokument s poslovnimi zahtevami, ki je vseboval vse, kar je podjetje potrebovalo v aplikaciji. Ti dokumenti o poslovnih zahtevah so bili dolgi in so vse podrobno opisovali: splošno strategijo, obsežne funkcionalne specifikacije in vizualne zasnove uporabniškega vmesnika.
Tehnologi so vzeli dokument o poslovnih zahtevah in razvili lasten dokument o tehničnih zahtevah. Ta dokument je opredelil arhitekturo aplikacije, podatkovne strukture, objektno usmerjene funkcionalne zasnove, uporabniške vmesnike in druge nefunkcionalne zahteve.
Ta postopek razvoja programske opreme za slap bi končno sprožil kodiranje, nato integracijo in končno testiranje, preden je bila aplikacija ocenjena kot pripravljena. Celoten postopek bi lahko trajal nekaj let.
Od razvijalcev se je pričakovalo, da smo vedeli »specifikacijo«, kot se je imenovala celotna dokumentacija, tako kot avtorji dokumentov, in so nas pogosto kaznovali, če smo pozabili pravilno izvesti ključno podrobnost, opisano na strani 77 200- dokument strani.
Takrat tudi sam razvoj programske opreme ni bil enostaven. Številna razvojna orodja so zahtevala specializirano usposabljanje in v bližini danes ni bilo odprtokodnih ali komercialnih komponent programske opreme, API-jev in spletnih storitev. Razviti smo morali stvari na nizki ravni, na primer odpiranje povezav z bazo podatkov in večnitnost pri obdelavi podatkov.
Za celo osnovne aplikacije so bile ekipe velike, komunikacijska orodja pa omejena. Naše tehnične specifikacije so bile tisto, kar nas je usklajevalo, in vzpodbujali smo jih kot Biblija. Če bi se zahteva spremenila, bi vodili podjetja skozi dolg postopek pregleda in se odjavili, ker je bilo sporočanje sprememb v skupini in popravljanje kode drago.
Ker je bila programska oprema razvita na podlagi tehnične arhitekture, so bili najprej razviti artefakti nižje stopnje, pozneje pa odvisni artefakti. Naloge so bile dodeljene po spretnostih. Inženirji baz podatkov so običajno sestavljali tabele in druge artefakte baze podatkov, nato razvijalci aplikacij, ki kodirajo funkcionalnost in poslovno logiko, nato pa je bil uporabniški vmesnik prekrit. Trajalo je nekaj mesecev, preden je kdo videl, da aplikacija deluje, do takrat pa so zainteresirane strani postale nervozne in pogosto pametnejše glede tega, kaj v resnici želijo. Ni čudno, da je bilo izvajanje sprememb tako drago!
Ni vse, kar ste postavili pred uporabnike, delovalo po pričakovanjih. Včasih uporabniki sploh ne bi uporabili funkcije. Včasih je bila zmogljivost zelo uspešna, vendar je bilo treba znova načrtovati, da bi podprli potrebno razširljivost in zmogljivost. V svetu slapov ste se tega naučili šele po uvedbi programske opreme, po dolgem razvojnem ciklu.
Povezani video: Kako agilna metodologija v resnici deluje
Zdi se, da vsi govorijo o gibčnem razvoju programske opreme, vendar številne organizacije nimajo trdega razumevanja, kako postopek deluje. Oglejte si ta petminutni video, da boste hitro pospešili hitrost.
Vrtišče k agilnemu razvoju programske opreme
Metodopija slapov, izumljena leta 1970, je bila revolucionarna, ker je v razvoj programske opreme vnesla disciplino in zagotovila, da je treba slediti jasnim specifikacijam. Temeljila je na metodi izdelave slapov, ki je izhajala iz inovacij tekočih trakov Henryja Forda iz leta 1913, kar je zagotovilo gotovost vsakega koraka v proizvodnem procesu, da je zagotovilo, da se končni izdelek ujema s tem, kar je bilo sprva določeno.
Ko je slapovska metodologija prišla v svet programske opreme, so bili računalniški sistemi in njihove aplikacije običajno zapleteni in monolitni, kar je zahtevalo disciplino in jasen rezultat. Tudi zahteve so se počasi spreminjale v primerjavi z današnjimi, zato so bila obsežna prizadevanja manj problematična. Pravzaprav so bili sistemi zgrajeni ob predpostavki, da se ne bodo spremenili, ampak da bodo trajne bojne ladje. Večletni časovni okviri niso bili pogosti le pri razvoju programske opreme, temveč tudi v proizvodnji in drugih podjetniških dejavnostih. Toda togost slapa je v obdobju interneta postala ahilova peta, kjer sta bili potrebni hitrost in prilagodljivost.
Metodologija razvoja programske opreme se je začela spreminjati, ko so razvijalci začeli delati na internetnih aplikacijah. Veliko zgodnjih del je bilo opravljenih v zagonskih podjetjih, kjer so bile ekipe manjše, kolocirane in pogosto niso imele tradicionalnega računalništva. Obstajali so finančni in konkurenčni pritiski, da bi spletna mesta, aplikacije in nove zmogljivosti hitreje prišli na trg. Kot odziv so se hitro spreminjala razvojna orodja in platforme.
To je privedlo do tega, da smo mnogi, ki smo delali v startupih, spraševali o slapovski metodologiji in iskali načine, kako biti učinkovitejši. Nismo si mogli privoščiti, da bi vnaprej izdelali vso podrobno dokumentacijo, zato smo potrebovali bolj ponavljajoč se in skupnejši postopek. Še vedno smo razpravljali o spremembah zahtev, vendar smo bili bolj odprti za eksperimentiranje in prilagajanje potrebam končnih uporabnikov. Naše organizacije so bile manj strukturirane in naše aplikacije so bile manj zapletene kot stari sistemi, zato smo bili veliko bolj odprti za gradnjo kot za nakup aplikacij. Še pomembneje je, da smo poskušali rasti podjetja, zato smo se, ko so nam uporabniki rekli, da nekaj ne deluje, pogosteje odločili, da jih poslušamo.
Naše sposobnosti in sposobnosti za inovacije so postale strateško pomembne. Lahko bi zbrali ves denar, ki ste ga želeli, vendar niste mogli privabiti nadarjenih razvijalcev programske opreme, ki bi bili sposobni delati s hitro spreminjajočimi se internetnimi tehnologijami, če bi jih radi obravnavali kot podrejene kodirnike, ki suženjsko sledijo "specifikaciji". Zavrnili smo projektne vodje, ki so prihajali s celovitimi urniki, ki opisujejo, kaj bi morali razviti, kdaj naj se pošiljajo aplikacije in včasih celo, kako strukturirati kodo. Bili smo grozni pri doseganju trimesečnih in šestmesečnih urnikov, ki so jih vodje slapov pripravljali in nenehno posodabljali.
Namesto tega smo jim začeli pripovedovati, kako je treba izdelati internetne aplikacije, in rezultate smo podali po urniku, ki smo ga ponavljali. Izkazalo se je, da nismo bili tako slabi, če smo se temu zavezali, v majhnih, enotedenskih do štiritedenskih intervalih.
Leta 2001 se je skupina izkušenih razvijalcev programske opreme zbrala in spoznala, da skupaj razvijajo programsko opremo drugače kot klasična slapovska metodologija. In niso bili vsi v startupih. Ta skupina, ki je vključevala svetila Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber in Jeff Sutherland, je pripravila Agile Manifesto, ki je dokumentiral njihova skupna prepričanja o tem, kako naj deluje sodoben proces razvoja programske opreme. Poudarili so sodelovanje pri dokumentaciji, samoorganizacijo in ne toge prakse upravljanja ter sposobnost, da se nenehno spreminjamo, namesto da se zaklenemo za togi proces slapa.
Iz teh načel se je rodila gibčna metodologija za razvoj programske opreme.
Vloge v agilni metodologiji
Agilen postopek razvoja programske opreme se vedno začne z opredelitvijo uporabnikov in dokumentiranjem izjave o viziji o številnih težavah, priložnostih in vrednotah, ki jih je treba obravnavati. Lastnik izdelka zajame to vizijo in sodeluje z multidisciplinarno skupino (ali skupinami), da uresniči to vizijo. Tu so vloge v tem procesu.
Uporabnik
Agilni procesi se vedno začnejo z mislijo na uporabnika ali kupca. Danes jih pogosto definiramo z osebami uporabnikov, da ponazorimo različne vloge v delovnem toku, ki ga podpira programska oprema, ali različne vrste potreb in vedenja strank.
Lastnik izdelka
Agilen razvojni proces se sam začne z nekom, ki mora biti glas stranke, vključno z vsemi notranjimi deležniki. Ta oseba destilira vsa spoznanja, ideje in povratne informacije, da ustvari vizijo izdelka. Te vizije izdelkov so pogosto kratke in enostavne, vendar kljub temu predstavljajo sliko, kdo je stranka, katere vrednote obravnavamo in strategijo, kako jih nagovoriti. Lahko si predstavljam, da je bila Googlova prvotna vizija videti nekako takole: »Olajšajmo vsem, ki imajo dostop do interneta, najti ustrezna spletna mesta in spletne strani s preprostim vmesnikom, ki temelji na ključnih besedah, in algoritmom, ki ugledne vire uvršča višje med rezultate iskanja.«
To osebo imenujemo lastnik izdelka. Njegova odgovornost je opredeliti to vizijo in nato sodelovati z razvojno skupino, da jo uresniči.
Za sodelovanje z razvojno skupino lastnik izdelka razdeli vizijo izdelka na vrsto uporabniških zgodb, ki podrobneje opredelijo, kdo je ciljni uporabnik, kakšen problem se zanj reši, zakaj je rešitev zanje pomembna in katere omejitve in merila sprejemljivosti opredeljujejo rešitev. Lastnik izdelka prednostno obravnava te uporabniške zgodbe in jih pregleda skupina, da se zagotovi skupno razumevanje tega, kar se od njih zahteva.
Skupina za razvoj programske opreme
Po zaslugi agilnosti se razvojna skupina in odgovornosti njenih članov razlikujejo od odgovornosti pri tradicionalnem razvoju programske opreme.
Ekipe so multidisciplinarne, sestavljene iz raznolike skupine ljudi s spretnostmi za opravljanje dela. Ker je poudarek na zagotavljanju delujoče programske opreme, mora ekipa dokončati celotno delujoče aplikacije. Torej baza podatkov, poslovna logika in uporabniški vmesnik del aplikacije se razvije in nato preusmeri - ne celotne aplikacije. Za to morajo člani ekipe sodelovati. Pogosto se sestajajo, da se prepričajo, ali so vsi usklajeni s tem, kaj gradijo, s tem, kdo kaj počne, in s tem, kako natančno razvijajo programsko opremo.
Skupine za razvoj programske opreme lahko poleg razvijalcev vključujejo inženirje za zagotavljanje kakovosti (QA), druge inženirje (na primer za zbirke podatkov in zaledne sisteme), oblikovalce in analitike, odvisno od vrste programske opreme.
Scrum, Kanban in drugi gibčni okviri
Številni okretni okviri, ki zagotavljajo podrobnosti o razvojnih procesih in agilnih razvojnih praksah, usklajeni z življenjskim ciklom razvoja programske opreme.
Imenuje se najbolj priljubljen gibčen okvir scrum. Osredotoča se na kadenco dostave, imenovano a sprint in sestankov, ki vključujejo naslednje:
- Načrtovanje - kjer so opredeljene prednostne naloge sprinta
- Obveza - kjer ekipa pregleda seznam ali zaostanke uporabniških zgodb in odloči, koliko dela je mogoče opraviti v trajanju šprinta
- Vsakodnevni standup sestanki - tako da lahko ekipe sporočajo posodobitve o svojem razvojnem statusu in strategijah)
Sprinti se končajo s predstavitvenim sestankom, na katerem je lastniku izdelka prikazana funkcionalnost, ki mu sledi retrospektivni sestanek, na katerem skupina razpravlja o tem, kaj je šlo dobro in kaj je treba izboljšati v svojem procesu.
Mnoge organizacije zaposlujejo scrum mojstre ali trenerje za pomoč skupinam pri upravljanju scrum procesa.
Čeprav scrum prevladuje, obstajajo tudi drugi okretni okviri:
- Kanban deluje kot postopek oboževanja in odpuščanja, kjer ekipa povleče uporabniške zgodbe z vstopne plošče in jih usmeri skozi postopni razvojni postopek, dokler niso dokončani.
- Nekatere organizacije sprejmejo hibridni agilni in slapovski pristop, pri čemer uporabljajo agilne postopke za nove aplikacije in slap za starejše.
- Obstaja tudi več okvirov, ki organizacijam omogočajo, da prakso razširijo na več skupin.
Medtem ko agilni okviri opredeljujejo postopek in sodelovanje, so agilne razvojne prakse specifične za reševanje nalog razvoja programske opreme, ki se izvajajo v skladu z agilnim okvirom.
Tako na primer:
- Nekatere ekipe sprejmejo programiranje v paru, kjer dva razvijalca skupaj kodirata, da bi zagotovila kakovostnejšo kodo in starejšim razvijalcem omogočila mentorstvo mlajšim.
- Naprednejše skupine sprejmejo razvoj in avtomatizacijo, ki temelji na testih, da zagotovijo, da osnovna funkcionalnost prinaša pričakovane rezultate.
- Številne ekipe sprejmejo tudi tehnične standarde, tako da razlaga razlage uporabniške zgodbe ne vodi zgolj do želene funkcionalnosti, temveč ustreza tudi varnosti, kakovosti kode, konvencijam o poimenovanju in drugim tehničnim standardom.
