Desarrollo Dirigido por Ejemplos Concretar   en lugar de   Abstraer Carlos Blé Jurado Marzo 2010 – Universitat Jaume I www...
Nada más salir de la facultad... “ ¡Podemos  programar  lo que sea!!” “ ¡Despues  de la carrera saco  adelante cualquier  ...
Y va la experiencia y dice... “ así que...  podeis hacer lo que  sea...” “ ¡y quien lo  va a  mantener !!!!!! ”
No te tortures con código imposible ni  se lo hagas a tus compañeros No juegues con  el dinero del  cliente. Dale  solucio...
¿Y eso como se hace? <ul>“ ...pero, no veas que broncas tienen con los usuarios...” </ul>“ ...tengo un colega en una empre...
¡¡¡¡¡¡¡ AL REVES !!!!!!!! A lo mejor es que los estamos haciendo...
Afrontemos los problemas del software <ul><li>Tiene  defectos (malditos bugs)
No  hace lo que el cliente  necesita  que haga   (hace otros rollitos que están que te cagas y tal)
Es muy caro de  mantener  y (más vale que el cliente evolucionar   no  pida cambios) </li></ul>
Los métodos tradicionales no están resultando eficajes para evitarlos <ul><li>Escuchar   (o peor, leer)
Transcribir  (volcar los requisitos en 500 páginas)
Abstraer   (intentar resumir las 500 páginas en conceptos)
Modelar  (diagramas de clases, etc)
Implementar  (a picar código)
Probar   (tres días usando la app a mano)
Entregar   (cobrar y salir pitando) </li></ul>
En realidad hay aun más problemas El mundo de la informática es complicado: <ul><li>Os recomiendo:  Informática Profesiona...
Pero en el lado técnico, al menos, podemos ser ágiles <ul><li>for i in iteration: </li><ul><li>Escuchar     (de primera ma...
Transcribir     (escribimos historias de usuario)
Concretar     (escribir criterios/tests    de aceptación)
Probar/Implementar    (primero la prueba, ¡cobarde!)
Upcoming SlideShare
Loading in …5
×

Charla Tdd Uji 032010

811 views
747 views

Published on

Charla sobre Test Driven Development en la Universidad Jaume I de Castellón en Marzo de 2010

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
811
On SlideShare
0
From Embeds
0
Number of Embeds
226
Actions
Shares
0
Downloads
19
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Charla Tdd Uji 032010

  1. 1. Desarrollo Dirigido por Ejemplos Concretar en lugar de Abstraer Carlos Blé Jurado Marzo 2010 – Universitat Jaume I www.carlosble.com
  2. 2. Nada más salir de la facultad... “ ¡Podemos programar lo que sea!!” “ ¡Despues de la carrera saco adelante cualquier cosa!!!!!!”
  3. 3. Y va la experiencia y dice... “ así que... podeis hacer lo que sea...” “ ¡y quien lo va a mantener !!!!!! ”
  4. 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. 5. ¿Y eso como se hace? <ul>“ ...pero, no veas que broncas tienen con los usuarios...” </ul>“ ...tengo un colega en una empresa donde saben un montón de ingeniería del software...”
  6. 6. ¡¡¡¡¡¡¡ AL REVES !!!!!!!! A lo mejor es que los estamos haciendo...
  7. 7. Afrontemos los problemas del software <ul><li>Tiene defectos (malditos bugs)
  8. 8. No hace lo que el cliente necesita que haga (hace otros rollitos que están que te cagas y tal)
  9. 9. Es muy caro de mantener y (más vale que el cliente evolucionar no pida cambios) </li></ul>
  10. 10. Los métodos tradicionales no están resultando eficajes para evitarlos <ul><li>Escuchar (o peor, leer)
  11. 11. Transcribir (volcar los requisitos en 500 páginas)
  12. 12. Abstraer (intentar resumir las 500 páginas en conceptos)
  13. 13. Modelar (diagramas de clases, etc)
  14. 14. Implementar (a picar código)
  15. 15. Probar (tres días usando la app a mano)
  16. 16. Entregar (cobrar y salir pitando) </li></ul>
  17. 17. En realidad hay aun más problemas El mundo de la informática es complicado: <ul><li>Os recomiendo: Informática Profesional de Roberto Canales </li></ul>
  18. 18. Pero en el lado técnico, al menos, podemos ser ágiles <ul><li>for i in iteration: </li><ul><li>Escuchar (de primera mano, del cliente)
  19. 19. Transcribir (escribimos historias de usuario)
  20. 20. Concretar (escribir criterios/tests de aceptación)
  21. 21. Probar/Implementar (primero la prueba, ¡cobarde!)
  22. 22. Entregar (una entrega cada 3 semanas y volver al inicio) </li></ul></ul>
  23. 23. La rueda ágil
  24. 24. Concretando: TDD
  25. 25. ATDD + TDD
  26. 26. ATDD <ul><li>Historias de Usuario que contienen una lista de ejemplos.
  27. 27. Los ejemplos son el puente que une a técnicos y usuarios/clientes
  28. 28. Eliminan la ambigüedad </li></ul><ul><li>Escaner de un tpv: </li></ul>
  29. 29. Ejemplo de ejemplo :-) 40x20+8x20x1.5+8x20x2 Ejemplo de ejemplo :-)
  30. 30. <ul><li>Ya sabemos lo que quiere el cliente.
  31. 31. Ahora vamos a pensar cómo queremos diseñar e implementar el software
  32. 32. Y vamos a implementarlo </li></ul>Escribimos un test (JUnit, NUnit, PyUnit...) Lo hacemos funcionar lo antes posible (implementamos el código de producción) Refactorizamos el código
  33. 33. Un test unitario
  34. 34. Cada cosa tiene su ámbito ATDD – ¿Qué quiere el cliente? TDD – ¿Cómo lo implementamos?
  35. 35. ¿Qué ventajas tiene A/TDD? <ul><li>Tenemos un producto (parcial) en producción desde las primeras semanas
  36. 36. No se implementa lo que no será usado (YAGNI)
  37. 37. Minimizamos el número de defectos
  38. 38. Conseguimos código más fácil de mantener
  39. 39. Código preparado para cambiar
  40. 40. Aumenta la confianza del equipo
  41. 41. Aumenta la productividad
  42. 42. Detectamos antes las prioridades del cliente </li></ul>
  43. 43. ¿Cómo aprender todo esto? Hay un tipo por ahí que imparte cursos Hay un libro en castellano sobre el tema Hay una comunidad de habla hispana Hay toneladas de herramientas libres ¿Tienes ganas? Just do it!!!
  44. 44. dirigido Por Tests .com Agile-spain.com carlosble.com Tambien estamos en Facebook!:

×