oisv_09a_sdlc_overview_1_2012

8/18/2019 OISv_09a_SDLC_Overview_1_2012

1/66

SDLC pregled


2/66

ExtremeProgrammingIterativna metodologija


3/66

Planiranje

User stories; Release planning; small releases;Business Anal ysis; Project Velocity; Iterations;Iteration planning; Move people around; Stand-

up meeting day; F ix XP when i t breaks .

Dizajn

Simplicity; System metaphor.Use CRC cards for design sessions.

Spike solutions to reduce risk. No functionality added early.

Refactor.

Kodiranje

Customer is always available; Standards.Code the unit test first; Pair programmed;

Integrates often; Collective code ownership.Optimization till last; No overtime.

Testiranje

All code must have and pass unit tests before it

can be released; When a bug is foundtests are created; Acceptance tests are run

often and the score is published.

Pravila i praksa Extreme

Programming-a

http://www.extremeprogramming.org/rules/customer.htmlhttp://www.extremeprogramming.org/rules/unittests.htmlhttp://www.extremeprogramming.org/rules/unittests.htmlhttp://www.extremeprogramming.org/rules/testfirst.htmlhttp://www.extremeprogramming.org/rules/customer.htmlhttp://www.extremeprogramming.org/rules/refactor.htmlhttp://www.extremeprogramming.org/rules/early.htmlhttp://www.extremeprogramming.org/rules/spike.htmlhttp://www.extremeprogramming.org/rules/crccards.html


4/66

Pregled

Extreme programming

User Stories

Business Analysis u XP

CRC Cards


5/66

Extreme Programming pregled

http://www.extremeprogramming.org/map/iteration.htmlhttp://www.extremeprogramming.org/map/iteration.htmlhttp://www.extremeprogramming.org/map/iteration.html


6/66

Jedna XP iteracija


7/66

Pregled razvoja

http://www.extremeprogramming.org/rules/pair.htmlhttp://www.extremeprogramming.org/rules/pair.htmlhttp://www.extremeprogramming.org/rules/pair.htmlhttp://www.extremeprogramming.org/rules/pair.html


8/66

Aktivnosti programera i načinrada

http://www.extremeprogramming.org/rules/sequential.htmlhttp://www.extremeprogramming.org/rules/sequential.htmlhttp://www.extremeprogramming.org/rules/sequential.htmlhttp://www.extremeprogramming.org/rules/sequential.html


9/66

User Stories


10/66

• User story je kratki opis šta poslovanje ili klijent zahtjevaju odsoftvera, napisan od strane klijenta, u njihovoj prirodnoj

terminologiji bez tehničkih termina.

Šta su User Stories?

Obično su u formi oddvije-tri rečenice i pisane

na 4x6 karticama.


11/66

Svrha

• User Stories se koriste za procjenu vremena za sastanke release

planning sastanke.

• Zamjenjuju velike requirement dokumente.

• User Stories omogućavaju kreiranje acceptance testova.


12/66

Primjer

"Tell me the story and write down the name of the story and a paragraph or two."

License Enforcement

When run for the first time, JeraWorks puts up a license dialog, and will not proceed until

the user enters either:

• a valid non-time-limited (paid) license certificate or

• a valid time-limited (demo) license that has not yet expired.

A valid license is stored so the user doesn't have to re-enter it on subsequent runs.

License info is displayed on the splash screen.

When a demo license expires, the license dialog re-appears the next time JeraWorks is run.


13/66

User Stories i Planning Game

• Osnovni cilj je kreiranje release plana

• Osnovni dijelovi su User Stories (kartice)

• Učesnici su klijenti i programeri

• Pravila:

• Programeri procjenjuju koliko vremena treba da se

Story napravi

• Klijent odlučuje koje će se Stories implementirati usvakom Release i datum Releas-a


14/66

User Stories i Planning Game

• Kad se napravi release plan, odabrane Stories se

prevode u individualne zadatke programiranja

koji će se obaviti za vrijeme iteracije kako bi se

dovršio Story.• Svaki Story dobija 1, 2 ili 3 sedmice "ideal

development time".

• Tipični XP projekat od 6 - 12 mjeseci zahtjeva 50-100 User Stories.


15/66


16/66

Requirements Specifications

VS User Stories• Detaljnost

• User stories su kratke i konkretne

• User stories daju onoliko detalja koliko je potrebno dase napravi razumno rizična procjena vremenaimplementacije.

• Fokusiranje na potrebe• Izbjegavati detalje vezane za tehnologiju, bazu

