Umowy fixed price na projekty Agile ang. Fixed price agile contracts

Umowy fixed price na projekty Agile - model rozliczania stosowany przez dostawców i odbiorców projektów głównie IT, którzy realizują je korzystając z metod Agile (ang. Agile methods). Model wprowadza wstępną fazę testową, po której budżet, termin wykonania i sposób kierowania jest z góry uzgodniony.

Spis treści

Charakterystyka

Umowy fixed price na projekty Agile różną się od tradycyjnych umów fixed price (o ustalonej cenie). Tradycyjne umowy wymagają z góry szczegółowego i dokładnego opisu przedmiotu zamówienia i dążą do zminimalizowania potencjalnego ryzyka spowodowanego nieprzewidywalnymi, późniejszymi zmianami. Natomiast umowy Agile wymagają tylko szerokiego opisu całego projektu.[1]

W umowach Agile, wykonawca i klient wspólnie określają założenia w zakresie wartości biznesowej, ryzyka związanego z wdrażaniem, wydatków (poniesionego wysiłku) i kosztów. Na podstawie tych założeń uzgadniany jest orientacyjny zakres cenowy, który nie jest jeszcze umownie wiążący. Po tym następuje faza testowa (faza punktu kontrolnego), podczas której zaczyna się rzeczywiste wdrażanie. Pod koniec tej fazy, obie strony porównują wyniki doświadczenia z początkowymi założeniami. Następnie razem decydują o realizacji całego projektu i ustalają warunki, które pozwalają na wprowadzanie zmian.

Dalszymi punktami umowy Agile jest podział ryzyka (obie strony dzielą równo między siebie wydatki na niespodziewane zmiany) i możliwość odstąpienia od umowy na każdym etapie (punkty wyjścia) dla każdej ze stron.

Etapy procesu zawierania umów Agile

  • Pierwszy etap obejmuje sformułowanie treści umowy na poziomie ogólnym. Zawiera najważniejsze cele projektu, tematy, opowieści (ang. epic)[2] i ramy prawne[3].
  • Z opowieści (ang. epics) wybierana jest ta, która najlepiej odzwierciedla cały projekt. Następnie zostaje ona dookreślona i przekształcona na kilka historyjek użytkownika (ang. user stories). Dobrze wybrana opowieść powinna zamienić się w znaczącą liczbę historyjek użytkowników, z których każda jest inna, a razem obejmują szereg różnych funkcji. Stąd, mogą być używane w jako spis historyjek użytkownika.[4]
  • Następnie wykonawca i klient spotykają się, aby określić wydatki związane z całym projektem na podstawie odniesienia do historyjek użytkowników i wszystkich innych opowieści za pomocą punktów historyjek. Założenia uwzględnione są również w kategoriach ryzyka wdrażania i wartości biznesowej. Z kolei ta informacja prowadzi do sporządzenia przedziału finansowego, który nie jest jeszcze prawnie wiążący i zostaje ustalony dopiero na późniejszym etapie (na końcu tzw. etapu kontrolnego).
  • Następnie zostaje zdefiniowana faza kontrolna będąca fazą testową współpracy, podczas której rozpoczyna się wdrażanie i zostaje osiągnięty wstępny doświadczalny wgląd w projekt. Zalecane jest, aby ta faza trwała od dwóch do pięciu przebiegów (ang. Sprint) (przy długości jednego przebiegu wynoszącej dwa tygodnie). Na koniec fazy kontrolnej klient i wykonawca sprawdzają swoje początkowe założenia i podejmują decyzję czy nadal chcą realizować cały projekt czy tylko jego część. Wtedy, oficjalnie zostaje uzgodniona orientacyjna stała cena, a umowa staje się wiążąca. Podczas fazy kontrolnej określany jest również podział ryzyka, determinujący zakres, w jakim klient zostanie obciążony dodatkowymi wydatkami przewyższającymi ustaloną cenę.[5]
  • Potem muszą zostać zdefiniowane i obsadzone role odpowiedzialne za kierowanie projektem. Klient wybiera kierownika projektu (ang. project manager), wykonawcę (ang. supplier) i właściciela produktu (ang. Product Owner). Zaleca się zaangażowanie niezależnego konsultanta wybranego za porozumieniem obu stron. Wszystkie te role tworzą Komitet Sterujący (ang. steering committee) formalnie upoważniony do podejmowania decyzyji, który spotyka się regularnie i gwarantuje, że ciągły proces specyfikacyjny uwzględnia historyjki użytkowników ang. user stories)[6] jako najwyższe priorytetowe wymagania.
  • W przeciwieństwie do tradycyjnych projektów o stałej cenie, projekty z umową Agile mogą zakończyć się wcześniej, jeśli klient uzna, że uzyskał oczekiwaną wartość poprzez dostarczone już usługi. Może się tak zdarzyć, zanim wszystkie uzgodnione usługi zostaną wdrożone. Aby ta elastyczność umowy była korzystna zarówno dla klientów jak i wykonawców w sposób jednakowy, należy uzgodnić szczegóły umowy np. wykonawca może otrzymać zapłatę odpowiadającą pewnemu procentowi budżetu za niedostarczone usługi lub nowe zadanie na poczet pozostałego budżetu.


Krytyka

Umowy fixed price na projekty Agile są umowami ramowymi, najodpowiedniejszymi do złożonych projektów informatycznych, których zakres, rozwój i koszty są trudne do przewidzenia z góry. Dla standardowych projektów, które zostały przeprowadzone w taki sam lub podobny sposób w przeszłości, faza badania i oceny postępów w realizacji projektu może zostać pominięta. Aby ten model umowy odniósł sukces wykonawca i klient powinni ściśle współpracować przez cały czas trwania projektu. Ponadto niezbędna jest pewna ilość wzajemnego zaufania, żeby móc porozumieć się co do budżetu, kosztów i zakresu usług. Również wskazane jest jak najszybsze upewnienie się, że ogólne wymagania klienta (opowieści) wymienione na początku projektu są rozbite na mniejsze, bardziej szczegółowe wymagania (historyjki użytkownika). Inaczej może pojawić się niepewność i związane z nią ryzyka.

Linki sponsorowane



Zobacz też

Bibliografia

  • Agile contracts, Wikipedia en
  • Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr: Agile Contracts: Creating and Managing Successful Projects with Scrum, 1st edition, Wiley Series in Systems Engineering and Management, 2013.
  • Michael Overly, James R. Kalyvas: Software Agreements Line by Line. How to Understand & Change Software Licenses & Contracts to Fit Your Needs. Aspatore Books, 2004, ISBN 978-1-58762-369-1.
  • Eckhart Hanser: Agile Prozesse. Von XP über Scrum bis MAP Springer-Verlag, 2010, ISBN 978-3-642-12313-9.
ostatnia modyfikacja 20 sierpnia 2016 r.