Job offer

Nie moglem sie powstrzymac od komentarza pierwszego zdania z opisu job oferty.


"Osoba, będzie odpowiedzialna w pełni za powierzone zadanie (zebranie wymagań od zleceniodawcy, analizę biznesową, projekt, implementację, testy i wdrożenie). Oczywiście zapewniamy pełne wsparcie w zakresie wiedzy biznesowej oraz technicznej."


Czyli po naszemu:
oczywiscie = oczywiscie
w pelni odpowiedzialna = w pelni odpowiedzialna
pelne wsparcie biznesowe = mozesz u nas pracowac, badz proaktywny
pelne wsparcie techniczne = maszyna do kawy, telefon, komputer

CodeRetreat w Wolfsburgu

No i sie doczekalem. Tym razem CodeRetreat w Wolfsburgu. Zastanawialem sie czego mozna sie nauczyc rozwiazujac kolejny raz to samo zadanie, w tej samej formule (formula CodeRetreat). No wiec oto rzecz, ktore odkrylem tym razem:

• Podczas jednej z sesji, moj pair-kolega mial laptopa z podlaczona dodatkowa klawiatura. Jedna dla niego, jedna dla mnie. To naprawde bardzo ulatwilo nam prace. Zamiast paluchem pokazywac cos na monitorze, wystarczylo wejsc koledze w slowo po to aby sie zatrzymal, a nastepnie bez przekazywania klawiatury klepac swoj pomysl tak zeby widzial rowniez w kodzie o co chodzi. Sluchajcie, bez zartow, niby taka pierdola ale naprawde duzo, duzo pomaga. Polcam na kazdy nastepny raz i w pracy jak robicie Pair Programming ;)
• Z innym kolega klepnelismy wszystkie zadane 4 reguly gry w zycie w 4 linikach kodu! TO dlatego, ze wspolpraca szla nam naprawde dobrze. Ja klepalem testy, kolega implementacje. Nazwy metod testowych byly pelnymi zdaniami, wyrazy oddzielalem podkreslnikiem. 
• Dwie pierwsze sesjie byly ciekawe z tego powodu, ze  mialem osoby zielone z TDD, i bedace pierwszy raz na code retreat. Tu uczylem sie nie wymadrzac, przekazywac wiedze i lamac schematy (ze jakies tam podejscie, ktore kiedys poznalem jest naj). Bardzo cenie sobie te sesje.

W trakcie kazdego takiego warsztatu obserwuje strone organizacyjna i pomysly jakie sa wykorzystywane. Moze bede mogl wykorzystac zebrane doswiadczenia pomagajac przy organizacji Global Day Of Code Retreat.
Jak zawsze takie spotkanie to okazja na nowe znajomosci i luzne z ludzmi z branzy. To sobie bardzo cenie - moc dowiedziec sie jak wyglada branza IT w Niemczech bezposrednio z ust osob z ta branza zwiazanych.

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.

Testy jUnitowe sa do dupy

Mowilem ci juz o tym czy nie, ze testy jUnitowe sa do dupy? Nie ? No to sluchaj... tzn czytaj...Co to wogle sa te testy jUnitowe? WTF? Gdzies po drodze wsrod ton klepanego kodu, gdzies gdzie jedni chcieli cos usprawnic, drudzy tylko odbebnic, gdzie cialge brakowalo czasu zetknely sie dwa pojecia: test jednostkowe i jUnit. W wyniku tego zetkniecia powstalo nowe super cool pojecie "testy jUnitowe". I teraz nie wiedomo czy chodzi o testy jednostkowe, integracyjne, alibi, czy jeszcze jakies inne.Co to wogle znaczy, ze ktos pisze, ze mam w projekcie testy jUnitowe poza tym, ze pewnie uzywa biblioteki jUnit? Czy tak trudno uzywac pojecia "test jednostkowy", "unit test"?. Wiec co jakis czas trzeba odkurzyc ten temat co udalo mi sie zrobic.
W projekcie, w ktorym pracuje poprowadzilem prezentacje o testach jednostkowych i bibliotece mockito. Korzystajac z tego, ze Staszek blisko jest i dosc czesto mozna pogadac o sprawach waznych z punktu widzenia software developera przeprowadzilismy kilka deskusji o mockowaniu, testowaniu jednostek kodu (publicznego api klasy, pojedynczej metody) i izolacji obiektow na potrzeby tesotwania jednostkowego. Zebrane przemyslenia zostaly dopieszczonem, ubrane w prezentacje i przedstawione ludziom z projektu.

