Prawie trzy lata temu pisałem o wadach metod zbierania i dokumentowania wymagań w postaci wywiadów i pisania tak zwanych “user story”. Byli i zapewne nadal są obrońcy tej metody:
User story to świetne narzędzie do komunikacji pomiędzy użytkownikiem a analitykiem (architektem) (uwagi do treści artykułu: User story – kłopoty).
Niedawno po raz kolejny widziałem negatywne skutki tego podejścia, tym razem był to wdrażany i zakończony porażką (projekt przerwano) obieg dokumentów, nie tylko kosztowych, więc postanowiłem do tamtego artykułu dodać coś jeszcze: wymagania zbierano tu z w postaci “user story”.
User story to perspektywa użytkownika i to skażona jego ograniczoną wiedzą lub jej brakiem oraz ograniczonym doświadczeniem lub jego brakiem. Duże, zdobyte w jednym miejscu, doświadczenie pracownika, bez głębszej i szerszej analizy, też nie poprawia sytuacji, częściej ją jeszcze pogarsza (bo nikt nie podejmuje dyskusji z tym “dużym doświadczeniem”). Popatrzmy na poniższy rysunek:
Jak zapewne już Państwo wiedzą, jest to “model” geocentryczny układu słonecznego (na rysunku jedynie orbita jednej planety z tak zwanymi epicyklami), stworzony na bazie obserwacji z Ziemi. Złożoność tego co widzimy jako mieszkańcy tej planety to efekt tego, że obserwator stoi na ziemi czyli krążącego wokół Słońca obiektu. Innymi słowy, obserwator jest we wnętrzu tego co opisuje (analizuje) i widzi jedynie fragment tego co stara się opisać i zrozumieć.
Poniżej prawdziwy obraz układu słonecznego:
Jak widać, prawda jest znacznie prostsza, jednak by ją odkryć należy zupełnie inaczej podejść do analizy i opisu otaczającej nas rzeczywistości. Należy zrezygnować z użycia zapisu subiektywnych obserwacji jako finalnego opisu zjawiska, zapis taki może być testem teorii ale nie nią samą. Kopernikański model to efekt głębokiej i formalnej (prawa fizyki) analizy i badań. Model geocentryczny, znany w średniowieczu, to nic innego jak “user story”.
Podaję ten przykład, mam nadzieję, że obrazowy, gdyż moja praktyka pokazuje, że próby tworzenia oprogramowania bazujące na relacjach (życzeniach, wywiadach, burze mózgów, itp.) przeciętnego obecnego lub przyszłego użytkownika, to bazujące na dobrych chęciach i niestety na zupełnym braku zrozumienia kontekstu, projekty o złożoności sztucznie zwiększonej nie raz naście razy, niż faktyczna. Użytkownik z drobnych, statystycznych odstępstw (tylko takie zwracają jego uwagę) robi zasady, nie potrafi wychwycić nadrzędnych uogólnień i prawdziwych reguł.
Oprogramowanie powstające z użyciem zwinnych metod, tych bazujących na bieżącej obserwacji i częstych poprawkach, traktowaniu odosobnionych przypadków jako wymaganych scenariuszy, prowadzi do bardzo złożonych tworów, których złożoność nie raz przerasta projekt. Brak logiki takiego opisu powoduje, że powstałe systemy wymagają ręcznej pracy przy każdej zmianie zasad panujących w firmie.
Tu niestety muszę napisać jedną ważną rzecz: winę za to ponoszą często sponsorzy projektów gdyż po pierwsze dopuszczają do tego, po drugie, nie raz jako członkowie zarządów i dyrektorzy, nie dopuszczają do siebie myśli o uporządkowaniu organizacji jako pierwszym kroku projektu.
Typowym, często spotykanym przykładem, są popularne ostatnio wdrożenia elektronicznego obiegu dokumentów, w tym faktur kosztowych. W większości chyba firm, z powodów historycznych, niemalże każdy kierownik i dyrektor ma nieco inny próg kwotowy samodzielnej akceptacji poniesionego koszu. Zapisanie w postaci wymagań a potem implementacja, takiego stanu rzeczy, bywa koszmarem. Koszmar ten jest bardzo kosztowny z uwagi na swoją złożoność i brak ogólnych zasad. Powoduje to, że zamiast uzyskania automatyzacji i znacznego wzrostu efektywności uzyskuje się bardzo złożony i pracochłonny (kosztowny) system zamrażający zastany stan rzeczy. Jedyną korzyścią czasami bywa to, że z raportów wiemy: to na prawdę długo trwa. A to tylko jeden aspekt opisu organizacji i wymagań na oprogramowanie.
Nie twierdzę, że każdy projekt związany z analizą wymagań, należy prowadzić kosztownymi, formalnymi metodami, jednak zanim z tych metod zrezygnujemy oceńmy jakie ryzyko podejmujemy, bo często jest ono bardzo duże. Dlatego przed decyzją o tym czy i jakie oprogramowanie wdrożyć, warto zbadać firmę i upewnić się czy nie wymaga uporządkowania, komputeryzowanie bałaganu jest zawsze bardzo kosztowne i ryzykowne.
Warto tu zwrócić uwagę na ciekawy trend. Otóż opisane wady user story (rozumianego jako mniej lub bardziej swobodny opis użytkownika) dostrzegają nawet zwolennicy zwinnych metod i zaczynają je powoli formalizować, np. tak:
Jako [osoba odgrywająca daną rolę] chcę [wykonać jakąś czynność] aby [osiągnąć jakiś cel].
W ten sam sposób można pisać scenariusze przypadków użycia, przy których należy uwzględnić, że scenariusz może obejmować kilka user story. (Pisanie user story i scenariuszy przypadków użycia | Michał Wolski).
Wzorzec ten, co ciekawe, jest bliski definicji procesu biznesowego: czynność lub łańcuch czynności w celu osiągnięcia ustalonego rezultatu. Jest to jednak stanowczo za mało wiedzy. Powyższe podejście komentuje inny autor:
Przykładowe pojedyncze user story może brzmieć:
?Jako użytkownik premium kupując towary powyżej 1000zł ccę dostać rabat 10% do końca miesiąca tak aby zachęcić mnie do kolejnych zakupów.?
Taki zapis user story ma wiele zalet. Pozwala określić:
1.kto będzie używał danej funkcjonalności,
2.czego ten użytkownik będzie wymagał od systemu,
3.kontekst dla wymagania.
Powyższy zapis ma też jedną wadę. Jest dość długi, a lista wymagań przedstawionych w tej formie jest nieprzejrzysta. (Jak ugryźć user story | agile.pl).
Właśnie problem w tym, że jest nieprzejrzysta oraz nie wiemy jaka logika wiąże wartość towaru z wielkością rabatu, który może być jeden, może być elementem tabeli rabatowej, może być wyliczany wg. określonego wzoru, może… Takie zapisy, zakładając, że dłuższe user story to lepszy opis, zbliżają nas do próby zapisania wymagań na grę w szachy poprzez nakręcenie kamerą kilku partii. Mając dziesiątki takich user story nie mamy żadnego narzędzia pozwalającego sprawdzić ich spójność, niesprzeczność i kompletność. Idąc zaś krokiem formalizacji user story i porządkowania przypadków użycia, powyższy wzorzec “ja jako użytkownik zrobię to a to by osiągnąć to a to” szybko nas doprowadzi do definicji procesu biznesowego, który jest niczym innym jak właśnie pracą mającą określony cel. Po co więc odkrywać Amerykę i walczyć z niejednoznacznością skoro problem ten dawno rozwiązano: zamiast pisać user story wystarczy w toku analizy opracować modele procesów biznesowych i w ramach zakresu projektu transponować je na przypadki użycia.
Tak więc opisowe user story może być wymaganiem biznesowym, testem ale raczej nie specyfikacją tego co ma powstać. Bez analizy pozwalającej wyspecyfikować wymagania dziedzinowe (logikę wewnętrzną) nie mamy szans na sprawne stworzenie oprogramowania wykraczającego poza prosty zestaw kartotek i rejestrów.
… jako komentarz tylko jedno zdanie, a dokładnie stare przysłowie chińskie: “jeśli nie wespniesz się na górę, nie ujrzysz dali”.
User Story dobrze napisany z użyciem retoryki nastawionej na kroki biznesowe a nie na kliknięcia w buttony jest dobrą techniką dla systemów, w których logika jest “płytka” – w sensie: to co widzimy na ekranie jest zapisywane do bazy. Czyli tak zwane przeglądarki bazy danych, aplikacje klasy CRUD.
Natomiast gdy logika jest “głębsza” (UI jest proste, bo user ma nie mieć świadomości o tym co system robi “pod maską”) wówczas User Story jest po prostu słabe i wręcz mylące. O tak systemach zapewne piszesz w domyśle.
W DDD mamy na to sposób: nie User Stroy a Domain Story. Źródłem wiedzy nie jest User a Ekspert Domenowy.
Pojawia się jeszcze kwestia miękka: lepszą są bardziej abstrakcyjne UC czy poparte przykładowymi scenariuszami US? Z mojego doświadczenia: to zależy – od tego z kim rozmawiasz (w sensie jakie preferencje kognitywne ma Twój ekspert domenowy).
Dokładnie to obserwuję w projektach. Bardzo wiele firm i programistów, mających duże doświadczenie w tworzeniu nawet złożonych portali przenosi te praktyki na tworzenie systemów biznesowych o złożonej wewnętrznej logice a to się kompletnie nie sprawdza.
Klasyczny przykład “głębokiej” logiki i płytkiego UI to np. logika naliczania rabatów (ekran zamówienia bardzo prosty, logika naliczenia ceny sprzedaży złożona) czy system wspomagający zawieranie umów ubezpieczeniowych (płaski formularz ubezpieczonego i bardzo wyrafinowana logika oceny ryzyka i naliczania rezerw na wypłatę odszkodowania). W zasadzie wszystkie poważniejsze systemy biznesowe to znacznie więcej niż zwykłe przeglądarki danych czyli CRUD’y (po protu rejestry).
Gdyby porównać UI do wierzchołka góry lodowej, to DDD plus diagramy sekwencji to wszystko to co pod wodą i czego nie zawiera niestety znakomita większość znanych mi dokumentów wymagań. Często piszę o “wymaganiach dziedzinowych”, to właśnie ta podwodna część góry. Wspominałem o tym przy okazji artykułu o tym, że prototyp nie niesie żadnej informacji o logice.
Poruszyłeś w ostatnim akapicie bardzo ważną rzecz: umiejętności kognitywne eksperta dziedzinowego, a te niestety najczęściej są słabe (ale z reguły nie jest to oczekiwana kompetencja w biznesie). Dlatego od pewnego czasu (od niedawna) praktykuję (testuję ;)) etap pośredni pomiędzy modelami procesów i/lub przypadkami użycia a modelem domenowym DDD. Jest to mojego pomysłu model “brama-umiejętność-wiedza” albo jak kto woli gate-skill-knowledge 😉 (takie bardziej obiektowe BCE: boundary-controll-entity), przykład takiego diagramu tu: Struktura…).
Biznes nieoswojony z wzorcami technicznymi (a DDD raczej jest już wzorcem architektonicznym) znacznie łatwiej operuje pojęciami z jego obszaru doświadczenia czyli pojęciami “dostęp do działu, umiejętności ludzi i zapisana wiedza”. Na te trzy pojęcia rozłożę każdą działalność biznesową. Dopiero kolejny krok to przejście z tego modelu na przypadki użycia (umiejętności przyporządkowane aktorowi nie są implementowane w oprogramowaniu) a potem dopiero architekturę DDD. Korzyść jest taka, że prawie każdy ekspert domenowy bez problemu sprawdzi poprawność modelu trzypojęciowegoopisującego jego obszar biznesowy. Moje doświadczenie pokazuje, że jeżeli jeszcze dobrzy programiści bez problemu odbierają struktury DDD, tak biznes już niekoniecznie.
Jak słusznie zauważyłeś, efektem pracy analityka przede wszystkim i po pierwsze ma być zrozumienie zagadnień/problemów. Na tym etapie nie istotne jest to, co ma robić przyszłe narzędzie, ale przyczyny dla których podjęto decyzję o jego zamówieniu/wdrożeniu. Przesłanki te są z kolei osadzone w biznesie, czyli w procesach. Rzeczywiście (i potwierdza to moje doświadczenie, a szczególnie nieudane projekty), kiedy już zrozumiemy, wówczas możemy przystąpić do doprecyzowywania stosownych wamagań (rózne dokumenty – w zależności od stosownej metodyki). Co więcej, dopiero po fazie “zrozumienia” możemy być partnerami do dalszych rozmów i “drążenia tematów”.
Mam takie same doświadczenia i wnioski, a ludzie stale się upierają przy tych setkach wymagań na samym początku…:(
Jedna podstawowa zaleta w przypadku podejścia zwinnego jest taka, że właściwie zastosowane sprzyja ono interakcji i rozmowie pomiędzy Klientem, analitykiem, programistą, testerem i wszystkimi zainteresowanymi osobami, co z natury rzeczy było nieco pomijane w podejściu tradycyjnym. Co więcej, zwinność nie tylko sprzyja komunikacji, ale jej wymaga. I to jest najważniejsze w zwinnym podejściu do wymagań, jak i do całego projektu. To, czy technicznie wymagania będą zebrane w postaci dokładnego dokumentu, czy modelu, czy user stories, jest kwestią nieco wtórną, jeśli zabraknie komunikacji. Agile, to nie konieczne użycie US, czy innych technik, ale zwrot w kierunku komunikacji i jak najlepszym WSPÓLNYM zrozumieniu potrzeby, celu, ale też środków do jej/jego zaspokojenia/zrealizowania.
Samo istnienie nawet najlepszej komunikacji nie da nam wiedzy o tym jak rozwiązać problem klienta. Po drugie relacje pomiędzy np. lekarzem ma pacjentem nie polegają tylko na dobrej komunikacji a na tym, że lekarz potrafi postawić diagnozę przed podaniem leków a nie dopiero po (metoda prototypowania to nie raz zgon klienta) … To, że klient potrafi swoim językiem opisać swoje potrzeby nie znaczy, ze należy to brać za dobra monetę (słyszymy jednak że klient nie wie czego chce, klient zmienia wymagania co chwilę….). Nie tylko jest to moje znanie: praca polegająca na wsłuchiwaniu się w życzenia klienta i realizowanie to przerzucanie 100% odpowiedzialności za efekty pracy programistów na klienta (jaka rolę pełni tu developer poza biernym słuchaniem???), żaden normalny lekarz by tak nie postąpił…
Problemy pojawiają się gdy User Storie’s traktuje się jako wymagania. Pracowałem w takim projekcie dawno temu i aby kompensować niedostatki User Stories musiałem dopisywać do nich całą masę testów akceptacyjnych. Czyli uzupełniać User Storie’s o informacje potrzebne na temat działania danej funkcjonalności. Brakowało w tym projekcie wymagań czego skutkami byly poważne błędy wykrywane dopiero przez klienta.
Jest jednak jedna sytuacja kiedy User Stories się przydają i jest to wówczas bardzo dobre i naturalne podejście. Chodzi o sytuację kiedy nie zna się zagadniania, nad którym dopiero zaczyna się pracować i na rozgrzewkę przed modelowaniem funkcjonalności innym sposobem (np. use case’ami) trzeba pogłębić temat i dowiedzieć się więcej o celach użytkowników i danej domenie. Wówczas User Stories słóżą nam do zdobywania wiedzy. Natomiast nie można na tym poprzestać i traktować ich jako specyfikację wymagań.
To prawda, jednak problem w tym, ze user story to niestety “perspektywa użytkownika” z wadami w rodzaju “tak to postrzega” i “taki biznes chce ukręcić w tym wdrożeniu”. Wtedy powstaje oprogramowanie dla użytkownika a nie dla firmy co często nie jest tożsame ;).
Dlatego user story przydają się przy definiowaniu systemu, struktury i pewnych funkcji. Przy zrozumieniu funkcjonowania produktu. Natomiast przy wrzucaniu zadań do backlogu nie zawsze mają swoje zastosowanie. Najlepiej używać takich narzędzi, żeby realizować postawione sobie cele, niezależnie czy będzie to user story, czy jakikolwiek inny zapis.
User story są bardzo dobre jako testy odbiorcze ale jako wymagania już nie koniecznie (chyba, że uznamy testy za wymagania jak w TDD). Obawiam się, że opowieści taksówkarza o tym jak korzysta z samochodu nie przybliża nas do konstrukcji (samochodu) jaka ma powstać… Co do ostatniego zdania, co do metod zapisu: oprogramowanie na końcu poddawane jest kompilacji a to ściśle formalny etap (ścisłe interpretowanie kodu), im więc wcześniej zaczniemy formalizować zapis dokumentacji tym mniej błędów popełnimy..