Gesprek met Sam Guckenheimer

Ik kom zojuist uit een interessante meeting met Sam Guckenheimer. Sam is schrijver van het boek "Software Engineering with VSTS" en hij is bij Microsoft betrokken bij het ontwikkelen van nieuwe features in VSTS als lead program planner. Sam en ik hebben gesproken over hoe je met iteratief ontwikkelen om moet gaan in een Demand/Supply omgeving als waar wij in het SDMC in zitten. Een belangrijk aspect volgens Sam is, dat je vooral rekening moet houden en ook willen houden met het feit dat je wijzigingen krijgt op het systeem dat je bouwt. Het is prima om een klant een vaste prijs te geven, met alle aannames en randvoorwaarden die daarbij horen, maar dit geldt alleen als je een project hebt dat niet onderhavig is aan wijzigingen. Bestaan die projecten nog wel? We waren het erover eens dat dat dus niet het geval is. Hoe gaan we dan om met het aanbieden en uitvoeren van projecten in 'onze' omgeving? Stop met het kruideniersdenken en help de klant met het oplossen van zijn businessprobleem. Dit betekent dat we in een bid dus niet alleen een vaste prijs moeten stellen voor een stuk software, maar dat we een prijs moeten stellen voor de basis van die software en een constructie moeten geven voor alle software waarvoor de specificaties kunnen wijzigen. Komt natuurlijk de vraag of we dit wel durven. Ik weet van Rainbows die absoluut niet ontvankelijk zijn voor dit soort nieuwigheden, maar aan de andere kant willen we wel af van het 'ouderwetse' waterval dogma af en ook in de markt een rol spelen in de nieuwe SE methodieken die allen gebaseerd zijn op iteratief en incrementeel werken. Wellicht kunnen we nog veel leren van onszelf.

Sam werkt in zijn boek vanuit het concept van scenario's en 'quality of service' requirements. Deze komen voor in MSF. Ik heb Sam gevraagd wat zijn ideeen zijn over de link tussen Scenario en Use Case. Scenario's zijn namelijk redelijk goed te vergelijken met Use Cases, met het verschil dat een scenario min of meer een enkele flow beschrijft en een use case een container is voor flows. Volgens Sam zit het verschil niet zo zeer in de structuur van het Scenario en de Use Case, maar meer in de manier waarop er mee gewerkt wordt. In zijn beeld worden Use Cases verkeerd benaderd en vooral niet zoals Ivar Jacobson (de uitvinder van de UC) ze bedoeld heeft... Wat gebeurt er namelijk vooral, is dat een UC wordt beschreven met alle mogelijke flows die bij de UC horen, dan wordt iedere flow apart geanalyseerd en het gedrag (in UML) uitgewerkt. Nadat alle flows bekend zijn, wordt een Use Case Realisation gemaakt, geanalyseerd en voorzien van de nodige diagrammen. Pas als al dit klaar is dan wordt naar implementatie gekeken en als je dan 100% volledig bent geweest, dan is die implementatie bijna te helemaal te genereren uit de modellen (hoor ik hier het MDA concept). Maar zo is de realiteit niet, het is onmogelijk om zonder ervaringen (die doe je namelijk niet op door het alleen beschrijven van een flow) alle flows goed te beschrijven. Je moet die ervaringen opdoen en dat is waar een Scenario om de hoek komt: neem in de UC een enkele flow, wellicht de basic flow of happy path, werk deze uit en leer ervan door middel van de implementatie, feedback van de gebruikers, testen etc. Pak met deze ervaring dan een volgende flow en leer ook hier weer van. VSTS laat helaas nog niet toe om een hierarchie in de work items te hebben, dus worden wat wij kennen als flows in een UC als aparte scenario's ingebracht. In een volgende release is het mogelijk dat deze hierarchie er wel komt en dan worden scenario's vermoedelijk samengebracht in een (business) requirement.

We hebben het verder ook gehad over de rol van Team Architect die zoals we weten, momenteel nog niet zo groot is. Een aandachtspunt dat ik zelf er belangrijk vind, is dat volgens mij Microsoft nog niet zo hard loopt om het Software Factory concept verder vorm te geven. Sam geeft me daar enigszins gelijk in. Bij Microsoft wordt met Software Factories meer in termen van 5 - 10 jaar gedacht dan in 1 - 2 jaar. Vanuit ons perspectief willen we uiteraard niet zo lang wachten voor we zeg maar MDA kunnen toepassen in VSTS, maar we moeten natuurlijk ook niet voor de muziek uit gaan lopen. Een eerste stap hierin, en dat komt helemaal overeen met wat Steve Cook vorig jaar ook al zei, is dat we klein moeten beginnen. Zorg voor kleine succesjes, quick wins, en leer daar weer van. In dit kader vroeg Sam me wat ik vind van het uitbreiden van VSTS met ondersteuning van de rol Business Analyst. Deze zou dan projecten moeten kunnen initieren en valideren op basis van business values, een interface hebben met VSTS via processbeschrijvingen, mind maps etc. Ik denk dat dit zeker een upgrade van VSTS oplevert, maar alleen als er twee zaken in VSTS worden toegevoegd: de eerste is Asset Management, dat zoals het zegt hergebruik beheerbaar maakt, en een tweede is dat momenteel alleen op projectniveau gewerkt kan worden (alles moet in een Team Project worden ondergebracht) en het toevoegen van BA functionaliteit betekent dat het ook mogelijk moet zijn om projectoverstijgend te kunnen werken.

Kortom, een heel interessant gesprek met nog een tweetal spin-offs: ten eerste de toezegging van Sam om samen te gaan werken aan een Case Study om het werken met VSTS te optimaliseren. Ik word daarvoor in contact gebracht met de verantwoordelijke daarvoor en een tweede is dat Sam me gaat introduceren bij iemand die nauw betrokken is geweest bij het tot stand komen van de Software Factory implementatie van HL7, dat als studie object wordt uitgewerkt.
Sam heeft zijn boek gesigneerd met "Peter, it is a great pleasure to have you contribute to future ideas for VSTS and to collaborate on current projects. I look forward to many years of mutual enrichment". Oke, een veer in eigen ..., maar dit geldt niet mijn persoontje: ik wil dit opdragen aan iedereen bij Atos Origin die net als ik geloof in de kracht en de toekomst van VSTS.

to be continued