Metodyki prowadzenia projektu
"To wasza sprawa jak będziecie prowadzić ten projekt, my chcemy dostać tylko to co u was zamówiliśmy". Rzeczywiście, z perspektywy odbiorcy kwestia metodyki prowadzenia projektu informatycznego może wydawać się nieistotna. Jednak gdyby przyjrzeć się statystykom projektów zakończonych porażką, takie twierdzenie przestaje być oczywiste.
Wśród przyczyn nieudanych projektów najczęściej wymienia się źle zdefiniowane lub zmieniające się wymagania względem tworzonego oprogramowania, źle oszacowana ilość wymaganych zasobów (w tym ludzkich), przekazywanie nieprawdziwych lub nieprecyzyjnych informacji o postępach prac, brak zarządzania ryzykiem w projekcie, słaba komunikacja pomiędzy użytkownikami a zespołem developerów, problem z ogarnięciem złożoności projektu czy właśnie złe zarządzanie projektem.
Problemy te nie są przypadkowym zjawiskiem i stanowią tylko wycinek obszaru jaki obejmują badania nad metodykami zarządzania projektami. Dlatego należy korzystać z usystematyzowanej wiedzy opartej na prawdziwych doświadczeniach managerów.
Wybór metodyki zarządzania projektem zależy od wielu czynników m.in. wielkość projektu, ilość uczestników, charakter projektu i wielu innych.
Metodyki, zgodnie z obecnymi trendami, możemy w dużym uroszczeniu podzielić na klasyczne i zwinne. Do klasycznych możemy zaliczyć RUP (Rational Unified Process), której kluczowym założeniem jest iteracyjne (czyli realizowane w wielu cyklach) podejście do realizacji projektu. Przebieg iteracji może zawierać wszystkie elementy klasycznego kaskadowego przebiegu projektu (m.in. analizę wymagań, projektowanie, implementację, testowanie, wdrożenie…) przy czym ich intensywność zmienia się w kolejnych iteracjach (w początkowych iteracjach analiza wymagań zajmuje większość czasu, a środkowych implementacja a w końcowych testy i wdrożenie). Bardzo istotne jest to, że iteracje mają stałą długość (np. 3 tygodnie) i ich produktem jest konkretny i dający się odebrać artefakt (może to być wersja specyfikacji wymagań jak również wersja systemu o założonej funkcjonalności). Po każdej iteracji jej produkt jest przekazywany zamawiającemu w celu odbioru.
Dzięki iteracyjnemu podejściu minimalizowane jest ryzyko, że projekt oddali się od wizji oczekiwanej przez zamawiającego. Ma on również na bieżąco wgląd w postępy prac i napotkane problemy. Wymagana jest zatem silne zaangażowanie zleceniodawcy przez cały czas trwania projektu.
Jest to całkowite przeciwieństwo sytuacji w której klient pierwszy raz styka się z systemem, który zamówił w dniu określonym jako termin realizacji (i zazwyczaj stwierdza, że chodziło mu o coś innego…).
Z innych metodyk stosowanych przez firmy i instytucję do dużych projektów należy wymienić PRICE2, która nadaje się do projektów z wielu innych niż IT dziedzin oraz PMI/PMBOK będącą zbiorem dobrych praktyk zarządzania w projektach IT.
Prowadzone w pełni zgodnie z zaleceniami metodyki RUP czy PRICE2 wymagają tworzenia i utrzymywania dużej ilości dokumentacji projektowej, regularnych spotkań na różnych szczeblach organizacji i obsługi zdefiniowanych procesów w ramach projektu co może powodować istotny narzut w postaci dodatkowej pracy i kosztów oraz zmniejszenie elastyczności. Dlatego czasami dostawcy stosują własne metodyki wzorowane np. na RUP, szczególnie gdy skala projektów jest nieadekwatna do całej „maszynerii” wprowadzanej przez daną metodykę.
W odpowiedzi na potrzebę sprawnej i szybkiej realizacji projektów bez nadmiernych obciążeń związanych z prowadzeniem projektu powstał nurt metodyk zwinnych (Agile). Ich wspólną cechą jest iteracyjne podejście (podobnie jak w RUP, choć iteracje mogą być nawet bardzo krótkie), duży nacisk na samoorganizującą się pracę zespołu developerów i dobrą komunikację zarówno w zespole jak i z zleceniodawcą przy jednoczesnym zmniejszeniu ilości tworzonej dokumentacji. Metodyki zwinne traktują zmianę wymagań w sposób dość liberalny i zakładają takie tworzenie projektów, iż zmiana taka nie wpływa na jego jakość. Wiele ustaleń dotyczących wymagań zapisywanych jest w formie tzn. historyjek (user stories), które później są realizowane w kolejności odpowiadającej ich priorytetom. Promowana jest praca zespołowa i bardzo ścisła współpraca pomiędzy dostawcą a zamawiającym. Według zwolenników metodyki te pozytywnie wpływają na kreatywność zespołu, znacząco podnoszą wydajność i obniżają koszty realizacji projektu. Są jednak i głosy mówiące, że mały nacisk na formalizację niektórych aspektów zarządzania projektem (takich jak np. analiza wymagań) mogą prowadzić do problematycznych sytuacji. Na pewno absolutnie niezbędne jest bardzo duże zaufanie pomiędzy dostawcą a zamawiającym. Ważnym aspektem jest również kwestia rozliczeń. W projektach z określoną kwotą na realizację całego projektu (fixed price) zwinne podejście może prowadzić do przekroczenia budżetu. Zazwyczaj w tego typu projektach stosuję się rozliczenie za wykonaną zgodnie z planem iterację lub za roboczodni (Time&Material). Do zwinnych metodyk należą m.in.: Scrum, XP (eXtreme Programming), Agile Unified Process i inne. Metodyki zwinne wprowadziły szereg bardzo cennych praktyk stosowanych obecnie w projektach (często również w klasycznych modelach). Należą do nich m.in. Test Driven Development czyli technika tworzenia oprogramowania, które poddawane jest równolegle tworzonym automatycznym testom na zgodność z założeniami projektowymi, co pozwala na utrzymywanie wysokiej jakości.
Jak widać pomimo wielu różnic, nowoczesne metodyki realizacji projektów informatycznych posiadają wspólną cechę jaką jest iteracyjność. Jest to kluczowa zmiana w stosunku do najstarszych metod kaskadowych (waterfall) w których realizacja projektu odbywała poprzez jedno przejście przez etapy analizy wymagań, projektowania, implementacji, weryfikacji i utrzymania i w której po zakończeniu jednego etapu nie można było do niego powrócić. Takie podejście oczywiście może być stosowane do małych projektów, ale należy być świadomym jego ograniczeń – w szczególności sztywnego podejścia do zmian i większego ryzyka projektowego.
Warto więc rozpoczęciem projektu uzyskać odpowiedzi na pytania:
- Według jakiej metodyki realizowany będzie projekt
- Jaki jest plan iteracji - szczegółowy harmonogram wraz z dokładnym opisem produktu każdej iteracji
- W jakich iteracjach i jak będzie przebiegała analiza wymagań, oraz jaki będzie kształt specyfikacji wymagań
- Czy są określone dokładne kryteria odbioru produktów poszczególnych iteracji projektu przez klienta
- Jak przebiegać będzie komunikacja w projekcie – czy są ustalone kanały komunikacji (dotyczące m.in. wymagań, zgłaszania uwag i błędów itp.)
Podsumowując, wydaje się że w interesie zamawiającego jest upewnienie się, iż projekt będzie realizowany „zgodnie ze sztuką” czego efektem będzie większa pewność dotarcia do wyznaczonego w projekcie celu.
Autor: Łukasz Kolczyński, 3e
Źródła:
http://spectrum.ieee.org/computing/software/why-software-fails/3
http://agilemanifesto.org/
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Rational_Unified_Process
Autor: Łukasz Kolczyński, 3e internet software house
