Transcript CT8_Agile ir Scrum_2013-10

Agile ir Scrum
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.

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 Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave 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
Klausimai ?
Ačiū