Co kryje się w Product Backlogu - seria: "Jak żyć?"

Okej, ale żeś z ciekawej perspektywy do tego podszedł. To ja spróbuję jeszcze raz wycofać trochę, ale to będzie związane z twoim pytaniem, bo popatrz, że takie popularne... To jest ta rozmowa, którą mieliśmy przed sekundą. Mieliśmy taką rozmowę, drodzy widzowie naszego kanału, o tym, że Scrum jest po prostu... Wylewa się takie wiadro pomyj na Scrum, że ten Scrum nie działa i to się wylewa w dużym stopniu z takiej narracji, że kurdebele miało być nowe podejście do zarządzania projektami I cholera, nie działa ten skram. I on nie działa z miliona powodów, ale jednym z powodów jest takie mentalne nastawienie, że właściwie dalej robimy to samo, co robiliśmy, tylko teraz będziemy robić to Zwinnie, iteracyjnie, cokolwiek. I popatrz, że to myślenie przekłada się też na nasze postrzeganie tego biednego Product Backlogu.

Uwaga, werbel, tutaj ten, możesz wiesz, wmontować potem werbel. To nie są historyki użytkownika. Nie, w sensie tak, wrzucam, bo to jest w ogóle fascynujące, jak spotykam się właśnie z ludźmi i tam w jednej organizacji jest Jira, w drugiej jest Azure DevOps, nie? Albo tam w trzeciej organizacji jest coś tam. To, jaki soft jest w danej organizacji, warunkuje, co jest w backlogu produktu i jednocześnie wbudowuje to ludziom w głowę, że w backlogu produktu są User Stories, a większe User Stories to są Feature, a jeszcze większe to są Epic. Więc myślę, że warto tutaj powiedzieć i przypomnieć sobie to, że Scrum jest frameworkiem, jest zestawem pewnych RAM, a to, czym my to wypełnimy, to już jest

Czasami to są jakieś pojedyncze zadania, które zostały. Będziesz miał wymagania niefunkcjonalne, na przykład sprawić, żeby w ramach naszej strony internetowej w jednej sekundzie było w stanie tam operować 100 tysięcy użytkowników, czyli wydajnościowe jakieś wymaganie. Będziesz miał wymaganie związane z bezpieczeństwem, będziesz miał jakieś Testy AB na przykład, czyli będziesz miał narrację o tym, że chcemy wprowadzić jakąś zmianę na stronie, która będzie połowie użytkowników się wyświetlała w taki sposób, a połowie w inny sposób. Więc tam będzie tona różnych pomysłów, hipotez. Natomiast ważne jest to, że one będą w tym miejscu, w tym jednym miejscu. Tam będzie dług techniczny jakoś opisany. Jeżeli żeśmy coś w poprzednim sprincie zawiązali na sznurki, wylali na to tonę kleju i zaszpachlowali tylko dlatego, że chcieliśmy wyjść z czymś szybciej na rynek, na przykład żeby zweryfikować jakąś hipotezę szybciej, to trzeba, powinniśmy, tak by było prawidlnie i sensownie, nie dlatego, że tak mówi Scrum Guide, tylko dlatego, że chcemy mieć w każdej chwili rozeznanie, jak bardzo jesteśmy w lesie z niektórymi tematami, powinniśmy wrzucić temat notacji do backlogu produktu.

Więc to gdzie to leci? Myślę, że mogą, gdyby było inaczej. No tak, gdybyśmy mieli osobną listę na to, to znowu, wszystko jest dozwolone, jakby rób to, co chcesz na świecie, w sensie nie ma wyższego ministerstwa w stosowaniu Scrum, natomiast nie jest to zgodne z regułami, bo uderza to w transparencję, czytelność tego, gdzie jesteśmy, ile przed nami pracy. Popatrz, że jeżeli masz tą adnotację w backlogu produktu, ty sobie jakoś to pewnie w swoim softcie Jakoś to se zgrupujesz, jakoś olabelujesz, otagujesz, że to jest utrzymanie na przykład, ale jeżeli masz tą adnotację, to jesteś w stanie zacząć myśleć o tym, że twój zespół wiosłuje w jakimś tempie i na przykład wprowadza takie powiedzmy rozwojowe

Skram i praca produktowa opiera się na tym, że te dwa światy się ze sobą zbliża i też jakby jasno się edukuje, to jest rola Scrum Mastera, edukuje o oba te światy, jak powinna ta relacja wyglądać. No i potem obserwujemy oczywiście, czy ona idzie w tą stronę, czy nie. Jeżeli nie, no to trzeba jakieś działania korygujące. Powiedz mi jeszcze taką rzecz, bo rozmawiamy o tym Product Backlogu. Jak w ogóle powstaje Product Backlog? Jak go stworzyć? Nie mamy nic, przychodzi biznes, mówi, że chce coś.

Niech będzie ten domek na działce. I co się dalej dzieje? Kto go tworzy? Jak go tworzy? To jest dobre pytanie, bo tutaj nasz ukochany przewodnik po Scrum jest bardzo okrojony w zawartość, czyli to jest takie ciekawe zjawisko, które też odkrywałem, że jak się zajrzy do Scrum Guide'a, to jest nagle takie podejście, że i nagle Od pewnego dnia objawiony tutaj był nam Product Owner i Backlog produktu i wszystko. Więc w praktyce bardzo ważna rzecz. Myślę, że od tego trzeba zacząć. I totalnie możemy narysować analogię do naszej pracy, współpracy.

Tu byśmy zeszli w różnego rodzaju praktyki, ćwiczenia poboczne, które nie są częścią frameworku Scrumowego, ale pamiętajmy, Scrum jest frameworkiem, można korzystać z różnych pobocznych narzędzi. To, co ja często robię, to jest story mapping. To jest jedna z praktyk. Story mapping to jest taka filozofia, narzędzie, w którym staramy się sobie skompletować pewną historię przejścia użytkownika przez różne obszary naszej aplikacji, różne kroki, które on wykonuje. Taka dekompozycja ogólnego flow na zasadzie Mamy księgarnię internetową, chcielibyśmy oczywiście pieniądze się zarabiać ze sprzedaży, ale co ten użytkownik wykonuje w ramach tej księgarni? Co on wiesz? Którymi on tam chodzi ścieżkami? Jakiego rodzaju części tego produktu on odwiedza?

Odkryją np. że cholera psu nos, to ten kret nam głowę zawraca, trzeba by rozłożyć tutaj siatkę jakąś np. przed tym, jak położymy trawnik. Więc tego typu rzeczy powinny, mogą, powinny być wrzucane przez deweloperów, przez interesariuszy. Ważne jest to, żeby ten Product Owner wiedział o tych zmianach. I to wyjdzie albo w bezpośredniej komunikacji, albo w ramach sesji refinementu. Wiesz, przed tym jak sobie powiemy, że coś jest ready for development, to ta rozmowa powinna się odbyć. Czyli znowu wracamy do tego tematu, że Product Owner musi cały czas być w kontakcie z zespołem. Tak, tak, tylko też nie chciałbym, żebyśmy... masz rację, tak, on powinien być, ja bym powiedział inaczej, on powinien być dostępny dla zespołu, o tak, cały czas, niekoniecznie, a co jeśli pracujesz w bardzo dużym setupie, skalowanym środowisku, tych zespołów jest wiele, ty jesteś Product Townerem, jednocześnie jesteś jakimś tam dyrektorem całego Departamentu Pionu, jeździsz po konferencjach, masz masę tematów poza Scrumem i Product Developmentem, nie?

Tak, tak. Z tego wynika cel produktu, cele sprintu również. I jeżeli mamy, dbamy o to, i znowu Scrum Master powinien zadbać o to, żeby Product Owner to rozumiał, to jeżeli mamy ten mechanizm in place, czyli on działa, to jest znacznie mniejsze ryzyko, że ten zespół gdzieś tam powiosłuje w zupełnie innym kierunku. Więc mamy tu dowolność. Każdy, kto ma jakiś pomysł na to, co można by dorzucić, może to robić. Tylko fajnie by było, żeby to było w takiej zdrowej relacji z Product Ownerem, żeby nie było też tak, że te działania finalnie doprowadzą do tego śmietnika. To też zahacza o pewną dojrzałość całego otoczenia Scrumowego. Jeżeli jesteśmy na samym początku wdrażania pracy w ten sposób, to pewnie więcej będzie tej dyrektywnej pracy Product Ownera, więcej kontroli nad tym.

Natomiast pytanie, co by się stało, jakby organizacja upubliczniała swój... Bo to było to pytanie, upubliczniała Product Backlogu na zewnątrz dla innych firm. Nie, nie, nie. W sensie domyślam się, że tak to już nie robimy, chyba że spółka giełdowa jakaś. Nie, no tak nie robimy. Ale chodzi mi o udostępnianie tego Product Backlogu osobom, które zleciły nam jakieś zadanie, ale niekoniecznie się na tym znają w ogóle. No dobra, bo ten termin zleciły, w sensie przyszły z jakimś pomysłem, który Product Owner uznał za stosowny, wrzucił go do backlogu produktu, to sobie tak powiem. Nie mam tu jednej odpowiedzi dla Ciebie, ja bym zadbał o to, żeby osoby, które są zainteresowane z perspektywy Scrum Mastera tym, co się dzieje w produkcie, miały ten wgląd i już.

Myślę, że to jest też wszystko kwestia obserwacji i patrzenia co się dzieje, to jest rola Scrum Mastera, co się dzieje z tym backlogiem produktu, w którą stronę to idzie procesowo, nad jak wieloma rzeczami w tym backlogu produktu Product Owner ma ogar, a jak wiele jest poza jego. Poza jego ogarem. I jeżeli jest dużo rzeczy poza tym ogarem, to znaczy, że pewnie nie trzeba się zwalidować, zrewaluować, jak podchodzimy do tematu zarządzania produktem. Tu mam takie pytanie, jeszcze mi się nasunęło. Przypójmy, że ten deweloper wrzuca coś do backlogu. W które miejsce on to wrzuca? Na nawiązanie do kolejności elementów, tak?