Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #29639 > unrolled thread
| Started by | Roman Tyczka <noemail@because.no> |
|---|---|
| First post | 2017-04-28 13:04 +0200 |
| Last post | 2017-05-17 21:22 +0200 |
| Articles | 20 on this page of 38 — 13 participants |
Back to article view | Back to pl.comp.programming
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 →
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2017-04-28 13:04 +0200 |
| Subject | Szacowanie 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]
| From | szykcech@gmail.com |
|---|---|
| Date | 2017-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]
| From | Mateusz Bogusz <mabakay@o2.pl> |
|---|---|
| Date | 2017-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]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2017-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]
| From | michal@kleczek.org |
|---|---|
| Date | 2017-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]
| From | szykcech@gmail.com |
|---|---|
| Date | 2017-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]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-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]
| From | gof@somewhere.invalid (Adam Wysocki) |
|---|---|
| Date | 2017-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]
| From | pwola <pwola@polbox.com> |
|---|---|
| Date | 2017-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]
| From | bartekltg <bartekltg@gmail.com> |
|---|---|
| Date | 2017-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]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-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]
| From | niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2017-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]
| From | niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2017-05-10 18:05 +0200 |
| Subject | Re: [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]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-05-11 09:18 -0700 |
| Subject | Re: [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]
| From | niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2017-05-11 18:40 +0200 |
| Subject | Re: [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]
| From | Wojciech Muła <wojtek.mula@gmail.com> |
|---|---|
| Date | 2017-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]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-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]
| From | "H.D." <hinidasini@gmail.com> |
|---|---|
| Date | 2017-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]
| From | niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2017-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]
| From | michal@kleczek.org |
|---|---|
| Date | 2017-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