Jest to typowy szablon historyjek (ang. user stories) stosowanych w scrumie. Historyjki tak zapisane pozwalają na szybką identyfikację trzech kluczowych elementów:
- [mark]roli[/mark], której potrzebę biznesową będziemy zaspokajać,
- [mark]funkcjonalność[/mark], która zostanie zaimplementowana,
- [mark]wartość biznesową[/mark], 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:
[quote align=”left”]As a user…
As a product owner…[/quote]
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.
No dobra, ale to nie wszystko. Ostatnio pisząc story staram się zastosować system oceny ich jakości. Do tego stosuję dość prosty mechanizm zaproponowany przez Billa Wake’a – kryteria INVEST. Aby story było poprawne (miało wysoką jakość) musi być:
- [mark]Independent[/mark] – niezależne od innych story, tak aby była możliwa jego samodzielna realizacja. Ma to na celu umożliwienie Product Ownerowi dowolnej zmiany kolejności dostarczania story. Dzięki temu na początku Backlog’a znajdą się story, które przyniosą największą wartość biznesową. Wystąpienie zależności może spowodować konieczność wcześniejszej implementacji story o bardzo niskiej wartości biznesowej przed implementacją właściwego story, co nie jest zbyt korzystne dla klienta.
Z własnego doświadczenia mogę powiedzieć, że jest to najtrudniejsze kryterium do spełnienia. - [mark]Negotiable[/mark] – negocjowalne. Należy pamiętać, że zespół scrumowy stanowią: Product Owner, Scrum Master i Zespół Deweloperski. Osoby pełniące te role powinny współpracować, tak aby dostarczyć maksymalną wartość biznesową klientowi. Zastanów się czy nie spotkałeś się z sytuacją, że w trakcie planowania zespół deweloperski przeglądał story przygotowane przez Produkt Owner’a. Następnie je estymował, ale nie prowadził rozmów na ich temat. Takie właśnie rozmowy – negocjacje mają za zadanie umożliwienie zdefiniowania dobrego story, które nie będzie skupiało się na detalach, ale uchwyci esencję problemu.
- [mark]Valuable[/mark] – powinno przynieść klientowi wartość. Początkowo możemy nie dostrzec wartości dla klienta, albo możemy doprowadzić do sytuacji w której to będziemy skupiać się na aspektach nie generujących wartości z punktu widzenia klienta. Przykładowo, tworząc nową aplikację można się spotkać z sytuacją, w której to najpierw stworzymy schemat bazy danych, potem warstwę dostępu do danych, warstwę pośrednią, itd. Interfejs graficzny pojawi się dopiero po zakończeniu wcześniejszych prac, które mogą zająć miesiąc, pół roku, rok… Przez ten czas klient będzie żył nadzieją, że w końcu kiedyś zobaczy zamówiony system i będzie on spełniał jego wymagania, które przez ten czas mogły się zmienić. A można zrobić to inaczej – przejść przez warstwy wertykalnie. Zbudować trochę bazy danych, trochę warstw pośrednich oraz trochę UI. Po każdorazowym ukończeniu story, klient będzie mógł podjąć decyzję o sposobie dalszego rozwoju aplikacji, jak również otrzyma możliwość wdrożenia ukończonego story na produkcję.
Czasem wystarczy tylko lekka zmiana sposobu definicji problemu, tak aby pokazać wartość biznesową. Ostatnio pisałem story, którego celem było dodanie nowego pola isEnable do bazy danych. Z jednej strony można to opisać językiem bardzo technicznym, z drugiej natomiast strony można przedstawić to jako wymaganie biznesowe: dział księgowy chciałby mieć możliwość ukrywania niepotrzebnych kategorii zamówień w aplikacji. - [mark]Estimable[/mark] – musi istnieć możliwość estymacji Wartość ta w połączeniu z wartością biznesową pozwala na ustalenie priorytetów wykonywania story. Może się tak zdarzyć, że story o największej wartości biznesowej nie zostaną wykonywane w pierwszej kolejności ponieważ ich wykonanie trwa zbyt długo.
Może zdarzyć się również taka sytuacja, że zespołowi nie uda się oszacować kosztu wykonania story. Wtedy takie story należy podzielić na kilka mniejszych i ponownie przystąpić do próby ich oszacowania. Jeśli to również nie pomoże i zespół w dalszym ciągu nie jest w stanie wyestymować story należy poświęcić trochę czasu na przeprowadzenie rozeznania tematu związanego z tym zadaniem. - [mark]Small[/mark] – odpowiednio małe story umożliwiają łatwe jego oszacowanie oraz zaplanowanie akcji związanych z jego realizacją. Małe story ułatwiają kontrolę jego wykonania, jak również trafność estymacji.
Nasuwa się pytanie, kiedy można uznać story za wystarczająco małe – ja uznaję, je za małe jeśli może zostać ono zrealizowane przez jedną osobę w przeciągu tygodnia. Jeśli czas ten jest większy należałoby to story podzielić na mniejsze. - [mark]Testable[/mark] – każde story powinno być testowalne. Co więcej zespół powinien zdefiniować testy jeszcze przed przystąpieniem do implementacji story. Wtedy stanowi to potwierdzenie poprawnego zdefiniowania i zrozumienia wymagań. Brak możliwości zdefiniowania testów świadczy o tym, że Product Owner nie do końca wie czego oczekuje od zespołu.
Jeśli chodzi o mnie, to w momencie rozpoczęcia pisania storiesów wyciągam listę tych kryteriów i staram się tak napisać story, aby wszystkie były spełnione. Największy problem mam z niezależnością. Czasami po prostu nie da się tego zachować. Na koniec proszę o sprawdzenie ich przez drugą osobę. Tak aby mieć pewność, że są one jasne i zrozumiałe.
Zostaw komentarz