Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Getting Real [Dutch]

3,704 views

Published on

Presentation about the "Getting Real" method of 37signals

Published in: Technology
  • Be the first to comment

Getting Real [Dutch]

  1. 1. “Getting Real” The smarter, faster, easier way to build a succesful web application http://www.nielsbruin.nl/blog
  2. 2. Inhoud • Waarom een ontwikkelmethode • Waarom “Getting Real” • Uitleg “Getting Real” • “Getting Real” in de praktijk • Vragen en informatie
  3. 3. 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?
  4. 4. Waterval model
  5. 5. Coding Cowboy
  6. 6. Deze manieren zorgen voor een traag en risicoloos proces. Resultaat is opgeblazen en onduidelijke applicaties die overlopen van middelmatigheid
  7. 7. 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/specificaties 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
  8. 8. 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 specificatie
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. Team • Minder vergaderingen • Minder mensen bij vergadering • Motivatie door kleine releases
  15. 15. 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
  16. 16. 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 flexible than NO code • Zet je code “open” (RSS, Webservices)
  17. 17. 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
  18. 18. 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
  19. 19. “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
  20. 20. Hoe denken jullie erover?
  21. 21. 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

×