...

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

by lukasz-wegrzyn

on

Report

Category:

Law

Download: 0

Comment: 0

1,022

views

Comments

Description

prezentacja przedstawiona podczas konferencji Agile Management 2014
Download Umowy agile - zakres, zasoby, pieniądze - jak tworzyć zwinne kontrakty

Transcript

  • 1. Umowy agile - zakres, zasoby, pieniądze- jak tworzyć zwinne kontraktyAgile 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 $ 125mlnCalifornia 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łomnegocjacyjnym 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 proceduraprzeprowadzenie warsztatu w celu stworzenia PB)• zobowiązanie wykonawcy do oszacowania nakładów oraz czasu potrzebnych dla realizacjiposzczególnych user case; szacunki wykonane z należytą starannością, w dobrej wierze, woparciu 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ówrealizacji 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: sprintplanning 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 podlegazmianie• procedura rolowania sprintów (opcjonalnie „pauza” pomiędzy sprintami)• procedura opracowania Sprint Backlogu (opcjonalnie wzór formatki dla SprintBacklogu 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łazgromadzona, (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ół developerskiobowiązek określenia podczas Sprint planning meetings, w jaki sposób DoD będą obowiązywać wobecposzczególnych elementów (user case)• umowa powinna zawierać postanowienia nakładające na Scrum Mastera obowiązek zapewnienia, żewszystkie elementy prezentowane podczas danego Sprint review meeting poddane zostały weryfikacjiwzględem kryteriów DoD• procedura rozwiązywania sporów pomiędzy stronami co do okoliczności czy dany element spełnia kryteriawynikające z DoD
  • 11. Zakończenie projektu• umowa powinna określać kiedy przedmiot umowy (projekt) uznawany będzie zazrealizowany• projekt uznaje się za zrealizowany jeśli wszystkie elementy składające się naProduct Backlog (Rejestr Wymagań) zostały zrealizowane przy spełnieniukryteriów wynikających z Definition od Done• ważne: lista elementów składających się na Rejestr Wymagań w końcowym etapieprojektu może różnić się od tej listy opracowanej na stracie projektu - w czasierealizacji projektu Właściciel Produktu może podjąć decyzję o wycofaniu z realizacjiwybranych 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ą zmianyzakresu, 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ływpł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) ktoponosi koszty za user case nie zrealizowane podczas sprintu albo które nie spełniły kryteriówDoD, (iv) jak zmniejszenie zakresu lub wcześniejsze zakończenie projektu wpływa narozliczenia
  • 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 wykonanegoproduktu), (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 projektachAgile• zakres obowiązków - opracowanie, priorytetyzacja i aktualizacja RejestruWymagań• 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ę otakich kompetencjach)• SM jako konsultant zewnętrzny (czy mamy budżet, czy SM zbuduje odpowiednierelacje 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 projektachAgile• zakres obowiązków – to nie Kierownik Projektu, raczej trener/mentor, wsparcie dlaPO 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 zawarciuumowy• prawo zamawiającego do akceptacji zespołu developerskiego• jeśli zamawiający nie zaakceptuje zaproponowanych członków zespołu, wtedyprocedura 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
  • 20. albo Waterfallalbo Agile
  • 21. Dziękuję za uwagęlwegrzyn@maruta.plwww.maruta.pl
  • Fly UP