¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Si no vas a velocidad límite, alguien lo hará y se comerá tu comida
— Kent Beck
eXtreme Programming

¿Cuándo? ¿Dónde? ¿Quién?

Comunidad de Smalltalk (GUI, OO+herencia, MVC, patrones, …​)

Ward Cunningham y Kent Beck

Kent Beck

Origen, finales de los 80

Desarrollo, en los 90

Creación, 1993-1997

  • desarrollo de software es un proceso adaptativo y orientado a las personas

    • multiples proyectos como consultor

  • C3 de Chrysler, se puede considerar el proyecto de su creación

    • Kent Beck acuñó el nombre de Extreme Programming.
Primera edición: 2000 Segunda edición: 2005

Hay cambios significativos entre ambas ediciones, que reflejan la evolución de XP y su maduración, incorporando algunas prácticas de otras metodologías

  • 4 valores

    • 14 principios

      • 12 prácticas

  • 5 valores

    • 14 principios

      • 13 prácticas

¿Qué?

Es un método ligero, eficiente, de bajo riesgo, predecible, científica y divertido para que equipos de tamaño mediano a pequeño (de 10 a 2 programadores) desarrollen software frente a requisitos imprecisos y muy cambiantes
— Kent Beck
eXtreme Programmig
Conservadora Niveles extremos Novedad

  • todas sus técnicas han sido probadas durante décadas o siglos

  • toma principios y prácticas de sentido común

  • poner todas a trabajar bajo un mismo paraguas

  • Si la simplicidad es buena,

  • siempre dejaremos el sistema con el diseño más sencillo que soporte su funcionalidad actual

  • la cosa más sencilla que probablemente pudiese funcionar, (MVP, minimum viable product)

  • Si las revisiones de código son buenas,

  • revisaremos el código todo el tiempo

  • programación por parejas

  • Si un código con un buen diseño es importante,

  • entonces diseñemos todos los días y cambiemos nuestro código para que siempre tenga un buen diseño

  • refactorizar

  • Si la arquitectura es importante,

  • todos trabajarán definiendo y refinando la arquitectura todo el tiempo

  • metáfora

  • Si las pruebas son buenas,

  • todos probarán todo el tiempo, incluso los clientes

  • prueba unitaria y funcional, respectivamente

  • Si las pruebas de integración son importantes,

  • entonces integraremos y probaremos varias veces al día

  • integración continua

  • Si las iteraciones cortas son buenas,

  • haremos iteraciones realmente cortas, segundos, minutos y horas, y no semanas, meses y años

  • el juego de la planificación con replanificación y retrospectivas

Asegurar todas las practicas tan minuciosamente como sea posible y que las prácticas se apoyan unas a otras en el mayor grado posible

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible
A los programadores A los clientes y directivos Al proyecto

  • Serán capaces de trabajar en cosas que realmente importan cada día.

  • No tendrán que enfrentarse solos a situaciones aterradoras.

  • Podrán aprovechar todas sus energías para hacer que su sistema tenga éxito.

  • Tomarán las decisiones que puedan tomar mejor y no tomarán aquellas para las que no sean los mejores preparados

  • Obtendrán el mayor valor posible de cada semana de programación.

  • Cada pocas semanas podrán ver progresos concretos en las metas que les importan.

  • Podrán cambiar la dirección del proyecto a mitad del desarrollo, sin incurrir en costes excesivos

  • Reducir riesgos del proyecto,

  • mejorando la sensibilidad a los cambios del negocio,

  • la productividad a lo largo de la vida del sistema y

  • añade diversión a la construcción de software en equipo
Tenemos éxito cuando tengamos un estilo que reúna un conjunto consistente de valores que sirvan tanto a las necesidades humanas como a las comerciales
— Kent Beck
eXtreme programming

¿Cómo?

Roles

Cliente/Usuario Gestor Programadores

Un equipo que trabaja de un modo eficiente “como una unidad” puede mejorar la productividad en todas y cada una de las etapas del desarrollo del software

  • No existen tantos equipos que trabajen de manera compenetrada y unida, como si fueran una sola persona.

    • En el mundo del desarrollo del software hay muchos egos (o “estrellas del rock”) que prefieren trabajar en solitario y no compartir su conocimiento.

  • Es necesario que todos los desarrolladores colaboren juntos, como un verdadero equipo, para crear el mejor producto que jamas hayan soñado. La motivación y el objetivo compartido es también uno de los aspectos que se fomentan.

Clientes/Usuarios

Gestores

Programadores

  • Necesitan que se cree la aplicación.

  • Controlan los recursos del proyecto.

  • Analiza, diseña, testea el software y lo integra en el sistema.

  • Estima el coste de implementar cada historia y, cuando finalmente la implementa, se puede medir su velocidad.

XP fija el coste y el tiempo y la calidad (siempre alta) y se negocia el alcance entre cliente/usuario y programadores

  • Aprenderán el modo de comunicarse con el equipo, para conseguir transmitir sus ideas.

    • El equipo le ayudará en ese cambio de mentalidad para obtener el producto en plazos.

  • Aprenderán a medir el progreso del proyecto, la calidad del producto y cómo responder a las preguntas importantes.

    • Es muy importante que aprendan a confiar en la propia gestión que hace de sí mismo el equipo de desarrollo.

  • Lo más importante es entender correctamente la funcionalidad que está descrita en la historia de usuario.

    • Ante cualquier duda, debería tener accesible al cliente para entablar una conversación que le permita entender la funcionalidad, su motivación y el mecanismo que el cliente usará para verificar que la historia se ha implementado correctamente.

    • El cliente debería ver cuanto antes la funcionalidad implementada, de forma que pueda dar realimentación a los desarrolladores si no han comprendido correctamente lo que él quería.

    • También puede ocurrir que el cliente quiera refinar la funcionalidad una vez que la haya empezado a usar o que incluso cambie de opinión completamente.

