Wokół metod zwinnych narasta wiele mitów, szczególnie tych o skuteczności w dużych projektach.  Dzisiaj kolejne kilka słów o popularnym narzędziu jakim jest tak zwane “user story” czyli historyjka użytkownika, o ich ewolucji i o tym, że mogą być przydatne i kiedy.

Co prawda, jako źródło informacji wolę dokumenty, ale bywa, że tym źródłem informacji są jednak użytkownicy, bo dotyczy to projektowania np. nowych portali biznesowych. Tu niestety nie ma ani ustaw z wzorami dokumentów ani “dotychczasowego papierowego obiegu dokumentów”.  Bardzo podobnie wyglądają start-up’y w obszarze operacyjnym. Podobnie wygląda analiza i projektowanie systemów wspierających obsługę klientów (CRM i podobne). Dlaczego? Bo tej sfery nie regulują ani przepisy ani żadne normy. Nie licząc elementów prawa cywilnego, są całkowicie uznaniowe.

User Story

Historyjki użytkownika, mają swój rodowód w EX (programowanie ekstremalne) i są z reguły definiowane tak:

In software development and product management, a user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function (źr. ang. wiki).

Scott Ambler pisze:

User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. ^?1?

Generalnie jest to opis w potocznym języku, ten – z uwagi na niejednoznaczność – jako wymaganie, stwarza problemy. Podejmowane są próby formalizowania tych historyjek. Pisze o tym autor bloga QAgile (podając przykłady, polecam cały artykuł):

W podejściu agile takim jak Scrum wymagania definiujemy na ogól w postaci User Story. Prosta forma, która ma adresować oczekiwania i potrzeby użytkowników często zespołom przysparza dużo problemów w implementacji.^?2?

Swego czasu ja także pisałem o efektach stosowania tej metody z zbytnią ufnością w jej skuteczność:

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”.[…]

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.^?3?

User story to opis z perspektywy użytkownika. Najlepszą chyba metaforą będzie tu znana anegdota z opisywaniem słonia:

Każdy z tych okrzyków to odrębne user story.

Wszelkie metody zakładające, że użytkownik wie czego chce i jest najlepszym źródłem “wymagań” bazują na zaufaniu dla tych opisów.

I tu wpadamy w efekt ?kręcenia filmu?. Najczęściej tak zwana analiza  wygląda tak, że pracownicy analizowanej firmy, w toku warsztatów lub wywiadów, opowiadają z jakimi to sytuacjami mają do czynienia, co robią, kiedy i jak, opisując konkretne przypadki z jakimi mieli do czynienia  i to, jak sobie z nimi poradzili. Do tego dochodzą przypadki, w których sobie słabo poradzili, przypadki tego jak sobie radzą z tym, że czegoś nie rozumieją, a to wszystko jest okraszone  sposobami pracy wynikającymi nie raz z niewiedzy, nieznajomości prawa czy wewnętrznych regulacji. Na domiar złego, nie raz można się spotkać z przypadkami, w których opowiadający o swojej pracy wplata elementy pozwalające mu na działania niepożądane takie jak upraszczanie  procedur lub wręcz łamanie prawa (np. swego czasu pewien urzędnik na moich oczach w trakcie warsztatów zgłosił jako wymaganie wobec systemu obiegu dokumentów, możliwość podpisania orzeczenia sędziego przeterminowanym podpisem elektronicznym!).^?4?

Historyjki użytkownika mają sens, jednak nie jako “kompletny opis wymagań na aplikację” (wczoraj usłyszałem, że w pewnej dużej instytucji zebrano już ok. tysiąca (!) takich historyjek i proces ten nadal trwa). Mają jednak sens jako “sample” do analizy. Przekazywanie takich historyjek bezpośrednio developerowi jest ogromnym ryzykiem. Dlaczego? Historyjka, nawet w sformalizowanej formie, niesie tylko subiektywne “spojrzenie z zewnątrz”, a programista zaczyna domyślać się i gdybać, niejednokrotnie przekraczając dozwolone granice:

…?jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT?, do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz ?algorytm? wyliczenia podatków. Jeżeli programista zaczyna ?lepiej wiedzieć? od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie ? jako developerowi ? robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach ?polegnie?.^?3?  

Bywa bardzo często, że programista bez żadnego oporu przyjmuje historyjkę: “ja jako sprzedawca, chcę umieścić na fakturze towar, którego nie ma jeszcze w magazynie, w celu zaliczenia sprzedaży w danym dniu” … (Komentarz zbędny…)

Czy to znaczy, że należy odejść całkowicie od tego narzędzia? Moim zdaniem nie. Wystarczy uznać , że “user story” to WYŁĄCZNIE opis z perspektywy użytkownika, swoiste “jedno spojrzenie z setek możliwych”.

Swego czasu opisałem taksonomię pojęć stosowanych w analizie wymagań:

U szczytu tej hierarchii mamy wymagania biznesowe. Są to w zasadzie owe historyjki użytkownika. To wyrażone językiem zamawiającego, oczekiwania w stosunku do oprogramowania. Rolą analityka jest takie przeanalizowanie i przetworzenie tych opisów, by doprowadzić do powstania sformalizowanego opisu (np. w postaci modeli UML: przypadki użycia, model dziedziny, ograniczenia, inne) czyli do postaci specyfikacji usług aplikacji i logiki (mechanizmu) działania tej aplikacji.

Kolekcjonowanie wymagań biznesowych w postaci np. user story, ma sens jako zbieranie “sampli”, przykładowych sytuacji. Na ich podstawie, w toku analizy, można tworzyć modele i testować te historyjki (stają się scenariuszami testowymi). Tu polecam między innymi blog i książki Scotta Amblera:

In this episode, Scott Ambler helps us to understand the power of using models and how to use models in an agile environment.^?5?

Wspominałem nie raz o nim i o jego książkach na tym blogu:

Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć? ^?6?

Ostatnio popularność zdobywa podejście sformalizowane do historyjek użytkownika, bazujące na koncepcji Scott’a Amblera (modelowanie) i Rona Jeffries’a, zwolennika porządkowania, nie tylko treści wywiadów ;). Tu posłużę się ilustracjami z artykułu na stronie Visual Paradigm.

User story is one of the most important tool for agile development. They are often used for identifying the features of a system under developed. User stories are well compatible with the other agile software development techniques and methods, such as scrum and extreme programming. […]

Concept of 3C’s

The 3C’s refer to the three critical aspects of good user stories. The concept was suggested by Ron Jeffries, the co-inventor of the user stories practice. Nowadays, when we talk about user stories, we usually are referring to the kind of user stories that are composed of these three aspects:
Card – User stories are written as cards. […]
Conversation – Requirements are found and re-fined through a continuous conversations between customers and development team throughout the whole software project. […]
Confirmation – or also known as Acceptance criteria of the user story. […]^?7?

W dużym skrócie: historyjki dzielimy na jednostkowe elementarne (niepodzielne) opisy w postaci “kart”, zawierających opis tego czego zamawiający oczekuje od aplikacji, zapis uwag (konwersacja) dotyczących kolejnych dyskusji z zamawiającym na temat danej historyjki to historia ustaleń, opis oczekiwanego uzyskanego efektu czynności opisanych w danej historyjce potwierdzenie uzyskania oczekiwanego efektu. Idąc zaś za wskazówkami Amblera, implementację poprzedzamy pracą nad koncepcją implementacji posługując się modelami na dość wysokim poziomie abstrakcji.

Karta historyjki to prosty zapis utrzymany w konwencji “ja jako <<aktor>>, chcę <<nazwa czynności>> w celu <<oczekiwany efekt>>. Osobiście w projektach dopuszczam bardziej “luźną” formę takiej historyjki, jednak pilnuje co do zasady, by dotyczyła wyłącznie jednego “uzyskanego efektu końcowego”.  Każda karta ma unikalne oznaczenie, jest bowiem używana jako jedno zadanie, w backlogu i  sprintach (kanban). W dokumentacji (wspomniane narzędzie VP) user story wygląda to tak:

Historyjki mają swój cykl życia i dobrą praktyką jest rejestrowanie wszelkich kolejnych uzgodnień w toku pracy:

Tak zapisujemy “słowotok” zamawiającego na temat jego wizji realizacji danej usługi aplikacyjnej.  Analogicznie zapisujemy opis oczekiwanego efektu końcowego:

Do tego momentu mamy “klasyczne” zwinne prowadzenie projektu z jego wadami opisanymi powyżej.

Wymagania powinny być “spójne, kompletne i niesprzeczne”

Jak to osiągnąć? Analityk zaczyna zbierać te historyjki i zaczyna składać z nich kompletny proces biznesowy. Stanowi on weryfikator, czy całość (zestaw takich historyjek) stanowi jakąś spójną, kompletną i niesprzeczną logikę biznesową w skali całej firmy. Zmorą projektów są wymagania odkrywane w toku wdrożenia, dlatego warto poświęcić czas na weryfikację pomysłu na całość systemu i zweryfikować spójność i kompletność tej całości z pomocą utworzenia modelu każdego całego procesu:

Warto modelować proces gdyż wtedy widać, że nie zawsze prawdą jest, że jedna (każda) historyjka jest odrębnym przypadkiem użycia. Przypadki użycia wyprowadza się z elementarnych aktywności jeden do jednego, co z uzasadnieniem opisywałem w artykule Transformacja…. Model procesu biznesowego daje kontekst, pozwala lepiej zrozumieć “sens” całości. Czy powyższy model procesu (notacja BPMN) z naniesionymi historyjkami, nie przypomina Wam wyników badania słonia? Tu słoń został przez analityka odkryty: to proces biznesowy (jego model w notacji BPMN). Przypadkami użycia będą elementarne aktywności w procesie. Więcej na temat zwinnego prowadzenia projektu z użyciem user story można znaleźć w tutorialu Agile handbook.

Na zakończenie…

We are called ?analysts? for a reason! We don?t merely hear stories and convert them into ?requirements?. Our integrated value lies in going above and beyond the story and expanding beyond engendering deliverables. We coalesce critical thinking and intellectual curiosity to transform stories into abstracts and to propose the needs as well as what the problem really is.^?1?

[2022-12-03] Niedawno znalazłem te prezentację, polecam:

___

1. 1.

   Alami A. Requirement Elicitation: Stories Are Not Requirements. Modern Analyst. https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5236/Requirement-Elicitation-Stories-Are-Not-Requirements.aspx. Accessed May 9, 2019.
2. 2.

   Kaczor K. Najczęstsze błędy popełniane przy pisaniu User Story. QAgile. https://www.qagile.pl/scrum/najczestsze-bledy-popelniane-pisaniu-user-story/. Accessed May 9, 2019.
3. 3.

   Żeliński J. User story czyli nic nie poprawić a może nawet bardziej skomplikować. IT-Consulting. https://it-consulting.pl//2013/09/11/user-story-czyli-nic-nie-poprawic-a-moze-bardziej-skomplikowac/. Accessed May 9, 2019.
4. 4.

   Żeliński J. Warsztaty analityczne ? czyli malowanie trawy. IT-Consulting. https://it-consulting.pl//2014/12/21/warsztaty-analityczne-czyli-malowanie-trawy/. Accessed May 9, 2019.
5. 5.

   Ambler S. MBA084: Agile Modeling with Scott Ambler. Mastering Business Analysis. . Accessed May 9, 2019.
6. 6.

   Żeliński J. Agile Modeling. Effective Practices for Modeling and Documentation. IT-Consulting. https://it-consulting.pl//2015/05/27/agile-modeling-effective-practices-for-modeling-and-documentation/. Accessed May 9, 2019.
7. 7.

   Visual-Paradigm. User Story. Visual_paradigm. https://www.visual-paradigm.com/learning/handbooks/agile-handbook/user-story.jsp. Accessed May 9, 2019.