W standardowym modelu podpisuje się umowę ze szczegółową specyfikacją tego, co klient ma otrzymać w określonym czasie i budżecie. Z założenia Scrum nie działa w taki sposób. Zatem, w jaki sposób sformułować umowę z klientem?
To bardzo złożony problem.
Zlecając dostarczenie Rozwiązania dostawcy zewnętrznemu w sposób scrumowy, Zamawiający(Klient) kupuje określony Zespół Deweloperski z jego kompetencjami na określoną(+/-) liczbę Sprintów. Nie jest możliwe (dlatego Scrum) określenie szczegółowego zakresu, który ma być dostarczony w zadanym czasie. Dlatego w umowie powinnniśmy określić raczej warunki realizacji, zasady planowania i zasady odbiorów (definition of done). W takiej umowie powinien się pojawić także Plan Release'ów. Nie można także pominąć mechanizmów zachęcających Zespół Deweloperski do wydajniejszej pracy pamiętając jednak, że motywacja pieniężna może mieć ograniczone działanie.
To tylko część elementów, a tworzenie tego typu umów jest trudne.
Witam,
rzeczywiście w standardowym modelu ustalony i zakontraktowany zostaje zakres funkcjonalności, który ma dostarczyć projekt. W podejściu zwinnym nie możemy tego zrobić, ponieważ zakres może się zmieniać. Tutaj dobrym rozwiązaniem jest kontrakt typu "time and materials", gdzie faktury są wystawiane na podstawie przepracowanych godzin przez zespół. Poniżej przedstawiam kilka propozycji rozwiązań:
1. Stopniowany kontrakt z ustaloną ceną
W takim kontrakcie stawka zmienia się w zależności od czasu wykonania projektu. Kontrakt zawiera standardową stawkę godzinową i przewidywaną datę ukończenia projektu. Jeżeli zespół zrealizuje projekt wcześniej - dostawca otrzymuje wyższą stawkę godzinową, a klient płaci łącznie mniej. W przypadku dłuższego czasu - odwrotnie.
2. Pakiety pracy o ustalonej cenie
W tym rozwiązaniu nie wyceniamy projektu całościowo, tylko dzielimy go na pewne zakresy, których koszt szacowany jest oddzielnie. Podział na pakiety i szacowanie następuje na początku projektu, a w miarę postępu prac koszty są szacowane ponownie, z większą dokładnością.
3. Money for nothing and Change for free
Podejście zaproponowane przez samego twórcę Scruma, Jeffa Shuterlanda. Podstawą takiego podjeścia jest ustalenie Rejestru Produktu, oszacowanie jaka liczba story pointów mieści się w tym Rejestrze i wycena każdego punktu. Jeżeli klient będzie chciał umieścić dodatkowe funkcjonalności - będzie musiał za nie dodatkowo zapłacić, zgodnie z tym, jaka jest wielkość tej funkcjonalności.
Change for free oznacza, że klient może dokonać zmiany funkcjonalności w Rejestrze Produktu, o ile funkcjonalność, którą dodaje ma taką samą lub bardzo podobną wielkość do funkcjonalności, którą usuwa.
Money for nothing ma być zabezpieczeniem dla dostawcy. Jeżeli klient zdecyduje się na wcześniejsze zakończenie projektu, oddaje część pozostałej kwoty kontraktu dostawcy, np. 20%.
Pozdrawiam,
UW
