Android Programjaim

Android fejlesztes, java, kotlin, web.. miegymas:)

Agile, SCRUM, agilis fejlesztes

2016. április 04. 13:09 - lacas82

Elobb egy video, aztan a lenyeges dolgok:

Agilis fejlesztes:

- SCRUM, xtreme programming, stb

Lenyege, kb:

Nem egyben fejlesztesz le hatalmas dolgokat, hanem inkrementalisan elosztva az idoben, ugynevezett sprintekben fejleszted. Mondjuk, ha van egy feleves projected, akkor nem felev mulva adsz ki egy release-t, hanem az elso honapban megirod a fontosabb ficsoroket, kimegy egy release, majd jon a kovetkezo sprint, amivel lehet kozben foglalkozni.

Minden feautere-nek termeszetesen van egy sulyozasa is, melyik fontosabb, mint a masik, es ez alapjan is megy a fejlesztes. Ezaltal gyorsan lehet pl kijavitani hibakat, vagy gyorsabban lehet reagalni a marketre is.

Termeszetesen minden sprintre ujabb sulyozast is vezetunk be, nem biztos, hogy a kovetkezo sprintnel egy elozo heten vett sulyozas vagy feature teljesen hasznos egy kovetkezo verzioban.

Tehat rovid fejlesztesi ciklusok jonnek letre, gyorsabb reakcioidovel, gyorsabb hibakezelessel.
A termek az agilis fejlesztesnek koszonhetoen gyorsabban es tobbszor valtozik, mint egy tradicionalis fejleszteskor. Tradicionalis fejleszteskor, kritikus hibak mondjuk csak a fejlesztesi ido vegen derulnek ki, vagy tervezesi hianyossagok, mig egy agilisnal ez gyorsan letisztulhat. Valamint versenypozicioban is jobb helyen leszel egy agilis fejlesztes kovetkezteben.

Timeboxok vannak, vagy masneven sprint-ek agilis fejlesznel, SCRUM-nal.

Aglie manifesto:

Elonyben reszesiti a valtoztatasokat azzal szemben, hogy kovessuk a tervet. Hisz a valtozas orok. Elonyben reszesiti az egyeneket es a kapcsolatokat, az eszkozokkel es folyamatokkal szemben.

Tradicionalis fejlesztes:

- Elore definialt ficsorok
- Nagy fejlesztesi szakaszok (inkrementalis fejlesztes), vagy az egesz project elkeszitese es szallitasa (waterfall)
- kevesebb stabilitas es hosszabb fejlesztesi ciklus, lassabb reakcio barmire


Agilis fejlesztes:


- dinamikusan definialt es prioritizalt ficsorok (sulyozott)
- kisebb fejlesztesi szakaszok, egyrol a kettore
- rovidebb reszfeladat fejlesztesek es gyorsabb reakcio a marketre es stabilabb mukodes

SCRUM:

- Az agilis fejlesztes egyik modszertana
- Egy folyamat, ami elore definialt gyakorlatok es szabalyok osszesege (na jo ezt csak forditottam, eleg hulyen hangzik:) )

Miert a SCRUM?

- Hogy maximalizaljuk a fejlesztocsapat kepesseget, hogy gyorsan reagalhassanak a valtoztatasokra, es hogy gyorsabban es stabilabb kodot irhassanak
- Hogy rovidebb fejlesztesi ciklusok lehessenek


Gyakorlatilag ezzel ossze is foglaltam a lenyeget, de folytatom...

Vannak napi Scrum metting-ek, ebben elhangzanak, hogy

- Mit haladtunk az utolso meeting ota
- Tervek mara
- Milyen akadalyok lehetnek

Vannak Sprint Planning Meetingek

- Product backlog attekintese
- A kovetkezo spring idejenek meghatarozasa
- A kovetkezo sprintben mi lesz benne

SCRUM TEAM:

Ezt a videoban latni, nem terek ki ra, kb 5-9 emberbol allhat es egy irodaban kell lenniuk, hogy a kommunikacio hasznos es gyors lehessen.

- Remote-ra annyira nem jo ez, foleg ha a fold kulonbozo pontjan elnek a fejlesztesben resztvevok. (idoeltolodasok, etc)


SCRUM MASTER:

- Terelgeti a fejlesztoket
- Mindent iranyit
- Segit az akadalyokat lerombolni
- A folyamatokat felugyeli
- Akarki lehet, akinek van ehhez affinitasa es megvan benne a Jedi Power

SPRINTEK:

- A SCRUM alap egysege
- A team hatarozza meg az idejet
- Tipikusan 1-4 het (hetfo-hetfo)
- Sprint elott, planning meting
- Sprint utan: demozas, review es visszatekintes

PRODUCT BACKLOG:

Nem mas, mint a feature-ok tomkelege, amit meg kell valositani.

- A PRODUCT OWNER es a team definialja
- Prioritizalja a PRODUCT OWNER
- Minden Sprint elott ujra prioritizalja (sulyozza, uj sorrendbe helyezi a fontosabb megvalositando feladatokat)

Najo kb ennyit errol.

Ez volt a SCRUM, az agilis fejlesztes ismertetese.