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.