Joel on Software

Joel on Software   Joel over Software

 

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

 

Pijnloze Software Planning


Door Joel Spolsky
Vertaald door Mark Tetrode
Geredigeerd door Erik van Linstee
29 maart 2000

In oktober van het vorige jaar werd het noordoosten van de Verenigde Staten overspoeld met advertenties voor Acela, de nieuwe sneltrein tussen Boston en Washington. Jou zou denken dat ze, door de hoeveelheid reclame toch enige vraag hadden gecreëerd voor de nieuwe sneltrein van Amtrak [Amtrak is de nationale spoorwegmaatschappij].

Misschien wel, misschien niet. Amtrak is er nooit achter gekomen. Acela werd uitgesteld, en opnieuw uitgesteld. Terwijl de marketingcampagne op volle toeren draaide was Acela niet eens beschikbaar. Dat deed me denken aan een uitspraak van een marketingmanager toen z'n product een positieve recensie kreeg in de maand voor het te koop was: "Wat een reclame! Jammer dat je het ding niet kan kopen!"

[Image]Spelletjesfirma's met een hoog testosterongehalte zetten met graagte op hun web sites dat het volgende spel uit komt "wanneer het klaar is". Planning? Wij hebben zo'n achterlijke planning niet nodig! Wij zijn hippe spelletjesontwikkelaars! De meeste firma's kennen deze luxe niet. Vraag het maar aan Lotus. De eerste release van Lotus 123 versie 3.0 had een 80286 nodig, niet zo courant in die tijd. Lotus vertraagde de release met 16 maanden, en deed het onmogelijke om alles in het 640 K geheugen van de toenmalige 8086 te proppen. Tegen de tijd dat ze klaar waren liep Microsoft 16 maanden voor met de ontwikkeling van Excel, en de 8086 was van de markt verdwenen!

Op het moment dat ik dit schrijf, komt de web browser Netscape 5.0 bijna twee jaar te laat uit. Dit komt gedeeltelijk omdat ze de fatale vergissing begingen om alle bestaande code over boord te gooien, en overnieuw te beginnen. Dezelfde vergissing die Ashton-Tate, Lotus en Apple's MacOS naar de prullenbak van de softwaregeschiedenis verwees. Het aantal mensen dat de Netscape browser gebruikte daalde van 80% tot 20% in die periode en Netscape kon niets doen, omdat hun browser vanaf de fundamenten opnieuw moest worden opgebouwd. Deze beslissing, meer dan welke andere, was de atoombom waarmee Netscape zichzelf opgeblazen heeft (zie Jamie Zawinski's wereldberoemde tantrum voor de details).

Dus je moet een planning maken. Dit is iets dat bijna geen enkele ontwikkelaar graag doet. De grote meerderheid probeert het geheel zonder een planning te doen. Diegene die wel een planning maken, doen dit halfslachtig en enkel omdat hun baas hierom vraagt. En niemand gelooft echt in de planning, behalve het hogere management. En die geloven ook dat "geen enkel software project tijdig klaar is" en in UFO's.

Waarom maakt niemand een planning? Twee redenen. Eerste: het is verdraaid moeilijk. Tweede: niemand gelooft er toch in. Waarom moet ik al die moeite doen voor een planning als er toch geen geloof aan wordt gehecht? Men heeft het idee dat planningen nooit accuraat zijn en meer en meer afwijken naarmate de tijd vordert, dus waarom lijden voor nop?

Hier is een simpele, pijnloze manier om een planning te maken die nog klopt ook.

1) Gebruik Microsoft Excel. Kom niet in de verleiding om een groot planningspakket zoals Microsoft Project te gebruiken. Het probleem hiermee is dat zulke pakketten denken dat je veel tijd kan besteden aan onderlinge afhankelijkheden. Een afhankelijkheid is wanneer je twee taken hebt, en de eerste moet af zijn voordat de tweede kan beginnen. Mijn ervaring met software is dat de afhankelijkheden zo duidelijk zijn dat het de moeite niet is om ze formeel te bewaken.

Een volgend probleem met Project is dat het denkt dat er een knop, genaamd 'Uitbalanceren' moet zijn. Dit betekent dat het zaken opnieuw gaat verdelen, en verschillende taken aan andere mensen zal toekennen. Dit werkt niet bij software. Ontwikkelaars kunnen niet zomaar worden verschoven. Het oplossen van de bugs van Rita door Jan duurt zeven keer zolang als omgekeerd, om maar een voorbeeld te geven. En als je de ontwikkelaar van een user interface een WinSock probleem geeft, duurt het minstens een week voordat deze het principe ervan door heeft. Project is gemaakt om kantoorgebouwen te bouwen, niet om software te bouwen.

2) Hou het simpel. Het standaard formaat dat ik gebruik voor planningen is zo simpel dat je het gemakkelijk uit je hoofd kan leren. Je begint met zeven kolommen:

[Image]

Als je meerdere ontwikkelaars hebt kan je een apart blad maken per ontwikkelaar, of je maakt een kolom erbij met de naam van de ontwikkelaar voor deze taak.

3) Elke programmaonderdeel moet uit meerdere taken bestaan. Een programmaonderdeel is bijvoorbeeld spellingscontrole toevoegen aan het programma. Het toevoegen van spellingscontrole bestaat uit een aantal te onderscheiden taken die de ontwikkelaar moet volbrengen. Het allerbelangrijkste deel van het maken van de planning is de lijst met taken. Daarom de volgende onmisbare regel:

4) Enkel de ontwikkelaar die de code gaat schrijven kan de planning opmaken. Elk systeem waar het management een planning maakt en dit aan de ontwikkelaars doorgeeft zal onherroepelijk falen. Alleen de ontwikkelaar die het eigenlijke werk gaat doen weet welke stappen er nodig zijn om een bepaald programmaonderdeel te maken. En enkel deze ontwikkelaar kan schatten hoe lang dit zal duren.

5) Neem zeer kleine taken.Dit is het allerbelangrijkste onderdeel om een werkzame planning te verkrijgen. De taken moeten in uren worden gemeten, niet in dagen (als ik een planning in dagen of zelfs in weken zie, weet ik dat het niet echt is). Wellicht denk je dat een planning met zeer kleine taken enkel meer precies is. Verkeerd! Erg verkeerd! Als je een planning begint met grote taken die je in kleinere onderdelen opsplitst krijg je een ander resultaat, niet een preciezer resultaat. Het is een volledig ander getal. Waarom?

Wanneer je zeer kleine taken neemt, moet je er over nadenken uit welke stappen deze taak bestaat. Schrijf de subroutine foo. Maak een dialoog-venster. Lees een verslag. Deze stappen zijn relatief simpel te schatten, omdat je reeds subroutines geschreven hebt, dialoogvensters gemaakt hebt en verslagen gelezen hebt.

Als je slordig bent, en lekker grote stukken plant ("implementeren van spellingcontrole"), dan heb je niet nagedacht over wat je eigenlijk moet doen. En als je niet nagedacht hebt over wat je eigenlijk moet doen, weet je ook niet hoe lang dat zoiets gaat duren.

Elke taak moet tussen de 2 en 16 uur duren, als een vuistregel. Heb je een taak van 40 uur (een week) op de planning, dan is deze niet genoeg opgedeeld.

Een andere reden om de planning in zeer kleine taken op te delen: je moet dan echt nadenken over het design. Als je een vage taak genaamd "Internet integratie - 3 weken" op je planning hebt staan, dan ga je de dieperik in. Als je moet uitvissen welke subroutines je moet schrijven, moet je over alle functionaliteit nadenken. Als je op dit niveau moet plannen, elimineer je veel instabiliteit in een softwareproject.

[Image]

 

6) Houdt de initiële en huidige schattingen bij. Op het moment dat je een taak aan de planning toevoegt schat je hoeveel uur deze taak zal duren en je vult dat in, in de Orig[inal] Est[imate] en Curr[ent] Est[imate] kolommen. Als je, naarmate de tijd vordert, er achter komt dat een taak langer of korter duurt dan verwacht, pas je de Curr Est kolom aan naar wens. Zo leer je van je fouten en zal je de volgende keer nog beter kunnen schatten. De meeste ontwikkelaars hebben geen idee hoe ze de tijdsduur van een taak moeten schatten. Dat geeft niet. Als je blijft leren schatten en je planning blijft bijwerken terwijl je de schattingen aanpast, blijft de planning goed werken (je moet wellicht programmaonderdelen schrappen of later opleveren dan gepland, maar de planning werkt, in die zin dat ze je continue vertelt dat je onderdelen moet schrappen of later opleveren). Mijn ervaring is dat de meeste ontwikkelaars goede schatters worden na ongeveer een jaar ervaring.

Wanneer de taak klaar is zijn de Curr Est en Elapsed velden gelijk en het Remain veld is 0.

7) Werk de kolom ‘elapsed’ elke dag bij. Je moet geen stopwatch naast je hebben terwijl je code klopt. Vlak voordat je naar huis gaat, of onder je bureau gaat slapen, als je zo'n soort geek bent, doe je net alsof je acht uur gewerkt hebt (ha!) en verdeel je dat over je openstaande taken in de kolom 'elapsed'. Het veld 'remaining' zal door Excel automatisch worden berekend.

Op dat moment werk je ook de kolom ‘Curr Est’ bij voor die taken. Het dagelijks bijwerken van je planning mag slechts twee minuten in beslag nemen. Daarom heet dit de Pijnloze Planning Methode -- snel en gemakkelijk.

8) Neem je vakanties op in je planning. Als je planning aangeeft dat het ongeveer een jaar gaat duren, zal elke ontwikkelaar vakantie opnemen. In je planning moet je dit dus meenemen, net zoals andere zaken die tijd vragen. Het idee hierachter is dat je altijd de opleveringsdatum kan uitrekenen door alle velden in de kolom 'remaining' op te tellen en te delen door 40 -- zoveel weken nog tot de oplevering.

9) Neem ook debugging mee in de planning! Het moeilijkste om te schatten is debugging. Denk maar aan je laatste project. Waarschijnlijk nam het debuggen daar 100% tot 200% van de tijd je nodig had om de code te schrijven. Dit is een verplicht item in de planning en waarschijnlijk het grootste.

Zo werkt het. Laten we zeggen dat een ontwikkelaar aan een bepaald onderdeel werkt. De Orig Est was 16 uur, en tot nu toe zijn er al 20 uren verstreken en waarschijnlijk moet er nog 10 uur aan gewerkt worden. Dus de ontwikkelaar vult 30 uur bij Curr Est, en 20 uur bij elapsed.

Bij het passeren van de mijlpaal zal alle uitloop tezamen een aardig aantal uren vertegenwoordigen. Theoretisch moeten we dan onderdelen schrappen om op tijd te kunnen opleveren. Gelukkig hebben we een 'onderdeel' Buffer voorzien waar we uren van kunnen 'lenen'.

In principe debuggen ontwikkelaars de code terwijl ze schrijven. Een ontwikkelaar moet nooit werken aan nieuwe code als er nog bestaande bugs zijn. Het aantal bugs moet altijd zo laag mogelijk zijn, om twee redenen:


1) Het is gemakkelijker om bugs op te sporen op dezelfde dag als je de code geschreven hebt. Het wordt veel moeilijker en het zal langer duren om bugs op te lossen een maand na dato wanneer je vergeten bent hoe de code nu precies werkt.

2) Het oplossen van bugs is vergelijkbaar met wetenschappelijk werk. Het is onmogelijk om te schatten wanneer je gevonden hebt waar de bug zich voordoet. Als er maar enkele bugs zijn, is het simpel te schatten wanneer de oplevering kan plaatsvinden -- er zijn niet veel onschatbare zaken in het project. Als er honderden of duizenden openstaande bugs zijn, is het onmogelijk om te voorspellen wanneer deze allemaal opgelost zijn.

Als ontwikkelaars de bugs oplossen terwijl ze programmeren, waarom moet er dan nog een taak debugging zijn? Nu, zelfs als je probeert om elke bug op te lossen aan het einde van elke mijlpaal, zullen de testers (intern en bètatesters) nog een aantal heel moeilijke bugs vinden.

10) Houdt rekening met integratietijd. In een project met meer dan één ontwikkelaar zullen er ongetwijfeld zaken zijn die inconsistent of dubbel gedaan zijn en die dus moeten worden samengevoegd. Soms zijn er dialoogvensters voor gelijksoortige zaken die inconsistent zijn. Iemand moet alle menu's, sneltoetsen, toolbars en dergelijke doorlopen, om zulke dingen recht te trekken en alle nieuwe menu-items die iedereen heeft toegevoegd op de juiste plaats zetten. Er kunnen compilerfouten optreden telkens als twee mensen code inchecken. Dit moet opgelost worden en hiervoor moet een taak voorzien worden in de planning.

11) Denk aan een buffer in de planning. Alles duurt langer dan je dacht. Er zijn twee belangrijke soorten buffers die je kan gebruiken. Eén: buffer voor taken die langer duren dan gedacht. Twee: buffer voor taken waar je niet aan gedacht hebt, gewoonlijk omdat het management beslist heeft dat XYZ ABSOLUUT IN HET PROGRAMMA MOET, en niet op de volgende release kan wachten.

Je zal misschien verrast zijn dat vakantie, ziekte, debugging, integratie en buffer meer tijd opslorpen dan de eigenlijke taken? Dan heb je nog niet zo lang geprogrammeerd zeker? Vergeet de buffer op eigen risico...

12) Laat een manager nooit ontwikkelaars een lager aantal dagen opdringen. Nooit. Veel beginnende managers denken dat je de ontwikkelaars kan "motiveren" door ze mooie "strakke" (onrealistisch korte) planningen op te dringen. Ik denk dat dit niet werkt. Wanneer ik achterlig op mijn planning, voel ik me gedoemd, gedeprimeerd en ongemotiveerd. Wanneer ik voorlig op mijn schema, ben ik opgewekt en productief. Met een planning kan je geen psychologische spelletjes spelen.

Als jouw manager je een kortere planning opdringt, doe dan als volgt. Maak een nieuwe kolom in de planning, en die noem je Rik's Estimate (als je naam Rik is, natuurlijk). Voer hier jouw versie van de planning in en laat je manager de kolom Curr Est invullen. Vervolgens negeer je de schatting van je manager. Wanneer het project klaar is, ga je naar hem terug en vergelijk je de resultaten. Mijn ervaring is dat alleen al door dit voor te stellen je manager zich realiseert dat dit resulteert in een wedstrijd 'eens kijken hoe langzaam ik kan werken'!

Waarom proberen incompetente managers de schattingen van ontwikkelaars te drukken?

Bij de start van het project vergaderen de technische managers met de commerciële mensen, en bedenken een lijst met features waarvan zij denken dat het 3 maanden duurt om deze te maken, maar in werkelijkheid gaat het 9 maanden duren. Als  je nadenkt over code schrijven zonder na te denken over alle verschillende stappen, lijkt het altijd n tijd te duren, terwijl in werkelijkheid het waarschijnlijk 3n tijd duurt. Als je een realistische planning maakt, voeg je alle taken samen en realiseer je je dat het project veel langer zal duren dan je initieel dacht. De werkelijkheid komt om de hoek kijken.

Incompetente managers proberen hier omheen te werken door te zoeken naar manieren om mensen sneller te laten werken. Dit is niet erg realistisch. Je kan meer mensen inhuren, maar die moeten het project nog leren kennen, en zullen de eerste maanden maar op 50% efficiëntie werken (en de efficiëntie van hun mentors naar beneden halen). In ieder geval, in deze markt duurt het 6 maanden om goede ontwikkelaars te verkrijgen.

Je kan misschien tijdelijk 10% meer ruwe code uit je mensen sleuren, en ze in een jaar volledig opbranden. Geen grote winst, en je zaagt de poten onder je eigen stoel door.

Je kan misschien 20 % meer ruwe code uit je mensen persen als je ze vraagt super hard te werken, hoe moe ze ook zijn. Boem, debugging tijd verdubbelt. Een achterlijke actie die op een idiote manier dubbelhard terugkomt.

Maar je kan nooit van 3n naar n gaan, en als jij denkt dat dit wel mogelijk is, stuur me dat een e-mail met de naam van je firma zodat ik die aandelen morgen kan verkopen.

13) Een planning is zoals houtblokken. Als je een aantal houtblokken hebt, die niet in een doos passen heb je twee keuzes: je zoekt een grotere doos, of je verwijdert een aantal blokken. Als je dacht dat je over 6 maanden kon opleveren, maar je planning zegt 12 maanden, moet je de oplevertermijn uitstellen, of sommige features niet implementeren. Je kan de blokken niet kleiner maken, en als je doet alsof je dat kan, dan ontzeg je jezelf de mogelijkheid om werkelijk in de toekomst te kijken, door tegen jezelf te liegen wat je daar ziet.

En weet je, een ander mooi bijproduct van met zo'n planning te werken is dat je features moet verwijderen. Waarom is dat goed? Stel dat je twee features hebt: eentje dat echt nuttig is en je product werkelijk verbetert (voorbeeld: tabellen in Netscape 2.0), en een ander dat simpel is, en waarover de ontwikkelaars vechten om het te mogen coderen (voorbeeld: de BLINK tag), maar dat niet echt nuttig is.

Als je geen planning hebt, doen de ontwikkelaars de makkelijke en leuke zaken eerst. Dan is de tijd op, en jij moet later opleveren omdat het nuttige/belangrijke feature er in moet.

Als je wel een planning maakt, zie je van tevoren dat er iets uit moet, dus beslis je dat makkelijke en leuke feature niet te doen, enkel dat nuttige/belangrijke feature. Door zaken te moeten verwijderen kun je een krachtiger, beter product maken met een betere mix van goede features, en sneller opleveren.

Toen ik meewerkte aan de ontwikkeling van Excel 5 was onze initiële lijst features enorm lang en we zouden ver over onze planning gaan. "Hoe nu verder?", dachten we. Alles op de lijst is superbelangrijk! Hoe kunnen we zonder een macro editing wizard?

Maar we hadden geen keuze en we verwijderden alles wat niet strikt noodzakelijk was om de planning te halen. Iedereen was hier ongelukkig over en, om onze gevoelens te sparen, zeiden we tegen elkaar dat we deze features niet verwijderden, maar enkel uitstelden voor Excel 6, omdat ze iets minder belangrijk waren.

[Image]

Toen Excel 5 bijna klaar was, begon ik met werken aan de specificaties voor Excel 6, samen met een collega, Eric Michelman. We zaten samen, en gingen door de lijst van "Excel 6" features die we in Excel 5 niet hadden kunnen maken. We waren geschokt toen we die lijst weer terugzagen. De lijst bestond uit de meest rare features die je maar bedenken kon. Geen enkele van deze features was het waard geïmplementeerd te worden. Ik denk zelfs dat er geen van in de volgende drie releases van Excel zitten. Het uitselecteren van features om de planning te halen was de beste keuze geweest. Als we dat niet gedaan hadden, had de ontwikkeling van Excel 5 twee keer zo lang geduurd en was ze opgeleverd met 50% waardeloze mogelijkheden (ik twijfel er niet aan dat dit nu gebeurt met Netscape 5/Mozilla: ze hebben geen planning, en geen definitieve lijst met features, niemand wil ook maar één feature schrappen en er wordt dus niet opgeleverd. En wanneer ze eindelijk opleveren hebben ze allerlei aanverwante mogelijkheden zoals een IRC programma, waar ze beter geen tijd aan besteed hadden).

Appendix: Dingen die je moet weten over Excel

Eén van de redenen dat Excel zo'n geweldig product is om een softwareplanning te maken is omdat de meeste Excel programmeurs Excel enkel hiervoor gebruikten! (Niet veel van hen gebruiken zakelijke what-if scenario's, het zijn ontwikkelaars...).

Shared Lists met het commando File/Shared Lists kan iedereen hetzelfde bestand openen en wijzigen. Omdat heel het team continue de planning moet bijwerken, helpt dit enorm.

Auto Filter Een makkelijke manier om de planning te filteren zodat je bijvoorbeeld enkel de features voor jou ziet. Gecombineerd met Auto Sort, zie je ze zelfs gesorteerd op prioriteit - je hebt zo direct je takenlijst. Gaaf!

Pivot Tables Een goede manier om samenvattingen en kruistabellen te maken. Je kan bijvoorbeeld een grafiek maken met de overblijvende uren per ontwikkelaar per prioriteit. Pivot Tables zijn enorm handig. Je moet ze leren gebruiken omdat ze Excel een miljoen keer krachtiger maken.

De WORKDAY Functie uit het Analysis Toolpak is een gemakkelijke manier om enkel de werkdagen over te houden in een Pijnloze Planning.



De originele versie van dit artikel verscheen in het Engels onder de naam Painless Software Schedules  

Joel Spolsky is de oprichter van Fog Creek Software, een klein softwarebedrijf in New York. Hij studeerde af aan de Yale universiteit, en heeft als programmeur en manager gewerkt bij Microsoft, Viacom en Juno.


De inhoud van deze pagina's vertegenwoordigt de mening van één persoon.
Alle inhoud Copyright ©1999-2005 door Joel Spolsky. Alle rechten voorbehouden.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky