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 jest przyczyną?
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!
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.
Na zakończenie polecam interesujący referat na podobny temat: