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 agilistá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, amit segít megismerkedni az egyik keretrendszerrel, azonban előtte az alapeveket hasznos megérteni.

Az agilitás használható más iparágakban is, mert található az agilis kiáltványban 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 hasznos 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 blog bejegyzések között az agilitás kategóriába.

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

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ég nö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 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! Legfontosabb az alapelveket megérteni!

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?
Mennyire 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 legfontosabb megérteni, mert erre épül az egész agilitás, hogy 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 Srum 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 mellőzni teljesen.

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 dokumentum kitöltés és küldés.

Második pont
A régi fejlesztése 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 ellehet 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ővel igényei kéz a kézben egyeztethetőek, a merev mindig a szerződésre mutogatással szemben. A csapatoknak a megrendelőnek együtt kell működnie.

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 kersztü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ítani valója, az alkotók 12 alapelve

Hagyományos és agilis módszertan kü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 személetnél a projekt terjedeleme, 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 modósí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 projekt háromszög

A megrendelő  minnél rövidebb idő alatt, minnél olcsóbban egyre többet szeretne kapni, miközben
rugalmassabban modósíthatja az elképzeléseit a hagyományos projekt szemé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

Előnyei az agilis fejlesztésnek

Előnyei az agilis fejlesztésnek
Előnyei az agilis fejlesztésnek

Megrendelő orientált, mert lehet, hogy a piaci igények változtak és a megrendelő ahhoz mérten szeretné igazi a projektet. Ezáltal flexibilisan 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 kapcsoltban, 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 működött 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 az 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 filózófia alapjain nyugszik a Scrum módszer és minden megvalósítás az agilis filozófia alapján 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 projekt szemléttel szemben.

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

Agilis projektmenedzsement folyamata
Agilis projektmenedzsement folyamata

Scrum módszer

A Scrum egy keretrendszer. Talán ez a legismertebb azok számára, akik most ismerkednek az agilis projektszemlélettel.
Scrum az iteratív fejlesztés módszere, ahol adott időközömkénti sprintekben (2-4 hét között) mindig elkészítésre kerül a kijelölt feladat mennyisé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)
    • Sprint tervezé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ág listába. A product backlog egy lista, aminek a végső terméknek rendelkeznie kell. Egy Sprint tervezési meeting keretében minden feladatot priorizálnak és súlyoznak és sorba rendeznek. A 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őtartalmúak. Minden egyes Sprint végén, teljesen tesztelt és müködőképes program részletnek kell elkészülni az adott feature-ből. Például az először az első sprintben a zenelejátszó felület kerül kialakításra. Utána, hogy hogyan lehet a zenéket megvásárolni.

A Sprintek minden nap Daily Scrumbol á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. Ugyan az, csak van aki másként nevezi. Ezt a megbeszélést a Scrum Master vezeti. A napi Stand up megbeszélés nem lehet hosszabb mint 15 perc. Ennek a megbeszélésnek az a lényege, hogy a csaptagok elmondják mit végeztek el az előző megbeszélés óta, és milyen akadályok vannak, amiket meg kell oldani és mit fognak csinálni aznap. Ennek a meetingnek a lényege, hogy szinkronizálja a csapatot.

Ha egy sprintek 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ése szakasz.

Ezután még van egy lépcső, amit Sprint retrospective, azaz visszatekintő megbeszélésnek neveznek, ahol annak áttekintésére kerül sor, 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 Mater – 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 neve.
És a fejlesztő csapat –Fejlesztők, tesztelők.

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

Scrum ceremóniák

Sprint: 2-4 hétig tartó fejlesztési szakasz.  Nevezhető alprojekteknek a projektben. A sprintek szakaszai mindig azonosnak kell kell lennie.
Sprint tervezés: A csapat összeül minden sprint elején és megtervezi, hogy mi került 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ékenyéségek, és az aznapi célok kerülnek gyorsan elmondásra a csapattagok által és a blokkoló tényezők. Három kérdés amit kérdeznek, 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ék funkciónak áttekintésére és kiválasztására kerül sor.
Product backlog a product owner által vezetett lista, ami tartalmazza az össze szükséges funkciókat, követelményeket, amit a termékben a jövőben fejleszteni vagy módosítani kell. Sohasem végleges a lista. Dinamikusan változik, mivel a stakeholderekkel együtt kerül egyeztetésre. Product owner feladat, hogy prioritás szerint össze legyen rendez a lista.
A Product backlogból kialakul a Sprint backlog lista. A sprint tervezé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 standup 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 keresztül, ahol fa játékokat fejlesztenek

Egy lehetséges fejlesztési megoldási lehetne, hogy egy üzletben egy gyereksarkot hoznak létre, ahol megfigyelhetik, hogy a gyerekek melyik fa já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 szervezet?
Mindennek megvan a tanulási görbéje, az agilitásnak is. Hasznos egy külsős szakértő bevonása vagy valaki olyat bevonni a transzformációba, 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-ban 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 keretrendszer 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 összefoglaló

Minden itt leírt információ csak elmélet. Egy agilis folyamat bevezetéshez külsős szakemberek segítségére van szükség.
A szoftver fejlesztésben már régóta használják az agilistást. Például az autó fejlesztésben, banki szektorban, marketingben mindig az adott cégre kell szabni az agilitást, amennyiben a cég vezetése is elkötelezett a bevezetése mellett.