Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pl.comp.programming > #29639 > unrolled thread

Szacowanie czasu realizacji zadań

Started byRoman Tyczka <noemail@because.no>
First post2017-04-28 13:04 +0200
Last post2017-05-17 21:22 +0200
Articles 20 on this page of 38 — 13 participants

Back to article view | Back to pl.comp.programming


Contents

  Szacowanie czasu realizacji zadań Roman Tyczka <noemail@because.no> - 2017-04-28 13:04 +0200
    Re: Szacowanie czasu realizacji zadań szykcech@gmail.com - 2017-04-28 10:08 -0700
      Re: Szacowanie czasu realizacji zadań Mateusz Bogusz <mabakay@o2.pl> - 2017-04-28 20:03 +0200
        Re: Szacowanie czasu realizacji zadań Roman Tyczka <noemail@because.no> - 2017-04-28 20:39 +0200
          Re: Szacowanie czasu realizacji zadań michal@kleczek.org - 2017-04-29 02:05 -0700
          Re: Szacowanie czasu realizacji zadań szykcech@gmail.com - 2017-04-29 02:18 -0700
            Re: Szacowanie czasu realizacji zadań "M.M." <mmarszik@gmail.com> - 2017-04-29 11:48 -0700
          Re: Szacowanie czasu realizacji zadań gof@somewhere.invalid (Adam Wysocki) - 2017-04-30 19:49 +0000
      Re: Szacowanie czasu realizacji zadań pwola <pwola@polbox.com> - 2017-05-04 22:34 +0200
        Re: Szacowanie czasu realizacji zadań bartekltg <bartekltg@gmail.com> - 2017-05-05 06:36 +0200
        Re: Szacowanie czasu realizacji zadań "M.M." <mmarszik@gmail.com> - 2017-05-05 12:57 -0700
    [OT] Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-29 11:48 +0200
      Re: [OT] Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-10 18:05 +0200
        Re: [OT] Szacowanie czasu realizacji zadań "M.M." <mmarszik@gmail.com> - 2017-05-11 09:18 -0700
          Re: [OT] Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-11 18:40 +0200
    Re: Szacowanie czasu realizacji zadań Wojciech Muła <wojtek.mula@gmail.com> - 2017-05-05 12:18 -0700
      Re: Szacowanie czasu realizacji zadań "M.M." <mmarszik@gmail.com> - 2017-05-05 13:24 -0700
        Re: Szacowanie czasu realizacji zadań "H.D." <hinidasini@gmail.com> - 2017-05-12 06:28 -0700
          Re: Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-12 17:24 +0200
          Re: Szacowanie czasu realizacji zadań michal@kleczek.org - 2017-05-13 22:34 -0700
            Re: Szacowanie czasu realizacji zadań "M.M." <mmarszik@gmail.com> - 2017-05-14 00:43 -0700
              Re: Szacowanie czasu realizacji zadań Wojciech Muła <wojtek.mula@gmail.com> - 2017-05-14 01:55 -0700
                Re: Szacowanie czasu realizacji zadań "M.M." <mmarszik@gmail.com> - 2017-05-14 09:46 -0700
              Re: Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-14 18:22 +0200
                Re: Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-14 18:39 +0200
                  Re: Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-16 12:01 +0200
                    Re: Szacowanie czasu realizacji zadań "H.D." <hinidasini@gmail.com> - 2017-05-16 03:50 -0700
                      Re: Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-16 16:25 +0200
                        [OT] Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-16 16:27 +0200
                          Re: [OT] Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-16 19:32 +0200
                            Re: [OT] Szacowanie czasu realizacji zadań Sebastian Biały <heby@poczta.onet.pl> - 2017-05-16 20:31 +0200
                          Re: [OT] Szacowanie czasu realizacji zadań fir <profesor.fir@gmail.com> - 2017-05-16 11:54 -0700
                            Re: [OT] Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-16 21:10 +0200
                              Re: [OT] Szacowanie czasu realizacji zadań fir <profesor.fir@gmail.com> - 2017-05-16 12:58 -0700
                                Re: [OT] Szacowanie czasu realizacji zadań niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-17 16:55 +0200
      Re: Szacowanie czasu realizacji zadań Mateusz Bogusz <mabakay@o2.pl> - 2017-05-11 20:08 +0200
        Re: Szacowanie czasu realizacji zadań "M.M." <mmarszik@gmail.com> - 2017-05-11 11:50 -0700
          Re: Szacowanie czasu realizacji zadań Mateusz Bogusz <mabakay@o2.pl> - 2017-05-17 21:22 +0200

