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ąć?

--
pozdrawiam
Roman Tyczka

do góry

Od wieków jest tak:
Przewidywania czasu optymistycznego (czyli w wersji bezproblemowej) co najmniej x2.

do góry

> Od wieków jest tak:
> Przewidywania czasu optymistycznego (czyli w wersji bezproblemowej) co najmniej x2.
>

Dokładnie. A jak ktoś się upiera, że "dobrze przemyślał" to i tak się
dodaje 20% i przekazuje dalej do góry ;-)

--
Pozdrawiam,
Mateusz Bogusz

do góry

On Fri, 28 Apr 2017 20:03:02 +0200, Mateusz Bogusz wrote:

>> Od wieków jest tak:
>> Przewidywania czasu optymistycznego (czyli w wersji bezproblemowej) co najmniej
x2.
>
> Dokładnie. A jak ktoś się upiera, że "dobrze przemyślał" to i tak się
> dodaje 20% i przekazuje dalej do góry ;-)

Ok, ale ja pytam o ten czas bazowy, który potem mnożycie. Jak go
wyliczacie? Bo chyba nie na czuja?

--
pozdrawiam
Roman Tyczka

do góry

On Friday, April 28, 2017 at 8:39:26 PM UTC+2, Roman Tyczka wrote:
> On Fri, 28 Apr 2017 20:03:02 +0200, Mateusz Bogusz wrote:
>
> >> Od wieków jest tak:
> >> Przewidywania czasu optymistycznego (czyli w wersji bezproblemowej) co najmniej
x2.
> >
> > Dokładnie. A jak ktoś się upiera, że "dobrze przemyślał" to i tak się
> > dodaje 20% i przekazuje dalej do góry ;-)
>
> Ok, ale ja pytam o ten czas bazowy, który potem mnożycie. Jak go
> wyliczacie? Bo chyba nie na czuja?
>

Generalnie właśnie na czuja.
Gdyby istniała jedna, dobra metoda szacowania pracochłonności nie "na czuja"
(dobra czyli taka, ze oszacowania się sprawdzają), to inżynieria oprograowania byłaby
dziedziną nie wymagającą większej wiedzy i doświadczenia niż skanowanie produktów w
kasie w supermarkecie.

https://en.wikipedia.org/wiki/Software_development_e
ffort_estimation

--
Michal

do góry

> Ok, ale ja pytam o ten czas bazowy, który potem mnożycie. Jak go
> wyliczacie? Bo chyba nie na czuja?

Zwykle da się zdekomponować problem na etapy, a te na konkretne prace jakie trzeba
wykonać i wtedy wychodzi mniej więcej co jest do zrobienia. I wtedy określa się ile
to czasu może zająć w wersji "optymistycznej".

do góry

(piszę z punktu widzenia frajera co nie potrafi głosować)

to jest ciekawy temat... to jest bardzo ciekawy temat...

pytasz o to, czy praca polega na zmianie 1000 wywołań procedur
zmieniających zmienną pomocniczą, czy może o pracy która polega na
obczajeniu jakiegoś skomplikowanego, bliżej nie znanego nam, o którym na
początku nie mamy zielonego pojęcia - zagadnienia sukces-popis/eu?

do góry

On Saturday, April 29, 2017 at 11:18:14 AM UTC+2, s...@g...com wrote:
> > Ok, ale ja pytam o ten czas bazowy, który potem mnożycie. Jak go
> > wyliczacie? Bo chyba nie na czuja?
>
> Zwykle da się zdekomponować problem na etapy, a te na konkretne prace jakie trzeba
wykonać i wtedy wychodzi mniej więcej co jest do zrobienia. I wtedy określa się ile
to czasu może zająć w wersji "optymistycznej".

To najlepsza metoda z jaką miałem styczność. Ponadto wykonuje się część
prac, jakiś prototyp i ekstrapoluje się nakład pracy na całość. Niestety
to już wymaga np. tygodnia czasu pracy zespołu. Jeśli pracuje się
na stosunkowo podobnych aplikacjach, to po nabraniu doświadczenia
można wykonywać aplikację w 120%-150% czasu szacowanego.

Generalnie problem jednak jest nieprzewidywalny. Nakład pracy może
zwiększyć się znacząco gdy jakaś ważna biblioteka okaże się
nieprzydatna.

Pozdrawiam

do góry

Roman Tyczka <n...@b...no> wrote:

> Ok, ale ja pytam o ten czas bazowy, który potem mnożycie. Jak go
> wyliczacie? Bo chyba nie na czuja?

Na czuja. Tak samo jak szacowanie ilości wymaganego flasha w AVR-ach per
projekt, zanim ten projekt jeszcze się rozpocznie. Po jakimś czasie
nabiera się wprawy.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

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 ;)




---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry