Agilis módszertan összefoglaló nem csak IT-soknak

Mi is az agilis projekt, mit is jelent egyáltalán az agilis fejlesztés?
Ma már egyre többen érdeklődnek az agilis projektmenedzsmentről.
Az agilitásról készült egy-egy összefoglaló írás azok számára, akik most ismerkednek az agilis projektmenedzsmenttel.

Agilis = gyors és hatékony

Már az IT-n kívül más iparágakban is kezd elterjedni az agilitás.
Ez egy, a témát átfogó írás, ami segít megismerkedni az egyik keretrendszerrel, azonban előtte az alapelveket hasznos megérteni.

Az agilitás használható más iparágakban is, mert található az agilis kiáltvány alkotóelemeiben olyan pont, ami más iparágban alkalmazható, azonban ehhez mélyebben meg kell érteni az egész filozófiát.
A módszerek helyett fontosabb az agilis kiáltványon többször átrágnia magát annak, aki ismerkedik vele és átgondolni, hogy az ő iparágában melyik pont használható.

Az oldal egyik fő célja megvizsgálni, hogy más iparágakban hogyan lehetne használni az agilitást. Erről készül folyamatosan több írás, azonban először az alapelveket érdemes megérteni.

Minden fontos és lényeges tudnivaló össze lett foglalva és ábrákkal szemléltetve.
Ha jobban elszeretnél mélyedni az agilitás világában, akkor nézz be a blogbejegyzések között az agilitás kategóriába!

Melyik szakmából olvasod a bejegyzést?

A bejegyzésben az alábbi témák találhatók:

Bevezetés az agilitásba
Az agilis projektszemlélet kialakulása

A szoftverfejlesztők a vízesés módszer helyet egy rugalmasabb fejlesztési módszert szerettek volna használni. Az ok az volt, hogy a technológia rohamosan fejlődött és a vízeséses módszerrel a gyorsan növekvő és komplexebb igényeket kielégítő hagyományos módszer nem működött. Sokszor csúszások és költségnövekedés volt a jellemző.
Az 1990-es évektől kezdődött el az agilis szemlélet kialakulása, azonban az első agilis szoftverfejlesztés gyökerei az 1990-es évek közepére nyúlnak vissza, amikor is 1995-ben megalakult a Scrum.
2001-ben 17 szoftverfejlesztő lefektette a legfőbb alapelveket az agilis fejlesztés szempontjából, az Agilis Manifestot, azaz az Agilis kiáltványt.

Aki most ismerkedik az agilitással, hasznos az alkotó elveken átrágnia magát akár többször is! Legfontosabb: megérteni az alapelveket!

A Te iparágadban hogyan lehetne használni ezeket az alapelveket?
Például egy hardware fejlesztése esetén mennyire változhatnak a fejlesztés vége felé a követelmények?
Mennyire gyakran tudsz működő terméket, hardwaret szállítani?
Milyen mértékben működhetnek a leírt pontok marketing esetén? Vagy egy kkv esetén?

Az egész összefoglalóból ezt a részt a legfontosabb tudomásul venni, mert erre épül az egész agilitás, ettől gyorsabb és hatékonyabb az egész filozófia.

Az agilitás csak segítség a cégeknek, nem megoldás. Ha eddig is nehezen haladtak a dolgok, ezzel a módszerrel sem fog könnyebben menni.

Az agilis projektmenedzsment jelentése

Az agilis gondolkodásmód négy fő érték alapján nyugszik.
(Nem keverendő össze a Scrummal! A Scrum egy módszertan, aminek kialakult folyamata van.)
A gondolkodásmódot az agilis kiáltvány foglalja össze.
A lényege, hogy a négy fő alapelve mentén kerüljön a projekt megvalósításra, azonban a hagyományos projektvezetési módszereket sem szabad teljesen mellőzni.

Az Agilis Manifesto négy értéke, ami az agilitást jelenti
Az Agilis Manifesto négy értéke, ami az agilitást jelenti

„Azaz annak ellenére, hogy a jobb oldalon szereplő tételek is értékkel bírnak, mi többre tartjuk a bal oldalon feltüntetetteket.” – így szól az agilis kiáltvány.

A négy pont kifejtve az agilis Manifestoból

Első pont
Nem azt jelenti, hogy a módszereket és az eszközöket el kell felejteni, hanem hogy a személyes beszélgetés, kapcsolat sokkal többet segít, mint a személytelen üzenet vagy dokumentumkitöltés és küldés.

Második pont
A régi fejlesztési módszer során kiterjedt dokumentumokat kellett elkészíteni a tesztelés előtt, azonban egy működő szoftver fontosabb a dokumentumnál. A dokumentumokat később is el lehet készíteni.

Harmadik pont
Természetesen szerződésre szükség van, azonban az még a fejlesztés során a megrendelő igényei szerint kéz a kézben egyeztethetők, a merev szerződésre mutogatással szemben. A csapatoknak együtt kell működnie a megrendelővel!

Negyedik pont
Semmi sem működik mindig a terv alapján. Ahelyett, hogy a nem működő terv bármi áron is követésre kerüljön, hasznosabb, ha a terv inkább kisebb módosításokon megy keresztül és az kerül követésre.

A te iparágadban hogyan tud érvényesülni a négy pont?

Az Agilis kiáltványt alkotó elvek

Az agilis kiáltványt alkotó 12 elve
Az agilitás legfontosabb elsajátítanivalója, az alkotók 12 alapelve.

Hagyományos és agilis módszertankülönbség

A hagyományos projekt során először jellegzetesen a projekt terjedelme állandó, és az idő és a költség vizsgálatára kerül sor.
Az agilis szemléletnél a projekt terjedelme, és a követelmények lehetnek a változók. Egy előre meghatározott idő és költségkereten belül, az idő és a költség állandónak tekinthető, azonban kisebb módosítások lehetségesek – a lehető legtöbb legyen leszállítva a megrendelő számára.

Hagyományos vs agilis projektháromszög
Hagyományos vs agilis projektháromszög

A megrendelő  minél rövidebb idő alatt, minél olcsóbban egyre többet szeretne kapni, miközben
rugalmasabban módosíthatja az elképzeléseit a hagyományos projektszemlélettel szemben.

Az agilitás egyik alapvető célja az ügyfél elégedettsége a folyamatos és a gyakori visszajelzésen keresztül, ami együttműködve történik a megrendelő és szállító között, úgy, hogy a felmerülő igényekre, változásra gyorsan reagáljon a projekt.

Hagyományos vs agilis projekt négy pontjának összehasonlítása
Hagyományos vs agilis projekt négy pontjának összehasonlítása
Vízesés projekt és agilis projekt
Hagyományos vs agilis módszertan időbeli szakaszai. Az agilis módszer több, sok kicsi vízesés projektre bontott szakaszból áll.

Az agilis fejlesztés előnyei

Előnyei az agilis fejlesztésnek
Az agilis fejlesztés előnyei

Megrendelőorientált, mert lehet, hogy a piaci igények változtak és a megrendelő ahhoz mérten szeretné igazítani a projektet. Ezáltal flexibilisen módosíthatja a megrendelt terméket az idő és költségek figyelembevétele mellett.

Vegyük például a kommunikációt! A hagyományos fejlesztés esetén az ügyfél elmondta, hogy mi az elvárása a termékkel kapcsolatban, megírásra került a specifikáció. Egy év múlva amikor újra ránézett, vagy elkészült a projekt, nem azt kapta, ami az elképzelése volt. Ezért fontos a gyakori kommunikáció az agilis szemléletben, mert így gyakran egyeztetésre kerül, hogy a megrendelő mit is szeretne.

A hagyományos projektek esetén olyan nagy volt a csapat, hogy nehéz volt összefogni a csapat működését és nem is funkcionált igazi csapatként. Az agilis szemlélet esetében a fejlesztői csapatok sok kisebb csapatból állnak.

Gyakori ellenőrzési pontok által a megrendelő gyakran visszajelzést tud adni, hogy tényleg az elképzelése valósul meg, amit szeretne.

Teljesen áttekinthető, mivel a megrendelő igényei le vannak bontva, és priorizálásra kerülnek.

Agilitás egy filozófia, a Scrum egy módszer

Sokszor a két megnevezés egyszerre kerül használatra, azonban két különböző dolgot jelent.
Agilis szó filozófiát jelent, ami négy fő érték alapján nyugszik. A Scrum egy módszer.
Az agilis filozófia alapjain nyugszik a Scrum módszer, és minden megvalósítás az agilis filozófia szerint történik.

Az agilis módszer előbb teljesít, gyakran szállít, a célokat mindig újraértékeli, és mindig megerősíti az elégedettséget a hagyományos projektszemléttel szemben.

Előzetesen itt is van egy ajánlat adási és tervezési fázisa, azonban ez rugalmasabb, mint egy hagyományos projekt esetében. Utána a termék a sprintek által gyakori felülvizsgálaton és sok kisebb fejlesztési lépcsőn halad keresztül.

Agilis projektmenedzsement folyamata
Agilis projektmenedzsment folyamata

Scrum módszer

A Scrum egy keretrendszer. Talán ez a legismertebb azok számára, akik most ismerkednek az agilis projektszemlélettel.
A Scrum az iteratív fejlesztés módszere, ahol adott időközönkénti sprintekben (2-4 hét között) mindig elkészítésre kerül a kijelölt feladatmennyiség a csapat által.
A sprint egy kisebb alprojekt lefutása a projektben.
A sprint alatt a tervezés, fejlesztés és tesztelési fázis megy végbe a folyamat során. Miután egy sprint elkészült, kezdődik a következő sprint új feladatokkal.

A Scrum eszköztára:

  • Szerepkörök
    • Product Owner(PO)
    • Scrum Master
    • Csapat
  • Ceremóniák (megbeszélések)
    • Sprinttervezés
    • Sprint (2-4 hétig tartó fejlesztési szakasz)
    • Daily Scrum vagy más néven Daily Stand up
    • Sprint review/Demo (megrendelővel együtt a teszt)
    • Sprint retrospective (visszatekintő)
  • Scrum Artifact
    • Product Backlog
    • Sprint Backlog

Scrum módszer

Scrum módszer
Scrum módszer

Az érdekelt felek összegyűjtik, hogy milyen jellemzőket szeretnének. Ezeket az igényeket nevezik user storynak. A user story egy egyszerű összefoglaló egy funkcióról, hogy a felhasználó (end user) mit és miért szeretne, hogy belekerüljön a szoftverbe. Például: Én mint regisztráló, azt szeretném, hogy ha belépés, akkor mindig vigyen a kedvencek oldalra a belépés után. Ezeket a kívánságokat, igényeket felméri, egyezteti a Product owner és összegyűjti a Product backlogba, mondhatni a kívánságlistába. A product backlog egy lista, a végső terméknek rendelkeznie kell vele. Egy Sprinttervezési meeting keretében minden feladatot priorizálnak és súlyoznak, valamint igény és fontosság szerint sorba rendeznek. Először is a legfontosabb elemek kerülnek kiválasztásra, amik bekerülnek a Sprint backlog hátralék listába. Ez a lista lesz a Sprint alapja, aminek elvégzésére 2-4 hét közötti időt szoktak megadni. A sprintek mindig azonos időtartamúak. Minden egyes Sprint végén teljesen tesztelt és működőképes programrészletnek kell elkészülni. A sprintek úgy lettek tervez, hogy teljesíthetők legyenek a szakaszok és közben ne léphessen fel módosítás. Például az első sprintben a zenelejátszó felület kerül kialakításra. Utána az, hogy hogyan lehet a zenéket megvásárolni.

A Sprintek minden nap Daily Scrumból állnak. Ezt még nevezik Stand up meetingnek is. A Daily scrum és a Stand up meeting között semmi különbség nincs. Ugyanaz, csak van aki másként nevezi. Ezen a megbeszélésen a Scrum Master is részt vesz, de nem ő vezeti, hanem a csapat önszerveződő módon, aktívan, irányítás nélkül végzi. Ennek a megbeszélésnek az a lényege, hogy a csapattagok elmondják mit végeztek el az előző meeting óta, és milyen akadályok vannak, amiket meg kell oldani, továbbá mit fognak csinálni aznap. A beszélgetés lényege, hogy szinkronizálja a csapatot és a csapat munkáját. A napi Stand up megbeszélés nem lehet hosszabb, mint 15 perc.

