Wprowadzenie
O user story pisałem nie raz od ponad dekady, i w zasadzie zawsze powodem jest to samo: kolejny ratowany projekt, gdzie powodem dramatu było stosowanie user story jako wymagań. Kiedy user story jest stosowane jako wymaganie? W zasadzie zawsze tam, gdzie pominięto etap analizy i projektowania. Jakie są skutki? Kilkukrotnie wyższa pracochłonność, czyli znacznie wyższe koszty i dłuższy termin dostarczenia oprogramowania. Niestety, nie raz, tak realizowane projekty kończą się wstrzymaniem prac zanim powstanie pełna funkcjonalność aplikacji, z powodu znacznego przekroczenia budżetu i terminu.
Co proponuję? To co proponuję wielu doświadczonych praktyków na świecie:
User Story
W 2010 roku pisałem:
A co robią firmy programistyczne? Analityka i architekta się pomija jako zbędny koszt, zaś niewiedza zamawiającego gra na korzyść wykonawcy. Proponuję samemu sobie odpowiedzieć na pytanie jak prowadzić takie projekty i podyskutować nad potrzebą pracy analityka i architekta. Wyobraźcie sobie Państwu remont swojej łazienki (albo co gorsza budowę domku jednorodzinnego), który zlecacie od razu murarzom a to jak ma wyglądać efekt końcowy opisujecie murarzowi słownie, ten spisuje to prozą w umowie. Efekt zobaczycie dopiero po tym jak murarze skończą i zapłacicie im za roboczogodziny.
Source: User story – kłopoty – Jarosław Żeliński IT-Consulting
Jako autora user story wskazuje się Ronalda E Jeffries’a . Pisze on tak:
Samo wymaganie jest przekazywane od klienta do programistów poprzez rozmowę: wymianę myśli, opinii i odczuć. Ta rozmowa odbywa się w czasie, szczególnie gdy historyjka jest szacowana (zwykle podczas planowania wydania), i ponownie na spotkaniu planowania iteracji, gdy historyjka jest zaplanowana do wdrożenia. Rozmowa jest w dużej mierze słowna, ale może być uzupełniona o dokumenty. Najlepszymi uzupełnieniami są przykłady; najlepsze przykłady są wykonywalne, Przykłady te nazywamy potwierdzeniem.
Co do jakości i odpowiedzialności pisze on:
Historyjki użytkownika zapisywane są na kartkach. Karta nie zawiera wszystkich informacji, które składają się na wymaganie. Zamiast tego, karta ma tylko tyle tekstu, by zidentyfikować wymaganie i przypomnieć wszystkim, czym jest historia. Karta jest żetonem reprezentującym wymaganie. Jest używana podczas planowania. Notatki są na niej zapisywane, odzwierciedlając priorytet i koszt. Często jest wręczana programistom, gdy historia jest zaplanowana do wdrożenia, i oddawana klientowi, gdy historia jest ukończona.
Wniosek nasuwa sie jeden: 100% odpowiedzialności za uzyskany efekt spada na Zamawiającego, który jest autorem tych historyjek. Z Uwagi na bałagan i problemy z nimi, pojawiły sie szybko próby formalizacji treści tych “karteczek”:
Jako <rola> mogę <zdolność>, dzięki czemu <otrzymuję korzyść>
lub
Aby <otrzymać korzyść> jako <rola>, mogę <celować/chcieć>Gdzie jako prześmiewczy przykład takiej sformalizowanej historyjki nawet wiki (https://en.wikipedia.org/wiki/User_story) podaje:
Jako niezadowolony pracownik chcę wymazać bazę danych użytkowników, aby zaszkodzić firmie W sieci dość popularny jest żart na temat skutków stosowania user story jako wymagania do implementacji: (1) Jako kierowca chcę móc skręcać w lewo by dotrzeć do celu, (2) Jako kierowca chcę móc skręcać w prawo by dotrzeć do innego celu, (3) Jako kierowca chcę móc jechać prosto do dotrzeć do pewnego celu. W efekcie, w tygodniowych odstępach czasu, powstały – każdy osobnym kosztem – trzy moduły: do skrętu w prawo, w lewo i jazdy prosto. Jak się nie trudno domyśleć należało raczej nieco dłużej pomyśleć (etap pracy inżyniera) i opracować jeden moduł zmiany kierunku jazdy (kierownica).
Kilka lat po publikacji Ronalda E Jeffries’a podejmowane były nawet próby unaukowienia historyjek użytkownika:
Inny przykład:
Powyższe podejście jest wspierane przez niektóre narzędzia CASE, także Visual Paradigm. O tym jak takie podejście monstrualnie podnosi koszty projektu pisałem w artykule User Story i Story Mapping czyli jak podnieść koszty.
Niestety praktyka pokazuje, że poza sformalizowaniem pracochłonności dewelopera, powyższe w niczym nie poprawiło skuteczności tak pojmowanych user story (patrz np.: WHY USER STORIES FAIL at: https://www.romanpichler.com/blog/user-stories-failure/ Copyright ? Pichler Consulting).
Czy User Story są z gruntu złe?
Generalnie same user story jako takie nie są złe, bo użytkownik, jako nieprofesjonalista w branży inżynierii oprogramowania, nie jest w stanie inaczej opisać swoich potrzeb. Gdzie więc problem?
Otóż przyczyną problemów jest uznanie, że user story to wymaganie, wobec oprogramowania, które należy bezpośrednio zaimplementować.
A efektywne podejście polega na uznaniu, że:
User Story to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!
Pojmowanie user story w agile wg. opisu ich autora najczęściej prowadzi do implementowania problemów, a nie do ich rozwiązywania. Rozwiązywanie problemów to praca inżyniera. Implementacja tych rozwiązań to praca dewelopera (patrz artykuł: Software Engineer Vs. Programmer: What?s the Difference?):
Jak wygląda różnica? Implementowanie kolejnych user story jako odrębnych elementów kodu, prowadzi do sytuacji opisanej wyżej: do samochodu mającego odrębne moduły do skręcania w każdym kierunku i jazdy prosto. Tak powstaje monstrualny, kosztowny kod aplikacji.
Poniżej zilustrowano to zjawisko na przykładzie systemu dla biblioteki:
Mamy tu cztery user story: wypożyczenie, zwrot, weryfikacja statusu i naliczenie kary. Typowy proces agile zaowocuje czterema odrębnymi implementacjami. Biorąc pod uwagę fakt, że nadal znakomita liczba deweloperów stosuje architektury budowane na jednej, centralnej relacyjnej bazie danych, otrzymujemy efekt w postaci ogromnej ilości kodu w ośmiu częściach: cztery razy kod + zapytanie SQL do wielotablicowej bazy danych.
Jeżeli jednak “wstrzymamy się chwilę i pomyślimy” (praca inżyniera-projektanta) to możemy dojść do efektywnego rozwiązania:
- Projektujemy formularz Karta Wypożyczenia
- Na formularzu Karta Wypożyczenia dodajemy pole Data Zwrotu
- Bez żadnej dodatkowej pracy użytkownik może sprawdzić status książki: obecność daty zwrotu na Karcie Wypożyczenia (wyszukiwanie nie jest osobną funkcjonalnością!)
- Na formularzu Karta Wypożyczenia dodajemy pole Kara za przetrzymanie: ten formularz plus Regulamin Wypożyczeń zawierają wszystkie dane by naliczyć tę karę.
Jeżeli dodatkowo zrezygnujemy z monolitycznej relacyjnej bazy danych na rzecz repozytorium dokumentowego, to okaże się że aplikacja powstanie niemalże ośmiokrotnie mniejszym nakładem pracy i znacznie szybciej. Taka aplikacja będzie także znacznie tańsza w utrzymaniu i rozwoju. Detaliczny projekt aplikacji zarządzającej wypożyczeniami opisałem w artykule Biblioteka.
Aby zilustrować powyższy problem, poniżej struktura zapytania SQL do relacyjnej bazy danych mającej ok. 100 tabel (dla porównania typowy system ERP ma nawet 1500 relacyjnie powiązanych tabel). Takie pojedyncze zapytanie służy to “wydobycia” z tej bazy średnio złożonego dokumentu jakim jest np. Faktura czy paragon.
To dlatego ponad 20 lat temu opracowano (i są na rynku) nieSQLowe bazy danych zwane NoSQL, w tym dokumentowe systemy baz danych.
Podsumowanie
User Story, ale jako materiał uzupełniający regulaminy i dokumenty operacyjne, otrzymany od Zamawiającego oprogramowanie jest bardzo dobrym materiałem dla inżyniera, który zaprojektuje rozwiązanie (czyli mechanizm opisujący logikę działania aplikacji, patrz artykuł o ICONIX). User Story użyte jako kolejne implementowane potrzeby użytkownika prowadzi do znacznie większej pracochłonności, czyli znacznie większego kosztu całego rozwiązania.
Pamiętajmy więc, że:
User Story to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!
Poniższy diagram pokazuje efektywną ścieżkę projektowania:
Ciekawe są doświadczenia z projektów, w których na początku poświęcono czas na pełną analizę dziedzinową (pełny zakres wewnątrz tego co nazywamy “bounded context” w DDD). Otóż okazuje się kolejne zgłaszane potrzeby użytkowników to coraz mniej developmentu na rzecz odkryć “jako to zrobić w tym systemie”, co zobrazowano poniżej:
Zielona linia na powyższym diagramie to konsekwencja projektowania zorientowanego na pełny model dziedziny rozumiany jako mechanizm opisujący to co zawiera w sobie “bounded context” w DDD. W efekcie kolejne wymagane (zgłaszane) potrzeby coraz rzadziej wymagają prac deweloperskich a coraz częściej kończą sie “odkryciem” jak to zrobić lub szkoleniem. Dlatego projekty zorientowane na modelowanie (MBSE, MDD) są w dłuższej perspektywie znacznie efektywniejsze, mimo tego że tak zwane MVP (ang. Minimum Value Product, Produkt o minimalnej wartości, dostarczany jest nieco później) i nadal nie jest to dawny “wodospad” (waterfall) a iteracyjno-przyrostowe dostarczenia systemu.
Poniżej pokazano to na przykładzie młotka: pierwotnym wymaganiem było “wbijanie gwoździ”. Po przestudiowaniu materiałów ze stolarni zaprojektowano młotek ciesielski. Kolejne zgłaszane potrzeby (konteksty użycia młotka przez użytkownika) okazywały się kolejnym wyjaśnieniem lub prezentacją “jak to zrobić tym co mamy”, w efekcie nie były potrzebne żadne prace deweloperskie.
Jestem właśnie na etapie kończenia projektowania aplikacji wspierającej realizacje pewnego dużego programu lojalnościowego. Poprzednie podejście mojego klienta to zlecenie tego deweloperowi stosującemu zwinne metody, wieloletnie pasmo kosztownego grzebania i rozbudowywania aplikacji o kolejne “potrzeby”. W efekcie powstały ogromne ilości kodu i baza danych, której obecnie chyba już nikt rozumie (dostawca odmawia udziału w migracji danych do nowej aplikacji, brak dokumentacji powoduje, że help desk dostawcy od kilku miesięcy musi się kontaktować z byłym pracownikiem). Aplikacja formalnie nigdy nie została ukończona (przejście z etapu tworzenia do etapu utrzymania i rozwoju) i zapadła decyzja o jej porzuceniu i utworzeniu nowej ale już metodą jak wyżej.
Co ciekawe, zebrane spisane user story (“jako użytkownik chciałbym móc …..”) , pogrupowane na przypadki użycia (czyli przyporządkowane do pozycji w menu aplikacji) automatycznie utworzyły bardzo dobry podręcznik użytkownika.
Norma IEEE definiuje wymaganie jako:
Warunek lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia celu.
Więc raczej nie jest to “opadająca lista kontrahentów po naciśnięciu prawego klawisza myszy”….
Na zakończenie
Polecam dwa interesujące referaty:
Oraz:
Wykres z zieloną i czerwoną linią to są Pana obserwacje ?
To literatura na ten temat, zjawisko jakie opisałem (kolejne implementacje kolejnych user story), obserwacje z wielu audytowanych projektów, laboratoriów ze studentami i w części ten referat:
https://youtu.be/LtRWu9DErgU?si=ey1Cu1K1b2hcUL1B
Z artykułem jak najbardziej się zgadzam tylko zależy, o jakich problemach mówimy.
Z inżynieryjnego punktu widzenia lub podwykonawcy jak najbardziej zasadne zwłaszcza tego uczciwego, oraz z perspektywy Klienta dla dużych Systemów biznesowych , Zwłaszcza w biznesach, które już istnieją. Biznes już zarabia na siebie. Mamy model biznesowy, procesy już istnieją . Dla projektów gdzie Klient może nam zdefiniować procesy w jego domenie biznesowej. Może lepiej lub gorzej określić wymagania Biznesowe.
Ostatni wykres (czerwone – metody oparte na user Story, zielone DDD) świetnie obrazuje koncept artykułu i udowadnia linią przecięcia o kolejnych potrzebach użytkowników; Tu następuje dowód dot. Kosztów. Zgadzam się całkowicie; Z doświadczenia też wiem, że tak jest .
Z drugiej strony mamy Startupy (rozumiane jako pomysł innowacyjny (nie tylko technologicznie) , bez wyklarowanego modelu biznesowego, procesy dopiero powstają ,budżet jest np na rok a później jest 10% szans że będzię na następny rok ) ;
Moim zdaniem – W takim wypadku nie ma sensu robić obszernej analizy (nie mówie że w ogóle) – Naszym celem w startupach jest jak najszybsze zderzenie naszego pomysłu z rynkiem; Dlatego też tu mają zastosowanie metody zwinne i tu utożsamię z tym User Story ; Przykład z biblioteką – załózmy że robimy innowacyjny projekt np Kisiązki które możemy czytać/ale bardziej oglądać wygenerowane przez AI w Wirtualnej rzeczywistości. Nie wiemy, czy taki pomysł się w ogóle przyjmie na rynku;
Wtedy robimy tylko User story “ Wypożyczenie książki” Na początku pewnie przez długi czas klientów będzie od 0 do 5 także resztę procesów obsłużymy w excelu. Nie ma co tu projektować resztę rozwiązania. Po co projektować całe kompleksowe rozwiązanie z ujęciem innych User Story jak użycie ich może się nigdy nie wydarzyć; Robimy jeden user story i zamiast na analityka-projektanta wydajemy na marketing bo naszym celem jest szybkie market fit a nie robienie dobrego inżyniersko rozwiązania. Załóżmy pozytywny scenariusz; Startup się udaje ; Zarabiamy, albo ryzyko się zmniejsza to uzyskujemy kolejne finansowanie , robimy kolejne User Story, później kolejne i kolejne; działamy iteracyjnie; Ale nie iteracyjnie jak Scrum w zespołach developaerkich mówimy o iteracyjności biznesowej – czyt Agile;
W końcu uzyskujemy punkt krytyczny, że rzeczywiście koszt tworzenia nowych user story to dług techniczny, który męczy wszystkich od deweloperów po analityka i CEO; Wtedy robimy refaktoring i projektujemy rozwiązanie od nowa;
Tak – wszyscy inżynierowie mówią , “dlaczego to nie było na początku zaprojektowane” … ano dlatego , że nie wiedzieliśmy że dojdziemy w ogóle do takiego momentu;
W tym ujęciu na wspomnianym wykresie , moim zdaniem brakuje krzywej pokazującej ryzyko biznesowe kolejnych inwestycji, żeby dać pełen pogląd na sytuacje
Kolejno można by jeszcze dać rozwiązanie z zastosowaniem refaktoringu właśnie w miejscu przerywanej lini..
Moim zdaniem po refaktoringu czerwona linia pójdzie w dół i zetknie się z zieloną 🙂 Happy end 🙂
Kiedy wiemy, że nas biznes będzie działał dopiero wtedy należałoby przejść na podejście waterfall’owe i rozwijać oprogramowanie; zrobić refaktoring i zaprojektować jeszcze raz , ale nie na zasadzie myślę że tak to będzie działać (procesy biznesowe) tylko już mam doświadczenie (znam procesy core’owe) one zarabiają na siebie , teraz musimy taniej wypracowywać kolejne wydania , ulepszenia i funkcjonalności lub procesy budujące przewagę konkurencyjną;
Reasumując – Nie neguje artykułu , dodaję trochę inną perspektywę ;
“Z drugiej strony mamy Startupy (rozumiane jako pomysł innowacyjny (nie tylko technologicznie), bez wyklarowanego modelu biznesowego, procesy dopiero powstają ,budżet jest np na rok a później jest 10% szans że będzię na następny rok ) ;”
I to są zupełnie inne projekty. Zgadzam sie w pełni z tym, co Pan napisał.
Problem leży w tym, że deweloperzy (bardzo wielu), w projektach tworzenia oprogramowania dla KONKRETNEJ firmy oczekującej KONKRETNEGO efektu, stosują metody i wzorce mające sens w przypadku start-up’u, a stosowanie tych metod nie ma żadnego sensu w projektach dedykowanych aplikacji na określone potrzeby określonej firmy.
It seems that any software development without defining SDLC model for a given organisation will experience difficulties. User stories integrated into test requirements based on a proper requirements specifications should add value at any stage of software production.
Yes, I have described it in this article:
https://it-consulting.pl/2021/02/07/v-model/
“Study finds 268% higher failure rates for Agile software projects”
https://www.theregister.com/2024/06/05/agile_failure_rates/