Actividades

Escuchar Probar Codificar Diseñar
Queremos hacer cualquier cosa que debamos hacer para tener un desarrollo software estable y predecible. Pero no tenemos tiempo para hacer horas extras. Las cuatro actividades básicas del desarrollo son : codificar, probar, escuchar y diseñar
— Kent Beck
eXtreme Programming

  • Escuchar:

    • Puesto que (como programador) no lo conoces todo, tienes que preguntar a alguien. Te dirán cuáles son las respuestas que esperas, y cuáles son los casos raros desde la perspectiva del negocio.

    • Decir tan sólo “deberías escuchar a los otros y al cliente” no ayuda mucho. Las personas intentan eso y no funciona.

    • Tenemos que encontrar la forma de estructurar la comunicación para que las cosas que tienen que ser comunicadas, se comuniquen cuando necesitan ser comunicadas y con la cantidad de detalle que necesitan ser comunicadas.

    • De forma similar, las reglas que desarrollemos no tienen que fomentar la comunicación que no ayude

  • Codificar:

    • Al final del día, todo nuestro trabajo está en un programa. Llamo codificar a la única actividad de la que sabemos que no podemos prescindir.

    • Si dibujas diagramas que generan código o escribes en un editor, estás codificando. Cuando codificas algo, también tienes oportunidad para comprender la mejor estructura para el código. Hay ciertos signos en el código que te indican que todavía no entiendes suficientemente la estructura necesaria.

    • El código también te da la oportunidad de comunicarte de forma clara y concisa.

  • Probar:

    • Las características del software que no pueden ser demostradas mediante pruebas automatizadas, simplemente no existen. Por lo que no tengo confianza en nada de lo que escribo, hasta que no tengo una prueba para eso.

    • Las pruebas me dan la oportunidad de pensar sobre lo que quiero, de forma independiente a cómo será implementado.

    • Cuando no puedes pensar en ninguna prueba que pudiese originar un fallo, has acabado por completo. Las pruebas mantienen el programa vivo más tiempo (si las pruebas funcionan y son mantenidas).

    • Cuando tienes las pruebas, puedes hacer más cambios durante más tiempo que si no las tuvieras. Si continuas escribiendo las pruebas, tu confianza en el sistema aumenta con el tiempo.

    • Programar y probar a la vez es más rápido que solo programar. La ganancia en la productividad venía de la reducción en el tiempo utilizado en la depuración, no tardas una hora localizando un error.

  • Diseñar:

    • ¿Por qué no puedes escuchar, escribir una prueba, hacer que funcione, escuchar, escribir una prueba, hacerla que funcione, indefinidamente? La única forma de conseguir que el siguiente caso de prueba funcionase es hacer que otro no funcione. O la única forma de hacer que el caso de prueba funcionase es resolver otro problema que sea equivalente.

    • La única forma de evitar esto es diseñar. Al diseñar estás creando una estructura que organiza la lógica en el sistema. Un buen diseño organiza la lógica, de tal forma que un cambio en una parte del sistema no siempre requiere un cambio en otra parte del sistema.

    • Un buen diseño asegura que cada trozo de lógica está en uno y solamente un lugar. Un buen diseño permite el crecimiento del sistema con cambios en un solo lugar.
Valores Principios
las buenas prácticas no son suficientes por sí mismas, tienen que entenderse bajo un conjunto de valores y principios que permiten al equipo comportarse como una unidad con un objetivo común
— Kent Beck
eXtreme Programming

  • Los valores son universales y muy genéricos:

    • Los valores son demasiado abstractos para guiar el comportamiento.

    • La comunicación, simplicidad, realimentación, coraje y respeto se pueden aplicar en otros contextos diferentes al desarrollo software

  • Los principios el hueco entre los valores y las buenas prácticas técnicas

    • Los principios son un refinamiento de los valores pero concretados para un entorno específico.
Valores Principios Buenas prácticas

  • Simplicidad

  • Comunicación

  • Realimentación

  • Coraje

  • Respeto

  • Humanidad

  • Economía

  • Beneficio mutuo

  • Auto-similaridad

  • Mejora continua

  • Diversidad

  • Reflexión

  • Flujo

  • Oportunidad

  • Redundancia

  • Fallo

  • Calidad

  • Pasos de niño

  • Responsabilidad aceptada

  • Equipo

    • El equipo debe estar junto

    • El equipo como una unidad

    • Propiedad compartida del código

  • Organización del trabajo

    • Trabaja las horas razonables para ser productivo

    • Margen en la planificación (Slack)

    • Planifica usando historias de usuario

    • El ciclo semanal y el ciclo trimestral

    • Radiadores de información

  • Desarrollo

    • Programa por pares

    • Programación dirigida por pruebas

    • Integración continua

    • Pequeñas versiones incrementales

    • Diseño emergente y sencillo

    • Código de calidad

Valores

Sencillez Comunicación Realimentación Coraje Respeto

Sencillez

KISS, Keep it simple, stupid! BDUF, Big design up front YAGNI, You aren’t gonna need it

  • Es mucho mejor hacer una cosa sencilla hoy y pagar un poco más mañana para cambiar, si es que es necesario, que

  • hacer una cosa más complicada hoy y no utilizarla después.

  • Una de las cosas más difíciles del mundo es no mirar lo que necesitarás implementar mañana, la próxima semana y el próximo mes

  • más fácil y rápido de implementar y de probar.

    • Lo que implica que el cliente puede tener esa funcionalidad mucho antes y puede aportar su realimentación

  • sistemas software se implementan de tal forma que están preparados para cosas que nunca ocurren y eso tiene mucho coste y poco valor, sobre-diseño

    • se aplican en otras disciplinas de la ingeniería, en construcción, pero han resultado muy poco adecuadas para el desarrollo de software, utilizándose principalmente en el desarrollo en cascada.

  • Intenta consumir los mínimos recursos necesarios para sacar una funcionalidad, pero no pienses en lo que vas a necesitar mañana o dentro de un mes, piensa en las necesidades actuales y reduce el coste de llevarlas a cabo.

    • Metodología lean startup pero aplicada al desarrollo de software.

Comunicación

Comunicación con el cliente Comunicación con el equipo Comunicación técnica

  • Los problemas en los proyectos se pueden remontar a

  • alguien que no dijo a otro algo importante.

  • La mala comunicación no sucede por casualidad

  • metodologías no ágiles, se considera que esta comunicación tiene que realizarse a través de contratos y documentos

  • esa comunicación tiene que realizarse de la forma más directa posible, que permita una conversación e incluso una negociación

  • comunicación dentro del propio equipo de desarrollo y con los clientes.

  • Todos los involucrados en un proyecto tienen que conocer de forma clara los objetivos del proyecto, para que todas sus acciones vayan encaminadas a la consecución de esos objetivos.

  • entregas frecuentes de software funcionando se han demostrado como una de las mejores formas de comunicación entre el equipo y el cliente.

  • estimación del coste de forma conjunta por todos los miembros del equipo, la programación por pares y el concepto de que todo el código es de todos fomentan la comunicación entre los miembros del equipo.

Realimentación

Realimentación del sistema Realimentación del cliente Realimentación del equipo

  • Es La capacidad de medir diferentes aspectos del desarrollo software

  • Una realimentación concreta sobre el estado actual del sistema no tiene precio:

  • sistema funcionando, pruebas satisfactorias, …​

  • El optimismo es un riesgo del oficio de la programación. La realimentación es el tratamiento.

  • Una de las estrategias en el proceso de planificación es que

  • el equipo ponga las historias valiosas en producción tan pronto como sea posible

  • Gracias a los test automatizados, el sistema es capaz de generar un informe automático sobre su estado interno.

  • Gracias a las entregas frecuentes de software funcionando el cliente puede evaluar el software según se va desarrollando.

  • Esta es una importante herramienta para verificar que el proyecto avanza en la buena dirección. Y reaccionar en caso de que no sea así.

  • Se recomienda que el cliente colabore activamente en la creación de test de aceptación.

  • Si el cliente quiere incorporar funcionalidades no previstas en el producto, el equipo podrá estimar el coste de implementar dichas características

  • Las reuniones retrospectivas permiten que el equipo se realimente a sí mismo sobre su funcionamiento interno con el objetivo de mejorar

Coraje

  • Los desarrolladores deben tener valor durante el desarrollo de un proyecto en los momentos y ante las situaciones adecuadas.

    • Cuando se detectan problemas de coordinación o de incomunicación, cualquier miembro del equipo tiene que tener el coraje suficiente para poner los problemas encima de la mesa antes de que se agraven y sean más difíciles de solucionar

    • Los programadores deben tener el coraje de asumir los fallos que se cometan o limitaciones que se tengan y si es necesario, pedir ayuda para solucionarlos.

  • Los desarrolladores tienen que defender sus convicciones y negociar incluso con los otros miembros del equipo si no están de acuerdo en algo.

    • Hay que intentar llegar a situaciones de compromiso siempre que sea posible por el bien del equipo, y para eso hay que tener coraje.

Respeto

  • si los miembros de un equipo no se preocupan de los otros y de lo que ellos están haciendo, XP está muerto.

  • El respeto se manifiesta de muchas formas durante el desarrollo de un producto software.

  • Un compañero nuevo con poca experiencia se merece el mismo respeto que un programador experimentado.

    • Si un miembro del equipo tiene poca experiencia, hay que respetar sus ganas de aprender y mejorar y hay que hacer un esfuerzo por ayudarle y enseñarle todo lo posible.

  • Como todo el código es de todos, hay que hacer un esfuerzo extra por hacer el mejor código que puedas hacer.

    • Cuando programas para ti mismo, puedes tomarte muchas “licencias” y hacer las cosas rápido y sin pensar en el mantenimiento futuro.

    • Pero cuando tu código en realidad es el código de todos, por respeto a ellos, deberías cuidar al máximo su calidad.

  • Si tu código hace que varios test dejen de funcionar, por respeto a los demás miembros, deberías solucionar los problemas lo antes posible.

    • Unos test que no funcionan están invalidando el trabajo de todos.

  • Las críticas siempre deben ser constructivas y deben estar enfocadas en la mejora, no en la crítica destructiva.

