¿Las prácticas de programación extremas hacen que una aplicación sea más propensa a errores? [cerrado]

Estoy realizando una investigación académica sobre el tema de la Programación extrema y si sus prácticas conducen a crear espacio para más errores y errores en las aplicaciones.

De las experiencias que obtuve de muchos, tengo comentarios que caen en ambos lados. Muchos lo respaldan y lo consideran una necesidad diaria, con dinámicas que pueden facilitar los requisitos cambiantes del proyecto. Muchos otros argumentan que conduce a muchos problemas, como:

• La participación excesiva con el cliente en el proceso lleva a la expresión de los deseos del cliente en lugar de las necesidades.

• Muchos productos tienen múltiples clientes que conducen a necesidades y opiniones conflictivas, creando bloqueos innecesarios

• Muchos productos no tienen clientes externos, donde el producto está hecho para uso interno o para ser vendido en el futuro. En estos casos, el equipo mismo está jugando con el usuario y con el desarrollador, lo que mata la efectividad del proceso.

• No existen muchas cosas en la documentación formal, esta informalidad conduce a una visión vaga y puede crear problemas en los que el cliente podría decir que esto no es lo que pedimos, etc., etc.

La pregunta es por qué existen opiniones tan conflictivas con respecto a XP. ¿Se trata de diferentes escenarios? ¿Hay algo más? ¿En qué medida es cierto el reclamo (como está escrito en el título)?

Me gustaría que las personas que trabajan o hayan trabajado con XP aquí contribuyan con su aprendizaje y experiencias del mundo real. Sería ideal si tiene algún hecho o referencia para respaldar su respuesta.

La participación excesiva con el cliente en el proceso lleva a la expresión de los deseos del cliente en lugar de las necesidades.

Esto supone que el cliente es una especie de oráculo perfecto para los requisitos del sistema. Uno de los principios fundamentales de XP es que el cliente no es un oráculo perfecto y que se necesita una retroalimentación constante basada en software de envío real para determinar las verdaderas necesidades del mercado, los clientes y, en última instancia, las partes interesadas.

Muchos productos tienen múltiples clientes que conducen a necesidades y opiniones conflictivas, creando bloqueos innecesarios.

Sí, y la participación regular de esos clientes ayudará a hacer explícitos estos conflictos y ayudará a resolverlos con el tiempo. Ocultar el problema no hará que desaparezca.

Muchos productos no tienen clientes externos, donde el producto está hecho para uso interno o para ser vendido en el futuro. En estos casos, el equipo mismo está jugando con el usuario y con el desarrollador, lo que mata la efectividad del proceso.

Las partes interesadas internas no son fundamentalmente diferentes de las partes externas. No ha explicado cómo las metodologías que no son XP tratan este problema.

No existen muchas cosas en la documentación formal, esta informalidad conduce a una visión vaga y puede crear problemas en los que el cliente podría decir que esto no es lo que pedimos, etc., etc.

XP implica comentarios frecuentes e incrementales entre las partes interesadas y los desarrolladores. Si existen estas fallas de comunicación, entonces se pueden descubrir durante las primeras iteraciones y se pueden arreglar antes de que afecten significativamente las iteraciones posteriores. La alternativa es que estas fallas de comunicación no se descubren hasta justo antes de que se envíe el producto.

Creo que la idea errónea fundamental es que XP no está creando estos problemas. Es solo exponerlos . Los procesos que exponen y corrigen problemas de manera temprana y generalmente son menos propensos a errores, no más.

Algunas reflexiones:

• Demasiadas implicaciones del cliente en el proceso lo hacen comenzar a expresar sus deseos en lugar de sus necesidades al software

Siempre hay un equilibrio entre tener una especificación detallada y estable y responder al cliente. Extreme está destinado a aumentar la capacidad de respuesta al cliente y, por supuesto, es posible ir demasiado lejos en esa dirección. Entonces, esta es una preocupación legítima (especialmente dependiendo de cómo se facture el proyecto: si se trata de un contrato de precio fijo, obviamente debe tenerlo bien especificado).

En mi experiencia, sin embargo, no importa cuán buena sea su especificación, a menudo tiene que cambiarla para hacer "lo que el cliente desea" de todos modos. Extreme lo ayuda a realizar esos cambios lo antes posible, en lugar de después de haber creado un programa enorme y complicado según las especificaciones.

• Muchos productos tienen múltiples clientes que conducen a necesidades y opiniones conflictivas que conducen a bloqueos innecesarios

Por supuesto, resolver necesidades conflictivas en tal situación siempre será un problema con el que necesita un buen proceso para lidiar. Si el proceso de obtener comentarios de los clientes lleva mucho tiempo y es complejo, la Programación Extrema sería menos efectiva, por lo que creo que es una preocupación legítima.

• Muchos productos no tienen ningún cliente externo (organización de productos hecha para ellos o para vender en el futuro). En este caso, el equipo mismo está jugando con el usuario y con el desarrollador, lo que mata la efectividad del proceso.

