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!

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 vállalkozás 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.

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 agilitás legfontosabb elsajátítani valója, az alkotók 12 alapelve
Az agilitás legfontosabb elsajátítanivalója, az 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 projekt há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
Hagyományos vs agilis projekt időbeli szakaszai
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 feature-ket is 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. 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 sorbarendeznek. Először is a legfontosabb elemek kerülnek kiválasztásra, amik bekerülnek a Sprint backlog listába. Ez a lista lesz a Sprint alapja, aminek elvégzésére 2-4 hét közötti idő áll rendelkezésre. 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 az adott feature-ből. 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. A napi Stand up megbeszélés nem lehet hosszabb, mint 15 perc. 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.

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

Továbbá vannak projektmenedzserek is, azonban az ő feladatok a Scrumban annyira nem behatárolt, de rájuk is szükség van.

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 a stakeholderekkel együtt kerül egyeztetésre. Product owner feladata, hogy prioritás szerint össze legyen rendezve a lista.

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

Gyakran felmerülő kérdések

Lehet gyorsan agilissá transzformálni egy szervezetet?
Mindennek megvan a tanulási görbéje, az agilitásnak is. Hasznos egy külsős szakértő bevonása, vagy egy olyan személyé, aki már részt vett agilis projektben és kellő tapasztalattal rendelkezik. Legjobb egy pilot projekt keretében kezdeni, ha az erőforrások engedik és a vezetők is elkötelezettek.

Csak az IT-ben működik az agilitás?
Más iparágakban is használható, de minden folyamatnak meg kell találnia a számára megfelelő agilis keretrendszert. Már a LEGO-nál is agilisan fejlesztenek. Ott például a SAFe keretrendszert használják vagy lásd az előző példát.

Ha reggel mindig 15 perces megbeszélést tartunk és sok kis részre lebontjuk a feladatokat akkor már mi is agilisan dolgozunk?
Először is meg kell határozni, hogy miért is akar egy cég agilisan működni és melyik keretrendszer lehet számára a megfelelő. Figyelembe kell venni az agilis filozófiát és valamelyik keretrendszert el kellene sajátítani.

Agilis folyamat útravaló

Minden itt leírt információ csak elmélet. Egy agilis folyamat bevezetéséhez külsős szakemberek segítségére van szükség.
A szoftverfejlesztésben már régóta használják az agilitást.

HOZZÁSZÓLOK A CIKKHEZ

Please enter your comment!
Please enter your name here