Zanim w szczegółach o Gherkinie, to najpierw typowa rozmowa w trakcie refinmentu backloga:

[Spec z biznesu]: Słuchajcie, ta funkcjonalność wchodzi pod koniec kwartału. Chodzi o to, aby user mógł zmienić typ swojego konta na premium...

[Ktoś z dev]: Ale czy z każdego konta można przejść na premium?

[Spec z biznesu]: Yyy...poczekaj chwilę ...wtedy z jego salda pobieramy opłatę z upgrade...

[Spec z biznesu]: Co w przypadku zerowego salda? Też można upgradować?

Tu zatrzymajmy na chwilę tę ciekawą dyskusję, bo w głowie każdego z rozmówców pojawiły się pewne interesujące myśli. Przyjrzyjmy się im bliżej.

Co oni sobie myślą?

Spec z biznesu myśli: Łooo matko, znowu się czepiają....

Ktoś z dev myśli: Łooo matko, znowu płynie bez konkretu....

Dlaczego myślą w ten sposób?

Kluczowe przyczyny opisałem szczegółowo w artykule Programiści NIE maja problemu z komunikacją. Teraz zobaczymy, co z tego wynika dla opisanej sytuacji.

Statystycznemu Ktośowi z dev, gdy tylko usłyszy cokolwiek o nowej funkcjonalności, niemal automatycznie odpala się w głowie proces pt. jak ja zrobię?. No, bo przecież będzie robił, więc chce wiedzieć jak. Skutkiem powyższego w rozmowie jest uwrażliwiony na:

  • eksplorację przypadków szczególnych
  • scenariusze alternatywne
  • sytuacje wyjątkowe
  • transformacje przekształcające jedne informacje w drugie

Z drugiej strony reprezentatywny Spec z biznesu, ponieważ ma dowieźć daną rzecz na termin, również z automatu i bez żadnego przymusu skupiony jest na:

  • scenariuszu podstawowym
  • i w najbardziej pożądanym przypadku na:
    • potrzebach klientów
    • konwersji i zysku netto
    • ścieżkach krytycznych
  • a w najmniej pożądanym przypadku:
    • na dowiezieniu i zamknięciu projektu
    • swoim celu rocznym
    • całej masie innych spraw, które wrzucił mu jego dyrektor

No i jak mają się dogadać?

Krótki brief z Gherkin

Jakiś czas temu napisałem krótki tutorial po Gherkinie i w dalszej części wpisu zakładam, że go przeczytałeś :).

W gherkingowskiej nomenklaturze pierwsze oczekiwanie wyrażone na początku przez PO, wyglądałoby tak:

Feature: Upgrade to premium account

Scenario: Happy flow
Given a basic account
When upgrade was requested
Then user saw a payment form

Co się zmieniło?

Przeżyjmy jeszcze raz początkową rozmowę na refinemencie.

[Spec z biznesu]: Słuchajcie, ta funkcjonalność wchodzi pod koniec kwartału. Chodzi o upgrade konta. Coś w tym stylu:

Feature: Upgrade to premium account

Scenario: Happy flow
Given a basic account
When upgrade was requested
Then user saw a payment form

[Ktoś z dev]: Ale z każdego konta można przejść na premium?

[Spec z biznesu]: Yyy...poczekaj chwilę. Zapiszmy to, żeby nie uciekło.

Feature: Upgrade to premium account

Scenario: Happy flow for basic account

Scenario: Happy flow for free account

Scenario: Happy flow for intensive account

[Spec z biznesu]: Rzeczywiście typ konta ma znaczenie. To zacznijmy od konta basic, bo tych mamy najwięcej:

Feature: Upgrade to premium account
    
Scenario: Happy flow for basic account
Given a basic account
When upgrade was requested
Then user card is charged

Ktoś z dev]: A co w przypadku, gdy klient nie dodał karty?

[Spec z biznesu]: Mógłby dostać formularz płatności?

[Ktoś dev ]: Tylko, że to trzeba wydewelopować do początku. Obciążenie karty oraz PayPal mamy już gotowe.

[Spec z biznesu]: Dla mnie OK. Dajemy płatność tylko kartą albo PayPal. Zapiszmy to:

Feature: Upgrade to premium account
    
Scenario: Happy flow for basic account
Given a basic account
When upgrade was requested
Then user card is charged

Scenario: Flow for basic account - credit card is undefined
     ...

Gherkin porządkuje rozmowę

Gherkin każdej ze stron rozmowy daje możliwość wyrażenia swoich przemyśleń:

  • Specowi z biznesu pozwala sprecyzować pożądane zachowanie funkcjonalności
  • Co więcej, trudno jest napisać scenariusz do czegoś co jest zbyt duże i mało konkretne, zatem wymusza też podział funkcjonalności na mniejsze kawałki
  • Komuś z dev pozwala wyspecyfikować wątpliwości co do przypadków szczególnych i wrócić do nich później

