¿Qué es?

La programación extrema o XP es una metodología de desarrollo que se englobaría dentro de las denominadas metodologías Ágiles en la que se da máxima prioridad a la obtención de resultados y reduce la burocracia que se produce al utilizar otras ‘metodologías pesadas’.

"Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar."

 

Kent Beck.

Objetivos

El objetivo principal de la XP es la satisfacción del cliente.

Se le trata de dar al cliente lo que quiere y cuando quiere.Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto.

Como metodología Ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.

Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.

Valores de la programación extrema

Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores:

Comunicación

Muy importante. La XP ayuda mediante sus prácticas a la comunicación entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y desarrolladores.

Sencillez

Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos.

No hay que añadir algo que no se necesite hoy.

Si se necesita añadir más funcionalidad mañana pues ya se hará entonces.

Retroalimentación

Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.

Valentía

Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias no existe el riesgo de ‘meter la pata’.

Algunas voces, añaden además un quinto valor: la humildad.

Al compartir el código, la refactorización y el trabajo de equipo tan estrecho una buena dosis de humildad siempre es de agradecer.

Prácticas de la programación extrema

Son 12 las prácticas de la XP

1. El juego de la planificación

Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).

2. Pequeñas entregas

Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, no puedes implementar media característica y lanzar la versión.

Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.

3. Metáfora

Una metáfora es una historia que todo el mundo puede contar acerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas «Programa de gestión de compras, ventas, con gestión de cartera y almacén». Las metáforas ayudan a cualquier persona a entender el objeto del programa.

4. Diseño sencillo

Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo más simple posible, después de implementar esta característica, nos preguntamos cómo hacer el programa más simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring).

 

Esto a veces nos puede llevar a hacer más trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características.

 

No debemos de recodificar ante especulaciones si no solo cuando el sistema te lo pida.

5. Pruebas

No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales.

 

El resultado, un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.

6. Refactorización

Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo más simple posible, después de implementar esta característica, nos preguntamos cómo hacer el programa más simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring).

 

Esto a veces nos puede llevar a hacer más trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características.

 

No debemos de recodificar ante especulaciones si no solo cuando el sistema te lo pida.

7. Programación por parejas

Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa más estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?

 

El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera.

8. Propiedad colectiva

Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo.

 

Si hacemos el código propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejándonos cada vez más de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.

9. Integración continua

El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargará de integrar todo el código en una máquina y realizar todas las pruebas hasta que estas funcionen al 100%.

10. 40 horas semanales

Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar en algo distinto y volver el lunes lleno de pasión e ideas.

 

Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado.

 

Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.

11. Cliente en casa

Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades.

Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo, normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.

12. Estándares de codificación

Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.

Esta palabra, de origen japonés, se puede traducir como “tarjeta” o “cartón”. Representa un sistema que tiene como objetivo aumentar la eficiencia de la producción de una empresa y es esencial hoy en día.

 

Desarrollado por Taiichi Ohno Ingeniero de Toyota en la década de 1940, su simplicidad y beneficios lo convirtieron en uno de los métodos más utilizados por empresas de todos los segmentos.

El método fue desarrollado por Taiichi Ohno en Toyota y, en resumen, es una forma de registrar tareas y acciones a través de simbologías visuales.

 

Originalmente, se trata de un sistema de gestión y control de inventario y flujo de piezas que utiliza pequeñas hojas de papel autoadhesivo, conocidas como post-its.

 

También recibe el nombre de gestión visual debido al uso de los colores como señalización.

¿Qué es?

La tabla más simple de Kanban puede comenzar con tres columnas: "Solicitado", "En progreso" y "Hecho". Cuando se construye, gestiona y funciona correctamente, sirve como depósito de información en tiempo real, poniendo de relieve los cuellos de botella del sistema y cualquier otra cosa que pueda obstaculizar las prácticas de trabajo sin problemas.

Los 4 principios básicos de Kanban

David J. Anderson (pionero en el campo de Lean/Kanban para el trabajo del conocimiento) ha formulado el método Kanban como un enfoque para el cambio incremental, evolutivo de procesos y sistemas para las organizaciones de trabajo del conocimiento.

Se centra en conseguir que las cosas se hagan y los principios más importantes pueden desglosarse en cuatro principios básicos y seis prácticas.

Principio 1: Empieza con lo que haces ahora

La flexibilidad de Kanban permite aplicarlo a los flujos de trabajo, sistemas y procesos existentes sin interrumpir lo que ya se está haciendo con éxito; naturalmente, pondrá de relieve las cuestiones que deben abordarse y ayudará a evaluar y planificar los cambios para que su aplicación sea lo menos perjudicial posible.

 

La versatilidad de Kanban permite que se introduzca de forma gradual, y con simpatía, en todo tipo de organizaciones sin temor a un compromiso excesivo o a un "choque cultural". Esto hace que Kanban sea fácil de implementar en cualquier tipo de organización ya que no hay necesidad de hacer cambios radicales desde el principio.

Principio 3: Respetar el proceso, los roles y las responsabilidades actuales

La metodología de Kanban está diseñada para encontrar una resistencia mínima y por lo tanto, fomenta pequeños y continuos cambios incrementales y evolutivos en el proceso actual. En general, se desalienta la realización de cambios radicales porque normalmente encuentran dificultades debido al miedo o a la incertidumbre.

Principio 4: Fomentar actos de liderazgo a todos los niveles

Este es el más reciente principio de Kanban. Te recuerda que algunos de los mejores liderazgos vienen de los actos diarios de la gente en la primera línea de sus equipos. Es importante que todos fomenten una mentalidad de mejora continua (Kaizen) para alcanzar un rendimiento óptimo a nivel de equipo/departamento/empresa. Esta no puede ser una actividad de nivel gerencial.

Las 6 prácticas de Kanban

Aunque abrazar la filosofía de Kanban y emprender el viaje de transición es el paso más importante, toda organización debe tener cuidado con los pasos prácticos. Hay seis prácticas básicas identificadas por David Anderson que deben estar presentes para una implementación exitosa.

1. Visualizar el flujo de trabajo

Tablero basico de Kanban

Cuando se comienza a trabajar en el ítem X, lo saca de la columna "Por hacer" y cuando se completa, lo mueve a "Hecho". De esta manera, puede seguir fácilmente el progreso y detectar los cuellos de botella.

Para visualizar su proceso con un sistema Kanban, se necesita un tablero con tarjetas y columnas. Cada columna en el tablero representa un paso en su flujo de trabajo. Cada tarjeta Kanban representa un elemento de trabajo.

Cambiar el enfoque de un equipo a mitad de camino por lo general perjudicará el proceso, y la multitarea es una ruta segura para generar desperdicio e ineficiencia; una función principal de Kanban es asegurar un número manejable de artículos activos en progreso en cualquier momento. Si no hay límites de trabajo en curso, no se está haciendo el Kanban.

2. Limitar el trabajo en progreso (WIP)

Limitar el WIP significa que se implementa un sistema de arrastre en partes o en todo el flujo de trabajo. Establecer un máximo de elementos por etapa asegura que una tarjeta sólo sea "tirada" en el siguiente paso cuando hay capacidad disponible. Tales restricciones iluminarán rápidamente las áreas problemáticas en su flujo para que pueda identificarlas y resolverlas.

● Limitar el WIP normalmente aumenta el flujo
de trabajo
● Limitar el WIP no significa hacer menos cosas,
significa: Hacer menos cosas a la vez
● A mayor WIP, menor Lead-time o plazo de
entrega
● Normalmente, con sólo bajar o limitar el WIP
se produce una mejora notable

Limitar el WIP

Ley de little

WIP = 16

Throughput = 2

16/2 = 8 días

Ley de little

WIP = 8

Throughput = 2

8/2 = 4 días

Sólo se ha cambiado el WIP, todo lo demás: capacidad del equipo, tamaño del mismo, carga de trabajo, etc... sigue igual

La idea de implementar un sistema Kanban es crear un flujo suave y saludable. Por flujo, se refiere al movimiento de elementos de trabajo a través del proceso de producción.

 

Por lo tanto, manejar el flujo se trata de manejar el trabajo pero no las personas. Así que en lugar de microgestionar a las personas y tratar de mantenerlas ocupadas todo el tiempo, debemos centrarnos en la gestión de los procesos de trabajo y entender cómo hacer que el trabajo pase más rápido por el sistema.

 

Idealmente, queremos un flujo rápido y suave. Esto significa que nuestro sistema está creando valor rápidamente. De esta manera podemos minimizar el tiempo promedio del ciclo de producción y evitar el costo de la demora, pero de manera predecible.

3. Manejar el flujo

No puedes mejorar algo que no entiendes. Por eso el proceso debe ser claramente definido, publicado y socializado. La gente no se asociaría y participaría en algo que no cree que sea útil.

 

Cuando todos están familiarizados con el objetivo común, podrían trabajar y tomar decisiones con respecto a un cambio que te llevará en una dirección positiva

4. Hacer explícitas las políticas del proceso

Para que el cambio positivo ocurra, tenga éxito y continúe, hay que hacer una cosa más. La filosofía Lean apoya la suposición de que las reuniones regulares son necesarias para la transferencia de conocimientos (bucles de retroalimentación).

 

Tales son las reuniones diarias de "stand up" para la sincronización del equipo. Se celebran delante de la junta de Kanban y cada miembro dice a los demás lo que hizo el día anterior y lo que hará hoy.

 

La duración media ideal de una reunión de examen debería ser de entre 10 y 15 minutos, y otras pueden llegar hasta una hora, dependiendo del tamaño del equipo y de los temas.

5. Circuitos de retroalimentación

La forma de lograr una mejora continua y un cambio sostenible dentro de una organización es a través de la visión compartida de un futuro mejor y la comprensión colectiva de los problemas que deben superarse.

Los equipos que tienen una comprensión compartida de las teorías sobre el trabajo, el flujo de trabajo, el proceso y el riesgo tienen más probabilidades de construir una comprensión compartida de un problema y sugerir pasos hacia la mejora, que pueden ser acordados por consenso.

6. Mejorar en colaboración (usando modelos y el método científico)