Presentation about the "Getting Real" method of 37signals

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

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

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?

5. Waterval model

6. Coding Cowboy

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

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

16. 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

17. 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)

18. 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

19. 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

20. “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

21. Hoe denken jullie
erover?

22. 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