Principios

De los cuatro valores deducimos una docena de principios básicos para guiar nuestro nuevo estilo
— Kent Beck
eXtreme Programming

Humanidad

Economía

Beneficio mutuo

Auto-similaridad

Mejora continua

Diversidad

Reflexión

Flujo

Oportunidad

Redundancia

Fallo

Calidad

Baby steps

Responsabilidad aceptada

  • Humanidad

    • Los desarrolladores son personas y como tales tienen necesidades y objetivos personales.

    • La programación extrema es consciente de este aspecto y no considera a las personas como recursos intercambiables.

    • Algunas de las prácticas de XP tienen como objetivo satisfacer, en la medida de lo posible, las necesidades personales de cada miembro del equipo de forma equilibrada con el equipo como conjunto.

    • El razonamiento detrás de este enfoque es muy sencillo, una persona estará involucrada con los objetivos del equipo si en cierta forma esos objetivos están alineados con sus propios objetivos personales.

  • Auto-similaridad

    • Intenta aplicar las cosas que funcionan en otros contextos y a escalas diferentes, porque pueden funcionar también.

    • Esto sobre todo se aplica a los tests:

      • Puedes implementar tests a diario a módulos internos de la aplicación (test unitarios).

      • Pero también puedes implementar test de integración y de aceptación una vez por semana para verificar que la integración del módulos y el sistema completo funciona como se espera.

  • Beneficio mutuo

    • Las tareas tienen que suponer un beneficio para el que las realiza y para el que se beneficia de ellas. Si no es así, esas tareas acabarán realizándose con menos cuidado porque no aportan un valor directo al que las realiza.

    • El caso más representativo es el caso de la escritura de una documentación extensa que explica con detalle el comportamiento de un sistema. Escribir la documentación no aporta ningún valor concreto al que la escribe, porque todo el valor será obtenido por el que consulte la documentación en el futuro.

    • En XP se sustituye la documentación detallada por un conjunto de prácticas que aportan mucho valor al que las realiza y ofrecen incluso más valor que la documentación al que recibe los resultados en el futuro.

    • En concreto, en XP se promueve la escritura de test automatizados, la mejora del diseño de forma continua y la selección de nombres en el código que sean auto-explicativos.

    • Todas estas técnicas aportan mucho valor al que las realiza, porque facilitan la comprensión y mantenibilidad del código hoy.

  • Economía

    • Alguien paga los sueldos. Así que todo el trabajo técnico tiene que estar alineado con los objetivos de negocio.

    • Por eso siempre se intentan implementar cuanto antes las historias de usuario con mayor valor para el negocio.

    • Hay dos cuestiones económicas que afectan al desarrollo software:

      • Valor del dinero en el tiempo: Se refiere a que tener un euro hoy es mejor que tener es mismo euro mañana. Por eso es necesario tener software funcionando cuanto antes. Este tipo de ideas están muy alineados con los conceptos de lean startup, en los que hay que validar el modelo de negocio cuanto antes con los clientes.

      • Valor como opción de futuro: Si el software y el equipo son flexibles y se adaptan al cambio, tendrán mucho más valor que si son fijos y rígidos. Las prácticas técnicas que se proponen tienen la economía muy presente.

  • Mejora continua

    • En el desarrollo software nada es perfecto, pero todo es “perfeccionable”.

    • “Lo perfecto es enemigo de lo bueno” sugiere que algo razonable ahora es mucho mejor que algo perfecto dentro de una semana.

    • Pero siempre hay que tener como objetivo mejorar y perfeccionar eso bueno que acabamos de hacer. Por eso una de las prácticas es la mejora continua del diseño. No se debe sobre-diseñar un sistema, pero a medida que avanza su desarrollo, su diseño tiene que ir mejorando para que el código se mantenga con calidad.

  • Diversidad

    • Los miembros de los equipos de desarrollo tienen que tener diferentes habilidades, experiencia, enfoques.

    • De esta forma el equipo podrá elegir las mejores soluciones en cada caso.

    • Puede ser una fuente de conflictos que tienen que resolverse, por eso XP tiene algunas prácticas que favorecen los espacios de comunicación necesarios para resolver esos conflictos.

  • Reflexión

    • Los buenos equipos no sólo hacen el trabajo, si no que también son conscientes de cómo hacen el trabajo y mejoran de forma continua el proceso con el que hacen el trabajo.

    • Las retrospectivas son una práctica concreta orientada a la mejora del proceso. Tener un espacio para el auto-análisis y la crítica constructiva favorece enormemente al funcionamiento de un equipo.

  • Responsabilidad aceptada

    • La responsabilidad no se puede imponer, sólo se puede aceptar voluntariamente.

    • El equipo que tiene que estimar el coste de hacer ese trabajo y se responsabiliza de cumplir con esa estimación lo mejor que pueda. De igual forma, la persona encarga de implementar una historia de usuario se responsabiliza del diseño, implementación y prueba de dicha historia.

  • Oportunidad

    • Considera los problemas son una oportunidad de mejora.

    • Si un cliente se queja de que una funcionalidad tiene fallos, consideralo como una oportunidad para mejorar la cobertura de tus tests.

    • Si un programador comete muchos errores programando, favorece la programación por pares y la revisión del código.

    • Si enfocamos todos los problemas como oportunidades de mejora, será mucho más probable que el software desarrollado tenga cada vez mayor calidad con un coste razonable.

  • Redundancia

    • La redundancia se aplica en muchos contextos de la informática.

    • No se debería tener un único punto de fallo, ni en los sistemas informáticos ni en los equipos.

    • Ejemplos:

      • Los tests son una forma de redundancia sobre una funcionalidad implementada. Un código actúa de una forma y otro código verifica que actúa como debe actuar.

      • La programación por pares o la revisión del código son una forma de redundancia.

      • La comunicación continua con el cliente son una forma de verificar lo que se pidió en un primer momento.

  • Fallo

    • Hay veces que intentar algo y fallar es mucho mejor que tener interminables reuniones discutiendo las bondades de cada alternativa.

    • Hay gente que denomina “parálisis por análisis” al proceso de sobre-analizar algo elucubrando decenas de variantes y situaciones cuando en realidad se podrían haber implementado dos o tres propuestas y haber realizado un análisis empírico, mucho más efectivo.

    • El fallo es una forma de aprender y si se gestiona de forma adecuada, mucho mejor que el análisis parálisis.

    • El lean startup recomienda fallar rápido y barato, como forma de validar modelos de negocio.

  • Calidad

    • Un proyecto con mayor calidad no es más costoso que otro con menor calidad.

    • En proyectos pequeños, en forma de prototipos, los desarrolladores pueden relajar mucho la calidad del código y ganar con ello algo de time-to-market_.

    • Pero en prácticamente cualquier proyecto real la calidad garantiza que el coste del mantenimiento no se dispara, lo que en el medio plazo reduce los costes y los riesgos del proyecto.

    • Hay veces que la calidad está reñida con la simplicidad. Una solución más mantenible puede ser más compleja y costosa que una solución más simple pero menos mantenible.

    • La regla sería: intenta hacerlo lo mejor que puedas con el tiempo disponible. En la siguiente iteración se mejorará con el trabajo de la primera iteración como base.

    • Esto se puede considerar una pérdida de tiempo, pero también es una forma de luchar contra el análisis parálisis, aportando valor al cliente desde el principio y reduciendo los riesgos.

  • Pasos de niño (Baby steps)

    • Intenta dar los pasos lo más pequeños posibles, eso reducirá los riesgos de fallo de los pasos grandes.

    • Por ejemplo, pasa los test por cada pequeño cambio de código que realices. Eso permitirá detectar más rápidamente los potenciales errores que introduzcas.

    • No esperes dos años a sacar una nueva versión, intenta ofrecer las actualizaciones lo más frecuentes a los usuarios.

    • A priori puede parecer que los pequeños pasos hacen el desarrollo más lento, pero en la práctica, los pequeños pasos permiten mitigar muchos riesgos y los problemas se solucionan mucho más rápido.

  • Flujo

    • Históricamente el desarrollo software se ha realizado de forma discreta en grandes saltos. Las actualizaciones de software ocurrían cada uno o más años, lo que suponía mucho riesgo en forma de retrasos y en forma de rechazo por los usuarios.

    • Actualmente es común que el software se desarrolle de forma continua y predecible. Dependiendo del software puede ser una o dos veces al año, pero hay otros servicios (como algunas aplicaciones web) que se actualizan varias veces en el día.

    • Algoritmo del escalador: consigue un diseño sencillo, entonces lo haces un poco más complejo, después se simplifica y, a continuación, un poco más complejo

    • Las prácticas relacionadas con la integración continua están guiadas por el principio del flujo

  • Realimentación rápida: la psicología del aprendizaje enseña que el tiempo entre una acción y su realimentación es crítico para aprender. Los negocios aprenden cómo el sistema puede contribuir más, y realimentan lo que aprenden de días o semanas en vez de en meses o años. Los programadores aprenden a cómo mejorar a diseñar, implementar y probar el sistema, y realimentan lo aprendido en segundos o minutos en vez de días, semanas o meses

  • Asumir la sencillez: Tratar cada problema como si se pudiese resolver de la forma más sencilla. El tiempo que ahorras en el 98% de los problemas para lo cual es cierto, te dará unos recursos ridículos para aplicarlos al otro 2%. XP propone que hagas un buen trabajo día a día y tengas confianza en tus habilidades para añadir complejidad en el futuro, cuando la necesites.

  • Cambio incremental: Los grandes cambios hechos de una vez no funcionan. Cualquier problema se resuelve con una serie de pequeños cambios que marcan la diferencia: un poco cada vez.

  • Aceptar el cambio: La mejor estrategia es aquella que conserva la mayoría de opciones mientras resuelves tu problema más acuciante.

  • Trabajo de calidad: De las cuatro variables de desarrollo (ámbito, coste, tiempo y calidad), la calidad no es realmente una variable independiente. Los únicos posibles valores son “excelente” o “muy excelente”, dependiendo de si las vidas están o no en juego. De otra manera no disfrutas con tu trabajo, no trabajas bien y el proyecto va directo a la papelera.

  • Enseñar a aprender: Mejor que hacer un conjunto de sentencias doctrinarias tales como “Debes hacer las pruebas XYZ”, nos centramos en enseñar estrategias para aprender cuántas pruebas deberías hacer. Algunas ideas las estableceremos con exactitud. Habrá otras que no tengamos tanta confianza, y aquéllas las estableceremos como estrategias con las cuales el lector pueda aprender sus propias respuestas.

  • Pequeñas inversiones iniciales: Demasiados recursos al comienzo de un proyecto es una receta para el fracaso. Presupuestos escasos fuerzan a los programadores y clientes a recortar los requisitos y las aproximaciones. Centrarse en presupuestos escasos, anima a que se haga un buen trabajo de cualquier que se haga. Si tienes algún imperativo sobre el ámbito, la fecha, calidad o coste, entonces es improbable que seas capaz a una conclusión satisfactoria

  • Jugar a ganar: Muchos desarrollos de software que he visto, juegan a no perder. Se escriben muchos documentos. Se celebran muchas reuniones. Cualquiera intenta hacer un desarrollo de “libro”, no por nada en particular, sino porque quieren ser capaces de decir al final que ellos no han fallado, pues siguieron el proceso. ¡Cubre tu culo! En el desarrollo de software que se juega a ganar, se hace cualquier cosa que ayude al equipo a ganar y nada que no le ayude a ganar

  • Experimentos concretos: Cada vez que tomes una decisión de diseño y no la pruebes, hay alguna probabilidad de que la decisión sea errónea. Muchas de las decisiones que tomas, la mayoría llevan asociado un riesgo. Por lo tanto, el resultado de una sesión de diseño debería ser una serie de experimentos dirigosa los interrogantes surgidos durante la sesión y no un diseño acabado.

  • Comunicación abierta y honesta: Los programadores tienen que ser capaces de explicar las consecuencias de decisiones de otras personas “tú violas la encapsulación aquí y eso realmente ocasiona problemas”. Tienen que ser capaces de decirse el uno al otro dónde hay problemas en el código. Ellos tienen que tener libertad de expresar sus temores, y conseguir ayuda. Ellos tienen que tener la libertad de dar malas noticias a los clientes y directivos, de decirlas pronto y no ser castigados.

  • Trabajar con los instintos de las personas, no contra ellas: Es un engaño, diseñar un proceso donde siguiendo los intereses particulares a corto plazo también sirva a los intereses a largo plazo del equipo. Si XP no puede trabajar con los intereses de la gente a corto plazo, está condenada a ser un método olvidado.

  • Aceptar la responsabilidad: La alternativa es que la responsabilidad sea aceptada, no impuesta. Esto no quiere decir que harás lo que exactamente desees hacer. Eres parte de un equipo, y si el equipo no llega a la conclusión de que cierta tarea necesita hacerse, alguien escogerá hacerla, no importa lo odiosa que sea.

  • Adaptación particular: Tienes que adaptar todo lo que leas en este libro a tus condiciones particulares. Adoptar XP no significa que llego a decidir cómo vas a desarrollar. Significa que decides cómo desarrollar.

  • Ir ligero de equipaje: Las cosas que deberíamos llevar son: pocas, sencillas y valiosas. El equipo XP llega a ser nómada desde el punto de vista intelectual, siempre están preparados para empaquetar las tiendas rápidamente y seguir a la manada. La manada en este caso puede ser un diseño que queremos llevar en una dirección diferente a la que habíamos anticipado, o un cliente que quiere ir en una dirección diferente a la pensada.

Practicas

Confiaremos en las sinergias entre prácticas sencillas, prácticas que a menudo fueron abandonadas décadas atrás como impracticables o ingenuas
— Kent Beck
eXtreme Programming

Practicas2000

Practicas2004
Edición 2000 Edición 2005

  • Estrategias de desarrollo

  • Propiedad colectiva

  • El equipo como una unidad

  • Estándares de Codificación

  • Propiedad compartida del código

  • Integración continua

  • Integración continua

  • Programación por Parejas

  • Programa por pares

  • Estrategia de Diseño

  • Diseño sencillo

  • Diseño emergente y sencillo

  • Recodificacion

  • Código de calidad

  • Metáfora

  • Estrategia de Pruebas

  • Hacer Pruebas

  • Programación dirigida por pruebas

  • Estrategia de Planificación

  • Radiadores de información

  • 40 horas semanales

  • Trabaja las horas razonables para ser productivo

  • Versiones cortas

  • Pequeñas versiones incrementales

  • Cliente in-situ

  • Planifica usando historias de usuario

  • Juego de la Planificaciónes

    • Planificación de la Iteración

  • El ciclo semanal y el ciclo trimestral

    • Margen en la planificación (Slack)

  • Estrategia de Instalaciones

  • El equipo debe estar junto
Las prácticas se apoyan entre sí. La debilidad de una se cubre con los puntos fuertes de las otras.
— Kent Beck
eXtreme Programming

Estrategias de Desarrollo

- Estándares de Codificación - El equipo como una unidad

  • por la propiedad colectiva, no puedes permitirte tener diferentes tipos de normas de codificación

  • Uno de los secretos para que un proyecto tenga éxito, es que el equipo esté unido en la consecución de los objetivos del mismo.

  • El equipo debe incluir todos los perfiles necesarios para la consecución de los objetivos del proyecto.

    • Es mejor dividir a los equipos por proyecto que por tipo de tareas.

    • Es mejor que en un mismo equipo exista una persona experta en experiencia de usuario, varios desarrolladores y un administrador de sistemas en vez de tener departamentos de experiencia de usuario, departamentos de desarrollo y departamentos de sistemas que se encarguen entre ellos de varios proyectos.

  • Focalizar en un proyecto, con unos clientes concretos y con unos compañeros concretos ayuda a implicarse con el proyecto, a tener la sensación de equipo y a conseguir mejor los objetivos.
- Propiedad colectiva - Propiedad compartida del código

  • Cualquier persona puede cambiar cualquier parte del código del sistema en cualquier momento. Así, el código complejo no dura mucho tiempo, porque todo el mundo

  • Cuando el equipo es un conjunto de desarrolladores que tienen que realizar un producto software, esto se traduce en que todo el código es de todos, independientemente de quién haya escrito cada línea.

    • No hay propiedad del código.

    • Para conseguir esto, habitualmente se hacen revisiones de código de unos desarrolladores a otros, y los desarrolladores participan en varias partes del código a lo largo del proyecto.

    • Esto también fomenta la colaboración entre los miembros del equipos, los miembros con mejores capacidades técnicas enseñarán a los novatos cuales son las mejores técnicas.

    • Al fin y al cabo, todos los desarrolladores deben sentirse cómodos con todo el código, como si hubiese estado escrito por ellos mismos.
- Integración continua - Integración continua

  • el código no puede permanecer sin integrarse más de un par de horas. Al final de cada episodio de desarrollo, el código es integrado con la última versión y todas las pruebas deben funcionar al 100%

  • Cuando varios desarrolladores colaboran para desarrollar un producto software cada uno se encarga de programar una funcionalidad.

  • La integración de los módulos desarrollados por cada uno de los integrantes del equipo no es una tarea que debe tomarse muy en serio dentro del proceso de desarrollo.

  • Cuanto más tiempo pase desde la última integración, más probabilidad habrá de que la integración no sea satisfactoria.
- Programación por Parejas - Programa por pares

  • no significa que una persona programe mientras la otra mira. Es un diálogo entre dos personas que intentan simultáneamente programar (y analizar, diseñar y probar) y comprender juntos cómo programar mejor. En principio, no podrías escribir todo el código de producción en parejas pero la calidad del código resultante es mucho mayor.

  • Dos desarrolladores programan a la misma vez en el mismo código, sentados uno al lado del otro.

    • Cuando el código que hay que desarrollar es complejo, esta técnica reduce el tiempo de desarrollo y el código tiene mucha más calidad, menos errores y es más comprensible.

  • Habitualmente hay dos roles en cada pareja:

    • El programador que controla el teclado y el ratón y va programando los tests o el código y piensa cómo es la mejor forma de desarrollar la funcionalidad.

    • El otro programador que está pensando de manera más estratégica porque tiene una visión más global.

      • Al estar liberado de la escritura, se puede hacer las siguientes preguntas: ¿Es esta aproximación correcta? ¿Hay más casos de test que convendría implementar para verificar la funcionalidad? ¿Hay alguna manera de simplificar el sistema?

Estrategia de Diseño

- Diseño sencillo - Diseño emergente y sencillo

  • En la primera utilización solamente pagas lo que debes.

    • implementarás algo de una forma muy simple la primera vez que te lo encuentres.

  • La segunda vez que lo utilices, lo harás más general.

    • En la segunda utilización pagas por la flexibilidad.

  • De esta forma nunca paga por la flexibilidad que no utilizas, y tiendes a hacer el sistema flexible donde necesita ser flexible para la tercera, cuarta y quinta variación.

  • Cuatro imperativos en orden:

    • El sistema (código y pruebas junto) debe comunicar todo lo que quieres comunicar

    • El sistema no debe contener código duplicado

    • El sistema debería tener el menor número posible de clases

    • El sistema debería tener el menor número posible de métodos

  • Durante el desarrollo software hay que tener muchas cosas bajo control, pero una de las más peligrosas es la complejidad.

  • Hay veces que las cosas son complicadas porque son esencialmente complicadas (complejidad intrínseca), pero otras veces, las complejidad la provocamos nosotros por las herramientas que usamos, por el contexto, la inercia o la ignorancia (complejidad accidental)

  • La programación extrema te propone que intentes que tu diseño sea siempre lo más sencillo posible para la funcionalidad que tienes implementada hasta ese momento.

  • Y si en el futuro necesitas incorporar nueva funcionalidad y tu código actual no está preparado para admitir esa nueva funcionalidad, que ajustes tu código actual (mediante la refactorización) para permitir esa nueva funcionalidad.

  • Es decir, la regla de oro es “no intentes anticipar todas las posibles ampliación del futuro”, porque es posible que esas ampliaciones nunca lleguen (recuerda YAGNI).
- Refactoring - Código de calidad

  • un cambio en el sistema que lo deja sin cambios en su comportamiento, pero mejora alguna característica no funcional (sencillez, flexibilidad, comprensión, rendimiento).

  • XP recomienda que el código tiene que tener buena calidad a lo largo del proyecto.

  • Es la única garantía de que el software será mantenible, ampliable, predecible y libre de defectos

  • Un código es de calidad en función de muchos aspectos:

    • Buenos valores en las métricas que analizan el código

    • Sigue los principios del código limpio (SOLID, nombres de variables adecuados…​)

    • No tiene malos olores (Código duplicado, Listas de parámetros cortas, clases cortas…​)

  • A medida que el código crece porque se añaden nuevas funcionalidades, generalmente se suele degradar su calidad

  • La única forma de mantener la calidad del código constante es refactorizar de forma constante para acomodar las nuevas funcionalidades

  • La única forma de refactorizar con garantías es tener una buena batería de tests que verifiquen que no hay regresiones
