Kihagyás

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
    1. Költségvetés,
    2. határidő,
    3. specifikáció
    4. 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

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
    • 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
      • As a [end user role], I want [the desire] so that [the rationale].
      • Epic, story, task
    • Prioritási sor, a fontosabb feladatok jobban kidolgozottak
    • 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

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
  • Napi Scrum
    • 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
    • A gyakorlaton ez a bemutatók lesznek discordon
  • Sprint visszatekintés
    • A csapat kiértékelése, fejlesztési lehetőségek keresése 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
    • 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

Feladat

  • juttassunk el egy sportkocsit a Marsra
  • Hozzunk létre csapatonként egy projektet
  • Adjuk hozzá a csapat tagokat
  • Hozzuk létre a szükséges feladatokhoz egy-egy issue-t
  • Scrum: tervezzük meg az első sprint-et (mérföldkövek)
  • Kanban: kezdjük el az első feladatot

Utolsó frissítés: 2021-02-26 10:53:44