Artykuły o technologiach IT, programowaniu, testowaniu i nie tylko

Nawigacja

Sztuka estymacji dla początkujących

Estymowanie zadań wciąż dla wielu PMów jest czymś trudnym do zrozumienia. Często estymaty są utożsamiane z czasem, jaki zostanie poświęcony na dane zadanie i często próbuje się dociekać dlaczego coś zajęło 3h, a nie 1h jak wcześniej zespół wyestymował. Niestety, błąd pojawia się już na samym początku tego rozumowania. Estymujemy ilość pracy, a nie czas jaki zajmie jej wykonanie. To jest fundamentalna różnica, trudna do zrozumienia w świecie ManDayów i DevDayów oraz traktowania deweloperów jak zasoby. Deweloper deweloperowi nie jest równy. Dwóch Seniorów też zwykle nie. Przewidywalność w projekcie jest zagadnieniem wielowymiarowym. Aby te zagadnienia zwizualizować posłużę się pewną historią.

Gdzieś w świecie żył sobie człowiek imieniem Robert. Stwierdził, że otworzy firmę która zajmować się będzie pracami ziemnymi, a w szczególności przemieszczaniem hałd piasku. Zebrał czterech kolegów, którzy akurat szukali pracy i poszli na pierwsze zlecenie. Na samym początku pojawiał się problem – ile to może kosztować, na ile powinni się cenić? Początkowo chcieli liczyć na godziny. Stefan, pasjonat ćwiczeń na siłowni i najlepiej zbudowany w całej ekipie powiedział, że sam da radę przenieść tonę w 2 godziny. A cała hałda to około 5 ton, więc jak jest ich w sumie pięciu, to akurat 2 godziny powinny wystarczyć. Niestety, nikt poza nim nie był zbudowany jak Arnold Schwarzenegger albo Mariusz Pudzianowski. Pozostali członkowie zespołu zaprotestowali, że nie dadzą rady przesypać tego w takim tempie. Stwierdzili po długich naradach, że lepiej będzie liczyć sobie robociznę od tony piachu, bo w godzinę pracy ilość przeniesionego piasku przez poszczególnych pracowników była bardzo różna. Na początek ustalili, żę będą brać 200 PLN od tony. Klient jednak chciał mieć cenę ostateczną, dlatego skoro oszacowali ilość piasku na 5 ton, to umówili się z nim na 1000 PLN. Odległość na jaką mieli przenieść piach początkowo nie wydała im się duża, więc postanowili nosić piach w wiadrach. Napracowali się, zadanie wypełnili, ale ostatecznie byli bardzo zmęczeni. Po skończonej robocie poszli razem coś zjeść, uzupełnić płyny i zastanowić się co dalej. Podumali więc co nieco i doszli do wniosku, że warto byłoby policzyć ile naprawdę tych wiaderek piachu przerzucili. Na ile dobrze oszacowali ilość pracy i czy mogli zaproponować wyższą cenę ostateczną. Druga myśl jaka im się pojawiła to sprawdzenie, czy można by przenosić piach szybciej. Postanowili spróbować z taczkami. Zainwestowali w sprzęt i ruszyli do kolejnego zlecenia.

Przy drugim zleceniu szło im już znacznie lepiej, ale piasku było znacznie więcej. Wstępnie oszacowali ilość piachu na 25 ton, więc liczyli na okrągłą sumkę po paru dniach pracy. Liczyli też taczki, żeby sprawdzać ile faktycznie tego piasku udało się przewieźć i móc prognozować, kiedy skończą zlecenie. Pod koniec pierwszego dnia doszli do wniosku, że coś jest nie tak. Wizualnie oceniając hałdę wyszło im, że jest większa od tej z poprzedniego zlecenia około pięciokrotnie. Ale pod koniec dnia, udało im się przewieźć 5 ton (licząc po liczbie taczek) a hałda nie zmalała o 20%, tylko o znacznie mniej. Zaczęli się zastanawiać gdzie leży problem. Po chwili przyszło olśnienie. Piasek był przywieziony świeżo z kopalni. Był jeszcze bardzo mokry. Piasek z ostatniego zlecenia leżał tam już od kilku tygodni, a lato było w pełni. Słońce pozwoliło mu dobrze przeschnąć. Gdy kończyli to zlecenie, dostali wiadomość, że jest kolejny chętny na ich usługi.

Trzecie już zlecenie wyglądało podobnie do pierwszego. Piachu było tylko około 2 razy więcej i był raczej suchy. Nauczeni ostatnimi doświadczeniami sprawdzili, czy piasek jest mokry pod górną warstwą. Okazało się, że nie, dlatego ochoczo zabrali się za pracę. Początkowo praca postępowała zgodnie z planem. Podzielili się na ładowaczy i tragarzy, żeby optymalnie wykorzystać posiadane taczki i łopaty, ale po paru godzinach pojawił się problem. W niższych warstwach zaczął pojawiać się żwir, stopniowo coraz grubszy aż do całkiem sporych kamyków. Łopaty coraz gorzej się sprawdzały. Wg umowy hałda miałą zniknąć, niezależnie od tego co się znajduje na jej dnie. Skończyli wcześniej, bo łopatami nie byli zbyt wiele zdziałać, a szef ekipy pojechał do sklepu budowlanego po kilofy. Następnego dnia ekipa mogła ruszyć do pracy z nowym sprzętem i zaczęli nadrabiać zaległości. Ostatecznie ekipie udało się tylko niezbyt znacznie przekroczyć prognozowany termin ukończenia. Stało się jednak jasne, że nie brali do tej pory pod uwagę ryzyka, że coś pójdzie nie tak. Postanowili, że przed następnym zleceniem zrobią próbny wykop i dopiero wtedy podadzą cenę za tonę. Ucieszyli się też, że taka „niespodzianka” pojawiła się przy małym zleceniu, a nie takim jak np. zlecenie nr 2.

Tutaj możemy zakończyć tę historyjkę i przejść do rzeczy…

Jaka wnioski można wysnuć na podstawie tej tendencyjnej opowiastki?

  1. Szacowanie jest trudne, zamiast wróżyć z fusów lepiej opierać się na dotychczasowych doświadczeń. W software dewelopmencie znany jest problem: jak przeliczać godziny senior developera na junior developera? Najlepsza odpowiedź wg mnie? Nie przeliczać. Prędkość jest cechą całego zespołu, nie pojedynczych jego członków.
  2. Metryki – Po pierwszej robocie nasi bohaterowie postanowili zacząć stosować miary dla swojej pracy. Jeśli nie możesz czegoś zmierzyć, to jak sprawdzisz czy jest lepiej?
  3. Warto eksperymentować i szukać usprawnień. Nasi bohaterowie nie daliby rady zrealizować ostatniego zlecenia używając tylko łopat. Pracowali nad swoim warsztatem, stosowali innowacje, mimo że czasem oznaczało to, że jeden z pracowników nie będzie pracował tylko pojechał po kilofy (szukał innowacji). Innowacje długofalowo są opłacalne. Warto jednak pamiętać o ryzyku i eksperymentować na wczesnych etapach projektu.
  4. Nie wszystko da się przewidzieć. Mokry piach był do przewidzenia, ale gruby żwir – już mniej. Odpowiednie narzędzia (kilofy) pozwalają szybciej rozwiązywać napotkane problemy. Trzeba jednak zmotywowanego teamu, przestrzeni na innowacje i uczenia się na małych potknięciach.
  5. Estymata jest z definicji nieprecyzyjna. Dlatego należy obserwować rzeczywiste wyniki i na ich podstawie planować przyszłość. Estymaty zespołu są niedoszacowane o 100%, 200% a może 1000%? Tutaj warto zadać sobie pytanie, czy deweloperzy mieli szansę zapoznać się z tematem? Poszukać podobieństw do wcześniejszych prac (historie referencyjne)? Zrobić próbny wykop jak w historii powyżej (spike). Znane z XP spike’i nie powinny być tylko powierzchniowe, sprawdzające czy piach jest suchy, ale dość głębokie, by sprawdzić czy na dnie nie znajdą kamieni.

Jak poznać siebie i zespół, żeby pracować i komunikować się efektywniej

Jakim zwierzęciem jesteś? – to pytanie często można spotkać na rozmowach rekrutacyjnych, jednak nikt nie wie, jak na nie odpowiedzieć. Można się tylko głowić, co niby rekruter chciał przez nie osiągnąć. Sprawdzić naszą kreatywność? Zweryfikować jak odnajdujemy się w stresujących sytuacjach? A może spotkałeś się z testami psychologicznymi na rekrutacji, które miały wskazać, jaki jest Twój styl podejmowania decyzji, jesteś introwertykiem czy ekstrawertykiem, czy sprawdzisz się w zespole, jaką postacią z filmu jesteś…? Okazuje się, że za wszystkimi pytaniami stoi tak naprawdę jedno – jaki jesteś. I żeby się tego dowiedzieć, nie potrzeba utożsamiać się z pszczołą.

Pierwszy Pl Planning – wnioski

SAFe – trzy miesiące później

Pierwszy Program Increment za nami. Wkroczyliśmy w drugi PI z marszu, bogatsi o doświadczenia, metryki i wnioski. 5-ciu dostawców, 16-cie zespołów, setki elementów w backlogu. Czego się nauczyliśmy, jakie wyciągnąłem wnioski? Zapraszam do lektury.

Kiedy idę na szkolenie lub prezentację i ktoś sprzedaje mi wspaniałe narzędzie, które powinno rozwiązać większość moich problemów, zwykle jestem podejrzliwy. Szukam gwiazdek i dodatkowych warunków zapisanych drobnym drukiem.
Podobnie miałem w przypadku SAFe. Wydaje mi się, że mogę już (po paru miesiącach) zidentyfikować ten ‘drobny druk’. Są to dwa ważne obszary: wartości z obszarów Lean oraz Product Ownership.

Jak załatwić temat bez spotkania?

Podczas swojej pracy jako Scrum Master spotkałem się z tym pytaniem i postanowiłem odpowiedzieć na nie w tym artykule. Niezależnie od tego jaki temat chcemy załatwić, będzie on wymagał komunikacji z innymi osobami. Są różne kanały komunikacyjne i dyskusja na spotkaniu jest jednym z nich. Chcąc “załatwić temat bez spotkania”, powinniśmy mieć świadomość ograniczeń innych form komunikacji i ryzyk jakie się za nimi kryją.

Wydajne aplikacje webowe

Jakiś czas temu w mojej głowie

Gracjan

zrodził się pomysł dotyczący Raspberry PI i innych podobnych mini-komputerów, który polega na wystawieniu prostego interfejsu, do którego będzie można się odwoływać z dowolnego miejsca i z jego pomocą sterować np. GPIO oraz innymi zasobami takiej płytki. Jest to tak naprawdę część mojego hobbystycznego projektu, więc nie wzięło się to znikąd.

Robimy termometr elektroniczny za pomocą Arduino

ARDUINO, NEOPIXEL STICK I CZUJNIK TEMPERATURY

Czyli jak zrobić termometr za pomocą Arduino?

termometr1Jeśli chcesz zacząć przygodę z Arduino to dobrze trafiłeś. W poniższym artykule opiszę jak zbudować termometr elektroniczny na przykładzie Arduino Micro. Postaram się krok po kroku wyjaśnić jak połączyć poszczególne elementy oraz jak napisać program, który wyświetli zmierzoną temperaturę na pasku złożonym z diod.