¿Qué es la programación extrema? Una visión general de las reglas y valores de XP
en la década de 1990, el auge de Internet requirió un cambio en el desarrollo de software. Si el éxito de una empresa dependía de la velocidad a la que la empresa podía crecer y llevar productos al mercado, las empresas necesitaban reducir drásticamente el ciclo de vida del desarrollo de software.,
fue en este entorno que Kent Beck creó extreme programming (XP), una metodología ágil de gestión de proyectos que admite lanzamientos frecuentes en ciclos de desarrollo cortos para mejorar la calidad del software y permitir a los desarrolladores responder a los requisitos cambiantes de los clientes.
aunque puede reconocer algunas de estas prácticas y valores de otras metodologías de gestión de proyectos, XP lleva estas prácticas a niveles «extremos», como sugiere el nombre de la metodología., En una entrevista con Informit, Kent explica:
«la primera vez que me pidieron que liderara un equipo, les pedí que hicieran un poco de las cosas que pensé que eran sensatas, como pruebas y revisiones. La segunda vez había mucho más en juego. Yo asked le pedí al equipo que subiera todas las perillas a 10 en las cosas que pensé que eran esenciales y omitiera todo lo demás.»
si usted y su equipo necesitan liberar rápidamente y responder a las solicitudes de los clientes, eche un vistazo a los valores y reglas de la programación extrema—podría ser un ajuste perfecto.,
valores de la metodología de programación extrema
XP es más que una serie de pasos para administrar proyectos: sigue un conjunto de valores que ayudarán a su equipo a trabajar más rápido y colaborar de manera más efectiva.
simplicidad
Los Equipos logran lo que se les ha pedido y nada más. XP divide cada paso de un proceso importante en objetivos más pequeños y alcanzables para que los miembros del equipo logren.,
comunicación optimizada
los equipos trabajan juntos en cada parte del proyecto, desde la recopilación de requisitos hasta la implementación del código, y participan en reuniones diarias para mantener actualizados a todos los miembros del equipo. Cualquier inquietud o problema se aborda de inmediato.
retroalimentación consistente y constructiva
En XP, los equipos adaptan su proceso al proyecto y a las necesidades del cliente, no al revés. El equipo debe demostrar su software temprano y con frecuencia para que puedan recopilar comentarios del cliente y hacer los cambios necesarios.,
respeto
La programación extrema fomenta una mentalidad de «todos para uno y uno para todos». Cada persona en el equipo, independientemente de la jerarquía, es respetada por sus contribuciones. El equipo respeta las opiniones de los clientes y viceversa.
coraje
los miembros del equipo se adaptan a los cambios a medida que surgen y asumen la responsabilidad de su trabajo. Dicen la verdad sobre su progreso-no hay «mentiras blancas» o excusas para no hacer que la gente se sienta mejor. No hay razón para temer porque nadie trabaja solo.,
reglas de la metodología de programación extrema
Don Wells publicó las primeras reglas de XP en 1999 para contrarrestar las afirmaciones de que la programación extrema no admite actividades que son necesarias para el desarrollo de software, como la planificación, la administración y el diseño. Desde la planificación hasta la prueba del software, siga estos pasos básicos para cada iteración.
Planning
Esta etapa es donde ocurre la magia de UX., En lugar de un extenso documento de requisitos, el cliente escribe historias de usuario, que definen la funcionalidad que le gustaría ver, junto con el valor comercial y la prioridad de cada una de esas características. Las historias de usuario no necesitan ser exhaustivas o demasiado técnicas, solo necesitan proporcionar suficiente detalle para ayudar al equipo a determinar cuánto tiempo tomará implementar esas características.
con Lucidchart, los clientes pueden crear un diagrama de flujo básico y registrar y compartir fácilmente la funcionalidad deseada.,
a partir de ahí, el equipo crea un calendario de lanzamiento y divide el proyecto en iteraciones (de una a tres semanas de duración). Es posible que los gerentes de proyecto quieran crear una línea de tiempo o un diagrama de Gantt simplificado para compartir la programación con el equipo.
administrar
en esta etapa, el gerente de proyecto establecerá el equipo para tener éxito en esta metodología. Todo el mundo necesita trabajar en colaboración y comunicarse de manera efectiva para evitar cualquier descuido. Esta etapa implica:
- Crear un espacio de trabajo abierto para su equipo
- Establecer un ritmo sostenible (p. e., determinar la longitud correcta para las iteraciones)
- programar una reunión diaria de pie
- medir la velocidad del proyecto (la cantidad de trabajo que se realiza en su proyecto)
- reasignar el trabajo para evitar cuellos de botella o pérdida de conocimiento
- cambiar las reglas si XP no funciona perfectamente para el equipo
diseñar
Esta regla se remonta al valor de la simplicidad: comience con el diseño más simple porque tomará menos tiempo completar que el complejo solución. No agregue funcionalidad antes de tiempo. Refactorizar a menudo para mantener el código limpio y conciso., Cree soluciones de spike para explorar soluciones a problemas potenciales antes de que dejen atrás a su equipo.
Kent Beck y Ward Cunningham también crearon tarjetas de colaboración de responsabilidad de clase (CRC) para usar como parte de la metodología XP. Estas tarjetas permiten a todo el equipo del proyecto diseñar el sistema y ver cómo interactúan los objetos. Si desea probar esta herramienta de lluvia de ideas por sí mismo, comience con nuestra plantilla Lucidchart.,
Coding
entonces llega el momento de implementar el código. XP practica la propiedad colectiva del código: Todos revisan el código y cualquier desarrollador puede agregar funcionalidad, corregir errores o refactorizar. Para que la propiedad colectiva del código funcione, el equipo debe:
- Elegir una metáfora del sistema (esquema de nomenclatura estandarizado).
- practicar la programación de pares., Los miembros del equipo trabajan en pares, en una sola computadora, para crear código y enviarlo a producción. Solo un par integra código a la vez.
- Integrar y comprometer código en el repositorio cada pocas horas.
el cliente debe estar disponible, preferiblemente en el sitio, durante todo este proceso para que pueda responder preguntas y establecer requisitos.
Testing
El equipo realiza pruebas unitarias y corrige errores antes de que el código pueda ser liberado. También realizan pruebas de aceptación con frecuencia.,
cuándo usar extreme programming
¿todavía no está seguro de si XP se ajustará a las necesidades de su equipo, incluso después de leer sus reglas y valores? La programación extrema puede funcionar bien para los equipos que:
- esperan que la funcionalidad de su sistema cambie cada pocos meses.
- experimente los requisitos en constante cambio o trabaje con clientes que no están seguros de lo que quieren que haga el sistema.
- quiere mitigar el riesgo del proyecto, especialmente en los plazos ajustados.
- incluir un pequeño número de programadores (entre 2 y 12 es preferible).
- Son capaces de trabajar en estrecha colaboración con los clientes.,
- Son capaces de crear pruebas funcionales y de unidades automatizadas.
si la colaboración y el desarrollo continuo son prioridades para su equipo, la programación extrema podría valer la pena intentarlo. Debido a que este modelo altamente adaptable requiere comentarios continuos de los clientes, anticipa errores en el camino y requiere que los desarrolladores trabajen juntos, XP no solo garantiza un lanzamiento de producto saludable, sino que también ha mejorado involuntariamente la productividad de los equipos de desarrollo en todo el mundo.,
si decide usar XP, intente documentar visualmente sus historias de usuario, programas de lanzamiento, tarjetas CRC y documentación del sistema en Lucidchart. Regístrese para obtener su cuenta gratuita hoy.