Kihagyás

Agilis módszertanok

Motiváció

  1. 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.
  2. 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://www.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

Módszertanok

kep

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ő kep

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. kep

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 Wiki oldalán tesszük meg) kep
  • 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.

kep

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. kep

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

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?

Utolsó frissítés: 2022-01-25 08:09:32