Ha egy sprint befejeződött, akkor Sprint review, másként ahogy nevezik Sprint Demora kerül sor, ahol az érdekelt felekkel együtt áttekintésre kerül az adott fejlesztési szakasz.

Ezt követően még van egy lépcső, amit Sprint retrospective, azaz visszatekintő megbeszélésnek neveznek, ahol áttekintik a csapattatok, hogy mi ment jól az adott sprintben, vagy mit kell javítani a következő sprintben.

Csapattagok

Product owner – A termék „szakértője”, aki képviseli az érintetteket, és az ügyfél hangja. Azért felel, hogy a megfelelő funkció kerüljön a Product backlogba. Ő felel a termék fejlesztési irányáért.
Scrum Master – Felelős, hogy a projekt gördülékenyen haladjon előre. Feladata: megbeszélések szervezése, vezetése, munka monitorozása. Mondhatni projektvezető, azonban a Scrumban Scrum Master a megnevezése.
És a fejlesztő csapat –Fejlesztők, tesztelők.

Scrum ceremóniák

Sprint: 2-4 hétig tartó fejlesztési szakasz. Nevezhető alprojekteknek is a projektben. A sprintek szakaszainak mindig azonosnak kell lennie.
Sprinttervezés: A csapat összeül minden sprint elején és megtervezi, hogy mi kerül be a következő sprintbe. Ami bekerült a sprintbe azon a következő sprintig nem lehet változtatni.
Daily Scrum/Napi Stand up: 15 perces napi megbeszélés, minden nap, azonos időben a sprint alatt. Az előző napi tevékenységek, és az aznapi célok kerülnek gyorsan elmondásra a csapattagok által, illetve a blokkoló tényezők. Három kérdés merül fel, ami egy normál projekt alatt is sokat segíthet:

  • Mit csináltál az utolsó megbeszélés óta?
  • Mit fogsz csinálni a következő megbeszélésig?
  • Mi az, ami hátráltat a munkában?

Sprint review/Demo: Minden sprint végén a csapat bemutatja az érdekelt feleknek, hogy mi készült el az adott sprintben.
Sprint retrospective: Ezen a megbeszélésen a csapat értékeli az adott sprintnek a folyamatát, hogy mi ment jól, mi nem és mit kell javítani a következő megbeszélésre.

Scrum Artifact

Ezt a Scrum Artifact szót úgy lehet megfogalmazni magyarul a Scrumban, hogy változtatható, kiigazítható munkaanyagok. Úgy írható körbe, hogy egy lehetőség, ahol a termékfunkciónak áttekintésére és kiválasztására kerül sor.

Product backlog a Product owner által vezetett lista, ami tartalmazza az összes szükséges funkciókat, követelményeket, amit a termékben a jövő során fejleszteni kell. Sohasem végleges a lista. Dinamikusan változik, mivel az érdekekelt felekkel együtt kerül egyeztetésre. Product owner feladata, hogy prioritás szerint össze legyen rendezve a lista, ami egyeztetve lett előzetesen.

A Product backlogból kialakul a Sprint backlog lista. A sprinttervezési meeeting keretében a csapat közösen kiválasztja, hogy mennyi feladatot tudnak a következő sprintben elvégezni. A kiválasztott elemeket a sprintben mind teljesíteni kell. A listában lévő elemek kerülnek a napi Stand up keretében megbeszélésre, hogy hogyan alakul a fejlesztés

Egyéb fejlesztési módszerek

Természetesen léteznek egyéb fejlesztési módszerek a Scrumon kívül, azonban ez a módszer a legismertebb sokak számára, akik most kezdenek az agilitással foglalkozni.

Nézzünk gyorsan egy megfogható példát az IT-n kivül, ahol fajátékokat fejlesztenek!

Egy lehetséges fejlesztési megoldás lehetne, hogy egy üzletben egy gyereksarkot hoznak létre, ahol megfigyelhetik, hogy a gyerekek melyik fajátékkal játszanak és hogyan. Ha valami új ötlet születik, vagy valami eltörik, akkor azt egy új prototípusban lehet gyártani és oda lehet adni tesztelésre. Közben a fenti Scrum módszerrel egy folyamatos termékfejlesztést lehet kialakítani.

HOZZÁSZÓLOK A CIKKHEZ

Please enter your comment!
Please enter your name here