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

Nawigacja
KATEGORIA: Technologie

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.

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.

SOLID dla adeptów programowania – podsumowanie warsztatów

Ten post podsumowuje warsztaty przeprowadzone na Uniwersytecie Wrocławskim dla studentów pragnących powiązać swoją przyszłość z IT. W warsztatach wzięło udział 10 osób, dzięki czemu uczestnicy mogli dopytać się o interesujące ich szczegóły pracy programisty oraz dostać kilka cennych rad dotyczących rozwoju w tym zawodzie. Mimo, że temat był trudny to jednak bardzo cenny w kontekście rozpoczynania swojej przygody z programowaniem.

SOLID to zestaw zasad zaproponowanych przez Roberta C. „Uncle Bob” Martina, opisujący pięć podstawowych założeń programowania obiektowego. Ich znajomość pozwala na etapie projektowania aplikacji uniknąć dużej części błędów, które znacząco utrudnią jej rozwój w przyszłości. Warto znać i stosować je już w momencie, gdy realizujemy proste projekty – czy to na uczelnię czy dla samego siebie. Wyrobienie sobie dobrych praktyk programistycznych zapunktuje w przyszłości.

Jeśli temat Cię zainteresował zachęcamy do śledzenia naszego profilu na Facebooku gdzie będziemy publikować informacje o kolejnych warsztatach i szkoleniach: http://fb.com/RSTKariera

Link do prezentacji:http://slides.com/tomaszbanasiak/from-stupid-to-solid-code-in-modern-examples#/

Link do PDF-a, który możesz wydrukować i przywiesić sobie koło biurka aby móc regularnie przypominać sobie te podstawowe zasady: https://goo.gl/hX4jTw

Chcesz więcej w tym temacie? Polecamy linki:

 

 

DDD w praktyce, cz.1: Value Objects w PHP

DDD to bardzo nośne słowo w kontekście PHP. O ile sama technika nie jest specyficzna dla języka (to raczej sposób rozumowania oraz reprezentacji potrzeb biznesowych w kodzie) o tyle specyficzne są już implementacje pewnych struktur typowych dla DDD.

W tym artykule chcę się skupić na jednym z najbardziej przydatnych elementów w DDD – Value Object. VO możemy rozumieć jako zaawansowaną zmienną, gdyż reprezentuje jakąś wartość. W PHP mamy dostępne kilka bazowych typów zmiennych, przy czym reprezentują one głównie najprostsze typy: numer (Integer), ciąg znaków (String), tablicę (Array) itp.

Wzrok pod ochroną

Kiedy myślimy o „podstawowych narzędziach pracy programisty” mamy na myśli kompilatory, IDE, komputery i monitory. Często zapominamy o narzędziach nam najbliższych – takich jak np. wzrok. Jest to tak podstawowe narzędzie, a tak często pomijane przy rozpatrywaniu zdrowego środowiska pracy. Specyfika branży powoduje, że jako programiści pracują w większości ludzie młodzi, których teoretycznie problemy ze wzrokiem jeszcze nie dotyczą. Jeszcze, bo obserwując brak kultury dbania o wzrok niestety jestem przekonany, że wiele osób w późniejszym wieku borykać się będzie z bólami głowy, zaburzeniami widzenia czy nawet poważniejszymi schorzeniami. Trzeba również pamiętać, że choroba oczu może nas trwale zdyskwalifikować z życia zawodowego – zarówno w IT jak i w wielu innych branżach.

PHPStorm od kuchni

Od jakiegoś czasu coraz więcej programistów/osób piszących w PHP w firmie korzysta z JetBrainsowego PHPStorm. To potężne narzędzie ma pełno różnych feature’ów/pluginów, a o istnieniu wielu z nich często nie zdajemy sobie sprawy. Chcąc wymienić się wiedzą o nich, wypiszę o tych, z których często i regularnie korzystam i zachęcam do dopisywania kolejnych.