Kezdőoldal » Számítástechnika » Programozás » Hogyan lehet programozásnál...

Hogyan lehet programozásnál az időbecslést jól csinálni?

Figyelt kérdés

Nem mondta senki, hogy az egyetemen a programozás szakhoz előfeltétel az ezoterika OKJ vagy a jóslástan, esetleg a boszorkányság művészete, és mindenféle okkult szektákhoz kell belépni :) Vagy esetleg időgépet kell építeni hozzá :)


Alapvetően ezt az - egyébként roppant nehéz - feladatot nekem az egyetemen nem tanították. Olyan módszereket már hallottam, hogy veszed azt az értéket, amit gondolsz, majd azt kezded el megszorozgatni meg elosztogatni. De mit csináljon az, aki azt sem tudja, milyen értéket gondoljon? Hiszen rendben, veszel egy értéket, ami az egyszeri megoldáshoz kell (ez is csak egy random szám). De azt még úgyis átvariálják, megtoldják, összeakad valamivel, vagy érdemes refaktorálni adott idő után jobbról, balról, mert különben bizonytalan a működése, akkor még esetleg frissítgeted vagy háromszor hozzá a unit testet, meg még a tesztelő is talál vele valamit.


A legnagyobb problémám az, hogy annyira különböző programozási feladatokat kellett eddig mindig megoldanom, hogy még csak összehasonlítási alapom sem volt soha. És minden egyes alkalommal összekapódik a gyomrom, ha valaki ilyesmit kér, mert ebben csak és kizárólag hibázni lehet.


Ha túl alacsony óraszámot mond az ember, az a baj. (mert utána ki kellene elméletben dolgoznia a belét, sőt, ha annyira alacsony, akkor még túlórázásokkal és hétvégi munkával sem fogja tudni teljesíteni)

Ha túl magasat, akkor meg az. (hallottam olyat, hogy ha valaki túl magasat mondott, megkérdeztek mást, aki alacsonyabbat mondott - az mindegy, hogy meg is oldja-e annyi idő alatt - és aki sokat mondott, attól elköszöntek)

Pontosat meg lehetetlen mondani. Biztos vagyok benne, hogy még veterán fejlesztők sem mondanának jó becsléseket, ha totál új feladattípusokkal néznek szembe, amikre nem csinált előtte semmilyen kódot.


De azt gondolom - bár ezt sosem próbáltam - hogy megtagadom az időbecslést, és helyette a When it's done elvet követem, és legfeljebb kamerázzanak be, hogy dolgozok rendesen addig is.

Meg gondolom azt sem érdemes mondogatni, hogy "én ennyit mondok, de ne alapozz rá, mert amúgy fogalmam sincs", mert onnantól a junior aljának gondolják a fejlesztőt.


Szóval mi itt a jó megoldás?



2022. szept. 3. 23:56
1 2 3
 1/25 anonim ***** válasza:
100%
Tapasztalat, ezen sajnos más nem segít. Meg persze azt is jó lenne tudni, hogy milyen területről van szó. Egyébként érdemes azoknak a részeknek belőni az idejét, amiről nagyjából tudni fogod, hogy oké ez így x nap, aztán a többire meg mondasz valamit amit úgy intuitív jónak látsz. Így kevesebbet tévedsz majd remélhetőleg, de azért néha ez is megtud szivatni.
2022. szept. 4. 01:04
Hasznos számodra ez a válasz?
 2/25 anonim ***** válasza:
Mindig fele kell mondani...
2022. szept. 4. 04:16
Hasznos számodra ez a válasz?
 3/25 anonim ***** válasza:

Ha eleget foglalkozol ilyesmivel, szerintem könnyen meg lehet becsülni. A zhidat is megírtad időre, a feladataidat is leadtad időre. Amire van a fejedben egy körülbelüli megoldási forgatókönyv, annak az idejét meg tudod becsülni, amire meg nincs, azt meg nem vállalod be, mert nem vagy hozzá elég még.


