Przykład jedynym źródłem prawdy

Są trzy najczęstsze oczekiwania od specyfikacji:

1. żeby była wystarczająco jednoznaczna i precyzyjna,
2. żeby wszystko ze wszystkiego wynikało, czyli traceability,
3. żeby deweloperzy chcieli ją czytać.

Tematowi nr (2) przyglądałem się 9 lat temu 😃 w artykule „żeby tak wszystko ze wszystkiego wynikało” i myślę, że jest wciąż aktualny.

Temat nr (3) zostawiam na nieco później, więc wychodzi na to, że teraz będzie o (1).

Placek na ścianie

Postanowiliśmy przenieść telewizor na inną ścianę - taki mały redesign. W tym celu zaprosiliśmy dziarską ekipę i przeprowadziliśmy z nimi następującą rozmowę:

-- Na tej ścianie w tym miejscu [tu podaliśmy współrzędne] ma wisieć telewizor. Kabel sieciowy oraz prąd proszę pociągną z tamtej puszki. Natomiast wokół telewizora [tu znów współrzędne] będą lamele. Lamele przyjadą w przyszłym tygodniu, więc prace możecie zacząć już teraz.

-- Dobra, a co to są lamele?

-- To takie wąskie deski.

-- Acha.

Panowie dziarsko przystąpili do pracy. Po kilku dniach zamieszania, zanim jeszcze przyjechały owe lamele, na ścianie pojawiło się coś takiego.

Pomyśleliśmy, że czas na na krótkie review z naszą ekipą.

-- Mam pytanie: dlaczego na ścianie został taki placek niepokryty gładzią?

-- No, bo tam mają być lamele.

-- A czy widzieliście jak wygląda lamel?

-- Nie, ale mówiłeś, że to wąska deska.

-- Hmm...lamel wygląda tak!

I tu wyciągam zza pleców kawałek lamela, który dostaliśmy jako próbnik.

W tym momencie kliknęło.

-- Aaa - mruknął majster - To nie jest wąska deska, tylko mała kantówka.

-- Acha.

Jak widzisz, nie prawdą jest, że "jak zwał tak zwał", bo to jednak ma znacznie "jak zwał". Najlepiej, żeby prócz "zwał", to jeszcze "pokazał".

Okazało się, że jednak lamel to "kantówka" a nie "deska" i należy przyklejać go co 3 cm. Zatem wyżej pokazany placek prześwitywałby z pomiędzy drewna.

Po wyjaśnieniu wszystkich wątpliwości i opatrzeniu ich stosownymi przykładami, efekt końcowy był następujący.

Przykład czy schemat?

Umiejętność abstrahowania, czyli budowania ogólnego schematu postępowania, który potrafi obsłużyć duży zbiór przypadków szczególnych, nie jest powszechną umiejętnością. Przeciętni klient, użytkownik, czy ekspert dziedzinowy - niewytrenowani w budowaniu abstrakcji - nie potrafią tego zrobić.

Żeby być precyzyjnym: najczęściej nie potrafią tego robić w sposób użyteczny dla budowy oprogramowania. Trzeba im w tym pomóc

Pracując z użytkownikami i ekspertami zaczynaj od zebrania konkretnych przykładów, sytuacji, które były ich udziałem. Dopiero na podstawie zebranych przykładów zbuduj abstrakcyjny schemat działania, który będzie podstawą do stworzenia funkcjonalności.

Dos & Don'ts

Użyj prawdziwych dokumentów

Zamiast pytać: Jak przebiega proces wystawiania zwolnienia chorobowego?
przygotuj razem z rozmówcą wyklejankę z dokumentów i wypytaj o warianty.

Spisz poszczególne przypadki działania reguł

Zamiast pytać: Jakie są reguły biznesowe związane z tym wymaganiem?
spisz konkretne przykłady działania tych reguł.

Poniży przykład pochodzi z opisu warsztatu Example Mapping na blogu gasparnagy.com.

Nadaj strukturę rozmowie

Zamiast swobodnej rozmowy nt działania funkcjonalności.
poprowadź konwersację według schematu, który nada wypowiadanym informacjom konkretną przyczynowo-skutkową strukturę. Takim schematem jest np. Gherkin.

Feature: Użytkownik portfela może zmienić limit wydatków
    Scenario Outline: Ustawianie limitów dla nowego portfela
        Given Porftel 
            And Porfel nie ma limitu wydatków w 
            And Wprowadzony został limit  w wysokości 
        When Limit wydatków zatwierdzony
        Then Limit  ustawiony na 

        Examples:
        | porfel    | waluta | limit |
        | 'Wspólny' |  PLN   | 1 000 |
        | 'Wspólny' |  USD   | 1 000 |
        | 'Wspólny' |  EUR   | 1 000 |

