Dołącz do Governautów, zarejestruj się
Załóż konto
Reklama

Drogi użytkowniku!
Wygląda na to, że używasz rozszerzenia blokującego reklamy.
W Governice nie stosujemy nachalnych reklam. Możesz bezpiecznie odblokować je na naszej stronie ;-)
Czym jest projekt? Jakie są standardy zarządzania projektem? Do czego służy Strenght Deployment Inventory? W znalezieniu odpowiedzi na te pytania pomocne będą informacje zamieszczone w tym dziale. Z artykułów dowiedzieć można się również czym jest PRINCE2, SCRUM czy Komitet Sterujący.
Umowy fixed price na projekty Agile Przekierowano ze strony: Fixed price agile contracts 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.
Charakterystyka
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
Linki sponsorowane
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.