Szoftverprojekt-módszertan: hogyan válasszunk a Waterfall, Agile, Scrum, Kanban, DevOps és hibrid között

Mi az a szoftverprojekt-módszertan, és miért számít a választás

A szoftverprojekt-módszertan egy strukturált megközelítés, amely meghatározza, hogyan tervezik, hajtják végre és szállítják le a szoftverprojektet. Fázisokat (vagy azok szándékos hiányát), szerepeket, munkatermékeket, ritmusokat és döntési mintákat ír elő. A különböző módszertanok különböző eredményekre optimalizálnak: a Waterfall a kiszámíthatóságra és a dokumentációra, az Agile az alkalmazkodóképességre és az értékszállításra, a DevOps a kiadási sebességre és az üzemeltetési integrációra. Egyetlen módszertan sem egyetemesen jobb; mindegyik jobb egy adott feltételrendszerhez. A projektmenedzser feladata nem a kedvence kiválasztása, hanem a módszertan hozzáigazítása az adott projekthez.

A választás nem kozmetikai. A Wellingtone 2024-es State of Project Management Report jelentése szerint a szervezeteknek csupán 34%-a fejezi be a projekteket határidőre és 34%-a a költségvetésen belül, és bár a módszertan csak egy változó, ez egy irányítható változó. A stabil követelményű, Agile-ban futó projektek gyakran pazarolják az erőfeszítést olyasmi újratervezésére, aminek sosem kellett volna változnia; az illékony követelményű, Waterfallban futó projektek gyakran egy olyan tervvel szemben szállítanak, amely már nem felel meg az üzleti igénynek. Mindkét kudarcmód elkerülhető a módszertan kiválasztásával, és mindkettő gyakori azoknál a szervezeteknél, amelyek csapatpreferencia, nem pedig a projekthez való illeszkedés alapján választanak.

A projektmenedzser vagy PMO-elemző számára a döntési keret azért számít, mert a módszertan megválasztása a projekt egyik legkorábbi döntése és az egyik legnehezebben visszafordítható. Módszertant váltani a projekt közben lehetséges, de költséges: a szerződések, a szponzor elvárásai, az eszközök és a csapat képességei mind egy módszertanhoz igazodnak, és az irányváltás mindegyik újraigazítását jelenti. Az alábbi öt módszertan plusz a hibrid lefedi a szoftverprojektek többségét; a jó választás az elején elkerüli a későbbi átalakítást.

Az öt fő szoftverprojekt-módszertan egy pillantásra

Az alábbi táblázat összefoglalja az öt fő módszertant plusz a hibridet, gyors áttekintést adva a részletes szakaszok előtt. Minden sor megválaszolja azokat a kérdéseket, amelyeket egy projektmenedzser először tesz fel: hogyan szerveződik a munka, mi a ritmus, mire a legjobb, miben gyenge.

A cikk további része minden módszertant részletesebben tárgyal, majd következik a döntési keret a közöttük való választáshoz.

Waterfall: kiszámítható, tervvezérelt, szekvenciális

A Waterfall módszertan, amelyet Winston Royce formalizált egy 1970-es cikkben (ironikus módon egy általa hibásnak tartott megközelítést leírva), a szoftverprojektet egymásba folyó szekvenciális fázisokba szervezi: követelménygyűjtés, rendszertervezés, megvalósítás, integráció és tesztelés, telepítés és karbantartás. Minden fázis lezárul, mielőtt a következő elkezdődne, és egy korábbi fázishoz való visszatérés jelentős eseménynek számít, amely formális változáskezelést igényel. A módszertan fegyelme abból a feltételezéséből fakad, hogy a követelmények előre meghatározhatók, és a végrehajtás során nem változnak lényegesen.

A Waterfall nem az az elavult relikvia, amelyet az Agile marketing olykor sugall. Több helyzetben is a helyes választás marad. A szabályozott iparágak (gyógyszeripar, légi közlekedés, védelem, pénzügyi megfelelőség) gyakran megkövetelik a teljes előzetes dokumentációt és minden fázis formális validálását, amit a Waterfall természetesen biztosít. A rögzített hatókörű, rögzített határidejű szerződések (állami projektek, beszállítói szállítandók) profitálnak a Waterfall azon egyértelműségéből, hogy mit és mikor szállítanak. A végrehajtás során magas változtatási költségű projektek, mint a fizikai infrastruktúra, a hardverintegráció vagy az összetett szabályozói jóváhagyások, illeszkednek a Waterfall azon fegyelméhez, hogy a követelményeket az építés előtt kell helyesen meghatározni. A kiszámíthatóság, amelyet a Waterfall kikényszerít, pontosan az, amire ezeknek a projekteknek szükségük van.

A Waterfall gyengeségei erősségeinek tükörképei. Amikor a követelmények a végrehajtás során megváltoznak, a Waterfall formális változáskezelése olyan költséget és időt ad hozzá, amit az agilis módszertanok a normál iterációba építenének be. A visszajelzés későn érkezik, gyakran csak az integrációs tesztelés során, így a hibák és félreértések jelentős befektetés után bukkannak fel. Az üzleti érték szállítása a projekt végére tolódik, így ha a projektet korán leállítják, semmi használható nem készült el. A módszertan bizonyos projektekhez rendkívül jól illik; nem illik olyan projektekhez, ahol valódi bizonytalanság van azzal kapcsolatban, mit kell megépíteni. A Waterfall módszertani útmutatónk részletesebben tárgyalja a fázisokat és végrehajtásukat.

Agile: iteratív, alkalmazkodó, értékvezérelt

Az Agile nem egyetlen módszertan, hanem egy ernyőkeret, amely több konkrét módszert foglal magában (Scrum, Kanban, Extreme Programming, Crystal és mások). Ami összeköti őket, az a 2001-es Agilis Kiáltvány, amely az egyéneket és az interakciókat a folyamatok és eszközök elé helyezte, a működő szoftvert az átfogó dokumentáció elé, az ügyféllel való együttműködést a szerződéses tárgyalás elé, és a változásra való reagálást a terv követése elé. Tizenkét alapelv teszi működőképessé ezeket az értékeket: működő szoftver gyakori szállítása, a változó követelmények üdvözlése, önszerveződő csapatok, fenntartható tempó és mások. A Kiáltvány értékei nem tervezés- vagy dokumentációellenesek; prioritásokat állítanak fel, amikor kompromisszumokra van szükség.

Az Agile olyan projektekhez illik, amelyeknek fejlődő követelményei, bizonytalan hatóköre, magas a korai visszajelzés értéke, és a csapatok felhatalmazottak a szállítási döntések meghozatalára. A szoftvertermék-fejlesztés, a digitális transzformációs kezdeményezések és minden olyan projekt, ahol az ügyfél fejlesztés közbeni hozzájárulása érdemben javítja az eredményt, profitál az Agile rövid ciklusaiból és folyamatos alkalmazkodásából. A módszertan ereje a szoros visszacsatolási hurokból fakad: egy kis inkrementum megépítése, megmutatása az érdekelteknek, annak megtanulása, mit kell igazítani, a következő inkrementum megépítése. Egy projekt során ez a hurok általában valami olyat hoz létre, ami közelebb áll ahhoz, amire az érdekelteknek valóban szükségük van, mint az előre megtervezett alternatívák.

Az Agile gyakorlati megvalósítása gyakori eszközproblémába ütközik: a fejlesztők erősen preferálják a Jirát, az Azure DevOpsot vagy hasonló, csapatközpontú agilis platformokat, mert ezek natívan illeszkednek a sprintmechanikához és a backlog-gondozáshoz, míg a PMO-knak portfólió szintű láthatóságra van szükségük, amit ezek az eszközök nem biztosítanak jól. A pragmatikus minta az integráció: a fejlesztők a Jirában dolgoznak, a PMO-k pedig a portfólió szempontjából releváns részhalmazt látják a PPM-rendszerükben adatszinkronizáción keresztül. A FlexiProject ezt a mintát közvetlen Jira-integrációval valósítja meg, amely importálja az epikeket, sztorikat és feladatokat az állapot, a felelős és a típus megőrzésével, így a PMO-k és a vezetés ugyanabban a portfólió-nézetben látja az agilis munkát, mint a nem agilis projekteket, anélkül hogy a csapatok eszközt váltanának. Az Agile teljesebb meghatározásáért lásd a Mi az Agile útmutatónkat; a PM/PMO operatív nézetéhez a Agilis szoftverfejlesztési projektmenedzsment a PPM-ben cikkünk részletesen tárgyalja a szállítási modellt.

Scrum és Kanban: az Agile két gyakorlati változata

A Scrum és a Kanban a két legelterjedtebb agilis módszer a szoftverfejlesztésben. Osztoznak az Agile alapértékein, de eltérően valósítják meg őket, és a közöttük való választás a csapat munkamintájától függ.

Scrum: sprintalapú Agile meghatározott szerepekkel

A Scrum az agilis munkát rögzített hosszúságú iterációkba, sprintekbe szervezi (jellemzően két hét). Minden sprint sprinttervezéssel kezdődik, ahol a csapat elkötelezi magát a termék-backlogból származó felhasználói sztorik egy csoportja mellett, és sprint-áttekintéssel (bemutató az érdekelteknek) és retrospektívvel (a csapat folyamatának javítása) zárul. Három szerep viszi a munkát: a Product Owner (rangsorolja a backlogot), a Scrum Master (facilitálja az eseményeket és elhárítja az akadályokat) és a fejlesztőcsapat (leszállítja a sprint elkötelezettségét). A Scrum jól működik olyan csapatoknál, amelyek új funkciókat építenek kiszámítható ritmusban, olyan Product Ownerrel, aki el tud kötelezni a sprint hatóköre mellett, és olyan csapattal, amely profitál az iterációs fegyelemből. A Scrum módszertani útmutatónk részletesen tárgyalja a szerepeket, eseményeket és munkatermékeket.

Kanban: folyamatos áramlás WIP-korlátokkal

A Kanban a Scrum sprinthatárait folyamatos áramlással váltja fel. A munkaelemek munkafolyamat-oszlopokon haladnak át (jellemzően Teendő, Folyamatban, Ellenőrzés, Kész) az egyes oszlopoknál folyamatban lévő munka korlátaival, ami arra kényszeríti a csapatot, hogy befejezzen, mielőtt újat kezd. Nincsenek rögzített szerepek azon túl, amivel a csapat már rendelkezik, nincsenek kötelező események (bár a legtöbb csapat bevezet napi standupokat és időszakos üzemeltetési áttekintéseket), és nincs a munka sprintekbe csoportosítása. A Kanban illik támogató csapatokhoz, DevOps-munkához, marketingkampányokhoz és minden olyan munkafolyamathoz, ahol a prioritások gyakrabban változnak, mint egy sprint hossza. A Kanban-rendszer útmutatónk a teljes módszertant tárgyalja, beleértve a hat gyakorlatot, a metrikákat és a PMO bevezetési mintáit.

A Scrum és a Kanban közötti választás nem végleges. A csapatok gyakran a Scrum struktúrájával kezdik, miközben az Agile-t tanulják, majd a Scrumban felé fejlődnek (Scrum-események Kanban-táblával és WIP-korlátokkal), ahogy munkájuk folyamatosabbá válik, végül pedig a tiszta Kanban felé, amikor a megszakítások dominálnak. A keretnek a csapat munkamintáját kell szolgálnia; a minta ritkán szolgálja a keretet.

DevOps: fejlesztés és üzemeltetés egyként

A DevOps egy módszertan, egy kultúra és gyakorlatok összessége, amely a szoftverfejlesztést és az IT-üzemeltetést egyetlen folyamatos szállítási pipeline-ba integrálja. A kifejezést Patrick Debois alkotta meg 2009 körül, a gyakorlat pedig olyan csapatokból nőtt ki, amelyek frusztrálódtak a fejlesztők (akik a kódot írták) és az üzemeltetés (amely telepítette és futtatta) közötti hagyományos fal miatt. A DevOps lebontja ezt a falat: ugyanaz a csapat birtokolja a kódot a commit-tól a produkcióig, az automatizálás pedig minden szakaszban felváltja a kézi átadásokat.

Az alapvető gyakorlatok a folyamatos integráció (CI, ahol minden kód-commit automatizált buildet és tesztet indít), a folyamatos szállítás (CD, ahol minden sikeres build automatikusan telepítésre kész), az infrastruktúra mint kód (IaC, ahol az infrastruktúra verziókövetett és szoftverként telepített), az automatizált tesztelés (egység-, integrációs, biztonsági és teljesítménytesztek automatikusan futnak) és a folyamatos monitorozás (a produkciós viselkedés visszahat a fejlesztési prioritásokra). Együtt ezek a gyakorlatok hónapokról napokra vagy órákra tömörítik a kiadási ciklust, és a telepítést ütemezett eseményből rutinműveletté alakítják.

A DevOps több jellemzővel bíró szoftverprojektekhez illik. A magas kiadási gyakoriságú felhőnatív szolgáltatások (SaaS-termékek, webalkalmazások, mikroszolgáltatások) profitálnak a DevOpsból, mert a kiadási ciklus a versenydimenzió. A produkcióba folyamatosan (nem csak a projekt végén) szállító csapatoknak szükségük van a DevOps által nyújtott automatizálásra. A termékszemléletű (nem projektszemléletű) szervezetek a szállítást folyamatosnak, nem véglegesnek tekintik, amit a DevOps lehetővé tesz. A felhőinfrastruktúra-szolgáltatók (AWS, Azure, GCP) a DevOps feltételezéseire építették eszközeiket, ami az egy évtizeddel ezelőttinél jóval egyszerűbbé teszi a bevezetést.

A DevOps nem illik minden projekthez. A kötelező negyedéves kiadási ciklusú és minden változást formálisan validáló szabályozott iparágak gyakran nem tudják befogadni a DevOps gyors telepítési ritmusát, mert az egyes telepítések validálásának megfelelőségi terhe felemésztené a sebességből származó nyereséget. Az alkalmi kiadású kis csapatok gyakran aránytalannak találják a DevOps eszközterhét a haszonhoz képest. Az automatizálásbarát architektúra nélkül épített örökölt rendszerek évekig tartó átalakítást igényelhetnek, mielőtt a DevOps-gyakorlatok érdemben működnének. Ezekben az esetekben a szelektív DevOps-gyakorlatok (CI, automatizált tesztelés) bevezetése teljes folyamatos telepítés nélkül gyakran a haszon nagy részét adja a teljes elkötelezettség nélkül.

Az eszköztáj kiterjedt, de közeledik. A CI/CD-platformok közé tartozik a Jenkins, a GitLab CI, a GitHub Actions, a CircleCI és a felhőnatív megfelelők (AWS CodePipeline, Azure Pipelines). Az infrastruktúra mint kód szabványok közé tartozik a Terraform (multi-felhő), az Ansible (konfigurációkezelés), a Kubernetes (konténerorkesztráció) és a Docker (konténerizáció). A monitorozó rendszerek metrikákat (Prometheus, Datadog), naplókat (ELK stack, Splunk) és nyomkövetést (Jaeger, OpenTelemetry) kombinálnak. A konkrét eszközök változnak; az általuk támogatott gyakorlatok stabilak maradnak. A DevOps gyakran együtt él az agilis módszertanokkal csapatszinten: Agile a tervezéshez és rangsoroláshoz, DevOps a szállításhoz és üzemeltetéshez. Ez a kombináció az, amit a legtöbb modern szoftverszervezet valójában működtet, akár így nevezi, akár nem.

Hibrid: módszertanok kombinálása a valós projektekhez

A hibrid projektmenedzsment több módszertan elemeit kombinálja olyan projektekhez, amelyek egyetlen megközelítéshez sem illeszkednek tisztán. Nem kompromisszum, hanem szándékos választás: a Waterfall fegyelmét használni ott, ahol a kiszámíthatóság számít, az Agile rugalmasságát ott, ahol bizonytalanság van, és a határokon integrálni őket. A leggyakoribb hibrid minta a szoftverprojektekben a Waterfall projektszintű tervezését (rögzített költségvetés, mérföldkő-alapú irányítás, formális jóváhagyások) kombinálja a fázisokon belüli agilis végrehajtással (iteratív fejlesztés, sprintalapú szállítás, folyamatos érdekelti visszajelzés).

