Analiza trwa zbyt długo? A może jej brakuje – zaskakują Cię nowe założenia, są uszczerbki w jakości? Jedno i drugie może puścić firmę z torbami! Dostosuj sposób, w jaki pracujesz, do projektu – żeby nie utknąć w papierach, ale też zachować potrzebny porządek. Pobawmy się w architekta procesów!
Po napisaniu poprzedniego artykułu – https://analizait.pl/2012/szybko-szybko/ – chcę wyjaśnić – czasem stosowanie się do niego nie wyjdzie na dobre 😉 Wszystko zależy od tego jaki jest projekt.
Jest wiele dobrych praktyk pomagających przeprowadzić i udokumentować szczegółową analizę. Najważniejsze z nich przedstawia BABOK (https://analizait.pl/2012/techniki-analizy-biznesowej-wg-babok-2-0/). Piękno analizy (i całego zarządzania projektem) polega na tym, że jest wyzwaniem i sztuką (!), by dobrać odpowiednie rozwiązania do projektu. Oto masz przed sobą skrzynkę z narzędziami – wybierz najbardziej pasujące.
Jakie mamy sposoby określania wymaganego poziomu sformalizowania analizy? Przede wszystkim dostosujmy analizę do potrzeb całego projektu. A jak te określić? Należy dobrać odpowiednią metodykę – znaleźć złoty środek między dyscypliną a zwinnością w projekcie. Niektórzy stając przed takimi wyborami kierują się jednym mitycznym kryterium – czy projekt jest „duży”? Tymczasem projekt możemy rozpatrywać w bardzo wielu wymiarach i na ich podstawie dokonywać ocen i wyboru bardziej odpowiedniej metodyki. Opisuje to m.in. książka panów Boehma i Turnera – „Balancing Agility And Discipline” [1]. Przedstawione modele są bardzo ciekawe same w sobie i przydałoby się ich szersze omówienie. Tutaj przedstawiam tylko same kryteria, żeby pokazać, że projekt ma o wiele więcej wymiarów, które powinieneś wziąć pod uwagę – nie tylko to, czy jest „duży”.
Model 12 kryteriów
Cechy związane z zastosowaniem:
- główne cele projektu – szybka wartość czy stabilność
- rozmiar – mały czy duży zespół i projekt
- otoczenie biznesowe – zmienne, skupione na produkcie czy niezmienne, skupione na oragnizacji
Cechy związane z zarządzaniem:
- relacja z klientem – codzienny czy sporadyczny kontakt
- planowanie i nadzorowanie – lista To Do na tablicy czy formalne plany i specyfikacje
- komunikacja w projekcie – każdy wie coś czy gdzieś zapisane jest wszystko
Cechy techniczne:
- podejście do definiowania wymagań – historyjki (będą zmiany) czy specyfikacja (może być ewolucja)
- podejście do wytwarzania – prosty czy bardzo złożony projekt
- podejście do testowania – przejście testu zamiast wymagań czy procedury testowania
Cechy związane z osobami:
- klient – dostępne czy niedostępne osoby CRACK*
- wykonawcy – wiele czy niewiele osób samodzielnych i znających metodyki zwinne
- kultura – osoby wolą pracować w twórczym chaosie czy w sposób uporządkowany
* CRACK (ang. Collaborative, Representative, Authorized, Committed, Knowledgeable) – chętny do współpracy, reprezentatywny, uprawniony, zaangażowany, posiadający odpowiednią wiedzę
Model skrócony (5 kryteriów)
- Rozmiar – mały czy duży projekt i zespół
- Krytyczność – niewielkie fundusze czy życie ludzi
- Dynamika – 50% czy 1% wymagań zmieniających się w miesiącu
- Osoby – wiele czy niewiele osób samodzielnych i znających metodyki zwinne
- Kultura – osoby wolą pracować w twórczym chaosie czy w sposób uporządkowany
Model sterowany ryzykiem
Otoczenie projektu – zagrożenia wynikające z ogólnego otoczenia projektu:
- E-Tech. Niepewność technologiczna
- E-Coord. Wielu różnych udziałowców do koordynacji
- E-Cmplx. Złożony system systemów
Zagrożenia zwinne – charakterystyczne dla metodyk zwinnych:
- A-Scale. Skalowalność i krytyczność
- A-YAGNI. Trudne, ograniczone użycie prostego projektu lub zasady YAGNI
- A-Churn. Zmienność (utrata) kadry
- A-Skill. Brak osób umiejących stosować metodyki zwinne
Zagrożenia dyscypliny – charakterystyczne dla metodyk sterowanych planem:
- P-Change. Częste zmiany
- P-Speed. Potrzeba szybkich rezultatów
- P-Emerge. Nowe wymagania
- P-Skill. Brak osób umiejących stosować metodyki sterowane planem
Wykorzystanie modeli ocen
Na czym polega wykorzystanie tych modeli? Każdy z nich wskazuje, w jakim kierunku skłania się Twój projekt – czy bliżej mu do podejścia zwinnego czy sterowanego planem. Możesz porównać te wyniki i wskazać dominujące. Wybór odpowiedniej metodyki polega nie tylko na wskazaniu jednej z gotowych metodyk. Jeśli nasz projekt znajduje się na jednym z biegunów, to dobrze – wybierzmy np. Scrum albo RUP (przycięty!). We wszystkich przypadkach pośrednich, spróbuj znaleźć równowagę – połączyć praktyki z obu światów, by odpowiedzieć na cele projektu i jednocześnie zidentyfikowane zagrożenia.
Przycinanie metodyki
Niekiedy słyszy się, że metodyki sterowane planem (podejście zdyscyplinowane) nie przystaje do możliwości i potrzeb w projektach i po prostu nie da się tego zastosować. Bywa to stosowane jako wymówka na kiepskiej jakości proces wytwarzania. Nie zapominaj, że metodyk takich jak RUP, Prince II, nie stosuje się nigdy w całości! Cała zabawa polega na tym, żeby umiejętnie przyciąć – wybrać takie aktywności, role i produkty pracy, które będą niezbędne do osiągnięcia celów projektu z zakładaną jakością. I ani jednego więcej!
Narzędziem do przycinania RUP może być stworzony przez IBM Rational Method Composer. Posiada on dołączoną bibliotekę elementów RUP, z których możesz wybrać pasujące do Twojego projektu.
Tworzenie własnych procesów
Jeśli stwierdzisz, że masz świetny pomysł na całkiem własny model pracy w projekcie, możesz przygotować go sam. Przykładek narzędzia, które umożliwi wprowadzenie elementów procesu i zarządzanie nimi, a później udostępnienie wszystkim pracownikom, jest EPF Composer (http://www.eclipse.org/epf/). Jego sporą zaletą jest to, że jest darmowe. Możliwości EPF-a jak najbardziej pozwalają wykonać postawione przed nim zadania. Jeśli znasz inne ciekawe narzędzie, daj znać 😉
Dla EPF-a dostępnych jest także wiele gotowych bibliotek procesów (http://www.eclipse.org/epf/downloads/praclib/praclib_downloads.php). Scrum, XP, Open Up. Warto zapoznać się i wykorzystać.
Pamiętaj, że między metodykami zwinnymi a mocno zdyscyplinowanymi jest jeszcze całe spektrum możliwości. Znajdź sposób na swój projekt, by zachować porządek, ale też nie puścić firmy z torbami 😉
Źródła:
- Boehm B., Turner R., Balancing Agility and Discipline, A Guide for the Perplexed, Addison-Wesley, 2004
- Miler J. (2012): Realizacja projektu informatycznego, Niepublikowane materiały, Politechnika Gdańska.