- Metáfora

  • una historia que todos (clientes, programadores y directores de proyecto) pueden contar sobre cómo funciona el sistema. Sustituye mucho de lo que otra gente llama “arquitectura”

Estrategia de Pruebas

- Hacer Pruebas - Programación dirigida por pruebas

  • Si la interfaz de un método no está clara, escribe una prueba antes de escribir el método

  • Si la interfaz está clara, pero imagina que la implementación podría ser un poco menos complicada, escribe una prueba antes de escribir el método

  • Si piensa en una circunstancia no usual en la cual el código debiera funcionar conforme está escrito, escribe una prueba para comunicar la circunstancia

  • Si encuentra un problema posterior, escribe una prueba que aísla el problema

  • Si esta haciendo refactorización en algún código, y no está seguro de cómo debe ser su comportamiento, y todavía no hay una prueba para dicho comportamiento en cuestión, escribe una primera prueba

  • Ciclo de desarrollo:

    • 1. Rojo: implementación del test de una nueva funcionalidad

      • Comprobación de que el test falla (no está implementada la funcionalidad, métodos vacíos)

    • 2. Verde: implementación de lo mínimo para que el test pase. Con nuevos casos de prueba se tiene que amoldar el código, posiblemente generalizando

      • Comprobación de que el test pasa

    • 3. Refactor: mejora de la calidad del código que ya funciona

      • Red de seguridad de pruebas es nuestro segundo “compilador”

  • ¿Crítica?

Estrategia de Planificación

- Usa radiadores de información

  • Cada miembro del equipo tiene que conocer el estado del desarrollo de la iteración actual y del proyecto en su conjunto.

  • Cada miembro del equipo tiene que saber cual es la mejor tarea que puede desarrollar en cada momento por el bien del equipo.

  • Esto se puede conseguir de muchas formas:

    • Herramientas software de gestión de tareas (Redmine, Taiga, Jira, Trello…​)

    • Se puede usar un “rudimentario” excel compartido en el que cada fila representa una tarea y están organizadas por orden de prioridad

  • Gestión visual, visual managment: el avance del proyecto es visible para todos en un mural.

    • Para ello, utilizan post-its que son fáciles de escribir, desechar y mover.

    • Cada post-it representa una historia de usuario en una fila.

    • Cada historia de usuario se divide en tareas, y para cada una de ellas también se usa un post-it.

    • Es habitual tener una pizarra con columnas. Cada columna representa el estado de la tarea: Lista, En progreso, Finalizada, Con impedimentos.
- 40 horas semanales - Trabaja las horas razonables para ser productivo

  • si el equipo no está fresco y con energías, no será capaz de llevar a cabo el resto de las prácticas.

  • El desarrollo de software es un tipo de tarea tan especial que parece que podemos estar programando todo el día simplemente con un poco de café a nuestro lado.

  • El problema es que llegado a un punto, la productividad cae y empezamos a cometer errores que producen más daño que el beneficio que podríamos obtener por haber trabajado más horas.

Sintesis

Bibliografía

Obra, Autor y Editor Portada Obra, Autor y Editor Portada

  • Refactoring (Pearson Addison-Wesley Signature Series)

    • Fowler Martin

    • Financial Times Prentice Hall; Edición: 01 (28 de noviembre de 2018)

height32

  • Test Driven Development. By Example (The Addison-Wesley Signature Series

    • Beck Kent

    • Addison Wesley; Edición: 01 (8 de noviembre de 2002)

height32

  • Extreme Programming Explained: Embrace Change: Embracing Change

    • Kent Beck, Cynthia Andres

    • Addison-Wesley Educational Publishers Inc; Edición: 2nd edition (16 de noviembre de 2004)

height32

  • Planning Extreme Programming (The Xp Series)

    • Beck Kent, Fowler Martin

    • Addison Wesley; Edición: 01 (16 de octubre de 2000)

height32

  • Scrum and XP from the Trenches (Enterprise Software Development)

    • Henrik Kniberg

    • Lulu.com; Edición: 1 (4 de octubre de 2007)

height32

  • Scrum: El revolucionario método para trabajar el doble en la mitad de tiempo

    • Jeff Sutherland,

    • Editorial Ariel (20 de enero de 2015)

height32

  • Refactoring Databases: Evolutionary Database Design

    • Scott J Ambler, Pramod J. Sadalage

    • Addison-Wesley Professional; Edición: 1 (13 de marzo de 2006)

height32

  • User Stories Applied: For Agile Software Development

    • Cohn, M.

    • Addison Wesley, 2004

UserStoriesAppliedForAgileSoftwareDevelopment

  • Scrum y XP desde las trincheras

    • Henrik Kniberg. Prólogos de Jeff Sutherland y Mike Cohn

    • proyectalis.com

ScrumXPTrenches

  • Diseño Ágil con TDD

    • Carlos Blé Jurado

    • Lulu.com

DisenoAgilconTDD

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM