Menu / szukaj

Win-Win w Scrumie – forma współpracy

Pojęcie win-win wywodzi się z teorii gier i opisuje takie rozstrzygnięcie gry, w którym obie strony odnoszą korzyść. Podejście to można wykorzystać w trakcie zawierania umowy, dotyczącej wytwarzania oprogramowania, kiedy to jedną stroną jest zespół Scrumowy. Z reguły podmioty zamawiające oprogramowanie oczekują podania estymacji kosztu wytworzenia aplikacji i na jej podstawie decydują o zawarciu umowy z danym dostawcą.

Podpisanie umowy tzw. time and material, w której to rozliczenie następuje na podstawie faktycznie przepracowanego czasu nie zawsze jest dobrze odbierane przez zamawiających. Zawsze można spróbować przekonać zamawiającego do zastosowania rozwiązania hybrydowego. W przypadku takiego rozwiązania zamawiający zobowiązuje pokryć koszty działania zespołu przez określony czas (np. rok), ale może również w każdym momencie zrezygnować z dalszej jego pracy. W takim przypadku zamawiający powinien zobowiązać się zapłacić część środków, które wynikałyby z dalszej realizacji kontraktu (np. 20% pozostałej należności). Czytaj dalej

As a [type of user], I want [some goal] so that [some reason] – jak napisać dobre user story. Kryterium INVEST

Jest to typowy szablon historyjek (ang. user stories) stosowanych w scrumie. Historyjki tak zapisane pozwalają na szybką identyfikację trzech kluczowych elementów:

  • roli, której potrzebę biznesową będziemy zaspokajać,
  • funkcjonalność, która zostanie zaimplementowana,
  • wartość biznesową, którą dostarczy implementacja.

Pisanie story nie jest jednak takie proste. I dosyć łatwo można popełnić błąd. Zastanówcie się jak często widzieliście story (pol. historyjki – chyba nie przekonam się do używania polskich nazw, brzmią one strasznie nienaturalnie…), które zaczynało się następująco:

As a user…

As a product owner…

Nie wyglądają one źle, ale na samym początku tracimy podstawową informację – o tym kto będzie używał naszej aplikacji. Przecież inaczej projektuje się interfejs dla kogoś obytego z technologią, a inaczej dla np. pani z księgowości.

Z reguły z definicją funkcjonalności, którą należy zaimplementować nie ma kłopotu. Brakuje natomiast zdefiniowania wartości biznesowej oraz kryteriów akceptacji. Można się zastanawiać, czy nie wystarczy nam sam środek – definicja funkcjonalności. W sumie na jej podstawie powinniśmy móc zaimplementować wymagany fragment oprogramowania.

Nic jednak mylnego. Dopiero połączenie tych trzech elementów umożliwia nam zrozumienie całego kontekstu problemu i zaproponowanie rozwiązania, które dostarczy wartość biznesową dla konkretnej roli. Kryteria akceptacyjne pozwolą nam natomiast w łatwy sposób sprawdzić czy zaproponowane rozwiązanie spełnia wymagania przed nimi stawiane. Czytaj dalej