No creo que esto sea legítimo en absoluto. La idea detrás de Extreme es que los clientes no se dan cuenta de lo que quieren hasta que realmente empiezas a hacerlo. Esto es tan cierto para los "clientes" internos como para los externos.

Y si está desarrollando algo que aún no tiene clientes (como un producto aún no lanzado) debe tener a alguien (o algún grupo) que actúe como el cliente hipotético y decida qué querrá la gente. Extreme funciona igual de bien con ellos actuando como el cliente.

He trabajado en un producto como este, que estaba destinado a clientes externos pero aún no se ha lanzado. Si bien no lo etiquetamos como "Programación extrema", utilizamos un proceso de desarrollo iterativo similar sin una especificación formal extensa y con compilaciones frecuentes. Lo encontré bastante efectivo.

• No existen muchas cosas en la documentación formal, esta informalidad conduce a una visión vaga y puede crear problemas en los que el cliente podría decir que esto no es lo que pedimos, etc., etc.

Sí, cualquier cosa que no esté documentada es un problema. Extremo, dado que no está impulsado por una especificación formal, podría facilitar la no documentación de las cosas. Pero Extreme no significa automáticamente "las cosas no están documentadas". Aún debe hacer documentación, pero se crea junto con el programa en lugar de antes. Y en algunos casos significará documentar el comportamiento después de implementarlo. Esto no es un problema en sí mismo.

Cuando se trata de facturación, a menudo necesita documentación escrita de exactamente lo que se entregará antes de comenzar el trabajo. Esto puede ser más difícil con la programación extrema.

Conclusión : Extreme es una metodología que, como todo, tiene ventajas e inconvenientes. Debe tener ambos en mente cuando lo use (o lo enseñe).

Sus preguntas solo se refieren a dos temas principales de XP: "comunicación directa con el cliente" y "no demasiada documentación formal". Entonces, desde mi punto de vista, esta no es realmente una pregunta "XP", esos son temas que son parte de cualquier otro proceso de desarrollo ágil que conozco.

Aquí están mis pensamientos:

Demasiadas implicaciones del cliente en el proceso lo hacen comenzar a expresar sus deseos en lugar de sus necesidades al software.

Bueno, si tiene un proceso similar a una cascada, con una especificación completamente detallada de antemano, con muchos requisitos, puede tener problemas, ya sea cuáles de esos requisitos son solo deseos y cuáles son necesidades reales. La forma más fácil de aclarar esto es, en mi humilde opinión, hablar con el cliente y mostrarle diferentes alternativas, siempre que llegue a un punto en el que se necesita una aclaración. Entonces, todo lo contrario es cierto: el "desarrollo ágil" lo ayudará a lidiar mejor con las "necesidades frente a los deseos".

Muchos productos tienen múltiples clientes que conducen a necesidades y opiniones conflictivas que conducen a bloqueos innecesarios

Sí, con una especificación detallada de antemano, esos conflictos pueden haberse resuelto antes de que comience el desarrollo (si tiene suerte). La solución a este problema en un proceso ágil es que solo unas pocas personas del lado del cliente hablen directamente con los desarrolladores y un representante responsable de los clientes que pueda tomar decisiones finales en caso de conflictos.

Muchos productos no tienen ningún cliente externo (organización de productos hecha para ellos o para vender en el futuro). En este caso, el equipo mismo está jugando con el usuario y con el desarrollador, lo que mata la efectividad del proceso.

No, eso no es correcto, si solo tiene usuarios internos que pertenecen a la misma compañía que los desarrolladores, "cliente en el sitio" es mucho más fácil de instalar que cuando solo tiene clientes externos. Si usted tiene no hay usuarios directos a la mano, que puede ser un problema, pero eso no es un problema con agilidad específica - a continuación, tendrá que encontrar a alguien que toma el rol de un usuario potencial en su lugar (y esta persona por lo general no es de la equipo de desarrolladores).

No existen muchas cosas en la documentación formal, esta informalidad conduce a una visión vaga y puede crear problemas en los que el cliente podría decir que esto no es lo que pedimos, etc., etc.

Según mi experiencia, si desarrolla siguiendo una especificación formal sin comunicación constante con el cliente, la posibilidad de desarrollar algo donde los clientes digan "esto no es lo que pedí" es> 100 veces mayor que cuando habla con el cliente todos los días. Si aún se encuentra con ese problema, hay una solución simple: después de cada sesión con el cliente, haga una breve nota escrita de lo que ha acordado. Si es necesario, envíe esa nota al cliente y dele la oportunidad de hacer correcciones. Eso funciona en un proceso ágil, así como en cualquier otro tipo de proyecto.

Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software

¿Está desarrollando software basado en lo que necesita un cliente? ¿Qué pasa si un cliente quiere? ¿Negará al cliente porque "oye cliente, solo construyo software basado en la necesidad?"

Realicé prácticas en una tienda de programación extrema y ágil. Vi interacciones semanales de primera mano con los clientes que a veces volvieron locos a los desarrolladores y al control de calidad. Pero entregaron exactamente lo que el cliente quería, cuando lo quiso, y fue claro durante "Mostrar y contar" con el cliente lo que hizo, lo que no hizo y lo que debía ser como él quería.

Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

No hay bloqueos innecesarios si la tienda extrema y ágil deja en claro los objetivos de implementación y qué se incorporará y qué no se incorporará al producto. Diferentes versiones del mismo producto también es una posibilidad y depende de lo que se negocie. Esto no tiene por qué ser un punto de discusión que detenga la productividad o conduzca a bloqueos innecesarios.

Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

No necesariamente. Incluso una interfaz de usuario externa mediante la cual uno está entrevistando a personas al azar en la calle para determinar qué interfaz les parecería interesante para un dispositivo en particular es una posibilidad.

Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

Entonces la documentación formal necesita ser empleada. La documentación formal mantiene los pies del cliente al fuego y una tarjeta perforada de una línea "esto es lo que nos dijo que quería" coincide con la documentación y la interacción del cliente, por lo que no hay excusas. Como tuve la oportunidad de ver esto en acción como pasante en una tienda extrema y ágil, el cliente firmó la documentación semanalmente. El cliente también tuvo la oportunidad de implementar cambios y también tuvo que firmarlos. Si falta documentación, hay una invitación al desastre.

The questions is why such conflicting opinions exists regarding XP, is it the matter of different scenarios or is there something else and till what extent the claim (as written in the title) is true.

Yo diría que depende de la inteligencia de la tienda. XP y Agile son pautas y no instrucciones. Para operar con éxito con XP y Agile, debe incorporarse a las prácticas operativas y utilizarse en toda la organización. El millaje siempre variará y algunos indudablemente afirmarán que es malo, algunos dirán que es bueno. donde hice la pasantía, sin duda fue bueno y se tuvo mucho éxito.

Desde mi experiencia, lo rígido que es a los principios de XP y Agile parece determinar si, cuando se incorpora a la "rutina diaria", qué tan exitoso es el desarrollo de software. Donde hice la pasantía, la interacción con el cliente condujo todo y no se hizo nada sin que un cliente haya declarado primero que debería hacerse. La forma en que esta tienda manejó sus operaciones proporcionó un éxito bueno y medible utilizando principios sólidos de desarrollo como parte del marco XP y Agile estrechamente integrado en todo lo que hacen.

Si nos atenemos a la pregunta original de

Estoy realizando una investigación académica sobre el tema de la Programación extrema y si sus prácticas conducen a crear espacio para más errores y errores en las aplicaciones.

No estoy seguro de que las preocupaciones expresadas sean relevantes para la pregunta.

Si existe el temor de que el cliente se vea involucrado en deseos y no en necesidades, me gustaría ver al equipo para asegurarme de que están desglosando adecuadamente los artículos en lanzamientos pequeños con diseños simples. Después de eso, priorizar esos elementos de tal manera que el equipo pueda trabajar a un ritmo sostenible.

Si el esfuerzo tiene múltiples clientes que no pueden acordar las necesidades y opiniones, ¿qué esperanza hay de poder probar que el software satisface las necesidades del cliente? Es mejor aclarar esas cosas temprano en el SDLC en lugar de más tarde.

Si el equipo tiene que ser el usuario de XP, esto no mata el proceso de XP. De hecho, se afirma específicamente que el cliente es un miembro del equipo. A veces, este miembro del equipo es un empleado interno en lugar de un "verdadero cliente", es importante que el individuo esté facultado para representar las necesidades del cliente. No veo cómo esta preocupación es más relevante para XP en comparación con cualquier otro enfoque, ya sea ágil o tradicional.

¿No existen muchas cosas en la documentación formal? Si se hace correctamente, los equipos XP pasarán más tiempo planeando que un equipo tradicional. Además, debido a que las especificaciones se escriben conjuntamente entre los miembros del equipo de negocios y de mentalidad técnica al comienzo de cada iteración, las especificaciones tienden a ser más precisas en comparación con el diseño grande por adelantado.

XP se centra en los aspectos de desarrollo (ingeniería) de un proyecto. Las cosas que deben discutirse al considerar XP son:

• ¿La curva de aprendizaje para el desarrollo basado en pruebas interfiere con el desarrollo de un producto de calidad?
• Qué difícil es crear pruebas de calidad que den como resultado un código de calidad.
• ¿Qué posibilidades hay de que los desarrolladores "engañen" al ciclo de desarrollo impulsado por la prueba y escriban primero el código, luego la prueba más tarde? ¿Importa?
• Cuán efectivos son los desarrolladores que trabajan en parejas en comparación con el desarrollo más tradicional (una persona que escribe el código para una función).
• ¿El diseño iterativo / emergente conduce a sistemas más estables y escalables que los sistemas diseñados por adelantado?
• Qué tan efectiva es la integración continua en la prevención proactiva de defectos de software.

Para mí esas son las preguntas a tener en cuenta con XP. Las inquietudes planteadas anteriormente parecen ser más adecuadas para una discusión sobre Scrum (que comúnmente se combina con XP).

Para referencias vería:

http://xprogramming.com/index.php

o

http://www.objectmentor.com/resources/omi_reports_index.html

Saludos y la mejor de las suertes con su investigación.