El documento describe el desarrollo dirigido por ejemplos (ATDD) y pruebas unitarias (TDD) como una forma ágil de desarrollar software que minimiza defectos y mejora la productividad. Se propone escuchar al cliente para entender sus necesidades a través de ejemplos concretos, luego escribir pruebas unitarias y código para satisfacer esos ejemplos de manera iterativa. Esto garantiza que se implementan sólo las funcionalidades necesarias y que el código está preparado para cambios.

1. Desarrollo Dirigido por Ejemplos Concretar en lugar de Abstraer Carlos Blé Jurado Marzo 2010 – Universitat Jaume I www.carlosble.com

2. Nada más salir de la facultad... “ ¡Podemos programar lo que sea!!” “ ¡Despues de la carrera saco adelante cualquier cosa!!!!!!”

3. Y va la experiencia y dice... “ así que... podeis hacer lo que sea...” “ ¡y quien lo va a mantener !!!!!! ”

4. No te tortures con código imposible ni se lo hagas a tus compañeros No juegues con el dinero del cliente. Dale soluciones, no más problemas Tranquilo majete: haz las cosas bien

5. ¿Y eso como se hace? “ ...pero, no veas que broncas tienen con los usuarios...” “ ...tengo un colega en una empresa donde saben un montón de ingeniería del software...”

6. ¡¡¡¡¡¡¡ AL REVES !!!!!!!! A lo mejor es que los estamos haciendo...

7. Afrontemos los problemas del software Tiene defectos (malditos bugs)

8. No hace lo que el cliente necesita que haga (hace otros rollitos que están que te cagas y tal)

9. Es muy caro de mantener y (más vale que el cliente evolucionar no pida cambios)

10. Los métodos tradicionales no están resultando eficajes para evitarlos Escuchar (o peor, leer)

11. Transcribir (volcar los requisitos en 500 páginas)

12. Abstraer (intentar resumir las 500 páginas en conceptos)

13. Modelar (diagramas de clases, etc)

14. Implementar (a picar código)

15. Probar (tres días usando la app a mano)

16. Entregar (cobrar y salir pitando)

17. En realidad hay aun más problemas El mundo de la informática es complicado: Os recomiendo: Informática Profesional de Roberto Canales

18. Pero en el lado técnico, al menos, podemos ser ágiles for i in iteration: Escuchar (de primera mano, del cliente)

19. Transcribir (escribimos historias de usuario)

20. Concretar (escribir criterios/tests de aceptación)

21. Probar/Implementar (primero la prueba, ¡cobarde!)