Page 1 of 2  [1] 2  Next page →


#29639 — Szacowanie czasu realizacji zadań

FromRoman Tyczka <noemail@because.no>
Date2017-04-28 13:04 +0200
SubjectSzacowanie czasu realizacji zadań
Message-ID<m1bhowamnfu8$.dlg@tyczka.com>
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

[toc] | [next] | [standalone]


#29641

Fromszykcech@gmail.com
Date2017-04-28 10:08 -0700
Message-ID<abc79ca2-df32-43e5-9168-9baf1ad04880@googlegroups.com>
In reply to#29639
Od wieków jest tak: 
Przewidywania czasu optymistycznego (czyli w wersji bezproblemowej) co najmniej x2.

[toc] | [prev] | [next] | [standalone]


#29642

FromMateusz Bogusz <mabakay@o2.pl>
Date2017-04-28 20:03 +0200
Message-ID<oe004m$g6j$1@node1.news.atman.pl>
In reply to#29641
> 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

[toc] | [prev] | [next] | [standalone]


#29643

FromRoman Tyczka <noemail@because.no>
Date2017-04-28 20:39 +0200
Message-ID<1remqkvbfssgg$.dlg@tyczka.com>
In reply to#29642
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

[toc] | [prev] | [next] | [standalone]


#29644

Frommichal@kleczek.org
Date2017-04-29 02:05 -0700
Message-ID<1840d20e-d9f6-4de3-8ccb-c3142eb56935@googlegroups.com>
In reply to#29643
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_effort_estimation

--
Michal

[toc] | [prev] | [next] | [standalone]


#29645

Fromszykcech@gmail.com
Date2017-04-29 02:18 -0700
Message-ID<61be9919-c2d7-48dc-b751-25855438dc29@googlegroups.com>
In reply to#29643
> 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".

[toc] | [prev] | [next] | [standalone]


#29647

From"M.M." <mmarszik@gmail.com>
Date2017-04-29 11:48 -0700
Message-ID<525d0e53-de6a-49b7-bc6d-d133828d755e@googlegroups.com>
In reply to#29645
On Saturday, April 29, 2017 at 11:18:14 AM UTC+2, szyk...@gmail.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

[toc] | [prev] | [next] | [standalone]


#29648

Fromgof@somewhere.invalid (Adam Wysocki)
Date2017-04-30 19:49 +0000
Message-ID<2mTdf840dIee6Nv8%gof@news.chmurka.net>
In reply to#29643
Roman Tyczka <noemail@because.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/ ]

[toc] | [prev] | [next] | [standalone]


#29652

Frompwola <pwola@polbox.com>
Date2017-05-04 22:34 +0200
Message-ID<pv3ngc9073m7lmmtrb721ueh7lh5j18olh@4ax.com>
In reply to#29641
On Fri, 28 Apr 2017 10:08:01 -0700 (PDT), szykcech@gmail.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

[toc] | [prev] | [next] | [standalone]


#29653

Frombartekltg <bartekltg@gmail.com>
Date2017-05-05 06:36 +0200
Message-ID<oegvfs$ga6$1@node1.news.atman.pl>
In reply to#29652
On 04.05.2017 22:34, pwola wrote:
> On Fri, 28 Apr 2017 10:08:01 -0700 (PDT), szykcech@gmail.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

