Agile ir scru m
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Agile ir Scru m PowerPoint PPT Presentation


  • 131 Views
  • Uploaded on
  • Presentation posted in: General

Agile ir Scru m. Stanislovas 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.

Download Presentation

Agile ir Scru m

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Agile ir scru m

Agile ir Scrum

StanislovasJonušas


Tradicinis krioklio metodas

Tradicinis (krioklio) metodas


Tradicini krioklio metod prielaidos

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

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


Agile manifestas

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

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

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

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

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

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

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

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

Scrum


Empirinio proceso atributai

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

Scrum framework


Dviej savai i iteracija

Dviejų savaičių iteracija


Rol s

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

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

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

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

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

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 be Agile pokerio


Vertinimas pagal agile poker

Įvertinimas pagal Agile pokerį


Sprinto planingas

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

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

„Burn down“ diagrama


Sprinto per i ra

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

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

Tradicinis procesas

Prielaidos:

  • Klientas žino tikrai ko norį

  • Programuotojas detalei žino kaip gamins produktą

  • Niekas nesikeis per visą projektą


Agile procesas

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


Agile ir scru m

Klausimai ?

Ačiū


  • Login