Nie tak dawno wziąłem udział jako prelegent w ProMeet #28. Było to moje pierwsze wystąpienie publiczne dla większości obcych mi ludzi. Tym wpisem chcę podzielić się z Tobą tym, co towarzyszyło przygotowaniom do tego wydarzenia. A zatem moim stresem, brakiem doświadczenia, problemami i odczuciami. No to od początku.
ProMeet to cykl spotkań dla ludzi związanych ze światem IT. Więcej na temat tego spotkania możesz przeczytać na stronie NBC.
Wpis ten dzielę na trzy części. W pierwszej przeczytasz o samych przygotowaniach do wydarzenia. To tutaj wydzieliłem dziesięć kroków, które prowadziły do mojego wystąpienia. Kolejna to mój subiektywny opis tego, co się działo. Natomiast w ostatniej umieszczam pytania, jakie pojawiły się po prezentacji.
Krok #1, czyli zaproszenie do wzięcia udziału w wydarzeniu
Kolejny już raz w moim życiu potwierdziła się dewiza, że komunikacja czy raczej rozmowa z drugim człowiekiem może czynić cuda. W przypadku wystąpienia na ProMeet kluczowe było to, że pracując nad projektem dla NBC zawarłem znajomość z dziewczynami, które były współorganizatorkami tego spotkania. W trakcie jednej z rozmów rzuciłem temat, że mogę wystąpić na spotkaniu dla testerów. Jakoś tak od słowa do słowa się to potoczyło, że moja propozycja została zaakceptowana.
Krok #2, Zapoznanie się z zasadami wystąpienia
Przygoda zaczęła się od tego, co zniechęca najbardziej (przynajmniej mnie), czyli od „Przygotowania formalności”. Wchodzą w ich skład przeczytanie wytycznych i planu spotkania. Przedstawienie planu prezentacji, a także maile dopinające szczegóły. Krótko mówiąc, wszystko to, czego większość z nas robić nie lubi.
Krok #3, Wybór tematu prezentacji
Jako temat wybrałem Estymację czasu pracy testera, o której możesz przeczytać na moim blogu. Temat mi bliski, ale i ogromny. W zasadzie najtrudniej było wybrać, o czym mówić a o czym nie.
Otrzymałem 45 minut na całą prezentację. W tym miałem również uwzględnić pytania do prowadzącego, czyli mnie :). Miałem więc jakieś 35 minut na przedstawienie wszystkiego. Znaczy się mało, malutko.
Krok #4, Treść prezentacji stworzyłem metodą eliminacji tego, co jest „mniej ważne”.
Nie miałem pomysłu jak to wszystko spiąć, żeby spełniało moje dosyć rygorystyczne założenia jakościowe.
Ostatecznie postanowiłem obciąć kilka tematów. Nie powiedziałem zatem o wycenie eksperckiej, wycenie na podstawie danych historycznych, czynnikach wpływających na wycenę, a także o wycenie procentowej.
Krok #5, w którym stworzyłem treść slajdów
Metodą eliminacji wyklarował się dość dobry plan prezentacji. Postanowiłem opowiedzieć o aspekcie biznesowym estymacji.
Uwzględniłem techniki takie jak: Trzystopniowa estymacja, Planning poker oraz Bottom up.
Na koniec chciałem poruszyć temat problemów, jakie możemy napotkać w trakcie robienia wyceny.
Tak powstała treść dla slajdów prezentacji oraz scenariusz tego, co chciałem powiedzieć.
Krok #6 to tworzenie prezentacji
Wiedziałem już, co chcę powiedzieć. Miałem napisany tekst prezentacji. Zostało już „tylko” stworzyć plik w Power Point.
I tutaj mała dygresja. Nie wiem jak u was, ale w moim wypadku w zasadzie ani na potrzeby szkoły, ani na potrzeby pracy nigdy nie musiałem stworzyć profesjonalnie wyglądającej prezentacji.
Nie musiałem, ponieważ w pracy były gotowe szablony, do których wklejałem tekst.
Nie musiałem, ponieważ przez wiele lat edukacji nikt nigdy nie zmusił mnie do tego.
Oczywiście nie obyło się bez problemów związanych z moimi zdolnościami posługiwania się programem, ale jakoś wybrnąłem i udało mi się stworzyć z małą pomocą całkiem fajną i sprawną prezentację.
Krok #7 to walka z czasem o czas
Siedem dni do prezentacji. W moim kalendarzu szkolenia, praca, pisanie obiecanych artykułów, ale też artykuły, które muszę przejrzeć i dać odpowiedź ich autorom. Jednym słowem po raz kolejny mój grafik jęczał od samego rana aż po wieczór, gdy padałem bez sił do łóżka.
Do tego z racji zbliżającego się terminu ProMeet musiałem zacząć dosyć poważnie rozbijać na czynniki pierwsze co powiem wychodząc na scenę.
Ćwicząc scenariusz prezentacji, przyjąłem następujące założenia.
- Treść wystąpienia ma być tak zwanym mięchem. Wychodzę i nie biadolę filozoficznie, tylko mówię, jak się coś robi, przytaczam przykłady i przechodzę dalej.
- Chcę trafić do bardzo szerokiego grona ludzi na sali. Wiedziałem, że przyjdą osoby zarówno początkujące, jak i osoby zaawansowane (tu niestety nie wpadłem, żeby dopytać ile jest jakich osób).
- MUSZĘ zmieścić się w moich 45 min Głupio, jeśli gość od estymacji wykłada się na czasie. Ograniczenie czasowe było dla mnie dużym problemem. Temat prezentacji nie należy do zero jedynkowych. Przez co założyłem, że muszę mieć około 5-10 min na pytania/odpowiedzi.
I teraz przyjąłem, że jeżeli wszystko wyjdzie zgodnie z moimi założeniami, to idealnie zmieszczę się w czasie +/- 3-4 min, ale też, jeżeli się przeliczę i nie będzie pytań, to skończę prezentację 10 min przed czasem i będzie wstyd, bo czas nie zostanie odpowiednio wykorzystany.
Krok #8, dopinanie nagrań
Ostatnie trzy dni do dnia prezentacji. Poprosiłem dwie osoby o nagrywanie mojego wystąpienia. Tak na wszelki wypadek, gdyby jedno się nie nagrało 😉 Miało to dwa cele.
Pierwszym z nich oczywiście jest możliwość podzielenia się z tymi, którzy nie mogli przyjść.
Po drugie chciałem mieć możliwość prześledzenia całego wystąpienia i wyciągnięcia wniosków na przyszłość.
W tym momencie zaświtała mi myśl „A może oprócz nagrania tego filmiku zrobię relację na żywo na fanpage?”. Tak trzy dni do prezentacji i ja jeszcze nigdy nie robiłem relacji na żywo.
Krok #9, o tym, jak się nie powinno zabierać za live na firmowym fanpage
Umówiłem się z przyjacielem, że przyjdzie, ustawi telefon, kliknie odpowiedni przycisk i będzie relacja na żywo.
Takie było założenie. Proste i w zasadzie niewymagające.
W praktyce wszystko było przeciw. W dzień prezentacji kolega zawiadomił mnie, że jest chory.
Zorganizowałem innego znajomego i postanowiłem z nim przećwiczyć na testowym fanpage działanie relacji na żywo. Facebook zgłaszał błąd w momencie, gdy próbowałem zaakceptować rolę admina, więc już wiedziałem, że nie ma czasu na testy.
Z relacji na żywo zrezygnowałem.
Zero stresu dosłownie zero 😀
Krok #10, czyli dzień prezentacji
Standardowo od rana w pracy. Dużo do zrobienia, a ja już myślami przy godzinie 18:15. Spotkania, planowanie oraz testy.
Wreszcie, Kraków, Meiselsa 18, pub HEVRE, znaczy ProMeet #28
Tuż przed rozpoczęciem spotkałem mojego byłego kursanta, Mateusza, który przyszedł razem z koleżankami z pracy również testerkami, aby posłuchać wykładów.
Wpis na listę obecności, przywitanie z koleżankami z NBC. Ponieważ chciałem pokazać na przykładzie jak wygląda planning poker, poprosiłem dziewczyny pracujące przy wydarzeniu, aby aktywnie pomogły mi na scenie. Podałem im przykłady, jakie chciałem omówić podczas gry właściwej, a reszta miała być niespodzianką – wyjaśniłem im również, jak wyglądają rezultaty takiej estymacji.
W mojej głowie myśli jak wyeliminować swoje złe nawyki. Łażenie/bujanie się/kręcenie oraz machanie łapami – ja po prostu nie umiem ustać w miejscu. Ci, co ze mną pracowali/się szkolili to wiedzą 😊. Po drugie nienadużywanie jednego słowa. Tu mały spojler i jedno i drugie się nie udało.
Prezentacja Estymacja Czasu Pracy na ProMeet#28
Zaczynamy! Wchodzę na środek. Na sali jak widzę niespodziewanych jak dotąd standardowo 10 osób a około 50. Chwila tremy, na szczęście tylko chwila. Mikrofon w ręce i jazda!
Początek prezentacji to stres, pewnie widoczny. Stałem przed dużą publicznością. W głowie miałem ciągle przewijającą się myśl, by nie gestykulować ręką z mikrofonem. Powtarzałem sobie „nie łaź tyle, stań sobie, bo ludzie nie mogą się skoncentrować na gościu biegającym od ściany do ściany”. I wreszcie miałem odczucie, że hmmm na próbach jakoś więcej czasu mi poszczególne slajdy zajmowały.
Przedstawienie się, to akurat proste: Cześć jestem Waldek obecnie pracuję w firmie Abventor jako test lead. Dodatkowo jako firma szkolę z zakresu testowania oprogramowania.
Następnie, zamiast powiedzieć o estymacji, która towarzyszy nam na co dzień i skąd w ogóle wzięła się moja myśl na temat tej prezentacji, zacząłem dukać o jednej z metod estymacji. Na szczęście później już było lepiej.
Jednostki estymacji czasu pracy
Tematy ocierające się o metodyki zwinne, w tym przypadku o Scruma określiłbym jako bardzo zawiłe. Dlatego z tą częścią mojej prezentacji miałem delikatny problem. Jeden temat łączy się z drugim i tak naprawdę ciężko jest idealnie połączyć tematy tak, żeby usatysfakcjonowały one wszystkich.
Przez rozdzielenie tematu jednostek od technik estymacji wyszło moim zdaniem trochę nierówno, o czym przeczytacie dalej.
Planning poker
Po nakreśleniu, na czym polega ta technika, razem z dziewczynami przedstawiliśmy trzy przykładowe scenariusze.
Scenariusz #1, Oszacowanie czasu potrzebnego na posprzątanie sali po spotkaniu.
Nakreśliłem co mamy do zrobienia i razem „na trzy cztery” pokazaliśmy nasze typy, które… były takie same!
W ten sposób pokazaliśmy pierwszy scenariusz, w którym cały zespół zgadza się co do swojej estymacji i przyjmuje ją jako właściwą.
Scenariusz #2, Ugotowanie Spaghetti.
Po raz kolejny „na trzy cztery” podnieśliśmy swoje typy. Dziewczyny podniosły solidarnie 5, ja natomiast podniosłem 13. Dzięki temu udało się zademonstrować kolejny przypadek – tym razem taki, kiedy członkowie zespołu nie zgadzają się co do estymacji. Oczywiście wytłumaczyłem, skąd wzięła się moja estymacja. Powiedziałem, że tylko dlatego daję tak wysoką estymację, ponieważ jestem facetem i nie umiem gotować.
Moim błędem podczas definiowania zadania, było nie sprecyzowanie, jakie ma to być spaghetti i z czego wykonane.
Pytanie z widowni „Czy waszą estymacją jako całego zespołu jest 13?”
Mogłaby to być właściwa estymacja pod warunkiem, że dziewczyny jako członkinie zespołu miałyby zadania, które uniemożliwiałyby udzielenie pomocy mi. Wycena byłaby również poprawna, jeśli nie byłaby możliwa zamiana między nami zadań. Gdyby jednak dziewczyny powiedziały „To nie jest aż tak problematyczne, w razie problemów pomożemy Ci z tym tematem”, w takim wypadku nasza wycena zeszłaby niżej.
Scenariusz #3, Przemieszczenie się z punktu A do punktu B.
Po objaśnieniu trasy i możliwości transportowych po raz ostatni wy estymowaliśmy nasz czas. Tutaj dziewczyny dały swoją wycenę jako 3, a ja dałem 5. To był trzeci scenariusz tego, co może się wydarzyć podczas estymacji. To znaczy, mamy liczby, które w ciągu Fibonacciego znajdują się koło siebie.
W takim wypadku do wyceny bierzemy przeważnie wyższą wartość. Wyjątkiem jest sytuacja, gdy jest nas tylko trójka i dwie osoby dały trzy. Wówczas należy przyjąć niższą wartość. W związku z tym, dla naszych wyników przyjęliśmy jako obowiązującą wartość liczbę trzy.
W czasie prezentacji nie udało mi się powiedzieć, że na podstawie tej estymacji budujemy sobie prędkość naszego zespołu. Jest nią wartość Story pointów, jaką jest w stanie zrealizować nasz zespół w określonym czasie Sprintu. Liczbę tą modyfikujemy na podstawie kolejnych iteracji.
W drugiej części mówienia o Planning pokerze poruszyłem kwestię rozbijania tasków na testy oraz implementację, oraz estymowanie pełnych tasków. W tej części myślę, że już się rozkręciłem i poszło mi bardzo sprawnie.
Kolejną techniką była trzystopniowa estymacja.
Opowiedziałem o scenariuszu pozytywnym, negatywnym oraz realistycznym.
Tutaj też dobrałem kiepski przykład do zaprezentowania pesymistycznego scenariusza – wybrałem brak prądu/awarię serwerów. Powinienem bardziej pójść w inny czynnik ryzyka np. zmiana developerów. Pracowaliśmy z seniorami, teraz seniorzy przeszli do innych zespołów, a my dostaliśmy juniorów. Mój przykład był o tyle nie trafiony, że później musiałem w części na pytania wyjaśnić skąd się biorą te czynniki, jakie bierzemy do naszych scenariuszy.
Ostatnią techniką była technika Bottom up
Na dzień dobry popełniłem błąd w prezentacji (miałem zapisane Botton up) oraz z niezrozumiałych powodów cały czas posługiwałem się błędnym terminem – zrzucam to na stres.
Od strony merytorycznej myślę, że udało mi się tę technikę oraz wszystkie z nią związane problemy dobrze nakreślić.
Ryzyka związane z estymacją
Częścią finalizującą moją prezentację były ryzyka związane z estymowaniem czasu pracy. Omówiłem tu ryzyka zewnętrzne, jak i wewnętrzne, czyli czemu tak drogo i czy nie da się szybciej.
W tym kontekście opowiedziałem również o presji ciążącej na estymującym i wykonawcy później, czyli co jak się przepala nasz czas.
Osobiście brakło mi tutaj jeszcze poruszenia tematu zbyt bezpiecznej estymacji tzn. dobierania czasów ponad miarę tak, aby uniknąć pytań o to, dlaczego coś jest przepalone. Ryzyka/problemy nie biorą się z samej chęci sprzedaży/kupna aplikacji lub rozwoju jej po określonej cenie, ale również mogą one wynikać z nas samych.
Pytania od słuchaczy po prezentacji
Pytanie o pesymistyczny scenariusz w trzystopniowej estymacji. Czy bierzemy pod uwagę tak skrajne przypadki, jak podałem, czy bazujemy na jakiejś wiedzy historycznej.
Bierzemy pod uwagę czynniki historyczne. Jeżeli wiemy, że nam prąd wywala i koło firmy mamy mega remont infrastruktury to jest to ryzyko dodatkowe. Jeżeli dostaliśmy maila, że zmieniamy dostawcę internetu, to możemy spodziewać się problemów. Z mniej skrajnych rzeczy po prostu musimy być dobrymi słuchaczami. Często chodzimy na kawę z programistami i słyszymy od nich jakie mają zdanie na temat pewnych funkcjonalności, które mają do zrobienia/mają wycenić.
My powinniśmy podczas naszej wyceny brać również ich słowa pod uwagę. Jeżeli coś jest dla nich problematyczne, to znaczy, że i nam może sprawić później problemy.
Kolejne pytanie dotyczyło metody Bottom up i tego, co możemy zastosować w kontekście Scruma, gdzie nie zawsze mamy podane szczegółowo informację jak ma działać dany komponent/aplikacja.
My tak naprawdę powinniśmy używać narzędzi/technik, które nie będą kolidowały z tym, co mamy do wykonania. Jeżeli mamy powiedziane, że pracujemy w Scrumie i np. nasza specyfikacja jest niepełna to nie damy rady użyć techniki Bottom up tylko np. możemy użyć techniki trzystopniowej lub planning pokera. Narzędzi/technik używamy tak, jak być użyte powinny, w przeciwnym wypadku generują nam one tylko i wyłącznie problemy. Nie je się widelcem zupy.
Jak podejść do zrozumienia Story pointa?
Story point jest bardzo ogólną jednostką miary, która tak naprawdę nie mówi nam ile czasu nam coś zajmie tylko, jak złożone/problematyczne jest zadanie. Widziałem w swoim życiu wiele podejść do interpretacji. Jednym z nich było przeliczanie jednego Story pointa na konkretną ilość godzin. Innym sposobem było zbudowanie skali:
1 – Zadanie trywialne do zrobienia od ręki.
2 – Zadanie bardzo proste do zrobienia nawet przez jednego członka zespołu – zajmie mało czasu.
3 – Zadanie proste do wykonania jednakże zajmujące trochę czasu.
5 – Zadanie średniej wielkości, które nie powinno sprawić większych problemów.
8 – Duże zadanie pochłaniające sporą część czasu kilku członków zespołu.
13 – Zajmie cały sprint.
21 – Nie do zrobienia w przeciągu całego sprintu, trzeba rozbić na mniejsze.
Jakie są możliwości mierzenia Story pointów?
Story pointy możemy mierzyć i spisywać w kontekście danych historycznych. Po kilku sprintach będziemy w stanie zbudować sobie prędkość zespołu na podstawie naszych wycen np. nasz zespół pracuje z prędkością trzynaście Story pointów. Ta wartość może ulegać zmianie oczywiście. Osobiście spotykałem się z tym że prędkość, z jaką nasz zespół pracował, była wyliczana na podstawie ostatnich trzech sprintów.
Czy spotkałem się z tym, że zespoły porzucały estymaty?
Tak spotkałem się z tym – w kontekście bardzo przestrzelonych estymat. Moim zdaniem jedynym czynnikiem do tego, żeby porzucić estymaty jest czynnik zewnętrzny, np. wprowadzenie w błąd przez klienta.
„Klient obiecał dostarczyć nam dokumentację oraz środowiska na dzień xyz”.
Natomiast z pewnych przyczyn się to nie zadziało i w tym momencie nie mamy za bardzo podstaw, żeby realizować wy estymowany scenariusz.
Podsumowanie
Jestem bardzo szczęśliwy, że mogłem uczestniczyć w tak świetnym wydarzeniu. Jak widzicie, nie jestem do końca z siebie zadowolony, natomiast jestem przekonany, że następnym razem pójdzie mi znacznie lepiej.
Chyba że zamiast 60 osób przyjdzie 120 😛
Sama organizacja wydarzenia stała na naprawdę wysokim poziomie i nawet mimo kilku wpadek myślę, że sam wykład wyszedł całkiem dobrze. Jeszcze raz dzięki i do zobaczenia niebawem!
