Kodėl verta naudoti „Agile Delivery“?
„Agile“ suteikia daugybę galimybių suinteresuotosioms šalims ir komandai įsitraukti į procesą – prieš kiekvieną sprintą, jo metu ir po jo. Klientą įtraukiant į kiekvieną projekto etapą, užtikrinamas glaudesnis kliento ir projekto komandos bendradarbiavimas, todėl komanda turi daugiau galimybių iš tiesų suprasti kliento viziją. Ankstyvas ir dažnas veikiančios programinės įrangos pristatymas didina suinteresuotųjų šalių pasitikėjimą komandos gebėjimu pristatyti aukštos kokybės veikiančią programinę įrangą ir skatina jas aktyviau dalyvauti projekte.
Taikant „Agile“ metodiką klientams suteikiama unikali galimybė dalyvauti visame projekte – nuo funkcijų prioritetų nustatymo, iteracijų planavimo ir peržiūros sesijų iki dažno programinės įrangos vystymo su naujomis funkcijomis. Tačiau tam taip pat reikia, kad klientai suprastų, jog mainais į papildomą skaidrumo naudą jie darbo eigoje gali matyti neužbaigtą darbą.
Naudojant nustatyto grafiko sprintus, kurių trukmė 1–4 savaitės, naujos funkcijos pristatomos greitai ir dažnai, o jų lygis yra lengvai prognozuojamas. Tai taip pat suteikia galimybę programinę įrangą išleisti arba atlikti jos beta bandymus anksčiau nei planuota, jei ji verslui suteikia pakankamą vertę.
Kadangi kiekvienas sprintas yra fiksuotos trukmės, išlaidos yra prognozuojamos ir ribojamos darbo kiekiu, kurį komanda gali atlikti per fiksuotos trukmės laikotarpį. Kartu su įverčiais, pateiktais klientui prieš kiekvieną sprintą, klientas gali lengviau suprasti apytiksles kiekvienos funkcijos sąnaudas, o tai leidžia lengviau priimti sprendimus dėl funkcijų prioriteto ir papildomų iteracijų poreikio.
Nors per kiekvieną iteraciją komanda turi sutelkti dėmesį į sutartų produkto funkcijų pogrupio pristatymą, yra galimybė nuolat tobulinti ir keisti viso produkto darbų sąrašo prioritetus. Naujus ar pakeistus darbų sąrašo elementus galima suplanuoti kitai iteracijai, suteikiant galimybę pakeitimus įdiegti per kelias savaites.
Suteikus klientui galimybę nustatyti funkcijų prioritetą, komanda gali suprasti, kas yra svarbiausia kliento verslui bei pateikti funkcijas, kurios suteikia didžiausią vertę verslui.
„Agile“ paprastai pasitelkia naudotojo istorijas su verslo priėmimo kriterijais, kad apibrėžtų produkto funkcijas. Funkcijas orientuojant į realių naudotojų poreikius, kiekviena funkcija palaipsniui sukuria vertę, o ne tik paprastą IT komponentą. Tai taip pat suteikia galimybę po kiekvieno sprinto atlikti programinės įrangos beta testavimą, gauti vertingų atsiliepimų ankstyvoje projekto stadijoje ir prireikus atlikti atitinkamus pakeitimus.
Suskirsčiusi projektą į suvaldomas dalis, projekto komanda gali sutelkti dėmesį į kokybišką vystymą, testavimą ir bendradarbiavimą su klientu. Be to, dažnai rengiant programinės įrangos versijas ir atliekant bandymus bei peržiūras kiekvienos iteracijos metu, kokybė gerėja greitai surandant ir pataisant defektus bei anksti nustatant lūkesčių neatitikimus.
„Scrum“ vystymo komandos
„Scrum“ vystymo komandos
Bendrovėje „Toughlex“ dirbame „Scrum“ vystymo komandose. „Scrum“ yra „Agile“ pogrupis. Tai lengviausia ir plačiausiai naudojama „Agile“ vystymo proceso sistema. „Scrum“ programuotojų komanda – tai savarankiškai organizuojama tarpfunkcinė žmonių komanda, kuri yra „Scrum“ vystymo komandos struktūros pagrindas. Tai komanda, atsakinga už faktinio produkto prieaugio vystymą ir sprinto tikslo įgyvendinimą. „Scrum“ sėkmė labai priklauso nuo to, kaip sėkmingai dirba programuotojų komanda. Kokios yra jų pareigos?Šiam procesui kūrėjų komanda skirs daugiausia laiko. Pasibaigus sprinto planavimo susitikimui, komanda gauna sprinto darbų sąrašą ir sprinto tikslą, prie kurio turi dirbti. Kūrėjų komanda pati priima organizacinius sprendimus bei kartu nusprendžia, kaip planuos ir valdys šį darbą. Tai apima sprinto darbų sąrašo elementų projektavimą, vystymą, integravimą ir testavimą, kad būtų sukurtas potencialiai išsiuntimui paruoštas produktas.
Vienas iš svarbiausių „Scrum“ modelio privalumų yra jo lankstumas ir gebėjimas kasdien prisitaikyti. „Scrum“ komanda kasdien dalyvauja „Scrum“ susirinkimuose, kuriuose bendrai tikrina, kaip sekasi siekti sprinto tikslo. Atsižvelgdami į pažangą, jie pritaiko dienos planą. Tai leidžia jiems užtikrinti, kad pasibaigus sprinto darbams nekiltų netikėtumų.
Nors daug dėmesio kūrėjų komanda skiria neužbaigtų sprinto darbų atlikimui, jiems vis tiek reikia skirti šiek tiek laiko šių darbų sąrašui tikslinti. Produkto savininkas visų pirma yra atsakingas už neatliktų darbų suvaldymą. Tačiau programuotojų komanda padeda jam patikslinti, įvertinti ir nustatyti prioritetus tokių darbų sąraše.
Kiekvieno sprinto pradžioje programuotojų komanda kartu su produkto savininku dalyvauja sprinto planavimo susitikime. Programuotojų komanda padeda produkto savininkui apibrėžti sprinto tikslą. Jie taip pat nustato, kiek darbo gali realiai atlikti, kad pasiektų sprinto tikslą. Paprastai tai daroma kiekvienai istorijai priskiriant istorijos taškus ir lyginant juos su tuo, kiek istorijos taškų kūrėjų komanda istoriškai pasiekė per sprintą. Jei programuotojų komandai kyla klausimų dėl nustatyto reikalavimo, jie juos išsiaiškina su produkto savininku.
Kiekvieno sprinto pabaigoje programuotojų komanda turi dvi galimybes patikrinti ir pritaikyti produktą ir procesą – sprinto peržiūrą ir sprinto retrospektyvą.
„Agile“ iteracijų darbo eiga
„Agile“ iteracijų darbo eiga
Per „Agile“ programinės įrangos vystymo gyvavimo ciklą bus atliekamos kelios iteracijos, ir kiekviena iš jų turi savo darbo eigą. Iteracijos metu svarbu, kad klientai ir verslo suinteresuotieji subjektai pateiktų atsiliepimus ir taip užtikrintų, kad funkcijos atitiktų jų poreikius.Tipišką iteracijos proceso eigą galima pavaizduoti taip:
Iteracijos reikalavimų apibrėžimas, remiantis neatliktų produkto darbų sąrašu, sprinto darbų sąrašu, klientų ir suinteresuotųjų šalių atsiliepimais.
Programinės įrangos projektavimas ir vystymas pagal nustatytus reikalavimus.
QA (kokybės užtikrinimo) testavimas, vidiniai ir išoriniai mokymai, dokumentacijos pateikimas
Darbinės iteracijos integracija ir pristatymas gamybai
Klientų ir suinteresuotųjų šalių atsiliepimų priėmimas ir jų įtraukimas į kitos iteracijos reikalavimus.
Nors į neužbaigtų produkto darbų sąrašą gali būti įtraukiamos papildomos funkcijos, projekto vykdymo metu likusi proceso dalis yra veiksmų kartojimas tol, kol bus įvykdyti visi produktų sąrašo elementai. Todėl proceso eiga yra labiau ciklinė, o ne linijinė.
„Scrum“ ar „Kanban“?
„Kanban“ ir „Scrum“ yra sistemos, padedančios komandoms laikytis „Agile“ principų ir atlikti darbus.„Kanban“ – tai darbo vizualizavimas, nebaigtų darbų ribojimas ir maksimalus efektyvumo didinimas. „Kanban“ komandos daugiausia dėmesio skiria laiko, reikalingo projektui (arba naudotojo istorijai) įgyvendinti nuo pradžios iki pabaigos, sutrumpinimui. „Scrum“ komandos įsipareigoja pristatyti veikiančią programinę įrangą nustatytais intervalais, kurie vadinami sprintais. Jų tikslas – sukurti mokymosi ciklus, kad būtų galima greitai surinkti ir integruoti klientų atsiliepimus.
„Toughlex“ paprastai pasitelkia abi to dalis, nes tai padeda pritaikyti procesą prie projekto ir kliento, o ne atvirkščiai.
- „Scrum“
- Reguliarūs fiksuotos trukmės sprintai (1–4 savaitės)
- „Kanban“
- Nenutrūkstamas srautas
- „Scrum“
- Kiekvieno sprinto pabaigoje
- „Kanban“
- Nuolatinis pristatymas
- „Scrum“
- Produkto savininkas, „Scrum“ meistras, programuotojų komanda
- „Kanban“
- Nėra privalomų vaidmenų
- „Scrum“
- Greitis
- „Kanban“
- Parengimo laikas, ciklo laikas, darbo procesas
- „Scrum“
- Komandos neturėtų daryti pakeitimų sprinto metu.
- „Kanban“
- Pokyčiai gali įvykti bet kuriuo metu
Mūsų „Agile“ partneriai
Glaudžiai bendradarbiaujame su geriausiais „Agile“ treneriais Lietuvoje. Tai užtikrina, kad mūsų „Agile“ praktika visada bus atnaujinama. Be to, tai leidžia mums padėti klientui efektyviausiu būdu įdiegti geriausią „Agile“ praktiką į savo vidinį darbo procesą.Susijusių atvejų tyrimai
Savitarnos portalas / „Telco“
Savitarnos portalas / „Telco“
Žiniatinklis / „iOS“ / „Android“ / savitarna
„Telco“ savarankiškos priežiūros sistemos palaikymas
„Telco“ savarankiškos priežiūros sistemos palaikymas
Žiniatinklis / Naudotojo sąsajos atnaujinimas / Savitarna
Elektroninis sveikatos įrašas
Elektroninis sveikatos įrašas
Žiniatinklis / „Angular“ / Savitarna
„Go24 Travel“
„Go24 Travel“
Žiniatinklis / B2B / Integracijos
„Meedooo“ kompetencijos stebėjimas
„Meedooo“ kompetencijos stebėjimas
Žiniatinklis / „AWS“ / BDAR
