Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
"Jeżeli nie potrafisz czegoś dobrze narysować, to znaczy że nadal tego nie rozumiesz…"
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.
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ć>
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:
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:
Tradycyjne metody prostej implementacji kolejnych user story z użyciem bazy relacyjnej vs. rozwiązanie problemu zarządzania wypożyczeniami z użyciem dokumentowego repozytorium.
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!
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”.…
Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agile requirements: the Quality User Story framework and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://doi.org/10.1007/978 – 3‑319 – 07881-6_15
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.
Widzę, że przeglądasz stronę. Zapraszam do dalszej lektury, tu zapoznasz się moim dorobkiem. Jeżeli szukasz usługodawcy zapraszam na STRONĘ Z OFERTĄ. Jeżeli szukasz wiedzy, zachęcam do dalszej lektury lub na SZKOLENIA i KONSULTACJE.