[OSy] Zadani o prodlouzeni deadline

martinec martinec at d3s.mff.cuni.cz
Sun Dec 11 20:33:14 CET 2011


Hezky vecer,

> zadam o prodlouzeni deadline (pokud mozno do stredy rano - v pondeli mam
> docela plny rozvrh).

odpoved je ponekud soukroma, takze ji poslu jen Vasemu tymu.

>     Pozorujeme, ze nekteri ucastnici si naplanovali, ze provedou vetsinu
>     vyvoje behem "prodlouzeneho" tydnu (a pred tim si vyresi jine
>     povinnosti). Bohuzel takoveto naplanovani neni stastne a my jsme s
>     tim prilis nepocitali. Totiz efekt snizeni casoveho presu pri vyvoji
>     a zaznamenavani chyb mizi, kdyz se ma vetsina prace udelat behem
>     nekolika dni. Take se da ocekavat, ze pri programovani pod tlakem
>     bude jine rozlozeni chyb nez pri programovani za "klidnych" okolnosti.
>
> samotna ucast ve studii docela ovlivnuje psani kodu (i jinak nez ze
> zabira cas). asi nejlepe to vystihuje 'prepnuti kontextu', clovek
> 'ztraci nit' a chvili trva nez se dostane zpet, takze doba na ladeni mi
> prijde vyssi.

Cetl jsem nejake zapisky, ktere vliv "prepinani kontextu" popisovaly. V 
peopleware se treba popisuje, ze programator ma v klidnem prostredi 
nasobne vyssi produktivitu nez v prostredi, ve kterem probihaji 
"prepnuti kontextu". Doporucuje se treba pri programovani vypnout 
instant messaging komunikaci; mail sledovat metodou pollovani a ne 
metodou interruptu, apod...

Asi je to proste inherentni vlastnost metod teto studie - popremyslim 
nad tim. Ten cas straveny na ukor "prepnuti kontextu" je neprijemny, ale 
momentalne me nenapada, jak to odstinit. Kdyz uz bychom tento vliv 
chteli zohlednit ve vysledcich, tak to uz by chtelo rovnou, aby nekdo 
sedel vedle vas s papirem a poznamenaval si veci jako treba, ze vam 
zazvolnil telefon. A to neni dobre realizovatelne a mozna ani eticky 
pripustne.

> zvlast otravny je pripad, kdy pri hledani bugu najdu jiny bug - musim
> zajistit ze budu schopny vyplnit oba reporty, takze si nekam zapisuji
> jestli to bylo assertem/zacyklenim nebo selhanim testu, atd... + kratce
> popis abych to pri vyplneni reportu byl schopny rekonstruovat. (mit
> otevrena dve okna pro pridani reportu a prubezne do nich zaznamenavat
> rozumne nejde - pri zmene casu se vynuluje formular (pokud to neni uz
> upraveno) a jen podle poradi karty prohlizece vedet ktera karta je ktery
> bug take moc dobre nejde)
>
> pro pristi roky by mohlo byt vhodne udelat studii vic jako
> bugzilla/trac, vytvori se bug (zaznamena se cas, vybere se zpusob
> detekce), pak tlacitko ktere prepina ladim tento bug / neladim tento bug
> (pocitani casu), a postupne pridavani nastroju/metod (kdyz nastroj zacnu
> pouzivat), prubezne volba jak moc nastroj pomohl. a nakonec pricina
> chyby. mozna by to slo udelat primo jako plugin pro trac (a verim ze
> hostovany tymovy trac pro OSy by vetsina uvitala)

Diky za podnety; zni to rozume a pro pristi rok to vezmu v potaz. Snad 
uz tento semestr upravim to rozhrani, aby se dal zaznam vyplnovat prubezne.

S pozdravem,
Tomas Martinec




More information about the NSWI004 mailing list