Agile ir Scru m

1. Agile ir Scrum StanislovasJonušas

2. Tradicinis (krioklio) metodas

3. 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.

4. 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Į.

5. 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ą.

6. 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.

7. 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).

8. 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.

9. 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.

10. 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ė).

11. 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.

12. 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)  • .....

13. Scrum

14. 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.

15. Scrum framework

16. Dviejų savaičių iteracija

17. 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ų.

18. 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ą.

19. 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ą.

20. 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ą.

21. 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);

22. 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ų.

23. Įvertinimas be Agile pokerio

24. Įvertinimas pagal Agile pokerį

25. 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ą.

26. 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.

27. „Burn down“ diagrama

28. 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.

29. 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.

30. Tradicinis procesas Prielaidos: • Klientas žino tikrai ko norį • Programuotojas detalei žino kaip gamins produktą • Niekas nesikeis per visą projektą

31. 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

32. Klausimai ? Ačiū