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