SlideShare une entreprise Scribd logo
1  sur  21
Télécharger pour lire hors ligne
Umowy agile - zakres, zasoby, pieniądze 
- jak tworzyć zwinne kontrakty 
Agile Management 2014
18% 43% 39% 
PORAŻKA PROBLEM SUKCES 
źródło: 2012 Chaos Research
>50% trudności w określeniu wymagań, 
zmiana wymagań w czasie projektu 
źródło: 2012 Chaos Research
250mln $ 500mln $ 125mln 
California vs. SAP NYC vs. SAIC Avon vs. SAP
Agile - nowe podejście do umów IT 
• co chcemy zrobić 
• jak chcemy to zrobić 
• i co jeśli się nie uda
przedmiot umowy - rezultat projektu 
• dzieło czy usługa - rezultat czy staranność 
• Product Vision / Product Backlog / User Case 
• rezultat jest nieznany do czasu ukończenia projektu (?)
Product Vision 
• nadrzędne cele projektu 
• wysokopoziomowe korzyści projektu 
• opracowane przed startem negocjacji (mają pomóc zespołom 
negocjacyjnym w zrozumieniu intencji i celów projektu) 
• forma - załącznik do umowy
Product Backlog 
• powstaje w toku negocjacji albo już po podpisaniu umowy (precyzyjna procedura 
przeprowadzenie warsztatu w celu stworzenia PB) 
• zobowiązanie wykonawcy do oszacowania nakładów oraz czasu potrzebnych dla realizacji 
poszczególnych user case; szacunki wykonane z należytą starannością, w dobrej wierze, w 
oparciu o racjonalne założenia; opcjonalnie: w przypadku sporu procedura eskalacyjna 
• zobowiązanie Właściciela Produktu do priorytetyzacji poszczególnych user case 
• wyraźne postanowienia umowy: (i) Właściciel Produktu nie może zmieniać szacunków 
realizacji user case przedstawionych przez CZ (zmiana tylko za wspólną zgodą stron), (ii) 
zakres lub priorytet poszczególnych user case nie może być zmieniany, kiedy został już 
przyjęty do realizacji w ramach sprintu
Sprint 
• co reguluje umowa, co ustalenia robocze - elastyczność i dyscyplina 
• umowa określa długość sprintów przewidzianych dla projektu 
• umowa określa rodzaj, zakres oraz przebieg spotkań w ramach sprintów: sprint 
planning meetings, daily meetings, sprint review meetings 
• wyraźne oświadczenie stron, że (i) długość poszczególnych sprintów nie może być 
przedłużana oraz, (ii) że przypisanie user case do danego sprintu nie podlega 
zmianie 
• procedura rolowania sprintów (opcjonalnie „pauza” pomiędzy sprintami) 
• procedura opracowania Sprint Backlogu (opcjonalnie wzór formatki dla Sprint 
Backlogu jako załącznik do umowy)
Definition of Done 
• „sól” projektów Agile - wyzwanie dla prawników 
• opcjonalne kryteria: (i) element przeszedł pomyślnie testy, (ii) cała konieczna dokumentacja została 
zgromadzona, (iii) element spełnia założone przez strony standardy kodowania 
• modelowo: kryteria Definition of Done ustalone podczas negocjacji, w formie załącznika do umowy 
• umowa powinna zawierać postanowienia nakładające na Właściciela Produktu oraz zespół developerski 
obowiązek określenia podczas Sprint planning meetings, w jaki sposób DoD będą obowiązywać wobec 
poszczególnych elementów (user case) 
• umowa powinna zawierać postanowienia nakładające na Scrum Mastera obowiązek zapewnienia, że 
wszystkie elementy prezentowane podczas danego Sprint review meeting poddane zostały weryfikacji 
względem kryteriów DoD 
• procedura rozwiązywania sporów pomiędzy stronami co do okoliczności czy dany element spełnia kryteria 
wynikające z DoD
Zakończenie projektu 
• umowa powinna określać kiedy przedmiot umowy (projekt) uznawany będzie za 
zrealizowany 
• projekt uznaje się za zrealizowany jeśli wszystkie elementy składające się na 
Product Backlog (Rejestr Wymagań) zostały zrealizowane przy spełnieniu 
kryteriów wynikających z Definition od Done 
• ważne: lista elementów składających się na Rejestr Wymagań w końcowym etapie 
projektu może różnić się od tej listy opracowanej na stracie projektu - w czasie 
realizacji projektu Właściciel Produktu może podjąć decyzję o wycofaniu z realizacji 
wybranych elementów składających się na Rejestr Wymagań
Rozliczenia 
• fixed price czy time & material 
• time & material w projektach Agile to czek in blanco (?) 
• co przemawia za time & material: (i) w projektach wdrożeniowych IT zawsze będą zmiany 
zakresu, bez znaczenia czy w modelu Waterfall czy Agile, (ii) fixed price wypacza model Agile, 
odwołuje się do niepożądanych z punktu widzenia pomyślności projektu przyzwyczajeń (zły 
wpływ na współdziałanie stron), (iii) fixed price ≠ fixed budget 
• time & material może nie sprzyjać realnym szacunkom wykonawcy 
• Modele: (i) fixed price za sprint, (ii) fixed price za user case, (iii) fixed price za ustaloną liczbę 
user case 
• do umowy: wyraźnie określony model/modele wynagrodzenia, (ii) kiedy fakturujemy, (iii) kto 
ponosi koszty za user case nie zrealizowane podczas sprintu albo które nie spełniły kryteriów 
DoD, (iv) jak zmniejszenie zakresu lub wcześniejsze zakończenie projektu wpływa na 
rozliczenia
Odpowiedzialność 
• czy współpraca to współodpowiedzialność 
• kary umowne (za co, wysokość, uchwała Sądu Najwyższego) 
• Product Description (Opis Produktu) przygotowany przez wykonawcę: (i) 
precyzyjny opis tego co zostało zrobione (projekt i funkcjonalności wykonanego 
produktu), (ii) zaprezentowanie jak wykonany produkt odpowiada Wizji Produktu 
(Project Vision) 
• modele ograniczenia odpowiedzialności
Odstąpienie od umowy 
• ustawowe, umowne, „autorskie” 
• co po odstąpieniu – procedura zakończenia współpracy (rozliczenia, IP, kody 
źródłowe) 
• kary umowne za odstąpienie (uchwała Sądu Najwyższego)
Kluczowe role 
• Product Owner (Właściciel Produktu) 
• Scrum Master (Mistrz Młyna) 
• Development Team (Członkowie Zespołu)
Product Owner 
• umowa jest upoważnieniem (pełnomocnictwem) do działania PO 
• zapewnienie dla wykonawcy że PO ma odpowiednie doświadczenie w projektach 
Agile 
• zakres obowiązków - opracowanie, priorytetyzacja i aktualizacja Rejestru 
Wymagań 
• zapewnienie odpowiedniego poziomu dyspozycyjności i responsywności PO 
• zmiana PO tylko z ważnych powodów (procedura)
Scrum Master 
• rezygnujemy ze SM (problem kiedy nie mamy dużego doświadczenia w Agile) 
• SM jest członkiem personelu zamawiającego albo wykonawcy (czy mamy osobę o 
takich kompetencjach) 
• SM jako konsultant zewnętrzny (czy mamy budżet, czy SM zbuduje odpowiednie 
relacje z PO i zespołem developerskim)
Scrum Master 
• umowa wskazuje SM albo procedurę jego wyłonienia 
• zapewnienie, że SM ma odpowiednie doświadczenie i kompetencje w projektach 
Agile 
• zakres obowiązków – to nie Kierownik Projektu, raczej trener/mentor, wsparcie dla 
PO i zespołu 
• zapewnienie odpowiedniego poziomu dyspozycyjności i responsywności SM 
• zmiana SM za zgodą zamawiającego, tylko z ważnych powodów (procedura)
Development Team 
• członkowie zespołu wskazani w umowie albo zaproponowani już po zawarciu 
umowy 
• prawo zamawiającego do akceptacji zespołu developerskiego 
• jeśli zamawiający nie zaakceptuje zaproponowanych członków zespołu, wtedy 
procedura eskalacyjna (np. 4 tyg.) 
• dalszy brak akceptacji = prawo każdej strony do odstąpienia od umowy 
• odpowiedni poziom doświadczenia i kompetencji 
• zmiana tylko w ważnych powodów
albo Waterfall 
albo Agile
Dziękuję za uwagę 
lwegrzyn@maruta.pl 
www.maruta.pl

Contenu connexe

En vedette

Zarządzanie informacją i automatyzacja procesów biznesowych
Zarządzanie informacją i automatyzacja procesów biznesowychZarządzanie informacją i automatyzacja procesów biznesowych
Zarządzanie informacją i automatyzacja procesów biznesowychJaroslaw Zelinski
 
So you are going to court! An overview of what you need to know if you are in...
So you are going to court! An overview of what you need to know if you are in...So you are going to court! An overview of what you need to know if you are in...
So you are going to court! An overview of what you need to know if you are in...Brisbane Family Law Centre
 
J. Żelinski: Rezygnujemy z waterfall...
J. Żelinski: Rezygnujemy z waterfall...J. Żelinski: Rezygnujemy z waterfall...
J. Żelinski: Rezygnujemy z waterfall...Jaroslaw Zelinski
 
Pomysł na analizę w Agile: Agile Modeling
Pomysł na analizę w Agile: Agile ModelingPomysł na analizę w Agile: Agile Modeling
Pomysł na analizę w Agile: Agile ModelingPaweł Jarosiński
 

En vedette (6)

Zarządzanie informacją i automatyzacja procesów biznesowych
Zarządzanie informacją i automatyzacja procesów biznesowychZarządzanie informacją i automatyzacja procesów biznesowych
Zarządzanie informacją i automatyzacja procesów biznesowych
 
So you are going to court! An overview of what you need to know if you are in...
So you are going to court! An overview of what you need to know if you are in...So you are going to court! An overview of what you need to know if you are in...
So you are going to court! An overview of what you need to know if you are in...
 
J. Żelinski: Rezygnujemy z waterfall...
J. Żelinski: Rezygnujemy z waterfall...J. Żelinski: Rezygnujemy z waterfall...
J. Żelinski: Rezygnujemy z waterfall...
 
What's The Name of That Legal Thingy?
What's The Name of That Legal Thingy?What's The Name of That Legal Thingy?
What's The Name of That Legal Thingy?
 
Pomysł na analizę w Agile: Agile Modeling
Pomysł na analizę w Agile: Agile ModelingPomysł na analizę w Agile: Agile Modeling
Pomysł na analizę w Agile: Agile Modeling
 
Australian Consumer Law
Australian Consumer LawAustralian Consumer Law
Australian Consumer Law
 

Similaire à Umowy agile - zakres, zasoby, pieniądze - jak tworzyć zwinne kontrakty

Szkolenie zarządzanie projektami wersja
Szkolenie zarządzanie projektami wersjaSzkolenie zarządzanie projektami wersja
Szkolenie zarządzanie projektami wersjaRoman Morawski-Jagram
 
Wiosenne Wieczory ze Scrum 1 Rzut okiem na Scrum
Wiosenne Wieczory ze Scrum 1 Rzut okiem na ScrumWiosenne Wieczory ze Scrum 1 Rzut okiem na Scrum
Wiosenne Wieczory ze Scrum 1 Rzut okiem na ScrumMichał Parkoła
 
Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...
Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...
Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...Michal Bukowski, MBA, P2P
 
Zarzadzanie projektami metodą SCRUM
Zarzadzanie projektami metodą SCRUMZarzadzanie projektami metodą SCRUM
Zarzadzanie projektami metodą SCRUMKarol Wnukiewicz
 
Agile Silesia - Scrum w zespołach rozproszonych - Łukasz Kempny
Agile Silesia - Scrum w zespołach rozproszonych - Łukasz KempnyAgile Silesia - Scrum w zespołach rozproszonych - Łukasz Kempny
Agile Silesia - Scrum w zespołach rozproszonych - Łukasz KempnyAgile Silesia
 
Skuteczne Zarządzanie Projektami Internetowymi 2015
Skuteczne Zarządzanie Projektami Internetowymi 2015Skuteczne Zarządzanie Projektami Internetowymi 2015
Skuteczne Zarządzanie Projektami Internetowymi 2015GoTechnologies sp. z o.o.
 
XIII Targi eHandlu - AtomStore - Łukasz Plutecki
XIII Targi eHandlu - AtomStore - Łukasz PluteckiXIII Targi eHandlu - AtomStore - Łukasz Plutecki
XIII Targi eHandlu - AtomStore - Łukasz Pluteckiecommerce poland expo
 
Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...
Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...
Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...Moonbite S.A.
 
Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...
Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...
Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...Business Link Krakow
 
4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...
4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...
4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...PROIDEA
 
JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...
JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...
JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...PROIDEA
 
Obietnice i wyzwania Robotic Process Automation - 2018.04
Obietnice i wyzwania Robotic Process Automation - 2018.04Obietnice i wyzwania Robotic Process Automation - 2018.04
Obietnice i wyzwania Robotic Process Automation - 2018.04TRostkowski
 
To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka.
To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka. To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka.
To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka. Piotr Grabski-Gradziński
 
Jak nie zabić swojego klienta/programisty?
Jak nie zabić swojego klienta/programisty?Jak nie zabić swojego klienta/programisty?
Jak nie zabić swojego klienta/programisty?NetDay
 
Scrum (Polish version) - wprowadzenie do frameworka
Scrum (Polish version) - wprowadzenie do frameworkaScrum (Polish version) - wprowadzenie do frameworka
Scrum (Polish version) - wprowadzenie do frameworkaalbrzykowski
 

Similaire à Umowy agile - zakres, zasoby, pieniądze - jak tworzyć zwinne kontrakty (20)

Szkolenie zarządzanie projektami wersja
Szkolenie zarządzanie projektami wersjaSzkolenie zarządzanie projektami wersja
Szkolenie zarządzanie projektami wersja
 
Wiosenne Wieczory ze Scrum 1 Rzut okiem na Scrum
Wiosenne Wieczory ze Scrum 1 Rzut okiem na ScrumWiosenne Wieczory ze Scrum 1 Rzut okiem na Scrum
Wiosenne Wieczory ze Scrum 1 Rzut okiem na Scrum
 
Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...
Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...
Projekty internetowe: książka kucharska czyli... szczypta teorii i kocioł p...
 
Zarządzanie umowami
Zarządzanie umowamiZarządzanie umowami
Zarządzanie umowami
 
Zwinny_Analityk_SIW_Panel
Zwinny_Analityk_SIW_PanelZwinny_Analityk_SIW_Panel
Zwinny_Analityk_SIW_Panel
 
Zarzadzanie projektami metodą SCRUM
Zarzadzanie projektami metodą SCRUMZarzadzanie projektami metodą SCRUM
Zarzadzanie projektami metodą SCRUM
 
Agile Silesia - Scrum w zespołach rozproszonych - Łukasz Kempny
Agile Silesia - Scrum w zespołach rozproszonych - Łukasz KempnyAgile Silesia - Scrum w zespołach rozproszonych - Łukasz Kempny
Agile Silesia - Scrum w zespołach rozproszonych - Łukasz Kempny
 
Skuteczne Zarządzanie Projektami Internetowymi 2015
Skuteczne Zarządzanie Projektami Internetowymi 2015Skuteczne Zarządzanie Projektami Internetowymi 2015
Skuteczne Zarządzanie Projektami Internetowymi 2015
 
XIII Targi eHandlu - AtomStore - Łukasz Plutecki
XIII Targi eHandlu - AtomStore - Łukasz PluteckiXIII Targi eHandlu - AtomStore - Łukasz Plutecki
XIII Targi eHandlu - AtomStore - Łukasz Plutecki
 
Scrum
ScrumScrum
Scrum
 
Scam, scum, sacrum
Scam, scum, sacrumScam, scum, sacrum
Scam, scum, sacrum
 
Agile methodology
Agile methodologyAgile methodology
Agile methodology
 
Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...
Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...
Od pierwszego spotkania z klientem do gotowego produktu. 5 etapów przygotowan...
 
Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...
Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...
Piotr Grabski-Gradziński (VML) - To jak zrobimy ten projekt? Czyli o doborze ...
 
4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...
4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...
4Developers 2015: "Eksperckość" pułapka na UX Designera - Arkadiusz Smółko...
 
JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...
JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...
JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...
 
Obietnice i wyzwania Robotic Process Automation - 2018.04
Obietnice i wyzwania Robotic Process Automation - 2018.04Obietnice i wyzwania Robotic Process Automation - 2018.04
Obietnice i wyzwania Robotic Process Automation - 2018.04
 
To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka.
To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka. To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka.
To jak zrobimy ten projekt? Czyli o doborze technologii słów kilka.
 
Jak nie zabić swojego klienta/programisty?
Jak nie zabić swojego klienta/programisty?Jak nie zabić swojego klienta/programisty?
Jak nie zabić swojego klienta/programisty?
 
Scrum (Polish version) - wprowadzenie do frameworka
Scrum (Polish version) - wprowadzenie do frameworkaScrum (Polish version) - wprowadzenie do frameworka
Scrum (Polish version) - wprowadzenie do frameworka
 

Umowy agile - zakres, zasoby, pieniądze - jak tworzyć zwinne kontrakty

  • 1. Umowy agile - zakres, zasoby, pieniądze - jak tworzyć zwinne kontrakty Agile Management 2014
  • 2. 18% 43% 39% PORAŻKA PROBLEM SUKCES źródło: 2012 Chaos Research
  • 3. >50% trudności w określeniu wymagań, zmiana wymagań w czasie projektu źródło: 2012 Chaos Research
  • 4. 250mln $ 500mln $ 125mln California vs. SAP NYC vs. SAIC Avon vs. SAP
  • 5. Agile - nowe podejście do umów IT • co chcemy zrobić • jak chcemy to zrobić • i co jeśli się nie uda
  • 6. przedmiot umowy - rezultat projektu • dzieło czy usługa - rezultat czy staranność • Product Vision / Product Backlog / User Case • rezultat jest nieznany do czasu ukończenia projektu (?)
  • 7. Product Vision • nadrzędne cele projektu • wysokopoziomowe korzyści projektu • opracowane przed startem negocjacji (mają pomóc zespołom negocjacyjnym w zrozumieniu intencji i celów projektu) • forma - załącznik do umowy
  • 8. Product Backlog • powstaje w toku negocjacji albo już po podpisaniu umowy (precyzyjna procedura przeprowadzenie warsztatu w celu stworzenia PB) • zobowiązanie wykonawcy do oszacowania nakładów oraz czasu potrzebnych dla realizacji poszczególnych user case; szacunki wykonane z należytą starannością, w dobrej wierze, w oparciu o racjonalne założenia; opcjonalnie: w przypadku sporu procedura eskalacyjna • zobowiązanie Właściciela Produktu do priorytetyzacji poszczególnych user case • wyraźne postanowienia umowy: (i) Właściciel Produktu nie może zmieniać szacunków realizacji user case przedstawionych przez CZ (zmiana tylko za wspólną zgodą stron), (ii) zakres lub priorytet poszczególnych user case nie może być zmieniany, kiedy został już przyjęty do realizacji w ramach sprintu
  • 9. Sprint • co reguluje umowa, co ustalenia robocze - elastyczność i dyscyplina • umowa określa długość sprintów przewidzianych dla projektu • umowa określa rodzaj, zakres oraz przebieg spotkań w ramach sprintów: sprint planning meetings, daily meetings, sprint review meetings • wyraźne oświadczenie stron, że (i) długość poszczególnych sprintów nie może być przedłużana oraz, (ii) że przypisanie user case do danego sprintu nie podlega zmianie • procedura rolowania sprintów (opcjonalnie „pauza” pomiędzy sprintami) • procedura opracowania Sprint Backlogu (opcjonalnie wzór formatki dla Sprint Backlogu jako załącznik do umowy)
  • 10. Definition of Done • „sól” projektów Agile - wyzwanie dla prawników • opcjonalne kryteria: (i) element przeszedł pomyślnie testy, (ii) cała konieczna dokumentacja została zgromadzona, (iii) element spełnia założone przez strony standardy kodowania • modelowo: kryteria Definition of Done ustalone podczas negocjacji, w formie załącznika do umowy • umowa powinna zawierać postanowienia nakładające na Właściciela Produktu oraz zespół developerski obowiązek określenia podczas Sprint planning meetings, w jaki sposób DoD będą obowiązywać wobec poszczególnych elementów (user case) • umowa powinna zawierać postanowienia nakładające na Scrum Mastera obowiązek zapewnienia, że wszystkie elementy prezentowane podczas danego Sprint review meeting poddane zostały weryfikacji względem kryteriów DoD • procedura rozwiązywania sporów pomiędzy stronami co do okoliczności czy dany element spełnia kryteria wynikające z DoD
  • 11. Zakończenie projektu • umowa powinna określać kiedy przedmiot umowy (projekt) uznawany będzie za zrealizowany • projekt uznaje się za zrealizowany jeśli wszystkie elementy składające się na Product Backlog (Rejestr Wymagań) zostały zrealizowane przy spełnieniu kryteriów wynikających z Definition od Done • ważne: lista elementów składających się na Rejestr Wymagań w końcowym etapie projektu może różnić się od tej listy opracowanej na stracie projektu - w czasie realizacji projektu Właściciel Produktu może podjąć decyzję o wycofaniu z realizacji wybranych elementów składających się na Rejestr Wymagań
  • 12. Rozliczenia • fixed price czy time & material • time & material w projektach Agile to czek in blanco (?) • co przemawia za time & material: (i) w projektach wdrożeniowych IT zawsze będą zmiany zakresu, bez znaczenia czy w modelu Waterfall czy Agile, (ii) fixed price wypacza model Agile, odwołuje się do niepożądanych z punktu widzenia pomyślności projektu przyzwyczajeń (zły wpływ na współdziałanie stron), (iii) fixed price ≠ fixed budget • time & material może nie sprzyjać realnym szacunkom wykonawcy • Modele: (i) fixed price za sprint, (ii) fixed price za user case, (iii) fixed price za ustaloną liczbę user case • do umowy: wyraźnie określony model/modele wynagrodzenia, (ii) kiedy fakturujemy, (iii) kto ponosi koszty za user case nie zrealizowane podczas sprintu albo które nie spełniły kryteriów DoD, (iv) jak zmniejszenie zakresu lub wcześniejsze zakończenie projektu wpływa na rozliczenia
  • 13. Odpowiedzialność • czy współpraca to współodpowiedzialność • kary umowne (za co, wysokość, uchwała Sądu Najwyższego) • Product Description (Opis Produktu) przygotowany przez wykonawcę: (i) precyzyjny opis tego co zostało zrobione (projekt i funkcjonalności wykonanego produktu), (ii) zaprezentowanie jak wykonany produkt odpowiada Wizji Produktu (Project Vision) • modele ograniczenia odpowiedzialności
  • 14. Odstąpienie od umowy • ustawowe, umowne, „autorskie” • co po odstąpieniu – procedura zakończenia współpracy (rozliczenia, IP, kody źródłowe) • kary umowne za odstąpienie (uchwała Sądu Najwyższego)
  • 15. Kluczowe role • Product Owner (Właściciel Produktu) • Scrum Master (Mistrz Młyna) • Development Team (Członkowie Zespołu)
  • 16. Product Owner • umowa jest upoważnieniem (pełnomocnictwem) do działania PO • zapewnienie dla wykonawcy że PO ma odpowiednie doświadczenie w projektach Agile • zakres obowiązków - opracowanie, priorytetyzacja i aktualizacja Rejestru Wymagań • zapewnienie odpowiedniego poziomu dyspozycyjności i responsywności PO • zmiana PO tylko z ważnych powodów (procedura)
  • 17. Scrum Master • rezygnujemy ze SM (problem kiedy nie mamy dużego doświadczenia w Agile) • SM jest członkiem personelu zamawiającego albo wykonawcy (czy mamy osobę o takich kompetencjach) • SM jako konsultant zewnętrzny (czy mamy budżet, czy SM zbuduje odpowiednie relacje z PO i zespołem developerskim)
  • 18. Scrum Master • umowa wskazuje SM albo procedurę jego wyłonienia • zapewnienie, że SM ma odpowiednie doświadczenie i kompetencje w projektach Agile • zakres obowiązków – to nie Kierownik Projektu, raczej trener/mentor, wsparcie dla PO i zespołu • zapewnienie odpowiedniego poziomu dyspozycyjności i responsywności SM • zmiana SM za zgodą zamawiającego, tylko z ważnych powodów (procedura)
  • 19. Development Team • członkowie zespołu wskazani w umowie albo zaproponowani już po zawarciu umowy • prawo zamawiającego do akceptacji zespołu developerskiego • jeśli zamawiający nie zaakceptuje zaproponowanych członków zespołu, wtedy procedura eskalacyjna (np. 4 tyg.) • dalszy brak akceptacji = prawo każdej strony do odstąpienia od umowy • odpowiedni poziom doświadczenia i kompetencji • zmiana tylko w ważnych powodów
  • 21. Dziękuję za uwagę lwegrzyn@maruta.pl www.maruta.pl