Gestionarea proiectelor în cascadă - Astăzi, majoritatea echipelor IT încearcă să adopte sisteme Agile de management de proiect. Dar ceea ce sfârșesc fac este să adopte sisteme Agile de Management de Proiect pentru proiectele lor. Aceasta înseamnă o combinație de sisteme tradiționale de gestionare a proiectelor (numite sisteme de gestionare a proiectelor în cascadă), combinate cu Principiile managementului agil, așa cum este detaliat în Manifestul original Agile.
Întrucât mai multe proiecte din întreaga lume includ practici de gestionare a proiectelor Agile, asta înseamnă sfârșitul managementului proiectelor în cascadă? Toate proiectele IT vor ajunge să fie Agile Project Management?
Pentru a înțelege diferitele modele, inclusiv Agile și pentru a-l utiliza pe cel mai potrivit pentru situația dvs., este important să înțelegeți mai întâi despre ce este vorba despre sistemul tradițional de gestionare a proiectelor, numit Modelul de gestionare a proiectelor cascadei.
Modelul de gestionare a proiectului Cascadă, denumit astfel datorită naturii procesului de lucru, este caracterizat prin următoarele:
- Produsul final este vizualizat pentru prima dată în detalii deosebite.
- Apoi etapele fluxului de lucru sunt implementate în succesiune:
- Cerințe și analiză
- Proiecta
- Punerea în aplicare
- Testarea
- Instalare
- întreținere
- Planul de proiect ar trebui să fie nepriceput, deoarece, odată finalizată o etapă a secvenței, dezvoltatorii nu pot revizui același lucru fără a începe din nou planificarea.
- Există prea puține posibilități pentru modificări sau erori, iar planul de proiect trebuie respectat cu atenție.
Originea modelului de gestionare a proiectului cascadei:
În primele etape ale industriei IT, nu a existat un model specific pentru dezvoltarea de software.
Astfel, industria a adoptat modelul secvențial al fluxului de lucru utilizat în industria de producție și construcții. Aceste industrii au avut stadii de lucru bine definite și au dezvoltat un model care le satisface nevoia de control strict al costurilor. Astfel, modelul industriei hardware a fost aplicat industriei software.
Winston W Royce a prezentat pentru prima dată acest model în 1970, dar nu a utilizat termenul „Waterfall Project Management”. De fapt, el a prezentat modelul ca unul defect. Reprezentarea picturală a modelului arăta ca o cascadă în cascadă. Thomas E. Bell și TA Thayer au folosit mai târziu termenul „cascadă” în lucrarea lor din 1976, „Cerințe software: sunt într-adevăr o problemă?” Și termenul a ajuns să rămână.
Există o serie de variante ale acestui model. Cele șase faze distincte utilizate în mod obișnuit în Modelul de gestionare a proiectului Cascadă sunt explicate mai jos. Cu toate acestea, în funcție de proiect, pot fi combinate două etape.
Să luăm în considerare exemplul construirii unei școli ca un exemplu pentru a înțelege mai bine modelul de management al proiectului cascadei.
-
Cerințe și faza de analiză:
În primul rând, trebuie să știm exact ce proiectăm. Pentru aceasta, am putea dori:
- Desfășurați discuții detaliate cu clientul
- Încercați să vizualizați clar produsul cu cele mai minime detalii
- Analizați componentele hardware și software necesare
- Enumerați detaliile care includ: problema pe care produsul ar trebui să o rezolve, constrângerile clientului, nivelul de performanță și compatibilitatea cu sistemele deja existente.
- Efectuați studii de caz pentru un produs similar.
- Luați în considerare cerințele fiecărui interesat
- Enumerați specificațiile din documentul privind cerințele produsului, care constituie intrarea pentru următorul pas.
În exemplul nostru de construire a unei școli, în acest pas, enumerăm numărul de săli de clasă, materialul care va fi utilizat pentru construcție, persoanele necesare, infrastructura deja existentă. De asemenea, am observa ce necesită conducerea școlii (birou, cameră pentru personal) și ce necesită studenții (toalete mai bune, locuri de joacă)
-
Proiecta:
În faza de proiectare, tot ce a fost vizualizat în prima etapă este transformat într-un model.
În proiectele IT, aceasta constă în definirea:
- Hardware-ul care va fi utilizat
- Platforma software care va fi utilizată, inclusiv implementarea locală sau cloud
- Arhitectura software, inclusiv diferitele componente și module care vor fi create
- Intrările necesare pentru ca proiectul să funcționeze cu succes
- Rezultate care pot fi de așteptat (în mod ideal, acestea se vor sincroniza cu cerințele detaliate în etapa anterioară)
Există două tipuri de design care intră în joc într-un proiect software:
- Proiectare logică
- Proiectare fizică
Proiectare logică:
Aceasta include datele de bază și procesele care vor fi incluse în proiect. Detaliază designul formularelor și rapoartelor, designul interfeței și designul bazei de date. De exemplu, pentru un site web de ticketing de tren, acest design va determina modul în care va funcționa întregul proces: ecranul pe care călătorul își introduce detaliile și cum aceste date vor curge în baza de date, precum și ce tip de bază de date va stoca aceste detalii.
Proiectare fizică:
Aceasta se referă la proiectarea bazei de date fizice, a programelor și proceselor și a sistemelor distribuite. Acest lucru este realizat după Proiectarea Logică și va include „cum” va fi realizat proiectul: hardware-ul, platforma pe care va fi dezvoltat, diversele baze de date, ecrane și forme care vor fi utilizate etc.
-
Implementare:
- Aici are loc dezvoltarea efectivă a software-ului / sistemului.
- Introducerea pentru această etapă este specificațiile de proiectare furnizate de etapa anterioară.
- Rezultatul este unul sau mai multe dintre componentele produsului construite după specificații, depanate, testate și integrate pentru a satisface arhitectura sistemului.
- Această etapă este de obicei îngrijită de echipa de dezvoltare care este formată din programatori, designeri de interfață și alți specialiști, iar instrumentele utilizate sunt compilatoare, depanatoare, interpreți și editori media.
- Această etapă durează de obicei timpul maxim și este important să urmăriți cu atenție procesele și proiectarea. Schimbările la proiectare în această etapă sunt dificile în gestionarea proiectelor cascadă.
- Pentru un proiect mare care implică mai multe echipe, se recomandă controlul versiunilor pentru a urmări modificările arborului de coduri și a reveni la instantaneele anterioare pentru gestionarea erorilor.
- În exemplul nostru: construcția reală a clădirii folosind forță de muncă și materiale se face în acest stadiu.
-
Testarea:
Testarea se poate face pentru produsul în ansamblu sau pentru componente individuale. „Cazurile de testare” pot fi verificate pentru a vedea dacă produsul poate livra așa cum a fost promis. Pot fi testări de module, teste de sistem ale produsului integrat și teste de acceptare. Testarea acceptării presupune testarea produsului pentru lacune de către utilizatorul final sau client. Defecțiunile sunt notate pentru ca echipa de implementare să fie corectată. După efectuarea corecțiilor, se pregătește o documentație oficială a produsului.
În exemplu, infrastructura școlii este testată, probabil de o echipă de audit. În unele cazuri, profesorii sunt invitați să vină și să utilizeze spațiile pentru a oferi feedback.
-
Instalare:
După ce testarea produsului este finalizată sub toate aspectele, produsul poate fi lansat pe piață sau instalat la sediul clientului. În această etapă, documentația completă a produsului este, de asemenea, predată.
În cazul școlii noastre, aceasta este inaugurată în mod oficial (de preferință printr-o lovitură mare!), Iar școala începe operațiunile!
-
Întreținere:
În această etapă, echipa IT rezolvă problemele care pot apărea odată ce clientul începe să folosească efectiv produsul sau când există o îmbunătățire a produsului. O bună documentare este coloana vertebrală a întreținerii. Problemele sunt rectificate prin modificarea codurilor, numite „patch-uri”.
Dacă sunt necesare schimbări majore, proiectul poate reveni la echipa de dezvoltare ca un proiect nou.
În exemplul nostru, școala are nevoie de întreținere regulată, în mare parte infrastructurală, de exemplu, cabluri electrice defecte sau băi care scurg. Aceste probleme trebuie să fie abordate din când în când.
După cum puteți vedea până acum, etapele în Managementul proiectului de dezvoltare a cascadei sunt distincte și, deși există de obicei o interacțiune constantă cu clientul, este în primul rând să discutați despre progresul proiectului, nu despre proiectare sau cerințe. Cu toate acestea, modelul de gestionare a proiectului cascadei a servit în mod adecvat industriei IT timp de mulți ani, iar pentru majoritatea proiectelor, etapele rămân în continuare bune, dar nu sunt la fel de rigide.
Cu toate acestea, există mai multe proiecte pentru care modelul de gestionare a proiectului cascadă este foarte potrivit.
La ce tip de proiect se potriveste Managementul proiectelor Cascada?
Definirea produsului:
În primul rând, rezultatul final (produs) trebuie să fie capabil să fie bine definit la început. Proiectele în care proprietarul produsului nu este foarte sigur cu privire la specificațiile exacte ale produsului dorit pot face bine să urmeze practicile de Agile Management.
Documentație:
Proiectul ar trebui să fie unul care poate fi documentat. Documentarea este o cerință importantă a Modelului de gestionare a proiectului Cascadă. Cerințele produsului, designul și codul sursă ar trebui să fie clar documentate în toate etapele. Dacă membrii originali ai echipei renunță, acest lucru este ghidul pentru continuitatea proiectului.
Timp și resurse:
Nu trebuie să existe urgență imediată pentru eliberarea produsului. Termenele de timp sunt stabilite la începutul proiectului, iar echipa trebuie să le poată respecta. De asemenea, trebuie să existe resurse suficiente în ceea ce privește forța de muncă și tehnologie.
Risc și incertitudine:
Instrumentele de gestionare a proiectelor în cascadă nu funcționează bine într-un mediu de risc și incertitudine. De exemplu, aplicația Mobile este un tip de produs care se confruntă cu o incertitudine constantă în ceea ce privește acceptarea clienților și concurența aplicațiilor similare.
Etapele clar definite:
Etapele sistemului trebuie să fie bine definite, deoarece acestea trebuie completate în succesiune și nu poate exista suprapuneri.
Când se creează o nouă versiune a software-ului existent.
În afara domeniului IT, Modelul de gestionare a proiectului Cascadă a fost utilizat cu succes în proiecte uriașe, cum ar fi
- Clădirea avioanelor
- Proiecte de infrastructură, cum ar fi poduri
- Fabricarea echipamentelor de apărare
- Sisteme de sănătate în spitale
În proiectele IT, Waterfall Project Management este adecvat în special acelor proiecte în care este necesar hardware extern. Specificațiile acestui lucru nu pot fi modificate la jumătatea drumului, deoarece aceasta ar duce la pierderi de milioane de dolari.
Când au apărut inadvertențe în managementul proiectului Waterfall în industria software, s-a gândit foarte mult la modul în care echipele IT pot oferi o valoare maximă clienților, asigurând în același timp flexibilitate în procesul de lucru.
Astfel s-a născut Agile Project Management System, care este adoptat acum de majoritatea companiilor de software.
Gestionarea cascadelor de proiect contra sistemelor agile:
Sistemul Agile Project Management este un model flexibil care a devenit popular în anii ’90. Aceasta implică dezbinarea proiectului în „mini proiecte” numite sprinturi și lucrul independent la fiecare dintre ei. Acest tip de model permite dezvoltatorilor să includă mai rapid modificările necesare și este foarte eficient acolo unde mediul clienților este variabil.
Rezultatele etapelor de gestionare a proiectului cascadă sunt:
- Deoarece produsul final este cunoscut în totalitate, planificarea și designul sunt lipsite de ambiguitate.
- Problemele potențiale care ar putea apărea în proiect pot fi rezolvate în timpul etapei de proiectare; înainte de a fi scris orice cod.
- Măsurarea progresului muncii este ușoară, deoarece etapele sunt bine definite.
- Stabilitatea echipei există acolo de când echipa rămâne până la sfârșitul proiectului. În cazul Agile, echipa se schimbă constant și acest lucru necesită o anumită ajustare.
- Documentarea este extinsă, ceea ce facilitează gestionarea echipelor dacă un membru pleacă.
- Dezvoltatorii consideră că acest model este mai ușor de lucrat, deoarece este ușor de înțeles,
- După faza Cerințelor, participarea activă a clientului final este necesară numai în faza de testare. Acest lucru se datorează faptului că toate cerințele au fost discutate, fără a lăsa ambiguități.
- Produsul poate fi dezvoltat ca un întreg, în loc să-l dezvolte în anumite părți.
- Problemele legate de gestionarea contractelor și a clienților sunt tratate mai bine în baza Modelului de gestionare a proiectului Cascadă
Rezultatele pozitive ale Agile Project Management sunt:
- Clientul poate interacționa cu echipa de proiect pe tot parcursul ciclului și poate efectua modificări ale produsului din când în când pentru a se potrivi mediului în schimbare.
- Dacă produsul trebuie lansat foarte curând din cauza circumstanțelor pieței, echipa de Management de proiect Agile poate lansa o versiune de bază care poate avea versiuni avansate ulterior.
- Sistemul este destul de transparent din punctul de vedere al clientului și are o idee corectă asupra etapei în care se află produsul său.
- Deoarece clientul oferă prioritatea caracteristicilor, echipa știe că trebuie să se concentreze pe funcțiile care oferă cea mai mare valoare de afaceri.
- Procesul are un impuls propriu.
- Echipele sunt fluide și flexibile, permițând idei de la fiecare membru
- Documentarea este minimă și, astfel, timpul este eliberat de aceste sarcini.
După mai mulți ani, ambele modele există cot la cot, este evident că:
Modelul de gestionare a proiectului Cascadă este eficient pentru managementul de proiect unde, odată ce proiectul este realizat, există modificări minime.
Gestionarea proiectelor Agile este mai potrivită pentru Managementul produsului, unde este important să fim flexibili la schimbări.
Indiferent, sistemul de management al proiectelor Waterfall rămâne o componentă importantă a majorității proiectelor IT. Nu se poate spune cu siguranță că un anumit proiect respectă strict practicile de gestionare agile. De obicei, principiile Agile sunt „încorporate” în proiectele IT.
Unii manageri de proiect Agile au manageri de proiect, în timp ce strict un model Agile are doar Maeștri Scrum. Este vorba despre combinații hibride de modele de gestionare a proiectelor Agile și Cascadă pe care unii le numesc proiecte „Agifall” sau „Agile Agile”.
Popularitatea sistemului de management al proiectului Waterfall se datorează și faptului că problemele legate de gestionarea contractelor și a clienților sunt tratate mai bine prin metodele de gestionare a proiectelor Waterfall.
În timp ce din ce în ce mai multe proiecte intră în faldul Agile de proiecte agile, iar mai multe companii văd beneficiile unui model de management flexibil, popularitatea Modelului de gestionare a proiectelor Cascadă nu se îndoiește.
Cu toate acestea, este dificil să se prevadă un viitor pentru proiectele IT care sunt complet agile, în viitorul apropiat. Și Waterfall Project Management, care a ajutat industria software până la început, va continua să funcționeze în câteva componente ale managementului de proiect cel puțin pentru alți câțiva ani următori.
Prima sursă de imagine: picjumbo.com
Articole similare
- 6 etape utile ale fluxului de lucru în managementul proiectelor în cascadă
- Sfaturi eficiente pentru discuții în grup (sfaturi pentru experți)
- Top 10 mituri de management de proiect au fost afectate
- 6 motive eficiente Toți au nevoie de un proiect de pasiune la locul de muncă
- Top 5 tipuri de instrumente de raportare a managementului de proiect
- Managementul produsului în raport cu managementul mărcilor - Diferențe utile