Idő alapú projekt költség kimutatás forráskódban eltöltött fejlesztési idő alapján
Sziasztok!
Régen jártam már nálatok, sok minden megváltozott az életünkben azóta... :)
Ismertek olyan rendszert, alkalmazást, ami a fejlesztés közben adatokat gyűjt a projektről azzal a céllal, hogy idő alapú költség kimutatást lehessen készíteni a projekt (akár legkisebb) egységeire?
Gondolok itt arra, hogy projekt befejeztével meg lehessen nézni, hogy egy controller-re vagy egy view-ra, vagy akár egy controller adott funkciójára összesen mennyi időt fordított a fejlesztő?
Nem volna utolsó szempont az sem, ha tudná a rendszer egységeit task-oknak kezelni. Például ha létrehozok egy új controller osztályt, akkor az egészen addig nyitott task, amíg azt befejezettnek nem jelölöm. Vagy funkció egy controlleren belül (vagy akár egy virew, model).
Remélem nem kérdeztem nagy baromságot.
Egy kicsit tudatosabban kellene foglalkoznunk a tervezéssel és a fejlesztésre szánt idők megbecsülése helyett inkább mérnék meglévő projektekben, amely adatok jelentősen megkönnyítenék az újabb projekt időigényének meghatározását.
Válaszaitokat előre is köszönöm!
■ Régen jártam már nálatok, sok minden megváltozott az életünkben azóta... :)
Ismertek olyan rendszert, alkalmazást, ami a fejlesztés közben adatokat gyűjt a projektről azzal a céllal, hogy idő alapú költség kimutatást lehessen készíteni a projekt (akár legkisebb) egységeire?
Gondolok itt arra, hogy projekt befejeztével meg lehessen nézni, hogy egy controller-re vagy egy view-ra, vagy akár egy controller adott funkciójára összesen mennyi időt fordított a fejlesztő?
Nem volna utolsó szempont az sem, ha tudná a rendszer egységeit task-oknak kezelni. Például ha létrehozok egy új controller osztályt, akkor az egészen addig nyitott task, amíg azt befejezettnek nem jelölöm. Vagy funkció egy controlleren belül (vagy akár egy virew, model).
Remélem nem kérdeztem nagy baromságot.
Egy kicsit tudatosabban kellene foglalkoznunk a tervezéssel és a fejlesztésre szánt idők megbecsülése helyett inkább mérnék meglévő projektekben, amely adatok jelentősen megkönnyítenék az újabb projekt időigényének meghatározását.
Válaszaitokat előre is köszönöm!
wakatime van sublime text es
Sublime
Az editor reszt loggolni
Editor log
Egy kérdés: hogy méred, hogy
Ismerve az emberi természetet: aki még kedvből csinálja, valószínűleg útközben, otthon is töri a fejét egy-egy problémán. Ezeket az időket hogy tudod beletenni egy ilyen rendszerbe? Számolhatsz-e vele egyáltalán? A probléma annyival hamarabb megoldódhat, de ki tudja, a következő esetben még tart-e a lelkesedés? Máris napokkal nőhet a szükséges idő.
Anno, rendszergazdaként szenvedő alanya voltam egy ilyennek.
Képzeld el azt a helyzetet, mikor párhuzamosan foglalkozik az ember több dologgal, mert egyik terminálon futtat egy hosszabb lélegzetű feladatot, másikon épp egy szkriptet ír, de közben beesik egy kolléga telefonon, hogy elfelejtette a jelszavát.
Mire mindezt leadminisztrálom, lemegy a nap.
Biztosan lehet másképp is, mint ahogy nálunk volt, de én ezt láttam, ezeken a területeken - üzemeltetés, fejlesztés - gyorsan leszoktak az időmérésről. :) Talán a helpdesknél maradt valami gépesített dolog, mert ott tényleges feladatmegoldással nem kellett szórakozni a kollégáknak, ha már letették a telefont.
Aki másképp látja, esetleg látott már erre pozitív példát, nyugodtan hülyézzen le, nem fogok megsértődni! ;)
Ez ilyen manager mania, de
A masik amit en hasznosnak talalok, hogy amikor megy egy pomodoro timer, es szigoruan csak akkor szakitom meg, ha muszaly, akkor sokkal jobban koncenralok es jobban haladok.
Nekem sem a legnagyobb erősségem az idő
Akkor nem biztos, hogy
Én épp ellenkezőleg vagyok ezekkel a dolgokkal: ha látom, hogy nem tudok határidőre végezni egy határidős feladattal, akkor nagyon gyorsan lelohad a maradék lelkesedésem is.
Plusz
Ugyan az a minta nem húzható rá minden projektre
A jelenleg használt eszközeink és tudásunk nem teszi lehetővé, hogy a fenti problémát tökéletesen kezeljük, hiszen ki vagyok segítve azzal, ha egy munkát határidőre teljesítünk, ha nem tudom, hogy közben valójában mennyi idő ment bele. Nem hajszál pontosan, grammra, de mégis a valóság a tervezéssel szemben.
Ez egy ördögi kör és úgy vélem, hogy a kiút ott kezdődik, hogy egyáltalán megmérem, hogy mennyi az annyi. Ezért foglalkoztat a gondolat, hogy valahogyan meg kellene mérni, mi is történik.
Rendszer és rendszer nagy mértékben különbözhet egymástól, ezért az egyikben megszerzett adatok nem feltétlenül lesznek igazak egy másikban, azt azonban biztosan tudom, hogy az előzőleg mért adatnál vagy több, vagy kevesebb időt fog igénybe venni azaz végre lesz egy (ha nem is objektív) stabil adatom. Az hiszem! :p
Értem én amit mondasz...
Nálunk a programozóknak nincs más feladtuk, csak az, hogy programozzanak. Őket nem zavarja meg senki, nem csörög a telefonjuk, nem viszik haza a munkát. Nyilván ettől még lehetnek egyszer kiegyensúlyozottak, másszor pedig családi gondokkal tele, ami nagy mértékben képes befolyásolni a teljesítményét.
Az alapvető elképzelés (és elvárás) az időmérésre kapcsolatban az, hogy a fejlesztő munkáját ne befolyásolja, azaz úgy kell működnie, hogy abból a fejlesztő nem vehet észre semmit.
Így a Sublime-os Python-os lehetőséget mérlegelve arra jutottunk, hogy a Sublime által biztosított eseményekre építhetnék egy naplózási eljárást, ami leegyszerűsítve megtudja, hogy hol van a kurzor, mennyi ideig van ott és miután már nincs ott, mi változott, ahol volt. Kezdetnek már ez is szolgáltathat információt.
Természetesen minden véleményt és kritikát elfogadok, különösen köszönöm azoknak, akik válaszoltak a felvetésemre! Köszönöm.
Ha belebeszélhetek a
Nem kell, hogy bármi tényleges negatív következménye legyen. Elég, hogy tudat alatt ott motoszkál az emberben, hogy folyamatos ellenőrzés alatt áll, rengeteget ront a hatékonyságon. És esetleg egy szép napon épp a legjobb embereitek közlik, hogy bocs, találtunk más munkát! :(
(olyat már éltem át, hogy egy csapat felállt és távozott, mert valami vezetői intézkedés nem tetszett, bár az kicsit durvább dolog volt. :( )
Egyetértek
Ez van most.
Nem is tévedünk az időkkel (nagyot). Talán helyesebb lenne azt mondani, hogy összességében mindig belefér a projekt a megbecsült időbe, de nem tudom, hogy mi volt az benne, ami belefért a becsült időbe, mi volt az ami hamarabb megvolt és mi volt az, ami felemésztett idő tartalékokat. Csak annyit látok, hogy egy egység elkészült-e időben vagy sem.
Ezek szerint kisebb egységekre kellene felbontani ahhoz, hogy ilyen típusú visszacsatolás érkezzen.
Első cégemnél projektalapon
Ha nálatok lennék valami főmumus, a magam részéről ennél több energiát biztos nem tennék a dologba, mert úgy gondolom, hogy olyan sokváltozós egy munka, az embereknek hol jobb, hol rosszabb napjuk van, ezért bármilyen erőfeszítés a pontosabb mérésre csak minimális eredménnyel fog járni.
Főmumus :)
A rövid határidők és rövid akció ciklusok valóban lehetővé teszik, hogy mérj és beavatkozz. Köszönöm.
Motiváltság
Természetesen tudniuk kell róla, hiszen részük van benne, ez így etikus. Fontos, hogy meglegyen a motiváltság is a képletben, különben megborulhat.
Hogy tudniuk kell róla, az
Inkább arra akartam kilyukadni, hogy a véleményüket kérd ki és lehetőleg ne azt figyeld amit mondanak, hanem ahogy... ;))
(húsz éve, ilyen helyzetben biztosan nem mertem volna tiltakozni, holott a lelkem nem is annyira mélyén, visszakívántam volna anyukájába az ötletgazdát. Most már nyugodtan megmondanám, mert számomra nincs tétje ;) )
Ha itt lenne Like..
Maximálisan egyet értek, köszönöm!
Ezt felvésem valahova, olyan
Ritkán mondasz
De ez tőlem is(!) +1.
Verziókezelő alapján?
Nekem az a véleményem, hogy a szőrszálhasogatás zsákutca. Mert hová számít pl. a WC-n töltött idő? Nyilván az alatt nem születik kód, de ha hosszú távon nincs megfinanszírozva a WC-re menés, akkor veszteséges lesz a projekt.
Érdemesebb talán viszonylag elnagyoltan, de jó heurisztikával mérni az időt. Erre szerintem pl. alkalmasak lehetnek a verziókezelő kommit időbélyegei. Egy munkanapló (munka kezdete/vége, ebéd szünet) és a megfelelő időben (munkafázisok határán, taszk váltáskor) használt commit segítségével szerintem a gyakorlatban elég jól használható időket lehet kapni.
Üdv:
Dávid
A fejlesztőnek is együtt kell működnie
Gondolok itt arra (kiindulva a Sublime kínálta lehetőségekből), hogy ha WC-re megy, vagy ebédelni, akkor tegye le tálcára az editort (már ha van neki olyan eseménye, ami ezt is tudja figyelni), hogy ne ketyegjen az idő.
Ahogy konkrét elképzelés nincs, úgy teljesen tökéletes megoldás sincsen.
Komplexitast becsultetni a
Kifejtenéd bővebben?
Nem tudom pontosan mit értesz az alatt, hogy komplexitást becsültetni a fejlesztőkkel, azonban én semmi mást nem akarok, csak azt, hogy fejlesszenek. Mert én a folyamataikból akarok adatokat kinyerni és nem azt akarom, hogy ők szolgáltassanak adatot. A fejlesztő szempontjából ezek láthatatlan folyamatok (természetesen tud róla), amelyek az önszándékától vagy akaratától függetlenül is végbemennek (ha nem szabotálja, de ezzel az erővel le is lőhet, meg ki is rughat... ja azt nem mert én vagyok a főnöke :p).
Nem fog menni
Adminisztratív terhek
A téma nyitásakor még nem volt teljesen tiszta a kép, hogy mit is akarok, csak a célom volt meg. Most már tisztábban látok és ahogyan a hozzászólásaimban is láthatod, semmiféle adminisztrációs feladatot nem akarok a fejlesztőimre testálni.
Abban viszont teljesen egyetértek, hogy a méréssel megszerzett adat más projektek viszonylatában nem törvényszerűen releváns, mégis adat egy olyan tevékenységről, amiről ezidáig csak elképzelésünk volt, konkrét adatunk nem.
Trello-t megnézem, köszönöm.
Hasonló probléma
Csak lesek
Én eddig kvázi kézzel "mértem" fejlesztési időt néha (egyedül programozva), sokat tanultam is belőle, de "rabszolgaként" meg rühellem (ez az, amikor a mumus is te vagy, meg akit terrorizál).
Költség szempontjából vigyázni kell: ha újrahasznosítható kódot írsz, azt ugye pont azért csinálod, mert az egy projekt költségeibe nem fér bele, de másik x-nél még használni fogod. Szerintem ezeket a megtérüléseket a legnehezebb megsaccolni.