In elk project komt er een moment dat de aandacht eigenlijk moet verschuiven van ontwikkelen van functionaliteit naar het afronden van het geheel. Er moet bijvoorbeeld worden gerefactored, er moeten extra testen worden geschreven en performance wordt geoptimaliseerd. Er bestaan echter op dit moment ook nog vaak een aantal stories die, als er geen extra tijd/budget komt, dus niet kunnen worden ontwikkeld binnen het traject.
Tenminste, als je deze op de typische Scrum-manier invulling geeft. Denk eens serieus na over de informatie die in een typische daily stand-up wordt meegedeeld: Wat heb je gisteren gedaan? Wat ga je vandaag doen? Heb je nog blokkades? We zijn verteld dat we deze drie vragen moeten beantwoorden tijdens de daily stand-up. We moeten ook allemaal even gaan staan zodat het niet al te lang duurt, want stel je voor dat er wat nuttigs verteld wordt!
Ik doe niet meer mee!
De discussies over de randvoorwaarden waaraan een project moet voldoen om het wel echt Scrum te mogen noemen. De bedrijven die voor een mooi uurtarief ook “Scrum” doen. De Scrum Master die als Project Managers opereren. De examens waarvoor je niet kan zakken. De teams die Scrum doen zonder enige agility. De mensen die keer op keer het Half-arsed manifesto opnieuw uitvinden. De slechte reputatie die Scrum krijgt naarmate er steeds meer Scrumfall projecten falen. Vooral het laatste punt hield me een tijd erg bezig maar dat is verleden tijd. Ik doe er gewoon niet meer aan mee.
De PHP-conferentie is inmiddels al weer twee weken terug, maar ik was nog niet toegekomen aan het schrijven van mijn verslag van dag 2 en 3. Hierbij dan een samenvatting van de lezingen die ik heb bezocht, waar er weer keus genoeg was. Ik heb gekozen voor lezingen over herbruikbaarheid, ORM, schaalbaarheid, REST, testen en SCRUM.
De eerste echte dag van RailsConf stond in het teken van tutorials. Van de acht tutorials van ieder 4 uur kon je er dus maar 2 volgen. Daarnaast was de unconference “Bohconf” begonnen. Een unconference is een gratis alternatief voor de conferentie, met wat lichtere onderwerpen in een informele setting. Er wordt gezellig gehackt en gekletst, de ene keer wat gestructureerder dan de andere keer.
Lees verder
Op dit moment ben ik in Baltimore, Maryland. Daar is deze week RailsConf 2010, de officiële conferentie over Ruby on Rails. De komende paar dagen zal ik vanaf hier verslag doen van wat er hier zoal gaande is.
Lees verder
Finalist zet graag in op innovatie en daaronder valt ook onze projectmethodiek. Hoe fijn Scrum/Agile ook werkt, mijn ervaring is dat het soms niet “past”. Dus hoe weet je nu of Scrum voor jou is?
Deze maand plaatsen we op het Finalist Developer Blog een serie over Ruby en scrum. Dit artikel is het laatste in die serie, waarin één van onze testers – Marco Plaisier – vertelt over zijn ervaringen met Ruby en scrum binnen Finalist.
Ik ben gefascineerd door de titel van het boek The 4-Hour Workweek. De strekking van het boek is dat je, door werk slim in te delen, maar 4 uur per week hoeft te werken. Je kunt dit bereiken met het vier (alweer) stappen plan: DEAL. Oftewel, Definition, Elimination, Automation, Liberation. Dit past toevallig genoeg perfect op onze scrum aanpak.
Deze maand plaatsen we op de Finalist developer blog een serie over Ruby en scrum die vanuit vier verschillende rollen wordt beleefd. Vandaag geeft Felix zijn visie op Ruby/ Scrum volgens de product owner.
De product owner vertegenwoordigt de klantorganisatie, het financieel belang en de domeinexpertise in een Scrumproject. De meest ontzagwekkende taak van de product owner is dat hij de te bouwen softwarefuncties kiest (prioriteert). Dat is niet zo gemakkelijk. Product owners kunnen het best streven naar Conceptuele Integriteit als ze een sprint vullen.
Lees verder
Deze maand plaatsen we op de Finalist developer blog een serie over Ruby en scrum die vanuit vier verschillende rollen wordt beleefd. Vandaag geeft Iain zijn visie op Ruby/ Scrum volgens de ontwikkelaar:
Ik hou van Scrum. Zo, dat is er uit. Ik ben een van die programmeurs die liever niet eindeloos vergadert en interviewt over hoe iets moet gaan werken. Ik krijg liever een korte instructie, ik bouw wat en laat dat zien. Mijn eerste ingeving is zelden gelijk naar wens, dus ik krijg feedback over wat ik gebouwd heb en verwerk dat weer. Zo komen we samen dichter bij het eindproduct. Ik houd er niet van om de gehele dag alleen maar te praten. Ik wil zo snel mogelijk mijn handen vuil maken en aan het werk. Effectief biedt scrum je evenveel overleg als de wat traditionelere projectaanpakken, maar meer verspreid, waardoor het wat beter uit te houden is.
De komende vier weken plaatsen we op de Finalist developer blog een serie over Ruby en scrum die vanuit vier verschillende rollen wordt beleefd. Wellicht ben je bekend met deze projectaanpak en programmeertaal? Wij hebben er het afgelopen jaar een aantal succesvolle projecten mee gedaan en we hopen je met deze serie te laten zien hoe Finalist Ruby/scrum projecten aanpakt en waarom deze aanpak zo succesvol is. Deze week is het woord aan Firas Daoud die het afgelopen jaar als projectmanager een aantal scrum projecten heeft begeleid.In mijn verhaal focus ik me op het scrum gedeelte van een Ruby/scrum project, met name over de opstartfase. Inmiddels heb ik het genoegen gehad om een aantal scrum projecten met Ruby (on Rails) de doen. Meestal waren dit kleine projecten en om zo’n klein project goed te doorlopen is het eeuwenoude gezegde ook binnen de ICT nog altijd waar: “een goed begin is het halve werk”.