Development-round-up - Iteratie #14

Voor de veertiende keer is succesvol een iteratie opgeleverd, waarbij ditmaal 74 tickets de revue zijn gepasseerd. De lat voor het realiseren van de gloednieuwe Tweakers.net-website ligt hoger dan ooit en er zijn dan ook weer bergen werk verzet. Graag zouden we een tipje van de sluier oplichten, maar we moeten jullie toch nog even in spanning laten. Het enige wat we momenteel kunnen zeggen is dat het mooi, modern en strak begint te worden. De ontwikkeling van de back-end heeft grote sprongen gemaakt en ook de voorkant, vooral de nieuws-, product- en review-listing, krijgt zijn uiteindelijke smoel.

De andere kant van dit nieuws is dat de huidige website ook nu geen grote wijzigingen heeft doorgemaakt. Iets wat wel merkbaar is in de huidige omgeving, is het doorvoeren van Project Phoenix, dat ons van een disaster-recoverylocatie moet voorzien. Hierbij hebben we vijf nieuwe servers opgehangen en een server verhuisd. Met de nieuwe servers worden onze search- en NoSQL-omgevingen dubbel uitgevoerd. Ze zijn dan ook ruim voorzien van geheugen (48GB per server) en snelle harde schijven, en hebben een ssd als extra cache-laag.

Verder hebben we nog een server opgehangen voor ons developmentwerk. Deze heeft 144GB geheugen gekregen, is voorzien van zes 900G 15k-RPM-schijven en heeft als extra cache twee 50GB-ssd's. Op deze server komen verschillende virtuele developmentomgevingen te draaien.

Naast Phoenix zijn nog enkele kleine bugjes gefikst. Zo bleek een wachtwoord na de reminder voor het activeren van een account niet langer valide te zijn. Verder is een nieuwe advertorial opgeleverd om de aandacht te vestigen op het nieuwe Office-pakket van Microsoft: Office365.

Reacties (18)

Halen jullie de sprint altijd? Zo nee, Wat is daar de oorzaak van? Zijn dat onvoorziene omstandigheden, onduidelijke stories, overschatten van eigen kunnen, onderschatten complexiteit etc. En werken jullie over om de sprint te halen?

Nee, niet altijd. We hebben er meerdere reden voor inderdaad; er wordt nog best vaak werk geescaleerd, complexiteit en/of afhankelijkheden worden nog wel eens onderschat. Maar de afgelopen iteratie was er bijvoorbeeld ook een developer die een week ziek was, dus was er minder tijd dan voorzien te besteden.

We hebben als developers bij de introductie van Scrum collectief aangegeven niet over te willen werken enkel omdat een planning blijkbaar niet klopte. Aangezien dat sowieso ook geregeld niet klopte omdat de stories niet voldoende de lading dekten en er dus afhankelijkheden en complexiteit tijdens het werk opduikt, vonden we niet dat wij het kind van dergelijke rekeningen mochten zijn. Bovendien is het voor je productiviteit toch niet beter om lang door te gaan

Dus als wij een sprint niet halen en het ook niet mogelijk lijkt om op release-dag en/of impediment-dag nog de laatste puntjes op de i te zetten, dan gooien we er werk uit.
Het heeft uiteraard ook de consequentie dat als we een keer het werk overschat hebben, dat we dan alvast klussen waarvan we verwachten dat ze in een volgende iteratie gaan komen moeten doen.

'Een sprint niet halen' bestaat eigenlijk niet binnen scrum; aan het begin van een sprint geeft je aan welke stories je op wilt pakken ('commitment geven') op basis van de volgorde van openstaande stories op dat moment (welke de product owner aangeeft) en de gemiddelde velocity op dat moment (= het aantal punten van opgeleverde stories van de afgelopen X sprints). Als aan het einde van een sprint blijkt dat niet al die stories opgeleverd zijn is dat jammer, maar niet het eind van de wereld - immers, 'agile' (de naam zegt het al) geeft aan dat je flexibel moet zijn, en natuurlijk ook om moet kunnen gaan met zaken als uitval door ziekte.

Het enige wat je concreet kunt zeggen is dat de velocity in sprint X iets lager lag dan het gemiddelde ivm dringende zaken / ziekte. Dat pleur je in een grafiekje, en met dat grafiekje loop je naar degene die je mensen van het team haalt, zo van 'kijk pik, jouw schuld, niet weer doen'.

Ik weet niet wat je onder 'commitment geven' verstaat maar het is zeker niet de bedoeling om 'maar een beetje userstories op te gaan pakken' en wel zien waar het schip strand. De Product Owner geeft het team de verantwoordelijkheid om zelf te bepalen wat ze op gaan pakken, maar dan heeft de Product Owner wel het 'recht' om van het team te mogen verwachten dat ze er alles aan gaan doen om dit doel te halen. Anders had je ook de product owner kunnen laten bepalen welke userstories er aan het eind van de sprint af moeten zijn...

Als een sprint keer op keer niet wordt gehaald is dit niet onderdeel van scrum, maar een duidelijk signaal dat er iets goed mis is.

Klinkt allemaal heel herkenbaar! Blij om te zien dat wij niet de enige zijn waar het niet altijd lukt volgens de planning. Gebruiken jullie nog bepaalde tooling voor jullie stories/scrumproces? Wij (mis/ge)bruiken ons CRM om stories te documenteren. Deze worden daar van een prioriteit voorzien en tijdens de planning uitgeprint en op het scrumbord gehangen. tijdens de planning maken we deeltaken voor de stories op post-its en deze worden gedurende de sprint opgepakt...
Klinkt allemaal erg analoog maar het werkt wel aardig...

Wij gebruiken in principe JIRA, maar stiekem val ik altijd terug op good old trusty Excel

144 GB ram

Het is de bedoeling dat ie dmv virtualizatie meerdere dev-environments gaat draaien. En die hebben we liefst met reele data en zonder dat ze elkaar vervuilen. Dus dan krijg je per environment: varnish + apache, mysql, memcached, activemq en onze java-omgeving voor de pricewatch. Qua cpu zullen die allemaal niet zoveel doen, maar je kan niet altijd zomaar minder RAM toekennen.
En dan is 144GB uiteraard nog steeds vrij veel, maar als je 24-32GB per omgeving wilt alloceren kan je er dan dus in totaal 4 tot 6 kwijt; we hebben er momenteel sowieso al 3 die we erop willen.

Nu is dat veel, over 5-10 jaar heeft iedereen dat in z'n desktop zitten

Misschien heb ik wat gemist, maar sinds wanneer is TNet over op NoSQL? Of is dit voor de nieuwe Tweakers overhaul?

'Over' is een groot woord. Zoals je al eerder kon lezen, zetten we MongoDB in voor onder andere de opslag van sessies. Dat is dus al bijna 2 jaar zo

Heel netjes!
Wie staat er bovenaan met de Continuous Integration Game?

De stand:
crisp 119.0
pascal 101.0
Arjen 91.0
robert 59.0
koen 49.0
jeroen 46.0
marijn 33.0
laurent 25.0

Ideaal voor een bak welke virtuele servers aan gaat bieden.

Ben je lekker schaalbaar toch, als je wat servers extra nodig hebt

Ik hoop dat Tweakers de Nederlandse Ars Technica kan worden en het naast nieuws meer goede achtergrond en opinie stukken gaat publiceren.

100 GB cache. *jaloezie*

De Iteraties zijn toch om de 3 weken? Dan had er nu toch al weer een moeten zijn.

Niet op pasen in ieder geval.
Ik denk a.s maandag?

[Reactie gewijzigd door AW_Bos op 11 april 2012 17:03]