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!