Agilis módszertanok¶
Motiváció¶
- Követelmények instabilitása
- Régebben a követelmények változása sokkal tovább tartott mint manapság.
- Időről időre ez az idő a felére csökken, pl. a 80-as években 10 évig tartott mire a termék specifikációján/követelményeken változtattak. Ma már ez fél év, vagy annál kevesebb.
- Technical debt: Technikailag "eladósodhatunk", ha a tervezésnél és fejlesztésnél a könnyebb és gyorsabb utat választjuk, mint a jobb megoldást amihez több idő kellene. Alapvetően 4 dolgot kell szem előtt tartani a szoftverfejlesztés során, ezek a
- költségvetés,
- határidő,
- specifikáció
- minőség
Ha az első 3 fix, akkor csak a minőségen tudunk „megtakarítani”, azaz később eladósodunk.
Agilis kiáltvány¶
Az agilis szoftverfejlesztés a szoftverfejlesztési módszerek egy csoportja, ahol a szoftverkövetelmények és a megoldások folyamatosan fejlődnek.
- Az agilitás 12 pontja (bővebben http://agilemanifesto.org/)
- Működő szoftver szállítása - gyakran
- Követelmények változtathatósága
- Fejlesztők és szakértők együttműködése
- Csapatközpontúság (5 pont)
- Motivált csapat
- Személyes kommunikáció
- Működés fejlesztése
- Fenntartható fejlesztés
- Rendszeres tervezés és minőségi kód
- Egyszerűség
Az agilis szó egyébként azt jelenti, hogy a fejlesztés változásbarát, azaz elfogadja, hogy a követelményekben változások lehetnek. Az üzleti szoftverek fejlesztésében ez a szempont alapvető, ugyanis például jogszabályváltozás miatt is gyakran változhatnak követelmények. Az agilis módszertan lényegében arra fókuszál, hogy a folyamatot olyan kisebb egységekre bontsuk fel, amelyek önmagukban már fejleszthető jellemzők, ugyanakkor változás esetén a lehető legkevesebb munka vesszen kárba.
Az agilis módszertanok nem szüntetik meg a korábban tanult, az előadáson említett modellek, mint a vízesés modell, RUP, vagy V-modell használhatóságát. Léteznek manapság is olyan fejlesztések, ahol a pontos tervezésnek szerepe van és a követelmények stabilak, azaz ahol a vízesés modellnek szerepe van (pl. repülésirányítás).
Projekt menedzsment¶
- GitLab
- https://about.gitlab.com/
- http://gitlab-okt.sed.hu/users/sign_in
- H-s azonosító és jelszó
- Új projekt létrehozása
- Issue kezelés és címék
- Wiki
- Mérföldkövek
- Jogosultságok
Módszertanok¶
Scrum¶
A Scrum egy összetett, komplex agilis módszertan, mely a szoftver hatékony fejlesztésére hivatott. A Scrum alappillére a Scrum csapat, melynek a felépítését az alábbi pontban láthatjuk.
Scrum csapat¶
- Product owner
- Teendők kezelése – Product Backlog: olyan lista, amely az előálló termék új jellemzőit, illetőleg a változtatni kívánt jellemzőket tartalmazza. Egyszerűbben fogalmazva mindazt tartalmazza, amit fejleszteni kell.
- Egyetlen személy (A gyakorlaton a gyakorlatvezető lesz ez)
- Fejlesztő csapat
- Önszerveződő
- Minden tudás megvan a szállításhoz, 4-8 fő
- Scrum master
- A Scrum működéséért felel
- A fejlesztő csapatot vezényli/segíti
- Ő is fejlesztő
Backlog¶
Ahhoz, hogy tudjuk min kell dolgozni, egy listában kell vezetnünk a feladatokat. Több féle backlog létezik, melyek közül a legfontosabbak:
- Product backlog
- Feladatok amiket meg kell oldani ahhoz, hogy elkészüljön a rendszer
- User story – felhasználó szempontjából fogalmazza meg a fejlesztendő alkalmazástól elvárt követelményeket. Formális szerkezete van:
- As a [end user role], I want [the desire] so that [the rationale].
- Epic, story, task - a user stroy alapján a fejlesztési feladatokat task szintre bontjuk le.
- Prioritási sor, a fontosabb feladatok jobban kidolgozottak, előre kerülnek a sorban.
- Dinamikus – tervezés, finomítás, priorizálás
- A gyakorlaton ez a gitlabon található Issuek listája lesz
- Sprint backlog
- Végrehajtandó feladatok az adott Sprintben. Ez a lista a Sprint tervezés során jön létre, a SCRUM csapat választja ki a product backlog alapján, ahol a prioritások is figyelembe vannak véve.
- Végrehajtandó feladatok az adott Sprintben. Ez a lista a Sprint tervezés során jön létre, a SCRUM csapat választja ki a product backlog alapján, ahol a prioritások is figyelembe vannak véve.
Sprint¶
Mivel iteratív a fejlesztés ezért meghatározunk adott időközöket, amelyben történik a feladat választás, fejlesztés, tesztelés stb. Ennek a neve Sprint. A Sprint végére kész és működő inkremens (a szoftver egy része) kell legyen.
- Fix időtartam: min 2 hét, max 1 hónap
- Sprint tervezés
- A csapat tesz vállalást
- Sprint cél: általában a backlog elemeiből
- A cél és a magas minőség nem változhat
- Story pointokat kell megszavaznia a csapatnak minden egyes feladathoz. Ez egy relatív mérőszám, csak a csapatra jellemző és összefüggésben van azzal, hogy az adott feladat elvégzéséhez mekkora munkabefektetés szükséges. Figyelem! Nem a ráfordítandó időt méri. https://youtu.be/Hwu438QSb_g
- Napi Scrum, vagy daily meeting
- max. 15 perc, teljes csapat: elvégzett munka, tervek, problémák
- Ezt érdemes meeting memoban vezetni (a gyakorlaton ezt a GitLab merge request-ben tesszük meg)
- Sprint áttekintés
- Inkremens ellenőrzése, bemutatása a megrendelőnek. Az egyes inkrementumokat a PO tételesen ellenőrzi, illetőleg fogadja el, vagy utasítja vissza.
- A gyakorlaton ez a bemutatók lesznek
- Sprint visszatekintés
- A csapat kiértékelése, fejlesztési lehetőségek keresése. Ez a csapat belső ügye, a PO ezen nem vesz részt.
Breakdown Chart¶
Hasznos diagram, amelynek a szerepe az, hogy tükröt tartson a csapat felé az aktuális teljesítményéről. A diagram azt mutatja, hogy a tervezetthez képes milyen gyorsan tudja a csapat a vállalt, user storykhoz kapcsolódó fejlesztési feladatait végrehajtani.
Kanban¶
Egy másik agilis módszertan a csapat munkájának szervezésére és menedzselésére. A folyamat megjelenítésére Kanban táblát szokás használni. (Pl. gitlab Issues -> Boards)
Kanban-ról dióhéjban¶
- Nagyon megengedő módszertan (Nincsenek sprintek, daily standupok stb.)
- Szabályok
- Vizualizáld a workflow-t
- Korlátozd a párhuzamosan folyamatban lévő feladatok számát
- WIP: work in progress: minden fázishoz hozzárendeljük azt az értéket, hogy maximálisan mennyi elem lehet az adott fázison belül (kivéve a backlog és az elkészült elemeket tartalmazó oszlop). Ha például a WIP értéke öt, akkor egyszerre csak öt task szerepelhet a fejlesztés, tesztelés, stb. oszlopokban és mindaddig nem kezdhet bele új task feldolgozásába a csapat, amíg fel nem szabadul egy hely.
- Legyen minden résztvevő fő célja segíteni a feladatok áramlását a folyamatban
- Kockázat és problémák
- Könnyen lehet Kanbannak látszó módszertant összerakni.
- csak szóban cél az agilitás, de a valódi változásra nincs hajlandóság.
- eredményt így nem hoz
- a sikerhez hatalmas önfegyelemre van szükség
- Könnyen lehet Kanbannak látszó módszertant összerakni.
Scrum és Kanban táblák¶
- GitLab-ban
- http://gitlab-okt.sed.hu/root/test/boards
- Cetlik azonosak az issue-kkal
- Oszlopok részhalmaza az issue címkéknek
- Új oszlop létrehozása: új címke
- Címkék (oszlopok) közti mozgatás automatikusan naplózásra kerül
- Drag-n-dorp oszlopok közti mozgatás
- Kanban: nincs automatikus WIP limit ellenőrzés
Scrum és Kanban összehasonlítása¶
A SCRUM fix időtartamú Sprintekre bontott, egy Sprint érintetlen. Azaz a Sprint kezdetét követően a PO-nak nincs módja a Sprint munkájába beleszólni, kivéve rendkívül sürgős eseteket. Ezzel szemben a KANBAN a feladatok számát korlátozza. A SCRUM definiál szerepköröket, amely a KANBAN-ban nem létezik. A KANBAN-ban csak a fejlesztő csapat van (illetőleg a PO, de ő nem része a csapatnak). A SCRUM definiál kötelező formai elemeket, mint például a napi meeting, vagy a Sprint tervezés, ilyen elemek a KANBAN-ban nincsenek. Az ismertetett elemeket (burndown chart, SCRUM/KANBAN tábla, user story) mindkét módszertan használja.
Az, hogy melyik módszertan alkalmazható egy adott fejlesztéshez, sok tényezőtől függ. Egyrészt a SCRUM megköveteli a napi szintű, preferált személyes találkozókat. A földrajzilag diverzifikált fejlesztések esetében így csak nagyon korlátozottan alkalmazható. Mindazonáltal, ha a megrendelő számára fontos a rendszeres kontroll, a prioritások dinamikus meghatározása, úgy a KANBAN alkalmazása sem javasolt, ez a módszertan csak a feladatok számában nyújt kontroll lehetőséget. A módszertan kiválasztásánál ezért rendkívül fontos a fejlesztői csapat és az adott feladat jellemzőinek együttes értékelése, valamint a megrendelői elvárások figyelembe vétele. Sokszor nem alkalmazzák tisztán egyik módszertant sem, hanem egy hibrid megoldás (SCRUMBAN) kerül kidolgozásra, amely a feladatnak megfelelően alkalmaz elemeket a két ismertetett módszertan repertoárjából.
Demonstráció¶
Az órához kapcsolódó projekt demonstrációs feladat itt érhető el.
Feladat¶
- Ismerjük meg a félév során fejlesztendő rendszerünket!
- Gondoljuk át, milyen módszertan mentén kívánjuk a fejlesztést végezni!
- Hozzunk létre csapatonként egy projektet! (gyakorlatonként egy lesz, a gyakorlatvezető hozza létre)
- Adjuk hozzá a csapattagokat! (a gyakorlatvezető végzi el)
- Készítsük el a fejlesztést támogató KANBAN táblát, definiáljuk a fejlesztés fázisait!
- Hozzuk létre a példa feladathoz tartozó issue-t. (gyakorlatvezető végzi)
- Tervezzük meg az első sprint-et (mérföldkövek)!
- Van-e szükség szétbontani az issue-t kisebb elemekre?
- Gondoljuk végig milyen hasonló feladatok lehetnek még?