Agile ir Scru m

Agile ir ScrumStanislovas Jonušas

Tradicinis (krioklio) metodas

Tradicinių (krioklio) metodų prielaidos

Projekto valdymas yra nuspėjamas ir kartotinis procesas. Mes galime tiksliai iš anksto įvertinti užtrukimo laiką ir resursų poreikį

projekto padarymui. Mes ištikrųjų galime suplanuoti visas smulkmenas, kurios nepasikeis

per visą projekto laiką. Visi reikalavimai gali būti surinkti prieš pradedant projektą. Klientas (vartotojas) gali paaiškinti savo reikalavimus ir pasakyti, ko

jam tiksliai reikia, net nematydamas veikiančios programos. Reikalavimai niekada nepasikeis.

Agile pradžia

2001 metais vasario mėn, susirinko programuotojai į Snowbird (Utah) kurortą aptarti, kaip būtų galima greičiau ir kokybiškiau pagaminti PĮ.

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler

James GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian Marick

Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

Agile Manifestas

Kurdami programinę įrangą ir padėdami ją kurti kitiems, mes randame geresnius būdus tai daryti. Dirbdami mes vertiname:

Žmones ir jų bendravimą labiau nei procesus ir įrankius;

Veikiančią programinę įrangą labiau nei išsamią dokumentaciją;

Bendradarbiavimą su klientu labiau nei derybas dėl kontraktų;

Reagavimą į pokyčius labiau nei plano vykdymą.

12 Agile principų

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the

customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the

shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust

them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-

face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to

maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior

accordingly.

Kodėl yra daroma Agile ?

Sumažinti kainą; Sumažinti riziką; Padeda išvengti esminių klaidų (fail-fast, fix-cheap); Padinti komandos produktyvumą; Rinkoje nieko naujesnio šiuo metu nėra; Dėl Mados (nes kiti tai daro).

Agile naudingas, kai:

Kuriamas inovatyvus produktas; Keičiasi rinkos/ekonomikos sąlygos; Sudėtingas (complex) produktas/projektas; Vartotojo reikalavimai yra pastoviai besikeičiantys, daug

neapibrėžtumo, sunku suprasti, ką reikia pagaminti.

Naudojant Agile yra būtina:

Kvalifikuoti (turintys reikiamus įgudžius) ir motyvuoti komandos nariai;

Efektyvus palaikymas iš kliento ir stiprus bendradarbiavimas su juo; Vykdomosios valdžios aplinkos palaikymas.

Agile naudojimas svarstytinas, kai:

Paprastas ir triavialus projektas, kai yra mažai nežinomujų. Organizacija naudoja „sunkų“ procesą ir lėtai priima sprendimus. Neįmanomas kliento/vartotojo įtraukimas (pakeičiame kažką kode,

bet klientas tų pakeitimų nepamato, nes pakeitmai buvo infrastruktūroje ir pan.)

Sena sistema, kur programos kodas „spageti“ principu. (Sunkiai padaromi pakeitimai projekte/produkte).

Kai suformuota komanda neturi reikiamų įgudžių (trūksta kažkokios srities specialisto, kuris būtinas PĮ pagaminimui).

Aukšto standarto reguliavimai, kai klaidos griežtai negalimos (pvz. Vaistų gamyba, atominės elektrinės, karinė pramonė).

Kodėl darant pagal Agile projektai žlunga? Agile metodas – tai ne sidabrinė kulka, jinai nesprendžia esminių

problemų, jeigu problemos yra susijusios su žiniomis ar komandos įgūžiais. Agile šitoje vietoje padės tik tuom, kad tos problemos anksčiau pasirodys (fail fast principas).

Nepavykęs kliento įtraukimas į procesą arba įmonės vykdomosios valdžios nepalaikymas.

Žmonės vadina projektą Agile projektu, bet nesupranta pagrindinių koncepcijų. Paprastai tai būna, kai daro „mini-waterfal“ ir sako, kad tai yra Agile.

Pagal Agile - paketimai yra visada sveikintini. Bet tai nereiškia, kad padarom ir po to daug kartų perdarinėjame. Agile šitokiems perdarinėjimams beprasmis.

Agile metodai

Scrum  Extreme programming (XP)  DSDM  Lean software development Feature Driven Development (FDD)  Agile Modeling  Agile Unified Process (AUP)  Agile Data Method  Essential Unified Process (EssUP)  Getting Real  Open Unified Process (OpenUP)  .....

Scrum

Empirinio proceso atributai

Skaidrumas (Transperancy) – turi visi matyti ir suprasti rezultatą vienodai (bendra kalba ir supratimas, ką reikšia DONE, tiek tarp darančių darbą, tiek ir tą darbą priimančių asmenų)

Patikrinimas (Inpection) – tikrinti SCRUM artifaktus (daily stand-ups, retrospektyva, sprint review)

Pakeitimas (Adaption) – po pasitikrinimo, padaryti atinkamus pakeitimus, kad gamintume greičiau ir tai, ką reikia.

Scrum framework

Dviejų savaičių iteracija

Rolės

Product Owner (PO) – kliento balsas, tarpinkas tarp komandos ir kliento, atsakingas už tai, kad didžiausią vertę gautų klientas/akcininkas. Jis atsako už backlog‘ą ir jo prioritetizavimą.

Scrum Master – atsakingas už komandos kliūčių pašalinimą, jis nėra team lead‘as, bet veikia kaip tarpinikas tarp komandos ir PO. Prižiūri, kad būtų laikomasi SCRUM taisyklių ir vertybių. Gerina komandos efektyvumą.

Team member – atsakingas, kad būtų pagamintas kokybiškas produktas. Komanda būna sudaryta iš cross-function žmonių.

PO atsakomybės:

Aiškiai aprašyti Product Backlog įrašai (User story, Epic). Užtikrinti, kad komandos darbas būtų vertingas (nedarytų to, ko

nereikia). Užtikrinti, kad Product Backlog yra visiems matomas, suprantamas ir

aiškus komandai, ką ji toliau darys. Užtikrinti, kad komanda supranta produkto Backlog‘o įrašus iki

pakankamo detalumo lygio. Pasako, ką reikai padaryti. Perteikia viziją komandai ir nukreipia ją reikiama kryptimi. Priima padarytą darbą.

Savybės gero PO:

Į verslą orientuotas (ROI); Supranta sritį (domain); Visada pasiekamas komandai (-oms); Turi galios priimti projektui/produktui sprendimus; Turi viziją, kaip sėkmingai pagaminti produktą/projektą.

Scrum Master

Prižiūri, kad būtų laikomasi taisyklių ir vertybių; Atsakingas, kad būtų pašalintos visos kliūtys ir komanda galėtų

pasiekti Sprint‘o tikslą; Apsaugo komandą nuo išorinio pasaulio poveikio ir PO; Padeda PO perteikti projekto viziją, paruošti backlog‘ą, suprasti

procesą; Praveda SCRUM eventus, jeigu yra poreikis; Atsakingas, už komandos kokybišką darbą ir motyvaciją.

Scrum Master nedaro:

Užduoties atlikimo laiko įvertinimo; Tvarkymo ir prioritetizavimo Backlog‘o; Darbų paskirstymo; Sprendimo priėmimo; Ir neduoda nurodymų, kaip padaryti (pačios implementacijos);

Grooming susirinkimas

Išlaikyti backlog‘ą suprioritetizuotą; Pašalinti nebereikalingus backlog‘o įrašus; Sukurti arba pakelti prioritetą pagal svarbą; Skaldyti arba sujungti backlog‘o įrašus; Įvertinti taskų sudėtingumą; Susirinkimas užtrunka ne ilgiau negu 2val., kai iteracija yra 2

savaičių.

Įvertinimas be Agile pokerio

Įvertinimas pagal Agile pokerį

Sprinto planingas

Dviejų savaičių iteracijai skiriama iki 4h (fiksuotas laikas);

Dalyvauja visa komanda; Skaldomi User Story į technines užduotis; Sudarytas iš dviejų dalių:

Nusprendžiama, kokie darbai turi būti padaryti; Kokią implementacija mes pasirinksime;

Sprinto backlog nesikeičia visą iteraciją.

Stand-up susirinkimas

Kiekvieną dieną, toje pačioje vietoje ir tuo pačiu laiku.

Neilgiau negu 15 min. Trys esminiai klausimai:

Ką vakar dariau; Ką šiandien planuoju daryti; Ar yra kokių klučių, kas neleis man pabaigti užduoties.

„Burn down“ diagrama

Sprinto peržiūra

Dalyvauja visa komanda; Vyksta demonstracija suinteresuotiems žmonėms (klientui,

akcininkams); Neilgiau negu 1h. (fiksuotas laikas) 2 savaičių iteracijai. Pagal gautą atgalinį ryšį galima daryti pakeitimus kitame sprint‘e; Pasitikriname, ar tą gaminame, ko klientui reikia.

Retrospektyva

Komandos darbo gerinimas (proceso pagerinimas išlaikant Scrum principus);

Trys klausimai: Kas buvo gerai; Ką galima pagerinti; Kokių veiksmų imtasi iš praeitos retrospektyvos susirinkimo.

Neilgiau negu 1h (fiksuotas laikas) 2 sav. iteracijai; Tai nėra skirta santykių aiškinimuisi ir senų sąskaitų

suvedimui; Visos komandos įtraukimas.

Tradicinis procesas

Prielaidos:• Klientas žino tikrai ko

norį• Programuotojas

detalei žino kaip gamins produktą

• Niekas nesikeis per visą projektą

Agile procesas

Prielaidos:• Klientas eigoje

supras ko jis ištikrųjų norį

• Programuotojas eigoje ras būdą kaip geriau pagaminti

• Viskas gali keistis viso proceso metu

Ačiū

Klausimai ?