Ahora hay una gran variedad de desarrollo de software ágil. Además de Scrum y Kanban, la Programación Extrema también se discute y se usa una y otra vez. ¿Qué tiene de extremo esta metodología de desarrollo?
¿Qué es la programación extrema?
La Programación Extrema (XP) es considerada como la implementación más radical del desarrollo ágil de software. Eso significa: probablemente no haya otro método más ágil que XP, y mucho menos los métodos de programación tradicionales.
Por lo tanto, la programación extrema también se diferencia específicamente del modelo en cascada que, según los inventores de XP, conlleva numerosos problemas. A mediados de la década de 1990, los desarrolladores Kent Beck, Ward Cunningham y Ron Jeffries decidieron darle la vuelta a la forma clásica de trabajar e ir por un nuevo camino.
Básicamente, la programación extrema está orientada a los requisitos del cliente. Esto suena obvio al principio, pero el desarrollo de software clásico solo puede responder a las solicitudes de los clientes de forma limitada; se vuelve particularmente difícil cuando estas solicitudes cambian regularmente. XP también busca fomentar la creatividad de los desarrolladores y acepta los errores como parte natural del trabajo.
Al mismo tiempo, XP, al igual que otros métodos ágiles, se basa en procesos iterativos. Pasar por un gran proyecto de principio a fin e invertir varios meses solo para descubrir que el resultado no encaja: XP rompe con eso. En cambio, se revisa, discute y publica constantemente en ciclos cortos. De esta manera, los errores pueden identificarse y eliminarse rápidamente.
Para cumplir con los requisitos, se ha desarrollado un marco bastante claro. Parte de diferentes valores, principios y técnicas. Además, se asignan roles específicos para que las tareas se puedan asignar claramente.
Valores
Con cinco valores, XP intenta cambiar la configuración básica al programar. El equipo en su conjunto debe seguir una cierta mentalidad para poder trabajar juntos de la mejor manera posible y crear un producto de primera clase.
Comunicación
La comunicación es importante en XP, tanto entre los miembros del equipo como entre los desarrolladores y los clientes. Un intercambio permanente debe garantizar que los problemas puedan abordarse directamente. Las deficiencias sólo pueden descubrirse con poca antelación si todos los implicados están en contacto constante entre sí. La comunicación también asegura que todos trabajen con el mismo nivel de conocimiento y se sientan comprometidos con el proyecto. Se prefiere una conversación real en el sitio al intercambio de mensajes escritos
Sencillez
Con XP, siempre se esfuerza por encontrar la solución más sencilla. Esto tiene varias ventajas: si solo te concentras en los factores necesarios, no te preocupas por lo que no es importante. Esto también incluye solo desarrollar las características requeridas en este momento y no prepararse para posibles requisitos futuros.
De esta manera, el equipo acelera el desarrollo. Un producto lean también es mucho más fácil de manejar, tanto en términos de desarrollo posterior como de trabajo de mantenimiento. Además, un código de programa lo más simple posible facilita la comprensión, lo que también se relaciona con el valor de la comunicación: si todo el equipo puede comprender el texto de origen, es más fácil intercambiar información al respecto
Reacción
Este valor también está íntimamente ligado al alto respeto por la comunicación directa. El cliente debe poder expresar sus críticas con la mayor frecuencia posible. Sin embargo, con la programación extrema, los mensajes del sistema (registros) también se tratan como retroalimentación.
Para poder implementar una cultura de retroalimentación en el sentido de XP, es importante pensar en pequeños pasos: el equipo trabaja en ciclos cortos, prueba el código una y otra vez y también presenta el desarrollo posterior al cliente en secciones cortas. . De esta manera, los cambios y las correcciones de errores se pueden realizar con poca antelación.
Coraje
La programación extrema entiende el coraje como la voluntad de decir la verdad, incluso si es bastante incómodo. Si hay errores en el producto, deben ser nombrados, incluso si usted mismo es responsable de ellos. En un equipo que trabaja por valores de XP, las disculpas tampoco importan.
Ningún miembro del equipo debe tratar de restar importancia a su participación en un error, ya que esto no es productivo. Además, el valor en este contexto también se entiende como tener el valor de cambiar las estructuras organizativas, cuestionar los propios métodos de trabajo, aceptar las críticas y, en determinadas circunstancias, reescribir completamente el código.
Respeto
El respeto mutuo es necesario para que el equipo pueda armonizar entre sí y lograr un excelente desempeño. Esto también se refleja en el hecho de que un desarrollador no sabotea el trabajo de otro mediante cambios. La apreciación también es importante más allá del equipo para el cliente.
Solo puede responder adecuadamente si toma en serio las preocupaciones de los demás. Finalmente, la gerencia debe mostrar respeto por el equipo de desarrollo y proporcionar a los empleados las habilidades y los recursos necesarios.
Principios
En la programación extrema, los principios se sitúan entre los valores y las prácticas, conectando lo abstracto con lo concreto. Los principios se derivan más o menos de los valores previamente definidos.
Retroalimentación inmediata
La retroalimentación debe obtenerse lo antes posible y luego implementarse lo más rápido posible. La retroalimentación debe ser implementada por el propio sistema (al probar el código) en segundos o minutos, en lugar de recopilar la retroalimentación primero, por ejemplo. Los comentarios de los clientes, por otro lado, deben obtenerse y tenerse en cuenta en días o semanas.
Luchar por la simplicidad
El principio de simplicidad básicamente corresponde al valor del mismo nombre, pero contiene instrucciones de implementación más específicas. Para ello se utilizan dos métodos:
- No lo vas a necesitar (YAGNI): Mientras no se solicite específicamente una funcionalidad, no se debe implementar para evitar hacer un trabajo innecesario.
- No te repitas (DRY): Debes evitar el trabajo doble y además diseñar el código de tal forma que no se tenga que hacer un cambio en varios lugares, sino una sola vez.
Cambios incrementales
En la programación extrema, los cambios siempre se realizan en pequeños pasos. En lugar de implementar grandes actualizaciones para eliminar múltiples fuentes de error a la vez, solo se aborda un problema a la vez.
Esto asegura que el equipo reaccione más rápido y que los cambios se puedan entender mejor. Sin embargo, el principio no solo se aplica al código del programa. Los cambios en el diseño o incluso en la estructura misma del equipo también deben realizarse en pasos pequeños e incrementales.
Aceptar cambios
Dado que la programación extrema pone al cliente en el centro, sus solicitudes de cambio también son muy valoradas. Es por eso que todo el equipo debe esperar dichos cambios en lugar de interponerse en su camino. Por lo tanto, debe alentar al cliente a expresar solicitudes de cambio en lugar de convencerlo de que no lo haga.
Trabajo de calidad
Suena banal, pero es, pensando más allá, muy importante para el funcionamiento de la programación extrema: el equipo debe hacer un trabajo de alta calidad. El cliente decide qué es de alta calidad. Sin embargo, para permitir un trabajo de calidad, se requiere gestión. Si los factores son correctos, es decir, el equipo puede estar satisfecho con el trabajo realizado, esto a su vez tiene un efecto positivo en la moral.
Técnicas
Las prácticas de XP son instrucciones y métodos de trabajo muy específicos. Si bien los valores y principios presentados también se utilizan en otros métodos de trabajo ágiles, las técnicas específicas de la programación extrema son puntos de venta únicos. Ellos también han cambiado ligeramente con el tiempo y difieren de una fuente a otra. En general, las técnicas se dividen en cuatro áreas diferentes.
Comentarios detallados
Los equipos de desarrollo trabajan en Programación Extrema en ciclos extremadamente cortos. Esto permite probar el código escrito una y otra vez. El desarrollo basado en pruebas llega tan lejos que los desarrolladores escriben un entorno de prueba antes de que se cree el código fuente real. El código que falla esta prueba no puede continuar. Así que aquí es donde la retroalimentación proviene del propio sistema.
El llamado juego de planificación es una reunión que tiene lugar al comienzo de cada fase de desarrollo. El equipo y el cliente se reúnen para revisar el trabajo anterior, proporcionar comentarios y analizar las funciones futuras. Luego se asignan las tareas.
La idea de un cliente en el sitio también asegura una retroalimentación regular. En el mejor de los casos, al menos un representante del cliente debe ser parte permanente del equipo para poder responder preguntas rápidamente o aportar ideas y prioridades.
Finalmente, la programación en pareja garantiza un principio de cuatro ojos: dos personas siempre trabajan en el código al mismo tiempo. Mientras un colega escribe el código, el otro revisa el código fuente, hace sugerencias de mejora y señala errores. Aunque este método es muy costoso, ya que se deben usar dos empleados para una tarea, el código resultante es finalmente mejor y requiere menos re elaboración.
Proceso continuo
Los equipos de XP revisan constantemente su código. Esta refactorización debería garantizar que se mejore el código fuente y que se eliminen las repeticiones y los componentes innecesarios. Tal código optimizado es más comprensible, también para lectores externos, y también menos propenso a errores.
Con la integración continua, los equipos en programación extrema y otros métodos de trabajo ágiles aseguran que el nuevo código se integre constantemente en el proyecto general. Un desarrollador inserta su trabajo en el proyecto varias veces al día.
Las contribuciones individuales se verifican continuamente y todos los involucrados trabajan con el estado actual.
Los programas de trabajo y las actualizaciones se lanzan lo antes posible en el espíritu de XP. Los lanzamientos pequeños también aumentan la frecuencia de la retroalimentación. Los errores se pueden detectar más rápido y erradicar con la próxima actualización. El cliente siempre tiene la oportunidad de probar directamente el último desarrollo y hacer críticas y sugerencias.
Entendimiento común
Con un diseño simple, el código es comprensible para todos los involucrados. Por lo tanto, todo lo que hace que el código fuente sea innecesariamente complejo debe eliminarse. Para los desarrolladores que trabajan de acuerdo con la Programación Extrema, es importante evitar cualquier duplicación. Además, debe quedar claro en el código fuente cuál es el objetivo del respectivo programador.
Los estándares de codificación se definen para que todo el equipo pueda trabajar codo con codo. Estas especificaciones se relacionan con el enfoque y el formato. Los colegas también deberían poder orientarse en el código de los demás y, al mismo tiempo, siempre debería ser posible rastrear quién realizó qué cambios.
La posibilidad de trabajar juntos en el código fortalece la propiedad colectiva del código: en lugar de señalar quién es responsable de qué parte y, por lo tanto, también de los errores que contiene, el código se entiende como un producto conjunto. Todo el equipo es responsable tanto de los errores como de los aciertos. Esta técnica también te invita a seguir trabajando en código de otros y aportar ideas.
Para aumentar aún más la comprensión del código fuente, la programacion extrema utiliza la técnica System Metáfora. Esta práctica consiste en describir el proyecto de la forma más sencilla posible, también utilizando metáforas.
Esto también hace referencia a las convenciones a la hora de nombrar objetos, clases o funciones en el código, que debe ser lo más auto explicativo posible. Los nuevos empleados que se unan al proyecto deberían poder entenderlo rápidamente. Incluso los no programadores obtienen una idea del texto fuente.
Bienestar del desarrollador
El bienestar del equipo es importante para el éxito del proyecto: solo los empleados descansados y motivados también pueden ofrecer resultados de alta calidad. Para garantizar esto, la Programación Extrema prescribe la semana de 40 horas. Las horas extraordinarias deben evitarse a toda costa y solo se permiten si no se acumulan más horas en la semana siguiente
Rol
En programación extrema, los roles se utilizan para distribuir tareas y competencias entre todos los involucrados, tanto los desarrolladores como los clientes
Cliente
Programación extrema actúa muy orientada al cliente, lo que va tan lejos que el cliente es percibido como parte del equipo y al menos un representante está siempre en el sitio (cliente en el sitio).
El cliente establece los requisitos sobre el producto, pero solo especifica parcialmente cómo se lograrán los objetivos. Solo la priorización de las subáreas cae dentro de su área de competencia. Sin embargo, esto también incluye hacer comprensibles sus propios deseos.
El rol de cliente puede ser desempeñado por una persona o por un equipo de diferentes representantes de clientes. En la práctica, los jefes de producto o empleados del área de marketing (siempre adecuados al objetivo del proyecto) suelen realizar las tareas.
Desarrollador
El equipo de desarrollo no se subdivide más. Esto significa que todos los que crean activamente el producto entran en el rol de desarrollador. Por lo tanto, a veces no solo los programadores están involucrados, sino también otras personas involucradas en la creación, según los requisitos del proyecto.
Además del trabajo de desarrollo real, también es tarea del desarrollador reaccionar a los deseos del cliente: estimar el esfuerzo, elaborar un cronograma, planificar la implementación.
Los desarrolladores tienen derecho a buscar la ayuda que necesitan, solicitar capacidades adicionales a la dirección. Además, según las técnicas de XP, los desarrolladores trabajan 40 horas a la semana.
Está en el espíritu del proyecto que los desarrolladores no estén sobrecargados de trabajo. El equipo de desarrollo establece su propio calendario para esto.
Gerente
El rol de gerente representa el vínculo entre los desarrolladores y los clientes. Las personas de este grupo reúnen a los otros dos en una misma mesa y también moderan el juego de planificación, por ejemplo.
Al hacerlo, el gerente se asegura de que se observen las reglas previamente definidas y las convenciones generales de una discusión constructiva. El gerente también actúa como mediador en caso de ser necesario.
El carrete también se conoce a veces como un rastreador . Esto se debe a que una de las responsabilidades del gerente es realizar un seguimiento de las métricas importantes (como el tiempo que cada empleado dedica al proyecto).
Entrenador
Todo el equipo (incluido el cliente) debe ser capaz de manejar Programación Extrema e implementar consistentemente este método de trabajo. Un entrenador puede ayudar a garantizar que todos tengan las mismas ideas sobre los procesos.
Esto no tiene nada que ver con el desarrollo real del producto, pero solo está disponible como ayudante externo, muy similar a un Scrum Master. En conversaciones preliminares, las reglas y prácticas se pueden discutir con esta persona.
En el mejor de los casos, el entrenador acompaña al equipo durante todo el proceso de desarrollo, está disponible para preguntas y ayuda con ambigüedades.
A menudo se utiliza un proveedor de servicios externo para esto. Sin embargo, también es posible que el entrenador provenga de dentro de la empresa, aunque de un área diferente. Deben evitarse los roles dobles (un desarrollador también asume el rol de entrenador).
Pros y contras de la programación extrema
La programación extrema ha dado un impulso importante a la forma en que se desarrolla el software, pero no es adecuada en todos los escenarios y para todos los equipos. XP asume que al comienzo del proyecto el cliente aún no tiene una idea precisa del producto terminado. En tal caso, el software puede ser ágil, es decir, planeado y desarrollado gradualmente.
De esta forma, por un lado, el cliente queda satisfecho: buscas junto a él la solución adecuada y él se implica en cada paso. Por otro lado, los desarrolladores pueden implementar proyectos como mejor les parezca, en lugar de tener que hacer concesiones constantemente. Sin embargo, si el cliente se acerca al equipo de desarrollo con una descripción completa del producto y una lista de funciones, XP se vuelve muy difícil de usar.
En particular, la programación en pareja puede plantear problemas a los equipos pequeños porque no se dispone de las capacidades necesarias para ello.
Las reuniones periódicas con los clientes también cuestan tiempo, que a su vez no puede fluir hacia el trabajo de programación real. En una situación ideal, no importa: el resultado será claramente mejor si el equipo puede asignar el tiempo y los recursos que necesita.
Pero en la práctica, los desarrolladores se ven presionados tanto por presupuestos limitados como por plazos claros. Además, el cliente puede carecer del interés o la oportunidad de involucrarse en el proyecto tanto como lo requiere XP.
Sin embargo, si las circunstancias son tales que permiten un acercamiento en el sentido de Programación Extrema, un equipo con este método puede entregar un excelente resultado.
Las pruebas constantes dan como resultado sistemas estables, y el enfoque iterativo, en combinación con el enfoque minimalista, garantiza que solo se creen las funciones que son importantes para el proyecto.
Ventajas
- Contacto cercano con el cliente
- Sin trabajo de programación innecesario
- Software estable a través de pruebas constantes
- Prevención de errores mediante la programación en pares
- Sin horas extras, ritmo autoseleccionado
- Los cambios se pueden hacer a corto plazo
- Código claro en todo momento
Desventaja
- Carga de trabajo adicional
- El cliente debe participar en el procedimiento
- Costos relativamente altos
- Gasto de tiempo relativamente alto
- Solo posible con la gestión de versiones
- Requiere autodisciplina en la implementación