¿Por qué la programación extrema (XP) ha caducado en favor de Agile, Kanban, etc.

Me gusta XP (programación extrema), especialmente la parte donde hay 2 programadores en la misma pantalla, ya que la solución de un problema a menudo se encuentra más rápidamente si solo explicas lo que estás haciendo y la programación de pares te obliga a explicar lo que estás haciendo. haciendo.

En los últimos 10 años más o menos, el estilo de trabajo XP parece haberse quedado obsoleto en favor de las metodologías de trabajo: ágil y / o Kanban. ¿Por qué? Desde XP me parece una muy buena forma de trabajar y se trata mucho de la programación, mientras que Agile y Kanban son más sobre procesos.

Hay muchos estilos, métodos y mentalidades diferentes relacionados con todo el desarrollo del campo, y todo tiene su propio nombre brillante.

Agile es solo una mentalidad que se aleja de los modelos de programación estáticos habituales (como las cascadas): su objetivo principal es lograr un desarrollo más flexible y (al final) un mejor software y clientes satisfechos. Debajo de ágil, hay muchos modelos diferentes como Scrum, Kanban, XP.

Especialmente Kanban no proviene del desarrollo de software originalmente, se origina en la construcción de automóviles (recuerdo que Toyota lo presentó para construir automóviles y algunos desarrolladores de software lo adoptaron y lo ampliaron)

La programación de pares, las revisiones de código y esas cosas son solo herramientas: siempre puede (y debe) hacerlo durante un proyecto, independientemente del método que utilice. Es solo que estas cosas son más nativas de lo ágil que de lo estático.

XP más o menos introdujo estas cosas (o al menos les dio un nombre brillante) y todo lo siguiente las adoptó porque simplemente funcionó bien.

En mi opinión, XP es una práctica de programación, Scrum y Kanban son prácticas de gestión de proyectos. Tienen una relación pero no se reemplazan entre sí.

En nuestro proyecto Kanban utilizamos programación de pares (principalmente para secciones complejas y depuración), TDD, CI. Por lo tanto, todavía se usa, pero la administración está presionando más al lado de la administración del proyecto.

La programación extrema trata sobre la mecánica del desarrollo, mientras que Agile trata sobre el SDLC (ciclo de vida del desarrollo de software).

La razón principal por la que ya no escuchas sobre "Extreme Programming" es el uso del término "Extreme" como un adjetivo positivo que es una cosa obsoleta de los 90 a principios de los 00 que ahora se ve cursi. Principalmente es solo una víctima del marketing. Es por eso que casi exclusivamente lo escuchas referido como "XP", incluso verbalmente.

Tengo algunas ideas sobre la programación de pares.

Para mí, esto es algo que haces cuando estás atrapado con algo. En esos momentos puede ser muy efectivo, puede sacarte de la rutina. Pero también es agotador y una forma de trabajar que al programador de tipo estéreo no le gusta hacer más que ocasionalmente.

Si está cavando un hoyo, a pocas personas les importaría obtener ayuda de un compañero de trabajo. Pero tan pronto como haya creatividad involucrada, las personas prefieren hacer las cosas a su manera en lugar de a otra persona. Por lo tanto, la tensión siempre está cerca, a menos que a uno no le importe de una manera u otra o si el papel de uno es claramente sugerir solamente.

Donde trabajo la programación de pares no está formalizada, pero tenemos sesiones ad hoc y generalmente son breves. No será como "Hola compañero de trabajo, ¿qué tal una programación extrema?" Más a menudo comenzaría con "¿Puedes echar un vistazo a mi pantalla?" y acercando una silla para ellos.

Por lo tanto, no creo que la programación de pares esté muerta o sea menos popular, es solo una de esas herramientas que no usa muy a menudo porque es costosa, y no principalmente porque tiene dos personas remuneradas trabajando en una cosa.

Agile es más comercializable porque involucra a diferentes partes interesadas con diferentes roles y responsabilidades relacionadas con el proceso de creación de software.

Cuando en su segunda edición, Kent Beck amplió el alcance de los participantes dentro de XP, fue tarde: la gente ya adoptó otras metodologías porque la primera versión de XP apunta a los creadores del código, y eso es lo que la audiencia todavía recuerda inconscientemente o no. XP no era comercializable al nacer.

Siempre pensé que Scrum era la versión de Agile que era más fácil de vender a la gerencia: las estimaciones deterministas, su naturaleza algo doctrinaria y bien definida ("realmente no estás haciendo Scrum, ¡siéntete culpable!") ...

Estira tus sprints el tiempo suficiente y toma esas pequeñas "cartas de póker" lo suficientemente en serio, y Scrum puede hacer cosquillas con el mismo picor que los métodos de la cascada. Esto no es necesariamente malo, pero no nos escondamos detrás de humo y espejos aquí.

En el lado de XP, la programación de pares generalmente no es atractiva para la administración, especialmente la administración no técnica.

Para ponerlo en formato de analogía SAT, Scrum: XP :: The Monkees: The Beatles