Extreme Programming (Programación Extrema)
La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación. Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática.
Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque
no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software.
El objetivo principal de la XP es la satisfacción del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodología ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.
Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.
¿Cuándo se debe usar? La programación extrema fue creada pensando en las siguientes circunstancias: * Proyectos en los que los requisitos tienen altas probabilidades de cambiar con el tiempo (por ejemplo, porque el cliente no tiene claro lo que quiere, o porque el cambio de requisitos está ligado al dominio del problema a resolver). * Proyectos con alto riesgo (por ejemplo, proyectos con una fecha de entrega que es indispensable cumplir, o proyectos totalmente novedosos para la industria). * Proyectos con un grupo pequeño de programadores (entre 2 y 12), aunque el equipo completo sea bastante más extenso (incluye a jefes de equipo y representantes de clientes).
Ciclo de vida
Planificación
XP plantea la planificación como un permanente diálogo entre la parte empresarial y técnica del proyecto, en la que los primeros decidirán el alcance –¿qué es lo realmente necesario del proyecto?–, la prioridad –qué debe ser hecho en primer lugar–, la composición de las versiones qué debería incluir cada una de ellas– y la fecha de las mismas. En cuanto a los técnicos, son los responsables de estimar la duración requerida para implementar las funcionalidades deseadas por el cliente, de informar sobre las consecuencias de determinadas decisiones, de organizar la cultura de trabajo y, finalmente, de realizar la planificación detallada dentro de cada versión. XP no es sólo un método centrado en el código –que lo es–,sino que sobre todo es un método de gestión de proyectos software.
Redactar historias de usuario: Las historias de usuario tienen el mismo propósito que los casos de uso, pero no son lo mismo. Las escriben los propios clientes, tal y como ven ellos las necesidades del sistema. Por tanto serán descripciones cortas y escritas en el lenguaje del usuario, sin terminología técnica.
Crear plan de entregas: El plan de entregas se usará para crear los planes de iteración para cada iteración.
Controlar la velocidad del proyecto: La velocidad de proyecto se usa para determinar cuántas historias de usuario pueden ser implementadas antes de una fecha dada (tiempo), o cuánto tiempo es necesario para llevar a cabo un conjunto de historias (alcance).
Dividir un proyecto en iteraciones.
Planificar cada interacción antes de comenzarla.
Rotar al personal.
Reunión de seguimiento diaria.
Corregir la propia metodología.
Desarrollo
Esta etapa debe reunir las siguientes características o cualidades:
El cliente debe estar siempre disponible.
Escribir código de acuerdo a estándares.
Desarrollar la unidad de prueba primero: la implementación será más rápida.
Todo código debe programarse en pareja.
Solo una pareja integrará el código.
Todo el código es común a todos: cualquiera puede contribuir al desarrollo desde cualquier parte del proyecto.
Dejar las optimizaciones para el final.
No trabajar más de 40 horas semanales.
Pruebas
Todo el código debe ir acompañado de una unidad de prueba.
Todo el código debe pasar las unidades de prueba antes de ser implementado.
Ante un fallo se crea una unidad de prueba.
Se deben ejecutar pruebas de aceptación a menudo y publicar los resultados, que son creadas a partir de las historias de usuario.
Diseño
XP establece unas recomendaciones o premisas a la hora de abordad esta etapa.
Simplicidad: Siempre costará menos tiempo de implementar un diseño sencillo que uno complejo.
Elegir una metáfora: Una metáfora para el sistema es una historia que todo el mundo puede contar a cerca de cómo el sistema funciona. Nos permitirá mantener la coherencia de nombres de todo aquello que se va a implementar.
Usar tarjetas CRC: Una tarjeta CRC representa un objeto. El nombre de la clase se coloca a modo de título en la tarjeta, las responsabilidades se colocan a la izquierda, y las clases que se implican en cada responsabilidad a la derecha, en la misma línea que su requerimiento correspondiente.
Crear soluciones puntuales para reducir riesgo.
No añadir funcionalidades en las primeras etapas.
Características
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi y NUnit para la plataforma.NET. Estas dos últimas inspiradas en JUnit.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
Ventajas y desventajas de Extreme Programming
Ventajas:
Ø Programación organizada.
Ø Menor taza de errores.
Ø Satisfacción del programador.
Ø X.P. sólo funcionará con gente buena, es decir, profesionales que son capaces de hacer un buen diseño, sencillo y a la vez fácilmente ampliable.
Ø El desarrollo de software con XP es más flexible, y como el sistema comienza a crecer orgánicamente, es más sencillo remover funciones paracumplir con el tiempo de desarrollo sin poner en riesgo el resto del sistema
Ø Por otro lado se ha de recalcar que XP no ha inventado ningún método nuevo, sencillamente ha recogido métodos ya existentes y los ha agrupado, y ha comprobado que funcionen. Y para terminar, mencionar que el creador de XP asegura que se garantiza un rato si más no divertido.
Desventajas:
Ø Es recomendable emplearlo solo en proyectos a corto plazo.
Ø Altas comisiones en caso de fallar.
Ø Si se utilizan diagramas UML, éstos tienden a estar poco actualizados, debido a la constante refactorización.
Prácticas básicas de la programación extrema
Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.
Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.
Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.
Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.
Mejora del diseño: Mientras se codifica, debe mejorarse el código ya hecho con el que nos crucemos y que sea susceptible de ser mejorado. Extraer funcionalidades comunes, eliminar líneas de código innecesarias, etc.
Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.
El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.
Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.
Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.
Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.
Ejemplos de aplicación de Extreme Programming
Las aplicaciones donde se puede usar Extreme Programming son extensas, ya que en cualquier rama de mercado y ciencia XP es una buena opción.
• Un ejemplo de una empresa que aplico Extreme Programming es ONess, cuyo objetivo es un proyecto open source para el negocio textil mayorista desarrollado con tecnologías open source innovadoras
Conclusión
La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Donde cuenta con un grupo de trabajo pequeño, en el cual reina cuatro valores fundamentales en cada uno de ello, estos son: la Comunicación, la Sencillez, la Retroalimentación y la Valentía, dándole un toque especial a esta manera de programar.
Cabe destacar que este método de programar, va más allá de cumplir con una exigencia propuesta por el cliente, debido a que los programadores tratan de cumplir con los requerimientos propuestos por este, así como también, brindarle la satisfacción
En la programación extrema es imposible prever todo antes de empezar a codificar. Es imposible capturar todos los requisitos del sistema, saber qué es todo lo que se tiene que hacer ni como hacer un diseño correcto al principio. Es bastante normal hacer un esquema, ponerse a codificar, ver que hay faltantes o errores en este, empezar a codificar fuera del diseño y al final, o no se parecen, o hemos perdido un montón de tiempo en cambiar la documentación de diseño para que se parezca al código. La programación extrema también se podría decir que es muy útil a la hora de que se cuente con un grupo de trabajo pequeño así la programación se hace mas organizada hay menos taza de error a la hora de programar, también este método ayuda mucho a que exista una mejor comunicación entre el cliente y el equipo de desarrollo.
Introducción
Es bien conocido por programadores y creadores de sistemas que en la actualidad en lo que respecta a creación, desarrollo, implementación y las distintas etapas que se requieran para la elaboración de un sistemas (software) se conocen una gran y amplia gamma de metodologías que son implementadas por los investigadores con el fin de establecer un mejor y optimo desempeño en el área de trabajo, ya sea tanto en el grupo que han de desarrollar el sistema como también en el cliente, es por esto que dicho trabajo de investigación en relación con lo antes mencionado busca de manera clara y precisa desarrollar y dar a entender una de las distintos métodos que posee esta amplia y compleja rama de estudio como es los es la programación extrema.
La programación extrema es una metodología de desarrollo ligera (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación. Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática.
Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en como se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque
no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software.
El objetivo principal de la XP es la satisfacción del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodología ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.
Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.
¿Cuándo se debe usar? La programación extrema fue creada pensando en las siguientes circunstancias: * Proyectos en los que los requisitos tienen altas probabilidades de cambiar con el tiempo (por ejemplo, porque el cliente no tiene claro lo que quiere, o porque el cambio de requisitos está ligado al dominio del problema a resolver). * Proyectos con alto riesgo (por ejemplo, proyectos con una fecha de entrega que es indispensable cumplir, o proyectos totalmente novedosos para la industria). * Proyectos con un grupo pequeño de programadores (entre 2 y 12), aunque el equipo completo sea bastante más extenso (incluye a jefes de equipo y representantes de clientes).
Ciclo de vida
Planificación
XP plantea la planificación como un permanente diálogo entre la parte empresarial y técnica del proyecto, en la que los primeros decidirán el alcance –¿qué es lo realmente necesario del proyecto?–, la prioridad –qué debe ser hecho en primer lugar–, la composición de las versiones qué debería incluir cada una de ellas– y la fecha de las mismas. En cuanto a los técnicos, son los responsables de estimar la duración requerida para implementar las funcionalidades deseadas por el cliente, de informar sobre las consecuencias de determinadas decisiones, de organizar la cultura de trabajo y, finalmente, de realizar la planificación detallada dentro de cada versión. XP no es sólo un método centrado en el código –que lo es–,sino que sobre todo es un método de gestión de proyectos software.
Redactar historias de usuario: Las historias de usuario tienen el mismo propósito que los casos de uso, pero no son lo mismo. Las escriben los propios clientes, tal y como ven ellos las necesidades del sistema. Por tanto serán descripciones cortas y escritas en el lenguaje del usuario, sin terminología técnica.
Crear plan de entregas: El plan de entregas se usará para crear los planes de iteración para cada iteración.
Controlar la velocidad del proyecto: La velocidad de proyecto se usa para determinar cuántas historias de usuario pueden ser implementadas antes de una fecha dada (tiempo), o cuánto tiempo es necesario para llevar a cabo un conjunto de historias (alcance).
Dividir un proyecto en iteraciones.
Planificar cada interacción antes de comenzarla.
Rotar al personal.
Reunión de seguimiento diaria.
Corregir la propia metodología.
Desarrollo
Esta etapa debe reunir las siguientes características o cualidades:
El cliente debe estar siempre disponible.
Escribir código de acuerdo a estándares.
Desarrollar la unidad de prueba primero: la implementación será más rápida.
Todo código debe programarse en pareja.
Solo una pareja integrará el código.
Todo el código es común a todos: cualquiera puede contribuir al desarrollo desde cualquier parte del proyecto.
Dejar las optimizaciones para el final.
No trabajar más de 40 horas semanales.
Pruebas
Todo el código debe ir acompañado de una unidad de prueba.
Todo el código debe pasar las unidades de prueba antes de ser implementado.
Ante un fallo se crea una unidad de prueba.
Se deben ejecutar pruebas de aceptación a menudo y publicar los resultados, que son creadas a partir de las historias de usuario.
Diseño
XP establece unas recomendaciones o premisas a la hora de abordad esta etapa.
Simplicidad: Siempre costará menos tiempo de implementar un diseño sencillo que uno complejo.
Elegir una metáfora: Una metáfora para el sistema es una historia que todo el mundo puede contar a cerca de cómo el sistema funciona. Nos permitirá mantener la coherencia de nombres de todo aquello que se va a implementar.
Usar tarjetas CRC: Una tarjeta CRC representa un objeto. El nombre de la clase se coloca a modo de título en la tarjeta, las responsabilidades se colocan a la izquierda, y las clases que se implican en cada responsabilidad a la derecha, en la misma línea que su requerimiento correspondiente.
Crear soluciones puntuales para reducir riesgo.
No añadir funcionalidades en las primeras etapas.
Características
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi y NUnit para la plataforma.NET. Estas dos últimas inspiradas en JUnit.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
Ventajas y desventajas de Extreme Programming
Ventajas:
Ø Programación organizada.
Ø Menor taza de errores.
Ø Satisfacción del programador.
Ø X.P. sólo funcionará con gente buena, es decir, profesionales que son capaces de hacer un buen diseño, sencillo y a la vez fácilmente ampliable.
Ø El desarrollo de software con XP es más flexible, y como el sistema comienza a crecer orgánicamente, es más sencillo remover funciones paracumplir con el tiempo de desarrollo sin poner en riesgo el resto del sistema
Ø Por otro lado se ha de recalcar que XP no ha inventado ningún método nuevo, sencillamente ha recogido métodos ya existentes y los ha agrupado, y ha comprobado que funcionen. Y para terminar, mencionar que el creador de XP asegura que se garantiza un rato si más no divertido.
Desventajas:
Ø Es recomendable emplearlo solo en proyectos a corto plazo.
Ø Altas comisiones en caso de fallar.
Ø Si se utilizan diagramas UML, éstos tienden a estar poco actualizados, debido a la constante refactorización.
Prácticas básicas de la programación extrema
Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.
Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.
Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.
Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.
Mejora del diseño: Mientras se codifica, debe mejorarse el código ya hecho con el que nos crucemos y que sea susceptible de ser mejorado. Extraer funcionalidades comunes, eliminar líneas de código innecesarias, etc.
Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.
El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.
Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.
Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.
Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.
Ejemplos de aplicación de Extreme Programming
Las aplicaciones donde se puede usar Extreme Programming son extensas, ya que en cualquier rama de mercado y ciencia XP es una buena opción.
• Un ejemplo de una empresa que aplico Extreme Programming es ONess, cuyo objetivo es un proyecto open source para el negocio textil mayorista desarrollado con tecnologías open source innovadoras
Conclusión
La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Donde cuenta con un grupo de trabajo pequeño, en el cual reina cuatro valores fundamentales en cada uno de ello, estos son: la Comunicación, la Sencillez, la Retroalimentación y la Valentía, dándole un toque especial a esta manera de programar.
Cabe destacar que este método de programar, va más allá de cumplir con una exigencia propuesta por el cliente, debido a que los programadores tratan de cumplir con los requerimientos propuestos por este, así como también, brindarle la satisfacción
En la programación extrema es imposible prever todo antes de empezar a codificar. Es imposible capturar todos los requisitos del sistema, saber qué es todo lo que se tiene que hacer ni como hacer un diseño correcto al principio. Es bastante normal hacer un esquema, ponerse a codificar, ver que hay faltantes o errores en este, empezar a codificar fuera del diseño y al final, o no se parecen, o hemos perdido un montón de tiempo en cambiar la documentación de diseño para que se parezca al código. La programación extrema también se podría decir que es muy útil a la hora de que se cuente con un grupo de trabajo pequeño así la programación se hace mas organizada hay menos taza de error a la hora de programar, también este método ayuda mucho a que exista una mejor comunicación entre el cliente y el equipo de desarrollo.
Introducción
Es bien conocido por programadores y creadores de sistemas que en la actualidad en lo que respecta a creación, desarrollo, implementación y las distintas etapas que se requieran para la elaboración de un sistemas (software) se conocen una gran y amplia gamma de metodologías que son implementadas por los investigadores con el fin de establecer un mejor y optimo desempeño en el área de trabajo, ya sea tanto en el grupo que han de desarrollar el sistema como también en el cliente, es por esto que dicho trabajo de investigación en relación con lo antes mencionado busca de manera clara y precisa desarrollar y dar a entender una de las distintos métodos que posee esta amplia y compleja rama de estudio como es los es la programación extrema.
No hay comentarios:
Publicar un comentario