Dlaczego warto dzielić pracę na małe części?

Twój zespół nie wyrabia się z zadaniami? Terminy gonią, górka staje się coraz większa. Może warto podzielić pracę na mniejsze kawałki? Dotyczy to zarówno dzielenia produktu na małe cząstki jak i dzieleniu czy wyróżnianiu różnych zadań. Dowiesz się jakie korzyści przynosi taki podział. Zebraliśmy na to aż dziesięć argumentów. Dodatkowo mamy kilka wskazówek na to jak zacząć tak działać, czyli jak wprowadzić dzielnie pracy na mniejsze elementy w swoim zespole.

Jak zjeść słonia? Podobno, najlepiej po kawałku. Warto w ten sam sposób podejść do pracy, jaką mamy do wykonania. Lepiej podzielić ją na mniejsze części, bo wiążę się z tym wiele korzyści, które opisujemy w tym artykule.

Poprzez wspomnianą w tytule “pracę” mamy na myśli produkt. Dlatego mówiąc o dzieleniu pracy, chcemy zwrócić Twoją uwagę na korzyści płynące z dzielenia dużych kawałków produktu na mniejsze elementy, które zespół ma wykonać. Można powiedzieć, że poruszymy temat Product Breakdown i korzyści z niego płynących. 

Dlaczego warto dzielić pracę na małe części?

Z naszej perspektywy korzyści płynące z dzielenia pracy na mniejsze elementy są następujące:

1. Łatwiej oddzielisz wartościowe elementy od mniej wartościowych

Jest to istotne zwłaszcza z perspektywy biznesowej czy z perspektywy wartości dodanej przez zespół. Wyobraźmy sobie, że mamy do zrobienia duży formularz w systemie. Jeśli ten formularz potraktujemy jako pojedynczy element, to nie jesteśmy w stanie odróżnić mniej i bardziej wartościowych jego części. Jeśli natomiast formularz ten rozdzielimy na mniejsze elementy, które są częściej używane przez użytkowników i na te rzadziej używane, to możemy wydzielić w nim obszary krytyczne dla biznesu i obszary opcjonalne. Te drugie są mniej istotne i mogą być przykładowo zrealizowane w późniejszym etapie lub całkowicie wyeliminowane, jeśli zajdzie taka potrzeba.

2. Podczas dzielenia odkryjesz niuanse pracy do wykonania

W praktyce zazwyczaj wygląda to w ten sposób, że w czasie dzielenia większego elementu, zaczynamy odkrywać, że na pewne pytania nie mamy jeszcze odpowiedzi, a będą nam one potrzebne i lepiej znaleźć te odpowiedzi przed rozpoczęciem prac.

Brakującą wiedzą mogą być jakieś szczegóły implementacji czy oczekiwań użytkowników. Mogą się tu kryć także jakieś uzasadnienia biznesowe lub ich brak, a wracając do przykładu z formularzem, może się okazać, że jednak konkretne pole czy przycisk nie są tak naprawdę niezbędne.

3. Prościej oszacujesz pracę

Mówimy tu o dwóch podejściach do szacowania. Z jednej strony, gdy rozpatrujemy mniejsze elementy produktu, to proces szacowania pracy i jej wyceny jest szybszy. Z drugiej strony, estymata, która uzyskamy, będzie trafniejsza i z mniejszą liczbą potencjalnych niedomówień czy  niespodzianek. 

4. Łatwiej rozdzielisz pracę wewnątrz zespołu

Mając więcej mniejszych kawałków, łatwiej jest rozdzielić pracę pomiędzy członków zespołów. Dzięki temu ciężar realizacji konkretnego zadania nie spoczywa na jednej osobie. Pozwoli to też skrócić Cycle Time. A w sytuacji, gdy trzeba będzie jeden z elementów produktu zrealizować wcześniej, to też będziemy mieć taką możliwość. 

Mniejsze elementy pozwalają też oddzielić bardziej skomplikowane do wykonania części i przekazać je do bardziej doświadczonych pracowników, od tych mniej skomplikowanych, które mogą być wykonane przez osoby z mniejszym stażem. 

5. Wygodniej zarządzisz małą porcją pracy

Gdy praca jest podzielona na mniejsze fragmenty, to łatwiej zrozumieć gdzie jesteśmy, jeśli chodzi o postęp pracy. Łatwiej zobaczyć te zadania, które są już faktycznie skończone, a także prościej jest przekazywać sobie pracę między członkami zespołu. 

Podczas codziennych spotkań szybciej też wychwycisz problemy niż w sytuacji, gdy ktoś ma tygodniowe zadanie na sobie, a my codziennie słyszymy tylko, że jest w trakcie pracy. Gdy porcja pracy nie jest np. większa niż jeden dzień, to w sytuacji, gdy coś się przedłuża, możemy szybciej zareagować.

6. Sprawniej opanujesz to, co jest do zrobienia

W szczególności mamy tu na myśli pracę, która jest wymagająca intelektualnie. Dotyczy to wytwarzania m.in. developmentu (wytwarzania produktów cyfrowych, pisania dodatkowych funkcjonalności), ale nie tylko. Gdy próbujemy zrobić duże zadanie na raz i ktoś coś będzie od nas chciał, to później tracimy czas, aby powrócić do miejsca, w którym nam przerwano. Jest to nie tylko czasochłonne, ale i stresujące. 

7. Szybciej wykonasz Code Review

Z doświadczenia wiemy, że zespoły, które realizują prace bardzo dużymi partiami, później mają też duży kłopot ze zrobieniem przeglądu kodu. Jest tego kodu po prostu za dużo. Gdy dołożymy do tego presję czasu, to może być ono robione na szybko i niestarannie, a to pociąga za sobą kolejne zagrożenia w postaci ukrytych w kodzie błędów.

8. Merge będzie mniej kłopotliwy

W sytuacji kiedy chcemy połączyć zmiany, które wykonaliśmy z główną gałęzią kodu, prościej będzie tego dokonać, jeśli mamy małe zmiany. 

Szansa na to, że w trakcie takiego merge’a pojawią się jakieś konflikty, jest o wiele mniejsza, niż kiedy robimy jakąś dużą zmianę. 

9. Znajdowanie przyczyny błędu będzie prostsze 

Gdy do istniejącego produktu, oprócz nowych funkcji, dodamy też błędy, łatwiej i szybciej te błędy znaleźć i naprawić w mniejszych elementach. Dotyczy to także błędów w samym procesie developmentu, implementacji kawałka produktu i jego testowania. 

10. Otrzymasz wcześniejszy feedback  

Obejmuje to informację zwrotną płynącą z różnych źródeł, np. od Product Ownera, Project Managera czy wewnętrznych stakeholderów, którzy im wcześniej otrzymają coś namacalnego, tym wcześniej mogą to przetestować i powiedzieć co o tym myślą.

Praca w małych porcjach umożliwia nam też częstsze dzielenie się zmianami z rynkiem. Zamiast robić jeden wielki release raz na pół roku, to jeśli pracę mamy podzieloną na małe kawałki, to możemy wypuszczać zmiany do klientów częściej i szybciej otrzymywać informację, o tym, w jakim kierunku rozwijać dalej produkt. 

Wymienione powyżej argumenty są ściśle związane z naszym doświadczeniem w pracy z zespołami. Praca, która nie jest podzielona na mniejsze kawałki, bardzo często rzutuje na problemy z szacowaniem, z jakością i wartością oraz na iteracyjno-przyrostowe dostarczanie.  

Jak wdrożyć dzielenie pracy na małe części do zespołu?

1. Przedstaw argumenty zespołowi

Członkowie zespołu mogą mieć potrzebę zrozumienia przyczyn zmiany podejścia. Unikaj jednak budowania wielopiętrowych argumentacji i autorytarnego narzucania swoich racji. Porozmawiajcie wewnątrz zespołu, powymieniajcie się doświadczeniami, przeanalizujcie różne możliwości. 

2. Zdobądź wiedzę jak to zrobić w praktyce

Być może wewnątrz organizacji jest osoba, która wie, jak podzielić prace na mniejsze kawałki i może podzielić się doświadczeniem. Można też skorzystać z pomocy konsultanta zewnętrznego lub poszukać informacji samemu w Internecie. Takim sprawdzonym źródłem, które polecamy, jest Splitting User Stories. 

3. Zrób z zespołem eksperyment

Spróbujcie podzielić pojedyncze User Story, czy jeden Epic na mniejsze kawałki i zobaczcie jak wam to wychodzi, jak się z tym czujecie, jakie są wokół tego emocje. Pamiętajcie też, aby mierzyć ile czasu zajmuje takie dzielenie i porównajcie też otrzymane wyniki z wcześniejszymi danymi. Odpowiedzcie sobie też na pytania o komfort dzielenia, komfort pracy, czy pracowaliście dłużej, czy krócej? Porównajcie podejścia i zastanówcie się, co się sprawdziło, co warto wdrożyć, a co poprawić. 

Podsumowując, warto dzielić pracę na mniejsze części, gdyż łatwiej jest oddzielić wartościowe elementy od tych mniej wartościowych. Dodatkowo podczas dzielenia odkryjesz niuanse pracy do wykonania, których inaczej byś tak szybko nie odkrył, prościej oszacujesz pracę i rozdzielisz ją wewnątrz zespołu. Sprawniej też zarządzisz pracą zespołu i szybciej odkryjesz potencjalne błędy w produkcie. 

A może Ty masz jeszcze jakieś argumenty za dzieleniem pracy na mniejsze części?

Dodatkowe materiały

• Splitting User Stories

Transkrypcja podcastu „Dlaczego warto dzielić pracę na małe części?”

Jacek: Pracowałem ostatnio z zespołem, który podczas rozmowy na Refinemencie poruszył temat, dlaczego warto dzielić pracę na małe części. Zakończyło się to długą dyskusją o tym, jakie wartości przynosi dzielenie pracy na mniejsze kawałki i chcemy dzisiaj z Kubą opowiedzieć Ci o tym, jakie widzimy korzyści płynące z takiego podejścia. 

Kuba: Ale, zanim przejdziemy do tych korzyści, to jedno ważne zastrzeżenie, chociaż odcinek nazywa się dzielenie pracy i będziemy jednak konsekwentnie to tak nazywać w tym nagraniu, to mamy na myśli dzielenie elementów produktu, czyli dużych fragmentów, kawałków produktu na mniejsze elementy, które są do wykonania przez zespół w mniejszych porcjach. Czyli Product Breakdown, a nie dzielenie pracy w rozumieniu rozdzielania, na przykład programowania osobno testów, osobno jakiejś pracy na frontcie na backendzie. To byłoby bardziej nazywane Work Breakdown i jest kojarzone raczej z taką pracą w środku Sprintu, codzienną, czy nawet godzinną. Będziemy argumentować o tym, jakie ma korzyści dzielenie fragmentów produktu do wykonania, czyli właśnie tej pracy na mniejsze kawałeczki produktu. Takie, które są na tyle drobne, że da się je realizować w korzystny dla zespołu sposób. 

Jacek: No dobrze to przechodząc do konkretów. Jakie widzimy korzyści dzielenia pracy na mniejsze kawałki?

Kuba: Pierwszy argument, bardzo ważna rzecz taka z perspektywy biznesowej, czy z perspektywy wartości dodanej przez zespół, to to, że dzięki dzieleniu pracy na mniejsze fragmenty, łatwiej oddzielić wartościowe elementy od mniej wartościowych. Jeśli wyobrazimy sobie, że mamy do zrobienia coś naprawdę dużego, na przykład duży formularz w jakimś systemie. No, to jeśli to ten formularz jest pojedynczym elementem, jest traktowany jako nierozłączna całość, to w ramach jego nie odróżniamy elementów mniej i bardziej wartościowych. Jeśli natomiast identyczny formularz rozdzielimy na jakieś częstsze przypadki, rzadsze przypadki, elementy, które są częściej używane albo dotyczą większej ilości naszych użytkowników, to może się okazać, że da się podzielić ten formularz na przykład na ten, który jest dla nas krytyczny biznesowo i zawierający jakieś elementy opcjonalne. I te elementy opcjonalne są mniej istotne i mogą na przykład być zrealizowane w późniejszym czasie albo na przykład nie być zrealizowane wcale. 

Jacek: Kolejną korzyścią jest to, że podczas dzielenia pracy najprawdopodobniej odkryjesz niuanse pracy do wykonania. Zwykle to w praktyce wygląda w ten sposób, że w procesie dzielenia czegoś dużego, jakiegoś dużego wymagania, które chcemy dodać do produktu, ficzera, jakkolwiek sobie to nazwiemy, zaczynamy odkrywać, że na pewne pytania jeszcze nie mamy odpowiedzi. Więc coś, co wygląda w dosyć oczywisty sposób, kiedy patrzymy przed podziałem, może się okazać, że po podzieleniu na mniejsze kawałki dostaniemy w prezencie kolejne pytania, na które musimy odpowiedzieć. Najprawdopodobniej i tak musielibyśmy na te pytania odpowiedzieć już w trakcie realizacji. Natomiast w przypadku dzielenia mamy jeszcze tę szansę, że jeśli oczywiście dokonujemy takiego podziału, zanim wykonujemy pracę, czyli w podejściu iteracyjnym po prostu wcześniej niż ten konkretny Sprint, iteracja czy tydzień pracy, w którym będziemy te konkretne rzeczy robić, no to mamy jeszcze możliwości, żeby na przykład jakąś brakującą wiedzę uzupełnić.

Kuba: I ta brakująca wiedza, to z jednej strony mogą być na przykład kryteria akceptacyjne, albo jakieś szczegóły implementacji, czy szczegóły pewnych oczekiwań ze strony użytkowników, interesariuszy biznesowych. Ale to też może być powiązane z tym pierwszym argumentem przeze mnie wymienionym, że w szczegółach mogą się też kryć jakieś na przykład uzasadnienia biznesowe lub niestety ich brak. Czyli wracając do tego mojego przykładu z formularzem, nagle się okaże, że weszliśmy głębiej, bardziej szczegółowo, bardziej dokładnie. No i zadaliśmy sobie pytanie, czy to konkretne pole, czy ta konkretna dana, czy ten konkretny przycisk naprawdę jest nam potrzebny? Bo nie znajdujemy uzasadnienia, gdy przyjrzeliśmy się temu bardzo szczegółowo. Bez dzielenia patrzyliśmy bardzo pobieżnie i wtedy nam wszystko pasowało i wydawało się takie oczywiste i takie niezbędne. 

Kuba: Trzecim argumentem, czy trzecią korzyścią dzielenia pracy na mniejsze kawałki, to prostsze oszacowanie pracy. I mamy tu na myśli dwa podejścia do szacowania czy dwie perspektywy. Z jednej strony dzięki temu, że rozpatrujemy o wiele mniejsze elementy, to oszacowanie czy ten proces dochodzenia do wyceny jest szybszy. Jak i też estymata, którą uzyskamy dzięki temu, że rozpatrujemy coś bardzo drobnego. Prawdopodobnie będzie trafniejsza. Oczywiście mówimy tu o estymatach, więc ona nie będzie trafna w stu procentach gwarantowana, ale też prawdopodobnie w małych fragmentach już o wiele trudniej, żeby ukryło się jakieś ryzyko, jakieś niedogadanie, czy coś co nas jeszcze zaskoczy.

Jacek: Jakby drugą częścią, drugą korzyścią tego jest to, że najprawdopodobniej ta estymata będzie po prostu trafniejsza. Czyli generalnie im mniejszy kawałek pracy mamy przed sobą do oszacowania, no tym jest mniej niespodzianek. Często to jest prostsze i po prostu te estymaty są nieco bardziej trafne.

Jacek: Kolejnym argumentem dzielenia pracy na mniejsze kawałki jest to, że podzieloną pracę łatwiej rozdzielisz wewnątrz zespołu. Bardzo często słyszę od osób w teamach, że nie możemy pracować nad jakimś tematem razem. No bo jak to zrobić? Jak się podzielić? To nie ma sensu. Co powoduje, że ciężar realizacji konkretnego zadania, spoczywa na jednej osobie i może to być w pewnych okolicznościach ryzykowne. Na pewno wydłuża Cycle Time. Natomiast, jeżeli pracę podzielono na mniejsze kawałki, no to możemy te prace rozdzielić wewnątrz zespołu. Co oczywiście będzie wymagało jakiejś tam koordynacji. No ale w sytuacji, kiedy będziemy chcieli przełożyć siły zespołu na to, żeby jakiś konkretny element zrealizować wcześniej, no to będziemy mieli w ogóle taką możliwość. I najprawdopodobniej jeśli podział został zrobiony sensownie, ludzie nie będą sobie wchodzić w paradę. 

Kuba: I taki dodatkowy temat w podziale, to może się okazać, że jeśli ten większy kawałek podzielimy na drobniejsze elementy, to te poszczególne elementy mogą wymagać trochę innego poziomu kompetencji, żeby je wykonać. Czyli na przykład coś dużego dzielimy na coś bardzo skomplikowanego, co prawdopodobnie trafi do najbardziej doświadczonego członka zespołu. Ale będą też takie elementy, które są prostsze, żeby nie powiedzieć wręcz trywialne, które mogą trafić do najmłodszej osoby z najmniejszym stażem i ta osoba też sobie poradzi. W scenariuszu bez dzielenia, no to cały wielki kawał trafia do najbardziej doświadczonego, no bo ma w sobie te elementy bardzo, bardzo trudne. No i ta osoba już to jest utopiona na przykład na cały Sprint, na iterację, czy na wiele dni roboczych pracy. 

Kuba: I podobnie, co do dzielenia pracy przy planowaniu, podobnym argumentem jest też zarządzanie małą porcją pracy już później w środku prac. Wygodniej jest to po prostu zrobić. Mam tu na myśli taką sytuację, gdy już jesteśmy w toku prac, gdy już zespół się dzieli pracą, samoorganizuje, przekazuje zadania. Pewne rzeczy wychodzą, pewne rzeczy nie wychodzą, pewne ryzyka się pojawiają. Na pewno gdy praca jest podzielona na mniejsze fragmenty, łatwiej zrozumieć gdzie jesteśmy, jeśli chodzi o postęp pracy. Łatwiej widzieć te zadania, które już są faktycznie skończone, które można zaliczyć jako gdzieś tutaj już nie obserwowane, bo po prostu już mamy je zamknięte. Ale też łatwiej na przykład przekazywać sobie tę pracę, gdy okazuje się, że coś się przedłuża, albo pojawiają się jakieś nowe okoliczności. 

Jacek: Takim bardzo często spotykanym przykładem jest jakaś forma codziennej synchronizacji zespołu, jakaś forma stand-up’u, gdzie, jeżeli ta porcja pracy jest mała, no to bardzo szybko wychodzi nam to, że jest jakiś problem. Natomiast, jeśli ktoś ma tygodniowe zadanie na sobie, no to codziennie właściwie usłyszymy, że jestem w trakcie, robię, już kończę i tak dalej. Natomiast jak zadanie jest małe, no to już po jednym dniu wiemy, że na przykład jest problem, no bo przykładowo umawiamy się w zespole, że porcja pracy jest nie większa, niż jeden dzień. Jeśli coś trwa dłużej, oznacza to, że są jakieś kłopoty, na które powinniśmy sprawnie zareagować. 

Jacek: Kolejnym argumentem za dzieleniem pracy jest to, że najprawdopodobniej też sprawniej opanujesz to, co jest do zrobienia. Tutaj mamy w szczególności na myśli pracę, która jest pracą wymagającą intelektualnie. Czyli jeśli myślimy sobie o wytwarzaniu produktów cyfrowych, programowaniu, no to bardzo często te rzeczy, które są zaimplementowania, to nie są proste rzeczy. Tylko trzeba je sobie dobrze w głowie przemyśleć. Sam proces pisania, wykonywania takiej pracy, pisania jakichś konkretnych ficzerów, jest wymagające. Mówię to z perspektywy swoich doświadczeń, jako developer, gdzie często mając dużą pracę do wykonania, czułem spory ciężar na głowie. Podczas developmentu musiałem utrzymywać te wszystkie zależności, pytania. Pamiętać gdzie jestem konkretnie, w jakiej pętli już tak schodząc na poziom deweloperski. No i myślę sobie tak, że gdybym dzisiaj miał do tego podejść, to na pewno taką pracę podzieliłbym na mniejsze kawałki, co spowodowałoby, że ta punktowa czy taka złożoność w danym momencie czasu byłaby po prostu mniejsza. Tak więc w szczególności, jeżeli praca ma charakter taki mocno intelektualny i wymaga od nas dużo zaangażowania, takiego w kwestii przemyśleń, no to warto taką pracę podzielić na mniejsze kawałki. Po prostu zjeść tego słonia na kilka razy.

Kuba: Jacek, użyłeś przykładów programisty. Myślę, że to się też ekstrapoluje na również inne prace intelektualne, wymagające poważnego zastanowienia się. Tam też, jednak działa ta zasada właśnie, jak powiedziałeś jedzenia słonia po kawałku. Jeśli próbuję zrobić wszystko duże naraz, a później nagle się okazuje, że są przerwania, że ktoś coś ode mnie potrzebuje, że ja się muszę na chwilę jakby przerzucić na jakieś inne zadanie, to się okazuje, że później dużo czasu tracę, żeby sobie przypomnieć, albo w ogóle gubię. Co też jest samą w sobie bardzo stresujące, że miałem jakiś świetny pomysł, tylko niestety wyleciał mi teraz z głowy i nie mogę sobie go przypomnieć lub muszę od nowa odtworzyć całą tę ścieżkę dochodzenia do tego pomysłu. 

Kuba: Kolejnym argumentem za dzieleniem pracy na mniejsze kawałki jest też to, że szybciej wykonasz Code Review. Zespoły, które realizują prace bardzo dużymi partiami, później mają bardzo duży też kłopot ze zrobieniem przeglądu kodu, gdy tego kodu jest bardzo dużo. Gdy on dotyczy też dosyć rozbudowanej funkcjonalności. No i wtedy jest albo kłopot w tym, że sama tylko to Code Review jest po prostu duża praca do wykonania, albo moim zdaniem równie groźny, a może groźniejszy przypadek, że jest ono robione, tak na za przeproszeniem odwal się, czyli szybko ktoś tam rzuca okiem i puszcza dalej, bo po prostu za długo by trwało w opinii tej osoby zajrzenie w duże szczegóły. 

Jacek: Śmieję się, bo właśnie po tego rodzaju dyskusji, właśnie konkretnie o Code Review z jednym z zespołów, jeden z developerów wrzucił potem na teamsy taki obrazek. To było coś w stylu 10 linijek kodu na Code Rewiew, znajdujemy 10 błędów. 500 linii kodu na Code Review wygląda dobrze. Tak więc dokładnie to, co mówisz, po prostu mało kto najczęściej w praktyce ma czas, albo ochotę generalnie jakieś tam zmiany po tysiąc linijek analizować. 

Jacek: Sąsiadującą korzyścią to wymienionej przed chwilą Code Review, jest korzyść gdy znów na poziomie kodu mamy do przeprowadzenia merge’a na repozytorium. Czyli mówiąc tak najprostszym językiem, chcemy połączyć zmiany, które wykonaliśmy z główną gałęzią kodu. I tutaj bardzo podobna sytuacja, jak w przypadku Code Review, mała zmiana najprawdopodobniej będzie o wiele prostsza do dołączenia, w porównaniu do dużej zmiany, która może zmieniać wiele plików, wiele linijek. Szansa na to, że w trakcie takiego merge’a pojawią się jakieś konflikty, jest o wiele większa, niż kiedy robimy jakąś małą zmianę, parę linijek kodu zmieniamy tylko w jakimś jednym, konkretnym pliku. Tak więc na poziomie developerskim, zdecydowanie o wiele prościej jest zarządzić małymi zmianami, które po prostu nie robią takiego zamieszania w bazie kodu jak duże zmiany.

Kuba: I logicznie patrząc z perspektywy przygotowywania i wdrażania kawałka produktu, który dodajemy do istniejącego już systemu, zazwyczaj może być temat błędów regresji, czyli do istniejącego produktu niestety oprócz nowych funkcji dodaliśmy też z nie do końca znanych nam powodów błędy. To się zdarza. I znowu argument za mniejszymi elementami, to to, że ten proces odnalezienia przyczyny błędu, znalezienia miejsca, gdzie ten błąd jest, poprawienia go, powinien być prostszy. Zwłaszcza w porównaniu do takiego podejścia dokładnie odwrotnego, czyli tworzymy jakieś bardzo duże wersje, wdrażamy je na raz i ten błąd tam też będzie. Pewnie będzie nawet ich więcej. I co gorsza, ponieważ tych błędów jest dużo i jest gdzie szukać, no to znajdowanie tej przyczyny błędu też będzie o wiele dłuższe. 

Jacek: Mówisz Kuba o regresji, ale to może być też znajdowanie błędu w samym procesie developmentu. Czyli ktoś implementuje jakiś kawałek produktu i to wewnętrznie w zespole ląduje na komputerze innej osoby, która po prostu robi test. No i też, im to jest mniejsze tym, o wiele szybciej dowiemy się, że coś nie działa. 

Jacek: I ostatnia wartość, którą widzimy z dzielenia pracy na mniejsze kawałki, to jest to, że zwiększa to nam szansę otrzymania wcześniej informacji zwrotnej. Ta informacja zawrotna może płynąć z różnych źródeł. Zwykle zespół pracuje z jakimś, nazwijmy to reprezentantem biznesowym. To może być klient zewnętrzny, to może być jakiś Product Owner, Project Manager, Product Manager. Mogą to też być wewnętrzni stakeholderzy, którzy im wcześniej otrzymają od nas coś namacalnego, tym wcześniej będą w stanie powiedzieć, co o tym myślą, poklikać sobie w to. Zastanowić się jak to się komponuje z resztą produktu. No i oczywiście możemy iść dalej. Praca w małych porcjach umożliwia nam też częstsze dzielenie się zmianami z rynkiem. No i, zamiast robić jeden wielki release raz na pół roku, jeśli pracę mamy podzieloną na małe kawałki i technicznie jest to możliwe w naszej organizacji, no to możemy sobie wypuszczać zmiany do klientów częściej i szybciej otrzymywać informację, która jest dla nas wskazówką, w jaką stronę powinniśmy dalej pójść z [produktem.

Kuba: I wymieniamy te 10 argumentów, które przed chwilą padło też, dlatego że mamy takie doświadczenie, że temat dzielenia lub braku dzielenia jest ściśle skorelowany z tym, jak skutecznie pracuje zespół. Bo tutaj niepodzielona praca na wiele mniejszych kawałków rzutuje na przykład na problemy z szacowaniem, na problemy z jakością. Na problemy z wartością, na iteracyjno-przyrostowe dostarczanie. Czyli ten fragment o feedbacku, który przed chwilą Jacek wymienił. Czyli wprowadzenie pracy małymi kawałkami wydaje się dosyć dobrym pomysłem, czy dosyć dobrą praktyką. 

Kuba: I w tej ostatniej części tego nagrania powiemy parę podpowiedzi, jak się za to zabrać. Jak wprowadzić to skutecznie do swojego zespołu? Zespołu, w którym jesteśmy takim czy innym liderem. Wymieniliśmy argumenty i wymieniliśmy je nieprzypadkowo, bo to jest pierwsza rzecz, która nam przychodzi do głowy. Wiele osób, zanim spróbuje takiego nowego podejścia lub podejścia, które do tej pory w danym zespole nie było próbowane, czyli taka silna dekompozycja, może mieć potrzebę zrozumienia. Zrozumienia argumentów, zrozumienia przyczyn. Też może trochę pospierania się, powymieniania się swoimi doświadczeniami. I na pewno taka konkretna przestroga z mojej strony, to to, żeby może niekoniecznie budować takie wielopiętrowe argumentacje zbudowane na poziomie logiki, że oto ja teraz wam powiem, jak powinno być. O wiele mocniej poszedłbym w to, od czego Jacek zaczął we wstępie, czyli po prostu porozmawiajmy o tym. Powymieniamy się doświadczeniami. Osoba, która jest tutaj liderem wprowadzania pewnej zmiany, może w takim dosyć coaching’owym stylu pewne rzeczy przedyskutować, popytać, popodsuwać pewne myśli, czy analizy sytuacji. 

Jacek: Drugim krokiem wprowadzania tego rodzaju zmiany, jest zdobycie wiedzy, jak to zrobić w praktyce. Czyli sama świadomość, że to ma sens to za mało, no bo musimy wiedzieć, jak to przekuć na nasz konkretny projekt, produkt, inicjatywę, którą się zajmujemy. Tutaj mamy również kilka możliwości. Być może taką wiedzę, jak dzielić pracę na mniejsze kawałki ma już jakaś osoba w naszej organizacji. Może to jest ktoś z innego zespołu, może ktoś z innego departamentu, kto mógłby przyjść, podzielić się swoimi doświadczeniami, jak w zespole X czy Y podeszli do tego tematu. Alternatywnym podejściem może być posilenie się wiedzą spoza organizacji. Zatrudnienie konsultanta zewnętrznego, który jest w stanie taką wiedzę do zespołu dostarczyć. Można również taką wiedzę znaleźć w internecie. Takim sprawdzonym źródłem, które polecamy to jest Story splitting patterns, czyli taka koncepcja przetłumaczona na wiele języków będąca takim drogowskazem do tego, jak w ogóle można myśleć o dzieleniu pracy i od jakiego miejsca zacząć. Link do tego materiału załączmy do notatek do odcinka. 

Kuba: Ostatnim krokiem, który może pomóc we wprowadzaniu zmiany podejścia do dzielenia pracy na mniejsze kawałki, to jest zaproszenie całego zespołu do eksperymentu. Czyli niekoniecznie na początku musimy się wszyscy zobowiązać, albo dać się przekonać do tego, że od teraz już na zawsze będziemy dzielić pracę tak, albo inaczej. Zróbmy to po prostu na próbę. Dosłownie pojedyncze User Story podzielmy, może podzielmy jakiś jeden Epic, albo w jednym Sprincie podejdźmy trochę inaczej do sprawy i zobaczmy, co nam z tego wychodzi. Jak się z tym czujemy? Jakie są wokół tego tematu emocje? Ale też nie zapomnijmy o tym, żeby to zmierzyć. Czyli pomierzmy sobie, ile czasu zajmuje takie dzielenie, ale też jak wypadł Sprint w porównaniu do typowych poprzednich sprintów. Jaki był komfort współpracy? Jaki był komfort dzielenia? Może jakieś nadgodziny lub ich brak? Zróbmy eksperyment. Zastanówmy się, na jakie czynniki ten eksperyment może wpłynąć i zmierzmy je i później sobie je podsumujmy. Na przykład na Retrospektywie lub po kilku Sprintach na jakimś dłuższym horyzoncie czasowym. Porównajmy podejścia i zastanówmy się, co nam się sprawdziło, co się nie sprawdziło, co jeszcze moglibyśmy spróbować. 

Jacek: Podsumowując. Dlaczego warto dzielić pracę na małe części? Łatwiej oddzielić wartościowe elementy od mniej wartościowych. Podczas dzielenia odkryjesz niuanse pracy do wykonania. Prościej oszacujesz pracę. Łatwiej rozdzielisz pracę wewnątrz zespołu. Wygodnie zarządzisz małą porcją pracy.

Kuba: Sprawniej opanujesz to, co jest do zrobienia. Szybciej wykonasz Code Review. Merge będzie mniej kłopotliwy. Znajdowanie przyczyn błędów będzie prostsze i otrzymasz wcześniejszy feedback. 

Kuba: Jeżeli odcinek przynosi Ci wartość, podziel się nim ze swoim otoczeniem. Na przykład poprzez post na mediach społecznościowych, albo podesłanie do swojego zespołu. Będzie nam miło, że zostajemy w ten sposób docenieni i jednocześnie tym sposobem dotrzemy z naszymi treściami do większej ilości potencjalnych odbiorców. 

Jacek: Notatki do tego odcinka, transkrypcja, zapis wideo, a po kilku dniach również artykuł, znajdziesz na stronie porządnyagile.pl/76. I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.