3.5 Zestawienie omówionych metod

W powyższych rozdziałach przedstawiono kilka zwinnych metodyk zarządzania projektami IT. Decyzja o przedstawieniu jedynie metodyk zwinnych podyktowana jest statystyką mówiącą, że znacząca większość projektów IT to projekty z wyraźnie określonymi wymaganiami, ale niejasnym sposobem ich osiągnięcia, gdzie jako sposób zarządzania najlepiej sprawdzają się właśnie podejścia Agile. Omówione zostały podejścia Dynamic Systems Development Method, Scrum i Extreme Programming. Wybór tych konkretnych metodyk z kolei podyktowany był ich popualrnością, realatywnie długą historią, a także możliwością zastosowania w projektach małych i średnich. W niniejszym rozdziale metodyki te zostaną ze sobą zestawione pod kątem różnych kryteriów, a także przedstaiowe zostaną ich wady i zalety. Zestawienie ma na celu zebranie informacji o omówionych metodykach w jednym miejscu, porównanie przedstawionych podejść, a także zwięzłe uzupełnienie niektórych informacji o metodyce.

Tab. 3.5.1 Zestawienie metodyk DSDM, Scrum i XP

  Dynamic Systems Development Method Scrum Extreme Programming
Autorzy DSDM Consortium Ken Schwaber i Jeff Sutherland Kent Beck i Martin Fowler
Kraj pochodzenia Wielka Brytania USA USA
Rok pojawienia się pierwszej publikacji 1995 1997 1999
Oficjalny i najbardziej aktualny podręcznik DSDM Consortium: DSDM Atern Handbook. UK. DSDM Consortium. 2007. Schwaber K., Sutherland J.: The Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Scrum.org. 2011. Beck K., Fowler M.: Planning Extreme Programming. Boston. Addison-Wesley. 2000.
Wartości/Założenia Dostarczenie korzyści biznesowej, dostarczenie produktu na czas, współpraca, poziom jakości, przyrostowy  i iteracyjny charakter pracy, ciągła i klarowna komunikacja i kontrola. Przejrzystość, inspekcja i adaptacja. Wiedza wynika z doświadczenia, a decyzje łatwiej i lepiej podejmować w oparciu o to, co poznane. Prostota, komunikacja, feedback, szacunek i odwaga.
Skala projektów Projekty o różnej skali Projekty o różnej skali Projekty małe
Proces Etap przed projektem; Projekt właściwy, który uwzględnia 5 faz: analiza wykonalności, fundament biznesowy, analizy, wykonanie, wdrożenie; Etap po projekcie. Faza startu oraz sprinty, a w nich: planowanie sprintu, codzienne scrumy, przegląd sprintu oraz retrospektywa, a także pielęgnacja rejestru. Etapy analizy, projektowania, wdrożenia i testów zachodzą równolegle na niewielkim odcinku czasu i dotyczą wycinka zakres projektu.
Długość iteracji 80% rozwiązań w ciągu 20% czasu Od dwóch do czterech tygodni Od jednego do sześciu tygodni
Wielkość zespołów Małe zespoły liczące mniej niż 12 osób Małe zespoły od 3 do 9 osób. Ewentualnie większe zespoły przy zastosowaniu Scum of Scrums. Zespoły różnych rozmiarów
Role zespołowe Zespół projektowy: sponsor biznesowy, wizjoner, koordynator IT, koordynator projektu, lider zespołu. Zesół wykonaczy: lider zespołu, deweloperzy, analitycy biznesowi, testerzy, ambasadorzy biznesowi ewentualnie doradca biznesowy. Deweloperzy, Scrum Master oraz Właściciel Produktu. Klient, Programista, Trener, Kontroler.
Zaangażowanie klienta Klient zaangażowany w proces Udział klienta poprzez rolę Właściciela Produktu Kontakt z klientem w wyniku częstych wydań produktu.
Techniki i narzędzia Metoda MoSCoW Szacowanie w punktach, wykres spalania Programowanie parami, refektoring
Zalety + Duży nacisk na testy + Korzyść biznesowa jest zdefiniowana i oczekuje się jej realizacji + Jasny komunikat, że nie wszystkie funkcjonalności uda się wdrożyć + Duży nacisk na zespół i jego samoorganizację + Priorytety określane na bazie wartości bizneswej + Duży nacisk na komunikację i współpracę + Jasno zdefiniowane dobre praktyki deweloperskie + Aktywny udział klienta poprzez ustalanie priorytetów dla funkconalności + Częsty feedback + Duży nacisk na testy
Wady - Najmniej zwinna ze zwinnych metod zarządzania - Wymaga udział użytkowników - Rozbudowana dokumentacja - Utrudniony dostęp do materiałów - Porusza jedynie kwestie zarządzania - Nie definiuje żadnych praktyk deweloperskich - Szczątkowa dokumentacja - Wymaga zaangażowania klienta - Szczątkowa dokumentacja - Trudny do wdrożenia dla poczatkujących

