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?
In een vorig artikel heb ik drie handige principes voor gebruiksvriendelijke interfaces uiteengezet, maar hoe weet je nu of een GUI gebruiksvriendelijk is?
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 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”.
In deze blog wil ik Lotus Notes beschrijven zoals ik het 18 jaar geleden heb leren kennen. Hierbij wil ik me met name richten op een aantal zeer prettige eigenschappen van het product. Waarom? Omdat het al zo lang geleden is dat ik met Notes werkte en ik me wel eens afvraag waarom ik een aantal van die prettige aspecten zoveel jaren later in de dagelijkse praktijk moet missen. Het afgelopen jaar heb ik bij Finalist kennis mogen maken met modernere technieken, waarop de huidige webapplicaties zijn gebaseerd. Daar zitten toepassingen bij waar Notes niet geschikt voor zou zijn geweest, maar ook een aantal die ooit in zeer weinig tijd te realiseren waren en nu na zoveel jaren ineens weer raketwetenschap lijken. Waarom worden sterke kanten van Lotus Notes niet hergebruikt? Wellicht gebeurt dat ook wel maar gebeurt dat tot nu toe buiten mijn blikveld. Daar zou ik dan graag kennis van nemen. Vandaar ook de licht provocerende titel van deze blog. Mijn doel is om reacties uit te lokken.
Goed, duidelijk, onderhoudbaar en overdraagbaar CSS schrijven levert nog wel eens wat problemen op. Maar al te vaak ontstaan ellenlange CSS files met enorme hoeveelheid klassedeclaraties. Als je ooit een dergelijk project mag onderhouden of aanpassen, dan ben je nog niet jarig. In dit artikel geef ik aan hoe je structuur in je CSS kan aanbrengen. Object georienteerd werken is daar één van. Weet je eindelijk waarom een “class” een “class” heet.
Lees verder
Neal Ford is één van de weinige mensen/sprekers uit de Javawereld die vooral bezig is met het gebruiken van de techniek in plaats van het steggelen over triviale verschillen. Hij spreekt op Java, Ruby en .NET conferenties; werkt met zowel MS Windows als OSX en geeft voorbeelden in Java, Groovy, Ruby, Haskell en C#. Ik was dus erg benieuwd naar zijn recentste boek: The Productive Programmer.
Ik had ooit een voorkeur voor SOAP in plaats van REST vanwege:
- Ondersteuning door toolkits
- Afhandeling van foutmeldingen
- Definitiebestand voor methoden
- Gestandaardiseerd
Maar als gevolg van mijn groeiende aversie tegen onnodige complexiteit heb ik REST nader onderzocht en kwam ik erachter dat REST hier ook aan voldoet en meer!
Binnen de testwereld van Nederland is TMap een veelgebruikte methodiek om te testen. TMap heeft als doel om het testen gestructureerder te laten plaatsvinden. Hiervoor biedt het middelen om het testen een plaats te geven in het software ontwikkel proces en daarnaast middelen om het testen op zich te verbeteren. Maar wat heb je nou aan TMap als je niet test? En kan TMap ook problemen geven? Om deze vragen te beantwoorden, zal ik twee basisprincipes van TMap bespreken, waar ik ook het effect voor developers zal noemen.
Of drie principes voor betere gebruiksvriendelijkheid
Ik heb een magnetron thuis. Werkelijk een prachtig ding. Ik gebruik hem om mijn kip te ontdooien/per ongeluk te koken. Soms warm ik er een kliekje in op. En heel af en toe maak ik er diepvriesspinazie in warm. Om dat allemaal mogelijk te maken heeft mijn magnetron 21 knoppen! En een tweeëntwintigste om het deurtje te openen. Ik gebruik er zeven. Het lijkt wel of ik de ‘maximale potentie van mijn magnetron’ niet benut.
Lees verder
Ze bestaan al een paar jaar, en je ziet ze steeds vaker terugkomen. Fluent interfaces, ook wel interne DSL genoemd. Toch zie ik de techniek in de praktijk eigenlijk alleen worden gebruikt in frameworks. Jammer, want deze techniek kan eenvoudig worden toegepast om goed leesbare en op het domein toegespitste code te schrijven.
Lees verder
Rond de kerst mocht ik weer genieten van de The Royal Institution of Great Britain Christmas Lectures. Dit keer niet de meest recente versie maar de naar grote waarschijnlijkheid zeker niet minder interessante ‘Growing Up in the Universe’ lectures door Richard Dawkins, zoals uitgezonden door de BBC in 1991. Voor dit verhaal verder niet zo bijster relevant, behalve dan dat verschillende aspecten van evolutie worden behandeld. Daarnaast bevatte de aftiteling van de lectures een verwijzing naar wat eigenlijk wel een kleine revolutie mag worden genoemd. Of beter; juist de afwezigheid ervan; in 1991, een goede 15 jaar geleden, had de BBC nog geen website.
Als het gaat om evolutie of revolutie vinden veranderingen in ons vakgebied meestal op een evolutionele manier plaats. Hoewel vaak met de mond beleden is er niet vaak sprake van een echte revolutie.
Grote uitdagingen binnen software ontwikkeltrajecten zijn het binnen het budget blijven en het opleveren van een product dat voldoet aan de wens van de klant.
Softwareprojecten worden vaak aangeboden volgens het fixed price/fixed date principe. Als projectaanpak wordt vaak gekozen voor de watervalmethode [Waterfall]. Deze methode is vergelijkbaar met het bouwen van huizen. Eerst maak je een volledig afgebakend plan, vervolgens bouw je exact volgens de specificatie. Echter, in de jaren ‘80 werd al gezegd dat de vaak gemaakte vergelijking tussen het bouwen van huizen en het bouwen van software niet opgaat. Toch houden wij, de IT-leveranciers, samen met onze klanten deze illusie in stand door projecten aan te bieden volgens een watervalmodel met een vaste projectprijs en vast oplevermoment.
Omdat het model niet goed matcht met de software ontwikkeling leidt dit tot irritaties bij zowel de klant als de leverancier.
In dit artikel ga ik in op andere manieren om software ontwikkeling aan te pakken.
Migratie van oorspronkelijke data naar een nieuw CMS zou vroeg in het bouwproces moeten worden uitgevoerd om risico’s te verminderen. Tijdens elke herhaling van het project zou de migratie tool moeten worden verbeterd om de laatste kennis van zowel de oorspronkelijke omgeving als het nieuwe CMS te weerspiegelen.