On 04.05.2017 22:34, pwola wrote:
> On Fri, 28 Apr 2017 10:08:01 -0700 (PDT), s...@g...com wrote:
>
>> Od wieków jest tak:
>> Przewidywania czasu optymistycznego (czyli w wersji bezproblemowej) co najmniej
x2.
>
> Stara zasada
> x2 i przyjąć jednostkę bezpośrednio wiekszą
> tzn. coś co można zrobić w jeden dzień zajmuje 2 tygodnie ;)


Czyli małe zadania mają wspolczynnik bezpeczeństwa 14,
średnie "a w tydzień, może trzy" już tylko x8,
za to zadania większe, planowane na miesiące, nagla
wymagają powiększenia szacowanego czasu aż 24 razy.

Dziwne.

Chyba, że zamiast miesiac-> rok weźmiemy miesiąc-> kwartał.

Wtedy mamy x14, x8 i x6,

;-)

pzdr
bartekltg

do góry

On Friday, April 28, 2017 at 1:04:39 PM UTC+2, Roman Tyczka wrote:
> Jak u Was wygląda problem szacowania czasu realizacji zleconych zadań?
> Przykładowo oczekuje się od Was by dodać do projektu jakąś nową
> funkcjonalność, która wymaga zmian jednocześnie na poziomie bazy danych,
> skryptów, kodu właściwego, GUI, jakiś innych związanych z projektem
> przydupasów typu instalatory, autoupdaty, instrukcje, etc.
>
> Jak szacujecie ile to zajmie, gdy management żąda tej wiedzy by wyceny
> dokonać?
> Można owszem strzelać, ale każdy rozjazd jest źle postrzegany. Da się to w
> ogóle jakoś sensownie i praktycznie ogarnąć?

Estymacja to jest ładna nazwa dla zgadywania. Jeśli robisz coś
po raz pierwszy, to skąd możesz wiedzieć ile Ci to zajmie? Jak
robiłem powtarzalne rzeczy, to zwykle zgadywałem dobrze. Ale czasem
okazywało się, że trafiłem na minę: bez poważnego refactoringu
nie dawało się zrobić jakiejś pozornie łatwej rzeczy. I nagle
z 4 godzin, robiło się kilka dni.

Na szczęście obecnie mam szefa, który stąpa twardo po ziemi
i np. pozwala robić prototyp. Na zasadzie: zacznij robić i jak
po X dniach widzisz, że ci zajmie dużo więcej, to pomyślimy.

Czasem zdarzają się też rzeczy mocno losowe; w zeszłym roku
mieliśmy taki dzień, że co chwilę brakowało prądu. Tego nawet
Wróżbita Wojciech (zbieżność imion przypadkowa) nie przewidzi. :)

w.

do góry

On Thursday, May 4, 2017 at 10:35:03 PM UTC+2, pwola wrote:
> On Fri, 28 Apr 2017 10:08:01 -0700 (PDT), s...@g...com wrote:
>
> >Od wieków jest tak:
> >Przewidywania czasu optymistycznego (czyli w wersji bezproblemowej) co najmniej
x2.
>
> Stara zasada
> x2 i przyjąć jednostkę bezpośrednio wiekszą
> tzn. coś co można zrobić w jeden dzień zajmuje 2 tygodnie ;)

Jak nawali kilka rzeczy, to szacowanie nakładu pracy w trakcie realizacji
właśnie tak drastycznie rośnie względem szacunków przed podjęciem pracy.

Pozdrawiam

do góry

On Friday, May 5, 2017 at 9:18:27 PM UTC+2, Wojciech Muła wrote:
> On Friday, April 28, 2017 at 1:04:39 PM UTC+2, Roman Tyczka wrote:
> > Jak u Was wygląda problem szacowania czasu realizacji zleconych zadań?
> > Przykładowo oczekuje się od Was by dodać do projektu jakąś nową
> > funkcjonalność, która wymaga zmian jednocześnie na poziomie bazy danych,
> > skryptów, kodu właściwego, GUI, jakiś innych związanych z projektem
> > przydupasów typu instalatory, autoupdaty, instrukcje, etc.
> >
> > Jak szacujecie ile to zajmie, gdy management żąda tej wiedzy by wyceny
> > dokonać?
> > Można owszem strzelać, ale każdy rozjazd jest źle postrzegany. Da się to w
> > ogóle jakoś sensownie i praktycznie ogarnąć?
>
> Estymacja to jest ładna nazwa dla zgadywania. Jeśli robisz coś
> po raz pierwszy, to skąd możesz wiedzieć ile Ci to zajmie? Jak
> robiłem powtarzalne rzeczy, to zwykle zgadywałem dobrze. Ale czasem
> okazywało się, że trafiłem na minę: bez poważnego refactoringu
> nie dawało się zrobić jakiejś pozornie łatwej rzeczy. I nagle
> z 4 godzin, robiło się kilka dni.
>
> Na szczęście obecnie mam szefa, który stąpa twardo po ziemi
> i np. pozwala robić prototyp. Na zasadzie: zacznij robić i jak
> po X dniach widzisz, że ci zajmie dużo więcej, to pomyślimy.
>
> Czasem zdarzają się też rzeczy mocno losowe; w zeszłym roku
> mieliśmy taki dzień, że co chwilę brakowało prądu. Tego nawet
> Wróżbita Wojciech (zbieżność imion przypadkowa) nie przewidzi. :)

Zaniki prądu, przewidywalne czy nie, albo na krótko zaburzają
pracę, albo stosuje się agregaty :) Natomiast ciężka choroba
25% krytycznej części personelu (np. jedna osoba o specyficznych
umiejętnościach w zespole czteroosobowym) może wydłużyć
czas o miesiąc, dwa, albo trzy - tyle potrzeba czasami na
zatrudnienie specjalisty, wyzdrowienie lub wyszkolenie
innego pracownika.

Inna sytuacja, choruje znowu jedna osoba
która znowu stanowi 25% zespołu i jest autorem dużej
części kodu pisanego w sposób bałaganiarski, bez
dokumentowania i z powodu np. dużej presji czasu, albo
zmęczenia spowodowanego przepracowaniem. Co zrobić w
takim przypadku? Kodzili w czwórkę od roku, jeden
pracownik się rozchorował, brak postępu w jego części
kodu zacznie blokować resztę, nikt inny szybko się
nie połapie w jego kodzie?


Kolejny przypadek, przerabiałem to na własnej skórze
kilka razy. Opierałem błyskawiczny czas wykonania
jakiegoś zadania o bibliotekę. Biblioteka okazywała
się do bani. Napisanie samemu funkcjonalności jaką
oferowała biblioteka zajęłoby właśnie 20-30 razy
więcej czasu niż szacunki wykonania całego projektu.
Trzeba było się napracować, oddać pieniądze i
jeszcze przeprosić - dobrze że kar nie było :)

Co więcej... Rozbijamy projekt na funkcjonalne
części pierwsze. Duży projekt, dużo guziczków,
dużo scenariuszy, dużo pod-funkcjonalności, innymi
slowy idealne warunki do ekstrapolacji. Robimy
prototyp, przygotowujemy kod do wielokrotnego
użycia, zwykle czas jest niedoszacowany, ale
na początku jest większy nakład pracy na wykonanie
kodu do wielokrotnego użycia - jedno (lepiej
lub gorzej) kompesnuje drugie - więc znowu
idealne warunki do ekstrapolacji. Wykonujemy
10% projektu, 20%, może nawet 30%, wszystko
gładko idzie, ekstrapolujemy czas, dajemy
klientowi gwarancje, może zgadzamy się na
jakieś kary umowne, nagle pojawia się kilka
nieuwzględnionych problemów w prototypie:
np. właśnie choroba, problem z biblioteką,
albo algorytm o którym myśleliśmy że rozwiąże
dany problem jednak go nie rozwiązuje i trzeba w
ogóle zastanowić się nad możliwością rozwiązania
danego zadania na komputerze. Ilu z Was myślało,
że np. dobry program do gry w szachy da się napisać
przy użyciu algorytmu alpha-beta? Ja dla mnie to
było oczywiste, ale potem okazało się, że oprócz
alpha-bety trzeba jeszcze pierdylion heurystyk -
takie niedopatrzenie algorytmyczne może zwiększyć
nakład czasu pracy np. 1000 razy.

Można przejechać się do bólu, niemniej rozbijanie
na funkcjonalne części pierwsze plus wykonanie
prototypu plus ekstrapolacja to najlepsza metoda
jaką znam.

Pozdrawiam

do góry

ktoś się zesr... i wypierdział odpowiedź na moje pytanie: okazuje się,
że liderzy popis/eu podejmują się zupełnie kompletnie nie znanych sobie
prac i jeszcze umawiają się ze sponsorami na określony czas... i pewnie
jakieś kary... no to ciekawe...

do góry

On Wednesday, May 10, 2017 at 6:05:46 PM UTC+2, niepełnosprawny intelektualnie
'POPIS/EU wrote:
> ktoś się zesr... i wypierdział odpowiedź na moje pytanie: okazuje się,
> że liderzy popis/eu podejmują się zupełnie kompletnie nie znanych sobie
> prac i jeszcze umawiają się ze sponsorami na określony czas... i pewnie
> jakieś kary... no to ciekawe...

Raczej ktoś zasrał wszystkie grupy postami takimi jak ten.

do góry

skoro już ot to pogadajmy o tym, gdzie znajdują się wątki merytoryczne?
na politechnice warszawskiej? (taki żart)

interesuje mnie wyłącznie sranie - dopóki nie ogarnę tego w jakąś
działającą teorię która pozwoli na skuteczną obronę - nie planuję,
żadnych zmian... oczywiście można mi pomóc, chyba, że do głosu dojdą
dyrektywy...

do góry

> Na szczęście obecnie mam szefa, który stąpa twardo po ziemi
> i np. pozwala robić prototyp. Na zasadzie: zacznij robić i jak
> po X dniach widzisz, że ci zajmie dużo więcej, to pomyślimy.

O ile kierownikiem projektu nie jest właściciel firmy, to tak to powinno
wyglądać :-)

--
Pozdrawiam,
Mateusz Bogusz

do góry

On Thursday, May 11, 2017 at 8:08:37 PM UTC+2, Mateusz Bogusz wrote:
> > Na szczęście obecnie mam szefa, który stąpa twardo po ziemi
> > i np. pozwala robić prototyp. Na zasadzie: zacznij robić i jak
> > po X dniach widzisz, że ci zajmie dużo więcej, to pomyślimy.
>
> O ile kierownikiem projektu nie jest właściciel firmy, to tak to powinno
> wyglądać :-)

A jak szef to co?
Pozdrawiam

do góry

Gadanie. Nakład pracy na projekt informatyczny jest nieprzewidywalny. Nie rozmawiamy
o helołordach.

do góry