Programación extrema
Imagínese esto: un proyecto de desarrollo de software para un nuevo producto, basado en la ventaja del primero en el mercado, acaba de ser visto en el radar de su empresa. Los métodos tradicionales de programación extrema, donde el cliente sabe "exactamente" lo que quiere, están fuera. Su equipo es pequeño y está compuesto por profesionales jóvenes que probablemente respondan bien a un modelo radical de gestión de proyectos. Cuales son tus opciones?
Es probable que diga: Gestión de proyectos ágil, por supuesto. Pero, ¿qué metodología te gustaría usar? Hay varias opciones: por un lado, está el Scrum enormemente popular: que implica la creación de "sprints" cortos basados en la acumulación de tareas del cliente. Y luego, está Kanban, que trabaja en la optimización de la tubería de trabajo. También hay una programación extrema, a menudo abreviada como XP, que se enfoca en amplificar los aspectos positivos de los modelos de programación tradicionales para que funcionen a su máximo potencial.
La programación extrema es una metodología muy popular (aunque no tan popular como Scrum) centrada en satisfacer los requisitos cambiantes del cliente. El primer proyecto de Programación Extrema se inició en marzo de 1996, por Kent Beck en Chrysler. En su libro de 1999, Extreme Programming Explained: Embrace Change, detalló los aspectos para el desarrollo de software.
Kent Beck también fue el pionero del desarrollo basado en pruebas, que puso las pruebas de casos de uso en el radar como una mejora sobre la forma en que se hicieron las cosas entonces: escribir líneas y líneas de código y luego probarlo. También fue uno de los firmantes originales del Manifiesto Ágil, ayudando a dar forma al manifiesto para cambiar la forma en que se escribió el software de programación extrema.
Los cinco valores de la programación extrema basada en explicados son:
Comunicación
La programación extrema no depende de una extensa documentación. De hecho, se sugiere documentación de programación extrema solo cuando sea necesario. Por lo tanto, la metodología depende en gran medida de la comunicación entre los miembros del equipo y también con los usuarios.
Sencillez
Este es el núcleo de la programación extrema. La metodología favorece los diseños simples, sin pensar demasiado en el futuro, sino centrarse en los requisitos de hoy, al tiempo que hace que el programa sea lo suficientemente robusto como para agregar los requisitos que el futuro arroja.
Realimentación
Este ciclo esencial de ir y venir diferencia los sistemas ágiles en general y la programación extrema en particular, de otras metodologías de gestión de proyectos de software. La retroalimentación continua puede funcionar de diferentes maneras, pero todas trabajan para hacer que el sistema sea más fuerte y más confiable.
La retroalimentación puede venir en diferentes sabores:
- Desde el propio programa: el código se prueba enérgicamente durante todo el ciclo de desarrollo del proyecto, de modo que los desarrolladores puedan implementar los cambios.
- Del cliente: Esta es una parte esencial de la mayoría de los sistemas ágiles. Los clientes escriben las pruebas de aceptación en las que se basa el desarrollo, y esto forma la columna vertebral del proceso de desarrollo. Todas las iteraciones también se entregan al cliente, para una retroalimentación periódica.
- Del equipo: una vez que se ha creado un nuevo caso de uso / historia, el equipo revierte inmediatamente con la estimación de costos y la línea de tiempo, confirmando los requisitos a medida que surgen. En la Programación Extrema, ninguna persona "posee" ningún código y, por lo tanto, dentro de los equipos de programación extremos, se alienta la retroalimentación sobre el código de los demás.
Valor
¡Esto puede parecer un valor extraño en la programación extrema para el desarrollo de software, más adecuado para algo como el Ejército o los Marines! Sin embargo, piénselo: los proyectos de software se han estancado durante mucho tiempo por los métodos tradicionales de gestión de la programación extrema; seguro en la comodidad de una extensa documentación y jerarquía que no permite la innovación. Este valor ejemplifica el núcleo de la programación extrema: ¡prepárate para saltar, sin paracaídas si se trata de eso! Mire este estilo diferente de gestión de proyectos y prepárese para ser responsable, renunciar a la jerarquía y ser responsable y trabajar sin saberlo todo al principio.
El respeto
El respeto, el quinto valor, se agregó más tarde y significa respeto por los demás y por uno mismo. También implica respeto por el código que se está escribiendo y por las expectativas y necesidades del cliente. Este valor también subyace en la comunicación entre las diferentes partes interesadas.
Actividades de un proyecto de programación extrema
La programación extrema distingue cuatro actividades simples de un proyecto. Son:
- Codificación : Extreme Programming considera que esta es la actividad más importante. "Sin código, no hay nada", dice Kent Beck, el fundador de Extreme Programming.
- Prueba : el código es solo eso a menos que se pruebe. Extreme Programming es obsesivo con las pruebas, utiliza pruebas unitarias para confirmar que el código funciona y las pruebas de aceptación generadas por el cliente para confirmar que el código está probando lo que se necesita probar.
- Escuchar: escuchar, ejemplificado por el valor central de la comunicación, es una actividad que requiere que los desarrolladores no solo escuchen a los clientes, sino que realmente escuchen lo que quieren. El desarrollo y los negocios son dos cosas diferentes y, a menudo, los desarrolladores no entienden el caso comercial de una decisión en particular. Las necesidades del cliente, así como las de los desarrolladores, forman la base de la actividad de "escucha".
- Diseño : puede sorprenderle que en un proyecto de desarrollo de software, la actividad de diseño, a menudo tan importante y primaria, se coloque al final. Esto se debe a que Extreme Programming deliberadamente quiere sacar a las personas de la mentalidad de "diseñar y desarrollar" que la industria ha fomentado durante muchos años. No es limitar la importancia del diseño. Más bien, el diseño bueno y minimalista es una de las características de un proyecto.
De los valores y actividades surgen los 12 principios de la Programación extrema, tal como lo ideó su fundador, en su libro, Programación extrema explicada.
- Juego de planificación
- Programación en pareja
- Desarrollo guiado por pruebas
- Todo el equipo
- Integración continua
- Mejora de diseño
- Pequeños lanzamientos
- Estándares de codificación
- Propiedad colectiva del código
- Diseño simple
- Metáfora del sistema
- Marcha sostenible
Algunas de estas prácticas de programación extremas, todas asignadas a las mejores prácticas de ingeniería de software, son diferentes de las metodologías Agile genéricas. Algunas de las prácticas de programación extrema se explican a continuación:
-
Juego de planificación
Esta es la parte de planificación del proyecto, denominada "Juego de planificación". Incluye planificación para la próxima iteración y lanzamiento, en consulta con el usuario / cliente, así como una planificación interna de los equipos, en cuanto a las tareas en las que trabajarán.
-
Programación en pareja
Esto involucra a dos personas que trabajan en un código. Una persona, llamada teclado, escribe el código mientras que la otra, llamada monitor, supervisa el código, comenta y refina, según sea necesario. Las dos personas a menudo intercambian sus roles. Se ha demostrado que esto mejora significativamente la eficiencia del código. Es posible que esto no sea adecuado para todos los escenarios de desarrollo, y eso es algo a tener en cuenta antes de registrarse en Extreme Programming.
-
Desarrollo basado en pruebas
Todo el código que se escribe se revisa por unidad, es decir, cada pieza de código que puede hacer algo se prueba primero. La programación extrema pone mucho énfasis en las pruebas. Esto ayuda a confirmar que el código funciona y, por lo tanto, puede considerarse para su inclusión en el proyecto de programación extrema. Es análogo a las pruebas unitarias en la escuela: se prueban pequeñas piezas de información, de modo que el maestro / alumno puede hacer correcciones de curso y no se tambalea durante los exámenes anuales.
-
Mejora de diseño (refactorización)
Los proyectos de XP, basados en su característica de simplicidad, tienen como objetivo mejorar continuamente el código que se escribe. Esto significa que todo el código (y, a veces, la base de datos también) siempre se mejora. La refactorización no agrega ninguna funcionalidad; simplemente mejora el código existente. Lo hace más apretado y claro. Es similar a editar un escrito, pulirlo y mejorarlo.
-
Diseño simple
En Extreme Programming, las funciones no se agregan hasta que se requiera específicamente. Incluso si el código en el que se trabaja actualmente es muy similar a lo que podría requerirse en el futuro, no se acepta a menos que se acuerde como una historia de usuario.
-
Metáfora del sistema
Esto incluye la estandarización de todas las convenciones de nomenclatura para que su propósito y función se descifren fácilmente. Por ejemplo, las operaciones o pueden ayudar a cualquier programador a comprender su funcionalidad. Esto debe hacerse en todo el proyecto de programación extrema, de modo que sea fácil para cualquiera mirar el código y modificarlo o mejorarlo, según sea el caso.
Roles dentro de un proyecto de programación extrema:
Al igual que Scrum, Extreme Programming tiene algunos roles designados dentro de cada proyecto. Ahora, los roles no siempre deben ser desempeñados por personas distintas, y una persona puede asumir más de un rol.
Los roles de programación extrema son:
- Cliente : autoexplicativo. El motivo del proyecto. Ella decide qué debe hacer el proyecto. Ella proporciona las historias de los usuarios.
- Programador : Esta es la persona que:
- Toma las historias que el cliente inventa
- Crea tareas de programación a partir de historias.
- Implementa las historias de los usuarios.
- Prueba el código por unidad
- Entrenador : el entrenador generalmente se asegura de que el proyecto esté encaminado y también interviene para ayudar cuando sea necesario.
- Rastreador : El Rastreador realiza consultas específicas a los programadores en un intervalo establecido. Por lo general, revisa el progreso de los programadores, ofreciendo ayuda donde sea necesario de varias maneras: arremangándose y ayudando directamente con el código, informando al Entrenador o organizando una reunión con el cliente, según sea necesario.
- Probador : ejecuta pruebas funcionales. El probador no ejecuta pruebas unitarias, que son ejecutadas por los propios programadores.
- Doomsayer: Esto, como su nombre lo indica, es similar al Sombrero Negro en el sistema de pensamiento grupal de Edward De Bono. Cualquiera podría ser un apocalíptico, que normalmente señala posibles problemas y ayuda a mantener los problemas en la perspectiva correcta.
- Gerente : El Gerente en un proyecto de Programación Extrema es más como un planificador, asegurando que las reuniones se realicen según lo planeado, y que las decisiones tomadas durante las reuniones se transmitan a la persona adecuada, la mayoría de las veces, el Rastreador. Sin embargo, el Gerente no le dice a la gente qué hacer y cuándo hacerlo. Esto lo hace el Cliente y / o las Historias de usuario.
- Propietario de oro : El propietario de oro es la persona que financia el proyecto. Este podría ser el cliente, pero no necesariamente así.
Algunos de los roles de programación extremos, como se describió anteriormente, se pueden combinar, pero otros claramente no.
El cliente, por ejemplo, tampoco puede ser el Programador. El Programador y el Rastreador, de manera similar, no pueden ser exitosamente la misma persona.
Los roles de programación extremos se definen con la suficiente claridad para que no haya confusión, y se crean para una máxima flexibilidad y eficiencia.
Inconvenientes de la programación extrema:
Si bien los defensores de la Programación extrema pintan una imagen optimista, el hecho es que la Programación extrema, como su nombre probablemente sugiere, es extremadamente difícil de implementar. Facets of Extreme Programming se puede incorporar en proyectos con más éxito que adoptar completamente XP.
Algunos de los aspectos negativos de la programación extrema son:
- Se encuentra que la programación extrema es más efectiva en grupos más pequeños . Su eficiencia en grupos más grandes es impugnada, y una mejor opción es dividir equipos de programación extremos para que los grupos sean más pequeños.
- Una de las características clave de Extreme Programming, la programación de pares no funciona bien en muchos casos . La codificación compleja puede requerir dos cabezas, pero no todas las tareas pueden requerir dos personas, siendo la segunda persona un peso muerto. De hecho, la programación de pares, si uno de los miembros no está sincronizado con el otro, es una de las principales razones por las que la programación extrema falla en muchos casos.
- La dependencia del cliente, hasta el punto de sugerir un recurso en el sitio por parte del cliente, puede ser profundamente desconcertante. También puede provocar interferencias, tanto reales como imaginarias, durante el desarrollo.
- El enfoque de Extreme Programming en la simplicidad puede hacer que sea muy difícil agregar al proyecto actual, lo que significa un mayor presupuesto para cambios simples, que ya no son simples.
- La estructura jerárquica plana significa que el equipo siempre debe estar enfocado, y en ausencia de un gerente para acorralar a tipos de personas divergentes, un equipo de Programación Extrema depende completamente de la madurez emocional de todos los miembros del equipo, un factor que no siempre es confiable .
Incluso con estos factores, la Programación extrema sigue siendo una herramienta poderosa para ser utilizada para el proyecto correcto, y las compañías informan un aumento múltiple en su eficiencia después de adoptar el proceso de programación extrema. Un sistema impulsado por el desarrollador en lugar de Scrum, que es más un sistema impulsado por procesos, la programación extrema, o al menos partes de él, puede conducir a una revolución en la forma en que desarrollamos software de programación extrema.