Una introducción a eXtreme Programming

eXtreme programming es una metodología que enfoca el desarrollo de software en la programación, pero no solo se ocupa de esto.

El énfasis en el desarrollo enfocado en el software fue el que precedió el Manifiesto Ágil. Kent Beck en 1999 compartió su experiencia en proyectos que desarrolló usando dicha metodología.

Extreme programming se enfoca en cinco valores principales: comunicación, feedback, simplicidad, coraje y respeto.

La revolución por la que conocemos el desarrollo de software a día de hoy con la etiqueta "ágil" empezó ahí.

En esta charla nos vamos a adentrar en más detalles de lo que estaba ocurriendo en aquel momento en el que eXtreme programming fue presentado a la comunidad de desarrollo, sus prácticas y similitudes con los marcos que utilizamos actualmente.

A continuación se exponen los objetivos a alcanzar:

- Conocer qué es eXtreme Programming y cómo se desarrolló.
- Describir los valores: comunicación, feedback, simplicidad, coraje y respeto.
- Comparar las diferencias entre SCRUM y eXtreme programming.
- El impacto en el coste del desarrollo con eXtreme programming y otras prácticas.

Aunque no parezca cercana la forma de trabajar con eXtreme programming por el hecho de que SCRUM es la metodología más popular en la industria, esta metodología ha sido empleada ya por diversas empresas de manera inconsciente, no solo en la técnica sino en el desarrollo de software.

Transcript

1. Una introducción a eXtreme Programming XP explained second edition
2. Objetivos _Conocer qué es eXtreme Programming y cómo se desarrolló. _Describir los valores: comunicación, feedback, simplicidad, coraje y respeto. _Comparar las diferencias entre SCRUM y eXtreme programming. _El impacto en el coste del desarrollo con eXtreme programming y otras prácticas.
3. Calentando motores
4. Agile vs Waterfall
5. "The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes." El cambio
6. Línea del tiempo ≃ 1997 - SCRUM ≃ 1999 - eXtreme Programming ≃ 2003 - Lean software development / Kanban
7. ¿Soy eXtreme? El primer proyecto extreme
8. Un proyecto con problemas Comenzó con una llamada telefónica, alguien estaba preocupado por el rendimiento del sistema de nómina de Chrysler (Kent Beck escribió una conferencia sobre el rendimiento de Smalltalk), así que lo llamaron.
9. Un proyecto con problemas - A dos meses lejos de producción - Escuchando a quien estaba escuchando antes de responder - La gente estaba cansada
10. ¿Cómo vamos a trabajar? - Iteración de tres semanas - Implementar algunas historias (el experto en la nómina de pagos elegirá) - Estimaremos y averiguaremos cuántos se ajustan a la iteración
11. ¿Cómo vamos a trabajar? - Un día de estimación - El cliente eligió la funcionalidad mínima para una primera implementación
12. - No se cumplió el plazo, se tardó tres meses más - fue un éxito empresarial - El proyecto fue desmantelado debido a los avances tecnológicos y la financiación ¿Los resultados?
13. eXtreme Programming
15. ¿Qué valores tiene que tener un equipo?
16. Valores _Comunicación _Feedback _Simplicidad _Coraje _Respeto
17. Comunicación Sentido común y cooperación eficaz
18. Feedback - Es posible que no sepamos cómo hacerlo bien - Lo que es bueno para hoy puede ser malo para mañana. - Estar satisfecho con la mejora en lugar de esperar la perfección - Los equipos XP generan la mayor cantidad de comentarios lo más rápido posible: tenga cuidado con los demasiados comentarios.
19. Simplicidad - La simplicidad depende del contexto. - Este valor se vuelve aún más claro en la práctica de Test Driven Development que reduce la complejidad que uno podría comenzar a implementar software. - La simplicidad también proviene de la experiencia a medida que avanza la carrera, los desarrolladores experimentados tienden a encontrar soluciones más simples en lugar de las complicadas.
20. Coraje - El coraje de decir verdades, agradables y desagradables, fomenta la confianza en la comunicación.
21. Respeto - El desarrollo de software tiene el mismo valor que un ser humano. - Se debe respetar la contribución de cada persona en el equipo.
22. Principios El fío conductor
23. Principios Humanidad Economía Beneficio mutuo Mejora Reflexión Diversidad Flujo continuo Oportunidad Redundancia Falla Calidad Pasos pequeños
24. Principios Economía Beneficio mutuo Mejora Reflexión Diversidad Flujo continuo Oportunidad Redundancia Falla Calidad Pasos pequeños Humanidad El desarrollo de software no satisface las necesidades humanas - Libertad y seguridad - Logro - Pertenecer - Crecimiento - Entender y ser entendido
25. Principios Beneficio mutuo Mejora Reflexión Diversidad Flujo continuo Oportunidad Redundancia Falla Calidad Pasos pequeños Humanidad - Lo que estamos haciendo tiene sentido para el negocio - no invertir en flexibilidad especulativa Economía
26. Principios Mejora Reflexión Diversidad Flujo continuo Oportunidad Redundancia Falla Calidad Pasos pequeños Humanidad Economía Beneficio mutuo - Automated tests that helps to design and implement better today. - Carefully refactor. - Chose names that are coherent and explicitly sets of metaphors.
27. Principios Reflexión Diversidad Flujo continuo Oportunidad Redundancia Falla Calidad Pasos pequeños Humanidad Economía Beneficio mutuo Mejora - No existe un proceso perfecto. - No esperes la perfección para empezar. Ponga la mejora a trabajar al no esperar la perfección. - Comience la actividad de inmediato y perfeccione los resultados con el tiempo.
28. Beneficio mutuo Principios Reflexión Flujo continuo Oportunidad Redundancia Falla Calidad Pasos pequeños Humanidad Economía Mejora Diversidad - Un equipo donde todos son iguales no es efectivo. - Los programadores deben trabajar juntos y valorar la opinión de los demás. - Aporta nuevas perspectivas, se necesita una variedad de habilidades para pensar en un problema y una solución.
29. Oportunidad Principios Flujo continuo Pasos pequeños Humanidad Economía Mejora Beneficio mutuo Diversidad Reflexión Redundancia Falla Calidad - Los buenos equipos dan un paso atrás para pensar en cómo están trabajando y por qué están trabajando. - Los sentimientos templados por el intelecto son una fuente de introspección. - El aprendizaje es acción reflejada.
30. Oportunidad Principios Pasos pequeños Humanidad Economía Mejora Beneficio mutuo Diversidad Reflexión Redundancia Falla Calidad Flujo continuo - Las prácticas de XP están sesgadas hacia un flujo continuo de actividades. - Los equipos han sufrido de integración big bang: todo a la vez en lugar de un flujo continuo de entrega. - Resolver los problemas que interrumpen el flujo.
31. Principios Pasos pequeños Humanidad Economía Mejora Beneficio mutuo Diversidad Reflexión Redundancia Falla Calidad Flujo continuo Oportunidad - Los problemas son oportunidades de aprendizaje.
32. Principios Pasos pequeños Humanidad Economía Mejora Beneficio mutuo Diversidad Reflexión Falla Calidad Flujo continuo Oportunidad Redundancia - Los defectos corroen la confianza, no se puede resolver el problema del defecto con una sola práctica. - Tener una fase de prueba después del desarrollo debería ser redundante.
33. Principios Pasos pequeños Humanidad Economía Mejora Beneficio mutuo Diversidad Reflexión Falla Calidad Flujo continuo Oportunidad Redundancia - Fallar y aprender. - El fracaso no es un desperdicio. Fallar en lugar de hablar.
34. Principios Pasos pequeños Humanidad Economía Mejora Beneficio mutuo Diversidad Reflexión Falla Calidad Flujo continuo Oportunidad Redundancia - Sacrificar la calidad no es efectivo como medio de control. - XP elige el alcance como el principal medio de planificación. - Haz el trabajo lo mejor que puedas.
35. Principios Humanidad Economía Mejora Beneficio mutuo Diversidad Reflexión Falla Calidad Flujo continuo Oportunidad Redundancia Pasos pequeños - Se expresan en prácticas como la programación test-first y la integración continua.
36. Prácticas Primarias y corollary
37. Prácticas primárias Prácticas corollary
38. Prácticas primárias Prácticas corollary
39. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design
40. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - desarrollarse en un espacio lo suficientemente grande para todo el equipo. - el problema es siempre un problema de personas. - Sentarnos juntos para comunicarnos con todos nuestros sentidos juntos. - sentarse juntos incluso si eso significa viajar.
41. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - nosotros pertenecemos. - nos apoyamos mutuamente en el trabajo, el crecimiento y el aprendizaje. - agregue y elimine personas del equipo a pedido - 150 personas más y no es posible reconocer a las personas para generar confianza y se necesita confianza para la colaboración
42. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - cuadros informativos - Se necesita espacio público y privado para trabajar.
43. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - El desarrollo de software se trata de conocimientos y los conocimientos vienen a la mente descansada. - No trabaje demasiado, realice un seguimiento de cuándo uno podría no ser tan productivo como pueda y deténgase por el día.
44. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - Dos personas sentadas en una máquina. - Rotar con frecuencia. - Sea consciente de las diferencias culturales, el espacio personal significa diferentes cosas para diferentes personas. - Las emociones en el trabajo deben estar relacionadas con el trabajo. - Si no te sientes cómodo haciendo pareja con alguien del equipo, háblalo.
45. Trabajo com impacto Prácticas primárias Equipo colocalizado Whole team Espacio informativo Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - la estimación temprana es una diferencia clave entre las historias y otros requisitos. - nombres cortos para historias
46. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - Plan de trabajo a la semana a la vez - revisar el progreso - discuta las prioridades y elija las más importantes para el negocio - dividir las historias en tareas - trabajar los fines de semana no es sostenible.
47. Historias de usuario Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - 80/20 - tarea elegida por el programador - semana Friki
48. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - mantener la compilación por debajo de diez minutos - vistas automatizadas sin necesidad de intervención manual
49. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - Integrar las cosas no más de un par de horas. - integrar el trabajo después de una sesión en pareja
50. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - Comience cualquier cosa con un test fallando.
51. Prácticas primárias Equipo colocalizado Whole team Espacio informativo Trabajo com impacto Historias de usuario Pair programming Ciclos semanales y trimestrales Tiempo libre Build de diez minutos Integración continua Test first programming Incremental design - invertir en el diseño del sistema todos los días. - Trae mejoras gradualmente y no todo por adelantado. - Los equipos de XP confían en su capacidad para adaptar el diseño a los requisitos futuros.
52. Prácticas primárias Prácticas corollary
53. Prácticas primárias Prácticas corollary
54. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario
55. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario - El cliente debe ser parte del equipo. - El cliente proxy conduce a una pérdida de tiempo. - El cliente no confiaría en nosotros si supiera cómo es el desarrollo de software. - Perder el tiempo encubriendo.
56. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario El lanzamiento del big bang trae dificultades a las personas y las pone demasiado nerviosas tratando de lograr todo lo que se necesita para el día D
57. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario Básicamente, mantenga juntas a las personas a las que les va muy bien, no evite el aspecto humano, pero eso no significa equipos estáticos. Los desarrolladores que trabajan en un equipo XP pueden unirse y dejar un equipo y volverse productivos después de un mes.
58. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario Demasiada gente en un equipo también trae desafíos, muy pocos miembros en diferentes equipos requieren fusionarlos.
59. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario 1. Escriba una prueba automatizada a nivel del sistema que reproduzca el defecto. 2. Escriba una prueba unitaria con el alcance más pequeño posible que también reproduzca el defecto. 3. Arreglar el sistema, para que funcione la prueba unitaria. Repita hasta que funcione. 4. Una vez que se solucione el defecto, averigüe por qué se creó.
60. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario Cualquier miembro del equipo puede mejorar el código en cualquier momento.
61. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario Solo el código fuente y las pruebas son artefactos permanentes.
62. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario Puede desarrollarse en una rama, pero nunca dejar que viva más de unas pocas horas. En lugar de crear muchas versiones del código base, solucione primero el problema de diseño subyacente.
63. Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Negociar contrato Pago por usuario Despliegue todas las noches. Existen algunas barreras para el despliegue frecuente, algunas de ellas son técnicas y otras son sociales, por ejemplo, el proceso de implementación es tan estresante que nadie quiere implementar.
64. Negociar contrato Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Pago por usuario Reduzca el riesgo firmando un secuencia de contratos cortos en lugar de uno largo.
65. Negociar contrato Prácticas corollary Participación real del cliente Continuidad del equipo Despliegues incrementales equipos cada vez más reducidos código compartido Análisis de raíz de la causa Código y pruebas Una code base Despliegues diarios Pago por usuario Con los sistemas de pago por uso, cobra por cada vez que se utiliza el sistema. El dinero es la última retroalimentación.
66. ¿y SCRUM?
67. XP y SCRUM - Enfoque en el equipo, prácticas y valores - Colaboración con el cliente y respuesta al cambio - Basado en valores y personas - Enfoque en gerencia del equipo - commitment en una carga de trabajo - Basado en el mundo empresarial, poco enfoque en las personas
68. ¿Soy eXtreme?
69. - Feedback - Corage - Simplicity - Comunicación - Respeto
70. - Feedback - Corage - Simplicity - Comunicación - Respeto - Flujo continuo - Humanidad - Diversidad - Beneficio mutuo - Redundancia - Economía - Oportunidad - Reflexión - Mejora - Calidad - Falla - Pasos pequeños
71. - Feedback - Corage - Simplicity - Comunicación - Respeto - Flujo continuo - Humanidad - Diversidad - Beneficio mutuo - Redundancia - Economía - Oportunidad - Reflexión - Mejora - Calidad - Falla - Pasos pequeños - Ciclos semanales y trimestrales - Test first programming - Equipo colocalizado - Espacio informativo - Build de diez minutos - Pair programming - Tiempo libre - Whole team - Historias de usuario - Trabajo com impacto - Integración continua - Incremental design
72. - Feedback - Corage - Simplicity - Comunicación - Respeto - Flujo continuo - Humanidad - Diversidad - Beneficio mutuo - Redundancia - Economía - Oportunidad - Reflexión - Mejora - Calidad - Falla - Pasos pequeños - Ciclos semanales y trimestrales - Test first programming - Equipo colocalizado - Espacio informativo - Build de diez minutos - Pair programming - Tiempo libre - Whole team - Historias de usuario - Trabajo com impacto - Integración continua - Incremental design - Participación real del cliente - Código y pruebas - Despliegues incrementales - Despliegues diarios - Análisis de raíz de la causa - Continuidad del equipo - Una code base - equipos cada vez más reducidos - código compartido - Negociar contrato - Pago por usuario
73. Una introducción a eXtreme Programming XP explained second edition