Pokazywanie postów oznaczonych etykietą komunikacja. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą komunikacja. Pokaż wszystkie posty

poniedziałek, 10 czerwca 2013

The right way - people first.

If you work with wimps who take everything personally, do not want to change their minds, are close for modifications and extensions and are scared of thinking about changing something then don't forget this:

PUT PEOPLE FIRST. 

Maybe the step you wanted to take was to big? Maybe there is a better way to explain something? Be smart and find another way, the RIGHT WAY to hack the wimp.

wtorek, 5 czerwca 2012

CodeRetreat w Berlinie

Bardzo sie ciesze, ze kolejny raz moglem wziac udzial w CodeRetreat (CR). Sa to warsztaty integrujace ludzi pracujacych jakkolwiek z kodem. Wedlug mnie dobrym polskim tlumaczeniem "Code Retreat" bedzie: "Rekolekcje dla programistow". CR stwarza mozliwosc do pomedytowania nad kodem, do wymiany refleksji nad jego stanem, do podjecia postanowien, do zmiany myslenia i wreszcie do uczenia sie od siebie nawzajem. Poza hardskillami w naturalny sposob uczysz sie softskilli. Pair programming, zmiana w parach co sesje, retrospekcje, wspolny obiad bez pospiechu - to wszystko sprzyja interakcji.
Tak bylo i tym razem. Dzieki zapalencom (no bo jak nazwac osoby zjezdzajace sie i to w niedziele po to zeby caly dzien razem kodowac) oraz sponsorom: @nokia@crealytics, @klosebrothers udaly sie kolejne rekolekcje. Bardzo ciekawa relacje mozna przeczytac na blogu Staszka.

sobota, 17 grudnia 2011

Szacowanie - od czego zaczac?

Szacowanie to moj temat nr 1 na rok 2011. Naczytalem sie sporo, naszacowalem i w pracy i poza, napopelnialem bledow, nawalilem wiele razy. Dyskutowalem z kilkoma osobami live, na forach, grupach i chcialbym to podsumowac. Najbardziej interesuje mnie poznanie mechnizmow psychiki czlowieka, ktore maja zasadniczy wplyw na szacowanie. Kolejny aspekt to sprawa swiadomosci jak moje szacowanie wplywa na to co robia inni czyli poszerzenie horyzontu i uswiadomienie sobie pewnych waznych zaleznosci. Na koniec wspomne ogolnie o pewnych metodach pomagajacych w szacowaniu.

Zacznijmy od tego oto meterialu. Linda Rising bardzo ciekawie tlumaczy skad biora sie niektore bledy oszacowan i jak sobie pomoc:
Linda Rising: Deception and Estimation: How We Fool Ourselves. cz1 cz2

wtorek, 25 października 2011

Czytanie między wierszami ma swoje minusy

Dużo dobrego słyszałem o polskich programistach, którzy z byle jakie specyfikacji potrafią zmajstrować solidny program. Jak oni to robią? Z tego co udało mi się zaobserwować stosuję metodologię CzytajMiędzyWierszami. A kim są ci, którzy bardzo lubią tą metodologię? Są to ludzie, którzy z różnych powodów opracowują niestarannie wymagania klienta, piszą nieprzemyślaną specyfikację, później to zatwierdzają i przekazują dalej (cokolwiek to znaczy).

Oto programista Henio dostaje do wyklepania CRa. Widzi jego opis zarejestrowany w BTS, widzi komentarze, jakieś dodatkowe wyjaśnienia, linki do UseCase'ów, widzi maile z kolejnymi potwierdzeniami od specyfikatorów i testerów, wszystko jest ok. Henio jest pilnym programistą i już niejedno na swojej programistycznej ścieżce widział. Po pierwszym czytaniu Henio widzi, że to co jest w BTS i to co jest w UseCase'ach to nie to samo. Henio zna metodologię CzytajMiędzyWierszami wie kiedy jest deadline i wie jeszcze, że żeby odkręcić te kilka szczegółów trzeba porozmawiać (Henio wie, że maila wysyła się, kiedy nie trzeba czegoś szybko załatwić) z 3 osobami, wyjaśnić im co jest nie tak, poprosić o komentarz, posłuchać ich wyjaśnień i dostać od nich poprawione wersje. Do tego wszystkiego dochodzi jeszcze pośrednio kierownik projektu, który zablokował pliki, ponieważ dostał informację, że wszystko jest zapięte. Tak się składa, że do pokoju Henia przyszedł Zenek. Henio przedstawił sprawę Zenkowi i zapytał co by Zenek zrobił. Zenek też zna metodę CzytajMiędzyWierszami do tego zna jeszcze NieCzytajMiędzWierszami. Zenek pyta Henia co się stanie jeśli CR zostanie wyklepany i pójdzie do testów. No jak to co? Testerzy przeczytają specyfikację i go przetestują, tzn przetestuję część. To co stoi między wierszami pominą. W końcu po to mamy specyfikację i wymagania, żeby na nich polegać. CR trafi na produkcję. Przyjdzie kilka bugów, się poprawi i jakoś będzie - pochodna code and fix. Ktoś nie dostanie na czas swojego samochodu, ktoś dostanie paczkę z tygodniowym opóźnieniem, innych 1000 osób będzie musiało dalej drukować i pewne dokumenty zamiast móc je przekazywać drogą elektroniczną. No chyba, że Heniu poświęci swój cenny czas, jaki spędza w pracy na zrobienie czegoś naprawdę dobrze i na poziomie. Co zrobi Heniu? A co zrobisz ty w takiej sytuacji?