Źródło: Opracowanie własne na podstawie Strode D.E.: The Agile Methods: An Analytical Comparison of Five Agile Methods and an Investigation of Their Target Environment. Palmerston North, New Zealand. Massey University. 2005. i Lane D., Coffin R.: A Practical Guide to Seven Agile Methodologies. Part 2. Devx.com. 2006.

Bardzo ważna w kontekście zestawienia przedstawionych metod jest analiza ich komplementarności. Poniżej przedstawiono wykres, który prezentuje jaki zakres zarządzania projektami pokrywają poszczególne podejścia. DSDM w wersji Atern, najnowszej obejmuje zakres najszerszy. Podejścia Scrum i XP skupiają się bardziej wybiórczo na konkretnych elementach zarządzania projektami przez co w łatwy sposób mogą się uzupełniać jednak wówczas nadal pozostaje pewien niezagospodarowany obszar. Pokrycie go przez metodykę DSDM może doprowadzić do sytuacji, w której metodyka Scrum zupełnie zostanie wykluczona na rzecz pełniejszego wykorzystania metodyki DSDM.

Warto zwrócić uwagę, że żadna z omówionych metodyk nie porusza w pełnym zakresie zarządzania projektami na poziomie całej organizacji. W tym zakresie pomocne są standardy typu PMBoK czy PRINCE2 jak też filozofie zarządzania takie jak Total Quality Management czy Lean Management, które jednak wykraczają poza przedmiot niniejszej pracy.

Rys. 3.5.1 Obszary zarządzania projektami w pokryciu przez przedstawione metodyki

Obszary zarządzania projektami w pokryciu przez przedstawione metodyki
Źródło: DSDM-Consortium: Agaile management. White Paper. s. 7

Omówione metodyki zostały wybrane pod kątem możliwości wdrożenia ich w małych projektach przy czym nie jest to równoznaczne z brakiem problemów przy ich realizacji. Małe projekty często realizowane są przez małe zespoły, co wiąże się z pełnieniem kilku ról przez jedną osobę. Jest to generalnie dopuszczalne postępowanie przy czym często implikuje pewne trudności, a niekiedy jest wręcz niemożliwe do zrealizowania jak na przykład pełnienie roli Scrum Mastera i Product Owner’a w Scrumie przez jedną osobę (wiecej: http://www.infoq.com/news/2008/12/scrum-master-product-owner). Kolejnym problemem rozwiązań zwinnych jest konieczność zaangażowania klienta w kwestii wymagań czy testów. Bliska współpraca z klientem zdecydowanie zwiększa efektywność zespołu i optymalizuje pracę, a na pewno zwiększa szanse powodzenia projektu, jednak w przypadku wielu zespołów jest trudna do wdrożenia ze względu na klienta, ale także nastawienie zespołu. Klienci mają również znaczne opory przed rezygnacją z rozbudowanej dokumentacji, której stworzenie pochłania czas wyjątkowo cenny w małych i średnich projektach. Pamiętając o tych ograniczeniach metodyki zwinne mają jednak pozytywny wpływ na realizację współczesnych małych i średnich projektów o zmiennym zakresie. [1]

[1] 4pm.pl: Wpływ stosowanych metodyk na czas realizacji projektów informatycznych z dnia 06.09.2013