Joel on Software

Joel on Software   Joel om Software

 

Andre "Joel on Software" artikler på dansk

Andre "Joel on Software" artikler på engelsk

Send en mail til forfatteren (kun på engelsk)

 

Smertefrie Tidsplaner


Af Joel Spolsky
Oversat af Emil Rasmussen
Bearbejdet af Stephan Dahl
29. Marts 2000

Sidste oktober var hele det nordøstlige USA oversået med reklamer for noget der hed Acela, en ny højhastighedstogbane mellem Boston og Washington. Der var TV reklamer, billboards og plakater over det hele, man skulle mene at sådan en indsats skulle kunne skabe et udmærket marked for Amtrak's nye højhastighedsforbindelse.

Hmm, måske. Amtrak fik aldrig muligheden for at finde ud af det. Acela blev forsinket og endnu mere forsinket, så reklamekampagnen ebbede lige så stille ud, mens Acela forbindelsen endnu ikke var klar til brug. Hvilket minder mig om, hvad jeg hørte en salgschef sige, da hans produkt fik en flot anmeldelse en måned før det kom på markedet: "Rigtig god reklame! Bare en skam man ikke kan købe det endnu!"

Testosteron fikserede spil firmaer elsker at brede ud over deres web sites, at deres næste udgivelse vil udkomme "når den er klar". Tidsplan? Vi har overhovedet ikke brug for en tidsplan! Vi er overseje spil-programmører! De fleste firmaer nyder ikke samme luksus. Spørg bare Lotus. Da de første gang udgav 123 version 3.0, krævede det en 80286 computer, det var bestemt ikke almindeligt dengang. De forsinkede udgivelsen med 16 måneder, i den tid arbejdede de med at mase programmet ned i 640k memory begrænsningen for 8086 computeren. Da de endelige var færdige, havde Microsoft fået et 16 måneders forspring i udviklingen af Excel. Og for at gøre det hele endnu mere tragi-komisk, så var 8086'eren alligevel blevet forældet!

Mens jeg skriver dette, så er Netscape's version 5.0 browser næsten to år forsinket. Tildels fordi de begik den selvmordsagtige fejl at smide alt deres kode væk og starte forfra: den samme fejl som sendte Ashton-Tate, Lotus og Apples MacOS i software historiens papirkurv. Netscape's markedsandel er faldet fra ca. 80 % til ca. 20 %, i mellemtiden har de ikke kunne gøre noget som helst for at styrke deres konkurrenceevne, fordi deres hovedprodukt har ligget skilt ad i 1000 stykker på gulvet og har været totalt ubrugeligt. Denne ene dårlige beslutning har mere end noget andet været den atombombe som Netscape kastede i hovedet på sig selv. (Du kan læse alle detaljerne i Jamie Zawinski's verdensberømte tantrum).

Du bliver altså nødt til at lave en tidsplan. Det er noget som næsten ingen programmører vil lave. Ifølge min erfaring, vil flertallet slet ikke lave nogen tidsplan, og prøve at slippe afsted med det. De få der faktisk laver en tidsplan, gør det kun fordi deres chef siger de skal, og så gør de et halvhjertet forsøg, der alligevel ikke er nogen der tror på. Det lige med undtagelse af den øverste ledelse, som samtidig tror på at "intet software projekt nogensinde er til tiden" og at der findes UFO'er.

Hvorfor er der ikke nogle der laver en tidsplan? For det første, det er død besværligt. For det andet, der er alligevel ikke nogen der tror på at den holder. Hvorfor bruge så meget energi på at lave en tidsplan, hvis den alligevel ikke holder? Den ofte herskende opfattelse er, at tidsplaner aldrig holder, og det kun bliver værre med tiden, så hvorfor lide for ingenting?

Her er der en simpel og smertefri måde at lave en tidsplan der faktisk holder.

1) Brug Microsoft Excel. Lad være med at bruge et eller andet smart program som Microsoft Project. Problemet med Microsoft Project er, at det tager for givet, at man vil bruge en masse tid på at bekymre sig om afhængigheder mellem opgaverne. En afhængighed er, når du har to opgaver, og den ene skal færdiggøres før du kan begynde på den anden. Når det drejer sig om software, så synes jeg at afhængighederne er så åbenlyse, at det ikke er besværet værd at bruge et program for at holde styr på dem.

Et andet problem med Project er, at det regner med, at du man vil kunne trykke på en lille knap og "genberegne" tidsplanen. Uundgåeligt betyder det, at det vil blive flyttet rundt på tingene, og sætte forskellige folk til nye opgaver. Sådan fungere det bare ikke med et software projekt. Det er ikke muligt at bytte om på programmører. Det tager syv gange længere tid for John at rette Rita's bug, end det tager Rita at rette Rita's bug. Og hvis man prøver at sætte UI programmøren til at arbejde med et WinSock problem, går hun i stå, og vil spilde en uge med at genopfriske hendes WinSock programmering. Når alt kommer til alt, så er Project lavet til at bygge kontor bygninger og ikke software.

2) Hold det enkelt. Det standard format jeg bruger til tidsplaner er så enkelt, at man kan huske det uden ad. Man starter bare med syv koloner:

Sample Spreadsheet

Hvis man har flere udviklere, så kan man have en ark til hver udvikler, eller en kolonne med navnet på den udvikler der arbejder med opgaven.

3) Hver funktion skal være inddelt i flere opgaver. En funktion kunne for eksempel være at tilføje en stavekontrol til programmet. Det at tilføje en stavekontrol indeholder en hel del små opgaver som programmøren skal udføre. Når man skal lave en tidsplan, så er det vigtigste at lave en liste over de involverede opgaver. Derfor er den vigtigste regel:

4) Det er kun den programmør, der skal skrive koden, som kan lægge tidsplanen. Hvis det er ledelsen der laver tidsplanen og programmørerne har bare værsgo at følge den, så er projektet dømt til at gå galt. Det er kun den programmør der rent faktisk skal lave arbejdet, som ved hvilke skridt han skal igennem for at implementere en bestemt funktion. Og det er kun den programmør der kan forudsige hvor lang tid, hver opgave vil tage.

5) Arbejd med små veldefinerede opgaver. Det er det mest vigtige, hvis din tidsplan skal holde. Længden på en opgave skal måles i timer, ikke dage. (Hver gang jeg ser en tidsplan der er målt i dage, eller endda uger, så ved jeg at den ikke passer.) Nu vil du måske tro, at man får et mere præcis tidsplan, hvis man bruger små opgaver. Forkert! Meget forkert! Når du starter med en tidsplan med groftskitserede opgaver, og så inddeler den i mindre opgaver, så vil du komme frem til et helt andet resultat, ikke bare et mere præcist resultat. Det bliver faktisk et helt andet tal. Og hvorfor mon det?

Når du skal arbejde med små veldefinerede opgaver, så tvinger du faktisk dig selv til gennemtænkte hvilke skridt du skal igennem. Skrive subrutine foo. Oprette dialogboks det og det. Læse wawa filen. Disse skridt er lette at forudsige arbejdstiden på, fordi du har skrevet subrutiner, oprettet dialogbokse og læst wawa filer før.

Hvis du sjusker og arbejder med store klumper af opgaver ("implementere grammatik kontrol"), så har du ikke rigtigt gennemtænkt hvad du skal lave. Og når du ikke har gennemtænkt hvad du skal lave, så kan du ikke vide hvor lang tid, det kommer til at tage.

Som en tommelfingerregel, så bør en opgave tage fra 2 til 16 timer. Hvis du har en 40 timers (en uge) opgave i din tidsplan, så er opgaverne ikke inddelt nok.

En anden grund til at arbejde med små opgaver er: det tvinger dig at designe den pokkers funktion. Hvis du har en luftig funktion som "Internet integration" og du sætter 3 uger af til det, så ender det galt min ven. Hvis du skal gennemtænke hvilke subrutiner du skal skrive, så bliver du tvunget til at få fastlagt hvordan funktionen skal fungere først. Ved at være tvunget til at planlægge på det niveau, så fjerner du meget af usikkerheden i et software projekt.

6) Registrér både den originale og nuværende forventende tid. Første gang du tilføjer en opgave til tidsplanen, skal du tage det forventede tidsforbrug i timer, og skrive det både i den originale forventede (Orig Est) og i den nuværende forventede (Curr Est) kolonne. Nu kan du under hele projektets forløb holde den nuværende forventede kolonne opdateret så meget som du har brug for. Det er en god måde at lære af sine fejl, og der ved blive bedre til at lægge tidsplaner. De fleste programmører vil have store problemer med at bedømme hvor lang tid de forskellige ting vil tage at lave. Det er helt ok. Så længe du bliver ved at lære og holder tidsplanen opdateret samtidigt med at du lærer. (Det kan godt være at du bliver nødt til at opgive nogle funktioner, men tidsplanen fungerer stadigvæk som den skal. Forstået på den måde, at du hele tiden kan holde dig orienteret om hvornår du bliver nødt til at skære en funktion fra.) Det tager ca. et års tid for de fleste programørere at blive rigtig gode til at lave tidsplaner.

Når en opgave er færdig, så vil den nuværende (Curr Est) og brugte (Elapsed) tid være den samme, og tilbage (Remain) bliver 0.

7) Opdatér den brugte tid hver dag. Det er ikke nødvendigt at side med et stopur mens du koder. Lige før du går hjem, eller lægge dig til at sove under skrivebordet, hvis du er en af den slags arbejdsnarkomaner, så forestil dig, at du har arbejdet i 8 timer (ha!), tænk lige igennem hvilke opgaver du har arbejdet med, og fordel de 8 timer ud på den brugte tids kolonne. Den tilbageværende tid vil Excel helt automatisk regne ud for dig.

På samme tid, skal du opdatere den nuværende forventede kolonne, for de samme opgaver, så de reflektere den nye virkelighed. Det behøver ikke at tage mere end 2 minutter at opdatere tidsplanen. Det er derfor dette er den smertefri måde at lave tidsplan på -- det er let og hurtigt.

8) Sæt tid af til ferier, helligdage osv. Hvis din tidsplan strækker sig over f. eks. et år, så vil hver programmør sikkert tage 10 til 15 feriedage. I din tidsplan skal du lave en "funktion" der dækker ferier, helligdage og alt det der ellers bruge folks tid. Ideen er nemlig at udgivelsesdatoen kan udregnes ved at lægge tiden i tilbage kolonnen sammen og dividere med 40 -- det giver dig hvor mange ugers arbejde der er tilbage, alt inkluderet.

9) Sæt tid af til at debugge! Debugging er det sværeste give et bud på. Tænk tilbage på det sidste projekt du arbejdede med. Der er gode chancer for, at debugging processen tog fra 100% til 200% af den tid som det tog at skrive koden første gang. Det er nødvendigt at lægge debugging ind i tidsplanen, og det bliver sikkert den største post i tidsregenskabet.

Sådan her fungerer det. Lad os sige at en udvikler arbejder på wawa. Det originale tidsplan var på 16 timer, men indtil nu har det taget 20 timer, og det ser ud til at det kræver endnu 10 timers arbejde. Så udvikleren sætte 30 timer ind under nuværende forventede tid og 20 under brugt tid.

Ved slutningen af en milestone, så vil alle disse "overskridelser" have samlet sig sammen til en hel del timer. I følge teorien, så bliver vi nødt til at fjerne nogle funktioner, så produktet kan blive færdigt til tiden. Heldigvis hedder den første funktion, som vi kan smide væk, Buffer, og den har masse af timer vi kan skære væk af.

I princippet, så debugger programmørerne samtidigt med de laver koden første gang. En programmør skal aldrig nogensinde arbejde med et nyt stykke kode, hvis han kan bruge tiden på at rette bugs. Antallet af bugs skal altid være så lavt som muligt. Og det er der to årsager til:

1) Det er lettere at rette bugs den samme dag, som da man skrev koden. Det kan være en meget svær og langsommelig proces at rette fejl en måned senere, når man har glemt hvordan det egentligt virkede.

2) Retning af bugs er lige som forskning. Det er umuligt at forudser, hvornår man vil gøre opdagelsen og kan rette fejlen. Hvis man altid sørge for at holde antallet af bugs på 2 eller 3, så vil det være lettere at forudse hvornår produktet er færdigt, fordi der ikke er særligt meget uforudsigelig forskning i din fremtid. På den anden side, så vil det være umuligt at forudsige, hvornår produktet er færdigt, hvis der konstant er flere hundrede bugs der skal rettes.

Hvis udviklerne alligevel rette bugs som de kommer frem, hvad er så meningen med at have linie til debugging? Altså, selv om man sørge for, løbende at rette de bugs man finder, så vil der uundgåeligt ved slutningen af en milestone skulle rettes mange bugs, når testerne (interne og beta) finde nogle af de rigtig svære bugs.

10) Afsæt tid til integration. Hvis man har mere end en programmør, så er det uundgåeligt der vil være ting, som to programmører laver forskelligt, derfor skal der bruges tid på at rette de uoverensstemmelser. For eksempel har de begge implementeret dialog bokse, til lignende opgaver, som er unødvendige forskellige. Det er nødvendigt at der er en, der går alle menuer, tastatur genveje, værktøjslinier og så videre igennem, så der bliver ryddet op i nye menu punkter, som bare er blevet smidt ind. Der vil være compiler fejl, som dukker op når folk checker deres kode ind. Det skal altsammen rettes, og der skal være afsat tid til det i tidsplanen.

11) Lav en buffer i tidsplanen. Ting har en tendens til at tage længere tid end man regner med. De to vigtigste buffere man skal tænke på er; en buffer der dækker for opgaver der tog længere tid end forventet, og en buffer for opgaver man ikke viste skulle laves, sædvanligvis fordi ledelsen har besluttet at det er HELT VILDT vigtigt at implementere wawa funktionen i præcis i denne version.

Du bliver måske overrasket over, at ferie, helligdage, debugging, integration og buffer tilsammen tager mere tid end den faktiske opgave. Hvis dette overrasker dig, så har du vist ikke programmeret særlig længe? Ignorer dette på eget ansvar.

12) Lad aldrig ledelsen bede en programmør forkorte en tidsplan. Mange uerfarne ledere tror de kan "motivere" deres programmører, til at arbejde hurtigere, ved at give dem en pæn stram (læs: urealistisk kort) tidsplan. Efter min mening er den slags motivation hjerne-død. Når jeg er bagefter tidsplanen, så føler jeg mig fortabt og deprimeret og umotiveret. Når jeg derimod er foran tidsplanen, så er jeg fornøjet og arbejdsom. Tidsplanen er ikke rette sted at lege psykologiske spil.

Hvis din chef tvinger dig til at skære i en tidsplan, så gør sådan her. Lav en ny kolonne i tidsplan, kald den Rick's forventning (selvfølgelig kun hvis du hedder Rick). Skriv din forventning i kolonnen. Lad nu bare din chef gøre som det passe hende med den nuværende forventede kolonne. Ignorer din chefs forventninger. Når projektet så er færdigt, så kan man se hvem der kom tættest på virkeligheden. I følge min erfaring, så giver det en fortryllende virkning, hvis man bare truer med det. Især når det går op for din chef, at hun lige har indgået et væddemål om, hvor langsomt du kan arbejde!

Hvorfor prøver uduelige ledere at få programmørerne til at forkorte tidsplanen?

Når projektet går i gang, så mødes den tekniske ledelse med forretningsfolkene, og frem kommer en liste af funktioner, som de tror med vil tage 3 måneder, men rent faktisk tager det 9. Når du vurderer hvor lang tid det vil tage at skrive noget kode, uden at gennemtænke hvilke skridt du skal igennem, så ser det altid ud til at det vil tage n tid, men i virkeligheden, så tager det måske 3n tid. Når du så laver en rigtig tidsplan, og du lægge alle opgaverne sammen, så opdager du at det kommer til at tage meget længere tid end du oprindeligt troede. Den virkelige verden trænger ind.

Uduelige ledere prøver på at afhjælpe det, ved at finde på metoder til at få folk til at arbejde hurtigere. Det er ikke særligt realistisk. Du er måske i stand til at ansætte flere, men de skal lige ind i arbejdsgangen, og vil sikkert arbejde på 50 % effektivitet i flere måneder (og gøre dem der skal oplærer dem mindre effektive). Men altså, i dette marked, tager det 6 måneder at tilføre en god programmør.

Måske kan du midlertidigt få 10% mere rå kode ud at folk, ved at lade dem brænde 100% ud på et år. Det er ikke meget at vinde, og det er lidt at save den gren man sidder på over.

Måske kan du få 20% mere rå kode ud af folk, ved at tigge dem om at arbejde virkeligt hårdt, lige meget hvor trætte de bliver. Boom, debugging tiden fordobles. Et idiotisk fejltrin, der giver bagslag så det batter.

Men du kan aldrig få 3n til at blive n, aldrig nogensinde, og hvis du tror du kan, så fortæl mig hvilket fima du arbejder for, så jeg kan sælge mine aktier i det.

13) En tidsplan er ligesom træklodser. Hvis du har en bunke træklodser, og du ikke kan få dem ned i en kasse, så har du to valg: finde en større kasse, eller fjerne nogle klodser. Hvis du regnede med at kunne udgive produktet om 6 måneder, men du har 12 måneder på din tidsplan, så bliver du enten nødt til at forsinke produktet, eller fjerne nogle funktioner. Du kan bare ikke gøre træklodserne mindre, og hvis du lader som om du kan, så fratager du dig selv, muligheden for at se ind i fremtiden ved at lyve overfor dig selv om hvad du ser.

Og ved at lave din tidsplan på denne måde, så følger der den gode bivirkning med, at du er tvunget til at fjerne nogle funktioner. Og hvorfor er det nu godt? Forestil dig, at du har to funktioner: den ene er rigtig smart og vil gøre dit produkt virkelig godt (eksempel: tabeller i Netscape 2.0) og den anden er virkelig let og programmørerne vil elske at kode den (eksempel: BLINK tagget), men den er hverken til nytte eller marketingsmæssig gavn.

Hvis du ikke laver en tidsplan, så vil programmørerne lave de lette/sjove funktioner først. Når tiden så er udløbet, så har du ikke andet valg end at overskride tidsplanen for at lave de brugbare/vigtige funktioner.

Hvis du laver en tidsplan før du starter med at arbejde, så går det op for dig, at du bliver nødt til at skære noget væk, så kan du fjerne de lette/sjove funktioner og kun lave de brugbare/vigtige funktioner. Ved at tvinge dig selv til at skære nogle funktioner væk, så ender du med et stærkere og bedre produkt, med et godt udvalg af gode funktioner der hurtigere bliver færdigt.

Jeg husker da jeg arbejdede på Excel 5. Vores oprindelige funktionsliste var virkelig lang, og vi ville have gået langt over tidsplanen. Åhh nej! tænkte vi. De er alle super vigtige funktioner. Hvordan kan vi leve uden en makroredigeringsguide?

Det viste sig, at vi ikke havde noget valg, og vi syntes selv at vi "skar helt til benet", for at overholde tidsplanen. Alle følte sig utilfredse med nedskæringerne. For at berolige vores følelser, sagde vi til hinanden, at vi ikke fjernede nogle funktioner, men at vi kun udsatte dem til Excel 6, fordi de ikke var så vigtige.

Da Excel 5 nærmede sig færdiggørelse, begyndte jeg og en kollega, Eric Michelman, at arbejde på Excel 6 specifikation. Vi satte os sammen for at gennemgå listen med "Excel 6" funktioner, som var blevet fjernet fra Excel 5 tidsplanen. Det var et chok at opdage at listen med fjernede funktioner var den skrækkeligste funktionsliste man kunne forestille sig. Ikke én af de funktioner var værd at lave. Jeg tror ikke, at en eneste af dem nogensinde er blev lavet i de næste tre versioner. Processen med at fjerne funktioner, så vi kunne overholde tidsplanen, var det bedste vi gjorde. Hvis vi ikke have gjort det, så havde Excel 5 taget dobbelt så lang tid at lave, og havde indeholde 50% flere nytteløse skod funktioner. (Jeg er overhovedet ikke i tvivl om, at det er det, som er ved at ske med Netscape 5/Mozilla: de har ingen tidsplan, de har ingen endelig funktionsliste, ingen er villig til at fjerne noget, og de er bare aldrig blevet færdige. Når de engang bliver færdige, så vil de have en masse ligegyldige funktioner som IRC klienter, de bare ikke skulle have brugt tid på.)

Appendix: Værd at vide om Excel

En af grundene til at Excel er så velegnet til at lave tidsplaner i er, at det eneste de fleste Excel programmører bruger Excel til er at vedligeholde deres tidsplaner! (Det er ikke mange af dem der laver forretnings-what-if scenarier... det er programmører vi har med at gøre!)

Delte Lister med Filer/Delte Lister kommandoen gør det muligt for alle, at åbne den samme fil og lave ændringer på samme tid. Når det nu er meningen at hele holdet, konstant skal holde tidsplanen opdateret, så er det virkelig en fordel.

Auto Filter Her er en fantastisk måde at filtrere tidsplanen, så man, for eksempel, kun ser de opgaver man har fået tildelt. Kombineret med Auto Sortering, så kan man få en oversigt over sine opgave i prioriteret rækkefølge, og så har man faktisk sin "to do" liste. Seeejt!

Pivot Tabeller Her er en god måde at se oversigter og krydsreferencer. For eksempel kan man lave en graf der viser tilbageværende timer for hver udvikler for hver prioritet. Pivot Tabeller er lige som skiveskåret brød og chokolade milkshake. Man bliver simpelthen nødt til at lære at bruge dem, for Excel bliver 100 gange mere kraftfuldt.

ARBEJDSDAG Funktionen fra Excel's Analysis Toolpak er en god måde at få kalender dage ud en Smertefri Tidsplan.



Originalartiklens engelske titel er Painless Software Schedules  

Joel Spolsky er stifter af Fog Creek Software, et lille software firma i New York. Efter endt studie på Yale universitetet, arbejdede han som programmør og manager ved Microsoft, Viacom og Juno.


Indholdet på disse sider repræsenterer én persons meninger.
Alt indhold Copyright ©1999-2005 af Joel Spolsky. Alle rettigheder forbeholdes.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky