W szkole średniej poznałem – przynajmniej od strony filozoficznej dzięki Erichowi Frommowi – problem ucieczki od wolności. Gdy znalazłem się na tzw. ławce projektowej zacząłem odczuwać ten problem dość dotkliwie w praktyce. Bycie poza projektem oznacza jednocześnie konieczność odnalezienia się w sytuacji totalnej wolności lub inaczej rzecz ujmując: w strukturalnej próżni. Jeszcze kilka dni temu od rana śledziłem poczynania mojego zespołu i byłem w gotowości, by wkraczać do akcji tam gdzie to potrzebne, a tu z dnia na dzień nagła pustka.
Scrum – jak zresztą każda inna metodologia prowadzenia projektu – nakłada pewien rytm pracy, czyli de facto pewnego rodzaju strukturę. Ta struktura jest dodatkowo wzmacniana przez zespół: pokusa wyłamania się z ustalonych zasad i reguł, np. by nie zrobić Daily Scruma albo oddać się prokrastynacji, jest skutecznie gaszona w zarodku przez sam fakt, że ustalone zasady są egzekwowane kolektywnie, a człowiek pod wpływem presji społecznej z łatwością podda się obowiązującym regułom. Dobrze zgrany zespół jest najlepszym strażnikiem i wspomagaczem wzajemnej produktywności.
Znalezienie się w sytuacji bez projektu i bez zespołu – co w przypadku Scrum Mastera może skutkować szczególnie dotkliwym poczuciem odłączenia od bodźców społecznych – w naturalny sposób wykreowało we mnie potrzebę nałożenia na siebie samego nowej struktury. Struktury na tyle elastycznej, by z jednej strony stawać się bardziej produktywnym i kreatywnym, a jednocześnie na tyle rygorystycznej, by nie wpaść w sidła pokusy nieskończonej prokrastynacji. Tak się zrodził pomysł, by samemu na sobie wypróbować zasad Scruma, czyli by uchwycić esencję tej metodologii i zaaplikować ją do tej nietypowej sytuacji, w której przychodzi człowiekowi działać w pojedynkę w bliżej nieokreślonym celu przez bliżej nieokreślony okres czasu.
Purystów metodologicznych spieszę uspokoić: oczywiście Scrum w przypadku działania w pojedynkę nie jest prawdziwym Scrumem. Słowo zostało w tym tekście użyte ze świadomością łamania podstawowej zasady, że prawdziwy Scrum można tylko stosować w zespołach, tj. z definicji w kolektywach wieloosobowych. Krótki research haseł takich jak individual scrum, scrum for one person, solo scrum itp wykazał, że podejść jest bardzo wiele i nie ma jakiejś jednej ugruntowanej metodologii w tym zakresie. Pewna brazylijska uczelnia techniczna opublikowała nawet artykuł naukowy pod nazwą “Scrum Solo”, ale z przyczyn technicznych pomijam go w niniejszym tekście. Sam tytuł należy zatem traktować z przymrużeniem oka, tzn. zamiast próby stworzenia uniwersalnej metodologii dla osób pracujących w pojedynkę, jest to raczej opis doświadczeń związanych z szukaniem sposobu na zachowanie produktywności i satysfakcji zawodowej w okresie pracy indywidualnej.
W pierwszym tygodniu po zakończeniu pracy w projekcie przede wszystkim musiałem odnaleźć się w nowej rzeczywistości bez projektu i znaczącą część czasu musiałem poświęcić na tzw. rozruch. Trochę to przypominało wchodzenie do nowego projektu, tylko że tym razem zamiast poznawania innych ludzi na pierwszym planie było poznawanie samego siebie, a zamiast otrzymania dostępów do różnych niezbędnych softwarów używanych w projekcie, po prostu musiałem sobie stworzyć zupełnie nowe zwyczaje i strukturę pracy.
Kluczowym wydarzeniem, które pomogło mi przyspieszyć odnalezienie się w nowej sytuacji w pierwszych dniach totalnej reorganizacji, to nawiązanie kontaktu z pozostałymi Scrum Masterami będącymi, przynajmniej połowicznie, na ławce i zorganizowanie spotkań o charakterze zbliżonym do Daily Scruma, które daje namiastkę poczucia pracy w zespole. Codzienne półgodzinne spotkania, które poza inspiracją do działania oraz możliwością udzielenia sobie wzajemnej pomocy przede wszystkim umożliwiają wypowiedzenie na głos własnych myśli, co w przypadku pracy solo – na dodatek w czasach pandemii na home office – wydaje się dość istotne.
Zainspirowany znaczeniem werbalizowania własnych myśli spośród różnych rad i zestawów praktyk, które w większym lub mniejszym stopniu nawiązują do Scruma, moją uwagę przykuła metodologia opisana przez Alex Andrews jako Scrum of One (SO) na stronie raywenderlich.com. Jest to framework, który w umiejętny sposób wyciąga ze Scrum Guide’a esencję i transponuje ją na warunki, w jakich trzeba funkcjonować w pojedynkę. Ten framework bazuje na trzech podstawowych zasadach:
Ciekawą myślą w przypadku ship and share jest sugestia, aby możliwie szeroko myśleć o potencjalnych stakeholderach. Tzn. nie tylko użytkownicy końcowi muszą być osobami, którzy mogą nam dać cenny feedback. Równie dobrze może być to tester, przełożony lub znajomy. Po prostu nie ma co zwlekać z otrzymaniem cennej informacji zwrotnej na temat własnego pomysłu. Jeśli będą przeważać uwagi krytyczne – czego prawdopodobnie obawia się większość z nas – to lepiej ją usłyszeć na samym początku, gdy jeszcze możemy te uwagi uwzględnić w naszym planie.
W przypadku autorefleksji autor podaje bardzo ciekawy sposób na poddawanie się jej w pojedynkę. Jako że ‘rozmowa’ z samym sobą jest dość trudna, proponuje nagrywanie codziennie krótkiego wideo w ramach daily scruma, podczas którego mówisz, co zrobiłeś wczoraj, co zamierzasz zrobić dzisiaj i co Ciebie blokuje. Według autora nagranie powinno być krótkie (poniżej 45 sekund), natomiast po kilku dniach próbowania tej metody na samym sobie mogę stwierdzić, że nie o samą długość tutaj chodzi, lecz o bycie wiernym wartościom Scruma, czyli bądźmy zaangażowani, odważni i otwarci w tym co mówimy, skupieni na jasności przekazu i przy okazji samemu sobie okażmy szacunek. W końcu mówimy do samego siebie i dla siebie, a że kolejnym krokiem będzie odsłuchanie tego nagrania kolejnego dnia, nie musimy się sami siebie wstydzić, ani zbytnio ganić za niedotrzymanie planu.
Przeprowadzenie daily z samym sobą bazuje na trzech czynnościach na ‘r’: review, reflect & rehearse Kluczowym punktem w metodzie Scrum of One to możliwość zobaczenia siebie samego 24 godziny po ostatnim nagraniu i zweryfikowania swoich założeń (Review). Mamy tu do czynienia ze scrumowym inspect and adapt w swej najczystszej postaci. Im bardziej będziesz szczery ze sobą, tym lepszych efektów tej metody możesz się spodziewać. Oczywiście, co sam autor podkreśla dobitnie i co jest mocno związane z okazywaniem samemu sobie szacunku – nie bądź zbyt surowy wobec siebie, jeśli plan się nie powiedzie. To zupełnie naturalne, że robimy błędy w estymacjach i tak jako zespół, tak też w pracy indywidualnej można się pomylić w założonym tempie pracy i złożoności zadań.
Najważniejsze jest zastanowienie się nad prawdziwą przyczyną niewykonanego planu i wyciąganie wniosków z popełnionych błędów, a jest ku temu okazja każdego dnia na nowo (Reflect). Autor poleca jeszcze przed nagraniem kolejnego Daily Scruma przygotowanie się przez jakieś 1-2 minuty. Całość powinna zamknąć się w 5 minutach. Brzmi na czas zbyt krótki, by faktycznie wprowadzić realne zmiany w swoim sposobie pracy? Jeśli przeprowadzisz to sumiennie (o czym się sam przekonałem na własnej skórze), może to być najważniejsze 5 minut Twego dnia i w taki sposób można każdego dnia małymi kroczkami poprawiać własny styl pracy.
Jak pracujesz sam, powinieneś w pewnym momencie odejść od komputera i od spraw bieżących, by dać sobie chwilę na spojrzenie na swoją pracę z lotu ptaka. Autor SO sugeruje, by poświęcić na ten event raz w tygodniu od 30 do 45 minut i de facto jest to dodatkowy event, jeśli porównujemy to bezpośrednio do Scrum Guide. Najbliżej mu do Backlog Refinementu, podczas którego możemy się zastanawiać nad przyszłymi sprintami. Jest to okazja, by dla samego siebie ubrać czapkę Product Ownera i zastanowić się, co właściwie chcę osiągnąć i do czego chcę zmierzać w przyszłości? Może będzie to optymalizacja produktu, może nowy feature, a może – co bardziej prawdopodobne i adekwatne w przypadku pracy o charakterze Scrum Mastera – coś mniej uchwytnego w stylu zwiększenie osobistej produktywności i satysfakcji z wykonywanej pracy lub znalezienie skutecznego sposobu na rozwiązywanie konfliktu w zespole?
Nieodzownym elementem każdego sprintu, także tego prowadzonego w pojedynkę – jest pokazanie produktu zewnętrznym stakeholderom. Niezależnie od tego, nad czym pracujesz, spróbuj to pokazać komuś, kto może być potencjalnie zainteresowany Twoją pracą lub od kogo możesz dostać wartościowy feedback, przy czym nie musi to być ani kolega po fachu, ani ktokolwiek z Twego świata zawodowego. Po prostu pomyśl o kimś, kto pomoże Ci spojrzeć na Twoją pracę bardziej obiektywnie i komu ufasz na tyle, by się nie wstydzić ani pokazać efektów pracy, ani przyjąć (ewentualnie trudnego) feedbacku. Informacje zwrotne w oczywisty sposób pomogą nam zaplanować kolejny sprint i skorygować (lub przynajmniej dostrzec) ewentualne własne błędne założenia.
Kolejną ceremonią, oczywiście w pełni analogiczną do tej, która jest opisana w Scrum Guidzie, jest Retrospekcja. Autor SO rekomenduje poświęcić na to dwie godziny, aczkolwiek szczerze mówiąc chyba wliczył w to w dużej mierze czas na kontemplację (np. podczas spaceru). W wersji bardziej skromnej, tj. samemu przy komputerze (używałem do tego eksperymentalnie aplikacji Miro, ale możesz skorzystać z dowolnej aplikacji tudzież nawet tradycyjnego papierowego notesu), całość zamyka się w maksymalnie pół godzinie. Podczas solo retro próbujesz spojrzeć na miniony sprint z podobnej perspektywy, jak podczas ‘normalnego’ retro zespołowego.
Z uwagi na brak zespołu oczywiście nie ma mowy o jakiejkolwiek dyskusji. W ramach zastępczej ‘dyskusji’ można obejrzeć wszystkie swoje nagrania z minionego tygodnia, co da podstawę, by zmierzyć się samemu ze sobą i wychwycić ewentualne obszary do poprawy. Podczas tego solo retro próbujesz sobie tradycyjnie odpowiedzieć na pytania: co poszło dobrze w minionym sprincie? Które cele osiągnąłeś? Co nie wyszło, co można poprawić? Zasadniczą różnicą pomiędzy tradycyjną retrospektywą, a retro wg metodyki Scrum of One jest próba uchwycenia dwóch wniosków na następny sprint:
jednego, który uczyni się bardziej produktywnym (np. zainstalowanie time trackera typu Rescuetime, by móc dokładniej przeanalizować własną aktywność podczas następnego retro),
jednego, który uczyni Ciebie bardziej zadowolonym (w moim przypadku było to postanowienie, by wyraźniej oddzielać czas pracy od czasu nie-pracy),
Jeśli istnieje taka możliwość, to rekomenduję przeformułować te wnioski na zadania, by je dodać do następnego sprintu podczas planowania.
Ostatni element udanego sprintu według metodologii SO to Sprint Plan. O ile retrospektywa w pojedynkę to zabieg jednak nieco karkołomny, o tyle planowanie w pojedynkę jest czynnością prostszą niż planowanie zespołowe. Warto rozpocząć spotkanie od estymacji według obranej przez siebie metodologii. Ja zastosowałem – tak samo jak autor – prostą skalę z ciągu Fibonacciego, tj. 1, 2, 3, 5 i 8. Nieważne jak sobie te punkty nazwiesz. Mogą to być story pointy, mogą to być sprint pointy lub punkty zadaniowe, jakkolwiek – Ty jesteś całym Scrum Teamem, więc masz pełnię władzy decyzyjnej.
Estymacja może wydawać się początkowo przesadzonym pomysłem, ale po moim pierwszym solo sprincie bez estymacji odczułem dość mocno jej brak, tj. nieznajomość swego velocity i przez to problem w oszacowaniu odpowiedniego zakresu dla kolejnego sprintu. Sam proces selekcji i priorytetyzacji jest oczywiście znacznie uproszczony w stosunku do procesu planowania zespołowego. Gdy uznasz, że nowy zakres sprintu jest kompletny, pozostaje już tylko sformułować cel sprintu i zaczynasz swój kolejny solo sprint.
Scrumowanie w pojedynkę ma – jak każda metodologia – swoje oczywiste wady i zalety. Jednym się sprawdzi bardziej, innym mniej. Dla mnie jako Scrum Mastera metodologia ta nakłada bardzo fajną, prostą strukturę i pomaga utrzymać jako taką ciągłość w obcowaniu ze światem Scruma, nawet będąc tymczasowo poza projektem. Produktywność i zadowolenie zależy od indywidualnego zaangażowania i wierności wartościom Scruma. Głównym benefitem metodyki proponowanej przez autora SO jest moim zdaniem nagrywanie samego siebie codziennie rano. To może się wydawać nieco osobliwe, gdy to czytasz, jeśli nigdy jeszcze nie prowadziłeś vloga lub czegoś podobnego, ale obserwowanie własnych, codziennych zmagań, naprawdę wiele uczy o samym sobie i gorąco do tego zachęcam – nawet jeśli pracujesz obecnie w zespole, warto zrobić to dla siebie w ramach tymczasowego eksperymentu.
Na koniec uwaga dodatkowa, że jeśli dokładnie przeczytasz metodykę SO opisaną na raywenderlich.com, zauważysz zapewne drobne różnice w stosunku do niniejszego artykułu. Wynika to z tego, że jak z każdą metodologią zwinną, warto ją dostosować do swoich indywidualnych potrzeb. Zamiast dwutygodniowych sprintów dla mnie sprawdził się sprint tygodniowy, a zamiast zamykania sprintu w piątek, wolę zrobić retro i planowanie w poniedziałek na początek tygodnia. Niewykluczone, że do kolejnych dewiacji dojdę w kolejnych tygodniach scrumowania w pojedynkę i mój system będzie ewoluował tak samo jak każdy dobry zespół scrumowy. Pamiętaj, że stosując SO to Ty jesteś jednoosobowym Scrum Teamem i to od Ciebie zależy, jak sobie ułożysz swoją rutynę.
Charles jest ciekawym narzędziem, które może okazać się pomocne w pracy testera. (więcej…)
W trakcie rozwoju oprogramowania niejednokrotnie zachodzi potrzeba wdrożenia projektu mimo istniejących, nierozwiązanych błędów. (więcej…)
Dzisiejszy rynek IT daje wiele możliwości zmiany ścieżki kariery, a zapotrzebowanie na specjalistów w tym obszarze nie maleje. Jednym z bardziej popularnych i jednocześnie najbardziej dynamicznie rozwijającym się zawodem jest tester oprogramowania. (więcej…)
Ostatnio dostałem kilka projektów – w kilku z nich miałem wprowadzić caching z powodu długiego oczekiwania na odpowiedź z serwera. (więcej…)
Zanim przejdziemy do głębszego omówienia tematu, musimy ustalić sobie pewne fakty i definicje. Zatem, czymże jest „infrastruktura jak kod” (infrastructure as code – IAC)? (więcej…)
Na co dzień zdarza się, że potrzebujemy łączyć rozwiązania SAPowe z odrębnymi systemami informatycznymi. W większości przypadków polega to albo na eksportowaniu, albo importowaniu jakiś danych. W obydwóch przypadkach potrzebujemy pewnych mechanizmów i technologii, które umożliwią nam takie działanie. (więcej…)
Jak sprawdzić, czy nasz sklep internetowy działa poprawnie? Czego może dotyczyć audyt e-commerce i na jakie elementy trzeba zwrócić uwagę? (więcej…)
How to check if your online store is working properly? What can an e-commerce audit concern and what elements should you pay attention to? (więcej…)
There are couple of existing ways how to authenticate one app to another when you create a distributed system. You can write your own identity service and use it across your apps.
But here Azure Active Directory comes with its great features I personally love. In this post, I will show you how to configure one of those flows.
