Wspomniane w odcinku:

Transkrypcja

[00:00:01.690] Cze艣膰! To co - w drog臋?

[00:00:09.860] Kolejny tydzie艅, kolejny spacer. Dzisiaj porozmawiamy o temacie powi膮zanym z tym wczorajszym. Wczoraj by艂o o produktywno艣ci, dzisiaj co nieco o planowaniu. Ale nie takim zwyk艂ym, bo nie b臋d臋 ci臋 uczy艂 r贸偶nych technik planowania; takich, 偶eby zna膰 kiedy to si臋 sko艅czy, kiedy najlepiej co艣 zacz膮膰. Nie. Tu nie chodzi o wykresy Gannta, ani o nic takiego. Dzisiaj co艣 prostszego. Co艣 prostszego i daj膮cego lepsze i dok艂adniejsze wyniki. O czym mowa? O tym zaraz.

[00:00:52.160] Tak mi si臋 spodoba艂 ten Las Tyniecki, 偶e teraz praktycznie codziennie tutaj jestem. Fajna sprawa.

[00:00:58.490] Mo偶na spokojnie pochodzi膰, pooddycha膰 艣wie偶ym powietrzem i troch臋 odpocz膮膰. I pogada膰 do kamery. No to w takim razie - o co chodzi, je艣li nie o te wykresy Gannta? Je艣li nie o jakie艣 Excele, plany dok艂adne. Chodzi o zmor臋 programist贸w, czyli estymacj臋 zada艅. Masz zadanie… dostajesz zadanie no i masz wyestymowa膰 “ile Ci to zajmie”. I jak to zrobi膰? Prawda jest taka, 偶e nie da si臋. Ka偶dy programista, kt贸rego znam, nie potrafi tego zrobi膰 dok艂adnie. Niekt贸rzy strzelaj膮, niekt贸rzy estymuj膮 na podstawie poprzednich zada艅 (poprzednich podobnych zada艅), a niekt贸rzy po prostu wpisuj膮 cokolwiek.

[00:01:53.870] Nie przejmuj膮 si臋 tym, bo wiedz膮, 偶e i tak to nic nie da. I tak ka偶de planowanie, ka偶da taka sytuacja b臋dzie niedok艂adna. A dlaczego?

[00:02:14.140] Po prostu nie ma bata, 偶eby przewidzie膰 przysz艂o艣膰. Niewa偶ne ile zada艅 zrobisz wcze艣niej. Mo偶e by膰 dok艂adnie takie samo zadanie. A mo偶esz to zadanie tylko wyestymowa膰. Kiedy艣 s艂ysza艂em o 艣wietnym sposobie na estymacj臋. Pomy艣l sobie, ile zajmie ci dane zadanie i pomn贸偶 razy 3.14. To jest metoda planowania “PI”.

[00:02:39.690] No dobra. Powiesz: “ale przecie偶 s膮 r贸偶ne Scrumy, r贸偶ne Agile, r贸偶ne metodyki planowania. Nawet jakie艣 tam wzory magiczne. Czy nic nie daj膮?”

[00:02:50.240] Czy rzeczywi艣cie nic nie daj膮? Wed艂ug mnie troch臋 daj膮, ale czas potrzebny do takiej estymacji jest nieop艂acalny. M贸g艂by艣 zrobi膰 ju偶 p贸艂 jakiego艣 zadania zanim by艣 w miar臋 dok艂adnie wyestymowa艂 ile Ci co艣 zajmie. Tak naprawd臋 nie wiesz co ci臋 czeka po drodze. Nie wiesz na jakie problemy trafisz po drodze. Nie wiesz co inni robi膮. Bo najcz臋艣ciej nie dzia艂asz w odizolowanym ekosystemie. Nie dzia艂asz w innym systemie ni偶 inni. To jest w艂a艣nie plus i minus pracy w zespole.

[00:03:33.320] Pracujecie razem nad jedn膮 rzecz膮, ale tak naprawd臋 mo偶ecie sobie, albo pomaga膰, albo przeszkadza膰. Ale mimo nawet najlepszej komunikacji, ci臋偶ko jest doj艣膰 do takiego etapu, 偶e w kt贸rym艣 momencie si臋 nie jedziecie.

[00:03:52.620] I tak nawet same metodyki Agile’owe zak艂adaj膮, 偶e dzia艂asz na 偶ywym organizmie. 呕e nie planujesz z g贸ry na rok, dwa lata. Tylko dzia艂asz w ci膮gle zmieniaj膮cym si臋 艣rodowisku. Tak w艂a艣nie - je艣li Ty robisz jakie艣 zadanie i kolega z zespo艂u robi podobne zadanie w tym samym systemie (w tym samym module, w tej samej cz臋艣ci systemu), to jest du偶a szansa, 偶e b臋dziecie musieli p贸藕niej, albo rozwi膮zywa膰 konflikty, albo b臋dziecie musieli si臋 dogada膰. Ale i tak jaki艣 czas na to p贸jdzie. Jaki艣 czas, nieprzewidziany przez was. Dlaczego?

[00:04:33.840] Bo po prostu to jest 偶ycie. Nie macie magicznej kuli. Nie jeste艣cie wr贸偶bitami. Nie potraficie przewidzie膰 przysz艂o艣ci. I to jest normalne. Tak naprawd臋, mimo 偶e biznes, mimo 偶e mened偶erowie, scrum masterzy licz膮 na to, 偶e wycenisz im zadanie na ile艣 czasu, to tak naprawd臋 mega ci臋偶ko jest wyceni膰 to dok艂adnie. Bo albo si臋 rozjedziesz w jedn膮 stron臋, albo w drug膮. To jakie jest rozwi膮zanie tego problemu? Wed艂ug mnie nie ma dobrego. Tak, czy inaczej, pr臋dzej czy p贸藕niej si臋 rozjedziesz ze swoimi planami. Wed艂ug mnie najlepiej oszacowa膰 na oko.

[00:05:16.890] Ale jest jeszcze lepszy spos贸b, kt贸ry pomaga w takim szacowaniu. Opr贸cz szacowania r贸偶nych zada艅, warto jest podzieli膰 te zadania na mniejsze bloki. Tak samo w tym odcinku, w kt贸rym m贸wili艣my o nauce. Im mniejsza porcja wiedzy, tym 艂atwiej j膮 przyswoi膰. Tak w zadaniach. Im mniejsze zadanie, im mniejsza cz膮stka do zrobienia tym 艂atwiej ci to wyestymowa膰. Bardziej wiesz, co zrobi膰. Jakie przeszkody mog膮 ci臋 czeka膰. I tym dok艂adniej to wycenisz. I w艂a艣nie takie ci臋cie zada艅 na mniejsze kawa艂ki pomaga nie tylko zaplanowa膰 to wszystko lepiej (bo zawczasu widzisz ile pracy ci臋 czeka, tak z grubsza). Zamiast jednego tematu do zrobienia, masz dziesi臋膰, ale 1/10 tego du偶ego. I dzi臋ki temu widzisz dok艂adniej, 偶e jest du偶o (albo ma艂o) do zrobienia. Dodatkowo, je艣li wykonujesz jakie艣 zadanie, to m贸zg dostaje ma艂e zastrzyki dopaminy. Po prostu m贸zg si臋 cieszy, 偶e co艣 zosta艂o zrobione.

[00:06:38.470] No i dalej, w idealnym 艣wiecie nie trzeba by takich zada艅 wycenia膰 w og贸le. Ale niestety nie 偶yjemy w idealnym 艣wiecie. W takim razie 艂atwiej wycenia膰 takie ma艂e klocki. Bo w idealnym 艣wiecie po prostu masz stos zada艅. Bierzesz jedno. Robisz. Odhaczasz. Bierzesz nast臋pne ze stosu, itd.

[00:07:02.130] Jednak przy wi臋kszych projektach kto艣 musi te zadania zaplanowa膰. Kto艣 musi mniej wi臋cej widzie膰, co 艂atwiej, a co trudniej zrobi膰. Co zajmie wi臋cej czasu, a co b臋dzie szybsze. No i na podstawie tego planuje czas. Robi te swoje wykresy Gannta. Robi arkusze w Excelu. Po prostu robi grafiki - kiedy mniej wi臋cej dana funkcjonalno艣膰 b臋dzie zrobiona. Tutaj mam oczywi艣cie najwi臋ksze do艣wiadczenia ze 艣wiatem programowania, ale tak naprawd臋 takie podej艣cie rozbijania zada艅 na mniejsze sprawdzi si臋 w wielu bran偶ach (je艣li nie we wszystkich). Po prostu warto spr贸bowa膰 dzieli膰 zadania na mniejsze. Zamiast pr贸bowa膰 szacowa膰 taki wielki klocek, warto rozbija膰 na mniejsze. Jakby艣 mia艂 przenie艣膰 stukilowy g艂az kontra 10 dziesi臋ciokilowych. Takiego stukilowego praktycznie nietkniesz. A 10 dziesi臋ciokilowych ju偶 pr臋dzej. Poprzenosisz po jednym. No i b臋dzie z g艂owy. Efektem ubocznym jest to, 偶e takie mniejsze zadania 艂atwiej pouk艂ada膰 w bloki czasu. Je艣li planujesz sobie czas, to 艂atwiej wcisn膮膰 takie mniejsze zadanie, ni偶 takie ogromne zadanie, przy kt贸rym stwierdzisz 偶e: “艂o matko, tyle czasu, tyle trzeba zaplanowa膰. Zamiast dziesi臋ciu minut, to dwie godziny”. I od razu ci臋偶ej wcisn膮膰 w tw贸j grafik. Takie du偶e zadanie.