[toc] | [prev] | [next] | [standalone]


#29655

From"M.M." <mmarszik@gmail.com>
Date2017-05-05 12:57 -0700
Message-ID<22d234bf-0db6-41e2-a57b-0f219a6e1064@googlegroups.com>
In reply to#29652
On Thursday, May 4, 2017 at 10:35:03 PM UTC+2, pwola wrote:
> On Fri, 28 Apr 2017 10:08:01 -0700 (PDT), szykcech@gmail.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

[toc] | [prev] | [next] | [standalone]


#29646 — [OT] Szacowanie czasu realizacji zadań

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-04-29 11:48 +0200
Subject[OT] Szacowanie czasu realizacji zadań
Message-ID<oe1ni1$952$2@node2.news.atman.pl>
In reply to#29639
(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?

[toc] | [prev] | [next] | [standalone]


#29675 — Re: [OT] Szacowanie czasu realizacji zadań

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-05-10 18:05 +0200
SubjectRe: [OT] Szacowanie czasu realizacji zadań
Message-ID<oevdop$136$1@node1.news.atman.pl>
In reply to#29646
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...

[toc] | [prev] | [next] | [standalone]


#29677 — Re: [OT] Szacowanie czasu realizacji zadań

From"M.M." <mmarszik@gmail.com>
Date2017-05-11 09:18 -0700
SubjectRe: [OT] Szacowanie czasu realizacji zadań
Message-ID<45fdf341-671b-42a6-a56a-07ee6e98f417@googlegroups.com>
In reply to#29675
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.

[toc] | [prev] | [next] | [standalone]


#29678 — Re: [OT] Szacowanie czasu realizacji zadań

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-05-11 18:40 +0200
SubjectRe: [OT] Szacowanie czasu realizacji zadań
Message-ID<of245j$nf9$1@node1.news.atman.pl>
In reply to#29677
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...

[toc] | [prev] | [next] | [standalone]


#29654

FromWojciech Muła <wojtek.mula@gmail.com>
Date2017-05-05 12:18 -0700
Message-ID<d512b37c-2148-4bd5-8cc6-31a2445e5c53@googlegroups.com>
In reply to#29639
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.

[toc] | [prev] | [next] | [standalone]


#29656

From"M.M." <mmarszik@gmail.com>
Date2017-05-05 13:24 -0700
Message-ID<2dd60512-a9b7-438a-8368-6f9dff5950d8@googlegroups.com>
In reply to#29654
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

[toc] | [prev] | [next] | [standalone]


#29681

From"H.D." <hinidasini@gmail.com>
Date2017-05-12 06:28 -0700
Message-ID<7ae7009f-5c80-42f6-95cb-77bd487b9b9a@googlegroups.com>
In reply to#29656
Gadanie. Nakład pracy na projekt informatyczny jest nieprzewidywalny. Nie rozmawiamy o helołordach.

[toc] | [prev] | [next] | [standalone]


#29682

Fromniepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2017-05-12 17:24 +0200
Message-ID<of4k3l$qm$1@node2.news.atman.pl>
In reply to#29681
niestety rozmawiamy, i to za sporawe granciki... tylko ci co zasłużyli 
oczywiście...

[toc] | [prev] | [next] | [standalone]


#29683

Frommichal@kleczek.org
Date2017-05-13 22:34 -0700
Message-ID<4963a335-7d7b-4b6a-97f4-e753d1c2b1d6@googlegroups.com>
In reply to#29681
On Friday, May 12, 2017 at 3:28:34 PM UTC+2, H.D. wrote:
> Gadanie. Nakład pracy na projekt informatyczny jest nieprzewidywalny. Nie rozmawiamy o helołordach.

To tak jakby powiedzieć, że nakład pracy (czy ogólniej środków) na - dajmy na to - budowę
mostu przez Wisłę jest nieprzewidywalny. Czym się różni projekt informatyczny od budowy mostu?

--
Michal

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | pl.comp.programming


csiph-web