piątek, 20 stycznia 2012

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.


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, 13 grudnia 2011

Testy Alibi

Spotkalem sie dzisiaj z nowym rodzajem testow. Tak mi sie on spodobal, ze zechcialem wspomniec o nim na blogu. Chodzi o Testy Alibi. Moja definicja tego pojecia jest nastepujaca:

Testy Alibi - to takie testy, ktorych glownym celem jest istnienie samo w sobie.

Jesli ktos pyta czy do danego kodu napisane sa testy to w przypadku testow alibi mozna odpowiedziec, ze oczywiscie tak. Najlepiej odpowiedziec na tyle stanowczo zeby nie otrzymac kolejnego pytania na ich temat.

piątek, 9 grudnia 2011

S.O.L.I.D i refaktoring

Wszystkim zainteresowanym tematem polecam mocno wg mnie dobre darmowe e-booki traktujace temat SOLIDnego projektowania i refaktoryzacji.

piątek, 2 grudnia 2011

Po co nam te javadocki, komantarze, etc...

Grzebiac w kodzie znalazlem kilka metod opatrzonych takim oto komentarzem:

"Life is too short..."

Autor mial zapewne wazniejsze rzeczy do robienia podczas pisania kodu i niepisania javadoca. Ocenil sytuacje i stwierdzil, ze szkoda jego cennego czasu, jego zycia na takie pierdoly. Po jakims czasie ja trafiam na to miejsce starajac sie zrozumiec jak cos dziala. Co z moim czasem, z moim zyciem? Patrzac z szerszej perspektywy, ktos bedzie musial za to zaplacic i z pewnoscia nie autor, ktory zaoszczedzil swoj czas.
Podumowujac:
Kod wiecej razy czytamy niz piszemy. Dlatego tak wazne jest zeby juz napisany byl czytelny i zrozumialy. Wszystkim piszacym kod polecam ksiazke "Clean Code" by Robert C. Martin (Uncle Bob).

piątek, 25 listopada 2011

Czy znasz wystarczajaco dobrze narzedzia, ktorych uzywasz?

Jaka jest twoja odpowiedz na to pytanie? Nie badz taki surowy ;) przeciez jestes wazna, nieprzecietna osoba! Jak trzeba bedzie to nauczysz sie wszystkiego w 2 dni.

Zaczne moze od tego, ze glownym powodem mojej sympatii do szeroko pojetego tematu komputerow i nauki o nich jest to, ze komputery moga wykonac szybko pewne zadane przez ludzi zadania. W ten sposob moga nam ulatwic zycie. Ulatwic zycie znaczy w pewnych sytuacjach oszczedzic nasz cenny czas.

Spojrzmy teraz na pewien zespol programistow. Jest ich 6. Codziennie spedzaja w pracy 8-9 godzin. Z tego efektywnie pracuja 4-6. Tu wtrace, ze blokowanie dostepu do pewnych zasobow internetu wcale nie poprawia, a czesto pogarsza ten wynik. Dla uproszczenia przyjme ze kazda osoba pracuje 5 = (6+4)/2 godzin dziennie. Do pracy uzywaja pewnego zbioru narzedzi. Nie znaja jednak wielu zastosowan tych narzedzi. Znaja pewne ich zastosowania i do tego maje wlasne przyzwyczajenia. Co sie stanie jesli pokazesz im jak uzywac narzedzi tak aby zaoszczedzili 10 minut dziennie?

10 min * 6 osob *20 dni pracy na miesiac * 12 miesiecy = 14400 minut
14400 minut / 60 minut / 8 godzin deklarowanej pracy na dzien = 30 dni
14400 minut / 60 minut / 5 efektywnej pracy = 48 dni!

Tak. Kazdy latwo sobie dalej przemnozy ile to pieniedzy (programisci pomnoza przez p, managerowie przez p*m, gdzie m>8). Jaki z tego wniosek?
Doskonalenie rzemiosla do pewnego poziomu oplaca sie.
W kolejnych postach opisze historie programisty Henia, ktoremu udalo sie wprowadzic pewne usprawnienia w projekcie, w ktorym pracuje. Zastanowimy sie tez ile oszczednosci moglo to wprowadzic.
A ile oszczednosci moze to wprowadzic w twojej pracy, niekoniecznie zawodowej?

niedziela, 6 listopada 2011

Jak dziala hibernate'owy cache

Jako, ze w kolejce czekaja zadania z optymalizacji aplikacji. Postanowilem zbadac jak dziala cache w hibernate. Zanim bede czytal kod hibernate (glownie na potrzeby second-level-cache) zapoznalem sie z tekstami innych programistow. Ten artykul uwazam za jeden z ciekawszych:
http://blog.dynatrace.com/2009/02/16/understanding-caching-in-hibernate-part-one-the-session-cache/

Kolejne czesci latwo wskaze uncle Google.