podataka i algoritme. Ostati fokusiran na potrebe

korisnika i benefite, a ne na izgled GUI-ja.


17/66

Analiza uExtreme Programming-u


18/66


XP "circle of life":

• Korisnik odlučuje koje su opcije „vrijedne”

• Programeri procijenjuju trošak vezan za te opcije,

• Korisnik izabira najbolju kombinaciju opcija na osnovuvrijednosti i cijene,

• Programeri izrađuju opcije, popravljajuči procjenu troškaza vrijeme procesa,

• Korisnik se uči boljem definiranju vrijednosti i odabiruefektivnih izbora.


19/66


• I korisnik i programer napreduju u procesu.

• Poslovni analitičari se uključuju kad je u pitanju više

korisnika ili kada korisnik ne može donijeti odluku.

• Prednosi uključenja analitičara:• I korisnik i programer više uče o svom poslu

• Korisnik i programer uče više o poslu druge strane

• Poboljšanje komunikacije, tačnosti, konzistentnosti proizvoda


20/66


• Problem u komunikaciji korisnik - programer:

• Prevod terminologije otežava komunikaciju

• Korisnik neće cijeniti rad programera i njegove procjene

• Korisnik gubi kontrolu i dolazi do nezadovoljstva

• Rješenja:

• Analitičar treba pomagati korisniku, a ne biti veza između korisnika i

programera

• Redovni sastanci korisnika i analitičara• Analitičar treba pomoći pri pisanju Stories-a, a ne prevoditi ih


21/66


• Pomoći korisniku u odabiru prioriteta, a ne praviti odluku za njih

• Učiniti da korisnik razumije proces i dati osjećaj kontole što je više

moguće

• Pomoći korisniku defnisati acceptance testove


22/66

CRC Cards

• „Class, Responsibilities, and Collaboration Cards”

• Jednostavan način specificiranja dizajna

• Nisu nužno dio Extreme Programming-a


23/66

CRC Card

• Na vrhu kartice je Class

• Lijevo su Responsibilities

•Desno Collaborating klase

• Jednostavan opis klasa i

njihove funkcionalnosti


24/66

Kako se koriste

• Kreirati kartice za očite klase

• Proći kroz user story, opisati kako se klase međusobno odnose

• Premještati kartice (istraživati različit dizajn)

• Dodati/obrisati kartice po potrebi


25/66

Dokumentiranje dizajna

• Ne treba čuvati kartice, niti davati dodatnu dokumentaciju.

• Dobro napisan i testiran kod je dokumentacija dizajna za sebe.

• Zašto gubiti vrijeme na pisanje u nadogradnju dokumentacije?Ili zašto raditi sa zastarjelom dokumentacijom?


26/66

Šta je onda sa UML-om?

• Ništa!

• Zašto crtati slike dizajna kad XP mijenja dizajn konstantno?

• CRC Cards se mogu koristiti kao prezentacija za kompleksnije

procese ako to projekat zahtjeva (ili ako volite dokumentaciju).


27/66

SCRUMAgilna Metodologija


28/66

Uvod

Klasični metodi imaju svoje mane: veliki napor u planiranju

teška izmjena zahtjeva u dinamičnim okolinama

tretiranje uposlenih kao „resursa”


29/66

Agilni razvoj

Manifest agilnog razvoja

"Mi pronalazimo bolje načine razvoja softvera čineći i pomažući drugima da to

čine. Kroz taj rad naučili smo vrijednovati:

Pojedince i odnose iznad Procesa i alata

Funkcionalan softver iznad Iscrpne dokumentacije

Saradnju s kupcem iznad Pregovaranja i ugovora

Reagovanje na promjenu iznad Praćenja plana

To jeste, premda su stvari s desna bitne, mi vrjednujemo stvari s lijeva više"

Agile Alliance (više autora)


30/66

Scrum


31/66

Scrum pojednostavljeno

• Scrum je agilni proces koji omogućava fokusiranje annajvišu vrijednost za najkraće vrijeme.

• Omogućave brzu i stalnu inspekciju živog softvera (svake2-4 sedmice).

• Korisnik definiše prioritete. Timovi se samostalnoupravljaju kako bi donijeli najbolji način za isporukuprioritetnih opcija.

• Svake 2-4 sedmice svi mogu vidjeti živi softver i odlučitida li ga pustiti u produkciju ili da poboljšavati još jednuiteraciju


32/66

Karakteristike

• Samoupravljivi timovi

• Proizvod se razvija u seriji jednomjesečnih sprintova -“sprints”

