Mi az agilis módszertan? Legelterjedtebb agilis módszertanok
Az agilitás egy mindset, egy gondolkodásmód, amely a szervezetek életében több módon is megjelenhet. Az agilis gondolkodás mentén éppen ezért ma már számos agilis módszertan alakult ki: a szervezetnek így lehetősége van kiválasztani, melyik a legmegfelelőbb számára. Sőt ma egyre gyakrabban találkozni hibrid, az adott szervezet igényeire szabott megoldásokkal.
Az agilis projektmenedzsment alapelveiről már írtunk egy részletes cikket, aki csak most ismerkedik az agilitással, annak mindenképp ajánlott ezzel kezdeni. Ebben az írásban kifejezetten az agilis módszertanokra koncentrálunk.
Az agilis módszertan jelentése
Az agilis módszertan olyan gyakorlatot, munkaszervezést jelent, amely során a szoftverfejlesztés vagy egyéb projekt az agilis értékek mentén iterációkban zajlik. Az egyes iterációk során mind a fejlesztés, mind a tesztelés megvalósul, ezek a tevékenységek tehát párhuzamosak. Folyamatos a kapcsolat a termék felhasználóival, ezért sokkal gyorsabban keletkezik visszacsatolás, valamint fény derül az ügyfelek változó igényeire is. Az egyes iterációk végén a fejlesztés alatt álló termék egy működő darabja, egy működő funkcionalitás készül el.
Az agilis módszertan nem egyenlő az agilis gondolkodásmóddal: az agilis gondolkodás szülte az agilis módszertanok kialakulását, amelyekben módszertanonként eltérőek lehetnek az eszközök, ceremóniák, szerepek.
A legfontosabb agilis módszertanok
Ma már számos agilis módszertan alakult ki, ezek közül a legfontosabbak:
- Scrum
- Extreme Programming (XP)
- Crystal módszertan
- DSDM (Dynamic Software Development Method)
- FDD (Funkció Vezérelt fejlesztés)
- Kanban
- Lean szoftverfejlesztés
Scrum: a leggyakrabban használt agilis módszertan
A Scrum egy olyan agilis fejlesztési módszertan, amely kifejezetten arra koncentrál, hogy hogyan lehet feladatokat kezelni egy csapat alapú fejlesztői környezetben. A Scrum hisz abban, hogy a fejlesztői tevékenységet kis létszámú (kb 7-9 főből álló) fejlesztő csapatokban érdemes elvégezni.
A Scrum csapatok magas felhatalmazással rendelkeznek: például maguk dönthetnek a munka menetéről: arról, hogy melyik termék funkcionalitáson dolgoznak és hogyan teszik azt. A Scrum 3 fő szerepkörből áll:
- Scrum Master: a csapat felállításáért, működéséért, a munkát zavaró tényezők elhárításáért és a Scrum működéséért felel
- Product Owner: ő felel a termék értékének maximalizálásáért, a termék backlog menedzsmentjéért
- Scrum csapat: keresztfunkcionális csapat, amely a saját munkáját menedzseli és felelős minden sprint végén egy működő funkcionalitás leszállításáért
A scrum folyamat
A Scrum folyamat dióhéjban a következőképpen néz ki:
- Az egyes iterációkat sprintnek nevezik, amely alatt egy működő funkcionalitást kell leszállítani
- A termék backlog (Product Backlog) az a lista, ahová az elkészíteni kívánt termék minden részletéről bekerülnek az információk
- A product owner (terméktulajdonos) a fejlesztés során a felhasználói igényeket összegyűjti a termék backlogba, amelyből az elkészítendő elemek az egyes sprintek során átkerülnek a sprint backlogba
- A csapatok a sprint backlog alapján dolgoznak
- A csapat tagjai minden nap beszámolnak arról, hogy ki és min dolgozik egy meghatározott ceremónia keretében (Daily Scrum)
- A sprint végén a termék egy működő darabja kerül leszállításra
- A munkát pedig visszatekintő értekezleten (retrospective) értékelik
A Scrumról bővebben ebben a cikkben írtunk.
Extreme Programming (XP)
Az Extreme Programming talán az egyik legspecifikusabb keretrendszer, amelynek célja nem csak a kiváló minőségű szoftverek előállítása, hanem az egész folyamat megkönnyítése is a fejlesztő csapat számára.
A fejlesztés jellemzően 2 hetes iterációkban történik, és minden iterációban végbemegy az elkészült funkcionalitás és a teljes rendszer tesztelése is. Egy olyan ellenőrző pont is bevezetésre kerül, ahol a felhasználói igények is könnyen megvalósíthatók, így az XP rendkívül ügyfélközpontú fejlesztést tesz lehetővé. Az XP fő értékei a kommunikáció, visszacsatolás, egyszerűség, bátorság és tisztelet.
Az eXtreme programming 6 fázisa
Az XP-ben 6 fázisra bontható a fejlesztés. Lássuk, melyek ezek!
Tervezés (planning)
- Az érintettek és szponzorok azonosítása
- Infrastrukturális követelmények meghatározása
- Biztonsággal kapcsolatos információk megszerzése
- Szolgáltatásról szóló megállapodások
Elemzések (Analysis)
- Felhasználói igények (User story) rögzítése egy helyen, az úgynevezett “parkolóban” (Parking Lot)
- A Story-k priorizálása
- Az elkészülésükhöz szükséges időtartam becslése
- Az iterációk időtartamának (SPAN) meghatározása
- Erőforrás tervezés mind a fejlesztési, mind a minőségbiztosítási csapatok számára
Design
- A feladatok lebontása
- Tesztforgatókönyv elkészítése minden feladathoz
- Regressziós automatizálási keretrendszer létrehozása
Végrehajtás (Execution)
- Kódolás
- Az egységek tesztelése
- Kézi tesztforgatókönyvek végrehajtása
- Hibajelentés generálása
- Kézi regressziós tesztesetek átalakítása automatizálásra
- Iteráció közbeni áttekintés
- Iteráció végi áttekintés
Wrapping
- Kis egységek leszállítása
- Regressziós tesztelés
- Demok és ismertetők elkészítése
- Új történetek kidolgozása az igények alapján
- Folyamatfejlesztések az iteráció visszatekintés tapasztalatai alapján
Zárás (Closure)
- Pilot Launch: az elkészült termék első üzembe helyezése
- Betanítás
- Gyártás elindítása
- Garancia biztosítása
- Támogatási rendszer kialakítása
Az XP azokban az esetekben jó választás, ahol nagyon dinamikusan változnak az ügyféligények, illetve amikor nem biztosak a rendszer működőképességében.
Crystal módszertan
A crystal egy módszertan család, mely egyes elemeit úgynevezett “lightweight”, azaz könnyű agilis módszertannak is nevezik, amely elsősorban az egyénekre és interakciókra összpontosít. Főleg rövid távú projektek esetében alkalmazható, amikor a fejlesztőcsapat egyetlen munkaterületen dolgozik.
A módszertan a következő 3 fázison alapul:
Chartering
Ebben a fázisban történik a fejlesztőcsapat létrehozása, az előzetes megvalósíthatósági elemzés elkészítése, a kezdeti terv kidolgozása és a fejlesztési módszertan finomhangolása
Ciklikus szállítás (Cyclic delivery)
Ez a fő fejlesztési szakasz, amely 2 vagy több szállítási ciklusból (iterációból) áll. Ezek során a csapat:
- Frissíti vagy finomítja a tervet
- A követelményeket megvalósítja egy vagy több programteszt-integrációs iteráción keresztül
- Az elkészült termék eljut a felhasználóhoz
- Felülvizsgálják a projekttervet és az elfogadott fejlesztési módszertant
Wrap up
Ebben a fázisban történik meg az élesítés, azaz a felhasználói környezetben történő üzembe helyezés, illetve az ezt követő felülvizsgálatok és mérlegelések.
DSDM (Dynamic Software Development Method)
A DSDM egy úgynevezett RAD (Rapid Application Development) megközelítés a szoftverfejlesztéshez, amely egy agilis projekt megvalósítási keretrendszert biztosít. Olyan szoftverprojekek állnak a fókuszában, amelyeket szűkös költségvetés és ütemterv jellemez. A DSDM legfontosabb tulajdonsága, hogy a felhasználókat nagyon aktívan be kell vonni a fejlesztés folyamatába, és a csapatok nagyon magas döntéshozatali felhatalmazást kapnak.
A DSDM 7 fázisból áll:
- Pre-Project (projekt előtti fázis)
- Megvalósíthatósági tanulmány
- Üzleti tanulmány
- Funkcionális modell iteráció
- Design és Build (Tervezés és kivitelezés) iteráció
- Implementáció
- Poszt-projekt
FDD – Funkció Vezérelt Fejlesztés (Feature Driven Development)
Az FDD más agilis módszertanokkal ellentétben nagyon rövid iterációkat és nagyon specifikus munkafázisokat ír le, amelyeket minden egyes funkció esetén külön el kell végezni. További érdekessége, hogy főként (például a Scrumhoz képest) nagyobb csapatokra alkalmazzák. A nagyobb számú emberrel végzett projektek könnyebb kezelése érdekében az FDD olyan speciális tevékenységeket is magába foglal, amelyek segítik a kommunikációs kihívások kezelését és a projekt könnyebb koordinálását.
Az FDD egy 5 lépcsőből álló folyamat, amelyből az első 3 szekvenciálisan, az utolsó kettő pedig iteratívan zajlik:
- Egy átfogó modell kifejlesztése
- A funkcionalitások listájának elkészítése
- Tervezés funkcionalitásonként
- A funkcionalitások dizájnjának elkészítése
- A funkcionalitások kódolása
Kanban módszertan
A Kanban módszer még a 2000-es évek elején jelent meg a szoftverfejlesztésben, részben válaszul a más agilis módszertanok, különösen a Scrum kihívásaira. Milyen kihívásokról van szó?
- A 2-3 hetes sprint ciklusok túl hosszúvá váltak több üzleti kontextusban is
- A szervezeti, projektmenedzsment szemléletbeli változtatások, amelyeket a módszertan igényelt túl megterhelőek voltak a szervezet számára
- Több csapat is szembesült azzal, hogy még sprint szinten sem tudják hozni a terjedelmi és minőségi kötelezettségvállalásokat
A Kanban sokkal kevésbé igényel szervezeti változásokat, a 2-3 hetes iterációkkal szemben folyamatos teljesítést és folyamatos ügyfél-visszacsatolást tesz lehetővé, így gyorsabban képes értéket szállítani a felhasználóknak.
A Kanban egy vizuális rendszer a munka irányítására, miközben az egy folyamaton keresztül halad. A Kanban magát a folyamatot és a folyamaton áthaladó tényleges munkát is megjeleníti. Célja, hogy azonosítsa az esetleges szűk keresztmetszetet a folyamatokban és ezek javításával költséghatékonyabbá, gyorsabbá tegye a munkát. A Kanban eredete egyébként a Toyota által kidolgozott JIT (Just-in-time) folyamatokban rejlik, amiben kártyák segítségével azonosították a gyártási lánc anyagszükségleteit.
A Kanban előnyeiről és hátrányairól ebben a cikkben írtunk bővebben
Lean szoftverfejlesztés
A lean szoftverfejlesztés szintén az imént említett “JIT” elven alapul. Célja a hatékonyság optimalizálása és a pazarlás vagy veszteség minimalizálása. A Lean szoftverfejlesztés az 1980-as évben indult lean menedzsment elveken alapszik, amelyről ebben a cikkben írtunk. Mára azonban már az agilis módszertanok szerves részének tekintik.
A lean szoftverfejlesztés a következő hét elvben foglalható össze:
- A veszteség minimalizálása
- A tanulás elősegítése
- A kötelezettségvállalás elhalasztása a minél későbbi döntés érdekében
- Korai szállítás
- A csapat felhatalmazása
- Integritás kialakítása
- Az egész folyamat optimalizálása
Miben tudunk mi segíteni?
Az elmúlt években agilis coach, product owner, fejlesztő és tanácsadó/tréner tapasztalattal rendelkező kollégáink több tucat agilis csapatot és szervezeti agilitás fejlesztési folyamatot támogattak.
Nem vagyunk agilis evangelisták, nem hisszük hogy mindenre az agilis irányzatok jelentenek megoldást. Hisszük, hogy ezek az eszközök segíthetnek a mindennapokban, illetve ennek a gondolkodásmódnak a napi munkába való megfelelő mértékű beépítése rövidtávú sikereket hozhat a projektek és a szervezetek számára.
Amennyiben az agilitás alapjairól, a scrum, esetleg kanban irányzatokról szeretne többet megtudni, ajánljuk agilis képzéseinket.
Designabc