dahliamaticlogoNa pytanie „czy można zarządzać projektami o stałym budżecie wykorzystując metodyki zwinne?” odpowiedź brzmi „tak”. Warto jednak zastanowić się jak połączyć wymagania projektu opartego o fixed price ze zwinnym frameworkiem, żeby nie wpędzić się w nieefektywność kosztową. Obecnie realizujemy projekty, których specyfika wymaga bardzo szczegółowego opisu (od cech funkcjonalnych aż po kwestie bezpieczeństwa) wypracowanego już na etapie analizy oraz z góry zdefiniowanego budżetu.

 REKLAMA 
 Baner srodtekstowy350x350 strona KSeF 
 
Dotyczy to między innymi projektów unijnych, w ramach których jesteśmy zobowiązani do przestrzegania terminów i zakresu funkcjonalnego, a jakiekolwiek zmiany w tych obszarach nie wchodzą w grę. Mimo tego, znając zalety metodyk zwinnych zdecydowaliśmy się wykorzystać jak największą część z nich łącząc je z elementami tradycyjnego zarządzania projektami. Jak? Wprowadziliśmy zasady AgilePM na poziomie prac developerskich.

Sztywny harmonogram, zwinny development

Na podstawie dokumentacji analitycznej wiemy jaki jest deadline wdrożenia i jakie wymagania mają zostać spełnione. Jedyny element, którym mogliśmy żonglować to organizacja pracy i to właśnie w tym obszarze zastosowaliśmy metodykę zwinną. Stworzyliśmy kompletny backlog (czyli spriorytetyzowaną listę wszystkich zadań potrzebnych do wytworzenia produktu końcowego) a następnie pracę nad nimi podzieliliśmy na timeboxy Oczywiście tylko w idealnym świecie pierwotny podział byłby również tym ostatecznym. Rzeczywistość projektowa zmusza nas do regularnego wprowadzania zmian, które często prowadzą do kolejnych zmian. Przy takim stopniu złożoności projektu musimy co 2 tygodnie weryfikować postęp prac, aktualizować plan i nadawać priorytety kolejnym zadaniom. A wszystko to w ramach pewnych nieprzekraczalnych kamieni milowych opisanych w harmonogramie projektu.

Poza samą organizacją prac programistycznych istotny jest również tryb testowania, który wybraliśmy. Testy UAT wykonujemy w trakcie procesu developmentu, co też jest jednym z założeń metodyk zwinnych. – mówi Klara Górska, Project Manager i Scrum Master z pionu Custom Development w DahliaMatic. Klient ma możliwość bieżącej weryfikacji funkcjonalności i działania systemu na „żywym organizmie”, co daje mu realny wpływ na proces wytwórczy. Nie byłoby to możliwe przy testach przeprowadzanych pod koniec projektu. Na tym etapie wprowadzenie niektórych zmian jest po prostu niemożliwe. Z kolei dla nas to szansa na szybkie wyłapanie i poprawienie błędów, a następnie nie powielanie ich w przyszłości.


Jak to rozliczyć?

Istnieje pogląd, że jedynym możliwym sposobem rozliczania projektu zwinnego jest T&M. Nasze doświadczenia mówią o tym, że fixed price oraz ograniczony harmonogram projektu nie wyklucza stosowania metodyk zwinnych. Jak to rozliczyć? Każdorazowo podchodzimy do analizy wymagań formalnych (np. w związku z dofinansowaniem unijnym) oraz możliwości zaangażowania klienta w rozwój systemu (ile czasu chce i może poświęcić w poszczególnych etapach). Odpowiedzi między innymi na te pytania pozwalają nam wypracować unikalny model współpracy i wytwarzania oprogramowania, dopasowany do danego projektu.

Sporo wyzwań, jeszcze więcej korzyści

Taka organizacja pracy nie jest typową w projektach o ustalonym budżecie, harmonogramie i zakresie, jednak niesie za sobą wiele korzyści. Przede wszystkim pozwala przemodelować rolę Klienta w projekcie. Duże zaangażowanie po jego stronie sprawia, że nasza współpraca ma często charakter partnerski. Dzięki tej relacji i otwartej komunikacji jesteśmy w stanie lepiej zrozumieć potrzeby Klienta i wprowadzać modyfikacje od razu po zaistnieniu takiej potrzeby, bez konieczności czekania na końcowy etap testów. Klient z kolei ma możliwość regularnej weryfikacji postępu w pracy i zgłaszania zastrzeżeń na bieżąco.

W ramach projektu tworzymy z Klientem jeden zespół, grający do tej samej bramki. Mamy wspólny cel i dzięki tak dużemu zaangażowaniu po obu stronach jesteśmy w stanie jeszcze lepiej zrozumieć jego potrzeby i wypracować optymalne rozwiązania. – dodaje Klara.


Poniżej przedstawiamy w skróconej formie proces wytwórczy uwzględniający development, testy wewnętrzne Wykonawcy oraz testy akceptacyjne Klienta. Przyrost aplikacji do weryfikacji klienta oddawany jest co 4 tygodnie, tym samym jest możliwe zebranie bieżącego feedbacku od użytkownika końcowego.

Proces wytwórczy uwzględniający development testy wewnętrzne oraz testy KlientaPomimo początkowego zdziwienia niecodziennym połączeniem scruma z fixed price, po chwili zastanowienia można określić to jako sytuację win-win. Klient ma gwarancje kosztów, zakresu i deadline’u. Dodatkowo regularnie weryfikuje efekty pracy i bierze czynny udział w realizacji projektu. My mamy dowolność w krótkoterminowej organizacji developmentu oraz możliwość bieżącego testowania i poprawiania ewentualnych błędów.

Źródło: www.dahliamatic.pl

PRZECZYTAJ RÓWNIEŻ:


Back to top