Porządne story

Porządny Agile

Jak mogą wyglądać elementy Backlogu Produktu, czyli potocznie story lub storki? Dowiesz się, jak takie porządne story powstaje i z jakich elementów się składa. Podajemy też przykładowy szablon zawartości dobrego story.

Porządny Agile · Porządne story

Dowiedz się jak stworzyć porządne story, które dzięki wykorzystaniu wizualizacji, pracy w podgrupach i eksperymentowaniu, może znacząco usprawnić pracę zespołu i zwiększyć jakość wytwarzanego produktu.

Inspiracją do poruszenia tego tematu jest doświadczenie Kuby ze współpracy z pewnym zespołem Product Ownerów. W trakcie rozmów pojawiła się kwestia praktycznego podejścia do Backlogu Produktu. Powstały się wówczas różnego rodzaju historyjki, a tym samym okazja do wprowadzenia drobnych poprawek oraz wskazania punktów, które są wartościowe i warto propagować je dalej.

Dlatego w tym artykule przekażemy Ci nasze rekomendacje związane z tworzeniem porządnego story, czyli inaczej elementu Backlogu Produktu. Mówiąc o story, mamy właśnie na myśli właśnie element, który chcemy mieć w produkcie i potrzebujemy go nazwać i określić.

Jak powstaje porządne story?

Nim przejdziemy do rekomendowanego przez nas szablonu story, podzielimy się z Tobą kilkoma wskazówkami:

1. Twórz Backlog Produktu całym Zespołem

Jedną z możliwych przyczyn niedoskonałych Backlogów Produktu lub pojedynczych stories jest to, że są realizowane przez jedną osobę. Nie ma znaczenia czy jest to Product Owner, analityk czy jeszcze inna osoba, w każdym przypadku, taka historyjka będzie bardzo jednostronna i całkiem możliwe, że niekompletna. Dlatego mocno rekomendujemy, aby w Twoim zespole stories były tworzone przez wszystkich jego członków. Pozwoli to zebrać wiele perspektyw od różnych specjalistów i stworzyć jak najbardziej kompletne story. Jednocześnie jest to dobra okazja do budowania odpowiedzialności zespołu za rozwiązanie i do zrozumienia kontekstu biznesowego, w którym ono powstaje.

2. Korzystaj z wizualizacji

Interpretowanie tekstu pisanego często niesie ze sobą zagrożenie tzw. głuchego telefonu i całkowite przeinaczenie pierwotnego przekazu. Aby upewnić się, że wszyscy w zespole rozumieją tak samo problem lub zadanie do wykonania, zaproponuj wykorzystanie z wizualizacji. Mamy tu na myśli różnego rodzaju schematy, diagramy, naszkicowane wersje interfejsu lub inne formy graficzne, które obrazują to, o czym rozmawiacie. Możesz to zrobić, biorąc kartkę i długopis i najprościej jak potrafisz, narysuj, to co omawiacie. Oczywiście, jeśli masz możliwość, to skorzystaj z tablicy czy whiteboardu, które są dostępne w wielu programach do spotkań online. Rekomendujemy Ci to, ponieważ z doświadczenia wiemy, że zespoły w większości przypadków przepracowują na tyle skomplikowane zadania, że samym tekstem trudno oddać istotę rzeczy, a ryzyko błędnej interpretacji jest dosyć wysokie.

3. Eksperymentuj z pracą w podgrupach

W pierwszej wskazówce mówiliśmy o angażowaniu całego zespołu do pracy nad Backlogiem Produktu, jednak niektóre czynności można przyspieszyć, rozdzielając zadania pomiędzy kilkuosobowe grupy. Każda z takich grup we własnym gronie przepracowuje zadany temat, a potem przedstawia go reszcie zespołu. Można również pracować w grupach symultanicznie nad tym samym zagadnieniem, aby później poznać różne perspektywy.

Praca w mniejszych grupach ma tę zaletę, że działając w kilkunastoosobowym zespole, może rodzić się pokusa siedzenia cicho, bo w końcu jest tyle osób, które może to zrobić za mnie. Natomiast pracując w mniejszej grupie osób, jest szansa, że wszyscy będą aktywni, gdyż trudniej się ukryć i tylko udawać zaangażowanie.

4. Unikaj pośredników

Zwróć uwagę na to, żeby tam, gdzie jest to możliwe, skracać łańcuch osób, które przekazują sobie informacje. Im mniej pośredników, tym większa szansa na uzyskanie konkretnej i właściwej informacji. Staraj się rozmawiać bezpośrednio z osobami, które są odpowiedzialne za poruszany temat. Dobrą praktyką jest też, zaproszenie tej osoby do rozmowy z całym zespołem. Wówczas wszyscy członkowie tego zespołu mają szansę dopytać o konkretne szczegóły i uzyskać z pierwszej ręki potrzebne Wam informacje. Dodatkową zaletą zaproszenia interesariuszy do współpracy jest to, że później można zaangażować ich w proces, np. przy tworzeniu wizualizacji czy do pracy w podgrupach. Taka zewnętrzna perspektywa jest często bardzo cenna i pozwala np. na szybsze uzyskanie informacji zwrotnej lub wsparcie przy bardziej skomplikowanych zagadnieniach.

5. Ciągle usprawniaj stosowane praktyki.

Jeśli w Twoim zespole została wypracowana konkretna propozycja rozwiązania czy plan działania, nie oznacza to, że nie można tego usprawnić w ramach kolejnych Retrospektyw. Podobnie, jeśli odkryty zostanie jakiś sprawdzony wzorzec postępowania, który przynosił dobre efekty, warto dalej eksperymentować. Wraz z Zespołem, ciągle przesuwajcie sobie granicę tego, co to znaczy dobrze opisany Backlog Produktu. Nie bój się, wychodzić z propozycją sprawdzania nowych podejść. Może to się odbywać nawet na bardzo malutkim wycinku elementu Backlogu Produktu, np. na jednym epiku czy pojedynczym, ale trochę inaczej opisanym story. Pamiętaj, tylko aby później przedyskutować efekty i wyciągnąć odpowiednie wnioski. Argumentem za tym jest również Manifest Agile, zgodnie z którym należy poszukiwać lepszych sposobów wytwarzania lub rozwijania produktu.

Propozycja szablonu historyjki

Proponowany przez nas szablon story składa się z poniższych elementów:

• User story – czyli historia użytkownika. Wskazuje się tutaj, dla kogo realizowany jest produkt, co jest konkretną potrzebą użytkownika i kim on jest. Jest to taka pigułka bardzo ogólnej wiedzy odnośnie tego, co jest do wykonania, ale jednocześnie daje ogrom punktów zaczepienia do pogłębiania tematu i zadawania pytań doszczegóławiających. Z tego, co obserwujemy w naszej pracy, wiele zespołów niestety pomija bardzo ważną część związaną z historią użytkownika, a mianowicie część odpowiadającą na pytanie “dlaczego”.

  Chcemy tu jednak zaznaczyć, że user story nie jest uniwersalnym narzędziem, zwłaszcza jeśli chodzi o mocno techniczne produkty. Traktuj user story jako okazję do empatyzowania z potrzebami użytkownika, zrozumienia go i na tej podstawie wytworzenia rozwiązań, z których zostanie wybrane to najbardziej sensowne.

• Tło biznesowe – oprócz zrozumienia perspektywy odbiorcy końcowego, zwykle istotny jest też aspekt biznesowy. Być może firma chce zarabiać na nowej funkcji albo konkurencja na tym zarabia, a może być też tak, że kwestie prawne wymuszają wprowadzenie zmian w produkcie. To tło biznesowe ułatwia zespołowi zrozumienie tego, dlaczego coś robi, nawet jeśli na pierwszy rzut oka może się wydawać, że nie ma to sensu. Oczywiście pomiń ten element, jeśli dana rzecz, nad którą pracujecie, nie wymaga dodatkowego omówienia pod kątem potrzeb biznesu.
• Kryteria Akceptacji – w przeciwieństwie do dwóch poprzednich elementów, które mają charakter opisowy, kryteria akceptacji są zwykle bardziej konkretne. Są z góry ustalonymi warunkami, jakie produkt, projekt lub ich fragmenty muszą spełnić, żeby zostały zatwierdzone. Pozwalają one ocenić czy osiągnięty został cel, do którego dążył zespół. Mogą mieć one postać krótkich, klarownych punktów, a więcej o nich dowiesz się z 94. odcinka podcastu Porządny Agile.

• ToDo i notatki – zachęć zespół do robienia notatek podczas dyskusji i zapisywania ważnych myśli czy pomysłów związanych np. z implementacją, nawet jeśli dotyczą bardzo odległego w czasie elementu Backlogu. Łatwo o nich potem zapomnieć, zwłaszcza jeśli developmentu podejmie się osoba, która nie uczestniczyła w tych rozmowach.

• Jak testować? – zawrzyj tu wszelkiego rodzaju informacje, które pojawią się w trakcie opracowywania poprzednich elementów story. Zapisuj informacje, które będą mówić o tym, jak podejść do testów, jakich środowisk użyć, z jakich danych korzystać, na co zwracać szczególną uwagę, czy pojawiły się może jakieś szczególne warunki brzegowe, o których trzeba pamiętać. Dzięki temu, gdy testerzy usiądą do pracy, będą mieli pewną bazę, na której będą mogli działać. Ponadto testerzy nie zostaną pozostawieni sami sobie, a członkowie zespołu może wpadną na jakieś usprawnienia czy automatyzacje, które będzie można wykorzystać w testach. Takie wspólne przedyskutowanie kwestii testowania jest szczególnie ważne przy bardziej skomplikowanych rozwiązaniach.
  
• Załączniki – mamy tu na myśli wielorakie pliki z notatkami, rysunkami, czy schematami. Mogą mieć one postać mało wyszukanych ręcznych zapisów, ale i uporządkowanych schematów interfejsu użytkownika lub ścieżki, jaką musi pokonać w produkcie, aby zrealizować swój cel. Oczywiście rodzaj i liczba załączników zależy od kontekstu i sposobu pracy zespołu, natomiast są one bardzo pomocne, gdy chcemy spojrzeć wstecz, przejrzeć starsze pomysły lub ustalenia z początku prac.

Pamiętaj, że nie jest to jedyna i zawsze uniwersalna lista. Każdy zespół sam powinien usprawniać swoje podejście i zdecydować, co sprawdza się najlepiej.

Przestrzegamy Cię też przed tworzeniem ścian tekstu i zbierania wszystkiego w jeden akapit. Warto zadbać o czytelność tego szablonu, stosować formatowanie tekstu, oddzielić poszczególne elementy nagłówkami. Same tytuły tych nagłówków powinny być jasne i łatwo rozróżnialne. Ułatwi to bardzo pracę z zebranymi informacjami i sprawi, że będą mogły być naprawdę pomocnym narzędziem podczas pracy zespołu.

Mamy nadzieję, że przedstawiony przez nas szablon historyjki oraz nasze rekomendacje, będą stanowić dla Ciebie i Twojego zespołu solidną bazę dla doskonalenia procesów i inspirację do ciągłego rozwoju produktu. Pamiętaj o ciągłym doskonaleniu praktyk, co pozwoli utrzymać wysoką jakość Backlogu Produktu i efektywność całego zespołu.

Dodatkowe materiały

• Kryteria akceptacji
• Jak zrobić dobry Backlog Produktu

Transkrypcja podcastu „Porządne story”

Kuba: Tematem tego odcinka będzie to, jak tworzyć porządne story. Pracowałem jakiś czas temu, to już prawie rok temu z pewną grupą Product Ownerów i w ramach tej współpracy pojawił się temat Backlogu Produktu, a tak dokładnie tego, jak dobrze jakościowo, jak dobrze podejść do tego od strony takiej narzędziowej czy praktycznej. Coś, co na pierwszy rzut oka było całkiem w porządku w przypadku Backlogów tych konkretnych Product Ownerów, gdy weszliśmy wszyscy razem w szczegóły, gdy zaczynaliśmy sobie porównywać poszczególne historyjki, które tamci Product Ownerzy przygotowywali, to jednak pojawiła się okazja do poprawienia, ale z drugiej strony też do wyliczenia takich punktów, które są wartościowe i które warto propagować. Więc tutaj postanowiliśmy, że w tym odcinku przekażemy dawkę tego, co naszym zdaniem jest jakąś taką pulą rekomendacji na temat tego, jak mogą wyglądać elementy Backlogu Produktu, czyli potocznie właśnie storki.

Jacek: I zdecydowaliśmy się na taką bardzo potoczną formę storki, story, dlatego że słyszymy, że w praktyce właśnie taki zwrot jest najczęściej używany, natomiast za każdym razem, jak o tym mówimy, to mamy na myśli najczęściej element Backlogu Produktu, jeżeli ktoś korzysta ze Scruma. Natomiast jeżeli ktoś się tylko inspiruje zwinnymi praktykami, to jest to po prostu jakiś element, który chcemy mieć w produkcie, chcemy mieć zrealizowany w projekcie, no i po prostu potrzebujemy go jakoś nazwać.

Jacek: Jeżeli chodzi o spis treści dzisiejszego odcinka, to właściwie dwa takie główne elementy. Po pierwsze, jak powstaje porządne story oraz druga część, z jakich elementów się składa.

Kuba: I, zanim zaczniemy, przypominamy, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to nasze płatne produkty znajdziesz na stronie porzadnyagile.pl/sklep

Jacek: OK. Jak powstaje porządne story? Pierwsza część tego podcastu. Na początek ważne zastrzeżenie. Celowo z Kubą nie zaczęliśmy od szablonu, ponieważ takie zaproponowanie szablonu bez kilku wskazówek, którymi chcemy się podzielić na początku, mogłoby zostać potraktowane przez Ciebie, słuchaczu, być może zbyt dosłownie. Dlatego najpierw kilka słów wprowadzenia, jak to zrobić porządnie, a dopiero następnie przejdziemy do samego szablonu.

Kuba: No i pierwszy punkt naszej rekomendacji, czy porady, to twórz Backlog Produktu całym zespołem. Coś, co jest jedną z możliwych źródłowych przyczyn niedoskonałych Backlogów Produktu, czy niedoskonałych pojedynczych stories, to to, że jest zrealizowana przez pojedynczą osobę, w niektórych zespołach to będzie analityk, w innych zespołach to będzie pojedynczy Product Owner, w jeszcze innych zespołach być może jeszcze jakaś inna osoba. No ale summa summarum taka niedoskonałość jest podobna, to story jest bardzo jednostronne, być może nawet całkiem nieźle rozpisane, w oczach tej pojedynczej osoby już całkiem kompletne, no ale jednak mocno rekomendujemy, czy mocno wspieramy pomysł tego, żeby do stworzenia story zaangażować cały zespół. Wszystkie perspektywy wszystkich specjalistów, czy profesjonalistów, jacy są w tym zespole, jacy z tego story będą później korzystać do tego, żeby ten produkt wytworzyć. Więc poszukajmy sposobów na to, o tym jeszcze będziemy dzisiaj mówić, ale angażujmy cały zespół.

Jacek: I zdecydowanie jest to jakaś forma inwestycji, no bo ktoś mógłby powiedzieć, lepiej przecież jak jedna osoba usiądzie i przygotuje całość, no i po prostu potem przekaże reszcie, natomiast super istotne w tej rekomendacji, żeby zrobić to całym zespołem jest to, że pracując nad tymi rozwiązaniami, po pierwsze budujemy odpowiedzialność zespołu za rozwiązanie. Z drugiej strony jest to superokazja, żeby sobie zbudować kontekst biznesowy. Z trzeciej strony jest spora szansa na to, że jeżeli od początku spojrzymy na budowanie rozwiązania z różnych perspektyw, to mamy okazję do tego, żeby wybrać naprawdę najlepsze rozwiązania, na które być może ta pojedyncza osoba po prostu by nie wpadła.

Jacek: Druga rekomendacja, korzystaj z wizualizacji. Intencją tego punktu jest zwrócenie uwagi na to, że interpretowanie tekstu pisanego grozi w pewnym sensie nieświadomym, ale jednak głuchym telefonem. To co ktoś miał w głowie, sposób w jaki to zapisał, to jak my to przeczytaliśmy, odczytaliśmy i jak to zrozumieliśmy, to mogą być kompletnie dwie różne historie. To co może pomóc w upewnieniu się, że wszyscy rozumiemy to, co jest do wykonania, czy problem, który rozwiązujemy w ten sam sposób, jest wspieranie się różnymi formami wizualizacji. Mówiąc o wizualizacji, mam tutaj na myśli różnego rodzaju schematy, diagramy, naszkicowane wersje interfejsu, jakiekolwiek formy, które powodują, że to, o czym rozmawiamy, prezentujemy nie tylko słownie czy pisemnie, ale także za pomocą wizualnej reprezentacji grafu, czegoś, co po prostu można zobaczyć.

Kuba: I zaczynaliśmy pracę zwinną w czasach przedpandemicznych, więc się o rzeczy też przed pracą powszechnie zdalną. No i to wtedy w praktyce oznaczało po prostu weź kartkę, weź długopis, czy jakiś pisak, może jeśli w salce, w której przepracowujesz, jest biała tablica, to skorzystaj z tej białej tablicy. I co się da, naszkicuj, narysuj, może dosłownie na gryzmol, ale jakby całym zespołem przepracujmy, co dokładnie tam jest w środku, jakie widzimy zależności, jak to się wszystko układa. Bo w większości przypadków akurat zespoły jednak mimo wszystko przepracowują zadania na tyle skomplikowane, że tekstem, samym tekstem, jest to dosyć trudno oddać lub wymaga chwili na interpretację, jednocześnie ryzykujemy, że ta interpretacja będzie błędna. Natomiast w pracy zdalnej oczywiście można się posiłkować podobnymi narzędziami, ważne, żeby je po prostu faktycznie wykorzystać. Nawet jeśli z jakiegoś powodu w naszej firmie nie stosuje się narzędzi do wspólnego szkicowania, czy jakichś białych tablic, na których wszyscy mogą fajnie pracować, bo są takie firmy, które niestety nie mogą w to wchodzić łatwo, to moim zdaniem naprawdę niewiele trzeba, żeby po prostu otworzyć Paint’a w komputerze, wyszerować go na ekranie i również spróbować po prostu narysować to. No a w tej chwili już narzędzia, mimo wszystko w ciągu ostatnich paru lat na tyle dużo postępu mają, że w większości narzędzi już takie rzeczy daje się robić lub daje się znaleźć odpowiedni zastępnik.

Kuba: Przechodząc do trzeciej porady, jak może powstać porządne story. Eksperymentuj z pracą w podgrupach. Tak jak na początku w pierwszej rekomendacji mówiłem o tym, żeby pracować czy tworzyć Backlog Produktu całym zespołem, to jednak to nie jest tak, że mamy taką wytyczną, że to każda czynność, czy każda aktywność, czy 100% tego procesu tworzenia story, to musi być praca całego zespołu, literalnie wszystkich zaangażowanych w ten proces, bo w praktyce może oznaczać, że duża część osób się przygląda, jak pojedyncza osoba wykonuje jakąś pracę. Więc tutaj intencją naszej rekomendacji jest to, żeby poszukać mądrego balansu właściwego dla danego zespołu czy dla danej organizacji, między trybami pracy w grupie jako w całości, a pracą w podgrupach. Być może stworzonych zadaniowo, czy takich ad hoc grup, które są właściwe i w kilka osób przepracują jakiś temat, wystarczająco dobrze i później na przykład przedstawią reszcie grupy.

Jacek: I tutaj też może pojawić się pokusa takiego myślenia, że no, po co robić symultanicznie to samo, zakładając, że do podzielonych grup ląduje to samo zadanie do przeanalizowania, przegadania czy zrozumienia, no ale tutaj działają takie mechanizmy jak to, że jest większa szansa, że pracując w małej grupie, wszystkie osoby się aktywują. Natomiast kiedy jestem jedną z 12 osób, które rozmawiają, no to może się rodzić we mnie takie poczucie, skoro tyle osób jest na sali, to jeżeli ja się nie odezwę, to się nic nie stanie. No, jeżeli tak parę innych osób sobie pomyśli, no to kończy się tym, że mamy 12 osób, z czego aktywnie współpracują 4, no natomiast pozostała reszta zwykle zaczyna się nudzić, no i w szczególności, jeżeli to jest praca zdalna, no to ta odległość od nudzi mi się do, ale super interesujących jest treści na Facebooku, no jest naprawdę niebezpiecznie bliska.

Jacek: Przedostatnia porada brzmi, unikaj pośredników. W całym procesie wytwarzania story warto zwrócić uwagę na to, żeby skracać łańcuch osób, skracać łańcuch pośredników i tam, gdzie jest to możliwe, rozmawiać bezpośrednio z osobami, które są w stanie nam jakąś konkretną informację, czy udzielić, czy być może rozjaśnić. Czyli przykładowo, jeżeli mamy jakąś formę Product Ownera, no to może być tak, że Product Owner rozmawia z interesariuszem, a następnie przynosi te informacje do zespołu. Równie sensowną, z mojej perspektywy, nawet często lepszą metodą jest to, żeby jednak ten interesariusz miał szansę wejść w interakcję z zespołem. Po pierwsze unikamy pośrednictwa, które może zniekształcić to, co interesariusz chciał przekazać, a z drugiej strony osoby, które mają szansę usłyszeć to z pierwszej ręki, mają również szansę zadać kontekstowe pytania, na które Product Owner z racji swojego doświadczenia, pełnionej odpowiedzialności, po prostu może nie wpaść.

Kuba: I to unikanie pośredników, a tak dokładnie to zaproszenie tych źródeł, właściwych ekspertów, czy właściwych osób, od których czerpiemy jakąś informację, daje też taki fajny efekt uboczny, że to te osoby też możemy później zaangażować w faktyczny proces tworzenia. To razem z nimi rysować, jak mówiliśmy o wizualizacji, to razem z nimi pracować w podgrupie, żeby może skomentowały to, co wytworzyliśmy, to, co spisaliśmy. No i w efekcie uzyskać też trzeba takie upewnienie się, że się faktycznie rozumiemy. Przy okazji może też rozpoczniemy jakąś fajną relację trwałej współpracy, nie tylko na etapie tworzenia story, ale też faktycznego wytwarzania produktu, gdy te osoby będą też mogły być się spontanicznie dopytane o jakieś szczegóły, czy nawet po prostu dostaną jakąś pierwszą wersję do szybkiej informacji zwrotnej. Więc tutaj jest parę kolejnych korzyści, innych niż tylko samo tworzenie wspólnie z tymi oryginalnymi źródłami.

Kuba: I ostatnia porada na temat tworzenia story, zanim pokażemy naszą propozycję samego schematu czy szablonu, to ciągle usprawniaj stosowane praktyki. To, że mamy jakąś swoją propozycję, to nie znaczy, że to jest jedna, jedyna, słuszna wersja. Ta propozycja, którą wymienimy, powstała w konkretnym zespole, jest efektem wielu, wielu kolejnych Retrospektyw. No i to jest schemat, który mi się powtarza. Niezależnie od siebie wiele zespołów wpada na wzorce postępowania, bo tak to dokładnie się nazywa, gdzie znienacka albo na zasadzie prób i błędów odkrywają bardzo podobne do siebie podejście, właśnie zawarte tak jak w naszych szablonach, ale niekoniecznie tylko takie. Więc dobre storisy w zespole to nie jest efekt jednej dobrej książki przeczytanej albo jednego dobrego podcastu odsłuchanego, tylko raczej tego, że na Retrospektywach do tego wracamy, jak mamy opisane elementy, czy nam się to sprawdza, czy czasami jakiś kawałek nie sprawił nam jakiegoś kłopotu i takie ciągłe, ciągłe przesuwanie sobie granicy tego, co to znaczy dobrze opisany Backlog Produktu. Więc rozmawiaj o tym na Retrospektywie, proponuj eksperymenty. I tutaj bardzo ważny dodatek, ponieważ najczęściej mówimy o dosyć dużych Backlogach, te eksperymenty niech od razu z automatu będą do bardzo wycinkowego fragmentu Backlogu. Czyli na przykład tylko do jednego epiku, czy dosłownie pojedyncze story napisane trochę inaczej i rozmowa o tym, jak nam się dzięki temu realizowało development. Faktycznie jest tak, że zespoły, które mają duże Backlogi, mogą być trochę niechętne do zmieniania podejścia, czy konwencji, czy szablonu, czy schematów postępowania, no bo po prostu to się wiąże na przykład z przepisaniem 50 elementów, gdyby chcieć wprowadzić jakiś nowy kawałek do opisu. Najczęściej to nie jest sensowne i w ogóle nie oddaje też takiej filozofii eksperymentowania. Zróbmy mały eksperyment wyizolowany i na jego bazie wyciągajmy dalsze wnioski.

Jacek: Jak słucham Kuba tego, o czym mówisz, to w sumie w pierwszej kolejności do głowy przychodzi mi taka jakby fundamentalna myśl z Manifestu agile, czyli poszukujmy lepszych sposobów wytwarzania oprogramowania, czy po prostu rozwijania produktu. No jakby to, co opowiadasz, myślę, że bardzo dobrze się wpisuje w tą taką nieustanną chęć odnajdywania jeszcze lepszych praktyk, jeszcze lepszych sposobów.

Jacek: Dobrze, zakończyliśmy tę część taką wstępną, którą z Kubą uważamy za niezwykle istotną, żeby sensownie z głową wykorzystać szablon tworzenia historyjki. I teraz podzielimy się tym, jak wygląda nasza rekomendacja. Propozycja szablonu historyjki wygląda następująco. Składa się ona z historii użytkownika, czyli popularnego user story, tła biznesowego, kryteriów akceptacji, wszelkiego rodzaju spisanych tudusów i notatek, informacji tego, jak przetestujemy, to, co właśnie opisaliśmy i ewentualnie, jeśli to kontekstowo ma sens, z załączników.

Kuba: Ale pamiętaj o naszym zastrzeżeniu, że lista, którą Jacek wymienił, nie jest zawsze uniwersalnie słuszna. Każdy zespół powinien usprawniać swoje podejście sam i nie gwarantujemy, że wszędzie wcześniej wymieniona całość to dobry zestaw. Ale opowiemy o każdym z tych elementów, trochę pogłębiając, co mamy na myśli i dlaczego naszym zdaniem warto, żeby story zawierało ten aspekt.

