Saltar al contenido
Codif铆ca.me | Desarrollo web | Programaci贸n

Programaci贸n extrema desarrollo de software extremo

25 enero, 2022
programacion extrema

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.

programacion extrema

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