Niezależnie od tego, czy jesteś Scrum Master, menedżer projektu, Właściciel produktu, członkiem zespołu, albo po prostu kimś próbującym odpowiedzieć na pytanie „Jak prowadzić projekt Agilne Scrum projekt w realnym świecie?” — ten artykuł na pewno dostarczy Ci odpowiedzi, które potrzebujesz.
Zwykłe zarządzanie projektami
Klasyczny sposób zarządzania projektami (metoda sztormowa) jest liniowy, w którym wszystkie fazy procesu zachodzą sekwencyjnie. Ten sposób opiera się na przewidywalnych narzędziach i przewidywalnym doświadczeniu. Każdy projekt podlega temu samemu cyklowi życia, obejmującemu fazy: analiza możliwości, planowanie, projektowanie, budowa, testowanie, wdrożenie i wsparcie, jak pokazano na rysunku poniżej.
Metoda sztormowa vs rozwój oprogramowania agilnego
Cały projekt jest dokładnie zaplanowany z brakiem miejsca na zmiany w wymaganiach — podobnie jak metoda sztormowa, PMBOK PMI i PRINCE2 są sztywne i bardzo kontrolowane. Wskazują one wyraźne fazy od początku do końca i zakładają, że masz już wszystkie wymagania i informacje, które potrzebujesz.
Ten podejście zakłada, że czas i koszt są zmiennymi, a wymagania są ustalone — dlatego zarządzanie projektami tradycyjnymi często napotyka trudności z budżetem i harmonogramem.
Zarządzanie projektami agilnymi
Podczas gdy systemy tradycyjne skupiają się mocno na wstępnym planowaniu, czynniki takie jak koszt, zakres i czas są kluczowe. Agilne podejście z kolei podkreśla pracę zespołową, współpracę z klientem i elastyczność.
Agilne podejście odrzuca tradycyjne zarządzanie projektami jako nudne, ograniczające i nieodpowiednie dla szybko zmieniającego się świata współczesnego. Zarządzanie projektami agilnymi jest iteracyjne, dążąc do ciągłego włączania opinii użytkowników i ciągłych wersji wydanych w każdej iteracji rozwoju, jak pokazano powyżej. Każde wyjście z zadania to produkt, który sprzedajesz interesantom. Zespoły i procesy są zorganizowane wokół tworzenia rzeczy bezpośrednio przydatnych dla klienta.
Tradycyjne czy agilne – jak wybrać?
Według raportu CHAOS z 2011 roku wydawanego przez Standish Group, projekty agilne są trzykrotnie bardziej skuteczne niż projekty metody sztormowej. Wykres poniżej przedstawia konkretne wyniki badań przeprowadzonych w latach 2002–2012:
Stopień skuteczności projektów metody sztormowej w porównaniu do projektów agilnych
Różnice między tradycyjnym a agilnym podejściem
Poniższa tabela podsumowuje wiele kluczowych różnic między modelami Scrum i tradycyjnego zarządzania projektami.
| Kategoria | Tradycyjne | Agilne |
| Model rozwoju | Sekwencyjny (metoda sztormowa) | Iteracyjny |
| Skupienie | Proces | Ludzie |
| Styl zarządzania | Kontrola | Ułatwianie |
| Udział klienta | Ograniczony do faz zbierania wymagań i dostarczania | Zawodowe i ciągłe zaangażowanie na miejscu |
| Styl pracy programisty | Pracuje indywidualnie w ramach zespołu | Współpraca lub programowanie w parach |
| Technologia | Dowolna | Przede wszystkim obiektowa |
| Funkcje produktu | Wszystkie funkcje uwzględnione | Najważniejsze funkcje najpierw |
| Testowanie | Na końcu cyklu rozwojowego | Iteracyjne i/lub oparte na testach |
| Dokumentacja | Obszerna | Tylko wtedy, gdy potrzebne |
Koszt zmiany
Zwykle zmiany w projektach oprogramowania są unikane, ponieważ koszt rośnie znacznie później w projekcie. Rozwój oprogramowania agilnego uznaje, że zmiany są nieuniknione, a intensywne inwestowanie w wczesne planowanie jest nierealistyczne. To wyraźnie wyrażone w jednym z czterech wartości Agile Manifesto:
„Reagowanie na zmieniające się wymagania zamiast ślepego przestrzegania ustalonego planu.”
Agile wyzwania to przekonanie i twierdzi, że koszt zmiany może być względnie płaski, jak pokazano na rysunku poniżej:
Koszt zmiany w tradycyjnym vs agilnym
Agile wobec tradycyjnego trójkąta stalowego w zarządzaniu projektami
Sukces w zarządzaniu projektami tradycyjnie kojarzony jest z umiejętnością zarządzania ograniczeniami zakresu, czasu, kosztów i jakości, jak pokazano na rysunku poniżej. Jest to popularny metafora sugerująca, że menedżerowie projektów są oczekiwani, by rozsądnie zrównoważyć te ograniczenia.
Trójkąt stalowy w agilnym vs tradycyjnym zarządzaniu projektami
Jaki jest problem z tradycyjnym trójkątem stalowym?
Na przykład projekt można zakończyć szybciej poprzez zwiększenie budżetu lub zmniejszenie zakresu. Podobnie, rozszerzenie zakresu zwykle wymaga odpowiedniego zwiększenia budżetu i harmonogramu. Obcinanie budżetu bez dostosowania harmonogramu lub zakresu prowadzi do spadku jakości. Jednak w praktyce kompromisy między ograniczeniami nie zawsze są możliwe. Na przykład inwestowanie większych środków (i ludzi) w projekt z obfitymi zasobami może rzeczywiście spowolnić postępy. Dodatkowo, w słabo działających projektach poprawa budżetu, harmonogramu lub zakresu bez negatywnego wpływu na jakość jest często niemożliwa.
W związku z tym tradycyjny trójkąt stalowy jest jasno niewystarczający jako model sukcesu projektu, ponieważ pomija kluczowe wymiary sukcesu, w tym wpływ interesariuszy, uczenie się i satysfakcję użytkowników.
Agile Trójkąt stalowy – Przesunięcie paradygmatu
W tradycyjnym podejściu trójkąt zwykle wygląda jak lewy pokazany poniżej. Jak widać, wymagania dotyczące produktu mają ustalony zakres. Dlatego, aby zapewnić, że produkt dostarczy wszystkie wymagane funkcje, potrzebujemy elastyczności w zasobach (i budżecie) oraz harmonogramie (terminie). Jeśli absolutnie potrzebujemy, by produkt zawierał pełną listę funkcji opisanych w początkowym specyfikacji wymagań, może być konieczne opóźnienie daty wydania o miesiące lub więcej.
W sensie Agile istnieje ustalony harmonogram (w Scrumie osiągany poprzezczasowo ograniczone Sprintyi ustalone zasoby). Dlatego, gdy rzeczy nie przebiegają zgodnie z planem, zakres musi zostać zmniejszony. Ale w Agile zapewniamy, że nawet jeśli musimy ustąpić pod względem zakresu, nadal dostarczamy najważniejsze elementy zBacklog produktuw celu maksymalizacji wartości generowanej przez projekt.
Trójkąt stalowy w kontekście Agile
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish