Czy zwinne planowanie to najlepszy wybór? O metodach osiągania celu w projektach IT
Koniec projektu powinien być wyznaczony przez osiągnięcie celu. Aby przygotować początkowy, wysokopoziomowy plan działania, czyli nakreślić drogę (po niemiecku Fahrplan, po angielsku road map), powinniśmy określić zakres przedsięwzięcia. Czy warto szczegółowo planować jeszcze przed startem, czy może postawić na planowanie krótkich odcinków? Wśród metodyków łatwo znaleźć zwolenników obu opcji.
Początek drogi
If you don’t know where you are going, how can you expect to get there? – Basil S. Walsh
Dzięki planowaniu możemy łatwiej zdefiniować zadania do wykonania, ustalić zachodzące między nimi zależności i ramy czasowe, zdefiniować ryzyka, przygotować plan zasobów, zaplanować koszty oraz ROI, przygotować plan finansowania projektu i tym podobne. Gdy planujemy, łatwiej nam też podjąć decyzję, jak wiele jesteśmy w stanie zainwestować w nasze przedsięwzięcie. Jak widać, na pytanie, co jest powodem, dla którego warto planować, najszybsza odpowiedź to: pieniądze. Jak w takim razie planować efektywnie?
W przypadku tradycyjnych wdrożeń w projektach SAP-owych metodyka jest oparta głównie na hierarchicznej strukturze zadań (tzw. WBS-y, czyli work breakdown structure), która prowadzi do uzyskania określonych produktów i jest zgodna z tradycyjnym podejściem do realizacji projektów (tzw. waterfall). W praktyce wygląda to następująco: na podstawie zakresu prac do wykonania tworzymy listę zadań, która w kolejnym kroku zostaje uporządkowana w logicznej kolejności. Planujemy, jakie działanie poprzedzi inne, a także, które z nich można prowadzić równolegle. Może się bowiem okazać, że nie ma przeszkód, by nad paroma kwestiami pracować jednocześnie. Takie podejście jest bardzo popularne w projektach SAP-owych.
W tradycyjnym podejściu na początku opracowujemy szczegółową koncepcję, która następnie zostaje zatwierdzona, podpisana i odebrana przez klienta. Dopiero po tym procesie możemy rozpocząć pracę nad implementacją. To jest zamknięty okres – w zależności od skali projektu trwający czasami trzy miesiące, czasami rok – podczas którego nie ma punktów kontrolnych ze strony klienta. Oznacza to, że testy prowadzone są dopiero po odbiorze gotowego produktu przygotowanego ściśle według specyfikacji. Jak jednak pokazują statystyki, w większości projektów na etapie tworzenia koncepcji jest za mało informacji, żeby spełnić oczekiwania i zrealizować w pełni cel klienta. W związku z tym w trakcie końcowych testów, zgodnie z procedurą, realizuje się dodatkowe prace, które zostały zidentyfikowane jako luki między tym, co klient na początku uważał, że potrzebuje, a tym, czego rzeczywiście potrzebował.
Web do planowania
Plans are worthless. Planning is essential – Dwight D. Eisenhower
W projektach webowych, napisanych na przykład w java, .net czy w aplikacjach mobilnych, częściej używa się metodyk zwinnych zarządzania projektami (agile project management), z frameworkiem Scrum na czele. Takie podejście zasadza się na tworzeniu wysokopoziomowego backlogu produktu, czyli rejestru zadań koniecznych do zrealizowania danego projektu informatycznego, który ciągle poddaje się weryfikacji pod kątem wartości biznesowej. To wartość biznesowa, ze względu na istniejące zależności, „decyduje” o kolejności wykonywanych prac. Podejście zwinne nie narzuca, jaką postać zadania powinny przybrać – często są to na przykład user stories, dzięki którym możemy spojrzeć na dane zadanie oczami użytkownika (wszyscy użytkownicy na początku projektu są zdefiniowani i scharakteryzowani pod kątem ich potencjalnej interakcji z systemem) i dowiedzieć się, co on sam chciałby w systemie zrobić. Inna postać zadań to use cases, czyli przypadki użycia, opisujące konkretne sytuacje i funkcjonalności w systemie, które użytkownik chce wykorzystać.
Wykorzystałeś swój limit bezpłatnych treści
Pozostałe 73% artykułu dostępne jest dla zalogowanych użytkowników portalu. Zaloguj się, wybierz plan abonamentowy albo kup dostęp do artykułu/dokumentu.