Ik zit inmiddels in Boston. Vlucht en hotel prima verlopen. Ik was zelfs binnen no-time door de douane heen. Nog nooit meegemaakt in de US.
Onderweg heb ik een flink stuk gelezen in het boek van Sam Guckenheimer. Het boek geeft vooral de achtergronden aan van het bestaan van VSTS en wat je er als teamlid mee kan, hoe je je die andere manier van denken eigen kunt maken. Nu dacht ik zelf toch best wel een eind te komen met mijn kennis van VSTS, maar Sam heeft toch weer een aantal interessante inzichten op me losgelaten. In zijn boek geeft hij bijvoorbeeld aan dat het work-down paradigma alleen maar werkt voor projecten die (bijna) geen risico's kennen en de specificaties helemaal bekend zijn. Dit soort projecten komen volgens hem niet meer voor om te ontwikkelen, die koop je. Blijft dus over de projecten die hoge risico's kennen, die vooraf nauwelijks te specificeren zijn - omdat de specs nog wijzigen of gewoon nog niet goed bekend zijn. Dit type projecten kennen we geloof ik maar al te goed: onze dagelijkse boterham. We moeten dus af van het oude paradigma en een nieuwe adopteren: het value-up paradigma. Dit paradigma zou het enige antwoord zijn op het in balans houden van de krachten agility, outsourcing/offshoring en compliance. In het value-up paradigma stuur je de ontwikkeling van software niet meer op gedane arbeid, maar op waarde voor de stakeholders. Dit lijkt heel erg op RUP zou je zeggen, maar ook eigenlijk weer niet. Ik heb gisterenavond nog een project berekend met RUP als proces en we hebben dat echt heel erg work-down gedaan, erg bezig geweest met het in balans krijgen van de resources, de tijd, de functionaliteit (en de kwaliteit). Leuke puzzel, maar in de geest van wat ik vandaag allemaal heb gelezen niet hoe het zou moeten...
Wat heeft dit nu met VSTS te maken zou je willen denken. Nu, VSTS is gebaseerd op dit paradigma. Het is van de grond af zo opgebouwd dat het dit paradigma ondersteund. Willen we dus met VSTS verder, en ik denk dat we dat zeker moeten willen, dan moeten we wellicht ook ons licht doen schijnen op die andere manier van denken over hoe je een systeem bouwt. Wat is dan de grootste uitdaging?
Abonneren op:
Reacties posten (Atom)
1 opmerking:
De grootste uitdaging is om een Agile project management methode zoals Scrum geadopteerd te krijgen. Deze ondersteunt namelijk deze denkwijze. Microsoft komt niet voor niets met een MSF Agile (subset van MSF CMMI). De huidige traditionele manier van project management gaat hiermee op de schop.
Groeten en leuk om je verhalen te lezen.
Een reactie posten