Oczywistym benefitem są - jak najbardziej - możliwość automatyzowania scenariuszy, zewnętrzne biblioteki, które organizują i uruchamiają scenariusze. Ten temat jest już dobrze opisany w sieci, więc nie będę się powtarzał

Notka dla Kogoś z dev: Tutaj znajdziesz, jak w najprostszym przypadku i bez dodatkowych bibliotek, automatyzowany jest taki scenariusz.

Bardziej szczegółowa notatka dla Kogoś z dev]: Przeczytaj GOOS.

Uwaga! Uwaga!

Za chwilę będę ostrzegał przed poważnym błędem związanym z używaniem Gherkin, więc proszę o skupienie.

Już?

No to uwaga, ostrzegam:

Nie chodzi o to, żeby zapisać wymagania w formie given-when-then. Chodzi o to, aby IT z Biznesem spotkali się w jednym pokoju (fizycznym, czy wirtualnym) i zrobili given-when-then razem.

Wiedza i wymagania mieszkają w głowach ludzi. Natomiast Gherkin to tylko sposób ich zapisania. Jeden z wielu. Głównym problemem w trakcie wytwarzania oprogramowania nie jest sposób zapisu wymagań w formie scenariuszy Gherkin, use cases, diagramów czy innym. Głównym problemem jest określenie co właściwie należy wykonać.

Ww. problem rozwiązuje współpraca z klientem, jego dostępność i zaangażowanie. Wtedy Gherkin pomoże wam układać tę współpracę i przyniesie wiele korzyści. Jeśli zaczniesz korzystać z Gherkin bez Biznesu, to się zamęczysz, a scenariusze i tak będą "z czapy".

"A, bo to bedzie dużo pisania"

Tę kwestię szczegółowo omawiam w mojej książce Getting Things Programmed. Droga do efektywności w rodziale 4. - Wyodrębnianie zadań.

W skrócie: nie. Nie będzie dużo pisania. Podczas definiowania zadań do zorbienia (a scenariusze Gherkin są formą zadań do zrobienia) najtrudniejszą sprawą jest określenie i sprecyzowanie, co też należy zrobić. Samo zapisanie to już sprawa techniczna.

W przypadku Gherkina bedzie bardzo dużo myślenia, precyzowania, dyskusji i podejmowania decyzji. To należy do istoty twojej pracy. Samego pisania bedzie zdecydowanie mniej w porównaniu z nieuporządkowaną dokumentacją.

We wspomnianej wyżej książce znajdziesz praktyczne techniki, które pomogą ci definiować zadania zmierzające wsprost do celu.

Gherkin nie działa?

Najczęstszą przyczyną tego, że nie działa jest to, że scenariusze Given-When-Then tworzone są przede wszystkim przez IT. Jeśli tak jest to zaobserwujesz następujące objawy:

  • specyfikacje są, ale rozmijają się z tym, co Biznes oczekuje od funkcjonalności
  • w dodatku są bardzo szczegółowe
  • a także często skupiają się na interfejsie użytkownika
  • możliwość automatyzowania specyfikacji jest uznawana za ich największą zaletę
  • no i oczwiście macie testy automatyczne ;)

Tak już mamy, my ludkowie z IT, że jeżeli gdzieś można zrobić intelektualną rozkminę i pobawić się technologiami, to to robimy. Automatyzacja jest ważna, ale to nie ona jest głównym benefitem z Gherkin. Najważniejszymi korzyściami spisywania scenariuszy są:

  • podejmowanie decyzji o koształcie i działaniu funkcjonalności
  • specyfikowanie oczekiwań w jednoznaczy sposób
  • struktura scenariusza zrozumiała dla każdego
  • wczesne wykrywanie błędnych założeń biznesowych
  • wczesne wykrywanie naruszenia reguł biznesowych chronionych przez oprogramowanie
  • możliwość zaproponowania tańszego bądź łatwiejszego sposobu realizacji funkcjonalności

...a przy okazji można to zautomatyzować.

Te kluczowe korzyści osiągniesz gdy:

  • Pracujecie nad specyfikacjami Gherkin razem: Biznes i IT
  • "razem" oznacza: w tym samym momencie, kolaboratywnie :)
  • Specyfikacje są regularnie przeglądane i udoskonalane
  • Osoby z Biznesu oraz IT są osobiście i operacyjnie zaangażowanie w tworzenie i utrzymywanie specyfikacji

Jak to dla ciebie brzmi?

.