On Fri, 13 Jul 2007 19:18:04 -0000, Tequila Uć wrote:
> a nie skutkuje to przymykaniem oka na błędy, po to żeby samemu nie być
> zbyt surowo ocenionym??
jeżeli ktoś traktuje wytknięcie błędu jako naukę to nie powinno. Jeżeli ich
ilość ma wpływać na premię to masz rację, ja bym żadnego błędu nie wytknął i
prawdopodobnie zmienił pracę:)


Taki wzorek o którym myślisz IMHO by na Nobla zasługiwał.

Pzdr

--
http://www.pajacyk.pl - czy już dzisiaj kliknąłeś dla dzieciaków?
( przypominacz: http://ds5.agh.edu.pl/~cysiek10/pajacyk/ )

do góry

Dnia Fri, 13 Jul 2007 19:18:04 -0000, Tequila Uć <p...@p...onet.pl>
w <1...@n...googlegroups.c
om> napisał:

>
>> Słyszałem o takim podejściu, aby _wzajemnie_ dokonywać inspekcji kodu.
>> Bynajmniej nie po to, aby uzyskać statystyki kto ile byków/linijkę kodu
>> robi, ale aby "cenzor" miał świadomość, że niedługo sam będzie oceniany
>> przez drugą osobę. W efekcie ocena nie jest zbyt surowa, kulturalnie zwraca
>> się uwagę.
>
> a nie skutkuje to przymykaniem oka na błędy, po to żeby samemu nie być
> zbyt surowo ocenionym??
> Ja też nie chcę tworzyć statystyk dla samego ich tworzenia. Szukam po
> prostu matematycznego modelu, który będzie potem miał przełożenie na
> premię.

http://www.joelonsoftware.com/
Gdzieś tam było napisane, jak ładnie matematycznymi modelami załątwić
kreatywność w programowaniu, czyli spowodować, że programiści zamaist
programować zaczną nabijać punkty w rankingu, kod będzie lepiej
punktowany i bardziej syfiasty.

Do audytu kodu musisz mieć bardzo solidne ustalenia.
I przygotować ewentualnie instancjęweryfikującą jakość owego audytu,
czyli nie że koleś A umówi się z kolesiem B na tyle a tyle błędów, A je
zrobi, B je znajdzie, a potem odwrotnie, i obaj będą wygrani, podczas
gdy tych błędów od początku mogło nie być.
Gra o sumie zerowej wystartuje wyścig szczurów, o sumie dodatniej
zarżnie produktywność.

ja czyli jakub
--
Z zaparkowanego Forda Fulkersona wysiedli generał Grant i porucznik
Revoke.

do góry

szomiz wrote:
> U?ytkownik "Tequila Uae" <p...@p...onet.pl> napisa? w wiadomo?ci
> news:1184272861.051144.218620@d55g2000hsg.googlegrou
ps.com...
>
>> Co s?dzicie o takim podej?ciu??
>
> Sadzimy, ze firma dojrzala do uzyskania ISO i zejscia na psy.
>
> BP, MSPANC
>
> sz.
>
>
A propos ISO. Firma bez iso-> jeden gwizdze, dziesieciu wiosluje. ISO
9xxx -> 10 gwizdze, 1 wiosluje, ISO 14xxx -> przewazylo kajak i ten
jeden nie dosiega wioslem do wody, ale wiosluje dzielnie.

IMHO. Jest cos takiego jak Extreme programing. Mam mala wiedze, ale
dwoch siedzi jeden pisze drugi patrzy jak chca to sie zmieniaja. Chodzi
o to, ze koszt naprawy bledu jest najmniejszy na etapie pisania i druga
osoba do pomocy jest tansza i efektywniejsza niz 7 stopni testow.

Systemow premiowo punktowych nie polecam.

Pozdrawiam
Przemek

do góry

Użytkownik "PZ" <p...@m...com> napisał w wiadomości
news:0qnnm4-d88.ln1@minskmaz.com...

> IMHO. Jest cos takiego jak Extreme programing. Mam mala wiedze, ale

Ino, ze to sie (czasami) sprawdza w malych zespolach, a nie w organizacjach
pretendujacych do miana korporacji.

-- --- -- --- -- ---
sz. & Draco - byrnenski pies pasterski
http://szomiz.republika.pl/dod/draco/

do góry

"szomiz" <s...@k...dostawac.reklamy.przez.net> wrote in message
news:f7bamo$pul$1@atlantis.news.tpi.pl...
> Użytkownik "PZ" <p...@m...com> napisał w wiadomości
> news:0qnnm4-d88.ln1@minskmaz.com...
>
>> IMHO. Jest cos takiego jak Extreme programing. Mam mala wiedze, ale
>
> Ino, ze to sie (czasami) sprawdza w malych zespolach, a nie w
> organizacjach pretendujacych do miana korporacji.
>
Co nie znaczy, ze nie jest w korporacjach niekiedy stosowane. Z roznym
skutkiem zreszta.

pzdr
Muchomor

do góry

Dnia Sat, 14 Jul 2007 18:42:22 +0100, PZ <p...@m...com>
w <0...@m...com> napisał:

> szomiz wrote:
>> U?ytkownik "Tequila U?" <p...@p...onet.pl> napisa? w wiadomo?ci
>> news:1184272861.051144.218620@d55g2000hsg.googlegrou
ps.com...
>>
>>> Co s?dzicie o takim podej?ciu??
>>
>> Sadzimy, ze firma dojrzala do uzyskania ISO i zejscia na psy.
>>
>> sz.

> A propos ISO. Firma bez iso-> jeden gwizdze, dziesieciu wiosluje. ISO
> 9xxx -> 10 gwizdze, 1 wiosluje, ISO 14xxx -> przewazylo kajak i ten
> jeden nie dosiega wioslem do wody, ale wiosluje dzielnie.
>
> IMHO. Jest cos takiego jak Extreme programing. Mam mala wiedze, ale
> dwoch siedzi jeden pisze drugi patrzy jak chca to sie zmieniaja. Chodzi
> o to, ze koszt naprawy bledu jest najmniejszy na etapie pisania i druga
> osoba do pomocy jest tansza i efektywniejsza niz 7 stopni testow.

Mocno zależy od mentalności pracowników i ich własnego i wzajemnego
przekonania o swojej/cudzej nieomylności.
Możesz mieć gości przekonanych że oni wiedzą najlepiej i w dowolnych
konfiguracjach, i żadne extreme im nie pomogą, bo będą robili i
puszczali przez review takie kwasy, że proszę siadać.

A błędy to najtaniej poprawić na etapie projektowania ideowego a nie
kodowania.

> Przemek

ja czyli jakub
--
Z zaparkowanego Forda Fulkersona wysiedli generał Grant i porucznik
Revoke.

do góry

"Tequila Uć" <p...@p...onet.pl> wrote in message
news:1184354284.050700.243020@n60g2000hse.googlegrou
ps.com...

>> Słyszałem o takim podejściu, aby _wzajemnie_ dokonywać inspekcji kodu.
>> Bynajmniej nie po to, aby uzyskać statystyki kto ile byków/linijkę kodu
>> robi, ale aby "cenzor" miał świadomość, że niedługo sam będzie oceniany
>> przez drugą osobę. W efekcie ocena nie jest zbyt surowa, kulturalnie
>> zwraca
>> się uwagę.

>a nie skutkuje to przymykaniem oka na błędy, po to żeby samemu nie być
>zbyt surowo ocenionym??

Code review czy Peer review nie maja na celu oceny _programisty_. Jesli to
jest Twoim celem to lepiej zapomnij o inspekcjach. W sumie to nie zapominaj
bo to na prawde potezna metoda w zapewnianiu jakosci, tylko ewentualne
metryki wykorzystuj do oceny produktu, a nie pracownikow.
Naczelna idea jest taka, ze zglaszane bledy nie sa atakiem na autora, tylko
przyczynkiem do poprawienia jakosci kodu. koniec kropka.
Code review ma za zadanie wychwycic bledy w kodzie, niedostateczna
jakosc/ilosc komentarzy, brak odnosnikow do dokumentacji, odstepstwa od
coding standardu jesli taki obowiazuje itp. Jak zaczniesz do tego dorabiac
ideologie przeliczalna na premie to cala zabawa straci calkowicie sens.

>Ja też nie chcę tworzyć statystyk dla samego ich tworzenia. Szukam po
>prostu matematycznego modelu, który będzie potem miał przełożenie na
>premię.
Otworz ksiazke do matematyki i wybierz dowolny wzor. wszystkie beda mialy
taki sam sens.

pzdr
Muchomor

do góry

Tequila Uć <p...@p...onet.pl> napisał(a):

> Witam,
> Zastanawiam si=EA nad wprowadzeniem punktowego systemu oceny
> zaanga=BFowania ludzi w projektach. Projekty to typowy informatyczny
> design/tworzenie nowych aplikacji. Ocena ma da=E6 matematyczny wk=B3ad dla
> decyzji o marchewce (nagroda), jak i karze (obni=BFenie premii
> pracownika).
> Posiadacie jakie=B6 do=B6wiadczenie w tym temacie, kt=F3rym mo=BFecie si=EA
> podzieli=E6??
> Pzdr
> Tequila U=E6
>

Wszelkie "sistiemy" mają te wadę, że są oparte na jakiś estymacjach na
poczatku projektu, które potem mają luźny związek z rzeczywistościa na końcu
projektu, więc jak ktoś sie będzie chcial tego niewolniczo trzymac, to albo
popadnie w absurdy, albo i tak w końcu będzie decydowal na zasadzie "raz, dwa,
trzy, nagrode dostaniesz ty", więc całkowie przeciwieństwo swoich założen.

Najlepsza metoda jest po prostu dobra komunikacja z zespołem, rozmowy,
dyskusje, okresowa weryfikacje, inspekcje i budowanie sobie obrazu sytuacji na
podstawie rzeczywistej wiedzy i znajomości co się dzieje.


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

ok. dzięki wszystkim za opinie.

--
Tequila Uć

do góry

gdyby skupić się jedynie na aspekcie jakosciowym programowania?? praca
zorganizowana jest w taki sposób iż fragment kodu (blok) napisany
przez jednego programistę jest inspektowany przez innego pracownika.
tak na gorąco:

Wprowadź sobie coś takiego ale na zasadach doksonalenia zarządzania a nie
oceny pracowników.
wyznaczasz timebox i tak jak napisałeś peer review oprogramowania w celu
utrzymania/podniesienia jakości

Po kilku iteracjach będziesz wiedział jak zarządzać zadaniami na poziomie
timebox'u aby się mieścić i robić produkt dobry jakościowo. Do produktu rób
sobie backlog tworzący bazę więdzy zarówno o produkcie jak i o zarządzaniu.
To automatycznie da Ci przegląd wydajności pracowników, ale nie
przekształcaj tego w system oceny bo stracisz ludzi i rozwalisz zespół.

Dobrze jest wprowadzić test driven development ale to może wymagać naprawdę
sporych wysiłków bo będziesz musiał zmienic mentaność i sposób myślenia
ludzi. To bywa bolesne i dla tego lepiej sprawdza się przy budowaniu nowego
zespołu niż wprowadzaniu zmian w zeposle juz istaniejącym i w pewiem sposób
zgranym lub dotartym


---
Tequila Uć

do góry