A vízesés modell vagy PPP szemlélet lényege a munkafolyamatok fázisokra bontása, ezért is használják rá a PPP ( phased product planning) és alapvetően a tervezés
fontossága fókuszál.
fontossága fókuszál.
Az agilis modellt ezzel szemben arra szemléletmódra használjuk, amely az egyénekbe és a csapatba vetett bizalomra épül, elfogadja a fejlesztési folyamatokban lévő bizonytalanságot és ezért ciklikus fejlesztési megközelítést javasol.
12 alapelv (http://agilealliance.hu/materials/documents/agilemanifesto.pdf):
1) Legfontosabbnak azt tartjuk, hogy a vevőnk elégedett legyen, mert értékes szoftvert szállítunk neki hamar és folyamatosan.
2) Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis módszertanok befogadják a változást a megrendelő versenyképességének érdekében.
3) Gyakran szállítsunk működő szoftvert, pár hetes és hónapos időközönként, lehetőleg a rövidebb periódust választva.
4) A megrendelők, üzleti szakemberek és a szoftverfejlesztők dolgozzanak együtt minden nap a teljes projekt során.
5) Építsük motivált egyénekre a projekteket. Teremtsük meg nekik a számukra szükséges környezetet és támogatást, és bízzunk bennük, hogy elvégzik a munkát.
6) A személyes beszélgetés az információ átadásának leghatásosabb és hatékonyabb módja a fejlesztő csapaton belül.
7) Az előrehaladás elsődleges mércéje a működő szoftver.
8) Az agilis módszertanok elősegítik a fenntartható fejlesztést. A szponzoroknak, fejlesztőknek, felhasználóknak korlátlan ideig képesnek kell lenniük az egyenletes sebesség megőrzésére.
9) A folyamatos figyelem a technikai kiválóságra és a jó tervezésre fokozza az agilitást.
10) Az egyszerűség – az el nem végzett munkamennyiség maximalizálásának művészete – alapvető érték.
11) A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatmunkából alakulnak ki.
12) A fejlesztői csapat rendszeres időközönként megfontolja, hogyan válhatna hatékonyabbá és ennek megfelelően változtatja viselkedését.
2) Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis módszertanok befogadják a változást a megrendelő versenyképességének érdekében.
3) Gyakran szállítsunk működő szoftvert, pár hetes és hónapos időközönként, lehetőleg a rövidebb periódust választva.
4) A megrendelők, üzleti szakemberek és a szoftverfejlesztők dolgozzanak együtt minden nap a teljes projekt során.
5) Építsük motivált egyénekre a projekteket. Teremtsük meg nekik a számukra szükséges környezetet és támogatást, és bízzunk bennük, hogy elvégzik a munkát.
6) A személyes beszélgetés az információ átadásának leghatásosabb és hatékonyabb módja a fejlesztő csapaton belül.
7) Az előrehaladás elsődleges mércéje a működő szoftver.
8) Az agilis módszertanok elősegítik a fenntartható fejlesztést. A szponzoroknak, fejlesztőknek, felhasználóknak korlátlan ideig képesnek kell lenniük az egyenletes sebesség megőrzésére.
9) A folyamatos figyelem a technikai kiválóságra és a jó tervezésre fokozza az agilitást.
10) Az egyszerűség – az el nem végzett munkamennyiség maximalizálásának művészete – alapvető érték.
11) A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatmunkából alakulnak ki.
12) A fejlesztői csapat rendszeres időközönként megfontolja, hogyan válhatna hatékonyabbá és ennek megfelelően változtatja viselkedését.
Ennek az értékrendszernek a lényege:
- a gyorsaság,
- a változásra való reagálási képesség,
- az egyének és a csapat képességeibe és motivációjába vetett bizalom,
- a működő terméknek, mint a siker egyetlen mércéjének elismerése.
Az agilis szemlélet nem más, mint a értékrendbeli hangsúlyok erős kijelölése, megváltoztatása.
A project hatékony lesz, addig az agilis szemlélet abból indul ki, hogy ha a megfelelő emberekből összeállított team elé világos célokat tűzünk ki,
és világos kereteket jelölünk ki számukra, akkor azok hatékony eljárásokat, szabályokat és szervezeti felépítést fognak kialakítani.
és világos kereteket jelölünk ki számukra, akkor azok hatékony eljárásokat, szabályokat és szervezeti felépítést fognak kialakítani.
Nincs projekt változás nélkül, nincs szoftverfejlesztés változáskérelem nélkül.
Scrum módszer:
Szervezet:
SAFe : Scaled Agile Framework
A SAFe a legismertebb skálázási keretrendszer, melynek legfőbb célja, hogy a vállalat szerkezete, folyamatai és kultúrája minden esetben az adott időszak stratégiájának mentén működjenek, biztosítva az állandó változtatási képességet az ügyféligény kiszolgálása érdekében.
A korábban elszigetelten működő szervezetek működését, hatékonyságát és eszközrendszerét formálja át, hogy a közös cél mentén rangsorolni tudják az elvárásokat, terveket, és ennek megfelelően allokálja az erőforrásokat a vállalat teljes egésze.
Alapértékek
- Igazítás: jól követi a gyors változásokat, hogyan működjenek együtt a területek, hogy elérjék a közös célokat.
- Beépített minőség: minden megoldás megfelel az egységes minőségnek, 5 kulcsminőség van a SAFe-ben, úgy mint: architektúrális minőség, kódminőség, dizájnminőség, rendszerminőség, release minőség.
- Transzparencia: nagyon fontos a nyitottság, illetve a bizalom kiépítése, a kis csapatokban való tervezésnél hamarabb jut felszínre egy-egy probléma és ezért hamarabb is lehet őket megoldani.
- Program Kivitelezés: a SAFe lelke, folyamatos értékszállítás a cél, a csapatok és programok rendszeresen szállítanak üzleti értéket és minőségi, működő szoftvert.
4 rétű hierarchia
- Epic: nagy mennyiségű munka amit kisebb, jobban megfogalmazott feladatokra lehet bontani, ez egy konténer a magasszintű megoldás iniciatíváknak. Többféle Epic van többféle szinten.
- Képességek (Capabilities): magasszintű megoldási képesség, ami megosztott a többféle funkciók között.
- Funkció: egy darab funkció ami egy ART-ban kerül leszállításra, és kielégíti a stakeholder szükségletét, egy üzleti érték leszállításával (egy iteráción belül), ezeket sztorikra bontjuk.
- Sztori: rövid leírása a kívánt funkció egy kis darabjának, ami a felhasználó nyelvén íródott.
A Rendszerszervező feladatai, felelősségei:
A rendszerszervező támogatja a Product Owner-t az üzleti igények kidolgozásában, User Story szintre történő lebontásukban.
A Storyban meghatározott feladatokhoz megadja a szükséges információkat és (szükség esetén az üzemeltetés bevonásával) meghatározza a nem funkcionális követelményeket.
Felméri a rendszerek közötti kapcsolatokat és szükség esetén bevonja az Architektet és más IT területeket.
A Product Owner-el közösen gondoskodik arról, hogy az adott sprintben tervezett elem tartalmazza a párhuzamosan folyó egyéb banki fejlesztések által igényelt funkciókat.
Elvégzi a kompetenciájába tartozó környezetvalidációs és paraméterezési feladatokat.
Tesztelés során elvégezheti a smoke/funkcionális teszteket és a nem funkcionális tesztekhez szükséges rendszerszervezői feladatokat.
Beszállító bevonása esetén kezeli a beszállító szintű erőforrás allokációs kérdéseket és elszámolásokat.
A Rendszerszervező részvételét az agilis eseményeken az határozza meg, hogy milyen mértékben kerül hozzárendelésre az adott csapathoz a teljes munkaideje:
Amennyiben a munkaidejének legalább a 80% egy adott agilis csapathoz kerül hozzárendelésre, úgy a csapat szerves részeként minden eseményen részt vesz.
Amennyiben ennél kevesebb mértékben vesz részt a csapat munkájában, úgy javasoljuk, hogy a Sprint tervezésen és a Sprint Review megbeszélésen vegyen részt.
A Story-k méretezésénél fontos szempont, hogy egy adott Story-t a csapat egy sprint alatt le kell hogy tudja szállítani. Ideális méretezés esetén egy 6-8 tagú csapat egy sprint alatt minimum 6-8 Story-t szállít le. Az egyes Story-k méretét, komplexitását a csapat becsüli meg, a Product Backlog Refinement vagy a Sprint tervezés során.
Amennyiben a Story túl nagy, túl összetett vagy túl sok a bizonytalanság körülötte és ezért a csapat valószínűleg nem tudja egy sprint alatt leszállítani, akkor a Product Owner feladata a kisebb darabokra bontás. Ehhez támogatást nyújthat a szűkebb-tágabb csapat (pl. rendszerszervező, teszt menedzser).
A Story-k további bontásának különböző technikái vannak, melyek szempontokat adnak a Product Owner számára, hogy milyen irányból közelítse meg a darabolási feladatot.
A Scrum póker a csapatot abban támogatja, hogy egy nem pontosan ismert Story méretéről, komplexitásáról relatív becslést tudjon adni, mely támogatja a Product Ownert az adott Story Backlogban történő elhelyezésében, illetve támogatja a csapatot sprintben elvégzendő feladatok vállalásában.
A Scrum póker (planning poker) egy közös megállapodáson alapuló játékosított technika. Főként az erőfeszítés mértékének illetve a feladatok egymáshoz képesti (relatív) méretének becslésére szolgál. A Scrum Master segítségével a sprint tervezésénél, vagy Product Backlog Refinement-nél a csoport tagjai kezdetben egymás számára nem látható becsléseket készítenek, majd a becsléseket egymással megosztják és megvitatják az eltéréseket. A beszélgetés utáni újabb becslési körrel megvizsgálják, hogy közelebb kerültek-e az álláspontok és a beszélgetés-újrabecslés-megosztás lépések szükséges és racionális ismétlésével jutnak el a megállapodásig. A módszer segít a csapat összes tagjának részt venni a becslésben, hatékonyan korrigálja a túlzott becsléseket és a megbeszélések révén erősíti a csapat együttműködését.
A Scrum pókerhez használhatóak kártyák, alkalmazások vagy home office esetén online honlapok, pl. pointingpoker.com
A Story-k méretezésénél fontos szempont, hogy egy adott Story-t a csapat egy sprint alatt le kell hogy tudja szállítani. Ideális méretezés esetén egy 6-8 tagú csapat egy sprint alatt minimum 6-8 Story-t szállít le. Az egyes Story-k méretét, komplexitását a csapat becsüli meg, a Product Backlog Refinement vagy a Sprint tervezés során.
Amennyiben a Story túl nagy, túl összetett vagy túl sok a bizonytalanság körülötte és ezért a csapat valószínűleg nem tudja egy sprint alatt leszállítani, akkor a Product Owner feladata a kisebb darabokra bontás. Ehhez támogatást nyújthat a szűkebb-tágabb csapat (pl. rendszerszervező, teszt menedzser).
A Story-k további bontásának különböző technikái vannak, melyek szempontokat adnak a Product Owner számára, hogy milyen irányból közelítse meg a darabolási feladatot.
Megjegyzések
Megjegyzés küldése