Prácticas extremas de programación - Extreme programming practices

La programación extrema ( XP ) es unametodología de desarrollo de software ágil que se utiliza para implementarproyectos de software . Este artículo detalla las prácticas utilizadas en esta metodología. La programación extrema tiene 12 prácticas, agrupadas en cuatro áreas, derivadas de las mejores prácticas de la ingeniería de software .

Retroalimentación de escala fina

Programación en pareja

La programación por pares significa que todo el código es producido por dos personas que programan en una tarea en una estación de trabajo. Un programador tiene control sobre la estación de trabajo y está pensando principalmente en la codificación en detalle. El otro programador está más centrado en el panorama general y está revisando continuamente el código que está produciendo el primer programador. Los programadores intercambian roles después de períodos de minutos a horas.

Los pares no son fijos; Los programadores cambian de socio con frecuencia, de modo que todos sepan lo que están haciendo y todos estén familiarizados con todo el sistema, incluso con las partes fuera de su conjunto de habilidades. De esta manera, la programación por pares también puede mejorar la comunicación en todo el equipo. (Esto también va de la mano con el concepto de Propiedad Colectiva).

Juego de planificación

El proceso de planificación principal dentro de la programación extrema se llama el juego de planificación. El juego es una reunión que ocurre una vez por iteración, generalmente una vez a la semana. El proceso de planificación se divide en dos partes:

  • Planificación de versiones : se centra en determinar qué requisitos se incluyen en qué versiones a corto plazo y cuándo deben entregarse. Tanto los clientes como los desarrolladores son parte de esto. La planificación de la versión consta de tres fases:
    • Fase de exploración: en esta fase, el cliente proporcionará una lista corta de requisitos de alto valor para el sistema. Estos se escribirán en tarjetas de historias de usuario .
    • Fase de compromiso: dentro de la fase de compromiso, las empresas y los desarrolladores se comprometerán con la funcionalidad que se incluirá y la fecha del próximo lanzamiento.
    • Fase de dirección: En la fase de dirección, el plan se puede ajustar, se pueden agregar nuevos requisitos y / o se pueden cambiar o eliminar los requisitos existentes.
  • Planificación de iteraciones : planifica las actividades y tareas de los desarrolladores. En este proceso el cliente no está involucrado. La planificación de la iteración también consta de tres fases:
    • Fase de exploración: Dentro de esta fase el requisito se traducirá en diferentes tareas. Las tareas se registran en tarjetas de tareas.
    • Fase de Compromiso: Se asignarán las tareas a los programadores y se estimará el tiempo que se tarda en completar.
    • Fase de dirección: las tareas se realizan y el resultado final se compara con la historia del usuario original.

El propósito del juego de planificación es guiar el producto hasta la entrega. En lugar de predecir las fechas exactas de cuándo se necesitarán y producirán los entregables, lo cual es difícil de hacer, su objetivo es "dirigir el proyecto" hacia la entrega utilizando un enfoque sencillo. El enfoque del juego de planificación también ha sido adoptado por equipos y proyectos que no son de software en el contexto de la agilidad empresarial .

Planificación de lanzamientos

Fase de exploración

Este es un proceso iterativo de recopilación de requisitos y estimación del impacto laboral de cada uno de esos requisitos.

  • Escribe una historia: los negocios han llegado con un problema; Durante una reunión, el desarrollo intentará definir este problema y obtener requisitos. En función del problema empresarial, se debe escribir una historia ( historia de usuario ). Esto lo hacen las empresas, donde señalan lo que quieren que haga una parte del sistema. Es importante que el desarrollo no influya en esta historia. La historia está escrita en una tarjeta de historia de usuario.
  • Estimar una historia: Desarrollo estima cuánto tiempo llevará implementar el trabajo implícito en la tarjeta de la historia. El desarrollo también puede crear soluciones de picos para analizar o resolver el problema. Estas soluciones se utilizan para la estimación y se descartan una vez que todos obtienen una visualización clara del problema. Nuevamente, esto puede no influir en los requisitos comerciales.
  • Dividir una historia: cada complejidad crítica del diseño debe abordarse antes de comenzar la planificación de la iteración. Si el desarrollo no puede estimar la historia, es necesario dividirla y escribirla nuevamente.

Cuando la empresa no puede presentar más requisitos, se pasa a la fase de compromiso.

Fase de compromiso

Esta fase implica la determinación de costos, beneficios e impacto del cronograma. Tiene cuatro componentes:

  • Ordenar por valor: Business clasifica las historias de usuario por valor empresarial .
  • Ordenar por riesgo: Desarrollo ordena las historias por riesgo.
  • Establecer velocidad: El desarrollo determina a qué velocidad pueden realizar el proyecto.
  • Elija el alcance: se seleccionarán las historias de usuario que se terminarán en la próxima versión. Según las historias de los usuarios, se determina la fecha de lanzamiento.
Ordenar por valor

El lado empresarial clasifica las historias de usuario por valor empresarial. Los organizarán en tres pilas:

  • Crítico: historias sin las cuales el sistema no puede funcionar o no tiene sentido.
  • Valor comercial significativo : historias de usuarios no críticas que tienen un valor comercial significativo.
  • Es bueno tener: historias de usuarios que no tienen un valor comercial significativo.
Ordenar por riesgo

Los desarrolladores clasifican las historias de usuarios por riesgo. También se clasifican en tres grupos: historias de usuarios de riesgo bajo, medio y alto. El siguiente es un ejemplo de un enfoque para esto:

  • Determine el índice de riesgo: proporcione a cada historia de usuario un índice de 0 a 2 en cada uno de los siguientes factores:
    • Integridad (¿conocemos todos los detalles de la historia?)
      • Completo (0)
      • Incompleto (1)
      • Desconocido (2)
    • Volatilidad (¿es probable que cambie?)
      • baja (0)
      • mediano (1)
      • alto (2)
    • Complejidad (¿qué tan difícil es construir?)
      • simple (0)
      • estándar (1)
      • complejo (2)

Se agregan todos los índices de una historia de usuario, asignándole a las historias de usuario un índice de riesgo bajo (0-1), medio (2-4) o alto (5-6).

Fase de dirección

Dentro de la fase de dirección, los programadores y la gente de negocios pueden "dirigir" el proceso. Es decir, pueden realizar cambios. Las historias de usuarios individuales, o las prioridades relativas de diferentes historias de usuarios, pueden cambiar; las estimaciones pueden resultar erróneas. Esta es la oportunidad de ajustar el plan en consecuencia.

Planificación de iteraciones

Teniendo en cuenta los puntos de historia de la velocidad del equipo a planificar. La duración de la iteración puede ser de 1 a 3 semanas.

Fase de exploración

La fase de exploración de la planificación de la iteración se trata de crear tareas y estimar su tiempo de implementación.

  • Traducir el requisito a tareas: Colóquelo en tarjetas de tareas.
  • Combinar / dividir tarea: si el programador no puede estimar la tarea porque es demasiado pequeña o demasiado grande, el programador deberá combinar o dividir la tarea.
  • Estimar la tarea: Estime el tiempo que tomará implementar la tarea.
Fase de compromiso

Dentro de la fase de compromiso de la planificación de la iteración, a los programadores se les asignan tareas que hacen referencia a las diferentes historias de usuario.

  • Un programador acepta una tarea: cada programador elige una tarea de la que asume la responsabilidad.
  • El programador estima la tarea: debido a que el programador ahora es responsable de la tarea, debe dar la estimación final de la tarea.
  • Establecer factor de carga: el factor de carga representa la cantidad ideal de tiempo de desarrollo práctico por programador dentro de una iteración. Por ejemplo, en una semana de 40 horas, con 5 horas dedicadas a reuniones, esto no sería más de 35 horas.
  • Equilibrio: cuando a todos los programadores del equipo se les han asignado tareas, se hace una comparación entre el tiempo estimado de las tareas y el factor de carga. Luego, las tareas se equilibran entre los programadores. Si un programador está comprometido en exceso, otros programadores deben hacerse cargo de algunas de sus tareas y viceversa.
Fase de dirección

La implementación de las tareas se realiza durante la fase de dirección de la iteración.

  • Obtener una tarjeta de tarea: el programador obtiene la tarjeta de tarea para una de las tareas a las que se ha comprometido.
  • Encuentre un socio: el programador implementará esta tarea junto con otro programador. Esto se analiza con más detalle en la práctica Programación por parejas .
  • Diseñar la tarea: si es necesario, los programadores diseñarán la funcionalidad de la tarea.
  • Implementar la tarea mediante el desarrollo basado en pruebas (TDD) (ver más abajo)
  • Ejecutar prueba funcional: se ejecutan pruebas funcionales (basadas en los requisitos de la historia de usuario y la tarjeta de tareas asociadas).

Desarrollo impulsado por pruebas

Las pruebas unitarias son pruebas automatizadas que prueban la funcionalidad de partes del código (por ejemplo, clases, métodos). En XP, las pruebas unitarias se escriben antes de codificar el código final. Este enfoque tiene como objetivo estimular al programador a pensar en las condiciones en las que su código podría fallar. XP dice que el programador ha terminado con un cierto fragmento de código cuando no puede encontrar más condiciones bajo las cuales el código puede fallar.

El desarrollo impulsado por pruebas avanza cíclicamente rápidamente a través de los siguientes pasos, y cada paso toma minutos como máximo, preferiblemente mucho menos. Dado que cada historia de usuario generalmente requerirá de uno a dos días de trabajo, se necesitará una gran cantidad de estos ciclos por historia.

  • Prueba unitaria de escritura : los programadores escriben una prueba mínima que debería fallar porque la funcionalidad no se ha implementado completamente en el código de producción.
  • Observe cómo falla la nueva prueba: los programadores verifican que la prueba sí falla. Si bien puede parecer una pérdida de tiempo, este paso es fundamental porque verifica que su creencia sobre el estado del código de producción es correcta. Si la prueba no falla, los programadores deben determinar si hay un error en el código de prueba o si el código de producción es compatible con la funcionalidad descrita por la nueva prueba.
  • Escribir código: los programadores escriben solo el código de producción suficiente para que pase la nueva prueba.
  • Ejecutar prueba: las pruebas unitarias se ejecutan para verificar que el nuevo código de producción pase la nueva prueba y que ninguna otra prueba esté fallando.
  • Refactorización : elimine los olores de código tanto del código de producción como de prueba.

Para obtener una versión más intensa del proceso anterior, consulte Tres reglas de TDD del tío Bob.

Todo el equipo

Dentro de XP, el "cliente" no es el que paga la factura, sino el que realmente usa el sistema. XP dice que el cliente debe estar disponible en todo momento y disponible para preguntas. Por ejemplo, el equipo que desarrolla un sistema de administración financiera debe incluir un administrador financiero.

Proceso continuo

Integración continua

El equipo de desarrollo siempre debe estar trabajando en la última versión del software. Dado que los diferentes miembros del equipo pueden tener versiones guardadas localmente con varios cambios y mejoras, deben intentar cargar su versión actual en el repositorio de código cada pocas horas, o cuando se presente una interrupción significativa. La integración continua evitará retrasos posteriores en el ciclo del proyecto, provocados por problemas de integración.

Mejora de diseño

Debido a que la doctrina XP aboga por programar solo lo que se necesita hoy, e implementarlo de la manera más simple posible, a veces esto puede resultar en un sistema que se atasca. Uno de los síntomas de esto es la necesidad de un mantenimiento dual (o múltiple): los cambios funcionales comienzan a requerir cambios en múltiples copias del mismo (o similar) código. Otro síntoma es que los cambios en una parte del código afectan a muchas otras partes. La doctrina XP dice que cuando esto ocurre, el sistema le dice que refactorice su código cambiando la arquitectura, haciéndolo más simple y más genérico.

Pequeños lanzamientos

La entrega del software se realiza a través de lanzamientos frecuentes de funciones en vivo que crean un valor concreto. Los pequeños lanzamientos ayudan al cliente a ganar confianza en el avance del proyecto. Esto ayuda a mantener el concepto de todo el equipo, ya que el cliente ahora puede presentar sus sugerencias sobre el proyecto basándose en la experiencia real.

Entendimiento compartido

Estándar de codificación

El estándar de codificación es un conjunto de reglas acordadas que todo el equipo de desarrollo acuerda cumplir durante todo el proyecto. El estándar especifica un estilo y formato coherentes para el código fuente, dentro del lenguaje de programación elegido, así como varias construcciones y patrones de programación que deben evitarse para reducir la probabilidad de defectos. El estándar de codificación puede ser un convenio estándar especificado por el proveedor del lenguaje (por ejemplo, las convenciones de código para el lenguaje de programación Java, recomendado por Sun), o definido por el equipo de desarrollo.

Los patrocinadores de Extreme Programming abogan por un código que se documente a sí mismo en la mayor medida posible. Esto reduce la necesidad de comentarios de código , que pueden desincronizarse con el código en sí.

Propiedad colectiva del código

La propiedad colectiva del código (también conocida como "propiedad del código de equipo" y "código compartido") significa que todos son responsables de todo el código; por lo tanto, todos pueden cambiar cualquier parte del código. La propiedad colectiva del código no es solo una política organizacional, sino también un sentimiento. "Los desarrolladores sienten más la propiedad del código del equipo cuando comprenden el contexto del sistema, han contribuido al código en cuestión, perciben la calidad del código como alta, creen que el producto satisfará las necesidades del usuario y perciben una alta cohesión del equipo". La programación de pares, especialmente la rotación de pares superpuestos, contribuye a esta práctica: al trabajar en pares diferentes, los programadores comprenden mejor el contexto del sistema y contribuyen a más áreas de la base del código.

La propiedad colectiva del código puede acelerar el desarrollo porque un desarrollador que detecta un error puede solucionarlo de inmediato, lo que puede reducir los errores en general. Sin embargo, los programadores también pueden introducir errores al cambiar el código que no comprenden bien. Las pruebas unitarias suficientemente bien definidas deberían mitigar este problema: si las dependencias imprevistas crean errores, cuando se ejecutan las pruebas unitarias, mostrarán fallas.

La propiedad colectiva del código puede conducir a una mejor copia de seguridad de los miembros, una mayor distribución del conocimiento y el aprendizaje, una responsabilidad compartida del código, una mayor calidad del código y una reducción de la reelaboración. Pero también puede conducir a un mayor conflicto de miembros, aumento de errores, cambios en el flujo mental de los desarrolladores y rupturas de su razonamiento, aumento del tiempo de desarrollo o menor comprensión del código.

Diseño simple

Los programadores deben adoptar un enfoque de "lo simple es lo mejor" para el diseño de software. Siempre que se escribe una nueva pieza de código, el autor debe preguntarse "¿hay una forma más sencilla de introducir la misma funcionalidad?". Si la respuesta es afirmativa, se debe elegir el curso más simple. La refactorización también debe usarse para simplificar el código complejo.

Metáfora del sistema

La metáfora del sistema es una historia que todos (clientes, programadores y gerentes) pueden contar sobre cómo funciona el sistema. Es un concepto de nomenclatura para clases y métodos que debería facilitar que un miembro del equipo adivine la funcionalidad de una clase / método en particular, solo por su nombre. Por ejemplo, un sistema de biblioteca puede crear loan_records(class)para borrowers(class), y si el ítem llegara a estar vencido, puede realizar una operación make_overdue en un archivo catalogue(class). Para cada clase u operación, la funcionalidad es obvia para todo el equipo.

Bienestar del programador

Marcha sostenible

El concepto es que los programadores o desarrolladores de software no deberían trabajar más de 40 horas a la semana, y si hay horas extras una semana, que la próxima semana no deberían incluir más horas extras. Dado que los ciclos de desarrollo son ciclos cortos de integración continua, y los ciclos de desarrollo completo (lanzamiento) son más frecuentes, los proyectos en XP no siguen el tiempo crítico típico que requieren otros proyectos (que requieren tiempo extra).

Además, en este concepto se incluye que las personas se desempeñan mejor y más creativamente si descansan bien.

Un habilitador clave para lograr un ritmo sostenible es la combinación frecuente de código y el código de alta calidad siempre ejecutable y cubierto por pruebas. La forma de trabajo de refactorización constante hace que los miembros del equipo tengan mentes frescas y alertas. La intensa forma colaborativa de trabajar dentro del equipo impulsa la necesidad de recargar energías durante los fines de semana.

El código y los entornos bien probados, integrados continuamente y que se implementan con frecuencia también minimizan la frecuencia de los problemas de producción inesperados y las interrupciones, y el trabajo asociado durante las noches y los fines de semana que se requiere.

Ver también

Referencias

enlaces externos