Web Services hebben we het over het gedeelte van het internet dat begrepen kan worden, in tegenstelling tot het gewone web van web sites, door computer systemen. Er zijn verschillende manieren hoe je computer A over het internet met computer B kunt laten praten, en de RESTful wijze is er daar 1 van. In het boek RESTful Web Services, geschreven door Leonard Richardson en Sam Ruby (ISBN nr.: (978) 0596529260), wordt deze wijze uitgebreid behandeld.
Ten opzichte van andere manieren van communiceren over het internet is dat het uit gaat van de eenvoud van het HTTP protocol, dit in tegenstelling tot b.v. SOAP en RPC. Hoewel ook deze technologiën uiteindelijk wel over het HTTP gaan hebben deze technologiën een geheel andere benadering in de wijze waarin informatie op gevraagd en gemanipuleerd kan worden. Deze benadering is resource oriented, i.p.v. activity oriented. In plaats van de actie die veelal centraal staat …
Kort voorwoord: sommige ideeën moet op gebroed worden. Deze post lag er ook al een tijdje. Maar het is tijd voor publicatie. Misschien dat meer mensen er op door kunnen broeden. Het is geen 'af' product, geen implementatie handleiding, geen nieuwsfeitje of eigenaardigheidje, maar een idee, dat op z'n best inspireerd…
Alweer een tijdje geleden, maar helaas ben ik vergeten waar (verdorie, waar is mijn 'Google History' voor offline gebruik?), las ik een artikel over een ontwerper, of architect, die Nederland al geruime tijd had verlaten en momenteel werkzaam was in Japan. Een opvallend cultuurverschijnsel werd door hem opgemerkt: nemawashi.
Nemawashi verteld ons dat -ik hoop dat ik hier niet te kort door de bocht ben- in plaats van de directeur direct te overtuigen van je idee, dat je eerst de mensen onder de leidinggevende (je collega's) dient te overtuigen van de kwaliteiten van je plan. Wanneer je het idee daarna voorlegt aan de leidinggevende is de organisatie onder …
Hoewel het nog te vroeg is om iets zinnigs te zeggen over de door ons onlangs ingeslagen weg om interaction design en scrummen te combineren, blijven we natuurlijk lezen over de mogelijk betere methodes. Zodoende kwam ik een hoofdstuk in Mike Cohn's boek 'User Stories Applied' (2004, ISBN: 0321205685, hoofdstuk 16) tegen. In plaats van interaction design mee te nemen in de sprint (onze eerste opzet), of een sprint voor te laten lopen (waar we dus onlangs aan zijn begonnen) stelt hij iets anders voor: doe het interaction design voor dat je met het daadwerkelijke scrummen (lees: programmeren) begint, een idee eigenlijk afkomstig van Constantine and Lockwood (2002). Gesuggereerd wordt, alvorens aan het sprinten te beginnen, de volgende stappen te doorlopen:
Modelleer de gebruikersrollen (zoals gebruikelijk) Selecteer de belangrijkste user stories (interaction design specifiek(?)) Prioriteer deze met hoge, midden, en lage prioriteit (interaction design specifiek(?)) Ver…
Zoals ik in mijn eerdere post al aanstipte is er nog veel onduidelijkheid over hoe user experience (/interaction) design en agile development, en in specifiek SCRUM met elkaar samen gaan. Het beste is om er in zo'n geval gewoon mee te beginnen en te kijken of er ook inderdaad problemen zijn. Onlangs hebben we onze eerste aanpassing gemaakt (in andere woorden, we zijn tegen een probleem aangelopen): interaction design moet uit de sprint.
Hoewel het niet zwart op wit door de scrum methode wordt voorgeschreven, zijn er doorgaans de volgende kolommen op het 'scrumboard': backlog, todo, in progress, to test, en done. Een user story op de sprint backlog wordt in de todo kolom in stukjes geknipt tot werkbare stukjes (work items). Ons idee was dat interaction design daar tussenin zou passen, en dat de interaction designer de work items min of meer definieerde als pagina's in de applicatie. Een workitem (in de praktijk dus vaak een pagina) werd verplaatst naar de todo wanneer…
Gisteren schreven ze bij Computable een stukje over de mogelijke oorzaak van het falen van het Wia-project bij de uitkeringsinstantie UWV. Dit Wia-project werd geannuleerd na een investering van 87 miljoen euro. De conclusie van het Computable-artikel is dat een andere ontwerpmethodiek, nl. agile i.p.v. de traditionele waterval, dit falen had kunnen voorkomen. Michael Franken wijst in zijn blog bij Agile Holland er echter op dat met het huidige systeem van aanbestedingsprocedures zoals deze zijn opgelegd door de EU het eigenlijk niet mogelijk is om nog echt agile te werken; aanbestedingen vereisen nl. al uitvoerige uiteenzetting van hoe het eindproduct er uit moet komen te zien:
> Ten eerste zijn de eisen van een aanbesteding echt funest voor een project aangezien alle parameters van de Iron Triangle (tijd, resources, scope) worden dichtgetimmerd.
Agile development maakt het, met zijn iteratieve karakter, goed mogelijk om aanpassingen op een later moment door te voe…
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .