Zwinne zarządzanie – dziś o jednym z najbardziej popularnych narzędzi zwinnych, które panoszy się obecnie w wielu projektach i nie tylko.
Historyjka użytkownika (User Story) – sprawdzi się w każdej sytuacji zwinnego zarządzania, w której tworzysz coś, z czego inni potem korzystają. Program szkoleniowy? Aplikacja banku na smartfona? Innowacyjny model auta? System do zarządzania projektami? W każdym z powyższych przypadków, odczujesz zbawienne skutki zastosowania „user story”.
HISTORYJKA UŻYTKOWNIKA – NARZĘDZIE
Historyjka użytkownika sprawdzi się w zwinnym zarządzaniu, jako narzędzie do opisywania wymagań produktu, projektu przez Product Owner’a. A uogólniając, tego, co ma być efektem naszych prac. Oto formułka historyjki:
Jako (kto?) chcę aby (co?), po to (po co?).
Prawdopodobnie, gdy zerkniesz na rysunek obrazujący szablon historyjki oraz trzy przykłady, zwinne zarządzanie w tym zakresie od razu stanie się jasne.
HISTORYJKA UŻYTKOWNIKA – PRZYKŁAD
Załóżmy, że jesteś Product Owner’em w firmie produkującej flipcharty. Do realizacji projektów stosujecie zwinne zarządzanie. Powyżej masz przykłady trzech różnych użytkowników tego przedmiotu. Kogo można by tu jeszcze dodać? Może panią sprzątającą? Producenta opakowań? Kuriera? Z pewnością można też mnożyć wymagania ze strony użytkowników, którzy już znaleźli się w powyższej tabeli. Jako trener zarządzania projektami w organizacjach chciałabym m.in. móc regulować wysokość flipcharta, chciałabym też by ten przedmiot miał podstawkę na flamastry.
Jak już zapewne zauważyłeś, historyjka użytkownika pozwala na uwzględnienie wymagań każdego, kto będzie w jakiś sposób miał styczność z produktem. Ważne jest, by zapisać kto to jest. W firmowych rejestrach produktów, w aplikacji JIRA często obserwuję formułkę zaczynającą się od: „jako użytkownik…” i tak do końca długiej listy wymagań występuje tylko jedna osoba, a właściwie wszystkie osoby pod jedną postacią 😉
Nie jest to dobra praktyka zwinnego zarządzania. W ten sposób nie zrozumiemy dlaczego ktoś chce aby produkt miał daną funkcjonalność, komponent. Dopiero dowiedziawszy się, że wymaganie pochodzi od kuriera albo producenta opakowań, rozumiem dlaczego Product Owner wpisał o kartonach w danej linijce rejestru produktu.
Historyjka pozwala zniwelować jeszcze jeden częsty mechanizm: mówienie rozwiązaniem. Bardzo często zdarza się w pracy z klientem, sponsorem, że otrzymujemy od nich zlecenie w postaci rozwiązania, czyli pracy do wykonania. Na przykład, że flipchart ma mieć półeczkę na flamastry. Tymczasem, takie półeczki w ogóle się nie sprawdzają – znam to z autopsji. Przekręcasz stronę i wodospad flamastrów leci na podłogę. I tak za każdym razem. No chyba, że flipchart jest za duży, a kartki zakupione za małe – ale to inny case.
Wracając do naszej półki na flamastry, gdy czytam po co: Żeby mieć wszystkie flamastry pod ręką, mogę szybko stwierdzić, że półka nie rozwiąże problemu i pomyśleć o innym rozwiązaniu umieszczania flamastrów w pobliżu flipcharta.
Chyba już teraz nie muszę Cię przekonywać, że „user stories” warto stosować, nie tylko w zwinnym zarządzaniu?
HISTORYJKA UŻYTKOWNIKA – PODSUMOWANIE
I tym sposobem zakończyłam wprowadzenie do tematu, bo już za tydzień w kolejnym odcinku opowiem Ci o miernikach historyjki:
- Use case
- Test case
- DoD
Jeśli starczy znaków i czasu na sesji live opowiem trochę więcej (INVEST i zasada 3c), ale tutaj pozwalam sobie na pełną swobodę. Czego nie omówię teraz, to stanie się tematem kolejnych #PmCatchUpów.
Pod tym tekstem obejrzysz filmik #ProstoZsaliSzkoleniowej, na którym przedstawiam historyjkę użytkownika.
Pamiętaj, że #PmCatchUp odbywa się, co tydzień w środę o godzinie 8:30 na moim fanpage tutaj.
Co tydzień wychodzi newsletter. Jeśli chcesz być na bieżąco i otrzymać od nas prezent – ściągę SCRUM w pigułce, to zapisz się tutaj.
A jeśli zwinne zarządzanie to Twój „konik” lub stojące przed Tobą wyzwanie, to zapraszam Cię na szkolenie scrum pod autorską nazwą Biznesowy Scrum . Sprawdź, czy akurat jest dostępne w niższej cenie!
Pozdrawiam,
Ania
Pingback: jak opisywać user story w agile