Wykorzystanie metodyki Agile w projektach IT w instytucjach publicznych – jak napisać OPZ?

Czym różni się metodyka Agile od Waterfall?

Metodyka Agile (zwinna) zdobywa coraz większą popularność w realizacji projektów IT – także w sektorze publicznym – jednak podejście to istotnie różni się od tradycyjnego modelu kaskadowego Waterfall. Waterfall zakłada realizację projektu etapami – najpierw pełna analiza i planowanie, potem implementacja, a na końcu testowanie i odbiór gotowego rozwiązania. Agile natomiast dzieli projekt na krótkie iteracje (sprinty) dostarczające działające fragmenty systemu, co umożliwia bieżące weryfikowanie rezultatów oraz elastyczne reagowanie na zmiany w wymaganiach. Różnice obejmują m.in. strukturę pracy, sposób komunikacji, podejście do zmian oraz proces testowania – zestawiono je poniżej w formie tabeli:

Dla jakich projektów IT dedykowana jest metodyka Agile?

Agile jest rekomendowany szczególnie dla projektów, w których zakres i wymagania mogą ewoluować lub nie są od początku jasno zdefiniowane. Sprawdza się przy przedsięwzięciach innowacyjnych, złożonych albo o długim horyzoncie czasowym, gdzie potrzebna jest szybka reakcja na informację zwrotną od użytkowników. Choć Agile kojarzony bywa z mniejszymi zespołami, istnieją też metody skalowania zwinnego podejścia (np. Scaled Agile Framework), pozwalające z powodzeniem stosować je w dużych, złożonych projektach informatycznych – również w sektorze publicznym.

Na co zwrócić uwagę w opracowaniu OPZ chcąc zaplanować realizację projektu w oparciu o Agile?

Tworząc OPZ (Opis Przedmiotu Zamówienia) z myślą o realizacji projektu w Agile, zamawiający powinien skupić się na opisaniu oczekiwanych rezultatów i funkcjonalności (czyli co ma zostać osiągnięte), a nie narzucać wykonawcy szczegółowego sposobu realizacji (jak należy to zrobić). Takie podejście zostawia wykonawcy przestrzeń na dobór optymalnych rozwiązań w trakcie iteracyjnego wytwarzania, a zamawiającemu daje możliwość elastycznego doprecyzowania wymagań w toku projektu. W dokumentacji warto też uwzględnić mechanizmy zwiększające elastyczność – przykładowo klauzulę prawa opcji pozwalającą rozszerzyć zakres prac lub określenie puli godzin na rozwój oprogramowania – zgodnie z zaleceniami rządowego poradnika „Dobre praktyki w zakresie stosowania metodyk Agile…” (2017). OPZ powinien również zawierać przejrzyste zasady współpracy, jasno określać role po stronie zamawiającego (np. wyznaczenie Product Ownera do szybkiego podejmowania decyzji) oraz wskazywać kryteria odbioru kolejnych przyrostów systemu.

Jak zorganizować przetarg przy wykorzystaniu Agile?

Przetarg na projekt realizowany zwinnie można przeprowadzić w standardowym trybie (np. przetargu nieograniczonego), pod warunkiem że dokumentacja została odpowiednio dostosowana do specyfiki Agile. Jeszcze przed ogłoszeniem postępowania warto rozważyć przeprowadzenie dialogu technicznego z wykonawcami w celu doprecyzowania założeń i zebrania opinii odnośnie planowanego podejścia. W samej dokumentacji przetargowej (SIWZ) należy jasno opisać oczekiwany sposób realizacji projektu – np. pracę w sprintach z regularnymi przeglądami postępów i częstym dostarczaniem kolejnych funkcjonalności – a także uwzględnić kryteria oceny ofert wykraczające poza cenę (takie jak doświadczenie zespołu w Agile czy jakość proponowanej koncepcji współpracy). Kluczowe jest również dostosowanie przyszłej umowy do modelu zwinnego – np. wprowadzenie prawa opcji, elastycznego harmonogramu i procedur zmian w trakcie projektu.

Jak może zareagować dostawca na zastosowanie Agile w projekcie?

Reakcje dostawców na zastosowanie metodyki Agile w projekcie publicznym mogą być zróżnicowane. Wykonawcy doświadczeni w Agile podejdą do takiego postępowania pozytywnie, doceniając bliską współpracę z zamawiającym, częsty feedback oraz możliwość korygowania wymagań na bieżąco, co zwiększa szanse powodzenia projektu. Inni, mniej zaznajomieni ze zwinnym podejściem, mogą podchodzić ostrożniej – Agile wymaga większego zaangażowania po stronie zamawiającego i elastyczności w ustalaniu zakresu, co niektóre firmy postrzegają jako ryzyko (utrudniając np. precyzyjne oszacowanie kosztów z góry).

Korzyści i ryzyka podejścia Agile

Poniższa tabela podsumowuje 5 kluczowych korzyści oraz 5 głównych ryzyk związanych z realizacją projektu IT w metodyce Agile:

Świadome zarządzanie powyższymi aspektami pozwoli czerpać pełne korzyści z Agile, jednocześnie minimalizując potencjalne ryzyka projektu.