Upravljanje projektima vodopada - Danas većina IT timova gleda na usvajanje Agile sustava upravljanja projektima. Ali ono što na kraju rade je usvajanje sustava Agile Project Management u njihove projekte. To znači kombinaciju tradicionalnih sustava upravljanja projektima (nazvanih Sustavi upravljanja vodopadima projekata) u kombinaciji s Načelima agilnog upravljanja, kako je detaljno opisano u izvornom manifestu Agilnosti.
Kako sve više projekata širom svijeta uključuje prakse Agile Project Management, znači li to upravljanje projektima vodopada? Hoće li svi IT projekti završiti kao Agile Project Management?
Da biste razumjeli različite modele, uključujući Agile, i upotrijebili onaj koji najbolje odgovara vašoj situaciji, važno je prvo razumjeti o čemu se radi u tradicionalnom sustavu upravljanja projektima, nazvanom Model upravljanja vodenim projektima.
Model upravljanja vodopadom, tako nazvan zbog prirode procesa rada, karakterizira sljedeće:
- Krajnji se proizvod prvo vizualizira s velikim detaljima.
- Tada su faze tijeka rada implementirane u slijedu:
- Zahtjevi i analiza
- Oblikovati
- izvršenje
- Testiranje
- Montaža
- Održavanje
- Projektni plan trebao bi biti siguran, jer nakon što je faza u nizu dovršena, programeri ga ne mogu ponovno pregledati bez ponovnog pokretanja planiranja.
- Malo je prostora za promjene ili pogreške i projektni plan mora se pažljivo pridržavati.
Porijeklo modela upravljanja vodopadom:
U ranim fazama IT industrije nije postojao određeni model razvoja softvera.
Dakle, industrija je usvojila slijedni model tijeka rada koji se koristi u proizvodnoj i građevinskoj industriji. Te su industrije imale dobro definirane faze rada i razvili su model koji je udovoljio njihovim potrebama za strogom kontrolom troškova. Dakle, model hardverske industrije primijenjen je na softversku industriju.
Winston W Royce prvi je model predstavio 1970. godine, ali nije koristio izraz "Upravljanje projektima vodopada". Zapravo je model predstavio kao pogrešan. Slikoviti prikaz modela izgledao je poput kaskadnog vodopada. Thomas E. Bell i TA Thayer kasnije su koristili izraz „vodopad“ u svom radu iz 1976., „Softverski zahtjevi: Jesu li oni zaista problem?“, A taj je termin ostao.
Postoji nekoliko varijanti ovog modela. U nastavku se objašnjavaju najčešće korištene šest različitih faza u modelu upravljanja vodopadom. Međutim, ovisno o projektu, dvije faze se mogu kombinirati zajedno.
Razmotrimo primjer izgradnje škole kao primjer za bolje razumijevanje modela upravljanja vodenim projektima.
-
Zahtjevi i faza analize:
Prvo moramo znati što točno projektiramo. U tu svrhu možda želimo:
- Vodite detaljne rasprave s kupcem
- Pokušajte jasno vizualizirati proizvod uz njegove najsitnije detalje
- Analizirajte koje su hardverske i softverske komponente potrebne
- Navedite detalje koji uključuju: problem koji proizvod treba riješiti, korisnička ograničenja, razinu performansi i kompatibilnost s već postojećim sustavima.
- Provedite studije slučaja za sličan proizvod.
- Razmotrite zahtjeve svakog dionika
- Navedite specifikacije u dokumentu sa zahtjevima za proizvod, koji tvori ulaz za sljedeći korak.
U našem primjeru izgradnje škole, u ovom koraku nabrajamo broj učionica, materijal koji će se koristiti za izgradnju, potrebne ljude, već postojeću infrastrukturu. Također bismo zabilježili što zahtijevaju uprave škole (uredska prostorija, soba za osoblje) i što učenici zahtijevaju (bolji zahodi, igrališta)
-
Oblikovati:
U fazi dizajna sve što je vizualizirano u prvoj fazi izrađeno je u nacrtu.
U IT projektima to uključuje definiranje:
- Hardver koji će se koristiti
- Softverska platforma koja se koristi, uključujući lokalnu upotrebu ili upotrebu u oblaku
- Softverska arhitektura, uključujući različite komponente i module koji se trebaju stvoriti
- Uputi potrebni za uspješan rad projekta
- Rezultati koji se mogu očekivati (u idealnom slučaju to će se sinkronizirati sa Zahtjevima koji su detaljno opisani u ranijoj fazi)
Postoje dvije vrste dizajna koje se igraju u softveru:
- Logički dizajn
- Fizički dizajn
Logički dizajn:
To uključuje osnovne podatke i procese koji će biti uključeni u projekt. U njemu su detaljno prikazani obrasci i izvještaji, dizajn sučelja i dizajn baze podataka. Na primjer, za web mjesto vlaka koji nudi kartu ovaj će dizajn odrediti kako će funkcionirati cijeli proces: zaslon na kojem putnik unosi svoje detalje i kako će ti podaci teći u bazu podataka, kao i koja će vrsta podataka pohranjivati te detalje.
Fizički dizajn:
To se odnosi na dizajn fizičke baze podataka, programa i procesa te distribuiranih sustava. To je učinjeno nakon logičkog dizajna i uključivat će „kako“ projekt biti izveden: hardver, platformu na kojoj će se razvijati, razne baze podataka, ekrane i obrasce koji će se koristiti itd.
-
provedba:
- Ovdje se odvija stvarni razvoj softvera / sustava.
- Ulaz u ovu fazu predstavljaju projektne specifikacije date u prethodnoj fazi.
- Izlaz je jedna ili više komponenti proizvoda ugrađene u specifikacije, ispravljanje pogrešaka, testirano i integrirano da zadovolji arhitekturu sustava.
- Ovu fazu obično vodi razvojni tim koji se sastoji od programera, dizajnera sučelja i ostalih stručnjaka, a alat koji se koristi jesu kompajleri, ispravljači pogrešaka, tumači i urednici medija.
- Ova faza obično traje maksimalno vrijeme i važno je marljivo pratiti procese i dizajn. Izmjene dizajna u ovoj fazi su teške u upravljanju projektima vodopada.
- Za veliki projekt koji uključuje nekoliko timova, preporučuje se kontrola verzija radi praćenja promjena u stablu kodova i vraćanja na prethodne snimke radi rukovanja pogreškama.
- U našem primjeru: Stvarna gradnja zgrade upotrebom rada i materijala vrši se u ovoj fazi.
-
Testiranje:
Ispitivanje se može obaviti za proizvod u cjelini ili za pojedinačne komponente. "Test slučajevi" se može provjeriti da li se proizvod može isporučiti onako kako je obećano. Može se testirati modul, testirati sustav integriranog proizvoda i testiranje prihvatljivosti. Ispitivanje prihvatljivosti uključuje testiranje proizvoda na rupe od strane krajnjeg korisnika ili kupca. Zabilježeni su nedostaci koje treba primijeniti tim koji implementira. Nakon što se naprave ispravke, priprema se službena dokumentacija proizvoda.
Na primjer, školska infrastruktura je testirana, vjerojatno revizorski tim. U nekim su slučajevima nastavnici pozvani da uđu i koriste prostorije za pružanje povratnih informacija.
-
Montaža:
Nakon što je ispitivanje proizvoda završeno u svim aspektima, proizvod se može pustiti na tržište ili instalirati u prostorijama kupca. U ovoj se fazi predaje i kompletna dokumentacija proizvoda.
U slučaju naše škole, ona je svečano otvorena (po mogućnosti velikim hicem!) I škola započinje s operacijama!
-
Održavanje:
U ovoj fazi IT tim rješava sve probleme koji se mogu javiti nakon što kupac stvarno počne koristiti proizvod ili kada dođe do poboljšanja proizvoda. Dobra dokumentacija je okosnica održavanja. Problemi se otklanjaju mijenjanjem kodova koji se nazivaju "zakrpe".
Ako su potrebne značajne promjene, projekt se može vratiti razvojnom timu kao novi projekt.
U našem primjeru, školi je potrebno redovito održavanje, uglavnom infrastrukturno, na primjer, neispravno električno ožičenje ili propuštaju kupaonice. Te bi se probleme trebalo povremeno rješavati.
Kao što vidite do sada, faze upravljanja vodenim projektima za razvoj vodopada su različite, i iako obično postoji stalna interakcija s klijentom, prvenstveno je raspravljati o napretku projekta, a ne o dizajnu ili zahtjevima. Međutim, model upravljanja vodostajem projekata adekvatno je služio IT industriji već dugi niz godina, a za većinu projekata, faze su i dalje dobre, iako nisu tako krute.
Postoji, međutim, nekoliko projekata za koje je model upravljanja vodopadom vrlo pogodan.
Kakav je projekt pogodan za upravljanje vodenim projektima?
Definicija proizvoda:
Prvo, krajnji rezultat (proizvod) mora biti sposoban da bude dobro definiran na samom početku. Projekti u kojima vlasnik proizvoda nije baš siguran u točne specifikacije željenog proizvoda mogu dobro slijediti postupke Agile Management.
Dokumentacija:
Projekt bi trebao biti dokument koji se može dokumentirati. Dokumentacija je važan zahtjev modela upravljanja vodopadom. Zahtjevi proizvoda, dizajn i izvorni kod moraju biti jasno dokumentirani u svim fazama. Ako izvorni članovi tima odustanu, to čini vodič za kontinuitet projekta.
Vrijeme i resursi:
Ne smije biti trenutna hitnost za puštanjem proizvoda. Rokovi su postavljeni na početku projekta i tim se mora moći pridržavati. Također, moraju biti na raspolaganju brojni resursi u pogledu radne snage i tehnologije.
Rizik i nesigurnost:
Alati za upravljanje projektima vodopada ne rade dobro u okruženju rizika i nesigurnosti. Na primjer, aplikacija Mobile je vrsta proizvoda koja se suočava s stalnom nesigurnošću u pogledu prihvaćanja kupaca i konkurencije sličnih aplikacija.
Jasno definirani stadiji:
Faze sustava trebaju biti dobro definirane jer se moraju dovršiti redoslijedom i ne može se preklapati.
Kada se kreira nova verzija postojećeg softvera.
Izvan IT domene, model upravljanja vodopadom uspješno se koristi u velikim projektima poput
- Zgrada aviona
- Infrastrukturni projekti poput mostova
- Proizvodnja obrambene opreme
- Zdravstveni sustavi u bolnicama
U IT projektima, Waterfall Project Management posebno je prikladan za one projekte u kojima je potreban vanjski hardver. Specifikacije ovoga ne mogu se mijenjati na pola puta jer to rezultira gubitkom milijuna dolara.
Kada su se u softverskoj industriji očito pojavile nedostatke u upravljanju projektima vodopada, razmišljalo se o tome kako IT timovi mogu pružiti maksimalnu vrijednost klijentima, istovremeno osiguravajući fleksibilnost u procesu rada.
I tako je nastao Agile sustav upravljanja projektima, koji sada usvaja većina softverskih kompanija.
Upravljanje vodopadom vs Agile Systems:
Sustav upravljanja projektima Agile fleksibilan je model koji je postao popularan u 1990-ima. To uključuje raščlanjivanje projekta na „mini projekte“ zvane sprint i neovisan rad na svakom od njih. Ova vrsta modela omogućava programerima da brže ugrade potrebne izmjene i vrlo je učinkovit tamo gdje je okruženje kupca promjenjivo.
Pozitivni koraci upravljanja vodostajem projekta su:
- Budući da je krajnji proizvod poznat u cijelosti, planiranje i dizajn su nedvosmisleni.
- Potencijalna pitanja koja bi se mogla pojaviti u projektu mogu se glačati tijekom same faze dizajna; prije nego što je bilo koji kod napisan.
- Izmjeriti napredak rada je jednostavno, jer su faze dobro definirane.
- Stabilnost tima je tu jer tim ostaje do kraja projekta. U slučaju Agile-a, ekipa se neprestano mijenja i to zahtijeva određeno prilagođavanje.
- Dokumentacija je opsežna, što ekipama olakšava upravljanje ukoliko član ode.
- Programeri smatraju da je s ovim modelom lakše raditi, jer je lako razumjeti,
- Nakon faze Zahtjevi, aktivno sudjelovanje krajnjeg kupca potrebno je samo u fazi testiranja. To je zbog toga što su svi zahtjevi raspravljani na dno, ne ostavljajući nikakve dvosmislenosti.
- Proizvod se može razviti u cjelini, umjesto da ga razvijate u dijelovima.
- Pitanja upravljanja ugovorima i klijentima bolje se rješavaju u okviru Model upravljanja vodopadom.
Stavovi Agile Project Management su:
- Kupac može komunicirati s projektnim timom tijekom cijelog ciklusa i može povremeno mijenjati proizvod kako bi odgovarao promjenjivom okruženju.
- Ako se proizvod mora uskoro izbaciti zbog tržišnih okolnosti, tim Agile Project Management može izdati osnovnu verziju koja može imati napredne verzije kasnije.
- Sustav je s transparentnog stajališta kupca prilično transparentan i on ima dobru predodžbu o fazi u kojoj se nalazi njegov proizvod.
- Budući da klijent daje prednost značajki, tim zna da se mora usredotočiti na značajke koje nude najviše poslovne vrijednosti.
- Proces ima svoj zamah.
- Timovi su fluidni i fleksibilni što omogućava ideju svakom članu
- Dokumentacija je minimalna i tako se vrijeme oslobađa od tih zadataka.
Nakon mnogih godina oba modela koja su postojala jedan pored drugog, očito je da:
Model upravljanja vodostajem projekata učinkovit je za upravljanje projektima, gdje jednom kada se projekt provede, dolazi do minimalnih promjena.
Agilno upravljanje projektima više odgovara menadžmentu proizvoda gdje je važno biti fleksibilan prema promjenama.
Bez obzira na to, sustav upravljanja vodostajima projekata i dalje je važan sastavni dio većine IT projekata. Ne može se reći sa sigurnošću da određeni projekt strogo slijedi Agile Management Practices. Obično su Agile načela "ugrađena" u IT projekte.
Neki Agile Project Management imaju voditelje projekata dok strogo agile model imaju samo Scrum Masters. Ovo su hibridne kombinacije modela upravljanja projektima Agile i Vodopad koji neki nazivaju „Agifall“ ili „Agency Agile“ projekti.
Popularnost sustava za upravljanje projektima vodopada također je posljedica činjenice da se problemi upravljanja ugovorima i klijentima bolje rješavaju metodama Waterfall Project Management.
Iako sve više i više projekata propada pod okretnim projektom upravljanja, a sve više tvrtki vidi prednosti fleksibilnog modela upravljanja, popularnost modela upravljanja vodenim projektima zasada nesumnjivo opada.
Međutim, teško je zamisliti budućnost IT projekata koji će u potpunosti biti agilni u skoroj budućnosti. I Waterfall Project Management, koji je pomogao softverskoj industriji u ranom dobu, nastavit će se živjeti u nekoliko komponenti upravljanja projektima barem još nekoliko godina koje dolaze.
Prvi izvor slike: picjumbo.com
povezani članci
- 6 korisnih faza tijeka rada u upravljanju projektima vodopada
- Učinkoviti savjeti za grupnu raspravu (stručni savjeti)
- 10 najboljih mitova o upravljanju projektima
- 6 Učinkovitih razloga svima je potreban projekt strasti na djelu
- Top 5 vrsta alata za izvješćivanje o upravljanju projektima
- Upravljanje proizvodima u odnosu na upravljanje robnom markom - korisne razlike