• Zahtjevi se upisuju kao stavke u lisi zvanoj “productbacklog”

• Nema preporučenih praksi i načina rada.

• Koristi generativna pravila za stvaranje agilnog okruženjaza isporuku projekta


33/66

Kako se izvodi?


34/66

Sprint

• Scrum projekti napreduju kroz seriju sprintova - “sprints”• Slično XP iteracijama

• Ciljno trajanje je jedan mjesec

• +/- jedna – dvije sedmice

•Konstantno trajanje vodi do boljeg ritma

• Proizvod je dizajniran, kodiran i testiran za vrijeme sprinta


35/66

Sekvencijani vs. Preklapajući razvoj

Requirements Design Code Test


36/66

Nema izmjena za vrijeme sprinta

• Planirati trajanje sprinta na onoliko dugo koliko je potrebnoda se osigura neuticanje izmjena na sprint.

SprintUlazi Testiran kod

Izmjena


37/66

Scrum Framework

• Uloge: Product Owner, ScrumMaster, Team

• Ceremonije : Sprint Planning, Sprint Review, Sprint

Retrospective, & Daily Scrum Meeting

• Artifakti : Product Backlog, Sprint Backlog, and Burndown

Chart


38/66

Product Owner

• Definiše opcije proizvoda

• Odlučuje o release datumu i sadržaju

• Odgovoran za profitabilnost proizvoda (ROI)

• Prioritizira opcije prema tržišnoj vrijednosti

• Modificira opcije i prioritete pred svaku iteraciju, po potrebi

• Prihvata ili odbija rezultate rada.


39/66

The Scrum Master

• Predstavlja menadžment projekta

• Odgovoran za održavanje Scrum vrijednosti i praksi

• Uklanja zapreke

• Osigurava da je tim funkcionalan i produktivan• Omogućava blisku kooperaciju svih uloga i funkcija

• Brani tim od eksternih uticaja


40/66

Scrum Team

• Obično 5-10 ljudi

• Multi-funkcionalan

• QA, Programeri, UI dizajneri, itd.

• Moraju biti full-time uposleni

• Izuzetci (System Admin, i sl.)

• Timovi su samoupravljivi

• Šta ako sam tim odbaci nekoga?

• Idealno bez titula, ali teško moguće

• Članovi se mogu mijenjati samo između sprintova


41/66

Ceremonije

• Sprint Planning Meeting

• Sprint

• Daily Scrum

• Sprint Review Meeting


42/66

Spring Planning Meeting

Sprint Planning

Meeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Sprint Goal


43/66

Dijelovi Sprint Planning Meeting-a

• 1. dio:

• Pravljenje Product Backlog

• Odlučivanje Sprint Goal-a.

• Učesnici: Product Owner, Scrum Master, Scrum Team

• 2. dio:• Učesnici: Scrum Master, Scrum Team

• Pravljenje Sprint Backlog


44/66

Pred-Projektni/Kickoff Meeting

• Posebni Sprint Planning Meeting

• Održava se prije početna projekta


45/66

Sprint

• Iteracija duga jedan mjesec za čije se vrijemepoboljšava/dodaje funkcionalnost proizvoda

• Nema vanjskog utjecaja na Scrum team za vrijeme sprinta

• Svaki sprint počinje sa Dnevnim Scrum Meeting-om


46/66

Dnevni Scrum

• Parameteri• Dnevno

• 15-minuta

• Stand-up

•Nije za rješavanje problema

• Tri pitanja:1. Šta si uradio/la jućer?

2. Šta ćeš uraditi danas?

3. Koje su prepreke pred tobom?

• „Chickens” i „pigs” su prisutni*• Pomaže izbjegavanju drugin nepotrebnih sastanaka

• Samo „pigs” govore


47/66

Dnevni Scrum

• NIJE sesija rješavanja problema

• NIJE način prikupljanja informacija KO kasni sa poslom

• JESTE sastanak na kojem se članovi tima obavezuju jednidrugima i Scrum Master-u

• JESTE dobar način za Scrum Master-a da prati napredak tima


48/66

Scrum FAQ

• Zašto dnevno?• “Kako projekt zakasni čitavu godinu?”

• “Dan po dan”

• Fred Brooks, The Mythical Man-Month.

• Može li se Scrum meetingzamjeniti emailom?• Ne

• Cijeli tim vidi kompletnu sliku svaki dan

• Pravi se pritisak kolega kako bi se uradilo ono što se treba

uraditi


49/66

