The Pragmatic Programmer: From Journeyman to Master

Altijd fijn, als je een boek koopt waar je met plezier in leest. Deze dus ook. Had ‘m volgens mij op aanraden van iemand anders aangeschaft, en toen ik ‘m in handen kreeg was ik gelijk teleurgesteld: het boek was uit 1999! Zal me lekker pragmatisch zijn, zeker tips hoe je moet omgaan met klachten op je MS-Dos scherm? Niets was minder waar.
Een boek geschreven om een tip-lijst heen (dat zie je tegenwoordig ook wel veel, in elke paragraaf een ‘tip’, dus in dat opzicht waren zo ook al bij). Oftewel: het boek vertelt hoe je een goed pragmatisch developer kan zijn en worden, en vat alle stukjes aan het einde van de paragraaf samen als een tip. Het leuke is dat al die tips, met korte omschrijving, ook als uitscheur lijst achterin het boek zit.
En ik heb het nu twee weken uit, en sindsdien markeer ik op die lijst als ik de tip ook in andere artikelen lees, en ik de tip ook van waarde acht. Zo krijg je zo maar je eigen Agile-wiki op papier.
Anyway, het boek bevat 70 tips die variëren van ‘inkoppers’ tot ‘oh ja’ tot ‘oeps in de valkuil stap ik ook’ tot ‘waarom heb ik dat zelf niet bedacht’.
Soms wel een beetje achterhaald als ze het hebben over tooling en dergelijke, maar de principes staan nog altijd overeind.

Advertisements

Boekbespreking ‘Scrum and XP from the trenches, how we do scrum’

Op een vorig project werkte ik samen met Mark. Mark is iemand die ik zeer bewonder en die veel inzicht heeft in het proces van software development en software architectuur. Samen hebben we menig gesprek gehad over software architectuur. Voor allebei was dat leuk en leerzaam, het is prettig om collega’s te hebben waarmee je over dergelijke onderwerpen kunt sparren.
Later kwam John er ook bij, en het onderwerp waar we samen met hem over praatten was Agile Development. En als je praat en leest over Agile Development, dan kom je vaak uit bij Scrum en XP. Een leuk onderwerp, want het gaat over hoe we kunnen doen wat wij doen: software bouwen. We hebben er alle drie veel over gelezen en zijn er individueel al deels mee bezig op projecten, maar we hadden geen van allen een project gedaan waar er echt dedicated Agile wordt ontwikkeld.
Zelf heb ik o.a. het boek ‘Agile Project Management with Scrum’ gelezen met daarin case studies over Scrum, en als je dat leest lijkt het wel alsof een Agile project niet kan mislukken.
En dan komt in de discussie over Agile dus steeds de vraag naar boven: hoe zou het in de praktijk werken ? (dit waren dus meer theoretische discussies in tegenstelling tot de archtitectuurdiscussies met Mark, waar je echt de praktijk van alledag naast elkaar kan leggen)
En toen was er het boek ‘Scrum and XP from the trenches, how we do scrum’ met daarin een schat aan ervaringen uit ‘het echte Agile leven’. Dit boek is na registratie gratis te downloaden en is desgewenst ook als hardcopy te verkrijgen, wat ik ook heb gedaan als fijner naslagwerk en om de schrijver te steunen.
En zoals de schrijver Henrik Kniberg aangeeft: “er is niet de manier om een project met XP en Scrum aan te pakken, en zoals wij (de schrijver en zijn teams) het doen is niet per definitie de juiste manier (zelf zegt hij: misschien vind je onze werkwijze wel waardeloos) maar we kunnen in ieder geval leren van zijn ervaringen”. Want de schrijver heeft verschillende projecten gedaan met Scrum en XP en zijn meest belangrijke ervaringen en keuzes heeft hij in dit boek gebundeld.
Ikzelf las het in één ruk uit: al die vragen die je zelf hebt worden grotendeels beantwoord, of in ieder geval voorzien van argumentatie. Welke detaillering breng ik aan in de backlog, en waarom heeft hij bepaalde details er juist uit weggelaten. Hoe schatten we de tijd van user stories in, en waarom op die manier. En dat is prettig om te lezen: waarom ze bepaalde zaken hebben gekozen, en waarom ze bepaalde zaken hebben gelaten. Het mooie is dat je de argumentatie gewoon kunt volgen, en zelf een andere conclusie kunt trekken als je een andere mening toebedeeld bent.
Een minpuntje is dat er niets in staat over de mensen er om heen, hoe die het ervaren. Hoe ervaart een gebruiker het als hij van te voren alleen een inschatting krijgt wat er gebouwd wordt, alleen een grof idee van de functionaliteit, en alleen een inschatting van de kosten? Hoe breng je deze cultuuromslag bij mensen?
Maar ook zonder deze informatie een zeer nuttig boek.
 
Boekinfo:
168 pages, 6″ x 9″
ISBN: 978-1-4303-2264-1
Gratis copy te downloaden van de InfoQ minibooks site
In Nederland o.a. te koop bij comcol.nl en bol.com

Wanneer is het af?

Elke developer krijgt de vraag als je hebt aangegeven dat je weet wat er gebouwd gaat worden (of als je nog geen flauw idee hebt, als iemand je in 1 minuut een systeem heeft uitgelegd dat minimaal 5 manjaar kost om te bouwen, maar dat terzijde): wanneer is het af?

Ik ben een boek aan het lezen en daar is hun advies om als antwoord te geven: “I’ll get back to you”. (‘t is namelijk een Engels boek :-)). Dit omdat in hun ogen, en daar ben ik het wel mee eens, je een meer accuratere schatting krijgt als je er even over kunt nadenken.

Anyway, het punt dat ik interessant vond is het volgende. Als je denkt met iets een half jaar bezig te zijn, dan maakt het niet alleen uit hoe je het brengt, maar ook welke eenheid je gebruikt. Is een beetje uit de wiskunde; hoe kleiner je de eenheid kiest, hoe nauwkeuriger je aangeeft te zijn.
Gebruik je in dit voorbeeld bijvoorbeeld ‘een half jaar’, dan zal een goed verstaander al rekening houden met een maand of 8. Zeg je ‘6 maanden’, dan klinkt het al als tussen de 5 en 7 maanden. Zeg je echter ‘180 dagen’, dan klinkt het al alsof je verwacht er niet veel langer over te doen dan een dag of 180 à 190.

De auteurs van het Agile developer boek geven daarom aan in welke eenheid je moet schatten, afhankelijk van de tijd die je er voor nodig denkt te hebben. De laatste regel bevat een mooie tip: verwacht niet dat je meer dan een half jaar vooruit een accurate schatting kunt maken. Dat komt ook voor in Scrum: je kunt een sprint (van 30 dagen) accuraat plannen, de sprints van daarna al globaal, maar hoe verder vooruit, hoe minder accuraat het wordt.

Maar vooruit, dan eindelijk de tabel waar het allemaal om ging….

Als je denkt aan… Plan in
1 – 15 dagen dagen
3 – 8 weken weken
8 – 30 weken maanden
meer dan 30 weken Geef geen planning af