A hibrid több visszatérő helyzethez illik. A megfelelőségi okokból rögzített kiadási dátumokat igénylő, de agilis végrehajtási rugalmasságot kívánó szabályozott iparágak gyakran hibridet vezetnek be: a kiadási ritmus Waterfall-stílusú (negyedévente tervezett, formális jóváhagyásokkal), míg az egyes kiadásokon belüli fejlesztés agilisan fut. A rögzített szerződésű, de bizonytalan megvalósítási részletű vállalati szoftverprojektek hibridet használnak: a szerződés elkötelezi a hatókört és a dátumokat, de a hogyan ezeken az elkötelezettségeken belül iteratívan fut. Az agilis termékcsapatokat és Waterfall infrastruktúracsapatokat vegyítő többcsapatos programoknak hibrid koordinációra van szükségük: minden csapat a saját natív módszertanát működteti, mérföldkő-alapú szinkronizációs pontokkal, amelyek összekötik őket. A hibrid projektmenedzsment útmutatónk részletesebben tárgyalja a mintákat és buktatókat.

A hibrid kockázata a szándékostól a véletlenszerű felé sodródás. Egy hibrid megközelítés, amely gondosan meghatározza, mi fut Waterfallban és mi Agile-ban, jól működik; egy hibrid megközelítés, amely a kettőt kétértelműen keveri, mert senki sem hozta meg kifejezetten a döntést, egyik fegyelmével sem végzi. A PMO szerepe a hibridben a határok kifejezetté tétele: mely döntések Waterfall-stílusúak (tervezett, jóváhagyott, formálisan módosított), melyek Agile-stílusúak (iteratív, folyamatosan igazított), és hol kapcsolódnak. Egy jól megtervezett hibrid egyesíti mindkét megközelítés erősségeit. Egy gondatlan hibrid mindkettő gyengeségeit örökli.

Hogyan válasszuk ki a megfelelő módszertant: döntési keret

A módszertan kiválasztása a projekt egyik legfontosabb korai döntése, és legjobb szisztematikusan meghozni, nem preferencia alapján. Az alábbi négy kritérium lefedi a döntés nagy részét. Minden kritérium egyes módszertanok felé és mások ellen tol, és kombinálásuk védhető választást eredményez.

A követelmények stabilitása

A messze legfontosabb kritérium az, hogy a projekt követelményei valójában mennyire stabilak (nem az, hogy a szponzor mennyire állítja stabilnak). A stabil követelmények, mint a szabályozott szállítandók, a jól meghatározott integrációk vagy egy meglévő rendszer egyértelmű specifikációkkal történő cseréje, a Waterfallhoz vagy a hibridhez illeszkednek, ahol az előzetes tervezés megragadja a megépítendő nagy részét. Az illékony követelmények, mint az új termékek, az ügyfélnek szánt funkciók, a digitális transzformáció vagy bármi piaci bizonytalansággal, az Agile-hoz, Scrumhoz vagy Kanbanhoz illeszkednek, ahol a csapat várja és üdvözli a változást. Ha bizonytalan a stabilitásban, hajoljon az Agile felé: az Agile költsége stabil követelményeknél szerény többletmunka; a Waterfall költsége illékony követelményeknél jelentős újramunkálás.

Kiadási ritmus és határidőnyomás

A második kritérium az, hogy milyennek kell lennie a kiadási ritmusnak. A rögzített hatókörű rögzített határidők (szerződéses szállítandók, szabályozói határidők, konkrét dátumokhoz kötött marketingkampányok) Waterfallt vagy hibridet igényelnek, mert előzetes elkötelezettséget követelnek arról, mit és mikor szállítanak. A kiszámítható kötegelt kiadások (funkciókiadások 6-8 hetente, termékverziók) a Scrumhoz illenek, mert a sprinthatárok természetesen egybeesnek a kiadási határokkal. A kötegstruktúra nélküli folyamatos áramlás (támogatási munka, inkrementális fejlesztések, incidensvezérelt munka) a Kanbanhoz illik. A magas kiadási gyakoriság (napi vagy óránkénti produkciós telepítések) DevOpsot igényel, mert a kézi telepítés nem tudja fenntartani a ritmust.

Csapatösszetétel és agilis érettség

A harmadik kritérium az, amit a csapat valójában végre tud hajtani. Egy több éves tapasztalattal rendelkező érett agilis csapat hatékonyan tudja működtetni a teljes Agile-t; egy Agile-ban új csapat gyakran profitál a Scrum struktúrájából tanulás közben, majd később a kevésbé előíró módszerek felé fejlődik. A fejlesztést és üzemeltetést erősen vegyítő csapatok természetesen a DevOps felé hajlanak, mert a gyakorlatok megfelelnek valóságuknak. A kötelező dokumentációval és formális validálással bíró szabályozott környezetben lévő csapatok az agilis preferenciától függetlenül a Waterfallhoz vagy a hibridhez illeszkednek, mert a megfelelőségi követelmények felülírják a módszertani filozófiát. A csapat összetétele határozza meg, mi reális, nem csak azt, mi elméletileg ideális.

Portfóliókontextus

A negyedik kritérium gyakran alulértékelt: a projekt nem elszigetelten fut, hanem egy szervezeti portfólió részeként más projektekkel. A PMO-k jellemzően vegyes portfóliókat működtetnek, ahol agilis termékmunka, Waterfall tőkeprojektek és hibrid szabályozott kezdeményezések élnek együtt. Bármely egyedi projekt módszertani választása hat a portfólió többi részére, és fordítva: egy Waterfall projekt kimeneteitől függő agilis projektnek szinkronizációra van szüksége a mérföldköveknél; egy Scrum kiadási vonatba tápláló Kanban csapatnak átadási koordinációra van szüksége. A FlexiProject úgy támogatja a vegyes portfóliókat, hogy a Kanbant a három ütemterv-nézet egyikévé teszi (feladatlista, Gantt-diagram, Kanban), így a különböző csapatok a preferált ábrázolásukban dolgozhatnak, miközben a PMO mindet egyetlen egységes portfólió-irányítópulton látja. A közvetlen Jira-integrációval kombinálva ez lehetővé teszi, hogy az agilis csapatok a mindennapi munkájukhoz a Jirában maradjanak, miközben a portfólió szempontjából releváns feladataik a FlexiProjectben jelennek meg a Waterfall projektek mellett.

GYIK: szoftverprojekt-módszertan

Mi a különbség a módszertan és a keretrendszer között?

A módszertan egy projekt kezelésének teljes megközelítése: fázisok, szerepek, munkatermékek, ritmusok és döntési minták. A keretrendszer könnyebb struktúra, amely elveket és gyakorlatokat kínál teljes előírás nélkül. A Scrumot például gyakran keretrendszernek, nem módszertannak nevezik, mert szerepeket és eseményeket ír elő, de a mérnöki gyakorlatokat nyitva hagyja. A Kanban hasonlóan keretrendszer-jellegű. A Waterfall egyértelműen módszertan, mert a teljes fázisstruktúrát előírja. Maga az Agile pontosan egyik sem, hanem inkább értékek ernyője, amelyet konkrét módszertanok és keretrendszerek valósítanak meg.

Használható-e több módszertan egy projektben?

Igen, és éppen ezt formalizálja a hibrid projektmenedzsment. Gyakori minta a projektszintű Waterfall (rögzített költségvetés, mérföldkövek, formális irányítás) fázisszintű Agile-lal (iteratív végrehajtás minden fázison belül). Egy másik a Scrum a funkciófejlesztéshez plusz a Kanban ugyanazon termék folyamatos támogatásához. A kulcs a szándékos tervezés: meghatározni, melyik módszertan hol érvényes, és hogyan kapcsolódnak a határok. A hanyag keverés hajlamos mindkettő rosszabbik felét adni a jobbik helyett.

Melyik módszertan a legjobb a kis csapatoknak?

A kis csapatok (2-6 fő) jellemzően a Kanbanból profitálnak, mert annak van a legkisebb kötelező többletterhe: nincsenek szerepek azon túl, amivel a csapat rendelkezik, nincsenek események azon túl, amit választ, csak vizualizáció, WIP-korlátok, áramláskezelés, kifejezett szabályok, rendszeres áttekintések és folyamatos fejlesztés. Az új terméket fejlesztő kis csapatok gyakran könnyített Scrumot használnak kombinált szerepekkel (egy személy játssza például a Product Ownert és a Scrum Mastert). A rögzített hatókörű szerződésekkel bíró kis csapatok az irányítás egyszerűsége miatt továbbra is használhatják a Waterfallt, mivel az Agile többletterhe aránytalan lehet az egyszerű szállításokhoz.

Hogyan kapcsolódik a DevOps az Agile-hoz?

Az Agile és a DevOps kiegészítik egymást, nem versenyeznek. Az Agile egy módszertan a fejlesztési munka szervezésére (iteratív ciklusok, adaptív tervezés, együttműködés az érdekeltekkel). A DevOps gyakorlatok összessége a fejlesztés és üzemeltetés integrálására (automatizált pipeline-ok, folyamatos szállítás, infrastruktúra mint kód). A legtöbb modern szoftverszervezet mindkettőt működteti: Agile a tervezéshez és rangsoroláshoz csapatszinten, DevOps a szállításhoz és üzemeltetéshez a szoftver életciklusán át. Egyik sem helyettesíti a másikat; különböző problémákat oldanak meg a szoftverszállítási folyamat különböző rétegein.

Milyen szerepet játszik a PMO a módszertan kiválasztásában?

A PMO szerepe, hogy kiválasztási útmutatást adjon egyetlen módszertan előírása nélkül. A portfólió különböző projektjei különböző módszertanokból profitálnak, és minden projekt egyetlen megközelítésbe kényszerítése általában csökkenti a portfólió összteljesítményét. A PMO hozzájárulása magában foglalja: kiválasztási kritériumok (a jelen cikkben szereplőhöz hasonló keretek), módszertanok között működő portfólió szintű szabványok (irányítási ritmusok, költségjelentés, kockázatkategorizálás), több módszertant egyszerre támogató eszközök és a módszertant először választó csapatok mentorálása. A PMO birtokolja a keretet; a csapatok birtokolják a választást azon belül.

A megfelelő szoftverprojekt-módszertan az, amely illik a projekt követelményeinek stabilitásához, kiadási ritmusához, csapatösszetételéhez és portfóliókontextusához, nem az, amelyiknek a legjobb a marketingje vagy a leghangosabb támogatói vannak a csapatban. A Waterfall a kiszámítható, tervvezérelt, stabil követelményű munkához működik. Az Agile az alkalmazkodó, iteratív, fejlődő követelményű munkához működik. A Scrum a kiszámítható ritmusban építő csapatokhoz működik. A Kanban a folyamatos, megszakításvezérelt munkához működik. A DevOps a fejlesztést és üzemeltetést integráló, magas gyakoriságú szállításhoz működik. A hibrid akkor működik, amikor egyetlen módszertan sem illik a projekt valós feltételeihez. A PMI Power Skills kutatása szerint 10 projektszakemberből 9 úgy véli, hogy a puha készségek, mint a kommunikáció, az empátia, az alkalmazkodóképesség és a vezetés, segítik őket okosabban dolgozni, és a módszertan önmagában sosem helyettesíti ezeket. A legjobb módszertan rossz kezekben alulmúlja a tökéletlen módszertant hozzáértő kezekben. A módszertan struktúrát ad; az emberek szállítják az eredményeket. A FlexiProject a módszertanok teljes skáláját támogatja három ütemterv-nézeten keresztül (feladatlista, Gantt-diagram, Kanban), amelyek között a csapatok válthatnak, ahogy munkamintájuk fejlődik, valamint egy közvetlen Jira-integrációval, amely portfóliószinten láthatóan tartja az agilis csapatmunkát anélkül, hogy a csapatokat kikényszerítené preferált eszközeikből. Válassza a projekthez illő módszertant; fektessen be a végrehajtó emberekbe; használjon mindkettőt támogató eszközöket. Ez az a minta, amely a projekteket a kötelezettségeiket teljesítő 34% közé viszi, nem pedig a kudarcot valló 66% közé.