Sprint Review Meeting• Tim prezentuje šta je uradio za vrijeme

sprinta

• Obično je u formi prikaza demo verzijenovih opcija ili arhitekture

• Informalan

• 2-satna priprema

• Učesnici• Klijenti

• Menadžment

• Product Owner

• Ostali inžinjeri


50/66

Sprint Retrospective Meeting

• Samo Scrum Team

• Feedback meeting

• Tri pitanja

• Start?

• Stop?

• Nastavak?

• Naizostavno za prvih 5-6 sprintova!!!


51/66

Product Backlog

• Lista svog potrebnog posla na projektu

• Obično kombinacija

• story-based posao (“let user search and replace”)

• task-based posao (“improve exception handling”)

• Product Owner definira prioritete• Obično Product Manager, Marketing, Interni klijent, itd.


52/66

Product Backlog

• Zahtjevi sistema, prikazani kao prioritizirana lista Backlog Item-

a

• Product Owner je vlasnik i upravljač liste

• Obično tabela

• Obično se kreira na Sprint Planning Meeting-u• Može se mijenjati i re-prioritizirati PM


53/66

PrimjerProduct Backlog

Od S i t G l d S i t B kl


54/66

Od Sprint Goal-a do Sprint Backlog-a

• Scrum team preuzima Sprint Goal i odlučuje koji taskovi suneophodne

• Tim se samoorganizuje oko toga kako će ispuniti Sprint Goal

• Menadžer ne dodjeljuje taskove pojedincima

• Menadžeri ne donose odluke za tim• Pravi se Sprint Backlog


55/66

Sprint Backlog za vrijeme Sprinta

• Izmjene

• Tim dodaje nove taskove kad god treba, kako bi se ispunio Sprint

Goal

• Tim može ukloniti nepotrebne taskove

• Sprint Backlog Može mijenjati samo tim• Procjene se mijenjaju kad god postoje nove informacije


56/66

Sprint Backlog

• Podskup Product Backlog Item-a, definiše rad Sprinta

• Kreiraju ga SAMO članovi tima

• Svaki item ima svoj status

• Treba se osvježavati dnevno


57/66

Sprint Backlog

• Ne više od 300 taskova u listi

• Ako task zahtjeva više od 16 sati, treba ga podjeliti na dva iliviše

• Tim može dodavati i oduzimati iteme sa liste. Product Owner

ne može.


58/66

Sample Sprint Backlog


59/66

Sprint Burn down Chart

• Prikazuje total satnicu Sprint Backlog-a koja je ostala nadnevnoj bazi

• Prikazuje „koliko je vremena ostalo do releas-a”

• Idealno bi trebala biti smanjena na nulu na kraju Sprinta

• Nije prava linija• Može porasti!


60/66

Sprint Burndown Chart

Progress

752 762

664619

304264

180

104

200

100

200

300

400

500

600

700

800

900

5 / 3 / 2 0

0 2

5 / 5 / 2 0

0 2

5 / 7 / 2 0

0 2

5 / 9 / 2 0

0 2

5 / 1 1 / 2 0 0

2

5 / 1 3 / 2 0 0

2

5 / 1 5 / 2 0 0

2

5 / 1 7 / 2 0 0

2

5 / 1 9 / 2 0 0

2

5 / 2 1

/ 2 0 0

2

5 / 2 3

/ 2 0 0

2

5 / 2 5

/ 2 0 0

2

5 / 2 7

/ 2 0 0

2

5 / 2 9

/ 2 0 0

2

5 / 3 1

/ 2 0 0

2

Date

RemainingEffo

rtinHours


61/66

Release Burndown Chart

• Hoće li release biti na vrijeme?

• X-osa: sprint

• Y-osa: ostalo sati

• Može rasti!


62/66

Product Burndown Chart

• “big picture” progresa projekta


63/66

Skalabilnost Scrum-a

• Tipični Scrum tim je 6-10 ljudi

• Jeff Sutherland - preko 800 ljudi

• "Scrum of Scrums" ili "Meta-Scrum“


64/66



65/66



66/66

Za/protiv Prednosti

Kompletno razvijene itestirane opcije u kratkimiteracijama

Jednostavnost procesa

Jasna pravila

Povećana produktivnost Samoorganizovanje

Svaki član tima nosi velikuodgovornost

Poboljšana komunikacija

Kombinacija sa XP-om

Mane:

Nema dokumentacija

Kršenje odgovornosti

Uglavnom ga koriste

inventivne firme

oisv_09a_sdlc_overview_1_2012

Documents