Egy kis info a kanban modszerekrol. Egyebkent ilyen pl a Trello.

Es egy rakat masik.

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.
 

Ok ezek image loader / cache-ing library-k, bovebben nagyon nem fogok rola beszelni, eleg annyi, hogy:

En regebben picassot hasznaltam, de mostanaban inkabb Glide-ot hasznalok, mert :

http://stackoverflow.com/questions/29363321/picasso-v-s-imageloader-v-s-fresco-vs-glide

 Egyebkent dependency-be:

compile 'com.github.bumptech.glide:glide:3.6.1'

vagy

compile 'com.squareup.picasso:picasso:2.5.2'

majd:

Glide.with(mContext).load(mImagePaths.get(position))
      .placeholder(R.drawable.logobg)
      .into(imgDisplay);

A Picassot hasonloan kell hasznalni, csak Glide helyett Picasso van, es mas beallitasai. Amint lathato 1 sorral lehet betolteni webrol kepet egy imageview-be.

.load-ben adjuk meg mit akarunk betolteni, placeholder, hogy alapbol mi latszodjon kepkent. into-val pedig azt, hogy melyik imageview-be akarjuk betolteni.

A Glide kevesebb memoriat hasznal, es RGB_565-ot hasznal alapbol, mig Picasso baratunk RGB8888-at.