Witam Was w podcaście Zwinnej Kawy, w którym rozmawiamy o zwinności w biznesie i nie tylko. Dzisiaj gościem odcinka jest Paweł Lewiński.
Cześć, Paweł.
Cześć, witam serdecznie.
Chciałem cię poprosić, żebyś się na początku przedstawił i powiedział trochę naszym słuchaczom o sobie, czym, się zajmujesz, jaki jest twój background.
Nazywam się Paweł Lewiński, jestem Scrum Masterem i na co dzień w Software House pomagam zespołom w optymalny sposób realizować potrzeby klientów i tworzyć produkty.
Ale bycie Scrum Masterem to nie jest jedyna rzecz, którą się zajmujesz, bo masz jeszcze działalność po godzinach. Może nie jak Batman, gdzieś tam w masce, w pelerynie, ale są jeszcze inicjatywy, którymi się zajmowałeś, i takie, którymi się zajmujesz obecnie w swoim wolnym czasie, prawda?
Zawsze bardzo chętnie. Lubię to robić i dzielę się wiedzą. W związku z tym jeżeli chodzi o tematyki zwinnościowe, agile’owe i scrum masterskie, to jakiś czas temu założyłem z kolegą Marcinem taki portal agilelabs.pl – miejsce zwinnych eksperymentów, gdzie właśnie dzielimy się wiedzą i naszymi doświadczeniami związanymi z tym, w jaki sposób bawić się, eksperymentować, próbować w zakresie technik, narzędzi, play worków, z którymi się spotykamy i w ramach tego tworzymy różne ciekawe dodatkowe materiały, którymi też się dzielimy, a ostatnio zrobiliśmy nawet coś unikalnego, myślę, że na skalę światową.
O, to co takiego, jeśli możesz się pochwalić?
Tak, mogę, czekałem, aż zapytasz, bo chciałem napięcie zbudować w ten sposób. Stworzyliśmy kurs metryk procesowych, jeżeli chodzi o podejście zwinne w wytwarzaniu oprogramowania. Z mojej wiedzy wynika, że takich kursów jest bardzo niewiele na świecie, może ze dwa albo trzy, tak że nasz jest pod tym kątem unikalny. I jest po polsku. Jest takim całościowym zebraniem informacji związanych z używaniem, rozumieniem i wykorzystywaniem metryk, czyli tej esencji zwinności w zakresie empirycznego podejścia do pracy.
No właśnie, bo to jest temat, o którym mam wrażenie, że się mówi dość rzadko. Z mojej perspektywy i w mojej karierze dużo się mówiło o filozofii, która się wiąże ze zwinnością. Bo to jest bardzo fajny, chodliwy temat, mówiło się często o dowożeniu, o niedowożeniu itd., natomiast nigdy się nie spotkałem z jakimś kompleksowym rozwiązaniem poświęconym metrykom. To może powiedz, jakie są te metryki? Bo mamy to nasze osławione Velocity, które często jest używane przeciwko zespołom – to może być jedna z tych metryk. Chyba że myślę zupełnie nie w tę stronę, więc gdybyś mógł to rozwinąć.
Metryka Velocity – jeżeli jest używana – to rzeczywiście jest to taka najbardziej popularna z metryk. Wynika to z tego, że najbardziej popularnym sposobem estymowania rzeczy, które chcemy robić, są story pointy. I tutaj taka ciekawa obserwacja, że te story pointy, i w związku z tym Planning Poker, Velocity są bardzo mocno utożsamiane ze zwinnością i ze Scrumem. I często obserwuję takie utożsamienie tych dwóch rzeczy, że jeśli Scrum, to znaczy, że robimy w Story Pointach i patrzymy na Velocity.
Natomiast w Scrumie nie ma czegoś takiego nawet jak story pointy, w związku z tym powinno to być traktowane tylko jako narzędzie dodatkowe, którego potencjalnie można użyć. Natomiast jak zacząłem się tym interesować i wokół tego krążyć, to okazało się, że jest to megafascynujący temat odnośnie do samych story pointów; że to nie jest tak do końca. Plus użycie bardziej twardych danych, nieopartych na w pewien sposób subiektywnej ocenie osób, ale w przeliczeniu na story pointy. Jest dużo prostsze, efektywniejsze i dużo bogatsze – jeżeli chodzi o zastosowanie w projektach – i dzięki temu możemy więcej i lepiej zobaczyć: jak nasze procesy pracują, jak one wyglądają, co się tam dzieje. A jak to zobaczymy, to jesteśmy w stanie to pokazać, porozmawiać o tym i potencjalnie coś z tym zrobić.
Tak że jest to bardzo duża zaleta: zobaczyć, jak to działa. Np. bardzo lubię, jak wchodzę do projektu, który już działa. Niedawno też miałem taką sytuację, kiedy już był projekt i każdy miał jakąś opinię, że ten projekt idzie tak, albo inaczej, i tymi opiniami każdy się chętnie dzielił. Natomiast takie spojrzenie na twarde dane, jak ten proces jako całość jest ułożony i jak przebiega, bardzo ładnie pokazywało, co tak naprawdę się dzieje w sposób obiektywny. I to jest bardzo fajne narzędzie, które można do tego wykorzystać. I jeszcze tylko taka jedna uwaga, bo wspominałeś o Velocity używanym przeciwko zespołom: metryki też mogą być używane, i niestety często są, natomiast tak absolutnie nie powinno być. Te metryki nigdy nie mogą służyć do tego, żeby używać ich przeciwko osobom czy zespołom; to jest zupełnie inny cel.
Wszystko to kwestia, kto z nich korzysta. Bo wypaczyć można każde, nawet najfajniejsze narzędzie i jeśli wchodzisz do zespołu, rozmawiasz z ludźmi, słyszysz, że idzie dobrze lub źle, że jet dowożone, albo że nie jest dowożone, że jakość jest taka, śmaka, owaka. I to też jest rzecz, z którą się już wszyscy chyba zetknęliśmy w tej branży, ile ludzi, tyle opinii, a jak chcemy podejmować decyzje, to one powinny być jednak oparte o fakty, o dane, wtedy będą prawdopodobnie lepsze. Kwestia tego, co to znaczy lepsze, ale powiedz mi, na jakie metryki ty patrzysz poza Velocity i obiektywne story pointy, mendeje, cokolwiek. W jakiś sposób zawsze mierzymy tempo naszego dostarczenia i jakie kawałki pracy będziemy w stanie dostarczać klientom, bo to jest taki naturalny odruch, zarówno klientów, jak i nas samych, żeby trochę wiedzieć o sobie więcej. Ale powiedz mi, na co ty jeszcze zwracasz uwagę?
Za chwilę powiem, na co jeszcze zwracam uwagę, i w ogóle jakich metod używam w projektach, natomiast jeszcze chciałem rozwinąć to, co powiedziałeś, jak o temacie się niewiele mówi, i to jest też moja obserwacja, wynikająca właśnie z tego, że te wszystkie tematy, nawet nie rozróżniając ich na miękkie i twarde, ale te tematy związane z „jak tu zrobić, żeby było miło”, „porozmawiajmy, jak się czujemy” itd., one też jak najbardziej są ważne w życiu zespołu. Natomiast te tematy związane z metrykami wymagają może nie tyle matematycznego, bo ja też nie jestem matematykiem ani statystykiem, ale gdzieś rzeczywiście, mimo że są w centrum tego Scruma np., gdzie ten empiryzm powinien być na piedestale i na pierwszym miejscu, to te inne dookoła rzeczy, tak jak je opisałeś i określiłeś (każdy na pewno jak się rozejrzy, to takie rzeczy znajdzie dookoła) jednak grają pierwsze skrzypce. I wynika to prawdopodobnie z tego, że tak czy inaczej, jest jakaś tam bariera wejścia. Ja sam tę drogę też przeszedłem, jeżeli chodzi o poznanie metryk. I tak jak mówiłem, nie jestem matematykiem czy statystykiem, nie jestem nawet byłym deweloperem, ten próg wejścia jest wysoki i tak zakładam, że może to z tego wynikać, że nie jest to tak popularny temat niestety, jak powinien być. Natomiast przez to tracimy możliwość używania tego narzędzia do optymalizacji, do wsparcia zespołów, do poprawy.
I wracając już bezpośrednio do pytania odnośnie do pracy w zespołach, to pierwsze trzeba zacząć od takich metryk kanonicznych, nazwijmy je tak. One się wywodzą trochę z Kanbana, ale z powodzeniem można je stosować również w Scrumie, czyli tak naprawdę w każdym systemie pracy. I to, co jest istotne, to że one nam pokazują cały system pracy, jakkolwiek on jest zdefiniowany. Czyli pokazują nam nie pracę poszczególnych osób, tam też to można zobaczyć, ale pokazują cały system, jak on działa, co się tam w środku dzieje. To też jest bardzo duża zaleta, którą sobie cenię. I jeżeli chodzi o te rzeczy, takie kanoniczne, których używam w projektach, to jest to przepustowość tego systemu. Czyli ile rzeczy przepływa przez nasz system pracy, i to obojętnie czy w Scrumie czy w Kanbanie.
Ale rzecz rzeczy nierówna więc znowu, musisz o jakieś uśrednianie się pokusić, prawda? Bo story pointy, czy jakakolwiek estymacja, nie powiem, że miały działać przeciwko takiemu podejściu, ale miały służyć do tego, żebyśmy wiedzieli, ile jest mniej więcej pracy. Bo w kwestii ile rzeczy, to mówię, te rzeczy powinny być w miarę podobne do siebie, żebyśmy mogli je liczyć. Chyba że ja tu błądzę trochę.
Nie błądzisz, ale tak, jest takie przekonanie, że żeby używać np. przepustowości, to rzeczy powinny być takie same. One nie powinny być takie same. Jeżeli chcemy, to dobrze jest jeżeli są zbliżonej wielkości, ale tak na koniec dnia się okazuje, że to nie ma znaczenia, ponieważ statystycznie rzecz biorąc, jedna rzecz będzie mniejsza, inna będzie większa, jedna potrwa trochę dłużej, inna trochę krócej. I patrząc całościowo, ten system w jakiś sposób te rzeczy przetrawi, przemieli; czy też one w jakiś sposób przez tę pracę przepłyną.
To, co jest też ważne i co pokazuje teoria, to że wielkość rzeczy nie ma aż takiego wielkiego znaczenia, ponieważ to, co jest istotniejsze, to są ryzyka związane z tym, co się w tych zadaniach znajduje, albo które mogą się uzewnętrznić. Bo może być jakaś mała rzecz, ale z dużym ryzykiem, i będziemy ją i tak robić dłużej. I to ma bardzo duży wpływ na to, jak szybko rzeczy rzeczywiście przepływają przez nasz system pracy. W związku z tym nie powinniśmy się ograniczać, mówić: „Nie, nie, nie róbmy tego, bo nie mamy identycznie takich samych rzeczy”. To nie ma znaczenia tak naprawdę. To jest bardzo nieintuicyjne, ale tak jest. Jeżeli ktoś się będzie z tym czuł lepiej i to np. No Estimates proponuje, Vasco Duarte’a, żeby po prostu zweryfikować sobie rzeczy bardzo szybko, czy to jest rzecz, którą uważamy, że zajmie nam np. mniej niż 2 tygodnie jeśli mamy jakiś 2-tygodniowy sprint, czy tam jakąkolwiek inną miarę sobie będziemy przykładać. I tyle, i to jesteśmy w stanie dosyć szybko zrobić, bez story pointów tak naprawdę, i wtedy ewentualnie to podzielić, ale też bez zbytniego zagłębiania się.
Istotne jest też to, że bardzo często, gdy będziemy o czymś dyskutować, bardzo wielu rzeczy nie wiemy. Tak czy inaczej, nasza praca nad oprogramowaniem jest pracą twórczą. I nawet jeśli robimy któryś raz z kolei tą samą albo podobną funkcjonalność, to zawsze jakiś kontekst może być inny. Zawsze coś się może wydarzyć. Nieskończona liczba scenariuszy.
Gdzieś w tym wszystkim mamy ten mityczny biznes. I mam wrażenie, że z kim by się nie rozmawiało, to ten biznes jest zawsze ten krok dalej, niż miejsce, w którym jesteśmy. Ale oni jednak chcą dostać na koniec określony efekt. Ich może nie zawsze interesować, że to jest proces twórczy, albo nie do końca rozumieją, jak przebiega ten proces twórczy, że są pewne zmienne czynniki, że nawet oni czasami są tym zmiennym czynnikiem. Nadal chcemy być przewidywalni. Finalnie wszyscy chcą, żeby zespół, w którym pracujemy, był przewidywalny, żeby zobowiązywał się do dostarczenia pewnej wartości, pewnego efektu – i faktycznie temu zobowiązaniu później sprostał. Wszystkie te metryki chyba służą finalnie tylko temu. Jesteśmy tu po to, żeby wykonać pracę, dostarczyć pewną wartość naszym klientom.
To jest dobry przykład, tego typu, że biznes na koniec dnia właśnie chce wiedzieć „na kiedy”. Jest taki warsztat, który czasami prowadzę: „Czy story pointy są jak lotnisko w Radomiu?”, gdzie rozmawiamy właśnie o tym, że te story ponity są takie popularne. Natomiast jeden z elementów, który ja obserwuję, to jest takie przeliczanie. Ludzie i tak myślą w godzinach, jeżeli nawet jest jakaś dyskusja. Później przeliczają to na story pointy, a na koniec dnia i tak te story pointy są znów przeliczane na czas: czy to w postaci „ile się zmieści w sprincie”, czyli tak naprawdę też funkcja czasu, albo np. „na kiedy coś tam będzie dostarczone”.
Jezu, ile ja się Exelli już natworzyłem, które robią te kalkulacje. Bo zawsze był jakiś menedżer gdzieś tam w firmie, który prosił o coś takiego, a ludzie chodzą na urlopy, i skąd wiedzieć ile mamy story pointów w sierpniu albo we wrześniu, jak ludzie będą na urlopach. Finalnie prawdopodobnie dostarczymy trochę mniej, bo mamy mniejszą moc przerobową, więc to się w jakiś sposób przeskaluje. Ale ludzie chcą wiedzieć od razu i mam wrażenie, że nawet ten biznes czasami zapomina i że on chce określoną wartość i zaczyna się koncentrować na tym „ile?”, „na kiedy to będzie?”. A „co będzie?”, to już może nie do końca ważne, prawda?
Przede wszystkim problematyczne jest to, że bardzo często ta rozmowa wygląda właśnie tak, że z jednej strony my jesteśmy ci dobrzy, a tamci są ci źli. My coś chcemy, a oni nam nie chcą dać, albo odwrotnie. A to do niczego nie prowadzi, bo później właśnie będzie taki ping-pong: „A na ile obiecacie, że to zrobicie?”, „Na kiedy?” – „No na wtedy”. „Dajcie mi datę”. No to jakaś data się pojawia. Później ten termin jest niedotrzymany i się zaczyna: „Obiecaliście. Jesteście inżynierami, powinniście wiedzieć, ile to zajmie”. Tak czy inaczej, to odbieranie, to jest właśnie taka moja teoria, że my jesteśmy inżynierami i powinniśmy wiedzieć, ile coś zajmuje, właśnie ma jakieś zastosowanie do takich prac inżynieryjnych w dotychczasowym rozumieniu przemysłu. Natomiast prawda jest też taka, że nawet prace inżynieryjne czy większość projektów, mimo że są przeliczone, przekosztorysowane i do ostatniej śrubki policzone, to na koniec dnia się okazuje, że i tak coś się przedłuża.
I tu przykłady można mnożyć. By nie wskazywać placem, lotnisko w Berlinie, które już nie wiem, ile lat jest po terminie i nie wiem, ile setek milinów, jeżeli nie miliardów euro ponad zaplanowany budżet. Tak najzwyczajniej w świecie jest, natomiast bardzo ciężko jest o tym pamiętać i wziąć to pod uwagę, a ten aspekt pracy twórczej jest bardzo istotny. W związku z tym to przeliczanie się odbywa, niestety, natomiast używanie metryk w postaci np. przepustowości pozwala nam uzyskać ten sam efekt informacyjny, dodatkowo zobaczyć, w jaki sposób nasz system działa tak naprawdę, co się w nim w środku dzieje, i podjąć jakieś działania, czy eksperymenty związane z tym, żeby go w jakiś sposób usprawnić, polepszyć i znów zobaczyć na danych, jaki te eksperymenty przyniosły efekt, jeżeli chodzi o dostarczanie.
I tu nie mówię tylko na zasadzie takiej, że jak będziemy dostarczać więcej historyjek, to znaczy, że lepiej, bo dostarczamy więcej, znaczy szybciej. Bo tutaj ta wartość biznesowa czy jakość itd., to wszystko ma znaczenie. Tak że sama szybkość dostarczania jest z mojego punktu widzenia mniej istotna, czyli nie powinna być tym głównym obszarem rozmowy.
To nie jest taśma produkcyjna. My nie mamy wypluć tysiąca jednostek na koniec jakiegoś tam okresu, nie wiem, godziny, dnia, tygodnia, miesiąca, tylko mamy tę wartość biznesową, którą też w jakiś sposób można mierzyć. Nie wiem, czy to jest kolejna metodyka, której dotykacie, czy nie?
Wartość biznesowa akurat już nie wchodzi w zakres takich metryk procesowych – bo tutaj się koncentrujemy na procesie – natomiast istotne jest to, że właśnie przy użyciu tych metryk można z biznesem rozmawiać i na podstawie tych metryk również można używać prognozowania statystycznego. To tak brzmi może: „Ojejku, teraz wjedzie tutaj statystyka”, a statystyka nie była ulubionym przedmiotem w szkole…
Robi się poważnie.
I to, co mówiliśmy wcześniej, że to dlatego może nie jest takie popularne. Natomiast tak naprawdę to jest fantastyczna rzecz, która działa – najzwyczajniej w świecie. Ponieważ przede wszystkim pokazuje nam potencjalne np. zakończenie jakiegoś projektu czy realizacji jakichś zadań, również z określeniem prawdopodobieństwa, z jakim to się wydarzy. Tak że mamy silne podstawy do tego, czy mamy jakieś założenia, jakieś dane historyczne, i na tej podstawie jesteśmy w stanie przewidzieć (znaczy ten system, model jest w stanie nam pokazać), jakie są potencjalne wyniki działań, które przeprowadzamy i z jakim prawdopodobieństwem będą miały miejsce. I to jest świetne, bo zmienia totalnie optykę takiej rozmowy. „A na kiedy to będzie?”, „No powiedz mi datę, masz mi powiedzieć datę”. Ktoś w końcu przyparty do muru taką datę rzuca. Natomiast tutaj rozmawiamy o zakresie ilości czasu i prawdopodobieństwie, z jakim może się to zadziać.
I taki standardowy przykład rozmowy z biznesem to jest: „Jeżeli chcesz coś wcześniej, spoko, może się to wydarzyć, ale prawdopodobieństwo tego np.zmienia się, czy zmniejsza się o tyle. Czy jesteś w stanie przyjąć, czy zaakceptować ryzyko, które się wiąże np. z jakimiś działaniami, które chcesz podjąć?” I ta rozmowa staje się znów oparta o dane twarde. W ten sposób nasz system w tej chwili działał, do tej pory tak to wyglądało, w związku z tym to my możemy zaproponować i teraz rozmawiajmy o tym, co tutaj zrobić.
I przykład z projektu w ostatnim czasie, gdzie mieliśmy prognozowanie statystyczne, wiedzieliśmy kiedy coś potencjalnie może się zakończyć i w pewnym momencie uznaliśmy, że chcemy ten czas skrócić do kolejnego wydania aplikacji, w związku z tym musimy poprzesuwać rzeczy, które zostały wrzucone na początku, kiedy zaczynaliśmy pracę, czyli: „Chcemy to, to, to i to” Też to chcemy nadal, ale po prostu to musi być przesunięte na kolejne wydanie. I ta rozmowa była bardzo przyjemna, sympatyczna i taka ze zrozumieniem, że nie ma tu magicznych rozwiązań, które w jakiś cudowny sposób zrealizują tę wartość biznesową, którą chcemy zrobić.
I jedna ważna uwaga, że to się różni tym od estymowania – co bardzo chciałem podkreślić – że estymowanie jest obarczone bardzo dużą ilością heurystyk, błędów poznawczych osób czy zespołów, które biorą w tym udział.
Powiedziałbym nawet, że w 100 proc., bo jednak estymują to po prostu ludzie, a tak jak mówisz, błędy poznawcze są trochę podstawą naszego działania, jakby można tak powiedzieć, ten [nz 22:46] jest czymś, co pozwala nam z jednej strony przeżyć i reagować na odpowiednie sytuacje, a z drugiej strony tak naprawdę obarcza niemal każdą decyzję, jaką podejmujemy w życiu. Oczywiście to temat, który moglibyśmy sobie dużo bardziej pogłębić, ale jednak to estymowanie jest ekstremalnie subiektywne. Bardziej się chyba nie da.
Tak, zdecydowanie jest subiektywne, mimo że staramy się, żeby takie nie było. Są historie zespołów, które się np. nauczyły używać story pointów i u nich to działa, i absolutnie nie przeczę, że tak jest, ponieważ każdej metody można się w jakiś sposób nauczyć i używać, jeśli używamy jej dobrze. Natomiast częściej te historie niestety są mniej szczęśliwe i czy używamy story pointów, czy godzin, czy czegoś jeszcze innego, to stety czy niestety, nie mamy na to wpływu; te wszystkie rzeczy działają. Przy modelu tak samo one działają, w sensie, że też jesteśmy podatni na pewne nasze myślenie, natomiast model pozwala nam na to, że po pierwsze jesteśmy w stanie zrobić kilka różnych przeliczeń czy prognoz bardzo szybko, a po drugie ogranicza nas w ten sposób, że eliminuje maksymalnie, jak się da tę subiektywność rzeczy, które robimy.
Tak że takie modelowanie statystyczne to jest coś, co moim zdaniem świetnie działa. Mam na to przykłady ze swoich projektów, gdzie rzeczywiście to model miał rację, kiedy zaczynaliśmy nad czymś pracować. Zrobiłem nawet kiedyś takie porównanie, że padły jakieś tam estymacje, model mówił co innego, i się okazało na koniec, że model był bliższy rzeczywistości.
I jeszcze jedna rzecz, taka zupełnie nieintuicyjna i którą ciężko zaakceptować: Rozpoczynając pracę nad zadaniami, tak naprawdę nigdy nie jesteśmy w stanie przewidzieć, kiedy ta praca nad danym zadaniem się skończy. Cały zbiór zadań, które mamy do zrobienia, wykazuje wszystkie cechy zdarzeń losowych. I to jest już coś, co w ogóle ludzi wytrąca z bezpiecznego samopoczucia, bo my chcemy kontrolować rzeczy, a tu ktoś przychodzi i mówi: „Ale to wszytko jest losowe”. W rzeczywistości tak jest.
Ale powiedz mi, czy spotkałeś się z tym, że ten model jest w stanie dać wam trochę spokoju? Bo tak jak mówisz, my sobie lubimy planować, lubimy kontrolować, to jest też taka jedna z naturalnych ludzkich potrzeb. Model będzie prawdopodobnie tym dokładniejszy, im dłużej on działa. Im więcej ma danych, na bazie których funkcjonuje, prawda? Czy on faktycznie daje wam ten spokój, że w jakiś sposób prorokujecie to, co się będzie działo, bo macie narzędzie, które na podstawie obiektywnych danych, które wy mu dostarczacie, faktycznie coś wam przewiduje? Oczywiście robię z tego jakąś sztuczną inteligencję w tym momencie, ale jednak to jest praca na liczbach finalnie, prawda?
Tak, natomiast ważne, żeby zawsze pamiętać, że to jest tylko model. To nie jest magiczna kula, to nie jest prorok, który mówi: „A teraz słowo się rzekło i tak się stanie” Nie, to tak nie działa. To jest jakiś model, który możemy użyć. Natomiast jeżeli chodzi o ilość danych, to wbrew pozorom, żeby przeprowadzać takie rzeczy, nie musimy mieć nieskończenie dużej ilości danych i nie wiadomo jak długo czekać na to, żeby ten model „nakarmić”. Tak naprawdę można to zrobić mając jakieś założenia, albo dosłownie kilka czy kilkanaście danych historycznych, i to już jest wystarczające. Mnie w szkole tego nie uczono, nie wiem, czy w jakiejkolwiek szkole uczą tego w taki sposób, ale to jest taka ciekawa rzecz, żeby mieć 90-proc. pewność jakiegoś zdarzenia, to wystarczy mieć 11 próbek. Ale jak to, tylko 11 punktów? 11 obserwacji? Tylko 11 skończonych zadań, żeby już wiedzieć, jak system działa? Okazuje się, że tak. Czyli ta liczba obserwacji nie jest aż taka duża. I to też jest zaletą metryk, że one są szybkie. Szybko można zacząć ich używać, nie trzeba czekać kilka lat, żeby uzbierać nieskończoną ilość danych.
Wracając do podstawowego tematu naszej rozmowy, mówiliśmy o tej estymacji, o Velocity, prędkości… Mówiliśmy o przepustowości, która jest dla ciebie taką ważną daną i ważnym kryterium tego, jak patrzycie na swoją pracę… Co jeszcze? Jakie jeszcze są te dane, które zbieracie? Jakie są te metryki, które są kluczowe? Oczywiście nie chcę, żebyś nam tutaj pełen kurs zrobił tego, bo tym się zajmujesz gdzie indziej, ale powiedz mi jeszcze, na jakie dane patrzycie, żeby faktycznie nie estymować, nie zgadywać i nie opierać się na tych błędach poznawczych, a jednak mieć twarde dane, które powinny dać większą pewność.
Jeżeli chodzi o inne metryki, to jest to tzw. Cycle Time albo Lead Time, tutaj stety czy niestety, jest bardzo dużo różnych definicji. Każdy definiuje to sobie po swojemu. Czasami nawet niektórzy się ze sobą nie zgadzają co do definicji. Ale to jest tylko kwestia definicjii. Na koniec dnia chodzi tak naprawdę o to, żeby się umówić po prostu kiedy włączamy zegar, kiedy rozpoczynamy mierzenie pracy, działań nad zadaniem, a kiedy wyłączamy ten zegar. I to jest świetna metryka, bardzo fajnie działająca i w Scrumie i w Kanbanie, pokazująca nam po jakim czasie zadania, które wchodzą do systemu, które z niego wychodzą, i co się tam dzieje w środku. I można to zobaczyć, wykorzystując wizualizację tych danych, obserwować różne trendy czy wzorce, które jesteśmy w stanie tam zaobserwować, i w związku z tym też na tej podstawie wiedzieć, czy obserwować lepiej nasz system, i znów o tym porozmawiać, co możemy zrobić, żeby np. skrócić czas dostarczenia zadań, żeby biznes otrzymał jakąś wartość wcześniej. I to są bardzo fajne rozmowy na poziomie rzeczywistej rozmowy, nie o tym, co mi się wydaje, czy jesteśmy szybcy, wolni, obojętnie, tylko patrzymy na to, jak całościowo nasz system działa.
Bardzo fajną metryką jest metryka, która powinna być stosowana tak naprawdę na każdym daily, jeśli się spotyka zespół, i powinniśmy sobie patrzyć na working progress age, tak po staropolski mówiąc, czyli jak długo nasze zadania są już w systemie. Ile czasu rzeczy, nad którymi rzeczywiście aktualnie pracujemy, jak długo one tam przebywają. I wracając do danych historycznych, możemy wtedy zobaczyć pewne poziomy, że np. w kroku jakimś do tej pory w systemie zadania zajmowały ileś czasu, teraz jakieś zadanie zajmuje np. więcej czasu, i tak naprawdę…
Jesteś w stanie wąskie gardła w miarę szybko wyłapać na czymś takim.
Tak, to można od razu zauważyć, jak to się dzieje. I tak naprawdę takie daily, na którym jest rozmowa: „No, ja wczoraj robiłem to, a dzisiaj będę robił tamto” zmienia się w daily, na którym rozmawiamy: „Patrzcie, tu jest zadanie, które przekracza już nasze dotychczasowe czasy realizacji, i tu się skoncentrujmy, tu coś zróbmy, dlaczego tak się dzieje? Nie wiem, co, jest jakiś bloker? Ktoś potrzebuje pomocy?” No cokolwiek innego, i o tym rozmawiamy tak naprawdę, a nie o tym, co ja wczoraj robiłem.
No fakt, że większość tych narzędzi wspierających, te zwinne tablice nawet, ma automaty, które są w stanie ci to gdzieś szybko zwizualizować; to nie są rzeczy nawet, to nie są rzeczy, którymi ty się musisz zajmować na co dzień, bo Jira np., którą tu wszyscy znamy, kochamy i nienawidzimy jednocześnie, daje takie rzeczy wręcz prosto z pudełka, nie?
No niestety nie.
O kurcze, to może ja działam na jakichś pluginach, bo wiem, że takie rzeczy bardzo często w Jirze miałem, że mi pokazywała, ten Age, podkreślała, kolumnę, kolorowała itd.
To korzystałeś z pluginów, to są dodatki do Jiry. Sama z siebie Jira nie do końca daje takie wartościowe metryki czy wizualizacje metryk, jest z tym trochę problemów, przynajmniej takich, których ja używam albo chciałbym widzieć, i żeby to zautomatyzować, to potrzeba do tego jakichś dodatkowych pluginów, które tę pracę zautomatyzują czy nam uproszczą, a w najgorszym razie zawsze można coś przekleić do tego nieśmiertelnego Exella, na którym, jak wiadomo, cały świat stoi, i też go wykorzystać. I przeważnie jeżeli nie mamy dziesiątek czy setek zadań na tablicy, albo jakiś duży projekt czy duży zespół, to też nie są to jakieś strasznie pracochłonne czy skomplikowane rzeczy. I można się tym pobawić i zacząć to wykorzystywać i to bardzo fajnie usprawnia, daje dodatkową warstwę, na którą możemy patrzyć na daily, i to polecam wszystkim słuchaczom, żeby wykorzystać to i popatrzyć, w ogóle, zobaczyć przede wszystkim, jak te rzeczy w danym dniu wyglądają, czy te nasze rzeczy przepływają, czy gdzieś co się zakorkowało, zablokowało z jakichkolwiek przyczyn, bo przyczyny mogą być najróżniejsze.
Patrzycie na coś jeszcze? Bo wspominaliśmy już o tej przepustowości, o średnim wieku, możemy też sobie mówić o limicie na working progress…
Tu tylko sprostuję: to nie jest średni wiek.
Tzn. średni wiek w danym statusie – brakuje mi polskiego odpowiednika. Wiem, o czym myślę. Patrzymy, ile dane zadanie spędza w danym kroku procesu, tak więc to jest wiek średni tego konkretnego statusu, wiadomo, że ciężko mi to wyłożyć tak, jakbym chciał. Ale rozumiem, o co chodzi.
Spoko, spoko, tak się śmieję, bo teraz to też się wiąże z tym, że jesteśmy przyzwyczajeni przez szkołę, bo intuicyjnie wiemy, zostaliśmy nauczeni, co to jest średnia. I ta średnia tak otacza nas z każdej strony i wszelkie dane gdziekolwiek w telewizji czy internecie, to wszędzie są średnie. Natomiast średnia ma niskie prawdopodobieństwo wystąpienia i w związku z tym w ogóle nie powinna być używana.
Taki suchy żart prowadzącego: Jeżeli wejdzie Bill Gates do jakiegoś baru, to średnio statystycznie wszyscy są milionerami; czy jak idziemy z psem na spacer, to mamy średnio trzy nogi. Dlatego ta średnia nie jest najlepszym rozwiązaniem, są do tego lepsze rzeczy i jest taka teoria, żeby średnich w ogóle nie używać, bo są na tyle niemiarodajne, że wręcz ukrywają przed nami pewne rzeczy. A druga sprawa, że są bardzo podatne na wartości skrajne i w związku z tym ta transparencja tego, czego chcemy się dowiedzieć, jest bardzo duża.
Nie wiem, czy nie za dużo o tych metrykach teraz tylko mówimy.
Tak, bo finalnie poruszamy się cały czas w ramach tego „Na kiedy to będzie?”, bo to jest takie hasło, z którym ja ciebie kojarzę od dawna, chociażby na LinkedInie. Jest to pytanie, które my, pracując w tym biznesie, słyszymy pewnie najczęściej, na równi z drugim pytaniem: „Dlaczego to tak długi trwa?”. Bo tak jest, że i my to chcemy wiedzieć, i klient, na kiedy to będzie, kiedy on zobaczy realny efekt, albo rzadziej: jaki efekt będzie widział w konkretnych miejscach w czasie.
Mówiłeś, że model czasami wam pomógł, albo to model miał rację, a nie wasze założenia, ale czy właśnie patrzycie na to też z tej strony: okay, mniej więcej jaki będzie ten przyrost wartości, albo co będzie widział klient w konkretnych miejscach w czasie, cały czas mówimy o jakichś tam konkretnych wydaniach, cały czas pracujemy w jakiejś kadencji. Bo też jest bardzo często narzucone przez naszych klientów, przez ten biznes, i samo to interacyjne podejście do tego, jednak staramy się patrzeć w miarę możliwości na to w małych kawałkach.
To jest oczywiście bardzo różnie. Iteracyjne podejście jest bardzo trudne do osiągnięcia w takim najlepszym wydaniu. Z moich obserwacji wynika, że ludzie przeważnie traktują iteracyjność jako takie miniwaterfalle, nazwijmy to. Bo po prostu, potniemy na mniejsze kawałeczki i będzie git. I wtedy jesteśmy zwinni. Natomiast dla mnie ta zwinność jednak jest czym innym, w sensie rzeczywiście wydajmy coś szybko i zbierzmy jakąś informację zwrotną od klientów z rynku bezpośrednio, obserwujmy to.
Np. jedna rzecz, nie wiem, czy bardziej śmieszna, czy smutna, jest taka, że wiele razy widziałem, że klienci nie byli nawet zainteresowani tym, żeby mieć jakieś statystyki ze swoich produktów. Albo jeżeli te statystyki mieli, to się okazywało, że nikt ich nie używał i w związku z tym później był nowy pomysł, nowa funkcjonalność czy cokolwiek innego, i to się ograniczało do: no bo tak wymyśliliśmy, to zróbmy tak. I to jest trochę odległe jednak od tej zwinności, jaką ja rozumiem, jak próbuję, żeby wyglądała gdy pomagam zespołom.
Także wracając jeszcze do twojego pytania, czy jesteśmy w stanie powiedzieć, jak to będzie wyglądało w czasie. Właśnie dzięki modelowi prognozowania statystycznego jesteśmy. I co jest też ważne, wszelkie zmiany, wszelkie rzeczy, które się zadzieją w trakcie naszej pracy, jesteśmy w stanie bardzo szybko czy nawet od razu je zauważyć, pracując metrykami oraz przemodelować, zaktualizować naszą (naszą i biznesu) wiedzę na ten temat.
I tu wracam do tego, co już powiedziałem, że wtedy ta rozmowa schodzi na inny poziom, nie obwiniamy się „Obiecaliście, a nie dostarczyliście”, tylko rozmawiamy o zupełnie innych rzeczach. I przede wszystkim to, co jest ważne: to się dzieje szybko. To nie jest tak, że na tydzień przed końcem projektu się okazuje: „O kurcze, ale tu jeszcze jest dużo do zrobienia”, tylko jesteśmy w stanie porozmawiać o tym zaraz po starcie projektu, bo już się czegoś nauczyliśmy, czegoś się dowiedzieliśmy, coś się zmieniło, już wiem, jak to wszystko działa i jesteśmy w stanie na to zareagować, ponieważ metryki nam to pokazują. I ta rozmowa jest wcześniej, a dzięki temu biznes też się czuje poinformowany, bezpieczniejszy. Oni też na tej podstawie mogą pracować, mogą lepiej planować swoją pracę, wiedzą, jak to wygląda, zaczynają to rozumieć, zaczynają też być częścią tego dostarczania i przestajemy być na zasadzie: „my dobrzy, oni źli”.
No właśnie, bo cały czas kluczową rzeczą w zwinnym dostarczaniu, i w ogóle w pracy, w jakimkolwiek środowisku, jest zaufanie. Jedna sprawa, że musimy sobie w zespole ufać i móc na siebie liczyć, a druga, że musimy budować zaufanie pomiędzy nami a klientem. Bo wiadomo, że zaufanie w biznesowych relacjach najlepiej buduje się przez wyniki: zobowiązanie i sprostanie temu zobowiązaniu. A jeśli nie, to przynajmniej przez dobrą komunikację i tłumaczenie. Tak jak mówisz, te modele, te metryki też są w stanie w tym pomóc, to nie jest tylko tak, że okay, dostaliście x user stories teraz, dostaniecie x user stories za tydzień, albo takie i takie, i tu wam zrobimy demo i jest fajnie, tylko tak jak mówisz, wy nawet korzystając z tych modeli i danych, pracujecie z waszymi klientami.
Tak staramy się robić, i to jest wartościowa praca, która przynosi korzyści w długiej perspektywie, natomiast trzeba też mieć świadomość, że na początku, tak samo jak zespoły się tego uczą, tak jak rozmawialiśmy, to nie jest popularny temat. W związku z tym rzadko kiedy się zdarza, że ludzie mieli już wcześniej dobre doświadczenia związane z metrykami, wręcz przeciwnie, najczęściej mieli negatywne doświadczenia, albo słyszeli o takich, albo czytali, albo mają takie wyobrażenia, że te doświadczenia z metrykami są negatywne, w związku z tym ta praca jest trochę długa, czy wymagająca.
Tak samo jest od strony biznesu, który też wcześniej tego prawdopodobnie nie używał, a jest duża szansa, że nie używał, w związku z tym też musi to zobaczyć, nauczyć się, sprawdzić, jak to działa. I to zaufanie musimy między sobą zbudować i metryki w tym pomagają. Jest to na pewno jeden z ważnych elementów budowania zaufania i współpracy w zespole w ogóle, gdzie zespół jest rozumiany jako ten całościowy, czyli biznes plus zespół deweloperski.
Chciałem się jeszcze zapytać, czy ty masz jakąś taką swoją ulubioną metrykę? Czy jest coś takiego, na co patrzysz w pierwszej kolejności, kiedy zaczynasz pracę z nowym zespołem? Czy to jednak jest kompleksowy model, w którym te wszystkie metryki, o których mówiliśmy, muszą być mierzone? A może jeszcze są takie, o których nie powiedzieliśmy? Dorzuć je, jeśli możesz. Od czego zacząć? Czy da się to robić stopniowo, czy jednak jeśli chcemy mieć sensowny model, to im więcej danych, tym ten model będzie dokładniejszy?
Osobiście nie mam jakiejś ulubionej metryki, którą stawiam przed innymi, i którą uważam za najlepszą, jedyną, która rozwiązuje wszystkie problemy. Staram się używać wszystkich metryk (nie wspominaliśmy jeszcze np. o skumulowanym diagramie przypływu), ponieważ każda daje nam jakiś inny kąt widzenia, inne spojrzenie, opowiada historię z troszeczkę innej perspektywy, i to jest wartościowe. Natomiast istotne jest też z punktu widzenia zespołu takie podejście, że proponujemy, że np. od dzisiaj zaczynamy używać sześciu metryk. To też nie jest dobre, bo tak, jak wspominaliśmy, te doświadczenia przeważnie są nie najlepsze, albo komuś się tylko wydaje, że są nie najlepsze, i trzeba pamiętać, że tak czy inaczej, zawsze jest to jakiś dodatkowy wysiłek dla zespołu.
W związku z tym nie jest to najefektywniejsze takie wrzucenie od razu bardzo dużej ilości metryk. Tak że ja, bazując na własnym doświadczeniu, wolę wprowadzać to krok po kroku. Popatrzmy na jedną, zrozummy ją, popatrzmy na drugą, zacznijmy stosować, dostrzegać wartość w metrykach i krok po kroku rozszerzajmy ten arsenał, czy wachlarz – tak go nazwijmy. Zawsze jest też miejsce, i to coś, do czego zachęcam, gdzie prędzej czy później pojawiają się metryki zespołowe. Zespół jest już w stanie sobie powiedzieć „Co my chcemy wiedzieć o naszym systemie pracy?”, „A jak to chcemy zmierzyć?” i powstaje jakaś metryka, która nie jest nawet nigdzie opisana, bo jest taka nasza kontekstowa, to co chcemy rzeczywiście my wiedzieć. Sami ją zbudowaliśmy i sami na nią patrzymy. A to jest jeszcze lepsze pod tym kątem, że typowo my jako zespół to stworzyliśmy. Zbudowaliśmy to narzędzie i je wykorzystujemy jako zespół. I to jest bardzo fajne, bo wtedy to zespół stworzył tę metrykę i to jest nasze, my korzystamy z informacji, które ta metryka nam przynosi, i to jest super, żeby móc z zespołem dojść do takiego momentu, że sami zastanawiamy się, co i dlaczego chcemy zmierzyć.
I nie mówimy tu o tych takich najpopularniejszych typu poziom zadowolenia zespołu, tylko mówimy tu jednak o tym aspekcie procesowym. Tym, jak dobrze nam idzie praca. Czy jakiekolwiek metryki, jakie wyjdą od zespołu, po prostu zawsze będą wartościowe, bo to jest jednak ta zdolność do refleksji?
Zadowolenie zespołu też może być używane, osobiście go nie używam, ale znam zespoły, które go używają, i to jest fajne, jeżeli zespół tego potrzebuje, widzi w tym wartość, to jak najbardziej tak, używajmy. To też nie jest tak, że ktoś ma pomysł na metrykę, a my go odrzucimy. Też jej używajmy, jeżeli widzimy w niej wartość i przynosi nam rzeczywiście korzyści. Takim papierkiem lakmusowym tego, jakie korzyści przynoszą metryki, jest taki test: Myśląc np. o ostatnim okresie, odpowiedzcie sobie na pytanie, czy na podstawie tych metryk, które zbieracie, które obserwujecie, czy podjęliście jakąkolwiek decyzję. I to jest bardzo fajny papierek, pokazujący nam, czy to nie jest taka sztuka dla sztuki, bo np. kazali, tylko czy rzeczywiście to jest pokazanie, że ta metryka jest rzeczywiście narzędziem, które pozwala nam o czymś zdecydować, wprowadzić eksperyment, zmianę, cokolwiek.
I jeżeli odpowiedź jest twierdząca, to super, to właśnie o to chodzi w metrykach, żeby one pomagały nam podejmować lepsze decyzje od tych, których albo byśmy nie podjęli, bo byśmy nie wiedzieli, że trzeba, albo które czasami podejmujemy na zasadzie przeczucia, albo popatrzenia w sufit: „No to może teraz to czy tamto”. Także te metryki, które stworzy zespół, jeżeli to jest zadowolenie zespołu, czy jakakolwiek inna rzecz, czy już idąc jeszcze dalej, “co my chcemy osiągnąć i jak to możemy zmierzyć?”, i tu nie wiem, czy są jakieś ograniczenia. Na chwilę obecną wydaje mi się, że nie. Wszystko to, co zespół potrzebuje, uważa za użyteczne, na koniec dnia zawsze w jakiś sposób można zmierzyć i w związku z tym mieć z tego metrykę.
Wspomniałeś jeszcze o diagramie przepływu, zaraz sobie podsumujemy wszystkie te metryki, natomiast ja widzę to jako ogrom pracy. To jest jednak spora ilość danych, które trzeba regularnie zbierać, analizować, stworzyć jakiś szablon, model, który będzie to w jakiś sposób obrabiał. I można to w jakiś sposób zautomatyzować, i wiadomo, że dobrze jest dążyć do czegoś takiego, ale właśnie, czy to nie jest faktycznie ogrom pracy i nie tworzy trochę ze Scrum Mastera takiego statystyka tylko i wyłącznie? Ile czasu zostaje na te inne aspekty tej pracy? Z twojego doświadczenia oczywiście.
To, co możemy zautomatyzować, to wizualizacja i zbieranie tych danych. Interpretacji danych nie zautomatyzujemy. To jest kwestia doświadczenia i wiedzy, którą się w kursie metryk dzielimy, ponieważ z danych czy z wizualizacji można też wyciągać wnioski nie do końca dobre, czy czasami wręcz błędne, tak że na to trzeba zwrócić uwagę. Natomiast to nie jest trak, że te metryki mają przykryć całą pozostałą działalność Scrum Mastera i tego, co on robi w zespole. Tak jak mówiłem, jeżeli mamy to zautomatyzowane, czy nawet robimy to ręcznie, przy większości projektów jest to jak najbardziej do zrobienia, jeżeli robimy to regularnie i rzeczywiście tego używamy. Natomiast to zastanowienie się, zwłaszcza na początku, żeby Scrum Master był w stanie podpowiedzieć czy wesprzeć zespół w interpretacji tych danych, ich prawidłowego używania jest tak samo istotne. Ale tśmiejeak samo jak ludzie się nauczyli już korzystać ze story pointów i przemnażać to sobie w głowie i używać tego sposobu pracy, to tak samo możemy nauczyć się używania metryk, i wykorzystywać je z dużo lepszym efektem.
W związku z tym nie widzę niebezpieczeństwa, że to skończy się tak, jak powiedziałeś, że Scrum Master ma być jakimś statystykiem. Odnośnie do statystyki i matematyki, to jest też fajne, że pod kątem tej bariery wejścia, o której mówiłem na początku, rzeczywiście z mojej perspektywy ona jest wysoka, natomiast po jej przejściu, okazuje się, że to nie jest jakaś zaawansowana matematyka czy fizyka kwantowa, tylko są to dosyć proste rzeczy, obiektywnie rzecz biorąc. I się śmieję, że skoro ja je ogarnąłem, to każdy może je ogarnąć.
Mówiłeś właśnie, że nie jesteś matematykiem, że nie programowałeś, to kim jesteś z wykształcenia?
Kończyłem SGGW w Warszawie i swoją pracę zawodową zaczynałem w ogóle poza światem IT, ponieważ byłem menedżerem pola golfowego. Tak że temat chyba całkiem odległy od świata IT.
No fakt.
Przez wiele lat w tym obszarze się poruszałem. Bardzo fajny sport i bardzo fajny temat, natomiast w którymś momencie przeszedłem zmianę zawodową i wkroczyłem w świat IT. Zresztą bardzo fajnie, bo wymyśliłem po prostu swoją aplikację mobilną, która teraz byłaby bardzo na czasie, bo służyła do porównywania cen benzyny. I tak nastąpiło to moje przejście z biznesu pól golfowych do świata IT. I dosyć szybko pojawił się Scrum, który bardzo pasuje do mojego sposobu myślenia i realizacji zadań, tak że ta zwinność bardzo odpowiada mojemu sposobowi myślenia i działania, dobrze się tu uzupełniamy. A później bardzo dobrze czuję się z tym, żeby się tą wiedzą i doświadczeniem dzielić na warsztatach, spotkaniach, meetupach czy kursach.
Kończąc podcast, podsumujmy sobie może te metryki jeszcze ostatni raz. Wspominaliśmy o tym średnim czasie w statusie, wspominaliśmy o diagramie przepływu, o przepustowości… Co jeszcze tam się powinno znaleźć na tej liście?
Jeżeli będziecie szukać jakichś materiałów – co mam nadzieję, nastąpi po wysłuchaniu tego podcastu – to polecam bardziej używać słów angielskich, pojawi się wtedy na ten temat dużo więcej wyników wyszukiwania. I tylko jedna uwaga, że np. jeśli chodzi o Cycle Time i Lead Time, jest bardzo dużo różnych definicji, czasami są nawet sprzeczne. Tak samo jeżeli chodzi o inne obszary metryk, można spotkać sporo błędnych opisów metryk czy spojrzenia na metryki. Tak że tutaj zawsze daję taką małą gwiazdeczkę, że trzeba zwracać na to uwagę. I te metryki „podstawowe”, kanoniczne, czyli np. Cycle Time, Throughput, Cumulative Flow Diagram czy Weep Age to są te rzeczy, na które w pierwszym kroku zachęcam, żeby zwrócić uwagę, i sobie o tym poczytać, czy pooglądać. W związku z tym to są najlepsze pierwsze kroki, które pozwolą nam dużo zobaczyć. Jeżeli gdzieś bym miał w ogóle pierwsze kroki skierować, to myślę, że ten Cicle Time jest najbardziej obrazowy, dużo tam się dzieje, jest dużo kropeczek, w związku z tym jest akcja, jest napięcie i można dużo fajnych rzeczy zaobserwować, dużo różnych wzorców, i na tej podstawie sobie krok po kroku jako zespół rozmawiać i wokół tego próbować coś poprawić, naprawić bądź poeksperymentować. W związku z tym, takim najlepszym, najbardziej naturalnym krokiem są właśnie te metryki podstawowe. Kanban je wymienia z automatu, w Scrumie jest jakiś bardziej Burn Up Chart, tego typu rzeczy, i ich też można używać, one też coś obrazują. I później wchodząc w ten świat metryk, poznajemy go coraz lepiej, coraz więcej rozumiemy. Jest wysoki próg wejścia, no nie ma co się oszukiwać, ale mój przykład pokazuje, że można go pokonać i naprawdę cieszyć się później z tego, jakie możliwości to daje.
Na koniec mam jeszcze tylko jedno pytanie. Powiedz mi, gdzie ciebie i Marcina szukać, żeby z tego kursu metryk skorzystać. Albo kiedy?
W pierwszym kroku można sobie na pewno wejść na agilelabs.pl i tam pobrać sobie rysunkowy przewodnik po Kanbanie i zapoznać się z nim, żeby z tą metodą pracować i jednocześnie dostawać informacje, które na bieżąco z Marcinem przygotowujemy i którymi się dzielimy, ponieważ robimy dużo spotkań, dużo fajnych wydarzeń związanych z szeroko rozumianą wiedzą, z Agile, natomiast ten empiryzm zawsze gdzieś tam pełni przewodnią rolę w tej chwili. Natomiast wchodząc na kursmetryk.pl, można się zapisać na listę oczekujących, ponieważ myślę, że w tym roku jeszcze uruchomimy kolejną możliwość dołączenia do kursu. Natomiast w tej chwili pracujemy z kursantami, którzy zdecydowali się na nasze poprzednie otwarcie. Tak że jeżeli ktoś jest zainteresowany tym tematem, to można sobie wejść, my tą wiedzą się dzielimy, można się zapisać, i zawsze być jako pierwszy poinformowanym jeżeli będzie się coś wokół tego działo. No i spotykać się na wszystkich innych spotkaniach Agile Upsów.
No tak, sam miałem okazję nawet występować na jednym z nich, tak że polecam zdecydowanie, bo zapraszają tylko najlepszych i najwspanialszych.
Zdecydowanie tak.
To powiedz mi jeszcze na koniec, jaki jest koszt takiego kursu u was. Albo, jaki będzie, kiedy już wróci możliwość zapisu?
Pierwsze otwarcie kursu, które zrobiliśmy na końcówkę zeszłego roku 2021, to było takie otwarcie VIP, właśnie dla osób, które zaufały nam i naszej wizji kursu, w związku z tym to była cena na otwarcie, promocyjna, natomiast ile będzie kosztował kurs w drugim i w każdym kolejnym otwarciu, w tej chwili nie jestem w stanie powiedzieć, ponieważ nie mamy w tej chwili jakiejś konkretnej liczby w głowie. Tak że najlepiej po prostu się zapisać, i wtedy te wszystkie informacje trafią do rąk bezpośrednio zainteresowanych.
W takim razie ja się już zapisuję i czekam na kolejną edycję kursu. Pawle, ogromne dzięki za poświęcony czas i za podzielenie się wiedzą. Życzę powodzenia w szerzeniu wiedzy na temat metryk w Scrumie i nie tylko.
W Agile’u. Bardzo serdecznie dziękuję za zaproszenia, bardzo serdecznie dziękuję za wszystkie pytania, i dla wszystkich słuchaczy wszystkiego zwinnego!
