To jest 206. odcinek podcastu Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy w IT o nazwie Solid.Jobs, który zresztą mam przyjemność współtworzyć, dyskutujemy o narzędziach programisty. Zapraszamy do słuchania i komentowania.

A teraz życzymy Ci już miłego słuchania.

Odpalamy!

 

Cześć, Łukasz.

 

Cześć, Krzysztof.

 

Spotykamy się już po raz czwarty, żeby porozmawiać o narzędziach programisty. Było już o Code Review, było o pair programming, było o Spike’u, a dzisiaj poruszymy temat, w którym my jako programiści jesteśmy najlepsi, czyli estymaty.

Tak sobie myślę, że gdyby programowanie było tylko taką bardzo inżynieryjną i bardzo logiczną dziedziną, to te estymaty powinny być zawsze trafne, zawsze idealne i powinniśmy być w nich świetni, ale to, że w nich nie jesteśmy najlepsi, ogólnie rzecz mówiąc, to może pokazywać, że ta dziedzina jednak nie jest tak bardzo przewidywalna, jak się może wydawać i też my pewnie jako ludzie, jako programiści wnosimy trochę tego chaosu do tej dziedziny, bo myślę, że o tym będzie jeszcze dzisiaj mowa.

To może na początku taka podstawowa kwestia: po co nam w ogóle te estymaty?

 

To jest właśnie ciekawe pytanie i nie jest tak proste, jak się wydaje. Pytanie brzmi, czy ta estymata ma odpowiedzieć na pytanie, ile coś będzie trwało, czy może, jak coś jest duże. Myślę, że tutaj spróbujemy o tym trochę głębiej porozmawiać.

Schodząc na taki bardziej biznesowy level, to myślę, że estymata jest nam po to potrzebna, żeby wiedzieć, ile ten klient musi za coś zapłacić.

 

Czyli mówisz, że biznes, klient to jest generalnie to źródło, estymat główny?

 

Tal, ale wydaje mi się, że sami też chcemy wiedzieć, ile nam coś zajmuje. Chcemy umieć się np. porównać z kolegą czy z koleżanką. Jako team leader chcę np. wiedzieć, ile mój zespół jest w stanie w danej jednostce czasu, np. w sprincie pracy wykonać.

 

Jasne. Ja bym to podsumował, że generalnie chodzi nam o planowanie. Lubimy wiedzieć, ile coś zajmie, bo wtedy to planowanie jest po prostu łatwiejsze albo możesz się przełożyć na konkretną wycenę dla klienta wewnętrznego, zewnętrznego itd. I to stawia estymaty w takim świetle, że one muszą być wykonane przed tym zadaniem.

 

Tak, ale wydaje mi się, że jednak planowanie to jest coś więcej. Na planowanie się składa estymacja zadań, harmonogramowanie. Tak że estymata to jest część tego całego procesu planowania.

 

No właśnie. Mimo wszystko jednak najczęstsze podejście to takie, że estymat polega na próbie oszacowania, znalezienia, wydedukowania, jakkolwiek sobie ten proces nazwiemy, przed przystąpieniem do zadania. Tymczasem, jak sobie spojrzymy na to, jak bardzo dokładne mogą być estymaty, to najczęściej dopiero po wykonaniu zadania wiemy, ile nam to zajęło, wiemy, ile czasu na tym spędziliśmy, wiemy, jak duże też było zadanie.

 

Tak, to jest też bardzo ciekawe, że w miarę tego, jak praca trwa, ta estymata się staje coraz dokładniejsza i coraz więcej wiemy, coraz dokładniej jesteśmy w stanie powiedzieć, ile coś zajmie i oczywiście dokładnie wiemy, jak już skończymy, ile nam to zajęło.

 

No właśnie, niestety nie posiadamy wehikułu czasu, żeby się wówczas cofnąć do początku i taką dokładną estymatę posiadać. Mimo wszystko nie wiem, jak Ty, ale ja widzę często opór w zespołach do tego, żeby te estymacje gdzieś tam zmieniać w trakcie. Pomimo tego, że wiemy o zadaniu wówczas więcej, wiemy na, jakie problemy się nacięliśmy, wiemy jak bardzo potencjalnie może się czas wykonania rozszerzyć, to zazwyczaj staramy się trzymać tych pierwotnych estymat z różnych względów.

 

To już jest takie filozoficzne podejście, czy zmieniać tę oryginalną estymatę w zadaniu, czy nie, jak to się ma potem do tego sprintu. Tu są pewnie różne szkoły, różne podejścia. Jedne są bardziej przyjęte, kanoniczne, inne mniej, ale myślę, że chyba w tej rozmowie byśmy pominęli akurat ten aspekt, bo wydaje mi się, że to jest zbyt szeroki temat. Może następnym razem.

 

Jasne, to już pewnie wchodzi w planowanie, w project management itd., jak do tego podejść później w projekcie. Chciałem tylko zauważyć to, że podchodzimy do estymat jako coś, co jednorazowo jest tworzone, jednorazowo jest zgłaszane i później pozostaje do końca prawa realizacji tego zadania, często też niewłaściwie.

 

Tak, a sam ten proces estymowaniate także jest jakimś narzędziem. Znowu, wyjdźmy z tego pudełka i zastanówmy się, jak to w naszym procesie, w naszej konkretnej sytuacji możemy użyć, bo może właśnie coś takiego, że reestymujemy, ma sens. Ja np. spotkałem się z taką formą, że na początku była taka estymata wstępna, powiedzmy, analityka czy osoby takiej, która nie wykonuje tego zadania konkretnie, tylko właśnie jej zadaniem jest zaplanowanie tego sprintu, a następnie była już estymata dokładniejsza, kolejna zespołu. Wtedy trzeba było odpowiednio ten zakres jeszcze przed odpaleniem sprintu dostosować.

 

Kiedy sobie tak myślę o tym, że możemy reestymować, kiedy lepiej po prostu poznajemy ten problem, to zagadnienie techniczne, jakieś wyzwania, jakie przed tym stoją, to zazwyczaj widzę sytuację, w której jesteśmy w niedoczasie, kiedy widzimy, że to zajmie nam więcej, niż pierwotnie planowaliśmy. Ale przecież może się zdarzyć sytuacja zupełnie odwrotna, czyli sytuacja, kiedy ta estymacja jest większa niż czas potrzebny na realizację zadania.

 

Tak, i tutaj myślę, że może tak się zdarzyć, natomiast pamiętajmy o czymś takim jak prawo Parkinsona, czyli prawo, które mówi, że praca zawsze się rozszerzy tak, żeby wypełnić cały jej dostępny czas i w tym kontekście takie zadania raczej się nie trafiają, które są wykonywane szybciej, bo zawsze można wtedy ten pozostały czas wykorzystać, żeby coś ulepszyć, coś zrefaktoryzować.

 

Dokładnie, zawsze ten czas się wykorzysta i ta praca się po prostu rozciągnie na tyle, na ile czas nam pozwala.

 

Powiem teraz coś  kontrowersyjnego, byłem parę lat temu na ciekawej konferencji w Krakowie, było dużo zagranicznych gości, m.in. pamiętam David Fowler był jedną z, nazwijmy to, gwiazd tego eventu. Pamiętam, że byłem na takiej prelekcji właśnie o estymatach i gość powiedział, że no oni nie estymują wcale i w sumie estymowanie nie ma sensu. Ja tak słucham, co on tam za głupoty wygaduje, chyba nawet nie dosiedziałem do końca, tylko wyszedłem w trakcie, zmieniłem prelekcję. Ale teraz z perspektywy czasu wydaje mi się, że jednak jest tam ziarno prawdy w tym, co ten prelegent mówił, i wydaje mi się, że nie zawsze estymowanie ma sens, co o tym myślisz?

 

Tak absolutnie, jest taka słynna wypowiedź Jeffa Sutherlanda, czyli tego sygnatariusza manifestu Agile, też współtwórcy Scruma, o tym, że po iluś tam, nastu latach analizowania różnych zespołów IT itd. jego firma doszła do wniosku, że estymowanie w większości przypadków nie to nawet, że nie ma sensu, ale szkodzi. 

Po prostu szkodzi i wręcz się zaleca, żeby właśnie nie estymować albo robić to bardzo zgrubnie, ponieważ według ich statystyk te zespoły, które są najwolniejsze w dostarczaniu rozwiązań, estymują godzinowo, czyli tak bardzo granularnie. Im wyżej w tej granularności sobie idziemy, im większe to ziarno jest, tym mniej to spowalnia dostarczanie. I wręcz radzi, żeby raczej próbować dzielić zadania na tyle małe, żeby ta rozbieżność nie była wystarczająco duża, albo żeby nie była jakoś przytłaczająca.

Właśnie, ja mam też podobne podejście, uważam, że pewien rodzaj estymacji ma sens, bo to jest chociażby przydatne w planowaniu. Natomiast jeśli już tutaj próbujemy, dajmy na to, ten dzień programisty dzielić na godziny i tę pracę mu wyznaczać na każdą godzinę dnia, to wiemy, że to absolutnie nie ma sensu. Myślę, że takie zgrubne estymowanie może mieć sens, zwłaszcza jeśli współpracujemy z innymi zespołami, z innymi członkami zespołów, którzy też wnoszą coś do tej naszej pracy, bo to jakoś tam pozwala sobie zaplanować tydzień sprints czy jakkolwiek, ale jeśli chcemy z tym iść zbyt głęboko, to zazwyczaj przynosi więcej wad.

 

Tak, pamiętajmy, że trzeba to narzędzie dostosować do siebie, do swojej specyfiki, inaczej będzie w waterfallu, gdzie ten kontrakt jest podpisywany upfront i klient wie, czego chce. Przynajmniej tak mu się wydaje, a inaczej, myślę, będzie przy podejściu takim agile’owym, które polega w mojej ocenie na tym, że mamy jakiś określony czas, który jest nieprzekraczalny, taki timeboxing i w tym czasie staramy się dostarczyć jak najlepszy produkt na tych zgrubnych naszych wymaganiach wstępnych. W takim przypadku będzie inne podejście do tego estymowania, a inne podejście oczywiście w przypadku, jeśli musimy to wszystko wiedzieć już od początku.

Powiedziałeś o granulacji – też są różne podejścia. Podejście właśnie takie, że co do godziny coś estymujemy, kolejne przyrosty, ale może być też podejście małe, duże, średnie. I załóżmy małe to 3 zadania dziennie na programistę, średnie np. cały dzień i duże to już więcej niż dzień.

Tak, pamiętajmy, że trzeba to narzędzie dostosować do siebie, do swojej specyfiki, inaczej będzie w waterfallu, gdzie ten kontrakt jest podpisywany upfront i klient wie, czego chce. Przynajmniej tak mu się wydaje, a inaczej, myślę, będzie przy podejściu takim agile’owym, które polega w mojej ocenie na tym, że mamy jakiś określony czas, który jest nieprzekraczalny, taki timeboxing i w tym czasie staramy się dostarczyć jak najlepszy produkt na tych zgrubnych naszych wymaganiach wstępnych. W takim przypadku będzie inne podejście do tego estymowania, a inne podejście oczywiście w przypadku, jeśli musimy to wszystko wiedzieć już od początku.

 

Tak, to też może zależeć od długości sprintu, jak tutaj bardzo chcemy sobie z tą granularnością schodzić, jeśli mamy taki sprint tygodniowy, też się takie zdarzają, to być może wzięcie dnia jako jednostki estymacji ma sens, ale jeśli to są np. miesięczne sprinty, to być może próbujemy tutaj zgadywać de facto. Najczęściej moja obserwacja wygląda wtedy tak, że jeśli te sprinty są za długie, to zadania też są za duże i ich estymacja niestety jest dosyć kłopotliwa.

Właśnie, ale myślę, że istotne jeszcze jest to, czy próbujemy estymować optymistycznie, czy próbujemy jednak mieć takie pesymistyczne podejście, czyli zawsze na jakąś tam górkę jeszcze liczymy, dorzucamy, bierzemy to pod uwagę na bazie naszego doświadczenia. Patrzymy, że najczęściej dochodzi więcej rzeczy do zrobienia niż mniej w przypadku tego typu zadania, więc jak myślisz, jaki to jest złoty środek?

 

Myślę, że to bardzo zależy od natury człowieka, ale z moich doświadczeń wynika, że zawsze te estymaty są jednak optymistyczne. Nie bierzemy pod uwagę różnych sytuacji wyjątkowych, które mogą się zdarzyć w trakcie pracy. A inna jeszcze ciekawa rzecz, którą powiedziałeś, to kwestia optymistycznie / pesymistycznie. Ja natomiast z kolei zawsze byłem ambasadorem tego, żeby nie podawać estymat jako konkretnej liczby, pojedynczej wartości skalarnej, tylko że estymata to jest właśnie jakiś przedział czasu, czyli podajemy wartość optymistyczną, wartość pesymistyczną i np. jakimś fajnym wzorem wyliczamy tę wartość oczekiwaną i wtedy podajemy taki zakres, ile coś może trwać.

Oczywiście znowu to zależy od naszego procesu, od tego co budujemy, co chcemy osiągnąć, co jest nam potrzebne, ale myślę, że takie podejście, gdzie jednak nie myślmy o tych estymatach jako o konkretnej liczbie, bo to nigdy nie będzie 4 godziny, co do minuty, to jest jakiś zakres, ta czwórka to wiadomo, że to będzie trwało między 2 a 6.

 

Tak, to jest jakieś przybliżenie. Ja tak lubię myśleć o estymatach, że to jest przybliżenie, a nie zobowiązanie. Wiem jak często to w firmach wygląda, że nawet zgodnie z podejściem z frameworkiem scramowym sobie tutaj planujemy sprint, dobieramy te zadania, które gdzieś tam wcześniej zostały być może jakoś wyestymowane i traktujemy to jako zobowiązanie. To jest niestety przepis na niefajną relację z PM-em, z biznesem, relację nawet wewnątrz, jeśli ktoś z nas np. więcej czasu potrzebuje na to, żeby swoją część zrealizować. Zazwyczaj rodzi się to dużo stresu i napięć.

 

Tak, to jest taka kwestia właśnie kultury organizacyjnej danej firmy. Musimy jednak budować firmę tak, żeby można było się mylić, żeby za pomyłki nie karać, tylko żeby się uczyć na swoich błędach. Komu się nie zdarzyło dwukrotnie przekroczyć estymaty, niech pierwszy rzuci kamieniem. Albo to był tylko button na godzinę, czemu ten button powstawał dwa dni. Wszyscy to znamy, to są fajne potem anegdoty, ale musimy tutaj, jeśli się takie sytuacje zdarzają, odpowiednio po prostu reagować i na pewno nie może być tu takiego negatywnego feedbacku w takiej sytuacji.

 

Mówimy tu głównie o takich estymatach czasu potrzebnych do planowania, albo do tego, żeby zobaczyć, ile jesteśmy w stanie w ten sprint upchnąć tych zadań. Ale powiedziałeś ciekawą rzecz, że to nie jest jedyny typ estymat, że możemy sobie też estymować wielkość. Ale po co nam taka wiedza o tym, jak duże jest zadanie, komu to wnosi jakąś wartość?

 

Moim skromnym zdaniem estymaty czasu w ogóle nie mają sensu, bo wyestymujemy teraz zadanie, dajmy na to na te cztery godziny, ale teraz mamy w zespole kilka osób, no i czy te osoby to samo zadanie zrobią w tym samym czasie? Raczej nie. Jedna osoba jest seniorem, druga jest np. juniorem i ten junior oczywiście zrobi to szybciej, bo nie pomyśli o różnych sytuacjach wyjątkowych – to tak trochę pół żartem, pół serio.

Tak że estymując pewnie myślimy o tym, ile mnie to zajmie, a nie ile to zajmie koledze czy koleżance. Tak że myślę, że dużo lepszym podejściem jest jednak wyestymowanie wielkości tego zadania, a później opieranie się na tym velocity zespołu, żeby jakąś taką średnią wyliczyć i określić, ile tych zadań do danego sprintu jesteśmy w stanie wrzucić.

Moim skromnym zdaniem estymaty czasu w ogóle nie mają sensu, bo wyestymujemy teraz zadanie, dajmy na to na te cztery godziny, ale teraz mamy w zespole kilka osób, no i czy te osoby to samo zadanie zrobią w tym samym czasie? Raczej nie. Jedna osoba jest seniorem, druga jest np. juniorem i ten junior oczywiście zrobi to szybciej, bo nie pomyśli o różnych sytuacjach wyjątkowych – to tak trochę pół żartem, pół serio.

 

W tej serii podcastów rozmawiamy o narzędziach programistów, więc myślę, że też do tego narzędziownika trzeba zerknąć. Jakie Ty stosujesz, albo jakie widziałeś podejścia do estymacji? W jaki sposób podejmować się próby oszacowania, ile nam takie zadanie może zająć albo jak duże ono jest?

 

To pewnie jest znowu temat na cały odcinek, więc tutaj bardzo szybko wymieńmy tylko takie typowe podejścia. Podejście pierwsze: nie estymujemy. Zawsze jest to jakieś podejście, czasami ma sens wbrew pozorom, nie wyłączajcie tego odcinka już teraz. Inne podejście to opieranie się na jakiejś wiedzy eksperckiej, na jakimś np. liderze zespołu, team leaderze, czy też architekcie, który tutaj odgórnie powie: To zadanie tutaj wygląda na jeden dzień pracy. I mamy jeden dzień pracy.

Oczywiście to podejście ma dużo wad, bo ta jedna osoba tutaj decyduje, więc może lepiej, żeby to kilka osób tutaj estymowało i potem jakiś konsensus tego weźmiemy. I oczywiście szczegółowo to znowu są różne podejścia. Przykładem byłby np. planning poker, który jest chyba dość popularną techniką, nawet są narzędzia, ale oczywiście nic nie zastąpi analogowych kart.

 

Ja bym do tego jeszcze dodał, że możemy też wziąć nawet od jednej osoby, chociaż oczywiście im więcej, tym lepiej, jakąś średnią z takiej optymistycznej, pesymistycznej estymaty i prawdopodobnej. Jakoś nawet może wagami to jakoś jeszcze tutaj wzbogacić, jeśli mamy taką fanaberię, bo to powoduje, że one są bardziej urealnione, w sensie nie idziemy w tej skrajności optymistyczna czy pesymistyczna.

Bierzemy oczywiście pod uwagę, że to się może wydarzyć, że zazwyczaj nasza najbardziej prawdopodobna estymata i tak gdzieś tam idzie w kierunku optymistycznej, tak jak powiedziałeś, więc próbujemy wziąć te różne skrajności i jakąś średnią sobie wyznaczyć. To też może być jakieś przybliżenie.

 

Tak, to też takie podejście, gdzie kilka osób w, nazwijmy to, ukryciu estymuje i potem o tym rozmawiamy, ma tę zaletę, że możemy, jeśli czyjaś estymata właśnie odbiega od średniej, to możemy wtedy rozmowę przeprowadzić i spróbować się dowiedzieć, dlaczego jest ta różnica i z czego ona wynika, o czym ten ktoś pomyślał albo o czym ten ktoś na przykład nie pomyślał.

 

Ale wiesz, ja myślę, że istotniejsze od tego, jaką metodę sobie wybierzemy czy w ogóle te estymaty robimy zgrubnie, wielkościowo, czasowo czy jakkolwiek, jest to, jak są zdefiniowane zadania.

Bo jeśli one są źle doprecyzowane albo bardzo duże, to ich estymaty będą przestrzelone w różnym kierunku. Im lepiej zdefiniowane zadania i im mniejsze tym prawdopodobieństwo, że trafimy z estymacją, jest większe. A poza tym też samo wykonywanie tych zadań wówczas ma mniej niespodzianek pośrodku, bo wszystkie te warunki brzegowe, jakieś acceptance criteria itd. zostały określone. Myślę, że waga, istotność tego elementu vs jak bardzo trafne będą nasze estymaty jest znacznie większa.

 

Tak, wielkość, myślę, ma tutaj fundamentalne znaczenie, ale też jest tutaj taki czynnik jak niepewność. Czyli czy dokładnie wiemy, co trzeba zrobić, czy to jest takie zadanie z metra, które już robiliśmy wielokrotnie i teraz po prostu robimy tylko trochę inaczej, czy jakiś inny, kolejny widok, czy to jest coś nowego, integracja z nowym systemem, mamy nowy sprzęt, który musimy oprogramować. Tutaj dochodzi ta niepewność, która też tę estymatę nam dodatkowo rozmywa.

 

Tych przyczyn niedokładności jest całkiem sporo. Na pewno ta złożoność, o której mówisz, im większe zadania, tym trudniej jest ogarnąć wszystkie możliwe warunki brzegowe, wszystkie możliwe powiązania, wpływ tego, co chcemy zrobić na różne inne części systemu. Co też może często powodować, że tej pracy jest więcej, bo zapomnieliśmy, że coś musimy jeszcze tu uaktualnić. Ten button, o którym powiedziałeś, jest najlepszym przykładem. Czyli ta złożoność zadania jednoznacznie wpływa na niedokładność estymaty.

 

Tak, ale też np. złożoność systemu, z którym pracujemy. Bo jeśli mamy Greenfielda i mało zależności, to pewnie to samo zadanie do zrobienia w takim legacy projekcie, gdzie dostaliśmy w spadku oczywiście kod od ludzi, którzy się dawno ewakuowali z tego projektu, to będzie zupełnie inny czas wykonania.

 

Mówiliśmy tutaj o tym, że gdy estymujemy sobie godzinowo, to zakładamy, że będę robił dwa zadania po cztery godziny, zestymowałem na cztery godziny w ciągu dnia, to już nie może się tutaj udać. Po prostu nie może się udać, bo wiadomo, że takie założenie, że sobie osiem godzin dziennie kodujemy, to jest po prostu mrzonka. I to nie tylko doświadczenie ludzi pokazuje, ale też psychologia, która mówi, że to jest zwyczajnie niemożliwe.

 

Ok, a Krzysztofie, na początku mówiłeś, że najlepsze estymaty to są estymaty post factum. To teraz zadam Ci takie pytanie: Myślisz, że jest jakaś wartość w estymowaniu zadań, które już są zrealizowane?

 

Myślę, że tak. Myślę, że zespół może się uczyć na podstawie tego faktu pod warunkiem – i to niestety rzadko występuje – że jest czas, żeby to przeanalizować, żeby nad tym się skupić, zobaczyć w ogóle, że tutaj na przykład estymowaliśmy taki typ zadań i wyszło nam, że kompletnie się tutaj rozmijamy. Co możemy z tym zrobić? Być może powinniśmy to zadanie pociąć na mniejsze plasterki. Może powinniśmy użyć innej jednostki, może powinniśmy spotykać się np. przed tą estymacją jeszcze z innymi zespołami, które są uzależnione od nas albo mają wpływ na nas. Może po prostu powinniśmy się czegoś nauczyć na podstawie nietrafności tych zadań.

Jeśli jesteśmy w tym dobrzy i wychodzi nam to super, to ok, świetnie, pewnie żadnej dodatkowej wartości z tego nie będzie. Róbmy po prostu dalej to, co robimy. Natomiast największa wartość może płynąć właśnie z faktu zauważenia, że te estymaty się zupełnie gdzieś tam rozmijają. Nie po to, żeby się samobiczować, ale po to, żeby wyciągnąć jakieś wnioski co na przyszłość, jak lepiej podchodzić do realizacji zadań.

To wymaga też dużej świadomości PM, żeby właśnie ten czas po pierwsze zorganizować, znaleźć, pewnie też takiej samoświadomości zespołu. Ale myślę, że jeśli ten czas jakoś tam na retro na przykład się znajdzie, to może być to jakaś wartość dla zespołu.

 

Ale w sumie też to jest fajny pomysł na takie szkolenie dla zespołu, z estymowania. W sumie nie spotkałem się, żeby ćwiczyć estymowanie inaczej niż tutaj na polu walki, ale myślę, że może to byłoby fajne takie szkolenie, ćwiczenie, np. mamy dwa zespoły i tutaj już post factum zespół A bierze te zadania od zespołu B i próbuje je zestymować. Drugi zespół robi to samo nawzajem, a potem się spotykają i rozmawiają, ile to rzeczywiście zajęło i o czym tutaj wy nie pomyśleliście, co tutaj się pojawiło niespodziewanego.

Myślę, że jest tutaj pewne pole do podpisu, jeśli chodzi o team liderów i o taki rozwój zespołu i też naukę tej estymacji.

 

Tak, myślę, że to nie tylko tyczy się poszczególnych osób, że np. taka osoba ma jakiś problem z estymacją, problem w tym sensie, że zazwyczaj one są bardzo nietrafione, ale też może jest tam wartość dla całego zespołu, może uczymy się, jak razem współpracujemy, może uczymy się tego, że praca nad ficzerem to nie jest tylko kodowanie, często tak niestety w estymacjach to wygląda. Może jesteśmy w stanie się nauczyć, że te pierwotne założenia muszą być lepiej zdefiniowane, żebyśmy mogli przystąpić do estymacji. Myślę, że taka wartość może być całkiem spora też dla zespołu, jako grupy ludzi działających razem na przyszłość.

Dobrze Łukasz, myślę, że całkiem sporo powiedzieliśmy o estymacjach, dlaczego one nie wychodzą, kiedy mogą wychodzić, jaka wartość z nich płynie, nawet jak do nich podejść. To co, chciałbyś zrobić podsumowanie?

 

Jasne. Oczywiście tutaj tylko liznęliśmy ten temat, ale jeśli miałbym tu takie kluczowe punkty z naszej rozmowy wyciągnąć, to myślę, że jednak starajmy się estymuować wielkość, a nie czas. W ten sposób uniezależniamy się np. od osoby, która wykonuje dane zadanie i innych czynników zewnętrznych, które mogą się w trakcie tego wykonania zadania pojawić. Wielkość jednak jest, myślę, bardziej obiektywną wartością.

Potem myślę, że jednak estymować musi zespół, nie jedna osoba, tylko cały zespół. I oczywiście ludzie, którzy będą wykonywać tę pracę, bo oni najlepiej wiedzą, ile coś zajmie, a takie narzucenie z góry czasu nigdy się dobrze nie kończy.

Pamiętajmy też, że estymata to nie zobowiązanie. Coś może pójść nie tak, budujmy taką kulturę organizacyjną, w której jest zrozumienie tego faktu. I oczywiście estymując – to jest chyba taka najbardziej uniwersalna wskazówka – dzielmy jednak te zadania na jak najmniejsze fragmenty, bo mniejsze fragmenty dokładnie jesteśmy w stanie zestymować.

Zastanówmy się też nad tym, jak estymujemy, czy ta jednostka, którą użyliśmy, jest na pewno do naszych konkretnych potrzeb, do tego projektu adekwatna, czy nie przenieśliśmy z innego projektu jakieś przyzwyczajeń, które w tym projekcie, w tej specyfice pracy po prostu mają mniejszy sens.

Myślę, że to są takie najważniejsze tutaj punkty, które podsumowują tę naszą rozmowę.

Pamiętajmy też, że estymata to nie zobowiązanie. Coś może pójść nie tak, budujmy taką kulturę organizacyjną, w której jest zrozumienie tego faktu. I oczywiście estymując – to jest chyba taka najbardziej uniwersalna wskazówka – dzielmy jednak te zadania na jak najmniejsze fragmenty, bo mniejsze fragmenty dokładnie jesteśmy w stanie zestymować.

 

Świetnie. Myślę, że to jest dosyć ciekawy obszar IT, dosyć ciekawy obszar programowania, o którym dzisiaj tutaj zaczęliśmy rozmawiać. Co Ty na to, żebyśmy jeszcze trochę ten wątek pociągnęli, tzn. jak planować, jak dzielić zadania, jak to czasowo zamykać i porozmawiali właśnie o tym w następnym odcinku? Może masz jakąś propozycję co do tematu?

 

Myślę, że fajnie się łączy z tym tematem wątek iteracji i timeboxingu, czyli postaramy się pokazać, że iteracje to nie tylko kolejne sprinty i postaramy się pokazać, jak te zadania ograniczać w czasie. Żeby łatwiej je oczywiście estymować.

 

Świetnie, już teraz do tego odcinka zapraszamy, tymczasem dziękujemy za dzisiaj. Rozmawialiśmy o estymacjach. Zapraszamy też do wcześniejszych odcinków, gdzie już całkiem sporo o różnych narzędziach programisty było powiedziane. Zapraszamy też na SOLID.Jobs, gdzie możecie znaleźć ciekawe oferty w pracy zawsze z widełkami wynagrodzeń. Zapraszamy też do wystawiania ogłoszeń. Widzimy się i słyszymy już całkiem niedługo. Zapraszamy już za tydzień do odcinka właśnie o iteracjach i timeboxingu.

Łukasz, dzięki za dzisiaj. Cześć!

 

Dzięki, cześć!