Waterfall Project Management - Obecnie większość zespołów IT zastanawia się nad zastosowaniem zwinnych systemów zarządzania projektami. Ale w końcu robią to, stosując systemy Agile Project Management do swoich projektów. Oznacza to połączenie tradycyjnych systemów zarządzania projektami (zwanych Waterfall Project Management Systems) w połączeniu z Zasadami Zwinnego Zarządzania, jak wyszczególniono w oryginalnym Manifeście Zwinnym.
Ponieważ coraz więcej projektów na całym świecie stosuje praktyki Agile Project Management, czy to oznacza koniec zarządzania projektami kaskadowymi? Czy wszystkie projekty IT staną się zwinnym zarządzaniem projektami?
Aby zrozumieć różne modele, w tym Agile, i zastosować ten, który najlepiej pasuje do Twojej sytuacji, ważne jest, aby najpierw zrozumieć, na czym polega tradycyjny system zarządzania projektami, zwany modelem zarządzania projektami Waterfall.
Model zarządzania projektem Waterfall, nazwany tak ze względu na charakter procesu przepływu pracy, charakteryzuje się następującymi cechami:
- Produkt końcowy jest najpierw bardzo szczegółowo wizualizowany.
- Następnie etapy przepływu pracy są wdrażane kolejno:
- Wymagania i analiza
- Projekt
- Realizacja
- Testowanie
- Instalacja
- Konserwacja
- Plan projektu powinien być niezawodny, ponieważ po zakończeniu etapu w sekwencji programiści nie mogą wrócić do niego bez ponownego rozpoczęcia planowania.
- Możliwości zmian i błędów są niewielkie, dlatego należy ściśle przestrzegać planu projektu.
Powstanie modelu zarządzania projektami Waterfall:
Na początkowych etapach branży IT nie było konkretnego modelu rozwoju oprogramowania.
Tak więc branża przyjęła sekwencyjny model przepływu pracy stosowany w przemyśle produkcyjnym i budowlanym. Branże te miały ściśle określone etapy pracy i opracowali model, który zaspokajał ich potrzebę ścisłej kontroli kosztów. Model przemysłu sprzętowego został więc zastosowany w branży oprogramowania.
Winston W Royce po raz pierwszy zaprezentował ten model w 1970 roku, ale nie użył terminu „Waterfall Project Management”. W rzeczywistości przedstawił model jako wadliwy. Obrazowa reprezentacja modelu wyglądała jak kaskadowy wodospad. Thomas E. Bell i TA Thayer użyli później terminu „wodospad” w swoim artykule z 1976 r. „Wymagania programowe: czy naprawdę stanowią problem?” I termin ten pozostał.
Istnieje wiele wariantów tego modelu. Powszechnie stosowane sześć różnych faz w modelu zarządzania projektem Waterfall wyjaśniono poniżej. Jednak w zależności od projektu można połączyć dwa etapy.
Rozważmy przykład budowy szkoły jako przykład lepszego zrozumienia modelu zarządzania projektem wodospadu.
-
Wymagania i faza analizy:
Po pierwsze, musimy dokładnie wiedzieć, co projektujemy. W tym celu możemy chcieć:
- Przeprowadzaj szczegółowe rozmowy z klientem
- Staraj się wyraźnie wizualizować produkt z jego najdrobniejszymi szczegółami
- Przeanalizuj, które elementy sprzętu i oprogramowania są wymagane
- Wymień szczegóły, które obejmują: problem, który produkt powinien rozwiązać, ograniczenia klienta, poziom wydajności i kompatybilność z już istniejącymi systemami.
- Przeprowadź studia przypadków dotyczące podobnego produktu.
- Rozważ wymagania każdego interesariusza
- Wymień specyfikacje w dokumencie wymagań produktu, który stanowi dane wejściowe do następnego kroku.
W naszym przykładzie budowy szkoły na tym etapie podajemy liczbę sal lekcyjnych, materiały do budowy, liczbę wymaganych osób, istniejącą infrastrukturę. Zwrócilibyśmy również uwagę na wymagania kierownictwa szkoły (pokój biurowy, pokój nauczycielski) oraz wymagania uczniów (lepsze toalety, place zabaw)
-
Projekt:
Na etapie projektowania wszystko, co zostało zobrazowane w pierwszym etapie, jest przekształcane w plan.
W projektach IT polega to na zdefiniowaniu:
- Sprzęt, który będzie używany
- Platforma oprogramowania, która ma być używana, w tym wdrożenie lokalne lub w chmurze
- Architektura oprogramowania, w tym różne komponenty i moduły, które należy utworzyć
- Dane wejściowe wymagane do pomyślnego działania projektu
- Dane wyjściowe, których można się spodziewać (idealnie, to zsynchronizuje się z wymaganiami wyszczególnionymi na wcześniejszym etapie)
Istnieją dwa rodzaje projektów, które wchodzą w grę w projekcie oprogramowania:
- Logiczny projekt
- Projekt fizyczny
Logiczny projekt:
Obejmuje to podstawowe dane i procesy, które zostaną uwzględnione w projekcie. Wyszczególnia projekt formularzy i raportów, projekt interfejsu i projekt bazy danych. Na przykład w przypadku witryny z biletami kolejowymi ten projekt określi sposób działania całego procesu: ekran, na którym podróżny wprowadza swoje dane oraz sposób, w jaki te dane wpłyną do bazy danych, a także jaki typ bazy danych będzie przechowywać te szczegóły.
Projekt fizyczny:
Dotyczy to projektowania fizycznej bazy danych, programów i procesów oraz systemów rozproszonych. Odbywa się to po zaprojektowaniu logicznym i obejmuje „jak” projekt zostanie wykonany: sprzęt, platforma, na której zostanie opracowany, różne bazy danych, ekrany i formularze, które będą używane itp.
-
Realizacja:
- To tutaj ma miejsce faktyczny rozwój oprogramowania / systemu.
- Dane wejściowe dla tego etapu to specyfikacje projektowe dostarczone przez poprzedni etap.
- Dane wyjściowe to jeden lub więcej komponentów produktu zbudowanych zgodnie ze specyfikacjami, debugowanych, przetestowanych i zintegrowanych w celu spełnienia architektury systemu.
- Ten etap jest zwykle realizowany przez zespół programistów, w skład którego wchodzą programiści, projektanci interfejsów i inni specjaliści, a wykorzystywane narzędzia to kompilatory, debuggery, interpretatory i edytory mediów.
- Ten etap zwykle zajmuje maksymalny czas i ważne jest staranne śledzenie procesów i projektowania. Zmiany w projekcie na tym etapie są trudne w zarządzaniu projektami Waterfall.
- W przypadku dużego projektu z udziałem kilku zespołów zaleca się kontrolę wersji w celu śledzenia zmian w drzewie kodu i powrotu do poprzednich migawek w celu obsługi błędów.
- W naszym przykładzie: na tym etapie odbywa się faktyczna konstrukcja budynku przy użyciu robocizny i materiałów.
-
Testowanie:
Testy można wykonać dla produktu jako całości lub dla poszczególnych komponentów. „Przypadki testowe” można zweryfikować, aby sprawdzić, czy produkt może dostarczyć zgodnie z obietnicą. Można przeprowadzić testy modułów, testy systemu zintegrowanego produktu i testy akceptacyjne. Testy akceptacyjne obejmują testowanie produktu pod kątem luk przez użytkownika końcowego lub klienta. Wady są odnotowywane przez zespół wdrażający do poprawienia. Po dokonaniu poprawek przygotowywana jest formalna dokumentacja produktu.
W tym przykładzie infrastruktura szkoły jest testowana, prawdopodobnie przez zespół audytowy. W niektórych przypadkach nauczyciele są zaproszeni do skorzystania z lokalu i przedstawienia opinii.
-
Instalacja:
Po zakończeniu testowania produktu we wszystkich aspektach, produkt można wprowadzić na rynek lub zainstalować w siedzibie klienta. Na tym etapie przekazywana jest również pełna dokumentacja produktu.
W przypadku naszej szkoły zostaje ona oficjalnie zainaugurowana (najlepiej dużym strzałem!) I szkoła rozpoczyna działalność!
-
Konserwacja:
Na tym etapie zespół IT rozwiązuje wszelkie problemy, które mogą pojawić się, gdy klient faktycznie zacznie korzystać z produktu lub gdy pojawi się ulepszenie produktu. Dobra dokumentacja jest podstawą utrzymania. Problemy są rozwiązywane przez modyfikację kodów, zwanych „łatkami”.
Jeśli wymagane są poważne zmiany, projekt może wrócić do zespołu programistów jako nowy projekt.
W naszym przykładzie szkoła wymaga regularnej konserwacji, głównie infrastruktury, na przykład wadliwego okablowania elektrycznego lub nieszczelnych łazienek. Problemy te należy rozwiązywać od czasu do czasu.
Jak widać, etapy zarządzania projektami Waterfall Development są odrębne i chociaż zazwyczaj istnieje ciągła interakcja z klientem, chodzi przede wszystkim o omówienie postępu projektu, a nie jego projektu lub wymagań. Jednak model zarządzania projektem wodospadu przez wiele lat należycie służył branży IT, a dla większości projektów etapy nadal przebiegają dobrze, choć nie są tak sztywne.
Istnieje jednak kilka projektów, dla których model zarządzania projektem Waterfall jest bardzo odpowiedni.
Do jakiego projektu nadaje się Waterfall Project Management?
Definicja produktu:
Po pierwsze, wynik końcowy (produkt) musi być dobrze zdefiniowany na samym początku. Projekty, w których właściciel produktu nie ma pewności co do dokładnej specyfikacji pożądanego produktu, mogą dobrze postępować zgodnie z praktykami Agile Management.
Dokumentacja:
Projekt powinien być tym, który można udokumentować. Dokumentacja jest ważnym wymogiem modelu zarządzania projektem Waterfall. Wymagania dotyczące produktu, projekt i kod źródłowy powinny być jasno udokumentowane na wszystkich etapach. Jeśli pierwsi członkowie zespołu odejdą, stanowi to przewodnik dla ciągłości projektu.
Czas i zasoby:
Wydanie produktu nie może być natychmiastowe. Terminy są ustalane na początku projektu i zespół musi być w stanie ich przestrzegać. Ponadto muszą być dostępne duże zasoby pod względem siły roboczej i technologii.
Ryzyko i niepewność:
Narzędzia do zarządzania projektami Waterfall nie działają dobrze w środowisku ryzyka i niepewności. Na przykład aplikacja mobilna jest rodzajem produktu, który zmaga się ze stałą niepewnością w zakresie akceptacji klientów i konkurencji podobnych aplikacji.
Jasno określone etapy:
Etapy systemu powinny być dobrze określone, ponieważ należy je ukończyć w sekwencji i nie może się na siebie nakładać.
Gdy tworzona jest nowa wersja istniejącego oprogramowania.
Poza domeną IT model zarządzania projektami Waterfall z powodzeniem zastosowano w dużych projektach, takich jak
- Budynek samolotu
- Projekty infrastrukturalne, takie jak mosty
- Produkcja wyposażenia obronnego
- Systemy opieki zdrowotnej w szpitalach
W projektach informatycznych Waterfall Project Management jest szczególnie odpowiedni dla tych projektów, w których wymagany jest sprzęt zewnętrzny. Specyfikacji tego nie można zmienić w połowie, ponieważ spowodowałoby to utratę milionów dolarów.
Kiedy w branży oprogramowania ujawniły się niedociągnięcia w zarządzaniu projektami Waterfall, zastanawiano się, w jaki sposób zespoły IT mogą zapewnić klientom maksymalną wartość, zapewniając jednocześnie elastyczność procesu przepływu pracy.
I tak narodził się zwinny system zarządzania projektami, który jest obecnie stosowany przez większość firm produkujących oprogramowanie.
Zarządzanie projektami Waterfall vs Agile Systems:
System Agile Project Management to elastyczny model, który stał się popularny w latach 90. Polega ona na rozbiciu projektu na „mini projekty” zwane sprintami i niezależnej pracy nad każdym z nich. Ten rodzaj modelu umożliwia programistom szybsze wprowadzanie wymaganych zmian i jest bardzo skuteczny, gdy środowisko klienta jest zmienne.
Pozytywne kroki zarządzania projektami Waterfall to:
- Ponieważ produkt końcowy jest znany w całości, planowanie i projektowanie są jednoznaczne.
- Potencjalne problemy, które mogą pojawić się w projekcie, można rozwiązać podczas samego etapu projektowania; przed napisaniem jakiegokolwiek kodu.
- Mierzenie postępu pracy jest łatwe, ponieważ etapy są dobrze określone.
- Istnieje stabilność zespołu, ponieważ pozostaje on do końca projektu. W przypadku Agile zespół ciągle się zmienia, a to wymaga pewnej korekty.
- Dokumentacja jest obszerna, co ułatwia zespołom zarządzanie, jeśli członek odejdzie.
- Programiści uważają, że ten model jest łatwiejszy w obsłudze, ponieważ jest łatwy do zrozumienia,
- Po fazie wymagań aktywny udział klienta końcowego jest potrzebny tylko na etapie testowania. Jest tak, ponieważ wszystkie wymagania zostały omówione jako wytarte, nie pozostawiając dwuznaczności.
- Produkt można opracować jako całość, zamiast opracowywać go w częściach.
- Kwestie zarządzania kontraktami i klientami są lepiej rozwiązywane w modelu zarządzania projektami Waterfall.
Zalety Agile Project Management to:
- Klient może wchodzić w interakcje z zespołem projektowym przez cały cykl i od czasu do czasu wprowadzać zmiany w produkcie, aby dostosować je do zmieniającego się środowiska.
- Jeśli produkt zostanie wkrótce wydany z powodu warunków rynkowych, zespół Agile Project Management może wydać wersję podstawową, która może mieć wersje zaawansowane później.
- System jest dość przejrzysty z punktu widzenia klienta i ma on dobry obraz etapu, na którym znajduje się jego produkt.
- Ponieważ klient zapewnia priorytet funkcji, zespół wie, że musi skupić się na funkcjach zapewniających największą wartość biznesową.
- Proces ten ma swój własny pęd.
- Zespoły są płynne i elastyczne, umożliwiając ideę od każdego członka
- Dokumentacja jest minimalna, więc czas jest wolny od tych zadań.
Po wielu latach istnienia obu modeli widać, że:
Model zarządzania projektem Waterfall jest skuteczny w zarządzaniu projektem, w którym po zakończeniu projektu wprowadzane są minimalne zmiany.
Zwinne zarządzanie projektami jest bardziej odpowiednie do zarządzania produktem, gdzie ważna jest elastyczność w zakresie zmian.
Niezależnie od tego system zarządzania projektami Waterfall pozostaje ważnym elementem większości projektów informatycznych. Nie można z całą pewnością stwierdzić, że konkretny projekt ściśle przestrzega praktyk zwinnego zarządzania. Zazwyczaj zasady Agile są „włączane” do projektów informatycznych.
Niektóre zwinne zarządzanie projektami ma kierowników projektów, podczas gdy ściśle zwinny model ma tylko Scrum Masters. To hybrydowe kombinacje modeli Agile i Waterfall Project Management, które niektórzy nazywają projektami „Agifall” lub „Agile Agile”.
Popularność systemu zarządzania projektami Waterfall wynika również z faktu, że kwestie zarządzania umowami i klientami są lepiej rozwiązywane przez metody zarządzania projektami Waterfall.
Podczas gdy coraz więcej projektów wchodzi w skład Agile Project Management, a coraz więcej firm widzi zalety elastycznego modelu zarządzania, popularność modelu zarządzania projektami Waterfall bez wątpienia maleje.
Trudno jednak przewidzieć przyszłość projektów IT, które są w pełni zwinne, w najbliższej przyszłości. A Waterfall Project Management, który pomógł branży oprogramowania od samego początku, będzie działał w kilku elementach zarządzania projektami przynajmniej przez kilka kolejnych lat.
Pierwsze źródło obrazu: picjumbo.com
Powiązane artykuły
- 6 przydatnych etapów pracy w zarządzaniu projektami Waterfall
- Skuteczne wskazówki do dyskusji grupowej (porady ekspertów)
- Top 10 mitów związanych z zarządzaniem projektami
- 6 skutecznych powodów, dla których każdy potrzebuje projektu pasji w pracy
- Top 5 rodzajów narzędzi do raportowania zarządzania projektami
- Zarządzanie produktem a zarządzanie marką - użyteczne różnice