Kiekviena technologijų organizacija šiandien praktikuoja judrią programinės įrangos kūrimo metodiką arba jos versiją. Ar bent jau jie tiki, kad taip daro. Nesvarbu, ar esate naujokas judrių programų kūrimo srityje, ar mokėtės programinės įrangos kūrimo prieš kelis dešimtmečius, naudodamas krioklio programinės įrangos kūrimo metodiką, šiandien jūsų darbui bent jau įtakos turi judri metodika.
Bet kas yra judri metodika ir kaip ji turėtų būti praktikuojama kuriant programinę įrangą? Kuo praktiškas judrus išsivystymas skiriasi nuo krioklio? Kas yra judrus programinės įrangos kūrimo gyvavimo ciklas arba judrus SDLC? O kas yra „scrum agile“, palyginti su „Kanban“ ir kitais judriais modeliais?
„Agile“ buvo oficialiai paleista 2001 m., Kai 17 technologų parengė „Agile“ manifestą. Jie parašė keturis pagrindinius judrių projektų valdymo principus, siekdami sukurti geresnę programinę įrangą:
- Asmenys ir procesų bei įrankių sąveika
- Darbinė programinė įranga, apimanti išsamią dokumentaciją
- Klientų bendradarbiavimas derantis dėl sutarties
- Atsakymas į pasikeitimą pagal planą
Prieš judrumą: krioklio metodikos era
Senos rankos, tokios kaip aš, prisimena tuos laikus, kai krioklio metodika buvo auksinis programinės įrangos kūrimo standartas. Prieš pradedant koduoti, programinės įrangos kūrimo procesui reikėjo daugybės dokumentų. Kažkas, paprastai verslo analitikas, pirmiausia parašė verslo reikalavimų dokumentą, kuriame užfiksuota viskas, ko reikia programoje. Šie verslo reikalavimo dokumentai buvo ilgi, juose buvo išsamiai aprašyta visa strategija, išsamios funkcinės specifikacijos ir vaizdinės vartotojo sąsajos projektai.
Technologai paėmė verslo reikalavimo dokumentą ir parengė savo techninių reikalavimų dokumentą. Šiame dokumente buvo apibrėžta programos architektūra, duomenų struktūros, į objektą orientuoti funkciniai projektai, vartotojo sąsajos ir kiti nefunkciniai reikalavimai.
Šis krioklio programinės įrangos kūrimo procesas pagaliau pradės kodavimą, tada integravimą ir galų gale testavimą, kol paraiška buvo laikoma parengta gaminti. Visas procesas gali lengvai užtrukti porą metų.
Mes, kūrėjai, tikėjomės žinoti „specifikaciją“, kaip vadinosi visa dokumentacija, lygiai taip pat, kaip žinojo dokumentų autoriai, ir dažnai buvome nubausti, jei pamiršome tinkamai įgyvendinti pagrindinę detalę, nurodytą 200 puslapių 77 puslapyje. puslapio dokumentą.
Tada pats programinės įrangos kūrimas taip pat nebuvo lengvas. Daugeliui kūrimo įrankių reikėjo specializuoto mokymo, o šalia egzistuojančio atvirojo kodo ar komercinės programinės įrangos komponentų, API ir žiniatinklio paslaugų nebuvo nė vieno. Mes turėjome sukurti žemo lygio dalykus, tokius kaip duomenų bazių ryšių atidarymas ir duomenų apdorojimas daugeliu sričių.
Net pagrindinėms programoms komandos buvo didelės, o komunikacijos priemonės - ribotos. Mūsų techninės specifikacijos buvo tai, kas mus suderino, ir mes jas panaudojome kaip Biblija. Jei pasikeistų reikalavimas, verslo lyderius atliktume ilgą peržiūrą ir pasirašytume, nes pranešti apie pakeitimus visoje komandoje ir pataisyti kodą buvo brangu.
Kadangi programinė įranga buvo sukurta remiantis technine architektūra, pirmiausia buvo sukurti žemesnio lygio artefaktai, o vėliau - priklausomi. Užduotys buvo skiriamos pagal įgūdžius, ir duomenų bazių inžinieriams buvo įprasta pirmiausia susikurti lenteles ir kitus duomenų bazės artefaktus, paskui programų kūrėjai užkodavo funkcionalumą ir verslo logiką, o galiausiai perdengė vartotojo sąsają. Praėjo keli mėnesiai, kol kas nors pamatė, kad programa veikia, ir tada suinteresuotosios šalys ėmė skruzdėti ir dažnai sumaniau, ko iš tikrųjų norėjo. Nenuostabu, kad pakeitimų įgyvendinimas buvo toks brangus!
Ne viskas, ką pateikėte prieš vartotojus, veikė taip, kaip tikėtasi. Kartais vartotojai visiškai nenaudojo funkcijos. Kitais atvejais pajėgumai buvo labai sėkmingi, tačiau reikėjo pertvarkyti, kad būtų palaikomas būtinas mastelis ir našumas. Krioklio pasaulyje šių dalykų išmokote tik įdiegę programinę įrangą po ilgo kūrimo ciklo.
Susijęs vaizdo įrašas: Kaip iš tikrųjų veikia judri metodika
Atrodo, kad visi kalba apie judrią programinės įrangos plėtrą, tačiau daugelis organizacijų nėra tvirtai suvokusios, kaip procesas veikia. Žiūrėkite šį penkių minučių vaizdo įrašą, kad greitai įsibėgėtumėte.
Lankstus programinės įrangos kūrimas
Išrasta 1970 m., Krioklio metodika buvo revoliucinga, nes ji suteikė drausmės programinės įrangos kūrimui, kad būtų užtikrinta aiški specifikacija. Jis buvo pagrįstas krioklio gamybos metodu, gautu iš Henry Fordo 1913 m. Surinkimo linijos naujovių, kurie suteikė tikrumo dėl kiekvieno gamybos proceso etapo, kad būtų garantuota, jog galutinis produktas pirmiausia atitinka tai, kas buvo specifikuota.
Kai krioklio metodika atėjo į programinės įrangos pasaulį, skaičiavimo sistemos ir jų taikymai paprastai buvo sudėtingi ir monolitiniai, reikalaujant disciplinos ir aiškių rezultatų. Reikalavimai taip pat lėtai keitėsi, palyginti su šiandieniniu, todėl didelio masto pastangos buvo mažiau problemiškos. Tiesą sakant, sistemos buvo kuriamos darant prielaidą, kad jos nepasikeis, bet bus amžini mūšio laivai. Kelerių metų laikotarpiai buvo įprasti ne tik programinės įrangos kūrimo, bet ir gamybos bei kitos įmonės veikloje. Tačiau krioklio tvirtumas tapo Achilo kulnu interneto epochoje, kur reikėjo greičio ir lankstumo.
Programinės įrangos kūrimo metodika pradėjo keistis, kai kūrėjai pradėjo dirbti su interneto programomis. Daug ankstyvo darbo buvo padaryta startuoliuose, kur komandos buvo mažesnės, buvo apgyvendintos ir dažnai neturėjo tradicinių informatikos žinių. Buvo finansinis ir konkurencinis spaudimas, kad tinklalapiai, programos ir naujos galimybės būtų greičiau parduodamos. Kūrimo priemonės ir platformos greitai pasikeitė.
Tai paskatino daugelį mūsų, dirbančių startuoliuose, suabejoti krioklio metodika ir ieškoti būdų, kaip efektyviau veikti. Negalėjome sau leisti atlikti visos išsamios dokumentacijos iš anksto, ir mums reikėjo daugiau kartoti ir bendradarbiauti. Mes vis dar diskutavome dėl reikalavimų pakeitimų, tačiau buvome atviresni eksperimentams ir prisitaikymui prie galutinių vartotojų poreikių. Mūsų organizacijos buvo mažiau struktūrizuotos ir mūsų programos buvo mažiau sudėtingos nei įmonės senos sistemos, todėl buvome daug atviresni kurdami, o ne pirkdami programas. Dar svarbiau tai, kad mes bandėme plėsti verslą, todėl kai vartotojai mums pasakė, kad kažkas neveikia, mes dažniausiai nusprendėme jų neklausyti.
Mūsų įgūdžiai ir gebėjimas diegti naujoves tapo strategiškai svarbūs. Galėtumėte surinkti visus norimus pinigus, bet negalėtumėte pritraukti talentingų programinės įrangos kūrėjų, galinčių dirbti su sparčiai besikeičiančiomis interneto technologijomis, jei ketinate juos vertinti kaip paklusnius koduotojus, vergiškai sekančius „specifikaciją“. Mes atmetėme projektų vadovus, kurie ateina su galutiniais tvarkaraščiais, kuriuose aprašoma, ką turėtume sukurti, kada turėtų būti pristatomos programos, o kartais net kaip susisteminti kodą. Mums buvo baisu pataikyti į trijų ir šešių mėnesių grafikus, kuriuos krioklio projektų vadovai parengė ir be paliovos atnaujino.
Vietoj to mes pradėjome jiems pasakoti, kaip reikia kurti interneto programas, ir mes pateikėme rezultatus pagal tvarkaraštį, kurį parengėme kartotinai. Pasirodo, mums nebuvo taip blogai, kai įvykdėme tai, ką pasakėme, kai įsipareigosime tai padaryti mažais, vienos ar keturių savaičių intervalais.
2001 m. Grupė patyrusių programinės įrangos kūrėjų susivienijo ir suprato, kad jie kartu praktikuoja programinės įrangos kūrimą kitaip nei klasikinė krioklio metodika. Ir jie visi nebuvo startuoliai. Ši grupė, apėmusi technologinius šviestuvus Kentą Becką, Martiną Fowlerį, Roną Jeffriesą, Keną Schwaberį ir Jeffą Sutherlandą, sukūrė „Agile“ manifestą, kuriame buvo užfiksuoti bendri įsitikinimai, kaip turėtų veikti šiuolaikinis programinės įrangos kūrimo procesas. Jie pabrėžė bendradarbiavimą, susijusį su dokumentavimu, savęs organizavimu, o ne griežta valdymo praktika, ir sugebėjimą valdyti nuolatinius pokyčius, o ne užsirakinti griežtame krioklio kūrimo procese.
Iš šių principų gimė judri programinės įrangos kūrimo metodika.
Vaidmenys judrioje metodikoje
Vikrus programinės įrangos kūrimo procesas visada prasideda apibrėžiant vartotojus ir dokumentuojant vizijos teiginį apie problemų, galimybių ir vertybių, kurias reikia spręsti, apimtį. Produkto savininkas užfiksuoja šią viziją ir bendradarbiauja su daugiadisciplinine komanda (ar komandomis), kad įgyvendintų šią viziją. Čia yra šio proceso vaidmenys.
Vartotojas
Vikrūs procesai visada prasideda galvojant apie vartotoją ar klientą. Šiandien mes dažnai juos apibrėžiame su vartotojo asmenimis, kad iliustruotume skirtingus vaidmenis programinės įrangos palaikomame darbo sraute arba skirtingus klientų poreikius ir elgesį.
Produkto savininkas
Pats judrus kūrimo procesas prasideda nuo asmens, kuris privalo būti kliento balsas, įskaitant visus vidinius suinteresuotus subjektus. Tas asmuo išskleidžia visas įžvalgas, idėjas ir atsiliepimus, kad sukurtų produkto viziją. Šios produkto vizijos dažnai būna trumpos ir paprastos, tačiau vis dėlto jie parodo, kas yra klientas, kokios vertybės yra nagrinėjamos, ir strategiją, kaip jas spręsti. Įsivaizduoju, kad „Google“ pirminė vizija atrodė maždaug tokia: „Leiskime visiems, turintiems prieigą prie interneto, lengvai rasti atitinkamas svetaines ir tinklalapius su paprasta, raktiniais žodžiais paremta sąsaja ir algoritmu, kuris paieškos rezultatuose užima gerus reputacijos šaltinius“.
Šį asmenį mes vadiname produkto savininkas. Jo atsakomybė yra apibrėžti šią viziją ir tada dirbti su kūrėjų komanda, kad ji būtų reali.
Dirbdamas su kūrėjų komanda, produkto savininkas suskirsto produkto viziją į vartotojų pasakojimų seriją, kurioje išsamiau išdėstoma, kas yra tikslinis vartotojas, kokia problema jam sprendžiama, kodėl sprendimas yra svarbus jam ir kokie suvaržymai ir priėmimo kriterijai apibrėžia sprendimą. Produkto savininkas teikia pirmenybę šioms vartotojų istorijoms, kurias peržiūri komanda, kad užtikrintų bendrą supratimą apie tai, ko iš jų prašoma.
Programinės įrangos kūrimo komanda
Vikriai kūrėjų komanda ir jos narių atsakomybė skiriasi nuo tradicinės programinės įrangos kūrimo.
Komandos yra daugiadisciplininės, sudarytos iš įvairių žmonių grupės, turinčios įgūdžių atlikti darbą. Kadangi pagrindinis dėmesys skiriamas veikiančios programinės įrangos pristatymui, komanda turi užbaigti visas funkcijas veikiančias programas. Taigi duomenų bazė, verslo logika ir vartotojo sąsaja dalis sukuriama ir vėliau demonstruojama ne visa programa. Norėdami tai padaryti, komandos nariai turi bendradarbiauti. Jie dažnai susitinka norėdami įsitikinti, kad visi yra suderinti su tuo, ką jie kuria, kas ką daro ir kaip tiksliai kuriama programinė įranga.
Be kūrėjų, programinės įrangos kūrimo komandose gali būti kokybės užtikrinimo (kokybės užtikrinimo) inžinieriai, kiti inžinieriai (pvz., Duomenų bazių ir vidinių sistemų), dizaineriai ir analitikai, atsižvelgiant į programinės įrangos projekto tipą.
„Scrum“, „Kanban“ ir kitos judrios struktūros
Daugybė judrių sistemų, kuriose pateikiama specifika apie kūrimo procesus ir judrią kūrimo praktiką, suderinta su programinės įrangos kūrimo gyvavimo ciklu.
Vadinama populiariausia judri sistema skrupulas. Jis orientuotas į pristatymo ritmą, vadinamą a sprintas ir susitikimų struktūros, kurios apima:
- Planavimas - kur nustatomi sprinto prioritetai
- Įsipareigojimas - kai komanda peržiūri naudotojų istorijų sąrašą ar neužbaigtą sąrašą ir nusprendžia, kiek daug darbo galima padaryti per sprinto laiką
- Kasdieniniai atsarginiai susitikimai, kad komandos galėtų pranešti apie savo vystymosi būseną ir strategijas)
„Sprints“ baigiasi demonstraciniu susitikimu, kuriame funkcionalumas parodomas produkto savininkui, po kurio vyksta retrospektyvinis susitikimas, kuriame komanda aptaria, kas sekėsi gerai ir ką reikia tobulinti jų procese.
Daugelis organizacijų įdarbina „scrum“ meistrus ar trenerius, kurie padeda komandoms valdyti „scrum“ procesą.
Nors dominuoja „scrum“, yra ir kitų judrių rėmų:
- „Kanban“ veikia kaip „fan-in“ ir „fan-out“ procesas, kai komanda ištraukia vartotojų istorijas iš įsiurbimo lentos ir perkelia jas į etapinį kūrimo procesą, kol jie bus baigti.
- Kai kurios organizacijos taiko hibridinį judrų ir krioklio metodą, naudodamos judrius procesus naujoms programoms ir krioklius senoms.
- Taip pat yra keletas sistemų, leidžiančių organizacijoms pritaikyti praktiką kelioms komandoms.
Nors judrios sistemos apibrėžia procesą ir bendradarbiavimą, judrios kūrimo praktikos yra specifinės sprendžiant programinės įrangos kūrimo užduotis, atliekamas derinant su judriu pagrindu.
Taigi, pavyzdžiui:
- Kai kurios komandos priima porų programavimą, kai du kūrėjai koduoja kartu, kad gautų aukštesnės kokybės kodą ir kad vyresni kūrėjai galėtų kuruoti jaunesnius.
- Pažangesnės komandos taiko testais pagrįstą kūrimą ir automatizavimą, kad užtikrintų, jog pagrindiniai funkcionalumai duoda laukiamų rezultatų.
- Daugelis komandų taip pat priima techninius standartus, kad kūrėjo aiškinimas apie vartotojo istoriją neatneštų tik norimo funkcionalumo, bet taip pat atitiktų saugumą, kodo kokybę, vardų suteikimo tvarką ir kitus techninius standartus.