[00:08:40.650] Dodatkowo jeszcze w 艣wiecie programowania warto wypuszcza膰 takie ma艂e zadania od razu jak je zrobisz. Zamiast kisi膰 i 艂膮czy膰 kilka mniejszych zada艅 w wi臋ksze, warto wypu艣ci膰 jedno. Tylko ukryte, 偶eby funkcjonalno艣膰 nie by艂a od razu dost臋pna. Odkryjesz jak zrobisz ca艂膮 funkcjonalno艣膰. A tak to wypuszczasz ma艂e klocuszki, kt贸re na pocz膮tku s膮 ukryte. Po prostu niedost臋pne z poziomu aplikacji. Dzi臋ki temu od razu b臋d膮 w aplikacji - ju偶 b臋d膮 przetestowane, gotowe. I b臋d膮 czeka艂y na reszt臋 klock贸w. Tak samo je艣liby艣 budowa艂 dom. To nie budujesz go gdzie艣 na boku. I nie przenosisz ca艂ego domu na swoj膮 dzia艂k臋, tylko budujesz bezpo艣rednio na dzia艂ce. Po kawa艂ku, dobudowujesz, a偶 b臋dzie ca艂y dom gotowy. I tak w艂a艣nie jest z tymi mniejszymi zadaniami. Masz gotowe zadanie ma艂e - dopychasz je. Jedziesz z nast臋pnym. Budujesz drugie zadanie - jedziesz dalej. Tyle, 偶e ukryte, niedost臋pne z poziomu aplikacji.

[00:10:02.480] To, 偶e ci m贸wi臋, 偶e ci臋偶ko zaplanowa膰 cokolwiek, to nie znaczy, 偶e nie warto planowa膰 w og贸le. Wr臋cz przeciwnie. Im wi臋cej zaplanujesz, tym wi臋cej zrobisz. Nie pami臋tam jakie to jest prawo, ale jest takie prawo, 偶e zadanie zajmuje tyle czasu ile na niego przeznaczysz. I ile dla niego za艂o偶ysz. I to w miar臋 cz臋sto si臋 sprawdza. A to, 偶e m贸wi臋, 偶e ci臋偶ko wyestymowa膰 cokolwiek, to nie znaczy, 偶e nie warto estymowa膰. Tylko znaczy, 偶e ci臋偶ko jest wyestymowa膰. A im mniejsze jest zadanie tym 艂atwiej oszacowa膰.

[00:10:49.040] Idealnie by by艂o nieestymowa膰, ale tak najcz臋艣ciej si臋 nie da. Najcz臋艣ciej po prostu s膮 takie polityki, takie ustalenia. Biznes musi mie膰 jak膮艣 wiedz臋, jakie艣 szacunki, kiedy mo偶e si臋 czego艣 spodziewa膰. Tak samo jak przy budowie domu nie bierzesz robotnik贸w, a oni ci nie m贸wi膮, 偶e “b臋dzie jak b臋dzie zrobione” tylko mniej wi臋cej ustalasz z nimi - na kiedy ma by膰 zrobione. A to, 偶e potem si臋 pojawiaj膮 jakie艣 obsuwy - to jest naturalne. To jest przy produkcji ka偶dej rzeczy, w ka偶dej bran偶y. Podsumowuj膮c, warto planowa膰, ale warto te偶 rozbija膰 zadania na mniejsze.

[00:11:36.540] Dzi臋ki temu b臋dziesz wiedzia艂 dok艂adniej co jest do zrobienia i ile mniej wi臋cej zajmie to czasu. I jak to du偶e zadanie si臋 rozk艂ada na mniejsze. Jakie kroki musisz zrobi膰, 偶eby wykona膰 du偶e zadanie. Dodatkowo, to 偶e robisz mniejsze zadania, to bardziej widzisz post臋p.

[00:12:03.360] To ju偶 tyle na dzisiaj. Opowiedz o swoich metodach planowania i estymacji. Czego u偶ywasz? Co si臋 sprawdza, a co nie? I dlaczego? Podziel si臋 - tutaj, w komentarzach. A tymczasem ja lec臋 sobie dalej pospacerowa膰. I pewnie do kolejnego spaceru. Trzymaj si臋. Cze艣膰.