Wywodzę się z branży budowlanej, gdzie króluje podejście tradycyjne w kwestii projektu. Nie wyobrażam sobie tworzenia budynku w sposób zwinny 🤔. Projektanci wraz z kierownictwem muszą go starannie zaplanować z wyprzedzeniem. Dokonać wielu sprawdzeń sensowności stworzenia danego przedsięwzięcia 🏢. W sytuacji, gdy budowa już ruszy to nie ma innego wyjścia jak brnięcie w daną inwestycję.
Realizacja projektu budynku
Na samym początku musi zostać przeprowadzona staranna analiza jaki ma być to budynek. Czy dana okolica jest atrakcyjna dla potencjalnych kupców, jaki standard wykończenia ma się w nim znajdować itp. Następnie odpowiednie osoby sporządzają i tworzą projekt, na który trzeba otrzymać niezbędne pozwolenia z urzędów, aby móc rozpocząć prace budowlane. Po zatwierdzeniu nie można go już radykalnie zmieniać. Rozpoczynane są roboty, budynek jest realizowany na podstawie dokumentacji. Po wybudowaniu następują niezbędne odbiory w celu zakończenia budowy. Nad tym wszystkim czuwa kierownictwo wyższego szczebla, a każda zmiana musi być sformalizowana i ma wpływ na całość.
Schemat klasycznego podejścia życia projektu
Podejście kaskadowe - Waterfall
Tak w skrócie na przykładzie można opisać Waterfall, czyli zarządzanie w sposób kaskadowy (co widać na powyższym obrazku). Zauważono, że taka metodologia prowadzenia projektu, w stosunku do IT, jest bardzo trudna do udźwignięcia. Wiele firm z tego powodu zbankrutowało, ponieważ ładowali dużo pieniędzy w biznes a nie otrzymali przychodów. Te przedsiębiorstwa, którym udało się zakończyć produkt z sukcesem i wypuścić na rynek były w tyle za konkurencją z powodu przedawnionego i zdezaktualizowanego oprogramowania.
Agile na ratunek
I wtedy wchodzi Agile cały na biało (bum! 💣) jako próba rozwiązania wszystkich bolączek! Zakłada się w nim, że na początku nie da się dokładnie zaplanować przebiegu projektu, w którym to dokładnie kierunku on zmierza. Przyjmuje się iteracyjny tryb pracy, nazywany dokładniej sprintami trwającymi od 1 do 4 tygodni. W każdej takiej iteracji zespół dostarcza małą cześć finalnego rozwiązania. Dzięki temu mamy działający produkt a przy okazji możemy dostosować się do zmian zachodzących na rynku poprzez analizę wymagań przed kolejnym sprintem. Ważne jest także to, aby zespoły (małe, tak 3-9 osób) działające nad funkcjonalnością były samoorganizujące się oraz miały kompetencje we wszystkich dziedzinach. Tutaj ważne jest zaufanie osób z kierownictwa do takiej organizacji pracy z powodu niskiej kontroli i bardzo ograniczonej dokumentacji.
Filary Agile
Podsumowując, Agile opiera się na czterech krótkich założeniach:
- Ludzie i interakcje między nimi są ważniejsze od procesów i narzędzi
- Współpracę z klientem przekłada się nad formalne ustalenia
- Działające oprogramowanie przewyższa obszerną dokumentację
- Reagowanie na zmiany jest nad podążaniem za ustalonym planem
Wyciągnięta nauka
Najważniejsze czego się nauczyłem to, że Scrum jest “najpopularniejszą metodyką należąca do grupy Agile”. Jeśli ktoś wprowadza Agile to nie ma na myśli jakiś konkretnych narzędzi tylko kulturę i filozofię pracy, która jest fundamentem. To na tej podstawie wybierana jest stosowana metodyka, którą może być właśnie Scrum. Muszę przyznać, że trochę mi zajęło zrozumienie tego 🤔. Dodatkowo Scrum to nie jest narzędzie do zarządzania projektami, w nim interesuje nas tylko praca i dostarczanie wartości klientowi w postaci działającego produktu. Nie ma tutaj mowy o projekcie, budżecie czy harmonogramie. Pewnie pomyłka bierze się stąd, że używamy powszechnie stwierdzenia “projekt scrumowy”.
Faktycznie w moim obecnym projekcie istnieją ceremonie scrumowe, dzięki czemu mogę się przyjrzeć bliżej różnicą między specyfiką branży budowlanej i IT. Każda z nich posiada specyficzne dla siebie detale stąd istnieją różne podejścia do ich realizacji.
Podsumowanie
Na koniec małe podsumowanie:
- Model kaskadowy ma ściśle określony obraz jak ma wyglądać finalny produkt.
- Każda zmiana w Waterfall pociąga za sobą weryfikację jej wpływu na cały projekt.
- W Agile produkt tworzony jest przyrostowo, w każdej z iteracji powinien istnieć działający produkt.
- Przez brak zdefiniowanych długodystansowych wymagań ciężko sobie wyobrazić jak ma wyglądać końcowy produkt.
- Scrum to metodyka, która jest implementacją filozofii Agile.
Chciałbym się jeszcze bliżej przyjrzeć temu jak dokładnie powinien wyglądać sam Scrum, a następnie przedstawić to w jednym z artykułów. Więc spodziewaj się takiej publikacji 👊.
A jakie jest Twoje postrzeganie tych dwóch podejść do wytwarzania produktu? Proszę Cię, daj znać w komentarzu lub napisz do mnie.