Extreme Prototyping
De methode van Extreme Programming wordt al bijna een decennium aanbevolen voor het ontwikkelen van applicaties in complexe omgevingen met snel veranderende eisen. De genoemde voordelen: korte release cycles leveren steeds de optimale business value. Mocht het project niet tot het oorspronkelijk gestelde doel kunnen komen, dan is in ieder geval steeds de maximaal haalbare waarde gerealiseerd.
Het ontwikkelen van een (web) applicatie in een complexe omgeving wordt over het algemeen met een heel systematische project management methode aangepakt. Daarbij zit de complexiteit vooral in de vele, soms verschillende belangen van business, klant of gebuiker, marketing, communicatie, operatie en de verschillende IT afdelingen.
Traditioneel gaat een dergelijk ontwikkelproces uit van het aanvankelijke product idee, waarbij een programma van eisen wordt opgesteld, verder uitgewerkt en vervolgens in stappen door verschillende disciplines gerealiseerd – tot de feitelijke versie wordt opgeleverd. Ergens aan het begin van dit traject is een belangrijke rol weggelegd voor User Interaction Design, waarbij de eisen vertaald worden in een ontwerp. Dit ontwerp heeft nog het karakter van een wireframe, het dient als eerste model waarop getoetst kan worden of aan de eisen voldaan wordt. Vaak wordt in dit stadium de eerste terugkoppling vanuit de business verkregen en worden er tests met focus groepen gehouden.
Het probleem met deze aanpak is dat het vastleggen van de eisen tot en met het definitieve wireframe een lang proces is. Tussentijds is er niet veel bijsturing mogelijk doordat er simpelweg nog geen concreet beeld van het eindresultaat is.
Net zoals Extreme Programming een antwoord wil zijn op het probleem van lange ontwikkel trajecten in een veranderende omgeving, zo kan Extreme Prototyping een oplossing bieden voor het stapsgewijs ontwikkelen van het interactie-ontwerp.
Een gedetailleerde methode staat beschreven in Reshaping IT Project Delivery Through Extreme Prototyping (ONJava.com). Bij dit proces wordt als het ware een aantal ontwikkelfasen in elkaar geschoven, waarbij het concrete prototype van de applicatie steeds de centrale referentie is voor alle betrokkenen. De auteur, Satya Komatineni, onderscheidt vier fasen:
- Static Prototype phase
- Static Prototype
- Master or background pages
- CSS, JavaScript
- Business rules, use-cases
- Extended Static Prototype phase
- All of the above
- Logical data model to support the screens
- Dynamic prototype (or Extreme Prototype phase)
- UI recoded/adjusted for the chosen web framework
- Working executable code
- Field validations work
- Navigation of screens will work
- Service signatures solidified
- A complete working UI with no implementation behind
- Service Implementation Phase
- API document
- Each service implemented by calling databases or other resources
- Integration
Hiermee is productieve betrokkenheid van technisch (implementatie) specialisten al vanaf het begin van het project mogelijk. Verder hebben opdrachtgever en gebruikers in ieder stadium maximaal inzicht in wat het werkelijke product aan het worden is. In de praktijk zoals ik die ken, biedt een dergelijk prototype oneindig meer waarde dan een uitgebreid, maar puur tekstueel specificatie document. Laat de specificaties maar blijven waarvoor ze dienen: als randvoorwaarden voor de specialisten die het prototype uitwerken.
I’ve put together a microsummary generator repository at http://userstyles.org/livetitle/ . I’m interested in providing an interface to microsummary extensions. For example, your extension could allow the generators created by your users to be easily posted to my site. If you’re interested in collaborating, mail me!