Ustal przykłady używanych pojęć

Deska czy kantówka? Dopóki pojęcia nie zostaną dookreślone, trudno osiągnąć zrozumienie. Tu istotny jest taki niuans, że nie chodzi o zdefiniowanie tych pojęć i zbudowanie słownika.

No, może spróbujmy:

deska - prosty, prostokątny kawałek drewna
kantówka - deska o grubości min 2cm

Słowniki pojęć to pożyteczne rozwiązanie i z pewnością pomogą, gdy ty i twój klient spotkacie się w sądzie jako strony sporu. Wtedy ekstremalna jednoznaczność definicji wskaże tego, kto płaci.

Słowniki i definicje pojęć są ważnym elementem dokumentacji, ale nie rozwiązują trudności komunikacyjnych w codziennych konwersacjach.

Zatem oprócz definiowania pojęć, podaj przykłady

To jest lamel

Chodzi tu o Ubiquitous Language. Różnica między słownikiem pojęć, a Ubiquitous Language jest następująca:

• słownik ma konotacje do czegoś statycznego, budujemy go, aby móc się do niego odwołać w razie potrzeby.
• UL uwypukla dynamikę współpracy, wskazuje, że wspólny język oraz pojęcia należy stale upowszechniać tak, aby stały się bazą do codziennej komunikacji.

Konkretny problem, konkretne rozwiązanie

Praktyka życia pokazuje, że ogólnie sformułowane problemy są nierozwiązywalne. Tak, matematycy potrafią to robić, ale w codzienności organizacyjnej nikt nie ma czasu, ochoty, ani umiejętności, aby sięgać po metody dowodzenia. Ręką w górę, który z deweloperów formalnie dowodzi poprawności swoich algorytmów...

Przeciętnemu użytkownikowi świata, Internetu i smarfonów łatwiej jest najpierw zająć się rozwiązywaniem małych, uproszczonych problemów, aby potem stopniowo komplikując, znaleźć ogólniejszą zasadę.

W tym pomocne jest posługiwanie się przykładami. Konkretne przykłady z codzienności pomagają w precyzyjnym sformułowanie małego problemu.

Przeczytaj więcej w artykule Dwie zasady skutecznego rozwiązywania problemów

To jest kosztowne i długotrwałe?

Policzmy na szybko:

Tak, spotkania są kosztowne, nie ma co się czarować.

Najczęściej podnosi się tu argument, że dobre przewarsztatowanie tematu skutkuje oszczędnością na fixach i utrzymaniu (btw: mierzysz to?).

Ja mam jeszcze dwa argumenty.

Spotkanie to też jest praca

Z jakiś powodów analiza i dewelopment to dwie różne rzeczy. Najczęściej na analizę nie ma kasy, bo przecież trzeba kodzić. Do złudzenia przypomina to zany felieton o bezsensownym, ale widocznym zapi**dolu.

Analiza jest częścią dewelopmentu i każdemu, kto twierdzi inaczej, warto zaproponować operację u chirurga, który wcześniej nie postawił diagnozy.

Przeważnie sprawy trzeba najpierw zrozumieć, dopiero potem robić. Rzadko kiedy jest odwrotnie (choć bywa 😃

To nie jest czasochłonne

-- ...a bo ten warsztat jest długi
-- ...a bo tych karteczek jest dużo
-- ...a bo trzeba tyle pisać
-- ...a bo to wszystko jest takie czasochłonne

Pisanie, karteczkowanie, czy prototypowanie nie jest czasochłonne. Co innego jest.

Czasochłonne i pracochłonne są:

• odnajdywanie powodów, dla których chcesz tej, czy innej funkcjonalności,
• konkretyzowanie informacji,
• precyzowanie o co ci tak na prawdę chodzi,
• podejmowanie decyzji,
• uzgadnianie różnych stanowisk,
• uzgadnianie pojęć,
• "układanie w głowie" informacji, czyli dowiadywanie się, uczenie i produkowanie wiedzy.

Na powyższych sprawach utykają warsztaty, powyższe sprawy konsumują dużo czasu. Samo spisywanie scenariuszy, czy wyklejanie kartek jest bardzo szybkie.

Możesz się łatwo o tym przekonać spisując np. scenariusze do funkcjonalności, które niedawno robiłeś. Pójdzie szybko, bo masz już wszystko ułożone w głowie. To właśnie proces owego układania jest najbardziej kosztowny, gdyż wiąże się on z wydobywaniem konkretu z chmury przemyśleń, odczuć i przypuszczeń. Karteczki, scenariusze i stormingi to tylko narzędzia i same w sobie kosztują niewiele.

Ostatecznie różnica jest mniej więcej tak: