Vodni vodni projekti - danes večina IT-ekip gleda na sprejemanje sistemov Agile Project Management. Vendar pa na koncu sprejmejo sisteme Agile Project Management v svoje projekte. To pomeni kombinacijo tradicionalnih sistemov vodenja projektov (imenovanih vodenja vodnih projektov) v kombinaciji z načeli agilnega upravljanja, kot je podrobno opisano v prvotnem manifestu agilnosti.
Ker več projektov po vsem svetu vključuje prakse Agile Project Management, ali to pomeni konec vodenja projektov slapov? Ali bodo vsi IT projekti na koncu postali Agile Project Management?
Da bi razumeli različne modele, vključno z Agile, in uporabili tistega, ki je najbolj primeren za vašo situacijo, je najprej treba razumeti, kaj sploh predstavlja tradicionalni sistem upravljanja projektov, imenovan model vodenja projektov Waterfall.
Za model vodenja projektov slapov, ki je bil tako imenovan zaradi narave procesa dela, je značilno naslednje:
- Končni izdelek najprej predstavimo zelo podrobno.
- Nato se stopnje delovnega toka izvedejo po zaporedju:
- Zahteve in analiza
- Oblikovanje
- Izvajanje
- Testiranje
- Namestitev
- Vzdrževanje
- Načrt projekta mora biti brezhiben, ker ko je faza v zaporedju končana, razvijalci ne morejo znova pregledati istega, ne da bi načrtovanje začeli znova.
- Možnosti za spremembe ali napake je malo in projektnemu načrtu je treba skrbno slediti.
Izvor vodenja modela vodenja projektov:
V zgodnji fazi IT industrije ni bilo posebnega modela za razvoj programske opreme.
Torej, industrija je sprejela zaporedni model delovnega toka, ki se uporablja v predelovalni in gradbeni industriji. Te panoge so imele dobro opredeljene faze dela in razvili so model, ki je zadoščal njihovim potrebam po strogem nadzoru stroškov. Torej je bil model strojne industrije uporabljen za programsko industrijo.
Winston W Royce je prvič predstavil ta model leta 1970, vendar ni uporabil izraza "Vodenje projektov slapov". Pravzaprav je model predstavil kot pomanjkljiv. Slikovni prikaz modela je izgledal kot kaskadni slap. Thomas E. Bell in TA Thayer sta pozneje uporabila izraz "slap" v svojem dokumentu iz leta 1976, "Zahteve po programski opremi: Ali so res težava?", In izraz je ostal.
Obstaja več različic tega modela. Spodaj so pojasnjene pogosto uporabljene šest različnih faz v modelu upravljanja vodnih projektov. Vendar se lahko, odvisno od projekta, dve fazi združita.
Poglejmo primer gradnje šole kot primer za boljše razumevanje modela upravljanja vodnih projektov.
-
Zahteve in faza analize:
Najprej moramo natančno vedeti, kaj načrtujemo. Za to bi morda želeli:
- Vodite podrobne razprave s stranko
- Poskusite jasno predstaviti izdelek z najsodobnejšimi podrobnostmi
- Analizirajte, katere strojne in programske komponente so potrebne
- Navedite podrobnosti, ki vključujejo: težavo, ki jo mora izdelek rešiti, omejitve kupca, raven zmogljivosti in združljivost z že obstoječimi sistemi.
- Izvedite študije primerov podobnega izdelka.
- Upoštevajte zahteve vsake zainteresirane strani
- Navedite specifikacije v dokumentu z zahtevami za izdelek, ki tvori vhod za naslednji korak.
V našem primeru gradnje šole v tem koraku navajamo število učilnic, material, ki ga je treba uporabiti za gradnjo, potrebne ljudi, že obstoječo infrastrukturo. Zabeležili bi tudi, kaj zahteva vodstvo šole (pisarna, soba za osebje) in kaj potrebujejo učenci (boljša stranišča, igrišča)
-
Oblikovanje:
V fazi načrtovanja je vse, kar je bilo vizualno prikazano v prvi fazi, izdelano v načrtu.
Pri IT projektih to vključuje opredelitev:
- Strojna oprema, ki se bo uporabljala
- Programska platforma, ki jo je treba uporabljati, vključno z lokalno uporabo ali oblakom
- Arhitektura programske opreme, vključno z različnimi komponentami in moduli, ki jih je treba ustvariti
- Vložki, potrebni za uspešno delovanje projekta
- Rezultati, ki jih je mogoče pričakovati (v idealnem primeru bo to sinhronizirano z zahtevami, podrobno opisanimi v prejšnji fazi)
Obstajata dve vrsti zasnove, ki se začneta uporabljati v programskem projektu:
- Logična zasnova
- Fizična zasnova
Logična zasnova:
To vključuje osnovne podatke in procese, ki bodo vključeni v projekt. Podrobno določa obliko obrazcev in poročil, oblikovanje vmesnika in zasnovo baze podatkov. Na primer, za spletno mesto za vozovnice vozov bo ta zasnova določila, kako bo deloval celoten postopek: zaslon, na katerem potnik vnese svoje podatke in kako se bodo ti podatki pretakali v bazo podatkov, pa tudi, v kakšno vrsto baze podatkov bodo te podrobnosti shranjene.
Fizična zasnova:
To zadeva oblikovanje fizične baze podatkov, programov in procesov ter porazdeljenih sistemov. To se naredi po logični zasnovi in bo vsebovalo "kako" projekt, ki se bo izvajal: strojna oprema, platforma, na kateri bo razvit, različne baze podatkov, zasloni in obrazci, ki se bodo uporabljali itd.
-
Izvajanje:
- Tukaj poteka dejanski razvoj programske opreme / sistema.
- Vhod v to fazo so specifikacije za projektiranje iz prejšnje faze.
- Izhod je ena ali več komponent izdelka, vgrajene v specifikacije, odpravljene napak, preizkušene in integrirane, da zadovoljijo sistemsko arhitekturo.
- Za to fazo običajno poskrbi razvojna skupina, ki jo sestavljajo programerji, oblikovalci vmesnikov in drugi strokovnjaki, orodja pa so prevajalniki, razhroščevalci, tolmači in urejevalniki medijev.
- Ta faza običajno traja največ časa in pomembno je, da skrbno spremljate procese in oblikovanje. Spremembe zasnove na tej stopnji so težko vodljive pri vodenju projektov.
- Pri velikem projektu, ki vključuje več skupin, se priporoča nadzor nad različicami za sledenje sprememb kode drevesa in vrnitev na prejšnje posnetke za ravnanje z napakami.
- V našem primeru: dejansko gradnja stavbe z uporabo delovne sile in materialov je izvedena na tej stopnji.
-
Testiranje:
Testiranje se lahko izvede za izdelek kot celoto ali za posamezne sestavne dele. "Preskusni primeri" je mogoče preveriti, ali lahko izdelek dostavi, kot je bilo obljubljeno. Na voljo je testiranje modulov, sistemsko testiranje integriranega izdelka in sprejemno testiranje. Preverjanje sprejemljivosti vključuje preizkušanje izdelka na vrzeli s strani končnega uporabnika ali stranke. Napake se zapišejo, da jih mora izvajalska skupina odpraviti. Ko so popravki, se pripravi uradna dokumentacija izdelka.
Na primer, infrastrukturo šole preizkuša, verjetno revizijska skupina. V nekaterih primerih so učitelji povabljeni, da pridejo v prostore in posredujejo povratne informacije.
-
Namestitev:
Ko je preizkušanje izdelka končano v vseh pogledih, ga lahko izdelek sprosti na trg ali namesti v prostorih stranke. Na tej stopnji se preda tudi celotna dokumentacija izdelka.
V primeru naše šole je to uradno odprto (po možnosti z velikim strelom!) In šola začne z delom!
-
Vzdrževanje:
V tej fazi IT-ekipa odpravi vse težave, ki se lahko pojavijo, ko stranka izdelek dejansko začne uporabljati ali ko pride do izboljšave izdelka. Dobra dokumentacija je temelj vzdrževanja. Težave se odpravljajo s spreminjanjem kod, imenovanimi "obliži".
Če so potrebne večje spremembe, se lahko projekt vrne v razvojno skupino kot nov projekt.
V našem primeru šola potrebuje redno vzdrževanje, večinoma infrastrukturno, na primer okvarjeno električno ožičenje ali puščanje kopalnic. Te težave je treba občasno reševati.
Kot že vidite, so faze upravljanja vodnih projektov za razvoj slapov ločene, in čeprav je s stranko običajno stalna interakcija, gre predvsem za razpravo o napredku projekta, ne o načrtovanju ali zahtevah. Kljub temu pa je model upravljanja vodnih projektov ustrezni IT industriji služil že vrsto let, pri večini projektov pa so faze še vedno dobre, vendar niso tako toge.
Obstaja pa več projektov, za katere je zelo primeren model upravljanja vodnih projektov.
Za kakšen projekt je primeren projekt Vodenjak vodenja?
Opredelitev izdelka:
Prvič, končni rezultat (izdelek) mora biti sposoben natančno definirati na začetku. Projekti, v katerih lastnik izdelka ni zelo prepričan o natančnih specifikacijah želenega izdelka, lahko dobro sledijo praksam Agile Management.
Dokumentacija:
Projekt bi moral biti dokument, ki ga je mogoče dokumentirati. Dokumentacija je pomembna zahteva modela vodenja projektov slapov. Zahteve za izdelek, oblikovanje in izvorna koda morajo biti jasno dokumentirane v vseh fazah. Če prvotni člani ekipe odidejo, je to vodnik za kontinuiteto projekta.
Čas in sredstva:
Izdelka ne sme biti takoj. Časovni roki so določeni na začetku projekta in ekipa se jih mora držati. Poleg tega morajo biti na voljo dovolj virov na področju delovne sile in tehnologije.
Tveganje in negotovost:
Orodja za upravljanje projektov slapov ne delujejo dobro v okolju tveganja in negotovosti. Na primer, aplikacija Mobile je vrsta izdelka, ki se sooča s stalno negotovostjo glede sprejemanja strank in konkurence podobnih aplikacij.
Jasno opredeljene stopnje:
Stopnje sistema bi morale biti natančno opredeljene, saj jih je treba dokončati v zaporedju in ne sme biti prekrivanja.
Ko se ustvarja nova različica obstoječe programske opreme.
Zunaj področja IT je bil model vodenja projektov uspešno uporabljen v velikih projektih, kot so
- Zgradba letala
- Infrastrukturni projekti, kot so mostovi
- Izdelava obrambne opreme
- Zdravstveni sistemi v bolnišnicah
V IT projektih je Waterfall Project Management še posebej primeren za tiste projekte, pri katerih je potrebna zunanja strojna oprema. Specifikacije tega ni mogoče spremeniti na sredini, ker bi to povzročilo izgubo v milijonih dolarjev.
Ko so se v programski industriji pokazale pomanjkljivosti v vodnem projektu vodenja, se je veliko razmišljalo, kako IT ekipe lahko strankam zagotavljajo največjo vrednost, hkrati pa zagotavljajo fleksibilnost v procesu dela.
In tako se je rodil Agile Project Management System, ki ga zdaj sprejema večina programskih podjetij.
Vodni projekt vodenja proti Agile Systems:
Sistem Agile Project Management je prilagodljiv model, ki je postal priljubljen v devetdesetih letih. Vključuje razdeljevanje projekta na „mini projekte“, imenovane šprinti, in neodvisno delo na vsakem od njih. Takšen model omogoča razvijalcem, da hitreje vključijo zahtevane spremembe in je zelo učinkovit tam, kjer je uporabniško okolje spremenljivo.
Pozitivni koraki vodenja projekta slapov so:
- Ker je končni izdelek znan v celoti, sta načrtovanje in oblikovanje nedvoumna.
- Potencialne težave, ki bi se lahko pojavile pri projektu, je mogoče odkriti v sami fazi oblikovanja; preden je bila napisana katera koli koda.
- Merjenje napredka dela je enostavno, saj so stopnje dobro opredeljene.
- Stabilnost ekipe je tam, saj skupina ostane do konca projekta. V primeru Agile se ekipa nenehno spreminja in to zahteva določeno prilagoditev.
- Dokumentacija je obsežna, kar ekipam olajša upravljanje, če član zapusti.
- Razvojniki menijo, da je s tem modelom lažje delati, saj ga je enostavno razumeti,
- Po fazi zahteve je potrebno aktivno sodelovanje končnega kupca samo v fazi testiranja. To je zato, ker so bile o vseh zahtevah razpravljane niti, kar ne dopušča dvoumnosti.
- Izdelek je mogoče razviti kot celoto, namesto da bi ga razvijali v delih.
- Vprašanja glede upravljanja s pogodbami in strankami se bolje rešujejo v modelu vodenja projektov Waterfall.
Pozitivni ukrepi Agile Project Management so:
- Stranka lahko v celotnem ciklu komunicira s projektno skupino in lahko občasno spreminja izdelek, da ustreza spremenljivemu okolju.
- Če je treba izdelek zaradi tržnih okoliščin izpustiti zelo kmalu, lahko skupina Agile Project Management izda osnovno različico, ki ima lahko pozneje tudi napredne različice.
- Sistem je s stališča kupca precej pregleden in ima pošteno predstavo o stopnji, v kateri je njegov izdelek.
- Ker stranka zagotavlja prednost funkcij, tim ve, da se mora osredotočiti na funkcije, ki ponujajo največ poslovne vrednosti.
- Proces ima svoj zagon.
- Ekipe so tekoče in prilagodljive, kar omogoča idejo vsakega člana
- Dokumentacija je minimalna, zato se pri teh nalogah sprosti čas.
Po mnogih letih obeh modelov, ki obstajata drug ob drugem, je očitno:
Model upravljanja s slapovi je učinkovit za vodenje projektov, kjer se po projektu izvedejo minimalne spremembe.
Agile Project Management je bolj primeren za upravljanje izdelkov, kjer je pomembno, da je prilagodljiv spremembam.
Ne glede na to sistem vodenja projektov Waterfall ostaja pomemben sestavni del večine IT projektov. Ne moremo zagotovo reči, da določen projekt dosledno upošteva Agile Management Practices. Običajno so načela Agile "vključena" v IT projekte.
Nekateri Agile Project Management imajo vodje projektov, strogo Agile model pa imajo samo Scrum Masters. To so hibridne kombinacije modelov upravljanja s projekti Agile in Waterfall, ki jih nekateri imenujejo "Agifall" ali "Agency Agile".
Priljubljenost sistema vodenja projektov Waterfall je tudi posledica dejstva, da se vprašanja upravljanja pogodb in strank bolje rešujejo z metodami vodenja projektov Waterfall.
Medtem ko vse več projektov spada pod sklop Agile Project Management in čedalje več podjetij vidi prednosti fleksibilnega modela upravljanja, priljubljenost modela vodenja projektov Waterfall nedvomno pada.
Vendar je težko predvideti prihodnost za IT-projekte, ki bodo v bližnji prihodnosti povsem prilagodljivi. Vodno vodenje projektov, ki je programski industriji pomagalo že v povojih, se bo nadaljevalo v nekaj sestavnih delih projektnega upravljanja vsaj še nekaj let.
Prvi vir slike: picjumbo.com
povezani članki
- 6 koristne faze delovnega toka pri vodenju projektov slapov
- Učinkoviti nasveti za skupinsko razpravo (strokovni nasveti)
- Najboljših 10 mitov o upravljanju projektov
- 6 Učinkoviti razlogi Vsakdo potrebuje projekt strasti pri delu
- Top 5 vrst orodij za poročanje o upravljanju projektov
- Upravljanje izdelkov v primerjavi z blagovno znamko - Uporabne razlike