Ontwikkelstraat++

Binnen bedrijven die zich bezighouden met software development is het meer en meer gemeengoed om een omgeving in te richten aangeduid als “ontwikkelstraat”. Op deze site zijn al regelmatig postings langsgekomen over ontwikkelstraten – veelal gericht op een specifieke set aan tooling zoals source control systemen, continuous integration oplossingen en anderssoortige collaboratieve software.

Maar wat is nu eigenlijk een ontwikkelstraat? Laat ik beginnen met een definitie die ik vaak gebruik en die redelijk algemeen geaccepteerd is:

Het totaal van tools, methoden, processen en mensen met als doel het effectief en productief ontwikkelen van software.

Om een set aan tools te omschijven als een ontwikkelstraat is dus wat kort door de bocht. Desalniettemin zijn er veel partijen die een ontwikkelstraat aanbieden als een soort shrink-wrapped oplossing die je als product kunt kopen. De benadering die we bij Sogyo kiezen is veel meer toegespitst op de embedding binnen de organisatie zelf: Een set aan tools wordt altijd afgestemd op de bestaande werkwijze.

Om tot een grove classificatie te komen van tooling en technieken onder de overkoepelende term ontwikkelstraat analyseer ik hier tools en technieken op 4 niveau’s:

Individueel niveau
Op dit niveau onderkennen we tools en technieken die een software onwikkelaar op individueel niveau gebruikt. De meest basic tools zijn compilers en text editors, maar denk hierbij in meer geavanceerde vorm aan IDE’s met allerhande plug-in functionaliteit als codeanalysetools. TDD (Test Driven Development) is een voorbeeld van een op individueel niveau gerichte techniek.

Teamniveau
Op teamniveau praten we meer over real-time collaboratieve tools en technieken. Software development
teams hebben de opdracht om gezamenlijk een bepaalde hoeveelheid source code op te leveren die – eenmaal uitgerold – de juiste processen automatiseert. Om binnen een beperkte tijd tot deze oplossing van voldoende kwaliteit te komen is het nodig om intensief samen te werken. Tools die hierbij helpen zijn source control systemen als subversion, continuous integration oplossingen en issue tracking systemen. Veel gebruikte technieken zijn methoden als SCRUM, DSDM of XP.

Afdelingsniveau
In veel organisaties uit onze dagelijkse praktijk is dit niveau niet echt van toepassing en versmelt meer met het organisatieniveau. Ik noem hem toch omdat hier nogal eens een interessante ontwikkeling plaatsvindt in hele grote organisaties, met name met de invoering van SOA. Dit niveau kenmerkt zich door te richten op een bepaalde specifieke deelverzameling van de totale bedrijfsactiviteiten en in deze context uiteraard de automatisering daarvoor. Je ziet dat er op dit niveau vaak projectmatig gestuurd en gedacht wordt. Tools die hierbij een rol spelen zijn bredere issue management systemen (denk aan helpdesks) en service catalogi. Bepaalde processen rond deployment en release management zijn hier belangrijk. Het is interessant om hier ook systemen als urenregistratie/ERP tegen het licht te houden om bepaalde efficiëntiemetingen te kunnen uitvoeren. Methoden als PRINCE2 zie je hier vaak gebruikt worden.

Organisatieniveau
Zoals ik hierboven al
aangaf is dit niveau bij veel organisaties gelijk aan het hierboven omschreven afdelingsniveau. Midden- en grootbedrijf met IT intensieve bedrijfsactiviteiten lopen echter al snel tegen een scheiding van deze niveau’s aan. Denk op dit niveau aan portfoliomanagement, lifecyclemanagement en resource planning. Alle activiteiten die van hieruit gestuurd worden moeten getoetst worden aan de strategie van het bedrijf: hier is het focussen op een bepaald deelgebied geen optie. De businessvisie staat centraal.

Wat leren we nu door op deze – nogal brede – manier naar het fenomeen ontwikkelstraat te kijken? Allereerst vind ik het zelf interessant dat er nogal wat meer onder de zon is dan de door ons software engineers zo geliefde tools als versiebeheersystemen of continuous integration oplossingen. Deze bieden slechts een hulpmiddel op relatief laag niveau in de organisatie en er is nogal wat meer dat komt kijken bij het ontwikkelen van software. Met name het afdelings- en organisatieniveau dat ik hierboven heb aangestipt worden nog wel eens volledig overgeslagen tijdens het inrichten van een ontwikkelstraat, terwijl hier toch juist de aansluiting met de ‘echte’ wereld gerealiseerd wordt.

In deze post heb ik vrij bottom-up geredeneerd om een overzicht van verschillende niveau’s van tooling en methodes te kunnen onderscheiden. In een volgende post zal ik ingaan op de inrichting van software ontwikkelprojecten vanuit een top-down businessperspectief.