Waterfall vs. Agile: Którą metodologię wybrać dla swoich projektów Redmine?

Czasami słyszę krzyki jak „Gantt nie żyje”, „musisz prowadzić go zwinnie”, lub nawet „zarządzanie projektami jest martwe”. Chociaż wiele z nich to tylko przykład marketingowych śmieci, często spotykam menedżerów portfeli projektów, scrum masterów i innych specjalistów od zarządzania projektami, którzy chcą poważnie kłócić się o Agile vs. Waterfall (Gantta) techniki. Ten post to krótkie wprowadzenie do tematu.

Trójkąt żelaza w zarządzaniu projektem

Trójkąt żelaza jest w rzeczywistości bardzo prostą reprezentacją kluczowych elementów niezbędnych do pomyślnego planowania projektu. Zakres, czas i koszt/zasoby. Zasoby są jedynymi i/lub krytycznymi elementami ceny w wielu branżach. Ludzie są najcenniejszym zasobem, którego nie można po prostu zwiększyć, zmniejszyć ani pomnożyć. Podobnie zasoby maszynowe mają określoną zdolność produkcyjną i nie można ich zmienić jednym kliknięciem.

Łatwy Redmine - trójkąt żelaza #1

Ale jak żelazny trójkąt pasuje do ogólnego obrazu? Bardzo wygodnie. Daje nam prostą, ale skuteczną odpowiedź, kiedy powinniśmy skorzystać z planowania metodologii Waterwall, a wręcz przeciwnie, kiedy wybrać zwinne podejście.

Zarządzanie projektem Redmine Waterfall

Metodologia Waterfall najlepiej sprawdza się w przypadku projektów, których zakres jest precyzyjnie określony i jest kluczowym elementem projektu, takich jak budowa nieruchomości, planowanie konferencji, czy Łatwa implementacja oprogramowania Redmine.

Technika: Zakres projektu jest określony (ustalony). W naszym przykładzie oznacza to, że nie mogę zmienić liczby okien w mojej nieruchomości, nie mogę zmienić miejsca lub tematu konferencji itp. Czas projektu jest czynnikiem ograniczającym albo absolutnie (np. konferencje) albo prawie absolutnie (np. implementacja oprogramowania). Przy ściśle określonym zakresie głównym zadaniem kierownika projektu lub kierownika portfela jest zaplanowanie wszystkich rodzajów zasobów na osi czasu w równolegle działających projektach i uwzględnienie wymaganej sekwencji działań (zadań) w poszczególnych projektach.

Rozważmy na przykład budowę domu: pracownicy odpowiedzialni za dostawę cementu muszą zakończyć swoje prace w odpowiednim czasie, ponieważ opóźnienia spowodowane brakiem zasobów cementowych mogą uniemożliwić murarze wykonywanie własnych zadań. Gdy beton jest wystarczająco wytrzymały, można je już znaleźć w innym miejscu.

Łatwy Redmine - trójkąt żelaza #2

Zarządzanie projektami Redmine Agile

Zwrotne podejście jest użyteczne w przypadku projektów gdzie Czas jest ściśle określony, Zasoby są czynnikiem determinującym i Zakres podlega planowaniu (priorytetyzacja). Dobrym przykładem może być rozwój oprogramowania (sprinty), działalność wydawnicza (data wydania czasopisma/gazety) lub treści marketingowe (kampania).

Technika: mistrzowie scrum lub planiści o podobnych zadaniach nadają priorytet zadania następnemu sprintowi. Zwykle mistrz scrum ma różne zaległości i tablice szarpiące dla różnych typów zasobów, na przykład deweloperzy, którzy chcą naprawić błędy i obsługiwać żądania nowych funkcji, a po drugiej stronie dziennikarze mediów politycznych lub sportowych.

Łatwy Redmine - trójkąt żelaza #3

Co to znaczy?

Oczywiście cała kwestia zarządzania projektami wciąż sięga wokół trójkąta żelaznego. Planowanie operacyjne koncentruje się raczej na różnych częściach tego samego. Więc co możemy wyciągnąć z tego?

1. Praktycznie w każdej organizacji znaleźliśmy typy projektów, w których jest to konieczne stosować obie techniki zarządzania projektami Do tworzenia efektywnych procesów roboczych. Jedna metodologia nie jest lepsza od drugiej, porusza ona tylko w różne wyzwania.
   
   
2. Harmonogram zasobów związane z osią czasu są niezbędne dla każdego projektu wodospadu, zwłaszcza w przypadku planowania portfela projektów. To samo dotyczy łatwy Redmine projektów.
   
   
3. Zarządzanie projektami zwinnymi: Zarządzanie priorytetami odbywa się zwykle za pomocą różnych narzędzi. Często pojawia się problem z dokładną alokacją zasobów dla konkretnego zaległości. W związku z tym gorąco polecam Mapować i przydzielić zasoby konsekwentnie. Na przykład programista może być używany z wieloma zaległościami w tym samym czasie (np. poprawki błędów a żądania funkcji w tym samym języku). Jednak bez określenia ilościowej alokacji zasobów do zaległości nie będziesz w stanie zaplanować priorytetowych rezultatów, a mistrz scrum będzie musiał nieustannie rozwiązywać rozbieżności między tymi priorytetami. Inną nieprzyjemną konsekwencją będzie opóźnione wydanie nowych kluczowych funkcji produktu, takich jak poprawki błędów lub wymagania dotyczące funkcji, które wykorzystują strategiczne zasoby rozwojowe.

Połączenie obu metodologii zarządzania

Jak widać na poniższym obrazku, mamy podstawowy projekt Waterfall, który zawiera plan rozwoju oprogramowania, który pokazuje sekwencje i zależności. Jednak zespoły zaangażowane w ten projekt (sprzedawcy, pisarze techniczni) mogą zarządzać własnymi dostawami w swoim dziale nie tylko jak pokazano w tym przykładzie, ale także w sposób zwinny.

Easy Redmine Gantt - przykład projektu Wodospad