Mi olyan nagy az Agile-nál? Az agilis módszertan alapja
Agilis Definiálja az agilis menedzsment rendszereket, amelyek egy ideje már működtek, de az utóbbi időben pénzbe kerültek. Valójában az Agile Management következetesen szerepel minden évben szinte minden IT Projektmenedzsment blog legfontosabb projektmenedzsment trendjében.
Az Agile alkalmazása informatikai alapú projektekben nem vitatott, mivel nemcsak az informatikai szoftverekben, hanem a termékfejlesztésben és az innovációban is alkalmazható.
Mi tehát olyan nagy az Agile-nál? Kérdezze meg azokat a munkavállalókat, akik átmentek a hagyományos rendszertől az Agile-hez, és kérdezhetik őket az állandó értekezletektől és a „találkozókkal kapcsolatos találkozókról”.
Kiderült, hogy Agile-nél sokkal több van, mint csupán találkozók és visszajelzések. A csoportok felhatalmazására és a projektfejlesztés szekvenciális módjainak eltávolítására összpontosít, hogy nagyobb rugalmasság és innováció legyen. Bár ez sokkal inkább értekezleteket és előadásokat jelent, mint a hagyományos rendszereknél, ez azt is jelenti, hogy kisebb esély van az későbbi iterációkra és változásokra. tovább a projektciklusban.
Az IT-vel kapcsolatos projekteket sújtó közös problémák gyógyító eszközének tekintik. Pontosan mi ez és hogyan lehet jobb, mint a hagyományos rendszerek?
Agilis módszertan szükségessége - Menedzsment gyakorlatok
Aki a szoftverfejlesztési projektekben agilis módszertant dolgozott, elképzelései lesznek a projekt során felmerülő szokásos problémákról: a hatály változásáról, a be nem tartható határidőkről és a túlterhelt erőforrásokról.
A projektmenedzsment hagyományos, agilis módszereinek számos hátránya volt, amelyek miatt nem tudtak megbirkózni az állandóan változó üzleti környezettel, különösen a szoftverfejlesztés terén, és a fenti helyzetek sajnos túl gyakoriak voltak. Ez nem azt jelenti, hogy a hagyományos módszerek sehol nem alkalmazhatók . Még mindig a legjobb tét azoknak a projekteknek, amelyekben az ötlet a kezdetektől kezdve teljesen kialakult.
Az agilis menedzsment gyakorlatok az óra szükségessé váltak, mivel eleget tettek egy dinamikus környezetben elindított termék következő igényeinek:
- A termék piacra jutásának sebességére van szükség
- Rugalmasságra van szükség a műszaki adatok többszöri megváltoztatásához
- Hiányok a „munkamegosztás” forgatókönyvben
- Az ügyfél dilemmája
- A költségcsökkentés szükségessége
A termék piacra jutásának sebességére van szükség:
Gyors tempójú környezetben élünk, ahol a rugalmasság és a sebesség kulcsa a sikernek.
A technológia az iparág egyik leggyorsabban változó ágazata. Minden percben van egy újabb ötlet, termék vagy innováció. Ebben a háttérben a hagyományos projektmenedzsment megközelítés nem valósul meg. A szekvenciális projekt szükségszerűen attól függ, hogy az agilis módszertani lépéseket kielégítő módon befejezzék-e sorrendben. A hagyományosan menedzselt projektek ütemezése mindig vita csontja.
A nem dinamikus szervezetek és csapatok elveszítik a versenyt azokkal, akik maguk morfizálnak, hogy megfeleljenek a változó környezetnek.
Rugalmasságra van szükség a specifikációk többszöri változásának befogadására:
Az ügyfelek elvárásai és igényei gyakran változnak a termékfejlesztés során. Mielőtt az Agile Management Systems bekerült volna a rendszerbe, az informatikai projektek gyakran kudarcot vallottak, mert a hagyományos projektmenedzsment rendszert úgy építették fel, hogy „felszálljon”. Ha bármilyen változás történt, az ügyfelek gyakran megérintették pénztárcájuk vagy ütemezésük szorítását. A más iparágaktól adaptált hagyományos projektmenedzsment-modell egyszerűen nem működött olyan dinamikus iparágban, mint az informatika.
Munkamegosztás:
A hagyományos modellben külön szakaszok vannak, kezdve a rendszerigény-elemzéssel, és a termék kiadásáig és karbantartásáig. Ennek eredményeként megoszlik a munkamegosztás és a tagokat „tervezők”, „programozók” vagy „tesztelők” jelöléssel látják el. A valóságban azonban a mai erőforrások rendkívül funkcionálisak, és a szerepek ilyen egyértelmű megkülönböztetése a legtöbb projektben nem megvalósítható.
Az ügyfél dilemmája:
Az ingatag projektekben az ügyfelek gyakran nem egészen biztosak abban, hogy mi legyen végtermékük, az összes specifikációval együtt. A funkciók és a követelmények gyakran megváltoznak, amikor a munka megtörténik. A hagyományos modellek, például a vízesés modell hangsúlyozzák az egyértelműséget a végtermék vonatkozásában, és a tervektől való eltérések óriási stresszt jelentenek a rendszer számára. Ez az utolsó tényezőhöz vezet, amely az agilis rendszerek fejlesztéséhez vezetett.
A költségcsökkentés szükségessége:
Hagyományosan a projekt indulása után bármikor elutasították a követelmények változásait. Inkább a kiegészítő elemek költségei magasak voltak, néha túlságosan is. Ezért elengedhetetlen minden lehetséges forgatókönyvet magába a tervezési szakaszba belefoglalni. Ez azt jelentette, hogy minden forgatókönyvet megfontoltak és megoldást javasoltak. Mivel azonban szinte lehetetlen tudni, hogy a termék melyik részét részesíti előnyben, a csapatok gyakran fejlesztettek ki egy termék „felfújt verzióját”. Ez magában foglalta az összes lehetséges forgatókönyvet, amelyek közül a tipikus felhasználó nem haladja meg a 20% -ot. Ez szükségtelen költségeket és fejlesztést eredményezett.
Mondanom sem kell, hogy ez azt jelentette, hogy minden projekt globális volt a tervezésében.
És amikor egy teljesen új, nem tervezett forgatókönyv merült fel, a tervezés ellenére többletköltségek merültek fel.
2001 februárjában egy embercsoport találkozott, hogy pontosan megvitassa ezt: a szoftverfejlesztés rugalmas és agilis modelljének szükségességét, amely elősegítette az ügyfél és a fejlesztő számára ténylegesen alkalmazott termékek fejlesztését. Ennek eredményeként létrejött az „Agilis manifestum”, amely az agilis módszertani szoftverfejlesztés előnyeit jelentette, vagyis négy olyan alapelvből áll, amelyek ugyanolyan egyszerűek, mint leíróak. Tizenkét „agilis alapelv”, amely elmagyarázza, hogy az agilis rendszerek hogyan működnek valójában egy projektkörnyezetben, szintén kifejlesztésre kerültek.
Ezen a munkánkon keresztül értékeltük:
- Az egyének és a folyamatok és eszközök közötti interakciók
- Működő szoftver az átfogó dokumentáció felett
- Ügyfél-együttműködés szerződéses tárgyalások során
- Válasz a tervet követő változásokra
Vagyis, míg a jobb oldali elemekben van érték, addig inkább a bal oldalon lévő cikkeket értékezzük.
A 12 agilis alapelv
A 12 agilis alapelv az Agile Manifestó mögött meghúzódó vezető fogalmak egy csoportja, amely támogatja a projektcsoportokat az Agile Projects megvalósításában. Ők:
- Legfontosabb prioritásunk az ügyfelek kielégítése az értékes szoftverek korai és folyamatos kiszállításával.
- Üdvözöljük a változó követelményeket, még a késői fejlesztési szakaszban is. Az agilis módszertan segítségével az ügyfél versenyelőnye érdekében kihasználhatja a hámcserét.
- Szállítson működő szoftvereket gyakran, néhány héttől pár hónapig, előnyben részesítve a rövidebb időtartamot.
- Az üzletembereknek és a fejlesztőknek a projekt során minden nap együtt kell működniük.
- Építsen projekteket motivált egyének körül. Adja meg nekik a szükséges környezetet és támogatást, és bízza őket a munka elvégzésében.
- A leghatékonyabb és leghatékonyabb módszer az információ továbbítására a fejlesztői csapaton belül és azon belül a személyes beszélgetés.
- Az előrehaladás elsődleges mérőszáma a működő szoftver.
- Az agilis módszertani folyamatok elősegítik a fenntartható fejlődést. A szponzoroknak, a fejlesztőknek és a felhasználóknak képesnek kell lenniük arra, hogy határozatlan időre állandó sebességet tudnak fenntartani.
- A folyamatos figyelem a műszaki kiválóságra és a jó tervezésre fokozza az agilitást.
- Alapvető fontosságú az egyszerűség - a nem elvégzett munka maximalizálásának művészete.
- A legjobb architektúrák, követelmények és tervek az önszerveződő csapatok eredményei.
- Rendszeres időközönként a csapat gondolkodik arról, hogyan lehetne hatékonyabb, majd beállítja és hozzáigazítja magatartását.
Példa egy agilis irányítást igénylő projektre
Képzeljen el egy olyan induló vállalkozást, amely egy mobil alkalmazást fejleszt ki egy ügyfél számára. A fejlesztés megkezdése előtt a teljes alkalmazástervezés befagyasztása katasztrofális lehet. A piaci felmérés lefolytatására, a részletes terv kidolgozására, a felajánlni kívánt változatok eldöntésére és a termék fejlesztésére is korlátozott idő áll rendelkezésre. Az ezzel a megközelítéssel járó hatalmas költségek mellett fennáll annak a kockázata is, hogy más vállalkozások előbb kifejleszthetik az alkalmazást, mielőtt megtennék.
A projektmenedzsment agilis módszertana segít leküzdeni ezeket a problémákat. Ebben a rendszerben az alkalmazást szakaszosan fejlesztették ki, ügyfél-interakcióval minden nap, és például a héten azonosított teljesítések vagy projekt mérföldkövekkel.
Több csapat is dolgozhat ugyanazon az alkalmazáson, így a fejlesztési idő drasztikusan csökken.
A funkciókat minden egyes találkozón finomítják, és a végtermék tükrözi a végső igényt. Lépésről megtanulják, mi működik az ügyfélnek, és improvizálják az ajánlatokat, amíg meg nem kapják a kívánt terméket.
A projektmenedzsment hagyományos megközelítésében a termék kiadása előtt minden felülvizsgálatot meg kell fontolni. Ez elmulasztott határidőket, megnövekedett munkaterhelést és költség-inflációt eredményezne. Sőt, a termék valószínűleg teljesen elvesztette relevanciáját a kiadás időpontjáig.
Hogyan működik az Agile Management?
Noha az Agile Management-et leginkább informatikai koncepciónak nevezik, felhasználása nem korlátozódik az IT-iparra. Például a Zara üzletlánc-kiskereskedő az Agile Management alapelveit használta az üzleti vállalkozás átalakításához.
Az agilis alapelvek alapján a Zara kis tételekben gyártotta a termékeket, és nem az új szezon előtti nagy termelésre összpontosított. A társaság ezzel a módszerrel elkerülte a nagy készlet és a kiszámíthatatlan kedvezményes ajánlatok költségeit.
Az agilis projektmenedzsment néhány kulcsfontosságú szempontja a következő:
- Az agilis projektmenedzsment rugalmas megközelítést követ.
Az Agile Management üdvözli a termékfejlesztés során bevezetett kiegészítéseket és változtatásokat, ahelyett, hogy az eredeti előírásokhoz igazítaná.
- Az agilis projekteket általában külön munkadarabokra osztják, a csapatok részt vesznek a munka egy vagy több részének kidolgozásában.
Tehát lehetséges, hogy például négy csapat egyidejűleg dolgozzon egyidejűleg a projekt különböző részein, így rövidül a projekt ütemterve. A csapatok napi rendszerességgel koordinálják egymást és az ügyfelet.
- Napi találkozók vannak a projekt előrehaladásáról vagy akadályairól, állandó visszajelzéssel.
Miután megkapta az ügyfelek visszajelzését, a változtatásokat beépítették és a csapatok a következő részre lépnek. Ez a folyamat továbbra is olyan terméket szállít, amely dinamikusabb és jobban megfelel az ügyfél igényeinek.
- A csoporttagok nagyobb mértékű bevonása, nem pedig felülről lefelé történő megközelítés.
A szoftverfejlesztési életcikluson belül a csapat tagjai minden szakaszban részt vesznek: követelménykészítés, tervezés, fejlesztés és agilis módszertani tesztelés. Mivel rendszeresen áttekintik a feladat hatékonyságát, a csapat tagjai ennek megfelelően módosítják a viselkedést és az eljárásokat.
- Egy agilis projektben a projektmenedzser profilja megváltozik a hagyományos szerepről.
Többé nem töltenek sok időt az erőforrások tervezésénél vagy megfigyelésén, hanem most több időt töltenek be a csapatokkal való együttműködésben és annak biztosításában, hogy az általános kép mindig látható legyen. Ez nem könnyű átmenet, és az Agile rendszerekre áttérő vezetőknek gyorsan alkalmazkodniuk kell a projekt sikeréhez.
Néhány szó Scrumról:
A Scrum az Agile módszertan végrehajtásának egyik legnépszerűbb kerete. Mi az agilis módszer? Az Agile-t megelőzi, 1986-ban először javasolták, és bevezették az autó- és nyomdaiparban.
Az agilis metodika a scrummal nem szinonim; vannak más keretek, amelyek felhasználhatók az Agile megvalósítására, de a Scrum az egyik leghatékonyabb és valószínűleg a legnépszerűbb. Mi az a scrum? A Scrumnak általában csak három szerepe van: Terméktulajdonos, Csapat és Scrum master. A Scrum módszertan mestere nem projekt menedzser. A hagyományos projektmenedzser-szerepkör felelőssége megoszlik a három Scrum-projektmenedzsment szerep között. A projekt rögzített hosszúságú iterációk sorozatába épül, amelyeket sprintnek hívnak. Az egyes agilis módszertani sprint sikere kézzelfogható haladás érzését és folyamatos inspirációt idéz elő. Az egyes iterációk célja egy működő termék előállítása, amelyet be lehet mutatni az érdekelt felek számára. Az agilis módszertani scrum-mester együttműködik a termék tulajdonosával és a csapattal, hogy megkönnyítse a célok teljesítését az akadályok eltávolításával. Az agilis módszertan-fejlesztő csapat keresztfunkcionális, és a fejlesztők mellett tesztelőket, tervezőket és operatív mérnököket foglal magában.
Hagyományos projektmenedzsment: A vízesés
Az egyik legjelentősebb hagyományos projektmenedzsment rendszer a vízesés. Az 1970-es évek óta gyakran használták. Számos közismert és széles körben alkalmazott vízesés-módszertan létezik az informatikai projektekben. Ide tartozik a PRINCE2, amelyet az Egyesült Királyság kormánya hozott létre a közszektor számára.
Akárcsak a neve sugallja, ez egy szekvenciális munkafolyamat. A végterméket rögzítik a projekt elején. Ezután a munkafolyamat különböző szakaszai egymás után befejeződnek (koncepció kidolgozása, elemzés, tervezés, felépítés, tesztelés, megvalósítás és karbantartás). Az előző lépés befejezése után a fejlesztők tovább lépnek a következő lépésre. A projekttervnek bolondnak kell lennie; miután a szekvencia egy szakaszát befejezték, a fejlesztők nem nyithatják meg ugyanazt a helyet anélkül, hogy újrakezdenék. Ez egy statikus megközelítés az agilis módszertan számára a Projektmenedzsment területén. Nincs hely a változásoknak vagy a hibáknak, és az agilis módszertani projekttervet gondosan be kell tartani.
Analógiát lehet készíteni a Waterfall Management és a remekmű festése között. A végső remekmű képe már a művész eszébe jut, és folyamatosan dolgozik annak felé. Ha valamilyen okból a végtermék különbözik attól, amelyet látott, akkor nem tudja azt egyszerűen módosítani.
Agilis vagy vízesés?
- Mi az Agile? Az Agile jobban megfelel az inkrementális és evolúciós projektekkel foglalkozó kis csoportoknak, míg a Waterfall nagy rendszerekhez vagy fejlesztési projektekhez alkalmas. A vízesés kezelése jobban megfelelhet az iparágaknak, például az építőiparnak. Az Agile-t dinamikusabb projektekben, például az IT-iparban használják.
- Az agilis rendszerek magasan képzett csapattagokat igényelnek, akik képesek a projekt minden szakaszára. Ez drasztikus változást igényel a projektmenedzser szerepében. A vízesés folyamata hagyományosabb módon épül fel, lineáris, és a nem fejlesztők, és a szoftverfejlesztés újjai számára talán könnyebben érthető.
- Sok szervezet úgy véli, hogy a Waterfall módszertan megnyugtató, mivel ez jobban dokumentált. Agileről ismert, hogy nem hangsúlyozza a kiterjedt dokumentációt. Ez inkább az emberektől függ, ami kellemetlen lehet azokban a szervezetekben, ahol magas a lemorzsolódás.
- A kisebb, egyértelmű projekteknél nem feltétlenül szükséges egy agilis módszertani keret, és a szekvenciális vízesés modell ugyanúgy működhet.
Hol van ez mind?
Az agilis fejlesztési módszertan az Egyesült Államokban az összes informatikai projekt több mint kétharmadát képviseli, a HP által 2015 májusában végzett felmérés szerint.
De az Agile nem mindig a „tökéletes” megoldás. Ez nem egy mindenki számára alkalmas megoldás, amelynek eredményeként sok szervezet (a HP felmérése szerint 24%) most már hibrid megközelítést alkalmazott.
Az Agile és a Waterfall módszerek hibrid kombinációja kihasználhatja mindkettő előnyeit. Ez a hibrid megközelítés bonyolult projektekben működhet külső ügyfelekkel és nagy csapatokkal. Ezt a megközelítést Erick Bergmann és Andy Hamilton írta le. Ez egy kompromisszum a két módszer között, lehetővé téve a szoftvercsapatok számára, hogy „agilisan” dolgozzanak, míg a hardverfejlesztő csapatok és a termékmenedzserek a hagyományos módszert használják.
Mark Fromson, digitális tanácsadó rámutat a hibrid működésének egy másik módjára:
A projektet vízesés-szerű szakaszokra bontva, hogy lehetővé tegyék a rögzített licitálású és a meghatározott fázist egy kisebb szakaszban, de a projekt egészének folyamatos megtartása mellett.
A jövőbeni csapatok formájától függetlenül egyértelmű, hogy az agilis módszertan fejlesztése itt marad. Ez lehetővé tette a rugalmasságot, az idő és a költségek előnyeit, mindemellett a legfontosabb tényezőt: az elégedettség érzetének és motiváló légkörének megteremtését az ezen projektekben dolgozó emberek számára.
Forrás:
Az agilis manifesztumhoz és a 12 agilis alapelvhez - www.agilemanifesto.org
Kapcsolódó tanfolyamok: -
Agilis projektmenedzsment - Tanulja meg az agilis módszertant