Wstęp

Zostałem niedawno zapytany czy pomogę bo “mamy już ponad 150 przypadków użycia w dokumentacji…”. Myślę sobie, to niemożliwe, nie ma tak wielkich systemów (wycena okazała się w efekcie pięciokrotnie zawyżona tylko dlatego, że użyto metody zorientowanej na “user story”).

Tak więc user sto­ry nie wno­szą żad­nej war­to­ści do pro­jek­tu a kom­pli­ku­ją postrze­ga­nie zakre­su. Analiza i opra­co­wa­nie sfor­ma­li­zo­wa­ne­go mode­lu pro­ce­su będą zawsze prost­sze jako dia­gram. Specyfikacja apli­ka­cji opar­ta na for­mu­la­rzach i ich logi­ce jest znacz­nie wygod­niej­sza, bo zama­wia­ją­cy wie co dosta­nie, a deve­lo­per ma pre­cy­zyj­ną infor­ma­cję i nie ma moż­li­wo­ści zawy­ża­nia ceny. Pomijam, że user sto­ry to nie­ste­ty tyl­ko wyobra­że­nia zama­wia­ją­ce­go, któ­re potrak­to­wa­ne bez­kry­tycz­nie jako wyma­ga­nia, zaowo­cu­ją jedy­nie ??szyb­szy­mi koń­mi? a nie samochodem.

(źr.: User Story i Story Mapping czyli jak podnieść koszty)

Przypomniałem sobie także, jak prawie 10 lat temu, w pewnym projekcie, dotyczącym jedynie obiegu dokumentów w pewnej instytucji publicznej, dostałem dokumentację gdzie przypadków użycia było nieco ponad 400! Tu już nawet developer odmówił współpracy…

…Siedem lat temu pisałem:

Analizy biz­ne­so­we wyma­ga­ją ode­rwa­nia się od tech­no­kra­cji, nie ma cze­goś takie­go jak dzie­siąt­ki przy­pad­ków uży­cia dla jed­nej fak­tu­ry, nie ma sys­te­mo­wych przy­pad­ków uży­cia (nawet w spe­cy­fi­ka­cji UML ich nie znaj­dzie­cie), są kom­plet­ne (dają­ce jako efekt przy­dat­ne pro­duk­ty) usłu­gi apli­ka­cyj­ne i korzy­sta­ją­cy z tych usług akto­rzy, w tym inne apli­ka­cje lub kom­po­nen­ty. Dokumentacje zawie­ra­ją­ce set­ki przy­pad­ków uży­cia to nie­po­ro­zu­mie­nie, tech­no­kra­tycz­ni zabój­cy pro­jek­tów. Warto się zasta­no­wić zanim powie­rzy­cie ana­li­zę i pro­jekt logi­ki sys­te­mu tech­no­kra­tycz­ne­mu deve­lo­pe­ro­wi? (źr.: Wzorzec CRUD dla przypadków użycia i mikroserwisy).

Rok później:

Generalnie można podsumować to tak: metody wyceny bazujące na statystykach pochodzących ze zrealizowanych projektów są oparte na założeniu, że wyceniany projekt będzie realizowany tymi samymi lub analogicznymi metodami co samo z siebie jest zaprzeczeniem postępu technicznego i rozwoju metod inżynierii oprogramowania. Praktyka pokazuje, że wyceny tymi metodami są praktycznie prawie zawsze zawyżone a obszary nowatorskie mocno niedoszacowane lub przeszacowane (bo nowa funkcjonalność z zasady nie ma historii).

(źr.: Wymiarowanie oprogramowania)

Skąd sie biorą tak monstrualne listy “historyjek użytkownika” nazywanych potem “przypadkami użycia” i tak monstrualne wyceny na początku projektu? Dzisiaj o kolejnym wcieleniu powyższych metod: gherkin.

Gherkin

Nazwa wywodzi się z narzędzia Cucumber, to zaś oparte jest na, sięgającej końca lat 90-tych i wskrzeszonej niedawno jako “Ogórek”, idei Behaviour Driven Design (BDD)  (patrz np.: http://dannorth.net/introducing-bdd/). Na jednej z wielu stron poświęconej tej technice czytamy:

What is Gherkin? Gherkin is a language that developers use to define tests in Cucumber. Since this language uses plain English, it?s meant to describe use cases for a software system in a way that can be read and understood by almost anyone.This syntax promotes behavior-driven development because it allows developers, managers, business analysts and other parties involved to understand the requirements of the project and the life-cycle.The language makes it easy to create simple documentation of the code that?s being written.  Gherkin also provides scripts for test automation and supports dozens of languages. (źr.: What Is Gherkin + How Do You Write Gherkin Tests?)

[Co to jest Gherkin? Gherkin to język, którego programiści używają do definiowania testów w Cucumberze. Ponieważ język ten używa prostego angielskiego, jest on przeznaczony do opisywania przypadków użycia dla systemu oprogramowania w sposób, który może być odczytany i zrozumiany przez prawie każdego. Składnia ta promuje rozwój sterowany zachowaniem, ponieważ pozwala programistom, menedżerom, analitykom biznesowym i innym zaangażowanym stronom zrozumieć wymagania projektu i cyklu życia. Język ten ułatwia tworzenie prostej dokumentacji pisanego kodu.  Gherkin dostarcza również skrypty do automatyzacji testów i obsługuje dziesiątki języków.]

Przykład na stronie opisującej samą technikę:

Generalnie są to doprecyzowane “user story” oparte na szablonie:

• Nazwa funkcjonalności
• Kontekst
  • warunek początkowy
  • jeżeli (zajdzie)
  • to (efekt)

przykład 1 (źr.: https://support.smartbear.com/cucumberstudio/docs/bdd/write-gherkin-scenarios.html):

Ogólnie: (źr.: https://mvwi.co/posts/gherkin-cucumber):

Scenario: Some determinable business situation
  Given some precondition
    And some other precondition
  When some action by the actor
    And some other action
    And yet another action
  Then some testable outcome is achieved
    And something else we can check happens too

Całość bazuje na konkretnych zachowaniach użytkownika rozumianych jako jego “cel biznesowy” (a generalnie cel). Idea ta bazuje na założeniu, że każdy biznesowy kontekst (historyjka) to osobna funkcjonalność, wymagająca jej implementacji i napisania testu. Prowadzi to do efektu, w którym konstruowany w czasie samochód miałby np. trzy odrębne podzespoły: do skrętu w lewo, do skrętu w prawo, do jazdy prosto. Nie przypadkiem tak realizowane projekty mają ogromny nadmiar kodu, trudnego do zarządzania, jeżeli do tego dodamy “ubieranie” każdego elementu w mikroserwisy, będzie koszmar.

Przypadek Użycia w notacji UML

Kluczowa definicja w opisywanej metodzie brzmi:

A feature is a Use Case that describes a specific function of the software being tested. There are three parts to a Feature. [Cecha jest Przypadkiem Użycia, który opisuje konkretną funkcję testowanego oprogramowania.]

(źr.: https://en.wikipedia.org/wiki/Cucumber_(software))

Jest ona niezgodna z definicją przypadku użycia w UML. Notacja UML operuje pojęciem Przypadek Użycia (UC), definiowanym jako zachowanie się systemu, rozumiany jako usługa aplikacyjna (usługą aplikacji jest co do zasady np. generowanie poprawnej Faktury VAT a nie: “wstawianie numeru NIP z rozwijalnej listy podmiotów”). UC to “zestaw [kontekstowo powiązanych] zachowań mających określony cel. Po drugie UC nie reprezentuje (nie odnosi się do) konkretnych elementów wewnętrznej struktury (to nie jest model architektury systemu a opis systemu jako “czarnej skrzynki”): to abstrakcyjny model, umowa, WYMAGANIA wyrażone jako potrzeby. UC to dopiero materiał wejściowy na opracowanie implementacji (a wcześniej architektury czyli projektu systemu). Innymi słowy zawartość hipotetycznego głównego menu.

Powyżej fragment oryginalnej specyfikacji UML oraz ilustracja UC i możliwych kontekstów pracy aktora. Łatwo sobie wyobrazić, co będzie gdy pokazane po lewej konteksty (cele) aktora potraktujemy jako osobne elementy do implementacji. Każdy przypadek użycia może mieć kilka alternatywnych (kontekstowych) scenariuszy jednak realizowanych z użyciem określonej architektury jego implementacji (patrz także: Use Case 2.0 i Wzorce projektowe w analizie i projektowaniu modelu dziedziny).

Analiza i projektowanie

To trudna sztuka odkrycia istoty rzeczy (epistemologia). Wbrew pozorom nie da się tego procesu zalgorytmizować czy sprowadzić do listy kontrolnej. Uważam, że zrozumienie (odkrycie) mechanizmu działania (organizacji, ludzi) i opisanie go (modelowanie), jako wymagania wobec oprogramowania, to kluczowy cel analizy (odkrywanie) i projektowania (tworzenie). Co można tak uzyskać?

Poniżej praktycznie jedyna (poza ekranem konfiguracji) formatka ekranowa Google Calendar.

Zapewne każdy czytelnik, korzystający z tego, lub podobnego, kalendarza jest w stanie napisać dziesiątki “historyjek” o tym jak i po co używają kalendarza, czy one naprawdę wszystkie wymagają, każda, nowego kawałka kodu i testów? To jeden komponent obsługujący zawartość tej formatki, wraz z realizują usług takich jak np. wysyłanie monitów czy dublowanie wpisu w cudzym kalendarzu (dodaj uczestnika).

Tu można napisać: Planowanie zadania, Planowanie terminu, Określanie czasu zajęty/wolny, Dodanie gościa, Uprzedzanie (notyfikacja), Dodawanie opisu, ale też Sprawdzanie czasu wolnego. Każdy taki kontekst mogę opisać jako osobne “user story” (“korniszon”). Po co? To raczej wymagania biznesowe, potrzeby ale nie projekt architektury!

Nawet najbardziej rozbudowany sklep internetowy ma praktycznie tylko: ekran prezentacji oferty i zarazem wyszukiwania, ekran z opisem produktu (po jego wskazaniu), ekran z koszykiem i możliwością zapłaty oraz ekran profilu użytkownika: CZTERY USE CASY (usługi aplikacji). Wszystko to co możemy zrobić na tych stronach to nasze konteksty (historyjki, korniszony), i nie jest prawdą, że każde user story to musi być kolejny kawałek kodu do napisania i przetestowania. Każda księgarnia internetowa może mi posłużyć do sprawdzenia “kto napisał określoną książkę” czy “co napisał określony autor”, czyż nie? Czy to kolejne komponenty? Nie!

Podsumowanie

Obawiam się, że opisane “narzędzie” (metoda) to kolejne “lekarstwo” na brak analizy i zrozumienia logiki biznesowej. Problem w tym, że tak powstają monstrualnie nadmiarowe dokumenty i potem aplikacje… Audytorzy kodu aplikacji często stwierdzają, że taka aplikacja ma o rząd wielkości większą ilość kodu niż mogłaby mieć, a to oznacza także podobne relacje czasu i kosztu jej powstania. Jeżeli do tego dodamy próby napisania dla całej takiej aplikacji jednej bazy danych w modelu relacyjnym, to otrzymamy koszmar cyklicznej migracji danych na etapie prototypów a potem rozwoju z powodu ogromnego “pająka” czyli modelu jednej, współdzielonej bazy danych, a to klasyczny monolit a nie mikroserwisy.

Niestety nie jest prawdą, że tą metodą oprogramowanie powstaje szybciej, niż w wersji poprzedzonej analizą i projektowaniem. Prawdą jest zaś, że ta metoda nie raz przysporzy problemów z harmonogramem i budżetem.

Rok temu przeprowadziłem prezentację i potem napisałem artykuł: Inżynieria oprogramowania z użyciem narzędzia CASE ? przykładowy projekt. Celem było pokazanie jak to można robić inaczej.

Np. Wypożyczenie Książki, Zwrot Książki i ewentualne Naliczenie Kary za Przetrzymanie, to nie trzy User Story, to jedna Karta Wypożyczenia, mająca także pola: Data Zwrotu oraz Kara za Przetrzymanie. Jest to jeden Przypadek Użycia (Karty Wypożyczeń – jeden formularz) i różne konteksty pracy bibliotekarza z użyciem tej usługi aplikacyjnej. Dodać mogę jeszcze np. Sprawdzenie Dostępności Książki (czy jest Karta Wypożyczenia bez Daty Zwrotu) i wiele innych, podobnych “celów aktora”. Poprawna architektura to będzie jeden mikroserwis (micro aplikacja) zarządzający Kartami Wypożyczeń (jedno repozytorium tych kart). Artykuł ten zawiera także, dla porównania, link do rozwiązania powstałego jako efekt event stormingu, mający chyba wszystkie opisane tu wady.

Które z tych rozwiązań jest lepsze? To częste pytanie na moich szkoleniach. Poprawna odpowiedź: “księgowy prawdę Ci powie”, czyli łączny nakład pracy na powstanie, utrzymanie i rozwój systemu w ciągu 3-5 lat minimum. Innymi słowy liczy się koszt cyklu życia systemu. A skąd to wiemy” np. z dobrej praktyki Open Closed Principle (OCP), mówiącej że dobra architektura jest otwarta na rozszerzenia i zamknięta na zmiany, i raczej nie chodzi tu o dokładanie “a teraz moduł skrętu w prawo”, tylko o zrozumienie istoty rzeczy i zaprojektowanie raz, jednego modułu układu kierowniczego, potem można dodać układ hamowania (Chce Zmniejszyć Prędkość, Chcę Zatrzymać Samochód, Chcę Utrzymać Stałą Prędkość Jadąc z Górki).

Co obser­wu­ję na ryn­ku? Nie tak daw­no mia­łem w ręku wyce­nę pew­nej apli­ka­cji opra­co­wa­ną przez pew­ne­go deve­lo­pe­ra: naj­pierw ??sto­ry map? (ok. 60 user sto­ry!) potem wyce­na na ok. 300 tys. zł. pro­blem w tym, że apli­ka­cja (dosta­li pro­jekt ode mnie) mia­ła 6 (sześć!) for­mu­la­rzy po maks. 20 pól każ­dy, na moje pyta­nie skąd u nich tyle user sto­ry (bo w wyce­nie poda­li koszt za user sto­ry) nie ode­zwa­li się do do dzisiaj.

(źr.: User Story i Story Mapping czyli jak podnieść koszty)