Jacek: Pierwszy element, który wymieniliśmy, to jest user story, czyli jakaś forma historii użytkownika. Ten kawałek o tyle ma sens, że wskazuje nam na to, dla kogo realizujemy konkretną rzecz, co jest konkretną potrzebą i dlaczego tak naprawdę chcemy to zrealizować. Pierwotna koncepcja user story jest bardzo sensowna, bo jest taką pigułką, która dosyć ogólnie opisuje, co jest do wykonania, jednocześnie daje całą masę punktów zaczepienia, które powinny w nas uruchomić chęć dopytania, zadania pytania, czy pogłębienia tych aspektów. O ile dobrze pamiętam, to Alistar Cockburn określił, że user story to jest taki token, który mogę chwycić do ręki, myśląc oczywiście o tym, że jest to praca stacjonarna, czyli zdejmuję taką karteczkę z user story z tablicy i tak naprawdę mogę z nią podejść do kogoś, pokazać, czy rozpocząć rozmowę. Taka była pierwotna intencja. Wiele zespołów stosuje tego rodzaju szablon, obserwujemy to z Kubą, pracując z różnymi organizacjami. Wiele zespołów stosuje ten szablon w niekompletny sposób, na co też warto zwrócić uwagę, czyli bardzo często najpopularniejszym problemem jest to, że jest pomijana ta część dlaczego. Czyli częściej spotykamy jako ktoś chce coś, natomiast nieco rzadziej pojawia się ta część dlaczego, która tak naprawdę jest całkiem mądra i całkiem sensowna. Jednocześnie ta część związana z user story to nie jest super uniwersalne narzędzie, jeżeli mówimy o jakichś takich bardzo mocno technicznych produktach, jakichś funkcjach, systemów, no to próba wkładania tego rodzaju tematów w user story moim zdaniem nie jest najlepszym pomysłem. Faktycznie jest tak, że user story ma być dla nas taką okazją, żeby wykazać się empatią w stosunku do potrzeby klienta, posłuchać pewnej opowieści, posłuchać pewnej narracji, no i jakby dobrze rozumiejąc te potrzeby, powinniśmy jako zespół być w stanie zaproponować pewien pakiet rozwiązań, czy pewien wachlarz możliwości i na skutek dyskusji zwykle z Product Ownerem jesteśmy w stanie wybrać takie rozwiązanie, które w danym momencie wydaje nam się najbardziej sensowne.

Kuba: I, zwłaszcza jeśli do kontekstu Twojego zespołu user story rozumiana jako ten szablon, jako użytkownik chce coś tam, aby coś tam nie do końca pasuje, to nie róbmy tego szablonu na siłę, ale wróćmy do tego właściwego korzenia czy właściwej istoty, które ten komunikat ma przekazać. Czyli odpowiedzenie sobie wstępnie na pytanie, dla kogo to robimy, co chcemy zrobić i po co to robimy. I może możemy wkładać to do szablonu, a może możemy te informacje powtórzyć po prostu w pewnej puli takich właśnie nagłówków, dla kogo, co i po co, jako jakiś taki rodzaj wstępu do samej historyjki, do całej reszty opisu tej historyjki, no i ustalenie podstawowych faktów, które niedopowiedziane mogą prosić się o kłopoty w dalszej implementacji tego.

Kuba: Drugi składnik opisu historyjki to tło biznesowe. O ile ta historyjka użytkownika rozumiana jako user story, które wymieniliśmy chwilę wcześniej, mocno skupia się na użytkowniku, na perspektywie odbiorcy końcowego, to często jest tak, że dany element ma też jakieś uzasadnienie biznesowe, na przykład na tej funkcji firma zarabia, albo może nie zarabia, a powinna zarabiać, albo konkurenci zarabiają więcej niż my, może jest jakiś powód, dla którego musimy zrobić jakąś rzecz, może jakieś otoczenie prawne, jakieś wytyczne korporacyjne. Cokolwiek, co powoduje, że są jakieś dodatkowe powody, czy dodatkowy kontekst, dodatkowe tło, które powoduje, że zespół lepiej rozumie, po co to robi i być może lepiej też rozumie, dlaczego tak, a nie inaczej to będzie musiało być zaimplementowane. Więc sama ta konwencja user story wymieniona wcześniej czasami nie powie wszystkiego, albo na siłę i tak dosyć niepotrzebnie próbuje się wpasować do tego szablonu trochę więcej informacji, niż on jest w stanie zmieścić, proponuje po prostu osobny punkt, dosyć wcześnie w ramach opisu danej storki, gdzie takie jakieś dodatkowe, ważne informacje są dodane.One mogą być czasami takie dosyć powtarzające się dla całej większej puli, czegoś, co robimy w ramach epiku czy projektu, ale mimo wszystko warto pewne rzeczy jakby przypomnieć, czy pewne rzeczy powtórzyć, ten konkretny ficzer robimy z takich a takich powodów biznesowych, czy takie a takie ma uzasadnienie. Oczywiście, jeśli ma to sens, no bo jeśli dany mikroficzer, czy dana pojedyncza rzecz takiego jakiegoś dodatkowego tła nie ma, to po prostu sobie odpuśćmy uzupełnienie tego punktu.

Jacek: Trzeci element szablonu to kryteria akceptacji. I tak jak user story i to tło biznesowe, o którym Kuba przed chwilą mówił, zwykle mają charakter taki trochę bardziej opisowy, tak kryteria akceptacji są już trochę bardziej konkretne. Przede wszystkim są to takie z góry ustalone warunki, jakie produkt albo projekt lub fragmenty projektu czy produktu muszą spełnić, żeby zostały zaakceptowane. Czyli czego my się tak naprawdę po tym spodziewamy? Patrząc na kryteria akceptacji i na to, co faktycznie zrealizowaliśmy, bardzo łatwo jesteśmy w stanie ocenić, czy osiągnęliśmy to, co chcieliśmy. Jest to o wiele prostsze, jeżeli mamy to dobrze wyszczególnione w postaci takich krótkich konkretnych punktów, niż gdybyśmy mieli wyławiać te informacje z jakiejś takiej długiej ściany tekstu. To ujęcie takie w postaci punktów jest czymś, co najczęściej spotykamy w praktyce. No i z mojej perspektywy jest to taki wzorzec, który warto powielać i warto się nim zainspirować. Jeżeli temat kryteriów akceptacji jest dla Ciebie interesujący, to możesz przeczytać albo posłuchać o tym temacie pod adresem porzadnyagile.pl/94.

Kuba: Kolejnym elementem rekomendowanego przez nas szablonu jest lista tudusów i jakieś notatki implementacyjne. Coś, co obserwujemy, to to, że zespoły w procesie Refinementu bardzo często mimo wszystko zahaczają trochę o rozwiązanie. Z jednej strony jest taka, powiedzmy, wytyczna czy rekomendacja, żeby być może przede wszystkim ustalić właśnie te kryteria, user story, na razie zrozumieć potrzebę, a nie skakać do rozwiązania, ale to jest do jakiegoś stopnia nieodłączne, że zespół, czy to w procesie wyceny, czy to w procesie próby zrozumienia, jak to ma być zaimplementowane, jednak gdzieś tam zaczyna spekulować, szkicować sobie jakąś część rozwiązania. Dużym nieszczęściem jest to, że te elementy dyskusji gdzieś uciekają, a zwłaszcza jeśli ten konkretny kawałek Backlogu będzie implementowany dopiero za kilka tygodni albo kilka miesięcy, to cały proces myślenia od nowa jest dosyć frustrujący, a nawet wręcz może być niebezpieczny, bo być może ktoś zwrócił uwagę na bardzo ważny aspekt implementacyjny, a ktoś inny to później podjął do developmentu i akurat o tym zapomniał. Więc bądźmy w okej z tym, że częściom storki, być może dalszą częścią, to już jest któryś element Backlogu, któryś element naszego proponowanego szablonu, mimo wszystko zapiszmy takie jakieś ważne przypomnienia, czy ważne notatki. To nawet łączy się trochę z tym, o czym Jacek mówił przy kryteriach akceptacji, że czasami zespoły bardzo chcąc zapisywać sobie pewne rzeczy, to do kryteriów akceptacji ładują jakieś takie właśnie informacje implementacyjne. One w sensu stricto nie są kryteriami akceptacji, że zastosujemy tego podejścia, użyjemy tego modułu albo skorzystamy z Clouda, ale mogą być taką notatką dla samych siebie, skoro już całym zespołem dyskutowaliśmy o tym elemencie, no to nie zgubmy tego, zapamiętajmy to sobie, czy po prostu sobie jakoś to właśnie wypiszmy. I to może być dosłownie aż lista zadań do wykonania, bo niektóre zespoły już w procesie Refinementu szykują sobie jakieś takie składowe, jak to będzie dokładnie realizowane, jeśli chodzi o plan realizacji, a może to są tylko właśnie jakieś takie notatki gdzieś z pogranicza architektury, pomysłów na rozwiązanie, czy jakiś takich przestróg do samych siebie, które odkryliśmy w procesie zapoznawania się z tematem.

Jacek: Kolejnym podobnym elementem do tego, co Kuba przed chwilą powiedział, jest sekcja how to test, czyli jak przetestować. Generalnie jak przetestować, dosyć sporo jesteśmy w stanie się dowiedzieć, patrząc tylko na kryteria akceptacji, ale zwykle w procesie dyskusji na temat kryteriów akceptacji, w szczególności, jeżeli biorą udział w tej dyskusji testerzy, pojawiają się pewne takie kontekstowe informacje, które mają duże znaczenie, kiedy będziemy już siadać do testowania, no ale niekoniecznie byśmy chcieli to wrzucać do kryteriów. Więc wszystkie takie dodatkowe informacje wskazujące na to, jakich środowisk użyć, jakiego setu danych wykorzystać, jak podejść do testowania, na co zwrócić uwagę, może są już jakieś konkretne warunki brzegowe, o których nie chcemy zapomnieć, wszystkie takie istotne informacje, które wyłapaliśmy na etapie dyskutowania o konkretnej funkcjonalności, warto w takiej dedykowanej sekcji dotyczącej tego, jak będziemy testować, zapisać. Po to, że gdy usiądziemy do testów, a to może być przecież za parę dni, a to może być za tydzień, no to żeby nie wymyślać koło na nowo, tylko mieć pewną podpórkę, która przypomni nam, jak zrobić to porządnie.

Kuba: Zwłaszcza że niektóre z tych punktów, które wymieniłeś, przekładają się wprost na prace do wykonania. No pracujemy z bardzo różnymi zespołami, ale niektóre z nich tworzą bardzo skomplikowane logicznie rozwiązania, no i na przykład na generowanie wielu przypadków, albo zbudowanie bardzo dużej puli jakiś konkretnych przykładowych kont, albo konkretnych przykładowych jakichś tam transakcji, które trzeba zweryfikować, no to jest nietrywialna sprawa, warto o niej głośno powiedzieć, a być może całym zespołem poszukać jak najlepszego sposobu, żeby się za to zabrać, zautomatyzować całość, albo chociaż część tego działania, żeby się tam nie okazało na końcu, że tester jest zostawiony samemu sobie. I z drugiej strony patrząc, taka dedykowana sekcja o tym, jak to przetestować, jest też właśnie takim może właśnie polem do popisu dla każdej osoby, która odpowiada właśnie za proces testowy w danym zespole. Być może są jakieś takie ważne informacje, które akurat w tej sekcji mogą być zawarte.

Kuba: I ostatni punkt naszego szablonu to załączniki. One oczywiście będą kontekstowo uzasadnione, ale mamy tu na myśli zarówno wszystkie możliwe zapisy notatek, o których wspomnieliśmy wcześniej w formie wizualnej. Czyli może jakiś schemat, może jakiś diagram, może jakieś dosłownie gryzmoły, a może coś bardzo, bardzo uporządkowanego, jakiś fajny diagram wygenerowany w bardzo taki rzetelny i zgodny z konwencją sposób, czy idąc tropem user experience, czy user interface design, po prostu jakieś schematy wyglądów interfejsu użytkownika, jakichś kolejnych etapów, kolejnych stron, czy kolejnych wersji tego, jak to funkcjonuje. Fajnie jest, wiele zespołów sobie to superceni, że można bardzo szybko upewnić się, jak to skomplikowane coś, co właśnie przerabiamy w tej storce, ma wyglądać albo ma się zachować. Fajnie jest, gdy to jest jednak zawarte właśnie też w poręczny sposób w załączniku, który jest jednoznacznie opisany, który jest też zrozumiały, który ewentualnie jest też może właśnie przydatny, czy służy pomocą dla wszystkich członków zespołu.

Jacek: Ja myślę sobie o tych załącznikach w szczególności, jeżeli to jest uchwycenie właśnie jakichś takich naszych bazgrołów, jak to Kuba określił, jako taki, mówiąc po staropolsku, snapshot, czyli taki pewien zrzut uchwycony z czasu, dlatego, że patrząc na to za jakiś czas, jesteśmy w stanie sobie o wiele łatwiej przypomnieć tę konkretną dyskusję. Dlatego, że nie tylko patrzymy na zapisane teksty, ale widzimy też pewne obrazy i w szczególności, jeżeli jesteś wzrokowcem, to często taki rzut oka na taką notatkę automatycznie przywraca pamięć i o wiele prościej jest do konkretnego tematu wrócić.

Jacek: Osobna uwaga na koniec, którą chcemy się podzielić, dotyczy samej czytelności tego szablonu, tego układu, który proponujemy. Zdecydowanie rekomendujemy, żeby unikać ściany tekstu, zlepiania wszystkich informacji w jakiś jeden zbiorowy, duży akapit. Warto zadbać o czytelne nagłówki, warto pogrubić, wyboldować te elementy tekstu, które są istotne. Warto zadbać o wypunktowywanie pewnych rzeczy, o dodanie takiego, nazwijmy to, światła pomiędzy częściami tych informacji, po to, żeby sam rzut oka na taki zapis od razu pomagał nam tak naprawdę odnaleźć, gdzie są kryteria akceptacji, gdzie są jest user storisy. Czy też tak naturalnie wiemy, że na przykład musimy przewinąć kawałek ekranu, no bo zawsze na samym dole są załączniki?

Kuba: I to, co Jacek mówi, dotyczy opisu, to światło czy dobre poukładanie czy nagłówki, ale czytelny może być też przede wszystkim sam tytuł danej storki. Przez przykład to powiem, storka zmiany w formularzu może znaczyć wszystko i nic i za tydzień lub za miesiąc lub za pół roku nie będziemy pamiętać, o co chodziło i trzeba koniecznie wejść do środka, żeby sobie przypomnieć, co to tam było i co mieliśmy na myśli, ale już na przykład bardzo opisowy, może kilka słów więcej zawierający tytuł, dodanie do formularza rozwijanej listy kraju może być takim jednoznacznym rozróżnieniem między tym story a jakimiś kolejnymi innymi. Oczywiście wymaga do chwili może zastanowienia, ale fajnie, jeśli zespół sobie tworzy jakąś taką higienę, również na tym poziomie, że te opisy, ale też tytuły są jednoznaczne, łatwo rozróżnialne. Tytuły mają znaczenie zwłaszcza, jeśli mówimy właśnie o historii powracania do pewnych elementów albo o przeglądaniu długiej listy. Sam byłem wielokrotnie świadkiem zespołów, które wręcz topiły się w jakiejś długaśnej liście, totalnie bez konwencji, w której w zasadzie wszystkie możliwe warianty były widoczne, ale tak naprawdę odnaleźć tej właściwej historyjki nie było sposobu, no bo niestety właśnie nie było stosowania jakiejś podstawowej zasady tego, jak się tytułuje storki.

Kuba: Podsumowując, jakie mamy rady dla zespołów, które chcą tworzyć porządne story? Twórz Backlog Produktu całym zespołem, korzystaj z wizualizacji, eksperymentuj z pracą w podgrupach, unikaj pośredników, ciągle usprawniaj stosowane praktyki.

Jacek: Story naszym zdaniem może być stworzone według następującego szablonu. User story, tło biznesowe, kryteria akceptacji, wszelkiego rodzaju tudusy i notatki, informacja jak przetestujemy oraz wszystkie konieczne załączniki. Warto pamiętać, że każdy zespół dopracowuje sobie swój standard,

Kuba: I na koniec mamy prośbę, potrzebna nam informacja zwrotna od Ciebie i chcemy poprosić o wypełnienie krótkiej ankiety na temat naszego podcastu. Dzięki takiemu feedbackowi możemy się rozwijać. Poprzednie badania dały nam dużo wkładu, dzięki temu wiele aspektów tego jak działamy z podcastem, jak tworzymy nasze treści – ulega ciągłej poprawie. Dalej chcemy robić jeszcze lepsze treści, rozwijać się i tworzyć lepsze produkty dla wszystkich słuchaczy. Będziemy bardzo wdzięczni, jeśli poświęcisz kilka minut i wypełnisz nasz kwestionariusz na stronie porzadnyagile.pl/ankieta.

Jacek: Notatki do tego odcinka, artykuł, transkrypcja oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/115

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek

Jacek: Dzięki Kuba i do usłyszenia wkrótce.

The post Porządne story first appeared on Porządny Agile.