Month: Styczeń 2018

Dziel i zwyciężaj

Jest taka strategia w projektowaniu algorytmów “Dziel i zwyciężaj”. Polega na tym, że problemy dzielimy na mniejsze, które rozwiązać łatwo i łączymy ich rozwiązania – tak aby rozwiązać większy problem.

Z jej pomocą zaprojektowane są wszystkie szybkie algorytmy sortowania – chyba najpowszechniejszego problemu, o dużej złożoności obliczeniowej. Strategia ta jest skuteczna w przypadku komputerów. Czy nie będzie jeszcze skuteczniejsza w przypadku ludzi, którzy mają dużo mniej pamięci operacyjnej, a część z niej i tak jest wykorzystana na ważkie problemy: “co robi moja dziewczyna” i “co będzie na obiad”?

Opowiem dzisiaj historię, która może rzucić nieco więcej światła na pewien problem.

Byłam młodym Scrum Masterem. Mój zespół łączył pracę wykonywaną w dwóch technologiach, z których jedna była dla mnie całkowicie obca. Ciężko mi było z nimi polemizować kiedy mówili:

  • Nie da się tego podzielić.
  • W tym narzędziu zaczynasz zawsze od początku.

Ukończenie jednej funkcjonalności, którą można było zaprezentować na Przeglądzie Sprintu zajmowało im 2 do 3 Sprintów.

Próbowałam robić z nimi Elephant Carpacio – świetne ćwiczenie, które często robię na szkoleniach – pokazujące o co chodzi w dzieleniu zadań. Wysyłałam im artykuły, które pokazują techniki podziału. Jest ich mnóstwo. Piszą o tym polskiezagraniczne mądre głowy. Można znaleźć nawet gotowe plakaty do powieszenia, które pokazują jak dzielić zadania. Nic nie działało… dopóki nie usłyszałam o statystyce, którą można w prosty sposób wyciągnąć z Jiry. Z historii zespołu (polecam wziąć ostatnie pół roku) wyciągamy jakiej wielkości zadania zespół dostarczał oraz z jaką skutecznością. W zespole, o którym opowiadam, używano jednostki Story Point oraz ciągu Fibonacciego. Wyszło coś takiego:

Wspomagająco, zrobiłam jeszcze dwa wykresy.  Pierwszy pokazywał ile zadań określonej wielkości zespół przewidział że dostarczy.

Drugi ile punktów realizowane było w ramach zadań określonej wielkości, czyli ile zadań określonej wielkości razy ich wielkość.

Widać wyraźnie, że najwięcej punktów było realizowane w ramach wielkości zadań, które wiążą się z najmniejszą skutecznością.

Rozdałam zespołowi te dane na początku Planowania Sprintu, mówiąc:

  • Przygotowałam Wam małą statystykę.

Zespół z uwagą przyglądał się kartkom, przez dobrych kilka minut. Padło kilka pytań:

  • A skąd te dane wzięłaś?
  • Z jakiego okresu?

Planowanie Sprintu przebiegł typowo, ale już na następnym spotkaniu w ramach procesu refinementu sami, bez żadnej mojej sugestii zaczęli szukać sposobów na podzielenie zadań. Nigdy więcej nie wzięli zadania wielkości 21 (ani większego). Skuteczność poszybowała wysoko.

Na podstawie tej krótkiej historii śmiem twierdzić, że problemy z podziałem często nie są związane z tym, że zespół nie wie jak podzielić zadań na mniejsze. Problem polega na tym że zespół nie czuje po co mieliby się tak męczyć (tak, to jest trudniejsze), więc nawet nie szuka tych sposobów.

Dalsza część dla tych, którzy są ciekawi jak to wygląda od strony technicznej.

Dlaczego dzielenie zadań jest tak ważne z technicznego punktu widzenia? Otóż dlatego, że  najwięcej niespodzianek jest na łączeniu warstw. Np. okazuje się, że baza danych nie ma funkcji, której się spodziewaliśmy albo, że jednak inna funkcja byłaby tu wygodniejsza. Zakładaliśmy że jedna warstwa zwróci nam dane określonego formatu, a ten format jest odrobinę inny – na tyle inny, że ta następna warstwa nie ma gotowej metody obsługi tego formatu.

Jak widać może się pojawić mnóstwo drobnych problemów, które razem sprawiają, że koniec Sprintu zaskakuje nas jak zima drogowców, z połową zadań nieskończonych. Dlatego warto połączyć wszystkie warstwy jak najszybciej się da, zaprezentować wynik połączenia interesariuszom i sprawdzić, czy aby i ich coś nie zaskoczy w tym co zobaczą.

Zasada jest prosta. Jeżeli da się zrobić mniej, aby połączyć warstwy, zrób mniej i sprawdź czy warstwy do siebie pasują. Czas, który oszczędzamy robiąc więcej w ramach jednej warstwy, czyli:

“A jak już tu jestem, to jeszcze to zaimplementuje, przecież i tak będzie potrzebne”.

W ogromnej ilości przypadków taki czas, jest czasem straconym lub wręcz szkodliwym. Bo:

“No jak już zrobiłem to zostawię, mimo że teraz widzę jak można to zrobić lepiej”.

Zobaczmy to na przykładzie. Kaziu chce zrobić narzędzie do wyświetlania naszej małej statystyki opisanej w powyższym przykładzie. Eksportuje dane z JIRY. Spędza 5 godzin na rozgryzaniu Jirowego Excela i wyświetleniu odpowiednich danych na konsoli. Potem szuka czegoś co wyświetli wykresy. W końcu  znalazł. Wykresy wyglądają okropnie, a już minęła godzina. Następne dwie godziny szuka innego narzędzia do rysowania wykresów. W końcu znalazł narzędzie, które ma specjalny moduł do czytania eksportu z Jira. Super! Teraz poszło szybciej. I wykresy wyglądają obłędnie. Zrobił narzędzie w 1,5 dnia pracy. Pokazuje Właścicielowi Produktu, a on na to:

  • I za każdym razem trzeba mu dać dane z Jiry? Nie da się tego wyświetlić bezpośrednio w Jira? Wolałbym tak.

Sprawdza. Pewnie że się da! 1.5 dnia pracy do kosza. A co jakby na konsolę wyrzucił sobie dane tylko do pierwszego wykresu, zrobił wykres, od razu pokazał ten pierwszy nieszczęśliwy wykres Właścicielowi Produktu? Po dwóch godzinach pracy wiedziałby, że idzie w złą stronę i oszczędził ponad dzień pracy.

Jeżeli masz problem z dzieleniem zadań pomyśl o tym tak: jeżeli możesz napisać dwa osobne testy funkcjonalne do danego zadania, możesz podzielić zadanie. Nie musisz, ale  możesz. Zrób dla swojego zespołu statystykę opisaną powyżej, a dowiesz się, że naprawdę wielu przypadkach warto.

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

Warunki dobrej retrospekcji: 1 poczucie bezpieczeństwa.

Uwaga: wdrażamy Scruma. Wprowadzamy Planning, Daily, Retro, całą tę resztę i… tadam! Zrobiliśmy to! Premia się należy.

Tylko okazuje się, że w sumie to dostarczamy jeszcze mniej niż wcześniej… Ten Scrum nie działa…

Zdradzę Wam sekret. Siedzenie na spotkaniach nie sprawi, że będzie szybciej. Samo siedzenie na spotkaniach sprawi, że będzie wolniej, nie tylko o tyle, ile trwa spotkanie, ale jeszcze wolniej, bo ludzie przerywają pracę i nudzą się, a nuda spala więcej energii niż praca.

Scrum to przede wszystkim trzy filary: transparencja, inspekcja i adaptacja. Jak nie są stosowane w praktyce, Scruma nie ma.

Jedną z okazji do ich zastosowania jest Retrospekcja Sprintu. Na Retrospekcji inspekcji podlega proces i interakcje, które wchodzą w jego skład. Nie każdy ma na to ochotę, dlatego tak wiele jest Retrospekcji, na których rozmawiamy prawie jak o pogodzie:

  • No to podajcie minusy tego Sprintu.
  • Czajnik znowu nie działa, to już trzeci się popsuł.
  • Jest dużo literówek w Jirze.
  • Daily trzeba przesunąć na 8:45, bo pan z kanapkami nam ucieka.
  • Nie, ja nie wstanę tak wcześnie.

I tak dalej… Fajnie się rozmawia, tylko że z takich Retrospekcji można zrezygnować i nic się nie zmieni. Może skorzystamy z innej okazji do inspekcji i adaptacji, a może będziemy jeździć na kwadratowych kołach jeszcze przez parę lat, narzekając na to, że “Scrum nie działa”.

Z drugiej strony dobra Retrospekcja może przynieść pomysł, który sprawi, że będziemy działać kilka razy szybciej. Jak więc zrobić dobrą Retrospekcję? Pierwszym warunkiem jest:

Poczucie bezpieczeństwa

I to na nim się dzisiaj skupimy.

Żyjemy w niesłychanie bezpiecznym świecie. Na Retrospekcje zwykle przychodzimy do ciepłego miłego pokoju. Jesteśmy najedzeni. Nic nas nie goni. Czy możemy mieć problem z bezpieczeństwem?

Oczywiście, że tak! Przecież nadal jesteśmy uzbrojeni w radar, który w czasach jaskiniowych zapewniał nam bezpieczeństwo. Jest tam, czy tego chcemy, czy nie i jeżeli nasz stary gadzi mózg, który nie ma absolutnie nic wspólnego ze świadomością, uzna, że jest jakieś zagrożenie, to możemy zapomnieć o dobrych pomysłach.

Nasz mózg pracuje w czterech trybach:

  1. Tryb: oczywiste zagrożenie – nasze zmysły są maksymalnie wyostrzone, uwaga skupiona na oczywistym zagrożeniu, szare komórki pracują jak szalone, aby uniknąć zagrożenia. Krew zasila mięśnie. Kreatywność kompletnie wyłączona – jest bowiem za wolna, a w tym momencie trzeba działać. Cel: przetrwać.
  2. Tryb: coś tu nie gra – nasz umysł podejrzewa zagrożenie, ale nie jest ono oczywiste. Szuka i jednocześnie zachowuje ostrożność, stawia opór. Opóźnia wszelkie akcje do momentu przywrócenia bezpieczeństwa, zużywa energię na analizę otoczenia. Cel: przywrócić bezpieczeństwo lub przeczekać. 
  3. Tryb: zadaniowy – jest trybem domyślnym, powszechnym i przejściowym, jesteśmy w nim, kiedy idziemy po zatłoczonej ulicy, spotykamy się ze znajomymi; w tym trybie większość osób wchodzi na spotkanie. Od tego co będzie się tam działo, zależy czy przejdzie do trybu 4 czy 2. Cel: wykonać konkretne zadanie. Np. dostać się spotkanie, zrobić zakupy, wyspać się, odpocząć.
  4. Tryb kreatywny – to tryb w którym czujemy się dobrze ze sobą i w środowisku, w którym jesteśmy. Możemy tworzyć i być kreatywni. Nic nie blokuje nas przed całkowitym skupieniem uwagi, otwartym wyrażaniem myśli, wolnym i twórczym myśleniem. Cel: zrobić coś fajnego. Na przykład coś, co zależy od tego, co jest dla nas ważne i ekscytujące w tym momencie. To może być znalezienie sposobu na automatyzację produkcji, własnoręczne zrobienie prezentu, szczera rozmowa z przyjacielem w kłopocie.

Optymalnym trybem do inspekcji i adaptacji jest tryb 4. W trzech pozostałych chemia naszego mózgu blokuje kreatywność. Wchodzimy na Retrospekcję w większości w trybie 3. Jeżeli sytuacja okaże się komfortowa przejdziemy w tryb 4, jeżeli niekomfortowa w tryb 2, a nawet 1.

Tylko raz widziałam zespół który pracował w trybie 1 na Retrospekcji. Szef przyszedł wyrazić swoje zdanie na temat Sprintu, co doprowadziło do otwartego konfliktu. Konieczność unikania tego trybu jest dość oczywista. Zajmijmy się więc trybem 2: coś tu nie gra, który jest bardziej podstępny i powszechny.

Wyobraźmy sobie taką sytuację. Mamy całkiem niezłego Scrum Mastera w firmie, w której jest problem z salkami konferencyjnymi. Aby móc przeprowadzić retrospekcję Scrum Master załatwił pokój na piętrze zarządu. Ściana z drzwiami jest przeszklona. Cała śmietanka firmy kręci się za szybą. Scrum Master jest dobrze przygotowany, ma fajny pomysł na Retrospekcję, ale ludzie patrzą w podłogę, mają ręce w kieszeniach, słabo się angażują. Jakoś cicho rozmawiają. Nie ma żartów jak zwykle. Scrum Master myśli: co ja robię źle? Pyta ludzi:

  • Widzę, że dzisiaj mniej angażujecie się w zadania, czy coś Wam przeszkadza?
  • Chyba jesteśmy zmęczeni, po Review tego Sprintu.
  • Mamy dużo pracy w tym Sprincie, może dajmy dzisiaj spokój z Retrospekcją.
  • Może skoczymy na obiad? W pizzerii dzisiaj druga pizza gratis.

Scrum Master jest skołowany. Przecież ten zespół lubi Retrospekcje. Co się stało?

Zespoł może nawet nie zauważyć, że dyskomfort jest związany z pokojem i całkiem szczerze powiedzą, że po prostu są zmęczeni i chcą już skończyć. To nieświadoma część mózgu zawiaduje tym, w którym trybie pracujemy.

Wielu młodych Scrum Masterów pomyśli w takiej sytuacji, że po prostu zaproponowali nudne ćwiczenie, a prawda jest taka, że ich zespół wpadł w tryb 2.

A w trybie 2 mózg pracuje nad tym, aby wrócić do trybu 3 lub przeczekać (wytrzymać do końca). Nie ma mowy o prawdziwej koncentracji na Retrospekcji.

Co może sprawić, że zespół wpada w tryb 2?

  • Obecność kogoś, kto ma wpływ na ich pensje.
  • Obecność kogoś, kogo się boją.
  • Prowadzący spotkanie, któremu nie ufają.
  • Duży dyskomfort fizyczny: zimno, głód, słaba wentylacja.
  • Próba zmuszenia zespołu do wyjścia ze strefy komfortu, na którą nie są gotowi, np. ćwiczenie, w którym klepiemy się po kolanach, mówimy o swoich największych słabościach.

Oczywiście nie uda się nam zawsze przewidzieć, co będzie powodem wpadnięcia zespołu w tryb 2, ważne jest więc, aby umieć go zauważyć. Czego szukać?

  • unikania,
  • oporu,
  • oznak znudzenia,
  • unikania kontaktu wzrokowego,
  • oczekiwania na zakończenie spotkania.

A jak zauważymy, to co?

  1. Poszukaj przyczyny dyskomfortu i usuń ją. Np. zapalając światło, zamykając drzwi, zmieniając ćwiczenie. Jak nie masz pomysłu, to możesz zrobić krótką przerwę na przemyślenie.
  2. Jeśli to nie pomoże, to po prostu zapytaj uczestników spotkania, o co chodzi. Ludzie bardzo doceniają to, że prowadzący dostrzega ich sytuację i reaguje na dyskomfort.
  3. Zdecyduj z zespołem co dalej:
    1. usuwacie dyskomfort,
    2. czy kończycie spotkanie na dzisiaj. (Jeżeli jako facylitator wypuścisz ludzi, którzy się źle czują i na następny raz przygotujesz się lepiej, bardzo to docenią).

Co zrobić aby doprowadzić do trybu 4? Po pierwsze

PRZYJŚĆ PRZYGOTOWANYM!

A w tym:

ZAPEWNIĆ KOMFORTOWE, PRYWATNE, BEZPIECZNE ŚRODOWISKO

Po drugie:

PRZYJŚĆ W DOBRYM NASTROJU I Z WŁASNYM DOBRYM NASTAWIENIEM

Bo jeżeli prowadzący jest w trybie 2, to uczestnicy niemal automatycznie też w niego wpadną.

Czy to już wystarczy, aby mieć fajną Retrospekcję? Niestety, nie. To tylko warunek konieczny. Kolejne warunki opiszę w następnych artykułach.

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

© 2018 Brass Willow Blog

Theme by Anders NorenUp ↑