Autor: Piotr Wegert

W skomplikowanym związku z JIRĄ

Niedawno na blogu QAgile rozpoczął się bardzo fajny cykl artykułów o tym jak przy pomocy JIRy zabić zwinność. Tym razem kamyczek do Atlassianowego ogródka leci ode mnie *sploooonk*

Ponad 9 lat zajęło Atlassianowi dodanie funkcjonalności, która pozwala edytować zapisane filtry i pulpity (dashboards) przez kogokolwiek innego niż ich twórcę. Nawet admin nie mógł tego zrobić wprost, musiał zmienić ownera i dopiero nowy owner mógł cokolwiek edytować 🤦‍♂️🤦‍♂️🤦‍♂️

Okej, ale co to ma wspólnego z zabijaniem zwinności, poza tym, że sam Atlassian jest zwinny jak Gojira xD? Ano to, że tak mało elastyczne narzędzie nakłada spore ograniczenia na samoorganizujące się zespoły.

1) Jeśli tylko jedna osoba może edytować filtry i pulpity z burndown chartem i innymi gadgetami to w przypadku jej nieobecności zespół na dzień dobry ma problem.

2) Jeśli tylko jedna osoba ma prawa edycji to dużo bardziej prawdopodobne, że odpowiedzialność za wszelkie zmiany spadnie na Scrum Mastera jako, że popularne rozwiązanie w w postaci rotowania takiej odpowiedzialności w Zespole Developerskim odpada z powodu zbyt dużego narzutu.

Pomarudziłem to teraz idę świętować rozwiązanie JRASERVER-17783 🍾🥂
https://jira.atlassian.com/browse/JRASERVER-17783

pic: zdjęcie przedstawia mocno wyidealizowany obraz mojej relacji z JIRą

Scrum Values na retrospekcji

Tym razem krótko w temacie pięciu wartości, na których opiera się Scrum.

Prawie równo dwa lata temu Scrum Values oficjalnie weszły do Scrum Guide’a, choć wcale nie były nową koncepcją. Pierwszy raz pojawiły się… w pierwszej (i mojej ulubionej) książce o Scrumie „Agile Software Development with Scrum” (https://amzn.to/2fEZcQ5) i od tamtego czasu orbitowały wokół trzech filarów Scruma: transparencji oraz inspekcji i adaptacji.

Model osobowości „Big 5” a gust muzyczny

Czytam ostatnio dużo o osobowości i temperamencie (do egzaminu z Różnic Indywidualnych 😱) i przypadkiem wpadłem na świeżutkie badanie zestawiające cechy osobowości modelu „Big 5″… z gustem muzycznym.
 
Oczywiście ma ono swoje niedociągnięcia metodologiczne, ale wytycza kilka kierunków wartych dalszego zgłębienia. No to jedziem:
 
🔸Openness (Otwartość na doświadczenia) – osoby o wysokiej otwartości na doświadczenia preferowały muzykę o złożonej strukturze
🔸Conscientious (Sumienność) – wyniki na skali sumienności jako jedyne nie dały żadnych ciekawych wniosków czy predykcji
🔸Extraversion (Ekstrawersja) – ekstrawertycy, co może się wydawać zaskakujące, preferowali muzykę raczej spokojną, nie przekombinowaną w formie, akustyczną
🔸Neuroticism (Neurotyzm) – neurotycy ocenili większość prezentowanych kawałków jako słabe…
🔸Agreeableness (Ugodowość) – …a osoby o wysokiej ugodowości większość jako fajne
 
Wiadomo, że największa frajda to odnieść te odkrycia do siebie i zobaczyć czy się zgadza 😉 ;] Więc muszę przyznać, że nawet się zgadza (choć nie zapominam o Efekcie Barnuma :D), szczególnie jeśli chodzi o niski neurotyzm i wysoką/średnią ugodowość i otwartość na doświadczenia. Poza nu-metalem lubię chyba każdy gatunek muzyki, a połamańce jak math rock czy IDM w szczególności 🙂 Ciężko mi natomiast cokolwiek powiedzieć odnośnie ekstrawersji bo na tej skali mam wynik przeciętny. Sumienność też przeciętna, ale tu i tak badanie nic ciekawego nie pokazało ¯\_(ツ)_/¯
 
 

Link do oryginalnego badania: http://journals.sagepub.com/doi/abs/10.1177/0956797618761659

Źródło obrazka w nagłówku: By Anna Tunikova for peats.de and wikipedia [CC BY 4.0 (https://creativecommons.org/licenses/by/4.0)], via Wikimedia Commons

Code Review – dlaczego tak trudno o dyscyplinę?

Jest wiele powodów, dla których utrzymanie dyscypliny i regularność przeprowadzania inspekcji kodu nie jest zadaniem łatwym. W tym krótkim wpisie chciałem przyjrzeć się bliżej jednemu, ale za to takiemu, którego miałem okazję doświadczyć z trzech różnych perspektyw.

Czytaj dalej Code Review – dlaczego tak trudno o dyscyplinę?

R. I. P. Mike Beedle

To będzie krótki i smutny wpis. Mike Beedle, jeden z sygnatariuszy Agile Manifesto i współautor najważniejszej książki o Scrumie został zamordowany 23 marca 🙁

„Agile Software Development with Scrum” jest pełna odniesień do filozofii nauki (Kuhn), ewolucjonizmu (Dennett) czy teorii złożoności (Holland). Mike Beedle był gorącym zwolennikiem poglądu, że przejście z podejścia zdefiniowanego (Waterfall) na podejście zwinne, empiryczne (Scrum) spełnia kryteria rewolucji naukowej i zmiany paradygmatu w rozumieniu przedstawionym przez Thomasa Kuhna w książce „Struktura rewolucji naukowych”.

Śmierć Mike’a to ogromna strata dla społeczności 🙁

Poniżej link do zbiórki ze wsparciem dla rodziny: https://www.gofundme.com/mikebeedlesupport?lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3B48aBFqgbSU6sjXR7EKT%2Fdg%3D%3D

Stack Overflow Developer Survey 2018 okiem Scrum Mastera

Ósmy rok z rzędu Stack Overflow publikuje wyniki ankiety przeprowadzonej wśród członków społeczności. Poniżej mój subiektywny wybór pięciu najciekawszych spostrzeżeń z perspektywy Scrum Mastera.

Czytaj dalej Stack Overflow Developer Survey 2018 okiem Scrum Mastera

Ochrzan mobilizuje. Pochwały demotywują. Homeopatia działa.

Ochrzan mobilizuje

„Grubiorze mieli fatalny Sprint. Nie dostarczyli praktycznie nic. Velocity = 3. Porażka. Ale wystarczyło, że konkretnie ich ochrzaniłem i nastraszyłem, żeby w kolejnym Sprincie było już ok. Myślę teraz, żeby dawać im lekki, ale regularny ochrzan co Sprint.”

Rafał (44 l.), Product Owner w zespole „Grubiorze”

Czytaj dalej Ochrzan mobilizuje. Pochwały demotywują. Homeopatia działa.

Cone of uncertainty

Cone of uncertainty (czyli rożek/stożek/lejek niepewności) w większości publikacji związanych z zarządzeniem projektami definiuje się jako krzywą obrazującą następującą obserwację: „to jak dużo będzie kosztował projekt, jesteśmy w stanie tym dokładniej oszacować, im na dalszym etapie realizacji tego projektu jesteśmy”. A zatem, na początku rozrzut szacunków jest ogromny i maleje aż do osiągnięcia (teoretycznie) pełnej dokładności na końcu projektu. Szeroki na początku lejek niepewności zwęża się do zera wraz z upływem czasu.

Cone of uncertainty
źródło: http://www.agilenutshell.com/cone_of_uncertainty

 

Istnieje jednak druga definicja (nie druga interpretacja tego samego zjawiska), mniej znana, choć mi osobiście bliższa, mówiąca, że z perspektywy teraźniejszości im dalej chcemy zerkać w przyszłość, z tym większą niepewnością musimy się mierzyć, przede wszystkim, jeśli chodzi o to, co w ogóle będziemy robić. Tym razem, wąski na początku stożek niepewności rozszerza się wraz z okienkiem czasowym, stanowiącym granicę tego jak daleko w przyszłość sięgamy w naszych przewidywaniach.

Cone of uncertainty

W tym krótkim wpisie chciałbym odrobinę bliżej przyjrzeć się obu definicjom, podkreślając jeszcze raz, że nie do końca są to konkurujące interpretacje tego samego zjawiska, a raczej dwie różne obserwacje.

Czytaj dalej Cone of uncertainty

Nexus Guide 2018 – zmiany okiem młodego Scrum Mastera

Częstym zarzutem w stronę twórców Scruma jest to, że promując wartości płynące z częstej inspekcji i adaptacji, sami nie stosują się do swoich zaleceń i zmiany do frameworka wprowadzane są bardzo rzadko. Faktycznie przez pewien czas można było odnieść takie wrażenie, ale ostatnio pod wpływem ożywionych dyskusji na stronie Scrum Guide – User Voice, dostaliśmy uaktualnienie Scrum Guide’a (listopad 2017), a kilka dni temu Nexus Guide’a, czyli przewodnika po tym, jak skalować Scruma na 3 do 9 zespołów pracujących nad jednym produktem. O zmianach do Nexus Guide kilka słów poniżej.

Czytaj dalej Nexus Guide 2018 – zmiany okiem młodego Scrum Mastera

Memiczny Planning Poker

Z lekką obsuwą, ale są – memiczne karty do estymacji zadań metodą Planning Poker ®.

Karty warto wydrukować na twardszym papierze, w formacie większym od A4 (np. B4), koniecznie na drukarce dobrze radzącej sobie z dokładnym wydrukiem dwustronnym (inaczej brzegi kart z przodu i z tyłu nie będą się pokrywać).

PDF do druku: Planning-Poker-Memes.pdf

Przód:

Czytaj dalej Memiczny Planning Poker