Már egy juniornak is van annyi tapasztalata, hogy fel tudja mérni, mi mennyi idő neki. Nem tökéletes kódot kell írni, hanem működőt, közben szem előtt tartva azt, amit csak lehet a clean code elvek közül. Ne mondd már, hogy te nem tudod megmondani, hogy mennyi idő alatt írnál meg valamit, amihez hasonlót készítettél már! Tudod, milyen komponensek lesznek, tudod, hogy azokba kb mi kell, nem? Nem olyan nehéz elemeire szedni egy rendszert és visszavezetni egységnyi feladatokra. Ajánlatot is így teszünk.


Minden kódot javítani kell úgyis, egy alkalmazás sem lesz soha teljesen kész, még a megrendelő is variálhat, van egy szerencsefaktor a történetben, pont ezért használják az agile-t a szoftverfejleszzésben. Az a lényeg, hogy valami működjön a határidőre. Ha hamarabb működik, lehet refaktorálni, toldozgatni, átszervezni, kiszervezni, teszteket írni rá. Nem a kódminőséget nézi a megrendelő sem, hanem a terméket. Nem lát bele a kódba jobb esetben, gondolom ez evidens. És az is, hogy nem elbúcsúzol a kódtól, mikor kiadod, hanem van utánkövetés, karbantartás, adsz rá ki bugfixeket, frissítéseket, magyarul bőven meg tudod csinálni hozzá az elmaradt feladatokat is.


Amit pedig emberi időn belül nem tudunk befejezni, azért nem kérünk pénzt. Gondolom evidens, hogy miért nem zöldfülű juniorok vállalkoznak ebben a szakmában és miért seniorok. Azért, mert egy junior attól junior, hogy még sok problémát nem tud megoldani vagy nem tudja felvázooni magának fejben, hogyan kell megoldani és épp ezért nem is tud jó becslést adni.


Bizonytalan tudásra nem kérünk pénzt, mert abból bizony kötbér lesz.

2022. szept. 4. 04:21
Hasznos számodra ez a válasz?
 4/25 krwkco ***** válasza:

"Ha túl alacsony óraszámot mond az ember..." "Ha túl magasat, akkor meg az..."

Én másik oldalról fognám meg a kérdést. Annyit kell mondani, amennyit mindenki más mond.

Ezzel viszont az a helyzet, hogy a programozás időigénye között lehet egy személytől függő 3-10-es faktor. Ha valaki jó eszközöket használ, jó kódot ír, ami kevés javítást igényel, akkor simán (sok video nézéssel, maszekolással) tudja tartani az átlag időigényét és a megrendelő elégedett lesz.

De aki átlag alatti hatékonyságú (nem szégyen, van ilyen), az bajban lesz már a becslésnél. Mert az elvárásoknak megfelelő időt kell mondania, ami csak éjt nappallá téve teljesíthető.

Ez van. Amellett, amit 1 és 3 is mondott.

2022. szept. 4. 06:04
Hasznos számodra ez a válasz?
 5/25 anonim ***** válasza:
100%
A rutin meg az évek, azt látom a kollégákon. A másik oldalon ülök, én kérem a becsléseket, szóval azt tudom egy kicsit megvilágítani. Amikor egy projekten dolgozunk, tudnunk kell, mikorra lesz kész és mennyibe fog kerülni, mindkettőhöz a becslés fog közelebb vinni. Szóval enélkül nem megy. Ez a projekt 3 alappilléréből kettő, a harmadik a scope, tehát a mit kell megcsinálni. A srácok úgy szokták, hogy külön becsülnek időt a tesztelésre, tesztdoksi készítésre stb, és szintén külön becslik meg az egyes területeket pl backend/ frontend. Emellett azt is látom, hogy a becslésnél annyira körüljárják a témát, hogy a fejükben már nagyjából megvan, hogy mit fognak csinálni. Ehhez pedig a jól megfogalmazott requirment fontos. Ha nem elég az info, nyugodtan vissza lehet kérdezni.
2022. szept. 4. 09:21
Hasznos számodra ez a válasz?
 6/25 Fsms ***** válasza:
#5 jogos, a rutin a kulcsszó.
2022. szept. 4. 10:50
Hasznos számodra ez a válasz?
 7/25 A kérdező kommentje:

3-as:

"amire meg nincs, azt meg nem vállalod be, mert nem vagy hozzá elég még"


Hát ha ez ilyen egyszerű lenne... Ha nem vállalom be, akkor nem leszek soha elég hozzá, hiszen a feladat megkapásával fogom azt a feladatot gyakorolni, átlátni, megismerni a megoldási módszerét. Elég sok munkát nem kaptam volna meg, ha eleve nem vállaltam volna be rizikós feladatokat már a munka elkezdésekor, és ezzel saját magam alatt vágtam volna a fát, mert nem lesz meg az értékes tapasztalat a fejlődéshez.


Vagy a válaszadó arra gondol, hogy majd hétvégente hobbiból kell arra a feladatra komplex rendszereket megcsinálni szabadidőben és olyankor gyakorolni magamnak az időbecslést, munkahelyen kívül?


"Már egy juniornak is van annyi tapasztalata, hogy fel tudja mérni, mi mennyi idő neki."


Hát de ha tényleg totál újfajta feladatokat csinál az ember, hogyan mérje fel? Ha az egyik feladatom szinte rakétaprogramozás, a másiknál meg orvosi programozás? (nyilván átvitt értelemben) Néha még a használt eszközök is különböznek.


Most ezzel azt akarod mondani, hogy még junior sem vagyok, ha nem tudok időt becsülni?


"Ne mondd már, hogy te nem tudod megmondani, hogy mennyi idő alatt írnál meg valamit, amihez hasonlót készítettél már!"


Hát igen, ha hasonlót készítettem volna. De pont ezt mondom, hogy akkora eltérés van a feladattípusok között, mintha az egyikben sütnöm kéne a másikban meg főznöm. A hozzávalók többnyire ugyanazok, de az elkészítési mód mindig teljesen más.


"Amit pedig emberi időn belül nem tudunk befejezni, azért nem kérünk pénzt. " "Bizonytalan tudásra nem kérünk pénzt"


Akkor én az elmúlt években ingyen dolgoztam volna :) Már bocsánat, de nem is értem ezt.

2022. szept. 4. 10:53
 8/25 A kérdező kommentje:

5-ös: nem lenne logikusabb azt mondani, hogy ennyi a keret, ez ennyi időre elég, feleannyi idő alatt csináld, ameddig jutsz vele és ha nincs meg annyi idő alatt, akkor utána feleakkora fizetéssel folytatni, amíg kész nem lesz? Esetleg utána is adott idő után felezni a fizetést?


Akkor megmaradna a pénze annak, aki fizet, és a fejlesztő is motivált lenne végig, hiszen az ő érdeke, hogy ne kapjon kevesebbet a meghatározott idő alatt.


Meg nem tudom, biztos lehetne még ezer olyan módszert kitalálni, ahol nem kell jósolgatni senkinek.

2022. szept. 4. 10:58
 9/25 krwkco ***** válasza:

"ha nincs meg annyi idő alatt"

Logikus, de a következő hang az ajtó csapódása lenne a megrendelő mögött. :-)

2022. szept. 4. 11:09
Hasznos számodra ez a válasz?
 10/25 anonim ***** válasza:
8: nem, ez nem lenne jó megoldás. Gobdold át a projektvezető meg a megrendelő szemével még egyszer, és rájössz, miért.
2022. szept. 4. 12:55
Hasznos számodra ez a válasz?
1 2 3

Kapcsolódó kérdések:




Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!