A csapata éppen hat hónapot töltött azzal, hogy pontosan azt készítse el, amit az ügyfél kért. A bemutató tökéletesen sikerül. Aztán elhangzik: „Már nincs szükségünk erre. A piac megváltozott.”
Számtalan alkalommal láttam már, hogy ez a helyzet tönkreteszi a projekteket, a költségvetéseket és a csapat morálját.
A probléma nem az, hogy a követelmények változnak. Azok mindig változnak. A probléma az, hogy olyan folyamatokat építünk ki, amelyek úgy tesznek, mintha nem változnának.
A szoftverfejlesztő csapatok egy bizonyos ponton rájöttek egy fontos dologra: mi lenne, ha nem küzdnénk a változás ellen, hanem inkább számolnánk vele?
Így válhat AI-orientált projektmenedzserré →
Az AI-alapú projektmenedzsment kézikönyvben a következőket találja:
- 5 azonnal használható mesterséges intelligencia-rendszer a heti projektmunkádhoz
- 30 ügynök a projekt kezdetétől a lezárásig
- Valódi, több szereplőt bevonó munkafolyamatok, amelyek segítenek a sajátja megtervezésében.
Ez a gondolkodásbeli változás hozta létre az agilis projektmenedzsmentet.
Főbb tanulságok
- Az agilis menedzsment iteratív, rövid fejlesztési ciklusok révén teremt értéket.
- Az agilis projektek jelentősen felülmúlják a hagyományos, vízesés-modell szerinti menedzsmentmódszereket.
- A Scrum, a Kanban és az XP az agilis projektmenedzsment legfontosabb keretrendszerei.
- Az agilis módszerek sikeres bevezetése valódi szervezeti kultúraváltást igényel.
Mi az agilis projektmenedzsment?
Az agilis projektmenedzsment egy iteratív megközelítés, amely rövid, általában két-négy hétig tartó munkaciklusok, az úgynevezett sprintek révén teremt értéket, amelyek során a csapatok folyamatosan terveznek, végrehajtanak, értékelnek és alkalmazkodnak, ahelyett, hogy egy merev, egymást követő tervet követnének.
Ahelyett, hogy hónapokat töltenének azzal, hogy mindent elkészítsenek, mielőtt visszajelzést kapnának, a csapatok néhány hetente kiadnak egy működő szoftvert, és a tapasztalatok alapján módosítják azt.
Ez közvetlenül megoldja azt a problémát, amellyel a legtöbb csapat szembesül: a hosszú fejlesztési ciklusok során mindent egyszerre szállítanak le, csak hogy aztán kiderüljön, hogy a követelmények már hónapokkal ezelőtt megváltoztak.
A hagyományos vízesés-modellű projektmenedzsment a követelményeket már a kezdetén rögzíti, és lineáris fázisokon halad át, ahol minden szakasz befejeződnie kell, mielőtt a következő megkezdődhet.
Az ügyfelek bevonása elsősorban a kezdeti követelményfelmérés és a végső átadás során történik, a kettő között pedig nincs semmi kézzelfogható.
Az agilis megközelítés ezt teljesen felforgatja. Az ügyfelek a projekt teljes életciklusa során részt vesznek a folyamatban, és minden sprintben láthatják a működő szoftvert.
A csapatok még a fejlesztés késői szakaszában is szívesen fogadják a követelményváltozásokat, és azokat nem költséges problémaként, hanem versenyelőnyként kezelik.
A módszertan a változást nem kivételként, hanem elvárásként kezeli, így a meghatározott idő- és költségkeretek között is az ügyfélértékre összpontosít.
Miért fontos az agilis projektmenedzsment?
Azok a szervezetek, amelyek sikeresen hajtották végre az agilis átalakulást, körülbelül 30%-os növekedést jelentenek a hatékonyság, az ügyfélelégedettség és a munkavállalói elkötelezettség terén.
Amikor kéthetes sprintekre váltottak, négy hét alatt szállították le az első működőképes funkciót, és a valódi ügyfél-visszajelzések alapján módosították az irányt. Ez a váltás mentette meg a termékcsaládot.
Láttam, ahogy egy Fortune 500-as ügyfél kilenc hónapig küszködött a vízesés-modell szerinti tervezéssel, mire rájött, hogy a piaca teljesen megváltozott.
Amikor kéthetes sprintekre váltottak, négy hét alatt szállították le az első működőképes funkciót, és a valódi ügyfél-visszajelzések alapján módosították az irányt. Ez a váltás mentette meg a termékcsaládot.
A Standish Group kutatása szerint az agilis projektek 42%-os sikerarányt érnek el, szemben a vízesés-módszerrel megvalósított projektek mindössze 13%-os sikerarányával. Ugyanakkor a vízesés-módszerrel megvalósított projektek 59%-a bukik meg, míg az agilis projektek esetében ez az arány csupán 11%.
Ezek nem apró különbségek. Alapvető javulást jelentenek abban, ahogyan a csapatok kezelik a bizonytalanságot és értéket teremtenek, amikor a követelmények változnak.
Könnyű megoldást keres az agilis csapatod egy helyen történő irányításához? Töltsd le ingyen a ClickUp agilis menedzsment sablonját itt!
Az agilis projektmenedzsment alapelvei
Az Agilis Kiáltvány 2001-ben négy értéket fogalmazott meg, amelyek ma is irányadók a modern csapatok számára. Ezek nem elvont filozófiai elvek, hanem gyakorlati prioritások, amelyek meghatározzák a napi döntéseket.
- Az egyének és az interakciók fontosabbak, mint a folyamatok és az eszközök: A csapatok a közvetlen kommunikációt és az együttműködést részesítik előnyben a folyamatok merev betartásával vagy a bonyolult eszközök használatával szemben.
- Működő szoftver a részletes dokumentáció helyett: A hangsúly áthelyeződik a felhasználók által ténylegesen tesztelhető, működőképes fejlesztésekre, ahelyett, hogy olyan tökéletes dokumentációt készítenénk, amely talán soha nem tükrözi a valóságot.
- Az ügyféllel való együttműködés fontosabb, mint a szerződéses tárgyalások: A fejlesztés során az érdekelt felek folyamatos bevonása fontosabb, mint a kezdeti szerződések szigorú betartása, amelyeket még mielőtt bárki is megértette volna a valódi követelményeket, megfogalmaztak.
- A változásokra való reagálás a terv követése helyett: A csapatok elfogadják a változó követelményeket és alkalmazkodnak hozzájuk, amint új információk merülnek fel, ahelyett, hogy minden változást elkerülendő, költséges problémaként kezelnének.
Ezek az értékek nem azt jelentik, hogy teljesen el kell hagyni a folyamatokat, a dokumentációt, a szerződéseket vagy a terveket. Egyszerűen csak azt jelzik, hogy ha választani kell, akkor mi az, ami a legnagyobb értéket teremt.
Hogyan működik az agilis módszer [lépésről lépésre]
A csapatok az agilis módszert ismétlődő sprintciklusok révén valósítják meg, amelyek az ötleteket működőképes szoftverekké alakítják át.
Minden sprint ugyanazt a ritmust követi, általában két hétig tart, ami kiszámíthatóságot teremt, miközben megőrzi a rugalmasságot a struktúrán belül.
1. Sprinttervezés
A ciklus a sprinttervezéssel kezdődik, amelynek során a csapat kiválasztja azokat a termék-backlog-elemeket, amelyeket a sprint során el tudnak készíteni.
De ez nem csupán a feladatok véletlenszerű kiválasztását jelenti. A termékfelelős elmagyarázza, mi a legértékesebb jelenleg, a fejlesztők pedig felmérik, mi megvalósítható a jelenlegi kapacitásuk és a korábbi teljesítményük alapján.
Együtt határozzák meg a sprint célját, amely a munkának a puszta feladatlista teljesítésén túlmutató értelmet ad.
A csapat emellett a kiválasztott feladatokat kisebb részekre bontja, és tervet készít a munka elvégzésére.
2. Napi állásfoglalások
A sprint ideje alatt a csapat minden nap tart egy tizenöt perces ellenőrző megbeszélést, hogy összehangolt maradjon.
Ezek nem a vezetőnek szóló állapotjelentések. Hanem olyan munkamegbeszélések, ahol a fejlesztők áttekintik a sprintcél felé tett előrehaladást, és azonosítják a munkát akadályozó tényezőket.
Mindenki elmondja, mit végzett el tegnap, mivel foglalkozik ma, és mi akadályozza az előrelépést.
A szigorú időkorlát segít a lényegre koncentrálni, a részletes megbeszélésekre pedig utána kerül sor, kizárólag az érintettek részvételével.
3. Sprint végrehajtása
A ceremóniák között a fejlesztők olyan működőképes inkrementumokat hoznak létre, amelyek megfelelnek a csapat „kész” definíciójának, önállóan irányítják munkájukat, és a tanulságok alapján naponta módosítják terveiket.
A sprint célja változatlan marad, de az, hogy a csapat hogyan éri el azt, változhat, ha technikai kihívásokkal szembesülnek, vagy jobb megközelítéseket fedeznek fel.
Nem kerül sor olyan változtatásokra, amelyek veszélyeztetnék a sprint célját, bár a hatókör pontosításra és újratárgyalásra kerülhet a termékfelelőssel, ahogy a csapat egyre többet tud meg.
4. Sprint-áttekintés
A sprint végén a csapat nem formális prezentáció keretében, hanem egy munkamegbeszélésen mutatja be az elvégzett munkát az érdekelt feleknek, így a visszajelzések alapján azonnal kialakíthatók a következő prioritások.
Az érdekelt felek olyan működő szoftvert láthatnak, amelyet ténylegesen tesztelhetnek, és így a teoretikus követelmények helyett a valós tapasztalatok alapján adhatnak visszajelzést.
A termékbacklogot gyakran már a helyszínen módosítják annak alapján, amit mindenki az inkrementum megtekintése során tanul.
5. Sprint-visszatekintés
A záróünnepség minden sprintet azzal zár le, hogy áttekintik, mi sikerült jól, milyen problémák merültek fel, és mely fejlesztések a legfontosabbak a következő sprint szempontjából.
A csapat áttekinti, hogyan alakult a sprint az egyének, az interakciók, a folyamatok és az eszközök tekintetében.
Meghatározzák a hatékonyság javításához leginkább hozzájáruló változtatásokat, és azokat vagy azonnal végrehajtják, vagy felveszik a következő sprint backlogjába.
Ez a beépített fejlesztési mechanizmus megakadályozza, hogy a csapatok sprintről sprintre ugyanazokat a hibákat ismételjék meg.
Ez a ritmus átláthatóságot teremt, ahol mindenki láthatja a munkát, ellenőrzést, ahol a haladást rendszeresen felülvizsgálják, és alkalmazkodást, ahol a folyamatot módosítják, ha az ellenőrzés során problémák merülnek fel.
A leggyakoribb agilis megközelítések
Az agilis nem egyetlen módszertan, hanem egy keretrendszerekből álló család. Három keretrendszer dominál a modern gyakorlatban, és a választás attól függ, hogy milyen típusú munkát végez a csapata, és mennyire előre jelezhető a munkamennyiség.
Scrum
A Scrum a legnépszerűbb keretrendszer, amelyet a vállalatok 63%-a alkalmaz, és erre jó oka van.
Ezek strukturált szerepköröket határoznak meg – többek között a termékfelelős, a scrum master és a fejlesztők szerepét –, valamint előírt rituálékat és egyértelmű dokumentumokat biztosítanak, amelyek konkrét kiindulási pontot nyújtanak a csapatoknak.
Az időkeretekkel ellátott sprintstruktúra ritmust és kiszámíthatóságot teremt, miközben minden cikluson belül lehetővé teszi az alkalmazkodást.
Ez a keretrendszer leginkább komplex termékfejlesztéshez alkalmas, 10 főnél kisebb csapatok esetében, ahol a változó követelmények miatt előnyös az adaptív tervezés.
Ha olyan új dolgot fejleszt, amelynél az ügyfelek igényei a fejlesztés során változnak, a Scrum iteratív megközelítése lehetővé teszi, hogy néhány hetente módosítsa az irányt, ahelyett, hogy egy merev, hosszú távú tervhez kellene ragaszkodnia.
Kanban
A Kanban más megközelítést alkalmaz: a rögzített iterációk helyett a folyamatos áramlást helyezi előtérbe.
A csapatok táblákon ábrázolják munkájukat, és korlátozzák a folyamatban lévő feladatok számát, így elkerülve a túlterhelést és a feladatváltás okozta zavarokat.
A munka a rendszerben a kapacitás felszabadulásával halad előre, így zökkenőmentes, kiszámítható folyamatot teremtve.
Ez kiválóan alkalmas gyártástámogató és karbantartó csapatok számára, ahol a munka jellege kiszámíthatatlan és folyamatos, valamint olyan üzemeltetési csapatok számára, amelyek folyamatos szolgáltatást nyújtanak, és ahol a feladatok folyamatosan érkeznek.
Ha a csapata olyan ügyfélszolgálati jegyeket, hibajavításokat vagy infrastruktúra-igényeket kezel, amelyek nem várhatnak a következő sprinttervezési ülésig, akkor a Kanban folyamatos modellje természetesen illeszkedik a folyamatokhoz.
Extreme Programming (XP)
Az XP a fegyelmezett mérnöki gyakorlatok révén kiemelten összpontosít a technikai kiválóságra. A páros programozás során két fejlesztő ül egy munkaállomáson, hogy folyamatosan ellenőrizhessék egymás kódját.
A tesztvezérelt fejlesztés során a kód írása előtt megírják a sikertelen teszteket. A folyamatos integráció azonnal teszteli a kódot, amint az hozzáadódik, így a problémákat gyorsan fel lehet fedezni.
Ez akkor a legalkalmasabb, ha a kód minősége kiemelten fontos, a csapatok kicsiek és egy helyen dolgozhatnak a hatékony páros munkavégzés érdekében, valamint a követelmények gyakran változnak.
Az XP olyan technikai gyakorlatokat kínál, amelyek a követelmények változása ellenére is fenntarthatóvá teszik a kódbázisokat, így különösen értékes azoknál a hosszú élettartamú termékeknél, ahol a technikai adósság drágává válik.
Keretmunkamódszerek ötvözése
A csapatok gyakran kombinálják a különböző keretrendszereket, hogy kihasználják az egyes megközelítések legjobb tulajdonságait.
A Scrum plusz XP a legnépszerűbb hibrid módszer: a Scrumot használja a projektmenedzsment felépítéséhez, míg az XP fegyelmezett mérnöki gyakorlatok révén biztosítja a technikai minőséget.
Ez a kombináció a Scrum sprintalapú tervezését és az érdekelt felek bevonását ötvözi az XP kódminőségi gyakorlataival, amelyek megakadályozzák a technikai adósság felhalmozódását.
Mikor a legcélszerűbb az agilis megközelítés?
Az agilis módszerek akkor működnek igazán jól, ha bizonyos feltételek teljesülnek:
- Olyan projektek, amelyeknél a követelmények folyamatosan változnak vagy nem egyértelműek, és az ügyfelek igényei gyorsan változnak
- Komplex feladatok, amelyek rugalmasságot és alkalmazkodást igényelnek, miközben a csapatok tanulnak
- Szoftverfejlesztés, amelyhez gyakori ügyfél-visszajelzésre van szükség
- Olyan helyzetek, amikor a csapatok két-négy hetente működőképes részleges eredményeket tudnak átadni
- Olyan szervezetek, amelyek hajlandóak döntéshozatali jogkörrel felruházni a csapatokat
Ezeknek a forgatókönyveknek van egy közös vonása: a bizonytalanság, amelynek kezelésében az előzetes tervezés helyett az iteratív felfedezés bizonyul hatékonynak.
A másik oldal is ugyanolyan fontos. A változtatásokra nem számító, rögzített követelmények elpazarolják az agilis módszerek rugalmasságát, mivel feleslegesen viseled az alkalmazkodás költségeit.
Hasonlóképpen, a szigorúan szabályozott környezetek, például a gyógyszeripar, másfajta problémát vetnek fel, mivel kiterjedt dokumentációt igényelnek, amit az agilis módszerek egyszerű megközelítése természetéből adódóan nem biztosít.
Egyes projektek olyan korlátokkal szembesülnek, amelyek miatt az iteráció nem kivitelezhető. A fizikai építési projekteknél szigorú függőségek vannak, ahol a szekvenciális megközelítés egyszerűen ésszerűbb.
Ha pedig a szerződések előre meghatározott eredményekkel és szigorú büntetésekkel járó fix áras struktúrákat tartalmaznak, azok alapvetően ütköznek az agilis módszerek változó hatókörre való nyitottságával.
A megvalósítás előtt három előfeltétel határozza meg a megvalósíthatóságot:
- Képes-e havonta új funkciókat kiadni anélkül, hogy a tesztelés túlzott terhet jelentene?
- Van-e olyan személy, aki rendelkezésre áll és felhatalmazással rendelkezik arra, hogy termékfelelősként napi kiadási döntéseket hozzon?
- Még nem tudja, hogyan néz ki a megoldás?
Ha bármelyik kérdésre nemmel válaszol, akkor gyakran ésszerűbb olyan hibrid megközelítéseket alkalmazni, amelyek ötvözik az agilis gyakorlatokat a hagyományos projektszerkezettel, mint olyan módszertant erőltetni, amely nem felel meg a korlátainak.
Hogyan kezdjen bele az agilis projektmenedzsmentbe?
Az agilis módszerek bevezetése nem azonnali átalakulást igényel, hanem átgondolt lépéseket. Íme, hogyan juthat el a tervezéstől az első sikeres sprintig.
Mielőtt belemennénk a részletekbe, ez a videó szilárd alapot nyújt ahhoz, hogy megértsük, hogyan is néz ki az agilis módszer a gyakorlatban:
- 1. lépés: Mérje fel a felkészültségét Mielőtt bejelentené az agilis átalakulást, mérlegelje, hogy a környezete valóban támogatja-e azt. Először vizsgálja meg a projekt típusát, és győződjön meg arról, hogy a követelmények folyamatosan változnak, és gyakori visszajelzésre van szükség. Ezután vizsgálja meg, hogy a csapattagok hajlandóak-e megváltoztatni a munkamódszerüket, vagy esetleg mélyen gyökerező ellenállásba ütközik. Végül győződjön meg arról, hogy az érdekelt felek és a vezetés tisztában vannak azzal, hogy aktívan részt kell venniük a folyamat egészében, nem pedig csak a végén kapniuk az állapotjelentéseket. Ha ezek közül bármelyik elem hiányzik, pótolja a hiányosságokat, mielőtt továbbhaladna. Az agilis átalakulások sokkal gyakrabban buknak meg a szervezeti támogatás hiánya miatt, mint a technikai végrehajtási problémák miatt.
- 2. lépés: Válassza ki a keretrendszert Miután meggyőződött arról, hogy készen áll, válasszon ki egy keretrendszert, és legalább három hónapig tartsa be azt. A Scrum olyan struktúrát biztosít, amely jól működik a termékfejlesztő csapatok számára, míg a Kanban a folyamatos munkafolyamatokhoz, például a támogatáshoz és a karbantartáshoz alkalmas. Ha az elsődleges szempont a technikai minőség, az XP olyan mérnöki gyakorlatokra összpontosít, mint a páros programozás és a tesztvezérelt fejlesztés. A legfontosabb, hogy teljesen elsajátítson egy megközelítést, mielőtt keverni kezdené a keretrendszereket, mert meg kell értenie, miért létezik az egyes elemek, mielőtt elkezdené azokat a saját helyzetéhez igazítani.
- 3. lépés: Vezessen be egy kísérleti projektet Miután kiválasztotta a keretrendszert, válasszon ki egy olyan projektet, amely fontos az üzlet számára, de nem sodorja tönkre a vállalatot, ha problémákba ütközik. Ez lehetőséget ad a tanulásra anélkül, hogy katasztrofális következményekkel járna. Tervezzen két-három sprintet (négy-tizenkét hetet) értékelési időszakként, és tartsa a csapatot kicsinek, négy-öt főben, hogy a koordinációs terhek ne homályosítsák el azt a kérdést, hogy az agilis módszer önmagában működik-e. Gondoskodjon arról, hogy a csapat tagjai teljes munkaidőben a kísérleti projektre koncentrálhassanak, ahelyett, hogy figyelmüket több projekt között osztanák meg.
- 4. lépés: Határozza meg egyértelműen a szerepeket A kísérleti projektjéhez három kulcsfontosságú szerepre van szükség, amelyeknek már az első naptól kezdve megfelelően kell működniük. A termékfelelősnek jogosultsággal kell rendelkeznie ahhoz, hogy napi kiadási döntéseket hozzon anélkül, hogy feljebbvalóitól jóváhagyást kellene kérnie, és elérhetőnek kell lennie a csapat számára, nem pedig napokig eltűnnie. A Scrum-mesternek a folyamatot kell elősegítenie és az akadályokat el kell hárítania, nem pedig a hagyományos értelemben véve irányítania az embereket. Végül állítson össze egy többfunkciós fejlesztői csapatot, amely rendelkezik minden szükséges készséggel a munka elvégzéséhez anélkül, hogy külső függőségek lassítanák őket. Ezek a szerepkörök nem opcionális kiegészítők, amelyeket kihagyhat. Ezek strukturális követelmények ahhoz, hogy az agilis módszer a tervezett módon működjön.
- 5. lépés: Indítsa el az első sprintjét Kezdje a sprinttervezést azzal, hogy a termékfelelős ismerteti az aktuális prioritásokat, miközben a csapat kiválasztja azokat a feladatokat, amelyeket szerintük el tudnak végezni. Dolgozzanak együtt annak meghatározásán, hogy a „kész” mit jelent valójában a csapat számára, hogy mindenki ugyanazt a szabványt alkalmazzon, majd ütemezzék be az összes ismétlődő eseményt, mint például a napi standupot, a sprint-áttekintést és a retrospektívát, és védjék meg ezt az időt más megbeszélésektől. Ezután kezdjék el a fejlesztést, és számítsanak arra, hogy az első sprint kissé furcsának tűnik majd, mert ez mindig így van. A csapatoknak általában három-öt sprintra van szükségük ahhoz, hogy megtalálják a ritmusukat és kialakítsák a megbízható sebességüket.
Mielőtt bejelentené az agilis átalakulást, mérlegelje, hogy a környezete valóban támogatja-e azt. Először vizsgálja meg a projekt típusát, és győződjön meg arról, hogy a követelmények folyamatosan változnak, és gyakori visszajelzésre van szükség. Ezután vizsgálja meg, hogy a csapat tagjai hajlandóak-e megváltoztatni a munkamódszereiket, vagy esetleg mélyen gyökerező ellenállásba ütközik. Végül győződjön meg arról, hogy az érdekelt felek és a vezetés tisztában van azzal, hogy aktívan részt kell venniük a folyamat egészében, és nem csupán a végén kaphatnak helyzetjelentéseket. Ha ezek közül bármelyik elem hiányzik, pótolja a hiányosságokat, mielőtt továbbhaladna. Az agilis átalakulások sokkal gyakrabban buknak meg a szervezeti támogatás hiánya miatt, mint a technikai végrehajtási problémák miatt.
Miután meggyőződött arról, hogy készen áll, válasszon ki egy keretrendszert, és legalább három hónapig tartsa be azt. A Scrum olyan struktúrát biztosít, amely jól működik a termékfejlesztő csapatok számára, míg a Kanban a folyamatos munkafolyamatokhoz, például a támogatáshoz és a karbantartáshoz alkalmas. Ha az elsődleges szempontja a technikai minőség, az XP olyan mérnöki gyakorlatokra összpontosít, mint a páros programozás és a tesztvezérelt fejlesztés. A kulcs az, hogy teljesen elsajátítson egy megközelítést, mielőtt keverni kezdené a keretrendszereket, mert meg kell értenie, miért létezik az egyes elemek, mielőtt elkezdené azokat a saját helyzetéhez igazítani.
Miután kiválasztotta a keretrendszert, válasszon ki egy olyan projektet, amely fontos az üzlet számára, de nem fogja tönkretenni a vállalatot, ha problémákba ütközik. Ez lehetőséget ad a tanulásra anélkül, hogy katasztrofális következményekkel járna. Tervezzen két-három sprintet (négy-tizenkét hetet) értékelési időszakként, és tartsa a csapatot kicsinek, négy-öt főben, hogy a koordinációs terhek ne homályosítsák el azt, hogy az agilis módszer maga működik-e. Gondoskodjon arról, hogy a csapat tagjai teljes munkaidőben a kísérleti projektnek szentelhessék magukat, ahelyett, hogy figyelmüket több projekt között osztanák szét.
A kísérleti projektjéhez három kulcsfontosságú szerepkörnek kell megfelelően működnie már az első naptól kezdve. A termékfelelősnek jogosultsággal kell rendelkeznie ahhoz, hogy napi kiadási döntéseket hozzon anélkül, hogy felettesei jóváhagyását kellene kérnie, és elérhetőnek kell lennie a csapat számára, ahelyett, hogy napokra eltűnne. A scrum masternek elő kell segítenie a folyamatot és el kell távolítania az akadályokat, ahelyett, hogy hagyományos értelemben véve irányítaná az embereket. Végül állítson össze egy többfunkciós fejlesztői csapatot, amely rendelkezik minden olyan készséggel, amely a munka elvégzéséhez szükséges, anélkül, hogy külső függőségek lassítanák őket. Ezek a szerepkörök nem opcionális kiegészítők, amelyeket kihagyhat. Ezek strukturális követelmények ahhoz, hogy az agilis módszer a tervezett módon működjön.
Kezdje a sprinttervezést azzal, hogy a termékfelelős ismerteti az aktuális prioritásokat, miközben a csapat kiválasztja azokat a feladatokat, amelyeket szerintük el tudnak végezni. Dolgozzanak együtt annak meghatározásán, hogy a „kész” mit jelent valójában a csapat számára, hogy mindenki ugyanazt a szabványt kövesse, majd ütemezzék be az összes visszatérő eseményt, mint például a napi standupot, a sprint-áttekintést és a retrospektívát, és védjék meg ezt az időt más megbeszélésektől. Ezután kezdjék el a fejlesztést, és számítsanak arra, hogy az első sprint kissé furcsának tűnik majd, mert ez mindig így van. A csapatoknak általában három-öt sprintre van szükségük ahhoz, hogy megtalálják a ritmusukat és kialakítsák a megbízható sebességüket.
Gyakran feltett kérdések
Mennyi idő múlva láthatjuk az agilis módszerek eredményeit?
A csapatkommunikációban már az első sprint során azonnali javulás tapasztalható. A John Deere átalakulása hat hónapon belül 79%-os ciklusidő-csökkenést eredményezett. Középtávon a termelékenység 165%-kal nő. Hosszú távon, 12–24 hónap elteltével kialakul egy önfenntartó kultúra, amely maximális befektetési megtérülést biztosít.
Mi a különbség az agilis módszerek és a Scrum között?
Az agilis egy, az Agilis Nyilatkozatban megfogalmazott filozófia, amely értékeket és elveket tartalmaz. A Scrum egy olyan keretrendszer, amely meghatározott szerepkörökkel, eseményekkel és artefaktumokkal valósítja meg az agilis megközelítést. Képzelje el az agilis megközelítést egy egészséges életmód-filozófiaként, míg a Scrum egy konkrét étrend és edzésterv.
A két-három fős kis csapatok is hatékonyan alkalmazhatják az agilis módszereket?
Igen, gyakran hatékonyabban. A Scrum Guide háromfős csapatot javasol, de a kisebb csapatok is jól alkalmazkodnak. Folyamatosan kommunikálnak, így nincs szükség formális állóértekezletekre. A nagyobb csapatok három-négyszer többe kerülnek, és több hibát eredményeznek. Tartson retrospektívákat, és fontolja meg a Kanban vagy az XP gyakorlatok alkalmazását.
Következtetés
Nem titok, hogy az agilis projektmenedzsment a világ egyik legnépszerűbb projektmenedzsment-módszertana.
Egyszerű és gyors megoldás, amellyel csapata pillanatok alatt könnyedén elvégezheti a feladatokat és a projekteket!
Ráadásul, mivel ezek a módszerek nagy hangsúlyt fektetnek az ügyfelek visszajelzései alapján történő változtatásokra, biztos lehet benne, hogy olyan terméket fog piacra dobni, amelyet az ügyfelei imádni fognak.
Ha agilis projektmenedzsment módszerek bevezetését fontolgatja, miért ne próbálná ki egy olyan szoftvert, mint a ClickUp?
Minden megtalálható benne, amire szüksége van a projektek és a sprintek zökkenőmentes kezeléséhez! Regisztráljon még ma a ClickUp örökre ingyenes verziójára!