Módulo 4. Desarrollador ágil

1. http://anahatacoaching.files.wordpress.com/2011/07/zen-stones-620x387.jpg Agile y Scrum Bienvenidos al mundo de la Agilidad El Desarrollador Ágil Johnny Ordóñez

2. Soy desarrollador ágil…y ahora qué?

3. Hacer lo correcto Hacerlo correctamente Hacerlo frecuentementeAgile Desarrollo de Software ágil

4. Product Owner Hacer lo correcto Hacerlo correctamente Hacerlo frecuentemente Equipo Scrum Master Scrum Desarrollo de Software ágil Usted está aquí

5. Responsabilidades del Team Member • Comprender los principios del desarrollo ágil • Asegurar la excelencia técnica • Aplicar buenas prácticas para la programación • Probar el código • Permitir el desarrollo evolutivo • Reducir la deuda técnica • Trabajar colaborativamente

7. Cuál es la diferencia entre el desarrollo tradicional y el Desarrollo ágil?

8. Cuál es la diferencia entre el desarrollo tradicional y el Desarrollo ágil?

9. 4 444 : Documents Documents Unverified Code Software

10. Hagamos un sistema de facturación?

11. 1 2 3 4 5

12. features FacturaciónBasedeDatos AccesoaaDatos Negocio Transporte Servicios Agentes UI Desarrollo En el desarrollo tradicional se avanza a través de la completitud del módulo o componente anterior.

13. Qué es Scrum? Scrum es un marco de trabajo para la gestión y desarrollo de productos complejos, en un proceso iterativo e incremental utilizado comúnmente en entornos donde existe gran incertidumbre. “ ” Fuente: Introducción a Agilidad y Scrum: http://twileshare.com/uploads/EFF46d01.pdf Scrum: http://es.wikipedia.org/wiki/Scrum

14. Qué es Scrum? Scrum es un marco de trabajo para la gestión y desarrollo de productos complejos, en un proceso iterativo e incremental utilizado comúnmente en entornos donde existe gran incertidumbre. “ ” Fuente: Introducción a Agilidad y Scrum: http://twileshare.com/uploads/EFF46d01.pdf Scrum: http://es.wikipedia.org/wiki/Scrum

15. Qué significa iterativo e incremental?

16. Iterativo: construir una versión transversal cada vez, validarla, ajustar y agregar valor tras cada iteración. 1 2 3 4 5

18. 1 2 3 4 5 1 2 3 4 5 Iterativo e incremental

19. usertaskstosupport releaseD D D D D I IB- C C- D D D DA- B B- B B B B-A- A B A A- A- B- sprint 1234 Producto: (en 4 sprints) para entregar el major proudcto Iterativo e incremental permite construir el mejor producto posible ajustando las necesidades y entregando valor visible con cada iteración.

20. Producto

21. Una historia es como una porción del pastel

23. Porqué es necesario escribir un buen código?

24. http://photos.pcpro.co.uk/blogs/wp-content/uploads/2010/10/frustrated.jpg Pasamos más tiempo leyendo código que escribiéndolo

25. Costo de poseer código “No Mantenible”

26. “Escribir código que entienda la computadora es una técnica; escribir código que entienda un ser humano es un Arte” – Robert ‘Uncle Bob’ Martin Actitud

27. Entonces, ¿Por qué es importante escribir mejor código?

28. Fácil de Entender Fácil de Cambiar Barato de Mantener

29. Cómo detectar un código mal oliente? Code Smells

30. Qué son los Code Smells? Son todos los síntomas que podemos encontrar en el código fuente de un sistema que indican que muy probablemente existan problemas más profundos de calidad de código, de diseño o de ambos.

31. Rigidez

32. Rigidez es la tendencia que posee el software a ser difícil de cambiar, incluso en formas sencillas o cambios mínimos.

33. Fragilidad

34. Fragilidad es la tendencia que posee un programa para romperse en muchos lugares cuando un simple cambio es realizado.

35. Inamovilidad

36. Inamovilidad es la dificultad de separar el sistema en componentes que pueden ser reutilizados en otros sistemas.

37. Viscosidad

38. Viscosidad se presenta cuando hacer las cosas incorrectamente es más fácil que hacerlas del modo correcto.

39. Ambiente de desarrollo lento e ineficiente Tiempos muy largos de compilación Subir el código toma horas Hacer el deploy toma varios minutos

40. Complejidad innecesaria

41. Complejidad innecesaria existe cuando hay muchos elementos que actualmente no son útiles.

42. Repetición innecesaria

43. Repetición innecesaria es cuando el código posee estructuras repetidas que pueden ser unificadas bajo una sola abstracción.

44. Opacidad

45. Opacidad es la tendencia que posee un módulo a ser difícil de leer y comprender.

46. Refactorizar

47. Cambiar la estructura interna del código…

48. Cambiar la estructura interna… http://4.bp.blogspot.com/-RhAnCDMlvts/Tptjf9pQcZI/AAAAAAAAAUU/lJSYMataDOM/s1600/mecanismo-reloj.jpg Sin alterar su comportamiento visible…

49. Obtener un código más simple y limpio. La refactorización enseña técnicas para descubrir código de mala calidad y técnicas para cambiarlo.

50. S.O.L.I.D

51. Single Responsibility Principle Open / Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

52. Single Responsibility Principle “Cada objeto debe tener una responsabilidad única, y esta responsabilidad debe estar completamente encapsulada dentro de la clase.” “Las clases deben tener una única responsabilidad, una única razón de cambio.”

53. Open / Close Principle “Una clase debe estar abierta para extensión pero cerrada para modificación.”

54. Liskov Substitution Principle “Las clases derivadas deben ser sustituidas por sus clases base.”

55. Interface Segregation Principle “Mantenga interfaces finas a un nivel de granularidad que el cliente necesita. Los clientes no deben ser forzados a depender de interfaces que no utilizan.”

56. Dependency Inversion Principle “Clases de alto nivel no deben depender de clases de bajo nivel. Ambas deben depender de sus abstracciones.” “Dependa de abstracciones, no de objetos concretos”

57. Patrones de Diseño

58. Qué es un patrón de diseño? Es la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño resulta ser una solución a un problema de diseño. “ ” Fuente: http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

59. Creación: resuelven problemas de instanciación de objetos. Estructura: resuelven problemas relacionados a la forma de estructurar las clases. Comportamiento: resuelven problemas relacionados al comportamiento de la aplicación.

60. Creación: resuelven problemas de instanciación de objetos. Estructura: resuelven problemas relacionados a la forma de estructurar las clases. Comportamiento: resuelven problemas relacionados al comportamiento de la aplicación. Arquitectónicos: resuelven problemas relacionados a la arquitectura de la solución y despliegue.

61. Cambiar la estructura interna… http://4.bp.blogspot.com/-RhAnCDMlvts/Tptjf9pQcZI/AAAAAAAAAUU/lJSYMataDOM/s1600/mecanismo-reloj.jpg MVC MVP MVVM Page Controller Composite App Publicador – Suscriptor Microkernel Service Locator Basados en Eventos Basados en Atributos Basdos en Dominio - DDD Dependency Injection Polyglot Persistence

62. Code Smells http://www.slideshare.net/JohnnyDark/code-smells-y-solid-a-qu-huele-tu- cdigo Patrones de Diseño http://es.slideshare.net/ikercanarias/patrones-de-diseo-de-software-14836338

64. QA es responsable Responsabilidades del Team MemberLa Calidad en el enfoque tradicional

65. En Agile la Calidad es responsabilidad de todos!

66. Prueba Unitaria Procedimiento utilizado para validar que unidades individuales de código fuente trabajen adecuadamente. “ ”

67. Prueba Unitaria Es una pieza de código (usualmente un método) que invoca a otra pieza de código y verifica la correctitud de ciertas suposiciones hechas inicialmente. “ ” Fuente: The Art of The Unit Testing

68. Cómo escribir una prueba unitaria? Analizar unidad de código Definir Contrato de Invocación Diseñar casos de prueba Ejecución pruebas anteriores Crear Suite de pruebas para unidad Implementar unidad Ejecutar Suite de Pruebas. Corregir errores Ejecutar otras pruebas unitarias. Liberación de Unidad

69. Prueba Unitaria es un enfoque posterior al código Código PruebaError

70. Y si hacemos la prueba primero y después el código?

71. Test Driven Development

72. Y si creamos la prueba funcional primero?

73. Acceptance Test Driven Development

74. User Story AT1 AT2 Pruebas de Aceptación Automatizadas

75. ATDD y TDD

76. Unit Testing no es TDD. TDD genera pruebas unitarias.

77. TDD permite un refactor confiable.

79. Arquitectura Ágil = Diseño evolutivo + Arquitectura Emergente

81. Qué es la deuda técnica?

82. Deuda Técnica Es un concepto en la programación que refleja el trabajo de desarrollo adicional que surge cuando se utiliza la vía fácil de hacer código a través de medidas a corto plazo en lugar de aplicar la mejor solución global. “ ” Fuente: http://www.techopedia.com/definition/27913/technical-debt

83. Deuda Técnica Es el costo que se acumula por evitar hacer lo correcto en el momento adecuado, permitiendo que la calidad del software se deteriore en el tiempo. “ ”

84. Deuda Técnica

85. Deuda Técnica

86. Evaluación de la Deuda Técnica Esfuerzo estimado para el pago de la deuda (Colocar los indicadores al mínimo) Porcentaje de Deuda Técnica en el programa Impacto de las Métricas en el Indicador

87. Modelo de Mantenibilidad SIG - ISO Software Improvement Group Maintainability Model 0 1 2 3 Estabilidad Facilidad de análisis Facilidad de cambio Facilidad de Pruebas ISO/IEC 9126 Software Quality (Maintainability)

88. Principios Patrones Code Smells Prácticas Dominio del Desarrollador Ágil ü Code Clean ü Refactoring ü Diseño Evolutivo ü Menos Deuda Técnica

90. Programación en Pares

91. Y a veces programación en trío

92. Retrospectivas

93. Retrospectivas “Sin importar lo que hemos descubierto, entendemos y ciertamente creemos que cada uno hizo el mejor trabajo que pudo, con lo que conocíamos en ese momento, con las habilidades, los recursos disponibles, y la situación dada.” — Norm Kerth, Project Retrospectives: A Handbook for Team Reviews Directiva Primaria

94. Daily StandUp Sprint Planning Demo Retrospectiva Release Planning El cumplimiento de las tareas y la calidad técnica son mis principales responsabilidades. Debo entender las historias explicadas por el PO, y hacer preguntas cuando necesite aclaración. Debo comprender y respetar los criterios de aceptación. Debo estimar las historias priorizadas en función de su complejidad. Debo descomponer las historias en tareas (preferiblemente de 1 día máximo de duración). Debo aplicar principios, técnicas y patrones adecuados para mejorar la calidad de mi código. Debo subir mi trabajo al repositorio de código fuente regularmente. Debo actualizar mi trabajo en la herramienta. Todo mi esfuerzo y talento para el cumplimiento de los objetivos del sprint. Ayuda en resolver dudas técnicas y revisiones de código cuando lo necesiten. Estar presente puntualmente en las reuniones acordadas por el equipo. Apoyo a los demás miembros del equipo en compartir el conocimiento y solución de problemas técnicos. Comunicar transparentemente los problemas que tengo cada día. Fomentar la auto-organización y el respeto a los acuerdos del equipo. Apoyo al PO y SM en la coordinación de la entrega. Team Member ¿En qué consiste mi rol? ¿Qué esperan el resto del equipo de mí? ¿En qué reuniones debo estar? Reference Card

95. Gracias@JohnnyOrdonez picture by ePi.Longo

96. Referencias

97. The Scrum Guide:http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide- ES.pdf#zoom=100 The Scrum Body of Knowledge: http://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2013-spanish.pdf Introducción a Agile y Scrum http://www.slideshare.net/JohnnyDark/introduccin-a-agile-y-scrum-15642614 Estimación y Planificación ágil http://www.slideshare.net/JohnnyDark/estimacin-y-planificacin-gil-webinar Scrum y XP desde las trincheras: http://www.proyectalis.com/wp- content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf Flexibilidad con Scrum http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf

98. The Scrum Primer: http://assets.scrumfoundation.com/downloads/2/scrumpapers.pdf?1285932052 Un Mejor Scrum: http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum- 2.pdf The Scrum Papers: http://assets.scrumfoundation.com/downloads/2/scrumpapers.pdf?1285932052 Artículos sobre Scrum: http://www.mountaingoatsoftware.com/topics/scrum http://agileanarchy.wordpress.com/2009/09/20/simple-scrum/ http://www.scrumalliance.com/articles Agile for Dummies: http://digitalcelerity.com/Resources/Documents/AGILE%20FOR%20DUMMIES%20- %20eBOOK.pdf Essential Scrum [Book] http://www.amazon.com/Essential-Scrum-Practical-Addison-Wesley-Signature/dp/0137043295 =UTF8&qid=1438286302&sr=1-1&keywords=agile+software+development+Shore

99. Succeding Agile Software Development [Book] http://www.amazon.com/Succeeding-Agile-Software-Development- Using/dp/0321579364/ref=sr_1_1?s=books&ie=UTF8&qid=1438286257&sr=1- 1&keywords=succeeding+with+agile The Art of Agile Development [Book] http://www.amazon.com/Art-Agile-Development-James- Shore/dp/0596527675/ref=sr_1_1?s=books&ie=UTF8&qid=1438286302&sr=1- 1&keywords=agile+software+development+Shore Scrum Reference Card http://scrumreferencecard.com/ Introduction to Scrum [Video] https://www.youtube.com/watch?v=D8vT7G0WATM Agile Training (Scrum) [Videos] https://www.youtube.com/playlist?list=PLF6BFA8BAEDF6CE70

100. Growing Agile: A Coach's Guide to Agile Testing https://leanpub.com/AgileTesting Serious LeAP by Masa Maeda https://www.slideshare.net/masakmaeda/serious-leap-talk-at-agile-2015-conference Scrummaster As A Servant Leader https://luis-goncalves.com/scrummaster-servant-leader/ Scaled Agile Framework (SAFe) http://scaledagileframework.com/ https://www.youtube.com/watch?v=9TJDobOJMQw http://www.youtube.com/watch?v=XRKyYI5mbhc

Módulo 4. Desarrollador ágil

Esté a ler uma amostra.

Confira estes a seguir

Módulo 4. Desarrollador ágil

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Módulo 4. Desarrollador ágil (20)

Mais de Johnny Ordóñez (20)

Mais recentes (20)