Getting Things Done in een teksteditor

GTD (afkorting van Getting Things Done ontwikkelt door David Allen) is één van de meest gebruikte methoden voor ‘personal productivity’ en ‘time management’.

Ik heb lang gebruik gemaakt van OneNote als ondersteunende tool voor GTD. Enkele maanden geleden heb ik echter de gewone teksteditor herontdekt als de ultieme ‘distraction free’ tool. Microsoft Word, OneNote en Visio hebben plaatsgemaakt voor Markdown en PlantUML. Release.js heeft Powerpoint van zijn troon gestoten. En mijn favoriete editor is Visual Code Studio geworden. Voor Excel heb ik overigens nog geen alternatief gevonden.

Een belangrijke reden om te switchen naar lichtgewicht tools, is dat ik in verschillende operating systems werk (Linux, Windows en Android). Door gebruik te maken van platte tekstbestanden hoef ik mij geen zorgen te maken over compatibiliteit tussen deze operating systems. En aangezien Microsoft Word nog steeds de (de facto) standaard is binnen de zakelijke omgeving, kan ik vrij eenvoudig tekstbestanden omzetten naar dat formaat. Ook in Linux.

Een andere reden om te swichen naar teksteditor is dat zijn – in tegenstelling tot de Office producten – “donkere thema’s” ondersteunen. Urenlang werken op een wit scherm met zwarte cijfers en letters is erg vermoeiend. Het is niet voor niets dat software ontwikkelaars gebruik maken van lichte cijfers en letters op een donkere achtergrond.

Tools

