Breve descripción del rol del Desarrollador ágil y un miembro de un equipo Scrum.

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

6. 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?

13. 1
2
3
4
5

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

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

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

17. Qué significa iterativo e
incremental?

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

19. 19
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
1 2 3 4 5
Incremental: constuir un poco de cada capa o módulo
transversal agregando complejidad con el tiempo.

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

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

22. Producto

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

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

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

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

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

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

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

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

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

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

35. Rigidez

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

37. Fragilidad

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

39. Inamovilidad

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

41. Viscosidad

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

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

44. Complejidad
innecesaria

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

46. Repetición
innecesaria

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

48. Opacidad

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

50. Refactorizar

51. Cambiar la
estructura
interna del
código…

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

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

54. S.O.L.I.D

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

56. 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.”

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

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

59. 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.”

60. 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”

61. Patrones de
Diseño

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

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

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

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

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

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

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

72. En Agile la
Calidad es
responsabilidad
de todos!

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

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

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

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

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

78. Test Driven Development

79. Y si creamos la prueba
funcional primero?

80. Acceptance Test Driven Development

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

86. ATDD y TDD

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

89. TDD permite un refactor
confiable.

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

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

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

93. Qué es la
deuda
técnica?

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

95. 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.
“
”

96. Deuda Técnica

97. Deuda Técnica

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

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

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

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

104. Programación en Pares

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

106. Retrospectivas

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

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

109. Gracias@JohnnyOrdonez
picture by ePi.Longo

110. Referencias

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

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

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

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