Hvorfor timeføring ikke kan automatiseres
De fleste utviklere jeg kjenner har på et eller annet tidspunkt laget sitt eget timeføringssystem fordi de var misfornøyd med det de er pålagt å bruke. Målet er ofte å automatisere det som ser ut til å være en meningsløs aktivitet, denne posten handler om hvorfor timeføring faktisk er en meningsfylt aktivitet.
Det ser ut som et brudd på DRY (Don’t Repeat Yourself) å skulle fortelle hva man har gjort flere ganger. For eksempel oppsummerer jeg endringer jeg har gjort i koden gjennom versjonskontrollsystemet. En ide kunne dermed være å bruke dette til å lage en (automatisk) rapport over dagens aktiviteter:
git log --since="8 hours ago"vil lage en helt kosher liste over features jeg har laget idag, hvorfor skulle ikke dette være nok for å rapportere hva dagen handlet om?
Den enkleste delen av timeføringen er hvor mange timer man har jobbet. Formelen er omtrent slik:
klokkeslettet når jeg går hjem - klokkeslettet jeg kom - dødtid/surfing/whatever = fakturerbar tid
Den andre delen er å fortelle hva man har gjort. På samme måte som testene vi skriver beskriver hva programmet gjør på en bedre måten enn implementasjonen (fordi den har et annet utgangspunkt og muligens, hvis testene er veldig bra, et annet publikum) er timeføringen en oppsummering av hva dagen har handlet om.
Har du hørt den gamle historien om mannen som kom til en byggeplass i oldtidas Egypt? Han så masse mennesker som dro på digre steiner, noen sto og dirigerte, og andre satt i skyggen fra et palmetre. Mannen går bort til den første slaven han ser, og spør “Hva gjør du?”
Er du dum? Ser du ikke at jeg drar på denne digre steinen?
Mannen var ikke helt fornøyd, og nærmet seg en annen slave med samme spørsmål.
Jeg har fått beskjed om å flytte denne steinblokken fra den plassen der borte opp på haugen der.
Fortsatt ikke helt fornøyd gikk han bort til en tredje mann.
Jeg bygger en pyramide, svarte mannen på samme spørsmål.
Så forskjellig kan man altså beskrive nøyaktig samme aktivitet, og likevel kommunisere helt forskjellige hensikter.
Tenk deg at når du skal beskrive hva du har brukt timene dine på (som noen antakelig betaler dyrt fort), at du skal oppsummere hvilken verdi du har levert idag.
Istedet for en liste av typen:
- Added new checkbox in signup form
- Refactored authentication logic
kan samme aktiviteter oppsummeres som:
Made it possible for users to log in with the same username/password that they use in the legacy system.
Den siste formuleringen forteller ikke bare hva du har gjort, men hvilken betydning dette har. For kunden som skal bla opp for timene dine vil dette helt sikkert oppleves som mer verdifullt enn en liste med kodeendringer. Samtidig er min opplevelse at denne prosessen gjør meg mer bevisst på
- betydningen av det jeg har gjort
- retningen prosjektet tar
- verdien jeg leverer
Også på dager da jeg har knotet og ikke klart å levere så mye kode kan det tenkes at jeg har gjort noe verdifullt, denne prosessen gjør meg bevisst på dette. Og skulle det komme en dag da du har levert hundrevis av kodelinjer og likevel ikke klarer å formulere hvilken verdi dette gir, kan det tenkes at du ikke har fokusert på de riktige tingene.
Prøv det, jeg tror du vil like det!
Veldig godt poeng. Versjonskontrollsystemet har definitivt et annet publikum enn timelistene dine. Når det er sagt så syns jeg at “hvorfor”-delen av beskrivelsen vel så ofte også hører hjemme i versjonskontroll sammen med koden. Utviklerne som kommer etter deg er sannsynligvis minst like interessert i hvorfor du gjorde noe som de som betaler regninga :)
Timeføring har som du sier verdi som en bevisstgjøringsprosess, og nettopp derfor er det viktig at man holder seg til verktøy som ikke overkompliserer og gjør timeføring til noe man skyr unna. Personlig har jeg hatt best erfaring med en fysisk notatbok og en .txt-fil. Med jevne mellomrom fører jeg over i et annet system. Dette lar meg også slå sammen like oppføringer og gjøre den så oversiktlig som mulig for de som skal se over.
av Christian, 03/07-2009
Selv går det i en .txt før det føres inn i en Whiteboard i Basecamp. Som regel en stund etter jeg faktisk har jobbet så det blir ofte ganske så diffust (“Prosjekt 1 (signup)”).
Denne posten fikk meg til å tenke på en ting jeg savner i Git: En mulighet for å “pakke sammen” flere commits i en enkelt en. Slik at master-branchen kan ha en historie som:
Men bak hver av commitene ligger det flere commits. Om ønskelig kan man gå inn og se hva de commitene inneholder. Dermed kan commite så mye man vil mens man jobber med koden, uten å bekymre seg for å rote til historien. I tillegg blir master veldig mye ryddigere og man kan enkelt se hva man har oppnådd den siste tiden og hva som har tatt tid.
av Magnus Holm, 03/07-2009
Lurt! Jeg har samme prosess som Christian: kladde timene ett sted, føre dem inn et annet. Git-loggen er en del av kladden, men jeg kladder også manuelt.
av August Lilleaas, 03/07-2009
Supert innspill. Selv om innlegget er gammelt inspirerte det meg.
av Geir Wilter, 07/05-2010