Getting Real [Dutch]

“Getting Real” The smarter, faster, easier way to build a succesful web application http://www.nielsbruin.nl/blog

Inhoud • Waarom een ontwikkelmethode • Waarom “Getting Real” • Uitleg “Getting Real” • “Getting Real” in de praktijk • Vragen en informatie

Waarom een goede ontwikkel-methode • Wie heeft zijn product op tijd afgekregen? • Wie gebruikt het functioneel ontwerp na het maken? • Lijkt het product op wat je hebt bedacht? • Wie betrekt gebruikers en de klant bij het ontwikkel-proces?

Waterval model

Coding Cowboy

Deze manieren zorgen voor een traag en risicoloos proces. Resultaat is opgeblazen en onduidelijke applicaties die overlopen van middelmatigheid

Waarom “Getting Real” • Betere resultaten, omdat het je dwingt om te gaan met echte problemen, in plaats van ideeën te genereren over deze problemen. Het dwingt je om te gaan met realiteit • Ophouden met functionele ontwerpen/speciﬁcaties en andere tijdelijke documentatie, maar echte schermen ontwerpen. Functionele ontwerpen zijn maar een illusie • Past goed bij web-applicaties op het web. Real time updates zijn nu een feit, je kunt web-applicaties contant blijven verbeteren

Wat is “Getting Real” • Bouw minder • Blijf klein • Vorm een visie • Features selecteren • Maak snel iets werkend • Team • Ontwerp eerst een interface • Minder code • Geen functionele speciﬁcatie

Bouw minder • Minder features dan je concurrenten • Maak applicaties voor jezelf • Beperkingen dwingen creativiteit af • Leg de tijd vast, en schaal je applicatie bij te weinig tijd • Beter een half product, dan een halfslachtig product • Heb een vijand, volg nooit de leider

Blijf klein • Hoe kleiner je bent, des te makkelijker de verandering • Makkelijker inspelen op nieuwe technologieën • Begrenzingen zorgen voor creatieve oplossingen • Houd het team klein (communicatie) • Kleine bedrijven zijn persoonlijker en staan dichter bij de klant

Vorm een visie • Onderscheid jezelf • Begin bij de grote lijnen, en bewaar de details voor later • Het is pas een probleem, als het een probleem is • Beperk je doelgroep • Baseer je applicatie op visie, niet features

Features selecteren • Beter een half product dan een halfslachtig product • Zorg dat je alleen features overhoud die essentieel zijn • Wees kritisch op welke feature je toelaat • Zeg vaker “Nee” • Features leiden tot meer features

Maak snel iets werkend • Ontwerp schermen, gebruik ze, analyseer ze en begin opnieuw. • Streef niet naar perfectie • Brainstorm -> Schetsen -> Prototype -> Coderen • Geen voorkeuren / preferences • Fouten maken mag • Echte feedback door beta releases • Breek project in stukjes

Team • Minder vergaderingen • Minder mensen bij vergadering • Motivatie door kleine releases

Ontwerp eerst een interface • Ontwerp de interface VOOR het programmeren • Schetsen en prototypes zijn goedkoper en makkelijker aan te passen • “What you see Is what you get” • Ontwerp van de centrum naar buiten (epicentrum-ontwerp) • Ontwerp voor normaal, leeg en error • 1 interface voor bezoeker en admin • Geen “Lorem Ipsum” maar echte tekst

Minder code • Zorg dat je code zo simpel mogelijk is (elke extra regel code, zal je applicatie exponentieel ingewikkelder maken) • There is No CODE that is more ﬂexible than NO code • Zet je code “open” (RSS, Webservices)

Geen functionele specificatie • Functionele specificaties zijn een fantasie • Functionele specificaties leiden tot een illusie van overeenstemming • Functionele specificaties dwingen je beslissingen te nemen wanneer je over de minste informatie beschikt • Functionele specificaties leiden tot “feature overload” • Functionele specificaties zijn niet flexibel

Geen functionele specificatie (2) • Maak een korte beschrijving van 1 A4 over wat de applicatie moet doen. • Schetsen, prototypes en werkende demo’s als alternatief • Iedereen ziet hetzelfde scherm • Makkelijk testen van de gebruikerservaring • Echt waar, je zult nooit achteraf een functioneel ontwerp gaan lezen

“Getting Real” in de praktijk • “Ik moet een functioneel ontwerp maken van de docent” • Maak gebruik van schetsen en prototypes (dit kan ook in makkelijk in Flex of Fireworks) • Laat je prototypes regelmatig testen door gebruikers en de klant • Verdeel het proces in kleine delen (max 1 week) en stel deadlines • Zie andere projectleden als collega’s, deel informatie en geef feedback • Zet je applicatie zo snel mogelijk online, toon je ideeën op je blog

Hoe denken jullie erover?

Vragen en informatie • http://gettingreal.37signals.com • http://www.nielsbruin.nl/blog • http://en.wikipedia.org/wiki/Agile_software_development • http://en.wikipedia.org/wiki/Waterfall_model • http://37signals.com/svn

http://www.nielsbruin.nl	89
http://www.oldenhuizing.com	11
http://www.slideshare.net	10
http://static.slideshare.net	1

Getting Real [Dutch]

by nielsbruin on Feb 21, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 111

Statistics

Getting Real [Dutch] — Presentation Transcript