Przebieglo to mniej wiecej tak, ze przygotowalem prosty model w domenie samochodowej, ktora to domene kazdy w projekcie rozumie. Bez zadnych problemow podefiniodaem zaleznosci i prosta logike. Samochod ma silnik, rame, nadwozie, elektornike.

Pewne odpowiedzialnosci zakapsulkowane sa w danych jego elementach. Elementy te zaleza od siebie i wspolpracuja ze soba. 

Przedstawilem jak odizolowac obiekt samochod, ktory byl testowany - mockujac wspolpracujace z nim obiekty. Pokazalem jak to zrobic w sposob bez mockow (test setup sie mocno wydluzyl) i jak to samo zrobic z uzyciem mockito.

Wszystko bylo banalnie proste, zamokowalem doslownie dwie metody w klasie silnik - wspolpracujacej z klasa samochod. Hmm tak sobie teraz mysle, ze dobrze by bylo podpiac to pod githuba zebys mogl zobaczyc o czm dokladnie pisze... (TODO: podlinkowac repo z githuba). Ludzie patrzeli na pisany kod i mogli sami stwierdzic co jest przyjemniejsze i co im bardziej lezy. Pierwsze spostrzezenia jakie im przyszly pokazaly jak przez pisanie testow zmuszamy sie do tworzenia lepszego designu. A to ze statyczne pola jakos zmienne globalne sa slabe, baaardzo slabe (cokolwiek to znaczy), a to ze inicjalizowanie w obiektow zaleznych przez operator new w konstruktorze obiektu glownego jest tez slabe :) A ja tylko kiwalem glowa i sie usmiechalem.

Podparlem sie prezentacja Staszka i praktycznym jego podejsciem i opowiadzialem jeszcze o przewadze

assertEquals(expected, actual)

nad assertTrue(warunek)

jesli chodzi o ilosc informacji zwracanych jest przez jUnita w razie niespelnienia asercji.

o szablonie given-when-then
 

po to aby latwo mozna sie bylo polapac, ktory fragment metody testowej co robi.

... i o pewnej ciekawej ksiazce:

Na koniec nasz projaktowy leader zachecil wszystkich do prezentowania tematow, ktore zycie w projekcie uczynic moga lzejszy. Ja mam juz kolejny temat jednak zanim go zapodam musze przygotowac grunt pod zmiany. O tym co to znacz bedzie w jednym z nastepnych postow.

Ty, drogi czytelniku tez pewnie masz cos do powiedzenia. Nie czekaj wciaz wciskajac sobie kit, ze jeszcze potrzebujesz tego i tamtego, ze sa lepsi co nic nie przedstawiaja i ze nie ma co wychodzic przed szerego bo jeszcze sie skompromitujesz. Daj spokuj, zmien nastawienie, zacznij sie dzielic tym co masz i nie obawiaj sie wzbudzac skrajnych emocji. Jedni beda cie kochac inni cie wysmieja, a ja chetnie sie dowiem co za temat zapodales i komu...

Praktyki nie-studenckie w KEEP CODING

Nie obejdzie sie bez wyjasnienia, ze poleglem kolejny raz na metodzie "malej lyzeczki", czy jak kto woli "metodzie malych kroczkow". Regularnosc to cos co caly czas walczy we mnie z tym co nazywam spontanicznoscia choc jest to w duzej czesci mieszanka lenistwa i slabej woli. Post na blogu po miesiecznej przerwie jest tego dobrym przykladem szczegolnie, ze sie dzialo.

Oto przez dwa tygdnie mialem na praktyce ucznia technikum informatycznego, osobe z rodziny po stronie mojej zony, Adriana. Jako, ze ostatnio bywam duzo w Polsce zazachodniej polaczylem oferte praktycznej nauki zawodu z "wycieczka" krajoznawcza co sie dobrze sprawdzilo.

Najbardziej zalezalo mi na odkryciu prawdziwej pasji ucznia czyli tego co tak naprawde lubi robic oraz poszerzeniu jego horyzontu czyli pokazaniu co robic moze. Ostatecznie sie okazalo, ze jak na razie pracy z softem to nie lubi. O wile bardziej woli hardware i to w wersji hard -  szczegoly pomijam. I dobrze, karty zostaly odkryte i latwiej bylo reszte ustawic. 

Czy to co dzsiaj nie jest twoja pasja moze byc nia jutro? Znasz odpowiedz na to pytanie. Czy mozna robic cos bez pasji? - tu tez nie musze podpowiadac. Ostanio jeden ze znajomych opowiadzial mi o nowej osobie w swojej pracy (software) ktora to wybrala kierunek informatyczny studiow ze wzgledow ekonomicznych. Dzis nie ma problemu ze znalezieniem dobrej pracy i nie musi pracowac po pracy co pozwala jej na zajecie sie swoja prawdziwa pasja. Tak tez mozna :)

Kolejna istotna kwestia to swiadomosci, ze jesli koniec swiata nie nadejdzie po Euro 2012, a nawet w 2015 to trzeba bedzie na tym swiecie jakos zyc i cos robic. Ta wlasnie swiadomosc, moze zmotywowac do dzialania dzisiaj, do malych kroczkow lub jak to mowil jeden z moich wykladowcow, malej lyzeczki co jest jednym z wysoce skutecznych sposobow na dojscie do celu. O tak... cel... do niego mozna isc, mozna go miec lub tez nie, itp. Wiec ja jako starszy brat przedstawilem kilka celow, kilka gor, ktore czekaja na zdobycie. Piekna rzecza jest moc dzielic sie swoim doswiadczeniem i pomagac innym zdobywac gory, ktore przed nimi stoja. Dla mnie to byla podroz w przeszlosc, dla Adriana w przyszlosc, odbyla sie co ciekawe w terazniejszosci.

Wszystko przeplatany bylo roznymi zadaniami zwiazanymi z programowaniem od prostych stronek w html i javascripcie po gierki w JavaME. Zaliczylismy tez wyklad na JUGu o CauchDB, kilka wyjsc na bronka i jakis sport. Przy okazji wielkie podziekowania Marcinowi Stachniukowi za kursik JavaME, intro do yarba mate i cala pomoc w indoktrynacji praktykanta.

Juz po wszystkim przeczytalem wpis Jacka Laskowskiego o praktykach studenckich w IBM.

Tu bardzo spodobala mi sie propozycja przyuczenia do blogowania, twittowania, blipowania, itd jako sposobu dzielenia sie wiedza. Przy okazji nastepnych praktyk zastosuje ten pomysl.

Wymowne nazwy metod i kontekst.

Metoda malych kroczkow wprowadzam do kodu, z ktorym na codzien pracuje pewne konwencje. Piszac testy staram sie nazwac metode testowa tak aby w pewien sposob oddala kontekst testu. Jednak na nic te konwencje jesli tylko ja bede ich uzywal. Wiec pokazalem jednemu koledze moj kod z takimi dlugasnymi nazwami metodami (okolo 100 znakow na nazwe) i poprosilem o komentarz. 100 znakow! WTF! No wybacz, sa taki jezyki (nie programowania), ktore potrzebuja duzo miejsca. Podobno jezyk finski przebija wszystkie.

zwracaTrueDlaProcesowZewnetrznychTechnicznieZwalidowanychWersjonowanieRozpoczete

No wiec pokazje koledze pierwsza motode.... a on czytajac ja w polowie dostal stackoverflow. Czyta drugi raz i znowu. Mowi do mnie, ze to nie przejdzie, ze to do dokumentacji, ze jak dla niego 3 wyrazy i basta. Na koniec podkreslil jeszcze dobitnie, ze to za duzo. Sie zdziwilem, ze tak od razu, ze sie nie reebotuje i nie walczy no ale coz. Dla mnie jego zdanie jest wazyne bo przeciez na jednym kodzie pracujemy. Staram sie jednak mu pomoc i go zachecic. Czytam mu nazwe metody i robie przerwy. On to zwuwazyl i mowi mi, ze z tymi przerwami juz kmini ale ich w nazwie nie widzi. No wiec edytuje kod:

zwracaTrue_DlaProcesowZewnetrznych_TechnicznieZwalidowanych_WersjonowanieRozpoczete

Kolega jeszcze sie krzywi, no jest lepiej ale. Pokazuje mu inna, stara nazwe metody testowej:

rodzajSourcinguZmieniony

i pytam czy ta nazwa mu cos mowi. Kolega zaczyna parsowac, glowi sie, patrzy w kod (zaslonilem mu na chwile ;)). No nic, z samej nazwy metody nic nie wyprodukuje, nie wie w ktorym kosciele dzwoni. Odslaniam kod testu. W sumie pogorszylo tylko sprawe :D
No ale nie cisne na sile. Skoro jemu trudno to odczytac i woli w dokumentacji to mu pokazuje dokumentacje klasy i szeroko opisan kontekst. Swieteni, robi sie jasniej. Zmarszczki na czole powoli sie prostuja ( mam nadzieje, ze pod czaszka nastepuje proces odwrotny). W powietrzu czuc porozumienie. No to ide za ciosem. Cialo metody:

// GIVEN
wstepny kontekst, setup, ustawienie stanu systemu
// WHEN
zdarzenie faktycznie testowane (np. wywolenia metody)
//THEN
sprawdzenie wynikow tesotwanej metody, asercja

I tu pozytywna reakcja. Weszlo jak w maslo, sa pochwaly, jest dobrze. Rownoczesnie patrzymy na inne metody testowe napisane dawno temu. Czy ktos myslal kiedys o tym, ze inni beda je czytac szukajac powodu defektu? Czy ty myslisz o tym, piszac kod?

Polska Zazachodnia

Gdzie jest moja Polska? Jaka twoja? - mozesz mnie zapytac, przeciez Polska jest nasza! A ja ci odpowiem tak: to, ze jest nasza nie przeszkadza jej byc moja. Poza tym mam tez taka swoja Polske, domowa czy jak to nazwac. Ta Polska jest mobilna. Jest w tych miejscach, w ktorych slysze moj ojczysty jezyk, wsrod znajomych, wsrod swoich, w domu. Obecnie jest nia Polska Zazachodnia, czyli Polska na zachod od Odry.

Ubezpieczenie od NNW

Temat na kabaret. Wyobrazcie sobie, ze dzwoni do mnie jakas osoba z ING i oferuje mi pewna oferte. Z nudow zgadzam sie na jej przedstawienie. I oto co sie dzieje. Ja, jeszcze niedawno kwiat polskiej mlodziezy slysze, ze za 3 zlote miesiecznie w razie smierci dostane 20.000, za 5 zl miesiecznie 25.000, za... a za 21 zl miesiecznie 150.000 z mozliwoscia rozszerzenia oferty jakbym na przyklad zginal w wypadku samochodowym lub poniosl nagla smierc. Swietnie! "I jak podoba sie Panu nasza oferta" - uslyszalem na koniec. I tu poprosilem pania o chwile cierpliwosci bo potrzebowalem sie zastanowic jak moglbym umrzec. Zaczalem sobie wyobrazac te 21 zl miesiecznie w kombinacji z zawalem podczas pracy lub ewentualnie bardziej spektakularnie - w zderzeniu czolowym z tirem, hmmm. A moze 5 zl miesiecznie i zostac rozwalonym na pasach. No ale po co tak hardcorowo od razu. Moze jednak jakies uszczerbki na zdrowiu. I tu pytam pania o to co sie stanie jak zlamie noge ale nie bedzie trwalego uszczerbku na zdrowiu. Ton glosu mojej rozmowczyni posmutnial. Oznajmila mi ze niestety w takim przypadku nic nie dostane, ale....! I tu sie ozywila, ale jakby to bylo taki zlamanie ze wyladuje w szpitalu i w ciagu 180 dni amputuja mi konczyne to jest szansa! Co za oferta! Tylko brac!
W sumie jestem najbardziej pod wrazeniem sposobu jej przedstawienia. Ciekawe czy to jakis nowy rodzaj marketingu czy moza pani ktora mi to przedstawiala dzwoni na zmiane raz z oferta ubezpieczenia, a raz z najnowszym abonamentem kablowki. Jedno jest pewne zrobila na mnie duuuuze wrazenie.

Projekt - miejsce gdzie spedzasz wiekszosc dnia.

Bierzesz udzial w projekcie, w tworzeniu produktu (w moim przypadku jest to software). Narodzil sie on jakis czas temu, co kilka miesiecy ewoluuje o kolejne funkcjonalnosci. Cykl ewolucji powtarza sie z jednego wydania na drugie. W tym wszystkim obserwujesz przerozne formalizmy projektowe, ustawki, rozne formy wspolpracy, podkniecia, czkawki itd. Wszystko dziala w dosc sztywnej ramce, ktora potrzebuje z gory zdefiniwanych kosztow, terminow oddania, zakresu zmian, z gory okreslonego przadzialow prac dla osob w zespole, i calej masy innych z gory przewidzianych rzeczy. Ta ramke mozna co prawda usprawniac jednak wiaze sie to z praca w high tech czyli z ludzmi!
A gdyby tak zamiast myslec o kosztach pomyslec o ciaglych inwestacjach (brzmi troche inaczej)
Zamiast wersji i realeas'ow zalozyc ze produkt niegdy nie bedzie zakonczony za to ciagle rozwijany, ulepszany, malymi kroczkami.
Zamiast z gory okreslonego zakresu bedzie swiadome i ciagle odkrywanie nowych wartosci o jakie mozna go wybogacic, wsparte uczeniem sie w trakcie i umiejetnoscia obchodzenia sie z tym co jeszcze nieznane.
Zamiast zarzadzania zasobami (czyt. ludzmi) starac sie utrzymac balans miedzy tym co powinno zostac dostarczona, a tym ile jestesmy w stanie wytworzyc...

Ta, akurat, pitu pitu bedzie wiosna... juz to widze, ze to moze tak dzialac.

No i tu mozna przypomniec to co Jeff De luca powiedzial:

"I’m saying that
the Agile methods are more suited to types of people
and organisational cultures than types of project.”

water-scrum-fall to norma

Goraco polecam tekst o water-scrum-fall oraz dyskusje czytelnikow jakie mozna znalezc pod artykulem na infoq.

Zajawka na infoq
http://www.infoq.com/news/2011/12/water-scrum-fall-is-the-norm

Tekst w sdtims
http://www.sdtimes.com/content/article.aspx?ArticleID=36195&page=3

Opracowanie
http://www.cohaa.org/content/sites/default/files/water-scrum-fall_0.pdf

Crowdsourcing w tlumaczeniach

Jakis czas temu zabralem sie za tlumaczenie opowiadania na temat Real Options. Jest to swietny przyklad crowdsourcingu i sily jaka mozna uzyskac z spolecznego zaangazowania ludzi. Nie jest to w sumie nic nowego, m.in. OSS od dawna powstaje w podobny sposob. Samo pojecie nie podoba mi sie. Owszem jest cool, jest marketingowe jednak gubi sie w nim istota. W tlumie najcenniejsze sa jego skladowe, ludzie. Mozliwosc czerpania z ich wiedzy i doswiadczenia - nieoceniona plastycznosc mysli, ciagla krytyka oraz dostepnosc 24/7. Wiec na potrzeby marketingu crowdsourcing, a jak dla mnie to ludzie.

O estymacji

Koncze pisac specyfikacje, a co sie z tym wiaze zblizam sie do aktualizacji wstepnych oszacowan.
Podczas rozmowy z jednym z kolegow z projektu na temat tych wlasnie oszacowan uslyszalem cos czym chcialbym sie podzielic.

"Prognozowanie jest trudne zwlaszcza jesli chodzi o przyszlosc."

"Dlaczego nasz leader prosi nas co piatek o aktualizacje oszacowan?
On gra w totolotka i uwaza, ze jestesmy najlepszym generatorem liczb losowach."

Ha ha ha ha...

Real Options - tlumaczenie ksiazki

Od jakiegos czasu interesuje sie tamatem Real Options. Tak sie swietnie zlozylo, ze znalazlem informacje o inicjatywie trzech panow: Olav Maassen, Chris Matts, Chris Geary. Panowie maja w planie wydanie noweli traktujacej ten temat. Zglosilem sie jako tlumacz en2pl. Chcialbym zachecic ciebie, jesli Real Options jest rowniez dla ciebie interesujacym tematem, do zaangazowania sie w tlumaczenie tej ksiazki. Zostala juz stworzona odpowiednia grupa na portalu linkedin. Poza mozliwoscia zglebienia tematu, mozliwoscia kontaktu z osobami majacymi w tym temacie cos ciekawego do powiedzenia jest to rowniez okazja na zdobycie ciekawego doswiadczenia. Czakam na kolejnych czlonkow do polskiego teamu.

Po co to cale szacowanie?

W uproszczeniu szacowanie to okreslanie przyblizonej wartosci jakiejs wielkosci przy posiadaniu niepelnych danych.
Spotykamy sie z nim caly czas. Kiedy zony gotujac obiad dzwoni do meza wracajacego z pracy i pyta: "O ktorej bedziesz w domu?" prosi go o oszacowanie czasu jaki zajmie mu dojaz. Odpowiadz jaka udzieli obarczona jest bledem nawet jesli uda mu sie przybyc na czas.Co z tego, ze maz ma super szybka fure jesli nie wie bidulka, ze dwa skrzyzowania dalej byla stluczka i objazd nie jest mozliwy. Co to spowoduje w konteksie rodzinnego obiadu? To zalezy czy maz zadzwoni do zony i zaktualizuje wczesniej przekazane jej informacje.Moze jednak zalozyc, ze jego super szybka fura nadrobi stracony czas na kolejnym etapie drogi do domu i w zwiazku z tym, zakladajac, ze nic dodatkowo nie zakluci jego jazdy, nie ma sensu dzwonic i zawracac zonie glowy. Brzmi znajomo?

Wracajac do tematu: Po co to szacowania?
Odpowiedz zalezy w duzej mierze od punktu widzenia. Inaczej odpowie na nie malo doswiadczony pracownik, inaczej stary wyjadacz, ignorant, pracus, a jeszcze inaczej ten, ktory pilnuje aby zadania zostaly zrobione dobrze, w budzecie i na czas np. team leader.
No wiec zapytalem kilka osob i takie oto otrzymalem odpowiedzi.

• Malo doswiadczony pracownik: Ktos potrzebuje cos zaplanowac i kaze mi to robic wiec to robie.
• Stary wyjadacz: kierownictwo wciaz liczy, ze cos na tym projekcie zarobi. Podaje im co jakis czas nowe szacunki, a oni obliczaja to swoje cos.
• Ignorant: kaza mi to robie ale i tak zawsze wychodzi inaczej.
• Pracus optymista: naanalizowalem sie, naliczylem i na koncu przestraszylem, obetne troche zeby szef sie nie wkurzal.
• Team leader: zeby moc cokolwiek zaplanowac. Praca Henia zalezy od pracy Piotrka, praca testerow zalezy od pracy programistow, programistow od analitykow itd. no i jeszcze ludzie chce miec jakies wakacje (sic!), a klient pyta wciaz kiedy bedzie mogl uzyc zamowiony produkt.
  

Pytanie "Po co to szacowanie?" nurtowalo mnie czesto w momentach kiedy wiedzialem, ze wymagania lub specyfikacja sa dziurawe. No po co kaza mi to szacowac terazprzeciez za 2,3 dni dojdzie nowe wymaganie, cos sie zmieni w specyfikacji i trzeba bedzie robic to na nowo. To szacowanie to marnowanie czasu. Trzeba jakis czas poczekac, az temat dojrzeje i wtedy.... No wlasnie wtedy, "wtedy" jest tu kluczowym slowem. Zamiast zastanawiac sie kiedy bedzie to odpowiednie "wtedy" przyjmijmy, ze "wtedy" oznacza teraz. I zabierzymy sie do pracy.

Estymacja to zawsze duze wyzwanie, zwlaszcza kiedy dodamy do niej takie czynniki jak:

• nieznajomosc lub slaba znajomosc technik stosowanych do estymacji
• nieznajomosc lub slaba znajomosc domeny problemu
• niedokladnie zdefiniowane wymagania
• zaleznosc pomiedzy czesciami wykonywanymi przez rózne osoby. grupy, programy
  

Zbyt szczególowa analiza wymagan, zaleznosci i ciegle zmiany moge sparalizowac estymacje i moze ona niezostac ostatecznie zrobiona. Z drugiej strony moze sie okazac, ze estymacja byla zbyt pobiezna, optymistyczna co sprawilo, ze pewne sprawy zostaly pominiete.

Jak sobie z tym poradzic? Jak wkoncu szacowac zeby to mialo sens.

Po pierwsze trzeba to ciagle robic i uczyc sie na popelnionych bledach.
Mozna tez pomoc sobie okreslajac jakie szacowanie w danym momencie ma sens.

1. Szacowanie rzedu wielkosci (porównywanie z czyms podobnym) - odchylenie 2 lub 3 krotnosc rzeczywistej wielkosci. Mozna powiedziec, ze szacowanie rzedu wielkosci to zadne szacowanie. W tym przypadku jest to jedyne oszacowanie na którym mozemy sie jakkolwiek opierac. Ma ono znaczaca wartosc dla organizacji oraz zespolu projektowego poniewaz daje pewne wytyczne dla projektu jesli chodzi o czas, ludzi i pieniadze. Lepiej wiedziec, ze cos zajmie 4-6 miesiecy niz nie miec bladego pojecie ile to zajmie.
   
2. Zgrubna estymacja - odchylenie 50-100% rzeczywistej wielkosci Pracujesz z dobrze zrozumianymi wymaganiami, oraz jest ktos dobrze obeznany z domena problemu i problemami technicznymi, które moga sie pojawic.
   
3. Estymacja dokladna: odchylenie 25-50% rzeczywistej wielkosci. Jestes bardzo obeznany z tym co ma byc zrobione i robiles to juz wiele razy wczesniej. Takie podejscie nadaje sie do czynnosci wiele razy powtazanych (np. w utrzymaniu aplikacji) gdzie rozwiazania sa znane lub przy dodawaniu dobrze znanej i rozumianej funkcjonalnosci, która juz wczesniej byla dodawana.
   

W efekcie otrzymamy oszacowanie, ktore obarczone jest jak zawsze bledem. Patrzac bardzo ogolnie blad ten moze nazywac sie:

• przeszacowanie - wtedy moze sie okazac, ze do realizacji zostanie wziety ktos inny (inna firma lub inny pracownik) lub, ze w rezultacie pewne wygania nie zostana spelnione z braku czasu, zasobow. Redukcja wymagan moze wystapic juz na wstepie.
• niedoszacowanie - wymagania zostana zaakceptowane jednak niedostateczna ilosc czy czasu lub zasobów spowoduje brak ich realizacji. Redukcja wymagan nastpuje w pozniejszej fazie projektu, potrzeba przeplanowac prace ludzi, zespolow, termin dostarczenia produktu do klienta jest niedotrzymany.
  

Podsumowujac.
Warto pamietac, ze cale to szacowanie nie sluzy do przewidywania przysylosci ale pomaga dowiedziec sie jakie decyzje nalezy podjac obecnie. Np. obecnie nie trzeba zmieniac planu i podzialu zadan poniewaz ty wciaz twierdzisz, ze sie wyrobisz, a przynajmniej nie sygnalizujesz, ze cos idzie nie tak ;)

Pani Linda Rising powiedziala bardzo ladne zdanie, ktore pasuje do tematu szacowania:

Podejmuj zdecydowane decyzje ale nie trzymaj sie ich kurczowo, dopuszczaj zmiany.

O tym napisze nastepnym razem.