Aw agiles2010 - dppt 1.1

886 views

Published on

Desarrollo Agil de Productos, conferencia #Agiles2010 Lima-Peru

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
886
On SlideShare
0
From Embeds
0
Number of Embeds
102
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Aw agiles2010 - dppt 1.1

  1. 1. Desarrollo Ágil de ProductosUna Perspectiva Técnica<br />Juan Carlos Vergara<br />
  2. 2. Agenda<br /><ul><li>Introducción
  3. 3. Adopción de Agile para creación de productos
  4. 4. Desarrollo incremental/evolutivo
  5. 5. Funcionalidad mínima útil
  6. 6. Diseño guiado por pruebas
  7. 7. Algunas heurísticas útiles</li></li></ul><li>Introducción<br />Compartir la experiencia técnica de aplicar metodologías ágiles al desarrollo de un producto.<br />Como obtener sistemas orientados a objetos que permitan agregar funcionalidad incrementalmente.<br />
  8. 8. Introducción<br />Se uso un estilo TDD iniciado en Londres a comienzos de los 2000 (Steve Freeman & Nat Pryce) caracterizada por el enfoque end-to-end y por el énfasis especial en la comunicación entre objetos.<br />
  9. 9. Por qué adoptamos agile?<br />“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”<br />
  10. 10. Por qué adoptamos agile?<br /><ul><li>Es posible tener rápidamente una versión funcional útil del producto.
  11. 11. No permite entregas incrementales de funcionalidad con periodos que van desde un par de semanas hasta un par de meses.</li></li></ul><li>Por qué adoptamos agile?<br />Esto es posible debido a la alta productividad vista en equipos ágiles que a su vez es resultado del énfasis en la calidad interna y externa del producto promovida en los proyectos ágiles.<br />
  12. 12. Desarrollo del Producto<br /><ul><li>Product Owner
  13. 13. Visión del Producto
  14. 14. Plan de Negocio
  15. 15. Los Ingresos
  16. 16. Road Map
  17. 17. Release Plan
  18. 18. Product Backlog</li></li></ul><li>Características del Proceso<br />
  19. 19. Desarrollo Incremental/Evolutivo<br />Dividir el trabajo en periodos fijos, en cada uno de los cuales se diseña, implementa, prueba y despliega funcionalidad.<br />El desarrollo incremental construye el sistema característica por característica.<br />El desarrollo iterativo progresivamente refina la implementación hasta que sea lo suficientemente buena en respuesta a retroalimentación constante..<br />
  20. 20. Retroalimentación<br />Agile nos permite aplicar ciclos de retroalimentación organizando nuestros proyectos en ciclos anidados que duran desde segundos a meses.<br />
  21. 21. Retroalimentación<br />
  22. 22. Retroalimentación<br /><ul><li>Cada ciclo expone retroalimentación empírica de tal manera que el equipo puede detectar errores, malentendidos, conceptos erróneos.
  23. 23. Cuanto más efectiva es la implementación estos problemas se solucionan más rápidamente.</li></li></ul><li>Calidad<br /><ul><li>Los ciclos más internos están enfocados en el detalle técnico.
  24. 24. Los ciclos más externos están enfocados en la organización y el equipo.</li></ul>El proceso de pruebas ya no es una actividad final de verificación sino que va a la par con las tareas de desarrollo.<br />
  25. 25. División Funcional<br />Una técnica fundamental del desarrollo incremental es dividir la funcionalidad de tal manera que se pueda construir característica por característica.<br />
  26. 26. División Funcional<br />Cada característica a implementar se denominada un “slice” y debe involucrar todas las partes relevantes del sistema.<br />
  27. 27. Slices<br />Cada “slice” debe ser significativo y lo suficientemente concreto para determinar cuando estará terminado<br />Y lo suficientemente pequeño para estar enfocado en un único concepto y sea implementado rápidamente.<br />
  28. 28. Automatización<br /><ul><li>Pruebas manuales son demasiado lentas para tener ciclos de retroalimentación óptimos que nos permitan entregar un producto de calidad.</li></ul>Debemos automatizar para reducir costo y tiempo en construir, modificar, desplegar y probar end-to-end versiones del sistema.<br />
  29. 29. Niveles de Pruebas<br />Aceptación: Trabaja el sistema en su conjunto?<br />Integración: Nuestro código trabaja contra código que no podemos cambiar?<br />Unitario: Nuestros objetos hacen lo correcto, son convenientes para trabajar?<br />
  30. 30. Niveles de Pruebas<br />Separar las pruebas que miden progreso de aquellas que capturan regresiones.<br />
  31. 31. Pruebas End-to-End<br />Ejercitan al sistema desde el exterior a través de sus interfaces externas.<br />Esto puede significar bastante esfuerzo en lograrse, pero se tiene que hacer de todas maneras durante el ciclo de vida del software.<br />Con una combinación adecuada de automatización y pruebas end-to-end nuestro producto puede estar siempre integrado y listo para el despliegue.<br />
  32. 32. ¿Como iniciamos la Implementación? <br />
  33. 33. Walking Skeleton <br />Es la implementación de la funcionalidad mínima útil que pueda ser construida, desplegada y probada end-to-end.<br />Luego construiremos incrementalmente el producto slice por slice.<br />
  34. 34. Walking Skeleton <br />El primer test end-to-end ayuda a visualizar el contexto del proyecto para trazar el panorama de su solución y a tomar decisiones esenciales antes de escribir algún código.<br />Pasos para identificar una característica mínima útil:<br />http://blog.jbrains.ca/permalink/three-steps-to-a-useful-minimal-feature<br />
  35. 35. ¿Cómo aseguramos la calidad de la implementación a medida que construimos incrementalmente? <br />
  36. 36. Diseño Guiado por Pruebas<br />
  37. 37. Diseño Guiado por Pruebas<br />Como usamos las pruebas como guía para obtener sistemas orientados a objetos?<br />The big idea is “messaging” […] The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.<br />—Alan Key<br />
  38. 38. Una red de objetos<br />Que colaboran entre si…<br />
  39. 39. Diseño Guiado por Pruebas<br />El sistema es construido creando y ensamblando objetos de tal manera que puedan enviarse mensajes entre sí.<br />El comportamiento del sistema es resultado de ésta composición.<br />Esto permite cambiar el comportamiento agregando y removiendo instancias o ensamblando diversas combinaciones.<br />
  40. 40. Si escribimos pruebas durante todo el proceso de desarrollo podemos crear un red de seguridad que nos dará confianza para realizar cambios. <br />
  41. 41. Test Driven Development<br /><ul><li>Escribir un test.
  42. 42. Escribir código a fin de hacerlo funcionar.
  43. 43. Refactorizar el código a fin de que sea únicamente una implementación de la característica probada.
  44. 44. Repita.</li></li></ul><li>Test Driven Development<br />Como detectamos:<br /><ul><li>Cuando empezar a escribir código.
  45. 45. Cuando detenernos.
  46. 46. Como estructuramos el código.</li></li></ul><li>Test Driven Development<br />Nuestras pruebas pueden carecer de propósito y perspectiva y es complicado saber cuándo terminar de escribir las pruebas.<br />Probar código mal diseñado es complicado.<br />
  47. 47. Acceptance Test Driven Development<br />Están dirigidas por las historias de usuario y el diseño conceptual, es todo muy sistemático.<br />Se puede saber con precisión cuando se han terminado de implementar correctamente.<br />
  48. 48. Acceptance Test Driven Development<br />
  49. 49. Acceptance Test Driven Development<br />Empezamos construyendo una prueba de aceptación que ejercite la funcionalidad que necesitamos implementar.<br />Mientras no pase la prueba de aceptación se asume que el sistema todavía no implementa esa característica.<br />
  50. 50. Acceptance Test Driven Development<br />El ciclo externo es una medida demostrable de progreso y el conjunto de pruebas nos protege contra fallas de regresión cuando cambiemos el sistema.<br />
  51. 51. Cómolaspruebas de aceptaciónpuedenguiar el desarrollo?<br />
  52. 52. Outside-In Development from the Inputs to the Outputs<br />
  53. 53. http://www.natpryce.com/articles/000772.html<br />
  54. 54. Se inicia con un evento externo que ejercite el comportamiento que queremos implementar, éste se propaga a través del código objeto por objeto, hasta alcanzar un efecto visible.<br />En los límites de nuestro sistema, necesitamos escribir uno o más objetos para manejar esos eventos. <br />A medida que vamos avanzando con la implementación descubriremos que esos objetos necesitan servicios de soporte de otros objetos del sistema para cumplir sus responsabilidades.<br />
  55. 55.
  56. 56. De esta manera trazamos nuestro camino a través del sistema:<br /><ul><li>Desde los objetos que reciben los eventos externos,
  57. 57. A las capas intermedias, pasando por el modelo del dominio central
  58. 58. Y luego propagándose hacía otros objetos limite que generen alguna respuesta externamente visible.</li></li></ul><li>Cómo se relacionan los objetos?<br />
  59. 59. Objetos se relacionan a través de roles<br />
  60. 60. Relaciones entre objetos<br />En este esquema basado en la comunicación debemos diseñar la interface de un colaborador basándonos en su uso pretendido antes que en su implementación.<br />Esto lleva a un proceso de descubrimiento donde las interfaces de los objetos colaboradores son traídas a la existencia basadas en los requerimientos inmediatos dirigidos por necesidad.<br />
  61. 61. Representaciones de Relaciones<br />En lenguajes modernos como Java se representan las relaciones como interfaces.<br />Esto nos permite modelar las interacciones entre objetos sin necesidad de contar con una implementación concreta.<br />
  62. 62. Si no existen implementaciones concretas, como validamos en nuestras pruebas las interacciones entre los objetos?<br />
  63. 63.
  64. 64. Mock Objects<br />Las pruebas usando mock objects definen un conjunto de restricciones que especifican que mensajes los objetos pueden enviar y la forma en que los mensajes deben ser enviados.<br />
  65. 65. Mock Objects<br />Verifican interacciones entre objetos:<br /><ul><li>Que métodos son llamados (o no llamados)
  66. 66. Cuantas veces fueron llamados
  67. 67. En que orden fueron llamados.
  68. 68. Cuales son los parámetros correctos?</li></li></ul><li>Como se verifican las interacciones?<br />
  69. 69. Protocolos de Comunicación<br />Una interface define si dos componentes pueden relacionarse entre sí<br />Un protocolo describe si dos objetos pueden trabajar juntos.<br />
  70. 70. Protocolos de Comunicación<br />Los mock objects nos permiten visualizar éstos protocolos.<br />Son una herramienta tanto para descubrir los roles que desempeñan los objetos así como para describir sus interacciones cuando revisamos el código.<br />
  71. 71.
  72. 72. Importancia de los diagnósticos<br />Siempre debemos verificar que el test falle “correctamente” revisando los mensajes de falla.<br />Si la prueba falla de una manera inesperada podemos concluir que hemos malentendido algo o el código no está correctamente terminado.<br />
  73. 73. Cuando tengamos la falla “correcta” verificaremos que el diagnostico será útil si el código falla posteriormente.<br />
  74. 74. Algunas Heurísticas que nos ayudarán a empezar a aplicar este enfoque<br />
  75. 75.
  76. 76. Implementación<br />Cuando iniciamos una nueva área de codificación podemos suspender temporalmente nuestro sentido de diseño y escribir código sin imponerse mucha estructura. <br />Luego cuando encontremos que nuestro código se vuelve bastante complejo de entender debemos empezar a mejorarlo. <br />
  77. 77. Refactoring<br />El objetivo es mejorar el código de tal manera que represente mejor las características que implementa haciéndolo más mantenible y para facilitar la adición de nueva funcionalidad. <br />
  78. 78. SRP<br />Cada objeto debe tener una sola responsabilidad claramente definida.<br />Nuestra heurística espoder describir lo que hace elobjeto sin usar conjunciones (y / o).<br />Cuando agregamos comportamiento a un sistema este principio nos ayuda a decidir si debemos extender un objeto existente o si debemos crear un nuevo servicio a ser llamado.<br />
  79. 79. Descubriendo Roles<br />Una vez detectada una violación a SRP se debe descubrir algún colaborador que lleve a cabo el rol necesitado moviendo la implementación si el código ya existe.<br />
  80. 80. Creación de Nuevos Objetos<br /><ul><li>Breaking Out
  81. 81. Bundling Up
  82. 82. Budding Off</li></li></ul><li>Internals vs. Peers<br />A medida que organizamos nuestro sistema, debemos decidir que va dentro o fuera de cada objeto.<br />Esta decisión es importante porque determina que tan fácil de usar es un objeto y como contribuye a la calidad interna del sistema.<br />
  83. 83. Internals vs. Peers<br />Si exponemos lo interno de un objeto a través de su API, sus clientes pueden terminar haciendo parte de su trabajo.<br />Podemos tener comportamiento repartido en demasiados objetos (que estarían acoplados) incrementando el costo de mantenimiento debido a los cambios ahora estarán repartidos en el código.<br />
  84. 84. Object Peer Stereotypes<br />Ahora tenemos objetos con responsabilidades únicas que se comunican con sus colegas a través de mensajes basados en APIsclaros, pero que tienen que decirse uno al otro?<br /><ul><li>Dependencias
  85. 85. Notificaciones
  86. 86. Ajustes</li></li></ul><li>Object Peer Stereotypes<br />Estos estereotipos son solo heurísticas que ayudan a pensar sobre el diseño no reglas difíciles de seguir, por lo que no debemos obsesionarnos en encontrar la clasificación correcta.<br /><ul><li>Dependencias deben ser pasadas en el constructor.
  87. 87. Notificaciones y Ajustes son opcionales y pueden ser manejados con defaults.</li></li></ul><li>Objetos de Valor<br />Son objetos inmutables son simples y no tienen una identidad significativa, los objetos tiene estado, tiene una identidad y relaciones con otros objetos.<br />Debemos definir tipos para representar conceptos de valor en el dominio, aun cuando ellos no hagan mucho. Esto ayuda a crear un modelo del dominio más consistente y que es más auto descriptivo.<br />
  88. 88.
  89. 89. Afinamiento de Código Existente<br />
  90. 90. Arquitectura Emergente<br />Como identificar diseño oculto en código existente<br />Composed Method & SLAP<br />http://www.ibm.com/developerworks/java/library/j-eaed4.html<br />Métricas y visualizaciones ayudan a identificar partes importantes de nuestro código permitiendo extraerlos como elementos de diseño de primera clase.<br />Recolección de Patrones Idiomáticos<br />http://www.ibm.com/developerworks/java/library/j-eaed9/index.html<br />
  91. 91. Integración con Infraestructura<br />
  92. 92.
  93. 93. Referencias<br />
  94. 94.
  95. 95. Gracias<br />

×