Voordat ik iets vertel over hoe ik GTD heb geïmplementeerd, wil ik eerst iets vertellen over de tools die ik hiervoor gebruik.

  1. Mijn favoriete teksteditor is ‘Visual Code Studio’. Dit is een teksteditor gericht op software programmeurs, die gratis door Microsoft wordt aangeboden. Het is een erg stabiel programma, dat tegelijkertijd vrij licht is. Er is een groot aantal ‘extensions’ beschikbaar waarmee je de functionaliteit van het programma kunt uitbreiden. De installatie van deze uitbreidingen is erg eenvoudig. Goede tweede is het open source programma Atom, dat meer gericht is op webontwikkeling. Qua uitbreidingen (‘packages’) biedt Atom een iets uitgebreider en actueler pakket. Het door Adobe aangeboden programma Brackets is noemenswaardig. Ook gericht op webdevelopment en naar mijn gevoel een iets minder pakket aan uitbreidingen (“extensions’).

  2. Voor tekstopmaak maak ik gebruik van ‘Markdown’ dat een hele basale set aan instructies gebruikt. Zo wordt een koptitel bijvoorbeeld aangeduid door er een hashtag voor te plaatsen (# koptitel, subtitels worden voorzien van meer hashtags), een woord dat vet afgedrukt moet worden moet omringd worden door middel van asterisks. In Visal Code Studio zijn extensies beschikbaar Markdown beschikbaar, inclusief een extensie om een ‘live preview’ in een apart venster te kunnen bekijken.

Implementatie GTD in Visual Studio Code

De GTD file heeft vier secties (conform David Allen’s werkwijze) en de volgende structuur:

# GTD

## TODAY

{actionable item}

## STUFF

## CALENDAR

### Week {weeknumber}

{date}

{actionable item}

## FOLLOW UP

{actionable item}

## SOMETIME/MAYBE

{actionable item}

Toelichting

  • In de TODAY – sectie komen alle taken {actionable items} die ik vandaag wil afronden;

  • In de STUFF – sectie plaats ik alle nieuwe taken die nog toegewezen moeten worden aan de andere secties;

  • In de CALENDAR – sectie komen alle taken die op een bepaald moment in de tijd uitgevoerd moeten worden. Ik vind het prettig om dit op weekbasis in te delen.

  • In de FOLLOW UP – sectie komen alle taken die door anderen uitgevoerd moeten worden en waarop ik wacht. Deze sectie wordt vooral gebruikt om regelmatig reminders te verzenden;

  • De SOMETIME/MAYBE – sectie omvat alle taken die ik ooit nog een uit wil voeren, maar niet op korte termijn;

  • Taken worden vervolgens verplaatst (cut & paste) van sectie naar sectie.

Workflow

Ik gebruik de volgende dagelijkse routine:

  1. Het eerste dat ik ‘s-ochtends doe, is het kopiëren van taken uit de sectie CALENDAR / WEEK / Date (=vandaag) naar TODAY. De eerste datum onder CALENDAR is dan de dag van morgen.

  2. Als ik een taak heb afgerond, dan wordt verwijder ik de actie (ik ben tijdenlang alle afgeronde taken in een apart archief ondergebracht, maar feitelijk keek ik daar nooit meer naar keek)

  3. Taken die afgerond zijn, maar die regelmatig uitgevoerd moeten worden (recurring) worden verplaatst (cut & paste) binnen de CALENDAR – sectie.

  4. Als ik moet wachten op iemand anders, dan wordt een taak verplaatst (cut & paste) naar de FOLLOW-UP – sectie.

Tips en trucs

  1. Ik heb de GTD-file “_GTD.markdown’ genoemd. Door het gebruik van de underscore wordt deze file altijd bovenaan in lijsten / directories geplaatst. De extensie ‘markdown’ geeft teksteditors aan dat ik ‘markdown’ als opmaaksyntax heb gebruikt.

  2. Sommige teksteditor (waaronder Atom) ondersteunen de ‘folding’-functionaliteit. Je kunt dan secties in- en uitklappen. Dat is vooral handig voor de CALENDAR-sectie.

  3. GTD adviseert het gebruik van ‘contexts’, de omgeving of situatie waarin je een taak uitvoert, zoals @home or @work. Voor mij werkte dat niet, dus ik heb het uit mijn GTD systeem verwijderd.

 

 

Waterfall

Klassieke methode om producten te ontwikkelen. Sterk planmatig georiënteerd en gecentraliseerd rondom een projectmanager.

Een waterfall ontwikkeling bestaat grofweg uit de volgende achtereenvolgende fases:

  1. Voorbereiding; opstellen van pakket van eisen en wensen
  2. Analyseren; impact op processen, systemen, gegevens en organisatie
  3. Ontwerpen; architectuur, functioneel en technisch ontwerp
  4. Bouwen; software, systeem, opleidingen
  5. Testen; systeemtest, integratietest
  6. Implementeren; inbedden en borgen in de organisatie
  7. Vrijgeven; commerciële introductie
  8. In beheer nemen; overdragen van project naar de lijnorganisatie

mvp_waterfall

 

Merk op dat voorafgaand aan deze fasen dat er al een goedgekeurd plan is geschreven door de projectmanager, waarin de minimaal de factoren tijd (planning), geld (budget) en kwalilteit (van het projectresultaat) zijn vastgelegd.

ad 1 . Voorbereiding; In deze fase wordt onder leiding van de projectmanager een pakket van eisen samengesteld; de business requirements. Verantwoordelijk voor dit pakket is meestal de business, die de klant vertegenwoordigd. Wijzigingen kunnen ook uit de operatiën of uit de IT zelf komen. Ook dan dient een pakket van eisen opgesteld te worden. In de waterval-methode is het van groot belang is dat aan het einde van deze fase er overeenstemming bestaat over de inhoud van de requirements. In principe vormt het pakket van eisen de basis voor het verdere vervolg van het project. Een wijziging van eisen kan alleen via een formeel wijzigingsverzoek verwerkt worden. Afhankelijk van de omvang van de wijziging kan dat betekenen dat de projectmanager terug moet naar zijn opdrachtgever om meer tijd, meer geld of lagere kwaliteit te bedwingen.

 

ad 2. Analyse; Op basis van het pakket van eisen wordt de impact op de processen, de organisatie en op de systemen vastgesteld. De proces- en organisatie-impact wordt vastgesteld door procesmanagers (zie: procesanalyse), de impact op systemen wordt vastgesteld door IT architecten. Op deze manier wordt duidelijk waar zaken gewijzigd moeten gaan worden. Dit levert een actielijst op voor de projectmanager waarop hij kan gaan sturen.

 

ad 3. Ontwerpen; Nadat de impact is vastgesteld, kunnen procesmanagers hun procesontwerp (zie: procesontwerp) opstellen en de IT (solution) architecten de functioneel en technische ontwerpen.

 

ad 4. Bouwen; In deze fase wordt – op basis van het procesontwerp en de technische ontwerpen – overgegaan op het daadwerkelijk bouwen van software en systemen. Ook wordt de implementatie in de organisatie voorbereid, zoals het aanpassen van werkinstructies en het opstellen en inplannen van opleidingen. ad 5. Testen Na de bouw moet getest worden of de verschillende gebouwde onderdelen functioneren conform het waterfall-model.

Stakeholder Analysis

Vanuit de Stakeholdersanalyse kan vastgesteld worden wie er requirements hebben aangeleverd, wie een belang heeft in bepaalde requirements en wie alleen geïnformeerd hoeft te worden over de requirements.

Bij het opstellen van de Stakeholdersmatrix kan gebruik worden gemaakt van het template Stakeholder Matrix gebruikt worden.

mvp_stakeholder_1

Op basis van deze invuloefening kan de onderstaande figuur ingetekend worden, waarin het relatieve belang van een stakeholder vastgelegd kan worden. mvp_stakeholder_2

Binnen PDRE worden drie type stakeholders onderscheiden :

  • De primaire stakeholders (P) : dit zijn de stakeholders die een rol spelen in de uitvoering of besturing van processen. Omdat hun processen gaan wijzigen, zijn zij de primaire indieners van requirements.
  • De secundaire stakeholders (S) : dit zijn de stakeholders die niet betrokken zijn bij de uitvoering van processen, maar die er wel last van hebben als zij niet goed uitgevoerd worden. Zij zullen vooral aanvullingen en correcties op de door de primaire stakeholders ingebrachte requirements hebben.
  • De tertiaire stakeholders (T) : dit zijn stakeholders die doorgaans geen requirements hebben. Stakeholders kunnen zowel eigenaar als belanghebbende van een requirement zijn. De laatste groep kan daarom uit meerdere stakeholders bestaan.

Scrum

Scrum is een relatief jonge (1993) manier waarop teams samenwerking om een product (meestal software) te ontwikkelen. Wekende producten worden in beperkte tijd (doorgaans 1 tot 4 weken) en in kleinere delen opgeleverd, waarbij het opgeleverde deel is voortgebouwd op eerder opgeleverde delen. Op deze manier wordt de creativiteit van de teamleden gestimuleerd en kan er sneller en gereageerd worden op terugkoppeling en wijzigingen, zodat alleen gebouwd wordt wat nodig is. De term Scrum is dan ook afkomstig uit de rugbywereld en behoort to de Agile softwareontwikkeling.

Algemeen

Scrum is met name effectief als er sprake is van complexe projecten. Er wordt binnen Scrum van een beperkte set aan regels uitgegaan, die net voldoende zijn om structuur te geven om het team richting te geven aan het bedenken van oplossingen. De menselijke waarde staat hoog in het vaandel van Scrum: respect, bij het team horen, doen, maken, creatief zijn, persoonlijk groeien, verbeteren en samenwerken met andere mensen. Scrum stelt mensen in staat om boven zichzelf uit te stijgen en samen meer dingen voor elkaar te krijgen. Samenwerking, gezamenlijk, samen verantwoordelijkheid nemen zijn terugkerende begrippen in de Scrum-wereld. Bedenkers van Scrum zijn Jeff Sutherland en Ken Schwabe.

Rollen

Scrum kent wezenlijk drie fundamentele rollen:

  • Development teams; Development teams boven op basis van specificaties van de product owner (binnen 30 dagen) en demonstreren wat zij gebouwd hebben. De product owner gebruikt deze demonstratie om de volgende bouw vast te stellen. Development Team zitten bij idealiter in één ruimte, zodat er makkelijk kan worden samengewerkt.
  • Product owner; Deze persoon bepaalt wat er in de komende periode gebouwd moet worden (tot max. 30 dagen). De product owner is tevens verantwoordelijk voor de Product Backlog.
  • Scrum Master; Dit is degene die ervoor zorgt voor de randvoorwaarden dat het team zo probleemloos mogelijk kan bouwen, verbetert continu het ontwikkelproces, het team en het product. De Scrum Master is niet alleen leidinggevende, hij/zij is ook dienstig aan het Development Team. De Scrum Master bewaakt de Scrum theorie, de toepassing en de regels.

Karakteristieken

  • Daily scrum; Iedere dag komt het Development Team een kwartiertje bij elkaar om de activiteiten op elkaar af te stemmen en de activiteiten voor de komende 24 uur vast te stellen. Hierbij wordt gekeken naar wat er sinds de laatste Daily Scrum voor elkaar is gebokst en welke zaken beter kunnen.
  • Demo; Na afloop van een Spint wordt in een Demo het Increment getoond dat af is en wordt aangegeven wat niet af is. De Demo duurt maximaal 4 uur. Het hele Development Team is aanwezig plus eventueel andere geïnteresseerden.
  • Definition of Done; binnen Scrum is het belangrijk dat men een gemeenschappelijk beeld heeft wanneer een deellevering klaar is. Dit om transparantie en duidelijkheid te creëren.
  • Increment; Dit is de som van alle punten in de Product Backlog die gedurende de huidige en alle voorgaande Sprints zijn opgeleverd.
  • Product Backlog; Dit is een geordende lijst van alles dat nodig is om het product volwaardig te maken. De Backlog is de enige bron waaruit geput kan en mag worden bij het maken van het product. De verantwoordelijkheid voor de Backlog ligt bij de Product Owner; zowel de inhoud, de beschikbaarheid als de volgorde.
  • Scrum Team; Dit team bestaat uit de Product Owner, het Development Team en de Scrum Master. Scrum Teams are zelfsturend, autonoom en afdelingsoverstijgend.
  • Sprint Backlog; Dit is dat deel van de Product Backlog dat gebouwd gaat worden in een Sprint. Het bevat tevens een plan hoe het Increment opgeleverd gaat worden en hoe het Sprint Goal gerealiseerd gaat woden. De Sprint Backlog wordt samengesteld door het Development Team.
  • Sprint Goal; Dit is een instrument om het Development Team enige flexibiliteit te geven ten aanzien van de functionaliteit die gedurende een Sprint opgeleverd moet worden.
  • Sprint Planning Meeting; Het werk dat uitgevoerd moet worden gedurende een Sprint wordt gepland tijdens een Sprint Planning Meeting. Het is een gezamenlijk plan van het gehele Scrum Team.
  • Sprint Retrospective; De Retrospective is een mogelijkheid voor het Scrum Team om terug te kijken op de eigen activiteiten en te bekijken waar verbeteringen mogelijk zijn. De Retrospective vindt plaats ná de Scrum Review, maar voor de eerstvolgende Sprint Planning Meeting. De Retrospective duurt maximaal drie uur, afhankelijk van de lengte van een Sprint.
  • Sprint Review; Een Sprint Review wordt gehouden aan het einde van een Increment en is vormt een mogelijkheid om de gezamenlijk Product Backlog aan te passen. Deelnemers aan de Sprint Review zijn het Scrum Team en de stakeholders. De Review heeft een informele status en heeft vooral als doel om feedback gemakkelijker te maken en samenwerking te stimuleren.
  • Sprint; Het hart van Scrum wordt gevormd door de Sprint, een periode van maximaal een maand waarin een Done Increment wordt opgeleverd. Het Increment moet aan het einde van de Sprint gereleased kunnen worden. Sprints hebben een consistente doorlooptijd gedurende het ontwikkelproces en starten direct na de beëindiging van de vorige.

Failure Mode and Effects Analysis – FMEA

FMEA is een kwantitatieve methode om risio’s te identificeren, te schatten, te prioriteren en te evalueren met als doel om ‘failures’ te voorkomen. De methode is ontwikkeld in de 50’er jaren als onderdeel van een betrouwbaarheidsstudie van militaire systemen.

Voordat er een FMEA opgesteld kan worden, moet er een procesmap beschikbaar zijn. Een FMEA wordt altijd in groepsverband uitgevoerd.

Belangrijk is dat er binnen de groep consensus bestaat ten aanzien van hoe groot een risico is. Dit wordt binnen een FMEA wordt dit uitgedrukt in de volgende formule:

Risk Priority Number (RPN) = Severity (S) x Occurrence (O) x Detection (D)

waarbij:

Severity (ernst) aangeeft wat de ernstigste gevolgen van een storing zijn;
Occurrence (frequentie) aangeeft hoe vaak de storing optreedt en;
Detection (opsporing) aangeeft aangeeft via methode of middel de storing ontdekt wordt.

Het item met de hoogste score vormt het grootste risico voor het project of het probleem.

Het opstellen van een FMEA

Bij het opstellen van een FMEA kan gebruik worden gemaakt van diverse onderdelen, te weten:

  • Een root cause analysis (aka fishbone) om de risico’s in kaart te brengen;
  • Een VOC analyse om de CTQ’s in kaart te brengen;
  • Een process mapping om de processtappen in kaart te brengen;
  • Een correlatie matrix, waarin de processtappen, risico’s en de CTQ’s in verband gebracht worden;
  • Een FMEA-template waarin de RPN berekend kan worden.

De onderstaande figuur toont de relaties tussen deze onderdelen:

mvp_fmea_1

Toelichting

  • De linkerzijde van de tabel wordt gevuld met de waarden uit de correlatiematrix
  • De storingen voor ieder item wordt ingevuld
  • Severity wordt toegekend; 1 voor lage severity, 10 voor hoge;
  • Frequentie van Occurrence wordt ingevuld; 1 voor zeer zelden; 10 voor heel vaak/altijd;
  • Gemak waarmee ontdekking mogelijk is, wordt ingevuld; 1 voor ontdekking is zeer gemakkelijk; 10 is zeer moeilijk te ontdekken.
  • RPN wordt berekend door de scores bij severity, occurrence en detection te vermenigvuldigen.
  • De lijst wordt gesorteerd op RPN
  • Er worden acties en actieshouders gekoppeld aan de gesorteerde RPN lijst

Template voor FMEA

De onderstaande afbeelding geeft een voorbeeld van een FMEA template.
mvp_fmea_2

Agile

Achtergrond

Agile is een vorm van software-ontwikkeling die gebaseerd is op een artikel van Winston Royce uit 1970 getiteld “Managing the Development of Large Software Systems,” waarin hij de vloer aanveegt met de sequentiële wijze van productontwikkeling. Hij beargumenteert dar software niet ontwikkeld moet worden als een auto in een assemblagelijn, waarbij ieder onderdeel in sequentiële volgorde wordt gemaakt. Een start van een volgend onderdeel kan daarbij pas plaatsvinden als het vorige gereed is. In een sequentiële productontwikkelingstraject (ook wel de waterval-methode genoemd), worden eerst alle requirements verzameld, vervolgens daarop gebaseerd het ontwerp en de architectuur, daarna de code etc. Belangrijkste kritiek van Royce was dat een gebrek aan communicatie tussen gespecialiseerde teams de grootste tekortkoming van de waterval-methode is, waardoor hogere coördinatiekosten, grotere kans op fouten (en dus lagere productkwaliteit). En, misschien wel de belangrijkste tekortkoming: er is een product ontwikkeld dat – doordat de wereld sinds de start van het productontwikkeling is veranderd – dat niemand feitelijk nog wil hebben.

Karakteristieken

Agile softwareontwikkeling kenmerkt zich door de mogelijkheid om tijdens het productontwikkelingsproces (project of programma) wijzigingen mogelijk zijn. Hiervoor wordt een Agile-traject opgedeeld in meerdere, vaste periodes, iteraties of sprints genoemd. Aan het einde van iedere iteratie levert een team van ontwikkelaars een potentieel gereed deel van het product op. Kenmerkende woorden voor Agile zijn ‘iteratief’ (herhalend) en ‘incrementeel’ (groeiend in aantal of omvang). In de klassieke waterval-methode hebben de ontwikkelaars maar één kans om alle aspecten van het product goed te inventariseren en te formuleren. In een Agile-project worden alle aspecten van de softwareontwikkeling gedurende het gehele proces geanalyseerd, heroverwogen en indien nodig aangepast aan gewijzigde omstandigheden of betere mogelijkheden. Door dit kort-cyclisch te houden is het eenvoudiger bij te sturen. Hierbij gaat de analogie van het bijsturen van een mammoettanker (waterval-methode) of een fregat (Agile-methode) goed op. Het kenmerkende Agile proces van voortdurend ‘terugkijken-en-aanpassen’ heeft bewezen dat de ontwikkelingskosten en time-to-market aanzienlijk lager zijn dan bij de watervalmethode. Teams kunnen tegelijkertijd bezig zijn met het verzamelen van requirements en het ontwikkelen van de software.

Principes Agile Manifesto (2001)

Agile kent vier kernwaarden en twaalf grondbeginsel die in 2001 door 12 software-ontwikkelaars een heus manifest zijn opgenomen. De vier kernwaarden (http://agilemanifesto.org/iso/nl/):

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we:

  1. Mensen en hun onderlinge interactie boven processen en tools
  2. Werkende software boven allesomvattende documentatie
  3. Samenwerking met de klant boven contractonderhandelingen
  4. Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd. En de twaalf grondbeginselen (http://agilemanifesto.org/iso/nl/principles.html):

  1. Onze hoogste – prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.
  2. Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.
  3. Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.
  4. Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.
  5. Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
  6. De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.
  7. Werkende software is de belangrijkste maat voor voortgang.
  8. Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.
  9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken de bekwaamheid.
  10. Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.
  11. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
  12. Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

Vormen van Agile

De Agile-filosofie wordt o.a. in de volgende methodieken gehanteerd:

  • Scrum – 1995
  • RUP (Rational Unified Process) – 1994