Transkrypt odcinka 34
Wstęp
Witam was serdecznie w 34 odcinku podcastu Kanban przy kawie. Dzisiaj opowiem o narzędziach. Mówi się czasami, żeby nie myśleć narzędziami, ale bez narzędzi nie jesteśmy w stanie wykonywać naszej pracy. O jakich narzędziach mówię? Będzie to temat połączony poniekąd z poprzednim odcinkiem – w odcinku 33 opowiadałem konkretnie o kilku metrykach: metrykach przepływu. Na stronie internetowej odcinka (powyżej) znajdziecie ich wizualizacje. I tu pojawiają się pytania: fajnie, a tak poza rysunkiem, to jak takie grafy budować? Jak takie wykresy uzyskać? A najlepiej, żeby one były w sposób automatyczny aktualizowane. Właśnie o tym opowiem. Opowiem z perspektywy użytkownika kilku najpopularniejszych na rynku systemów, aplikacji do śledzenia czy organizacji pracy. Będzie więc coś dla osób które używają Jiry, będzie coś dla osób które używają Azure DevOps oraz narzędzi takich jak Asana czy Trello. Ale zaczniemy od takich narzędzi czy formy budowania wykresów, która jest zupełnie niezależna i bardzo nisko kosztowa..
Narzędzia pomiarowe: bezpłatne i komercyjne
Chciałbym opowiedzieć Wam dzisiaj o trzech kategoriach narzędzi. Pierwsze narzędzia to będą takie narzędzia bardzo nisko kosztowe pod kątem kosztu pracy oraz finansowym, a więc takie, które praktycznie nic poza niewielką ilością naszego czasu nie muszą kosztować. O czym mowa? Przed pandemią należałem do tych osób, które w różnych firmach propagowały taką pracę, żebyśmy zrozumieli, czym są metryki, które śledzimy, których używamy i takie metryki jak właśnie histogramy czasów realizacji czy wykresy delivery rate, a więc tego tempa dostarczania były budowane kolaboratywnie przez cały zespół w postaci karteczek, na których wypisywaliśmy zadania w określonych lead time’ach czy wybudowaliśmy z nich określone słupki. Część tych rzeczy przeniosła się wraz z rozproszeniem zespołu do narzędzi elektronicznych. Jakich narzędzi? Tych, które prawdopodobnie macie już w swoich firmach: Miro, Mural, Jamboard czy White Board od Microsoftu, a więc różnego rodzaju zastępstwa tych papierowych karteczek i białych sucho ścieralnych tablic. Mówimy o narzędziach, które wydawać się mogą niepoważne, dlatego że to nie jest jakieś narzędzie, które generuje metryki, ale przecież właśnie metryki można wygenerować w tym narzędziu. Jeżeli nasz zespół nie „przerabia” w ciągu tygodnia, sprintu czy miesiąca dziesiątek albo setek jednostek wartości klienta, a więc, pamiętajmy, tego, co klient rozpoznaje za zawartość: czy to jest gotowa funkcja, czy to jest odbyta rozmowa z kandydatem i pozytywnie zrekrutowany kandydat i tak dalej, i tak dalej, to okaże się, że takich elementów pracy, które właśnie w takim okresie chcielibyśmy zwizualizować jest raptem kilka-kilkanaście, wydaje się, że rzadziej więcej niż 20-30. Okazuje się, że przy zdrowej wielkości zespole taka praca polegająca na tym, że razem zbudujemy taki wykres i potem będziemy tak addytywnie dodawać te nowe karteczki wirtualne do niego, tak na dobrą sprawę pokaże nam właśnie, jak ta metryka działa, jak ona się kształtuje. Oczywiście będzie potrzebne trochę kalkulacji, zwykle takich, które da się zrobić w aplikacji kalkulator, nawet nie trzeba zaprzęgać do tego Excela i okaże się, że być może, to poza metryką, która rzeczywiście będzie nam dostarczała tej informacji (choć oczywiście będzie musiała być aktualizowana ręcznie), to pozwoli nam budować naprawdę dobre rozumienie tego i bardzo często, powiedziałbym, zainicjuje rozmowy. Te potrzebne rozmowy, których może by nie było, gdyby właśnie to narzędzie w postaci jakiejś wirtualnej tablicy zastąpić narzędziem, które będzie „robiło całą robotę” za nas – generowało te raporty za nas w sposób zautomatyzowany. Zapraszam do tego żebyście się zastanowili, jeśli jakiś metryki obecnie śledzicie, czy te metryki są kompatybilne, czy dałoby się właśnie w taki sposób, niewielkim wysiłkiem przenieść do takiej domeny cyfrowej.
Narzędzia eleketroniczne
Kolejną formą narzędzi do generowania i śledzenia metryk są narzędzia elektroniczne. Pewnym standardem w naszej branży IT, ale nie tylko, jest oczywiście sławna-niesławna Jira. Powiedziałem standardem, a nie złotym standardem, narzędzie rozwijane od wielu lat przez australijskiego (czy już teraz globalnego) Atlassiana, które występuje w dwóch rodzajach: w wersji serwerowej, to jest wersja, którą deweloper już zapowiedział, że porzuci po jakimś czasie, ale ona cały czas występuje w bardzo wielu organizacjach, oraz w wersji chmurowej. Zastanówmy się, co można zrobić, jeżeli jesteśmy w tym pierwszym scenariuszu ,a więc mamy narzędzie Jira, śledzimy w nim pracę, mamy włączony tam tak zwany Kanban board i chcielibyśmy z niego w automatyczny sposób wygenerować metryki. Sytuacja jest bardzo prosta: otóż jeśli w naszej firmie możemy użyć przeglądarki internetowej Google Chrome, a więc nie pod kątem bezpieczeństwa i możemy takiej przeglądarki używać, mam wrażenie, że to już jest w bardzo wielu firmach i możemy zainstalować do niej te aplikacje, te dodatki, to warto poszukać takiego dodatku, który nazywa się Jira Flow Companion. Jira Flow Companion jest dodatkiem bezpłatnym, jest dodatkiem właśnie dla osób, które używają wizualizacji pracy za pomocą tablicy Kanban w Jirze serwerowej i naprawdę za pomocą kilku magicznych kliknięć jesteśmy w stanie sobie wygenerować takie metryki, jak histogram czasów realizacji za określony okres, jak właśnie throuhput, jak kilka innych pomocnych metryk. Polecam, żeby to narzędzie przeklikać, ono nie jest naprawdę skomplikowane, cały interfejs jest taki naprawdę intuicyjny ostatnio (tutaj pozdrowienia dla zespołu) w trakcie SDR-u ktoś powiedział: „A może nacisnąć hide all subtasks?”. Więc możemy ukryć te popularne subtaski. Właśnie w świetle tego, co powiedziałem przed kilkoma minutami subtaski to są te zadania, których właściwie czas życia i przepływ nas tak bardzo nie interesuje, a przynajmniej nie są to pierwszego rzutu elementy, bardziej nas interesują bug fixy, te historyjki. Subtaski to jest właściwie troszkę taki zwykle szum, chociaż oczywiście tym subtaskom też warto poświęcić na którymś etapie być może uwagę, jeżeli tam znajdziemy pogrzebanego diabła, jak się mówi w przysłowiu. Oczywiście ta praca na subtaskach może powodować jakieś niepożądane zachowania czy elementy pracy mogą płynąć z powodu właśnie subtasków wolniej. Jira Flow Companion – polecam naprawdę bardzo fajna sprawa dla tych z Was, którzy chcą właśnie użyć w sposób prosty, zautomatyzowany danych z Jiry serwerowej. Jeżeli jesteśmy już przy tej Jirze serwerowej, to warto powiedzieć, że oczywiście istnieje cały Atlassian marketplace, a więc rynek takich pluginów do samej Jiry i tutaj trzeba sobie powiedzieć o kilku ograniczeniach. Po pierwsze instalacja takich pluginów będzie wymagała globalnych praw administratora. Jeżeli tego nie macie lub w Waszej firmie istnieje jakiś bardzo trudny proces walidacji oceny instalacji, to być może tu będziecie musieli się trochę nad tym wysilić, żeby to uzyskać. Z drugiej strony duża część tych pluginów, o których mówimy, czy w ogóle produktów w Marketplace, jest po prostu produktami płatnymi. Kilkoma takimi pluginami, o których warto powiedzieć jest na pewno Swiftly – jest to plugin, który jest pochodną można powiedzieć narzędzia Swift Kanban, takiego niezależnego narzędzia do organizacji pracy. Deweloper stojący za Swift Kanban tworzył taki plugin, który nazywa się Swiftly i ten plugin właśnie w sposób zautomatyzowany generuje nam metryki, które, nie oszukujmy się – w Jirze nie należą tak automatycznie do dobrze zwizualizowanych, dobrze zorganizowanych. Tu właściwie trochę pominąłem to, dlaczego nie używamy tych, które są wbudowane w narzędzie bezpośrednio i to jest trochę taka ironia, bo to jest narzędzie głównie: największym rynkiem są zespoły i czy organizacje IT budujące cyfrowe produkty, to narzędzie takie jak Jira zostało stworzone przez organizację tego samego pokroju. Ktoś nam zgotował los taki, a nie inny. Nie oszukując się – pewne wykresy w Jirze domyślnie dostępne są albo bezużyteczne, albo bezużyteczny w dłuższej skali, dlatego że im więcej będziemy mieli punktów danych, tym trudniej będzie z nich korzystać. O takich konkretnych metrykach przepływu niestety wręcz nie ma w ogóle mowy. Ale wracając do tych produktów, których możemy użyć, poza Swiftly, jeszcze takim produktem, o którym warto pomyśleć jest Actionable Agile – to również jest plugin płatny, który będzie używał chociażby takiej nomenklatury cycle time zamiast lead time, może nie najpiękniejszy graficznie, ale też będziemy w stanie przy jego pomocy wygenerować pomocne dla nas metryki, właśnie takie jak , właśnie takie jak scatter plot, również takie informacje jak WIP age. Co dalej? Pozostaje jeszcze, dla osób, które są osadzone w tych wersjach serwerowych, opcja eksportu danych, a więc możemy wyeksportować plik, który będzie zawierał jakąś, nawet często zanonimizowaną, informacje o ticketach, o tych zadaniach, które mamy. Mówię tu zanonimizowany, bo też pewna część organizacji będzie bardzo czuła na to, żebyśmy nie eksportowali danych poufnych, co jest zupełnie zrozumiałe i będziemy mogli takie dane poddać obróbce w narzędziu zewnętrznym. O tym za moment opowiem opowiadając o narzędziu dla Jiry chmurowej, ale oczywiście ci z Was, którzy są w jaki sposób magikami Excela lub podobnych narzędzi mogą sobie próbować te dane w ten sposób obrabiać, natomiast oczywiście minusem jest to, że aktualizacja takich danych, przynajmniej w taki prosty sposób ręcznego eksportu, będzie wymagała ręcznego eksportu i przerabiania tych danych za każdym razem ręcznie i osobno.
Co dalej? Idziemy w chmurę. Zbliżamy się więc do narzędzi chmurowych. Pierwszym narzędziem chmurowym, o którym opowiem jest…? Oczywiście – Jira. Ci z Was, którzy mają szczęście pracować w organizacjach, które już zmigrowały swoją Jirę, czy może od początku pracowały w Jirze chmurowej wiedzą, że tam różnego rodzaju instalacja jest może łatwiejsza, czasami plany taryfowe są trochę bardziej korzystne, jeżeli chodzi o ceny tych pluginów, ale również będziemy musieli raczej posiadać globalne prawa administratora, żeby takie pluginy (to się nazywa addony – w języku Atlassiana) zainstalować i tu właściwie wybór mamy bardzo podobny, a więc znów wchodzi Actionable Agile, jeżeli chodzi o taką aplikację, którą możemy podłączyć.
Natomiast możemy też skorzystać z aplikacji, które są po prostu połączone z naszą Jirą chmurową. I tutaj będę mówił o narzędziu, które, z mojego doświadczenia, jest najbardziej elastyczne i najfajniejsze zarówno graficznie, jak i pod kątem tego, co możemy wygenerować z tego narzędzia – z Jiry – jest to narzędzie Get Nave. Get Nave jest narzędziem chmurowym, które podłącza się do narzędzi chmurowych, a więc do wspomnianej tutaj Jiry, po autoryzacji w panelu Get Nave (strona internetowa się nazywa Get Nave), w panelu Nave jesteśmy w stanie wygenerować sobie w czasie rzeczywistym aktualizowane dane, które będą bardzo fajnie wizualizowanie, będziemy mieli tutaj właśnie delivery rate, throughput, scatterploty, WIP age, będziemy mieli też możliwość wykorzystania Monte Carlo – techniki prognozowania statystycznego do tego, żeby określić np. na kiedy nasz projekt, przy określonej liczbie utworzonych elementów, może być „dowożalny” biorąc pod uwagę obecne tempo dostarczania i oczywiście tutaj też możemy pewnego rodzaju dane zmienić, a żeby pokazać, jak to będzie wyglądało w takich scenariuszach pozytywnych, negatywnych zakładając jakieś konkretne zmiany czynników, na podstawie których ten model powstaje. Bardzo fajnie narzędzie, do niego również możemy zaimportować plik wyeksportowany z innej Jiry, a więc będziemy mieli możliwość tylko, żeby zrobić to ręcznie, natomiast najwygodniejsze jest po prostu połączenie dwóch narzędzi chmurowych. Tutaj jest bardzo ciekawa sprawa – Nave generuje te metryki w oparciu o konkretną tablicę kanbanową w Jirze. Tutaj koszt licencji jest związany z tym, ile mamy dashboardów niż z tym, ilu mamy na przykład użytkowników w Jirze, co, jak wiemy, jest raczej dla dużych organizacji niekorzystne, bo płacimy za to że mamy 1000 czy 2000 użytkowników, a samego pluginu używać będzie kilka czy kilkanaście osób. Więc w tym przypadku Nave jest najbardziej elastyczny.
Narzędzia chmurowe
Co dalej? Idziemy w stronę narzędzi chmurowych, równie popularnych, na pewno drugim wyborem, który widzę w organizacjach zwłaszcza tych które mają się za pan brat z produktami Microsoftu, jest Azure DevOps. Niektórzy pewnie kojarzą bardzo podobny produkt jako Team Foundation Server (TFS). Azure DevOps jest narzędziem chmurowym i w tym narzędziu metryki takie out-of-the-box, a więc takie które dostajemy w tym narzędziu (jeśli jest prawidłowo skonfigurowane) są na pewno lepsze – ja oceniłbym je jako lepszy od tego, co oferuje Jira – natomiast to tego narzędzia również jesteśmy w stanie podłączyć wspomniany tutaj Nave i również uzyskać taki Dashboard w zewnętrznym narzędziu chmurowym w czasie rzeczywistym. Do tego Azur DevOps również jesteśmy w stanie podłączyć wspomniany wcześniej Actionable Agile, a więc mamy tutaj wybór. To są narzędzia komercyjne o różnym profilu tych planów taryfowych – o tym nie opowiadam, bo to nie jest reklama konkretnego produktu, tu po prostu przechodzimy przez spektrum wszystkich narzędzi, które naprawdę są w tym obszarze najpopularniejsze i dostępne. Idąc dalej, poza Azure DevOps mamy takie narzędzia, które czasami są adoptowane na poziomie zespołów, które mają dużą swobodę, małych firm, a więc Asana czy Trello (tutaj pewnie byłby duży spór o tym, czy Asana i Trello są narzędziami kanbanowymi, ale na pewno możemy zbudować nich taką tablicę, która będzie nam pokazywała te zadania i ten przepływ pracy), do tych narzędzi istnieją różnego rodzaju power upy w Trello czy dodatki w Asanie, ale znowu te dwa narzędzia jesteśmy w stanie podłączyć do Nave’a i również w czasie rzeczywistym generować sobie takie metryki. A więc nawet ci z Was, którzy używają takich prostszych murowych narzędzi również mogą z takich metryk skorzystać.
Narzędzia klasy Business Intelligence
Możecie zastanawiać się – co jeszcze zostało? Omówiliśmy sobie te narzędzie miękkie, do ręcznej roboty, omówiliśmy sobie narzędzia bezpłatne jak Jira Flow Companion, czy też komercyjne dostępne jako dodatki do tych narzędzi komercyjnych, bo, nie oszukujmy się, za takie narzędzia jak Azure DevOps czy Jirę nasze organizacje płacą grube tysiące euro czy dolarów rocznie, a my i tak nie dostajemy tego, co nam naprawdę pomaga w tej pracy a więc tych metryk. Natomiast jeżeli jesteśmy w organizacji, w której mamy takie narzędzia czy to serwerowe, czy to chmurowe i mamy ludzi, którzy zajmują się czy jakąś analityką danych, a więc tutaj wszelkiego rodzaju departamenty analityków big data, portingu, to są zwykle takie miejsca, w których do narzędziownika naszych firm należą takie naprawdę kombajny do przetwarzania i wizualizacji danych. Ja opowiem o dwóch: Tableau i PowerBI. Z wykorzystaniem tych dwóch narzędzi przy odrobinie naprawdę wiedzy skryptowej jesteśmy w stanie te narzędzia podłączyć do tych naszych narzędzi śledzenia, organizacji pracy, takich projektowych i wygenerować te metryki, o których mówimy korzystając wręcz z gotowych wzorców typów wykresów, które są dostępne w takim Tableau czy PowerBI – z nich Jesteśmy w stanie zbudować cały dashboard, a więc jakąś tablicę i oczywiście tutaj znów nie ma mowy o jakimś ręcznym eksporcie i imporcie tych danych, tylko mamy to dostępne w czasie rzeczywistym. Jest to rozwiązanie, które pojawiło się u kilku moich klientów. Wiem, że duże, , które zwykle mają właśnie zaplecze takich specjalistów ale też mniejsze organizacje, które widzą w tym można powiedzieć elastyczność tego, jak dashboardy, jak te metryki też ewoluują, inwestują trochę czasu w to, żeby właśnie osoby z obszarów typu Business Intelligence pomogły product ownerom, zespołom deweloperskim, działom marketingu, przeróżnym interesariuszom tych dashboardów budować w ten sposób różnego rodzaju widoki, metryki i powiem, że jest to oczywiście pewnie patrząc na tej skali trudności bo w przypadku takich narzędzi typu Miro mural jesteśmy raczej niezależni w przypadku tych narzędzi o których mówiłem pośrodku odcinka, a pewnie problemem może być prawo administratora czy jakieś bardzo restrykcyjne polityki security, które będą stały na drodze łączenia dwóch narzędzi chmurowych, tutaj mamy przede wszystkim to bezpieczeństwo, ponieważ trzymamy te rzeczy raczej u siebie, z drugiej strony jesteśmy najbardziej elastyczni, ponieważ rzeczywiście budujemy te wykresy w taki sposób i śledzimy te metryki w taki sposób, w który one są nam pomocne. Chcę powiedzieć o jeszcze jednej rzeczy: co do budowania wykresów, co do używania różnego rodzaju metryk, to oczywiście powstaje, pojawia się na horyzoncie taki problem, że możemy zakupić nawet narzędzie komercyjne, budować przy jego pomocy jakieś wykresy, ale okaże się niestety, że te wykresy nie będą takie fajne dlatego, że pewna część danych w nich występujących będzie nam zakłamywała obraz tego, jako nasza praca płynie czy nie płynie, czy w ogóle kształtuje się w rzeczywistości. O czym mowa? O prostej zasadzie: trash in – trash out. A więc jeśli niestety takie narzędzie „nakarmimy” śmieciowymi danymi, na których nie jesteśmy w stanie polegać, bo wiemy że ta data nie jest prawdziwa, bo wiemy, że ten ticket zawracał kilka razy w ciągu twojego życia po tablicy, a jako czas rozpoczęcia się liczy tylko ten pierwszy i tak dalej, to niestety to wszystko pojawi się na naszym wykresie czy wykresach objawiając się w taki sposób: fajnie by było, gdybyśmy rzeczywiście mogli na tych wykresach polegać, ale teraz mamy tutaj obliczoną jakąś statystykę, na przykład percentyl 85 czasów realizacji, ale widzimy, że jest zakłamany bardzo mocno przez dwa punkty. I co teraz? Mówię o tym właśnie w tym podrozdziale poświęconym takim narzędziem, jak Tableau czy Power BI, ponieważ tutaj pojawia się pewna elastyczność, co do czegoś co mój kolega i współpracownik nazywa „masażem danych”. A więc jeżeli uznajemy, że te dane wyciągnięte surowo z narzędzia są niewłaściwe, to możemy na przykład ręcznie taki punkt danych usunąć z takiej metryczkach. W Tableau mamy taką możliwość, żeby tam potrzymać dłużej kursor, zrobić exclude i ten punkt znika, nie jest brany do tej populacji, widzimy te czasy realizacji o wiele lepiej skorygowane. Oczywiście musimy być bardzo ostrożni, żeby nie pozbywać się tych niewygodnych przypadków i mówić: to się tutaj nigdy więcej nie powtórzy taki długi lead time, natomiast jeżeli ten lead time jest taki długi w wyniku błędu dokonanego ileś miesięcy wstecz i nie jesteśmy w stanie go skorygować bez ingerencji w bazy danych narzędzia, z którego w ogóle to wyciągamy, to rzeczywiście mamy tutaj pewną możliwość korekty. Idąc dalej możemy tutaj w ogóle pomyśleć o tym, jakie dane są zaciągane z tych narzędzi. Tutaj dużo o tym opowiadam chociażby właśnie na szkoleniach Kanban System Improvement, gdzie pokazuję też przykłady, jak czasami znajdujemy pewnego rodzaju work aroundy na te problemy, obejścia, ale to już jest coś, co na pewno wymaga bardzo dobrej wizualizacji i żywych przykładów, ale nie chcę tutaj opowiadać konkretnych historii i wykresów, a bardziej zachęcić Was do tego, żeby pomyśleć, czy właśnie taka naprawdę najbardziej elastyczna siła sprawcza, jeżeli chodzi o metryki nie tkwi albo w Waszej organizacji, albo wręcz w zespole, bo mamy osobę, która rzeczywiście potrafi na przykład takie dane z API, z interfejsów tych narzędzi komercyjnych wyciągać i wizualizować.
Co dalej? Pamiętajmy: nie myślmy narzędziami, myślmy o tym, żeby te metryki i wykresy, które śledzimy pomagały nam podejmować decyzje. Oczywiście fajnie, kiedy one są automatycznie, jeśli są możliwe do korekty i kiedy są w sposób ciągły śledzone oraz kiedy możemy odtworzyć historię, natomiast pamiętajmy, że liczy się, co z tym zrobimy. Żebyśmy nie popadli w takie zakochanie w pięknych narzędziach, bo wiemy, że to staje się celem samym w sobie, a bardzo często właśnie, wracając do tych pierwszych sposobów wyliczenia tych metryk, tak na dobrą sprawę powiedziałbym: myśląc iteracyjnie, myśląc inkrementalnie, co Wam jako słuchaczom i słuchaczkom podcastu pewnie nie jest obce, a więc tym duchu zwinności, pomyślmy o tym, co jest takim NVP, co jest takim wystarczająco dobrym podejściem, jeżeli chodzi o te metryki na kilka pierwszych iteracji czy na jakieś pierwszym, może nie najdłuższy, ale jednak okres, w którym możemy już jakieś informacje uzyskiwać i na ich podstawie jakieś recenzję podejmować.
Podsumowanie
Zapraszam serdecznie do komentowania: jestem ciekaw, czy Wy używacie jakichś innych narzędzi, jeżeli tak, to się , być może macie jakieś specjalne combo jakiegoś narzędzia z czymś, czego dziś nie wymieniłem. Oczywiście takie narzędzia się pojawiają. Zupełnie innym aspektem są narzędzia, które są z definicji stworzone do pracy właśnie w metodzie Kanban, gdzie nie będziemy nie będziemy mieli ograniczenia, które występuje w narzędziach, w których Kanban jest rozumiany tylko jako jakaś tablica, ale niekoniecznie bardzo customize’owalna, niekoniecznie, taka do której jesteśmy w stanie, czy z której jesteśmy w stanie wydobyć takie bardzo kanbanowe metryki. Dajcie znać, jestem ciekaw waszych połączeń. W przyszłości będziemy pochylać się jeszcze nad sama wizualizacją danych, ale to taka mała zapowiedź na przyszłość. Dziękuję wam przeczytanie transkrypcji podcastu. Tradycyjna prośba o to, jeśli są tutaj rzeczy ciekawe, dajcie znać: czy w postaci jakiegoś komentarza, czy feedbacku na mediach społecznościowych Zapraszam też do podzielenia się tym podcastem z innymi – wystarczy że wyślecie po prostu taki wpis na swojego walla czy go tam polubicie. Zapraszam też do podzielenia się opinią na platformach, na których ten podcast jest dostępny.
Dziękuję!