Friday, August 23, 2013

Conversation Patterns: Słowa są ważne w User Stories

This article is part of my work on Conversation Patterns for Software Professionals


Wprowadzenie, którego nie trzeba czytać :)

Minął prawie rok od chwili wydania Oprogramowania szytego na miarę.... Prowadziłem sporo warsztatów w oparciu o tę książkę i mailowałem z czytelnikami. Z zadawanych pytań wnioskuję, że nie jest do końca jasne, w jaki sposób stosować techniki zadawania pytań w szczegółowych kontekstach. Opisane sposoby prowadzenia rozmowy z klientem są często widziane w izolacji od "reszty świata".

Rozmawiamy sobie, zadajemy pytania, konkretyzujemy, ale co dalej? My przecież posługujemy się: user stories, taskami, use cases, bounded contexts, architekturą itd. Jak to skleić z technikami zadawania pytań? Przecież w tych wszystkich wymienionych obszarach zadawanie pytań, konkretyzowanie, definiowanie problemu ma swoje zastosowanie. Albo inaczej: user stories, taski, use cases, bounded contexts, architekturą są efektem zadawania pytań. A zatem pytanie brzmi: jak zadawać pytania, aby otrzymać: USs, UCs, tasks, BCs, zdekomponowaną architekturę?

Tę umiejętność zadawania pytań prowadzących do w/w artefaktów nazywam conversation patterns. Termin ten ukuliśmy podczas iDDD Tour w Krakowie, kiedy Vaughn Vernon dał nam parę minut na przedstawienie paru spostrzeżeń nt. wyodrębniania modelu dziedzinowego podczas rozmowy z ekspertem. Tak powstała krótka prezentacja Conversation Patters for Ubiquitous Language (jeśli nie było Cię na iDDD Tour, musisz użyć wyobraźni, aby złapać o co chodzi:)).

Tyle tytułem wstępu. Zacznijmy od User Stories.

Literalne stosowanie szablonu

Krótki przegląd przez historię rozwoju US możesz przeczytać na stronie Scotta Amblera. W każdym razie popularną obecnie ich formą jest As a...I want...so that....
Ten bardzo sprytny schemat formułowania US ułatwia ekspertowi formułowanie myśli i oczekiwań. Jest bardzo prosty, lecz pod tą prostotą kryje się mnóstwo niuansów, bez zrozumienia których, powstają karykatury US. Zobaczmy do czego może doprowadzić literalne stosowanie tego szablonu:
  1. Jako Użytkownik chcę się zalogować, aby się zalogować :)
  2. Jako Użytkownik chcę się zalogować, aby skorzystać z systemu
  3. Jako Użytkownik chcę kliknąć prawym przyciskiem myszy i zobaczyć menu kontekstowe po to, aby wybrać interesującą mnie opcję
  4. Jako Likwidator chcę zwiększyć rezerwę szkodową, aby postępować zgodnie z wewnętrzną procedurą T-1000
  5. Jako PO chcę dodać pracownika do bazy, aby mieć go w systemie
Kilka słów komentarza. (1,2) słabują jeśli chodzi o precyzyjne sformułowanie korzyści (frazy po so that...). Czy korzyścią dla użytkownika jest to, że się zaloguje? Wątpliwe. Że skorzysta z sytemu? Być może, ale możliwe, że użytkownikowi chodzi o to, aby dostać się do swojego konta?

Jeśli chodzi o (3) również jest kłopot z korzyścią. Jasne, że wybranie interesującej opcji ma sens, jeśli mówimy o tworzeniu menadżera okien, albo biblioteki GUI, lecz a aplikacji biznesowej wybranie interesującej opcji nie jest korzyścią lecz specyfikacją interfejsu użytkownika.

W (4) jest lepiej. Czy postępowanie zgodnie z procedurą T-1000 sprawi, że dzięki oprogramowaniu będziemy mogli odnosić więcej korzyści? pozyskać więcej klientów? zarabiać więcej pieniędzy? Bez szerszego kontekstu trudno jednoznacznie stwierdzić. Brzmi dobrze.

Nieco inaczej jest w (5). To, że PO wypowiada US, nie oznacza, że to on chce danej funkcjonalności, i że on odniesie z niej korzyść. Oczywiście warto używać US do opisywania potrzeb interesariuszy (brzydkie słowo:)) -@see Stakeholder Stories, lecz w tym przypadku rola nie została właściwie dopasowana do potrzeby i korzyści. PO może chcieć np. ładniejszy layout, poprawę bezpieczeństwa. Funkcjonalności raczej rzadko.

Słowa są ważne w US [@see rozdział: Co to znaczy myśleć biznesowo?]
Tak naprawdę US nie jest niczym innym niż parafrazą [@see Technika parafrazy] tego, co ekspert powiedział, spisaną w ustandaryzowany sposób. Posługując się strukturą rozmowy [@see rozdział Sztuka zadawania pytań], formułujesz pojedyncze wypowiedzi rozmówcy w jak najbardziej konkretny sposób.
Tak jak sugeruje tytuł posta i akapitu, słowa których używasz w spisywaniu US mają znaczenie. Zerknij na rysunek. To, co mówi Twój ekspert możesz zapisać co najmniej z użyciem słownictwa trojakiego rodzaju:

Biznesowego - słowa pochodzą z dziedziny biznesowej np.: Jako Klient chcę obejrzeć możliwe do założenia lokaty, aby wybrać najodpowiedniejszą do moich potrzeb
Rozwiązań - słowa dotyczą konkretnych rozwiązań i sugerują j a k coś ma działać, np.:Jako Klient, chcę wejść na zakładkę możliwych do złożenia lokat, aby zaznaczyć najodpowiedniejszą do moich potrzeb.
Technikaliów - słowa pochodzą z żargonu technicznego np.: Jako Klient, chcę wyświetlić listbox ofert, aby najlepszą dodać do mojego rachunku.

Oczywiście to tylko typologia. Więc Twoje parafrazy tego, co mówi rozmówca, mogą miksować słownictwo różnego rodzaju. W tym miejscu chcę Ci zasugerować, abyś używał przede wszystkim słownictwa bizensowego. Dlaczego?

Powód 1. Tak jak na rysunku między tymi grupami słów występuje relacja podrzędności. Najwyżej umieszczony jest biznes, najniżej technikalia. Zmiany również przebiegają z góry na dół. Daną potrzebę biznesową można zrealizować na kilka sposobów, które mogą się zmieniać. Jeśli więc klient stwierdzi, że woli nowe strony zamiast zakładek, to spowoduje to dużo zmian w wymaganiach. Jeśli będziesz trzymać się słownictwa biznesowego, to zmiany w konkretnych rozwiązaniach nie będą aż tak bolesne.

Powód 2. To zespół jest odpowiedzialny za proponowanie klientowi rozwiązań i za znalezienie najlepszego. Klient jest odpowiedzialny za swoje potrzeby. Pamiętaj: User Stories są efektem konwersacji.

Powód 3. Używając żargonu technicznego kastrujesz domenę. Gubisz ważne pojęcia biznesowe, reguły za nimi stojące. Jest duża szansa, że stworzysz architekturę nieadekwatną do wymagań (@see Jak zniszczyć swój kod?).

Zatem celem jest to, aby wejść na poziom biznesu, z jego perspektywy sformułować US i używając swojego doświadczenia technicznego, zaproponować konkretne rozwiązania.

5 comments:

  1. US jeżeli *dobrze* opracowane są silną techniką, ale sprawdzają się tylko dla systemów (modułów systemów), które charakteryzują się "płytką" logiką.

    Płytką w sensie: model mentalny, który user ma w głowie jest mniej więcej tym, co system robi "pod maską". Przykładowo wszelkie CRUDy.

    Jeżeli natomiast "pod maską" system robi coś, czegoś User sobie nie uświadamia (bo nie powinien), to technika US będzie wręcz szkodliwa. Co wówczas? Domain Scenario.

    ReplyDelete
  2. Nie wiem jak wąsko/szeroko rozumiesz US. Ja rozumiem je tak, że USs same w sobie są Feture-centric, a nie Model-centric albo lepiej Need-centric :). "User" definiuje co chce, a propozycja rozwiązań należy do zespołu. Jasne jeżeli skupisz się na "jak chcę kliknąć i zobaczyć..." to tak, będą kłopoty.
    Ale jeśli tak poprowadzisz rozmowę, aby rozmówca definiował jakiego rodzaju ZADANIA chce wykonywać w systemie, to potem w trakcie KONWERSACJI (być może wspomaganej definiowaniem given/when/then również na poziomie biznesowym) zespół odkrywa model. Racja, że jest to czynność nieustrukturyzowana przez US.

    "Jeżeli natomiast "pod maską" system robi coś, czegoś User sobie nie uświadamia (bo nie powinien), to technika US będzie wręcz szkodliwa. Co wówczas? Domain Scenario."

    Chyba kłopotem jest ten "User". Jeśli domena jest skomplikowana to potrzeba eksperta dziedzinowego:). Idea jest ok, ale:

    * może brakować eksperta dziedzinowego - prace zleca ktoś, kto sprzedaje, ale jak działa ten biznes, tak naprawdę wymyślają programiści

    * ekspert mówi: "zróbcie tak jak w ...."

    * system jest na tyle rozległy, że jest wielu ekspertów, ale każdy jest ekspertem w swoim kawałku i brak całościowej koncepcji

    Technika jak technika kluczem i tak pozostanie wydobycie z rozmówcy potrzebnych informacji i oddzielenie ziarna od plew.

    Możesz podać przykłady Domain Scenarios?

    ReplyDelete
  3. :)
    Widuje się US brzmiące "jak chcę kliknąć i zobaczyć..." ale przemilczmy to tutaj;)

    Weźmy taki prosty przykład:

    Mamy jakiś komponent (serwis) obsługujący zamówienia. Ostatnim krokiem jest zatwierdzenie zamówienia, które rządzi się taką przykładową procedurą:

    public void confirm(orderNr){
    1. przeliczenie rabatów
    2. sprawdzenie czy ceny sie nie zmieniły
    3. pobranie należności
    4. zamkniecie zamowienia
    5. wystawienie faktury
    6. zdjecie z magazynu towaru
    7. powiadomienie moduły wysyłki aby zaczęli dogadaywać transport
    8. wypłata prowizji handlowcom
    }


    Na poziomie kodziku kroki będą jeden pod drugim lub zintegrujemy moduły przy pomocy np zdarzeń. Ale triki pytanie: ile z tych kroków znajdziemy w US? Czyli ile z nich "obchodzi" usera pod tytułem klient?

    Zaczyna się pojawiać zatem dziwny user: Jako System chcę zdjąć z magazynu gdy klient zatwierdza zamówienie.

    Drugi problem: im więcej rzeczy dzieje się "pod maską" tym więcej możliwych *istotnych* kombinacji do ogarnięcia w scenariuszch:P

    Np na szkoleniu DDD zaczynamy zawsze od US aby nauczyć się, żeby już więcej tak nie robić i zacząć od domeny:P

    Ale tak jak piszesz: brak eksperta jest blokerem. Co do dużej ilości ekspertów, bo po prostu dzielimy na Bounded Context.

    ReplyDelete
  4. Ok, jestem zaciekawiony. Widzę to trochę jako kontynuację rozmów z iDDD.

    "Co do dużej ilości ekspertów, bo po prostu dzielimy na Bounded Context"

    Ach te proste rozwiązania, DDD instant:) Taki case. System istnieje od jakiś 15 lat pisany w czymś co ideowo przypomina Formsy. Jest podzielony na domeny, lecz słowo domena to wypadkowa: kawałka biznesu, funkcjonalności, stanowiska pracy i podziału na moduły techniczne. Każdą "domeną" zajmuje się ekspert domenowy. Co należy zrobić to wiadomo. Problem tkwi w "JAK?".
    No, bo:
    * przede wszystkim trzeba rozplątać to, co jest zmiksowane razem
    * UL wypracowany tylko w połowie, bo każdy z zainteresowanych ma nieco inne myślenie o produkcie
    * podział na domeny wiązałby się z tym, że eksperci musieli być "poprzesuwać" nieco zakresy swojej eksperckości, bo tak jak wspomniałem słowo "domena" było niegdyś zrozumiane inaczej; co w konsekwencji skutkowałoby koniecznością reorganizacji firmy i kluczowych procesów
    * trzeba utrzymać SLA:)

    Więc, podział na subdomeny, BCs ok. Sęk tym, że jeśli w pierwszej kolejności nie uporządkujemy myślenia o systemie i nie będzie "porządku" w głowach ekspertów, to nigdy nie będzie porządku w architekturze. Dlatego interesują mnie jak działają owe Domain Scenarios, o których wspomniałeś.

    ReplyDelete
  5. Wracają do meritum, czyli US:

    Nie znam głębszego kontekstu, ale słowo klucz "Formsy" może sugerować, że pomiędzy GUI i bazą nie ma szczególnie "głębokiej" logiki - w sensie: widzę coś na ekranie, chcę to przeedytować i zapisać (plus co jakiś czas monstrualna procedurka w sql;).

    Wówczas US jest pewnie najlepszym podejście.

    Nawiązując do pytania o Bounded Context.
    Jeżeli jest tak jak piszesz, to US nie pomoże. Bajzel to bajzel i jeżeli organizacja go nie ogarnie, to żaden system informatyczny tego nie naprawi. To tak jak w rolnictwie: na kupie oborniku nic nie wyrośnie, obornik musi zostać starannie rozprowadzony:P

    ReplyDelete