User Stories: Ujęcie krytyczne
Autorzy tekstu: Tom & Kai Gilb
Wolny przekład: Agata Magdalena Nowak
Od tłumacza:
W przeglądzie sześciu popularnych mitów dotyczących User Stories, Tom i Kai Gilb wyjaśniają nam możliwe komunikacyjne przyczyny niepowodzeń projektów, w których poza uproszczonym formatem User Stories, nie funkcjonują żadne bardziej zaawansowane formy specyfikacji wymagań oraz ich ewaluacji.
Tom Gilb wraz z synem Kaiem od kilkudziesięciu lat nauczają jak w zrozumiały sposób komunikować i formułować wymagania oraz zarządzać projektami informatycznymi w dynamicznym środowisku, przy wykorzystaniu zwinnego podejścia do wytwarzania oprogramowania (Agile). Ich metody pracy, zestawy narzędzi i dobrych praktyk stanowią inspirację dla największych firm w branży technologicznej oraz są z sukcesami wdrażane m.in. w projektach rządowych i społecznych.
Inżynierska filozofia Toma Gilba oferuje zestawy zasad, dzięki którym prowadzone przez nas projekty, szczególnie te o wysokim poziomie złożoności, będą przynosić z każdą iteracją wartość kluczowym zainteresowanym. Przyswojenie jej założeń wymaga czasu, a zastosowanie wszystkich zasad, może wydawać się początkowo zupełnie niemożliwe. Nie jest to wiedza łatwa, wymaga czasu, a często znacznej zmiany sposobu naszego dotychczasowego działania i myślenia. Jednak, małymi krokami, stosując jej poszczególne elementy, można szybko osiągnąć zamierzone efekty. Podejście i warsztat inżynierski, opisane w ogromnej ilości powszechnie dostępnych książek i artykułów, okazuje się głęboką wiedzą uniwersalną, pomagającą nam komunikować się ze światem.
Niniejszy artykuł przedstawia dostrzegane przez autorów mankamenty wykorzystywania popularnego formatu opisu wymagań dla projektów informatycznych – User Stories – czyli tzw. historyjek użytkownika.
Prezentowane przez Toma i Kaia Gilba stanowisko krytyczne podkreśla ryzyko jakie niesie ze sobą nieścisłość w komunikacji i dowolność w interpretacjach wymagań przez różnorodnych interesariuszy projektu. W tekście autorzy rozliczają się powszechnymi przekonaniami dotyczącymi użyteczności User Stories – mitami, które swoją popularnością mogą odwracać uwagę od faktycznej skuteczności metody przy braku formalnie spisanych wymagań.
W tekście użyto poniższych pojęć:
- specyfikacja (ang. Specification) (zobacz źródło)
- user story (zobacz źródło)
- poziom aspiracji (ang. Ambition Level ) (zobacz źródło)
- cel (ang. Goal)(zobacz źródło)
User Stories – Ujęcie Krytyczne
Na początku naszego wywodu, chcemy zaznaczyć, że uznajemy i akceptujemy modelową formułę user stories, oraz ich wartość facylitacyjną. To z czym się nie zgadzamy, i dowodzimy w poniższych, podzielonych na “mity” akapitach, to twierdzenie, iż user stories są wystarczającym, a nawet najlepszym środkiem do osiągnięcia zamierzonego efektu.
W niniejszym tekście zamierzamy dowieść, jak ważne jest usprawnienie formatu user stories przy pracy nad definiowaniem wymagań dla produktów wysokim poziomie złożoności. W małych, błahych projektach może okazać się to format wystarczający.
Mit Pierwszy:
Przekazywanie informacji przy pomocy user stories i w ramach związanych z nimi rozmów, to czytelniejszej forma komunikacji od zredagowanego tekstu.
Trudno kwestionować przypadki, w których dobrze poprowadzona rozmowa, pomaga rozjaśnić źle sformułowany komunikat pisemny. Sami jesteśmy w stanie przytoczyć przykłady tak źle opisanych “potrzeb użytkownika”, że zagęszczenie niezrozumiałych słów i stwierdzeń waha się pomiędzy 30% a ponad 90% w skali całego tekstu [3].
Jakie z tego płyną dla nas wnioski?
Otóż, redukcja defektów w specyfikacji powinna być możliwa poprzez wzięcie pod uwagę dwóch wielkości – częstotliwości odniesień do specyfikacji oraz liczby osób potrzebujących interpretacji konkretnych zapisów specyfikacji. Dobrze napisane wymaganie, niezależnie od jego poziomu, powinno być tak czytelne i zrozumiałe, że niepotrzebne jest żadne dodatkowe tłumaczenie (nie tak jak w przypadku założonych z góry dyskusji nad user stories).
Moc specyfikacji wzrasta wraz z rosnącą częstotliwością powoływania się na nią, oraz malejącą liczbą osób, które potrzebują dodatkowych wyjaśnień.
Dla zilustrowania mocy spisanego wymagania, spróbujcie przedyskutować poniższe stwierdzenie:
“Nasz system ma być możliwie najbardziej intuicyjny”.
Już?
To teraz porównajcie, waszą rozmowę z poniższą specyfikacją:
Intuicyjność
Typ: Wymaganie dotyczące Jakości
Interesariusz: Dział promocji, użytkownicy końcowi, trenerzy
Poziom Aspiracji: Stworzenie intuicyjnej i szybko reagującej aplikacji, znacząco lepszej od wszelkich produktów konkurencyjnych.
Skala: czas w sekundach potrzebny zdefiniowanym [Użytkownikom] do Poprawnego Zakończenia zdefiniowanego [Zadania] przy zdefiniowanych ramach [Wsparcia]
Cel:
Deadline = pierwsze wypuszczenie produktu,
Użytkownik = Nowicjusz,
Zadania = Najbardziej Skomplikowane,
Wsparcie = {Bez szkolenia, Bez podpowiedzi w aplikacji}
10 sekund +/- 5 sekund <– Product Marketing Manager.
Poprawne Zakończenie: zdefiniowane jako: rezultat zadania nigdy nie jest oceniony jako błąd lub rozwiązanie pośrednie.
Jeżeli pojawiają się jakieś pytania odnośnie powyższej specyfikacji, to odpowiedzi na nie powinny zostać dopisane. Ten zabieg pozwoli na lepsze zrozumienie, przyszłym odbiorcom, specyfikacji. Samo przedyskutowane “na głos”, bez zapisu, szybko doprowadzi do zapomnienia wniosków.
Mit Drugi:
User Stories formułowane są przy użyciu języka codziennego. Są zrozumiałe zarówno dla użytkowników, jak i programistów.
User Stories niekoniecznie są zrozumiałe dla wszystkich użytkowników, ani wszystkich programistów, albo któregokolwiek reprezentanta tych dwóch grup.
Co więcej, w rzeczywistości, bardzo łatwo można udowodnić, że, zwykle user stories są NIEZROZUMIAŁE.
W celu weryfikacji zrozumienia pojęć i stwierdzeń zawartych w specyfikacji można wykorzystać prosty test wieloznaczności. Wystarczy poprosić dostępne akurat osoby z projektu, aby indywidualnie napisały swoją osobistą interpretację specyfikacji. Spróbujcie tej metody, na przykładzie poniższego stwierdzenia:
“Nasz system ma być możliwie najbardziej intuicyjny”.
Ile potencjalnie stwierdzeń jest tu wieloznacznych?
Wszystkie.
Po zebraniu interpretacji, zobaczycie, że każdy trochę inaczej zrozumiał to wymaganie i nie ma dwóch identycznych interpretacji.
Alternatywnym sposobem na pokazanie, że specyfikacja jest niezrozumiała, jest policzenie błędów według standardu pozwalającego na redagowanie specyfikacji – Specification Quality Control.
Zasada 1: Specyfikacja powinna być wystarczająca czytelna, aby móc ją przetestować. Nie później, ale taką jaka jest! W tym momencie!
Zasada 2: Specyfikacja jest jednoznaczna dla wszystkich zamierzonych czytelników, w każdym miejscu i o każdej porze (włączają w to prawników, i ekspertów – świadków na twojej rozprawie sądowej).
Teraz, wykorzystując specyfikację:
“Nasz system ma być możliwie najbardziej intuicyjny”.
Jak wiele słów, potencjalnie łamie te zasady?
Nasza odpowiedź to 5, ale już nawet jedno wykroczenie dyskwalifikuje specyfikację, jako przydatną.
Mit Trzeci:
User Stories mają odpowiednią długość, adekwatną dla planowania i priorytetyzacji.
Nie mamy pojęcia, co może oznaczać twierdzenie o “odpowiedniej długości”.
Samo w sobie pojęcie “Odpowiednia długość” może budzić wątpliwości – jest dla czytelników wieloznaczne, i nie wystarczająco zrozumiałe aby je przetestować. Pozwólcie, że zaprezentujemy Wam naszą definicję “odpowiedniej długości”, lecz zanim ją przeczytacie, spróbujcie napisać swoją własną – porównamy.
Odpowiednia długość:
Długość opisu wystarczająca do realizacji kompletnego przeznaczenia danego wymagania. Realizacja nie wymaga dodatkowych uzupełnień “wewnątrz projektowych”, których koszt przewyższałby ewentualne koszty poprawek, wynikających z ubytków specyfikacji.
Jeżeli realizacja jednego krytycznego wymagania, wymaga strony opisu składającego się z 60 wersów czytelnej i kompletnej specyfikacji, to tak, to jest odpowiednia długość. Jeżeli jedna linijka tekstu akurat wystarczy, to też dobrze. Warto jednak zapamiętać, że nie ma za wiele sensu w przesadnym upraszczaniu wymagań, aby zachować modelowy formatu opisu… doprowadzając po roku do upadku całego projektu. Prawda?
Mit Czwarty:
User Stories są idealne dla iteracyjnego procesu wytwarzania oprogramowania.
Spieszymy donieść, że nie – User Stories, są katastrofalne dla iteracyjnego procesu wytwarzania oprogramowania.
Dlaczego?
Ponieważ nie jesteśmy w stanie zrozumieć ich przyrostowych i finalnych konsekwencji – nie da się zmierzyć postępu dostarczanej wartości w tak ogólnie sformułowanym celu.
Wbrew temu co myślą niektórzy, istotą wytwarzania oprogramowania nie powinno być “pisanie przypadków użycia”, historyjek czy funkcjonalności. Ideałem zwinnego procesu jest dostarczanie mierzalnej wartości interesariuszom w sposób przyrostowy.
Mit Piąty:
User Stories pomagają ustalić priorytety, mające sens zarówno dla użytkowników, jak i programistów.
Wieloznaczne i niezrozumiale napisane historyjki, są raczej złą podstawą do nadawania im priorytetu przez kogokolwiek. Poniżej, nasz pomysł na “priorytetyzowanie”:
Potencjalnemu “inkrementowi”, zostanie nadany priorytet wynikający z relacji “wartość dla interesariusza – koszt”, przy uwzględnieniu “ryzyka”.
Wieloznaczne historyjki nie opisują wartości dla interesariuszy w sposób liczbowy, ani nie zawierają w sobie wszystkich aspektów kosztów i ryzyka [7].
Ważne jest, aby pamiętać, że dobrze zdefiniowane wymaganie może być podstawą do oszacowania potencjalnej wartości dla interesariusza, ale nie może być odczytywane przez pryzmat kosztu.
Koszt jest całkowicie zawarty w rozwiązaniu (ang. design), a to co do zasady, nie powinno w żadnym razie być określone przed analizą wymagań.
Zatem, nie możesz określić najlepszej relacji wartości do kosztów (ang. best value for money) mając do dyspozycji tylko wymaganie w formacie user story.
Spróbujcie to zrobić z historyjką:
“Nasz system ma być możliwie najbardziej intuicyjny”.
Jaki jest koszt?
Nie możesz mieć żadnego pojęcia o koszcie, ponieważ wymaganie jest tak ogólnikowe, że nawet nie da się go w pełni zrozumieć, a co dopiero wybrać jakiekolwiek rozwiązanie, które na nie odpowie. Nie możesz podać kosztu rozwiązania, które nie zostało wybrane. To wszystko jest nielogiczne! [8]
Dodatkowo, dopóki nie znamy dokładnie specyfiki rozwiązania, nie możesz ocenić ryzyka odchyleń od celów i kosztów [9], więc nie możesz priorytetyzować iteracji ze względu na ryzyko.
Podsumowując, argument związany z priorytetyzacja user stories jest, logicznie na to patrząc, po prostu niedorzeczny.
Mit Szósty:
Proces umożliwia transparentność. Każdy rozumie dlaczego podejmowane konkretne decyzje.
Wszystkie wcześniejsze kontrargumenty, szczególnie związane z priorytetyzacją, pokazują jasno, że nie. Nie każdy rozumie przyczyny zmian oraz konkretnych decyzji podejmowanych w projekcie.
Możliwe, że ludzie czują, że rozumieją, jednak ze względu na wieloznaczność i niekompletność formatu user story, nie da się w rzeczywistości zrozumieć czegokolwiek – aspektów związanych z wartością, interesariuszami, rozwiązaniem, kosztem i ryzykiem...
W rzeczywistych sytuacjach projektowych, może pojawiać się zjawisko iluzji zrozumienia, ale nie będzie to zrozumienie o racjonalnych fundamentach. Jest to pochodna potrzeby dobrych i wygodnych relacji społecznych, która może się realizować poprzez “wspólne niezrozumienie”. Takie przysłowiowe “klepanie po plecach” i brak kwestionowania, może okazać się zgubny w skutkach przy jednoczesnym braku wglądu w różnorodność interpretacji wymagania.
To nie jest droga do sukcesu projektowego, nawet dla tych racjonalizujących, którym wydaje się, że rozumieją konsekwencje wynikających z wyboru user stories. [10, Decision Rationale].
Podsumowanie:
Jeśli czujesz, że kultura user stories, może stanowić problem w twoim projekcie, to … możesz mieć rację! Czołowi liderzy podejścia Agile wierzą, że potrzebujemy czegoś bardziej adekwatnego w bardziej wymagających środowiskach projektowych. User Stories są przydatne, ale “zbyt proste”, jako podstawowe, albo jedyne narzędzie w wielu środowiskach IT. Mimo powyższej dyskusji krytycznej, pamiętaj, że jeżeli format sprawdza się u Ciebie, to nie panikuj – to po prostu oznacza, że w przypadku Twojego projektu nie ma sensu ich zmieniać na potężniejsze narzędzia. Bądź tylko pewny, że faktycznie się sprawdzają, a nie pracujesz w iluzji zrozumienia.
Who you gonna call! The Myth Busters!
Tom and Kai Gilb www.gilb.com
Referencje:
- http://www.stevedenning.com/Business-Narrative/userstories-applied.aspx Attributes of User Stories by Denning and Cohn.
- http://en.wikipedia.org/wiki/User_story
- Gilb, Agile Specification Quality Control: http://www.gilb.com/dl264 in Testing Experience March 2009 Agile SQC Paper Gilb, in Testing Experience
- DAC and Boeing experiences with aircraft design quality, using Gilbs Inspection method (now called Spec QC [5] . Case study. http://www.gilb.com/dl254
- Gilb, Tom (2005) Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering, Using Planguage, Elsevier ButterworthHeinemann. ISBN 0750665076. Download of Chapter 10, Evolutionary Project Management is available from http://www.gilb.com/dl77 [Gilb 2005 b] Chapter 5 Scales of measure free sample 54 www.agilerecord.com chapter http://www.gilb.com/dl26 [Both Chapters Accessed 3 January 2011].
- Gilb, Tom (2010c) Value-Driven Development Principles and Values – Agility is the Tool, Not the Master. Agile Record, July 2010, 3. Also available from: http://www.gilb.com/dl431 See also part 2 of the paper at Part 2 “Values for Value” http://www.gilb.com/dl448 Agile Record 2010, www.agilerecord.com, October 2010, Issue 4
- Gilb and Maier, Managing Priorities. http://www.gilb.com/dl60
- Gilb Estimation or Control http://homepage.mac.com/tomgilb/filechute/Estimation%20or%20Control%202010%20MASTER.pdf edit note, a major revision of this paper will be published March 2011 in Software Quality Progress and we need an updated reference to it. I can supply our edit of this on request to readers. March 9 2011 tom gilb
- Gilb, Risk Management : A practical toolkit for identifying, analyzing and coping with project risk. http://www.gilb.com/dl20
- Gilb, Decision Rationale: A Quantified Decision-Making Basis Using Planguage, 2006 http://www.gilb.com/dl43