¿Qué es la programación extrema?

La Programación Extrema (XP para abreviar) fue propuesta por Kent Beck en 1996. Cuando KentBeck trabajó con Ward Cunningham a principios de la década de 1990, habían estado explorando juntos nuevos métodos de desarrollo de software, con la esperanza de hacerlo más simple y efectivo. Kent observó y analizó cuidadosamente varios requisitos previos, posibilidades y dificultades para simplificar el desarrollo de software. En marzo de 1996, Kent finalmente introdujo un nuevo concepto de desarrollo de software: XP en un proyecto para DaimlerChrysler.

XP es un método de desarrollo de software ligero y flexible, al mismo tiempo, también es un método muy riguroso y exhaustivo. Su fundamento y valores son la comunicación, la sencillez, la retroalimentación y la valentía; es decir, cualquier proyecto de software puede mejorarse desde cuatro aspectos: fortalecer la comunicación a partir de la búsqueda de la retroalimentación y tener la valentía de buscar la verdad en los hechos; XP es un método de desarrollo casi en espiral que divide el complejo proceso de desarrollo en ciclos relativamente simples; a través de la comunicación activa, la retroalimentación y una serie de otros métodos, los desarrolladores y los clientes pueden tener muy claro el progreso del desarrollo, los cambios y los problemas. resolver y posibles dificultades, etc., y ajustar el proceso de desarrollo de manera oportuna de acuerdo con la situación real.

¿Qué es el desarrollo de software?

El contenido del desarrollo de software es: requisitos, diseño, programación y pruebas.

Requisitos: No solo las necesidades del usuario, sino todas las necesidades encontradas durante el desarrollo. Por ejemplo, primero necesita saber qué problema debe resolver este proyecto; qué datos deben ingresarse en el caso de prueba... Para comprender claramente estos requisitos, a menudo es necesario comunicarse con los clientes, gerentes de proyectos, etc.

Diseño: Antes de codificar, debe haber un plan que te diga qué hacer, cuál es la estructura, etc. Debes seguir esto, de lo contrario puedes terminar en un lío.

Programación: Si su programa no puede ejecutarse o no cumple con los requisitos del cliente en la fecha límite del proyecto, no recibirá el dinero.

Prueba: El propósito es avisarte cuando esté completo. Si eres inteligente, primero debes escribir el examen para saber a tiempo si realmente lo completaste. De lo contrario, a menudo no se sabe qué funciones se han completado realmente y en qué medida están respecto de los objetivos esperados.

En el desarrollo de software, los clientes y desarrolladores tienen sus propios derechos y obligaciones básicos.

Cliente:

Defina la prioridad comercial de las necesidades de cada usuario.

Desarrolle un plan general, que incluya cuánta inversión, cuánto tiempo llevará y qué; se lograrán los objetivos;

En cada semana laboral durante el proceso de desarrollo del proyecto, puede obtener el máximo retorno de su inversión;

Capte con precisión el progreso del proyecto ejecutando repetidamente el pruebas funcionales que especifique la situación;

Capacidad de cambiar los requisitos, la funcionalidad o las prioridades en cualquier momento evitando costosas reinversiones. Capacidad de ajustar rápidamente los planes del proyecto de acuerdo con diversos cambios; proyectos en cualquier momento cancelación del proyecto En este momento, el trabajo de desarrollo anterior no es un montón de basura, las funciones desarrolladas están en línea con los requisitos y el trabajo en curso o inacabado no debería ser difícil de asumir.

Desarrolladores:

Sepa qué hacer y qué priorizar;

Trabajar de manera eficiente.

Tiene preguntas o dificultades para poder obtenerlas; respuestas o ayuda de clientes, colegas y superiores;

Evaluar el trabajo y reevaluarlo de manera oportuna de acuerdo con los cambios en la situación circundante;

Asumir el trabajo activamente en lugar de aceptar pasivamente la tarea;

Semana laboral de 40 horas, sin horas extras.

¡Esto es desarrollo de software y hay otras cuestiones de las que preocuparse!

Método de desarrollo de software ligero e inteligente

Un método de desarrollo de software es una serie de reglas, especificaciones y convenciones relacionadas con el desarrollo. Los métodos de desarrollo pesados ​​definen estrictamente muchas reglas, procesos y trabajos de documentación relacionados.

Un método de desarrollo inteligente y liviano con relativamente pocas reglas y documentos, un proceso más flexible y una implementación relativamente fácil.

Antes de que surgiera el concepto de ingeniería de software, los programadores desarrollaban software como querían. La calidad del programa es difícil de controlar, depurar el programa es engorroso y es difícil para los programadores comprender el código escrito por otros. En 1968, Edsger Dijkstra escribió una carta titulada GOTOStatementConsideredHarmful to CACM, y nació el concepto de ingeniería de software. Los programadores comenzaron a abandonar sus prácticas anteriores en favor de métodos de desarrollo más sistemáticos y rigurosos. Para controlar el desarrollo de software de manera tan estricta como controlar la producción de otros productos, la gente ha formulado sucesivamente muchas reglas y prácticas, inventado muchos métodos de ingeniería de software y la calidad del software ha comenzado a mejorar enormemente. A medida que surgen más problemas, las reglas y procedimientos se vuelven más sofisticados y complejos.

Hoy en día, en el proceso de desarrollo real, muchas reglas son difíciles de seguir, muchos procesos son complejos y difíciles de entender, y el proceso de producción de documentos en muchos proyectos está perdiendo control. La gente intenta crear un paquete mejor y más completo, o poner sus esperanzas en herramientas de desarrollo auxiliares más complejas y potentes (CaseTools), pero siempre fracasan y las especificaciones y procesos de desarrollo se vuelven cada vez más complejos y difíciles de implementar. .

Para cumplir con el cronograma, los programadores a menudo se saltan algunos procesos específicos y pocas personas pueden seguir por completo esos métodos de desarrollo tan pesados.

La razón del fracaso es simple. No existe ninguna panacea en este mundo. Por lo tanto, algunas personas han propuesto eliminar, reorganizar y optimizar las reglas y procesos en métodos de desarrollo pesados, produciendo así muchos procesos livianos que se adaptan a diferentes necesidades. En estos procesos, se mantienen las reglas que satisfacen las necesidades prácticas y se descartan las que complican innecesariamente el desarrollo. Además, en comparación con los métodos de desarrollo tradicionales, los procesos ligeros ya no son como líneas de montaje, sino más flexibles.

La programación extrema (XP) es un método de desarrollo de software muy inteligente y ligero.

¿Por qué se llama "Extremo"?

"Extremo" significa que, en comparación con el método tradicional de desarrollo de proyectos, XP enfatiza cada método enumerado y piensa hasta el límite y haz lo mejor que puedas; Se ignorarán otras cosas que XP no recomienda (como el diseño general en la etapa inicial de desarrollo, etc.). Para un proyecto que implementa estrictamente XP, su proceso de desarrollo debe ser fluido, eficiente y rápido, capaz de lograr una semana laboral de 40 horas sin retrasar el progreso del proyecto.

¿Cómo es el desarrollo de software XP?

1 Entorno de trabajo extremo

Para lograr y satisfacer al máximo las necesidades de los clientes y desarrolladores durante el Proceso de desarrollo de software Derechos y obligaciones básicos, XP requiere el mejor entorno de trabajo. Todos los que participen en el desarrollo del proyecto asumirán un rol (gerente de proyecto, supervisor de proyecto, etc.) y desempeñarán los derechos y obligaciones correspondientes. Todas las personas trabajan en el mismo entorno de desarrollo abierto. Es mejor si todos trabajan en la misma casa grande y se les proporciona refrigerio; 40 horas a la semana, no se recomiendan horas extras todas las mañanas y todos se reúnen para comenzar el trabajo. reunión; hay algunas pizarras blancas grandes en la pared, y todas las tarjetas de Historia, tarjetas CRC, etc. están colocadas en ellas. Puedes escribir y dibujar en ellas cuando discutas problemas después del trabajo, todos pueden jugar juegos de computadora juntos; ..

2 Demanda Extrema

El cliente debe ser un miembro del equipo de desarrollo del proyecto, en lugar de estar separado de los desarrolladores porque desde la planificación del proyecto hasta la aceptación final, el; El cliente siempre ha jugado un papel muy importante. Los desarrolladores y los clientes trabajan juntos para convertir varios requisitos en pequeños módulos de requisitos (UserStory). Por ejemplo, "Calcular el número total de estudiantes en un grado significa sumar el número de estudiantes en todas las clases de ese grado".

"; estos módulos se combinarán o descompondrán en módulos más pequeños según la situación real; todos se registran en algunas tarjetas pequeñas (StoryCard) y luego los programadores los desarrollan en cada ciclo pequeño (Iteración, generalmente no más de 3 semanas) la implementación; los clientes especifican sus prioridades de acuerdo con el valor comercial de cada módulo; lo que los desarrolladores deben hacer es determinar el riesgo de desarrollo de cada módulo requerido; los módulos de demanda de alto riesgo (generalmente debido a la falta de experiencia similar) tendrán prioridad para la investigación; , exploración y desarrollo; después de que los desarrolladores y los clientes evalúen cada módulo desde diferentes perspectivas, se organizarán en diferentes ciclos de desarrollo y los clientes obtendrán un plan de desarrollo lo más preciso posible. El cliente especifica pruebas de aceptación (pruebas funcionales) para cada uno; módulo de requisitos.

Cada vez que se lanza un software desarrollado (después de un ciclo de desarrollo), los usuarios obtienen un sistema que pueden comenzar a usar, que está completamente implementado en algún plan de desarrollo tradicional. En los modelos, los usuarios tienen que esperar hasta que se complete todo el desarrollo antes de poder comenzar a usarlo.

Desde una perspectiva de desarrollo específica, los procesos internos de XP se basan en ciclos de desarrollo basados ​​en pruebas (TestDrivenDevelopment) y externos. Los procesos como la planificación y el diseño se centran en estos. Cada ciclo de desarrollo tiene muchas pruebas unitarias correspondientes (UnitTest). Al principio, todas las pruebas unitarias fallaron a medida que se completaban más y más unidades; De esta manera, los clientes y desarrolladores pueden verificar fácilmente si se cumplen las promesas a los clientes. XP aboga por un diseño simple, que consiste en utilizar la forma más sencilla para que los programas escritos para cada requisito simple puedan pasar. pruebas unitarias relevantes, además de la reorganización y optimización (Refectorio), todos estos procesos son en realidad procesos de optimización del diseño; la ejecución continua de pruebas unitarias y pruebas funcionales durante estos procesos puede garantizar que el sistema reorganizado y optimizado aún cumpla con todos los requisitos. p >

4 Programación extrema

Dado que la programación es muy importante, XP anima a dos personas a escribir el mismo programa (Programación en pareja) y la propiedad del código pertenece a todo el equipo de desarrollo (Propiedad colectiva del código). Al reorganizar y optimizar programas, se deben seguir estrictamente las especificaciones de programación. Cualquiera puede modificar los programas escritos por otros. Después de la modificación, asegúrese de que el nuevo programa pueda pasar la prueba unitaria. p>

Dado que las pruebas son muy importantes, XP recomienda escribir pruebas unitarias antes de comenzar a escribir programas. Los desarrolladores a menudo deben integrar los módulos desarrollados (integración continua) y ejecutar pruebas unitarias después de cada integración al realizar cualquier revisión y modificación del código y agregar las pruebas correspondientes cuando se descubren errores (por lo que el método XP no lo hace). requieren una base de datos de ERRORES). Además de las pruebas unitarias, también existen pruebas de integración, pruebas funcionales, pruebas de carga y pruebas de sistemas. Todas estas pruebas son uno de los documentos más importantes en el proceso de desarrollo de XP y uno de los contenidos finales entregados a los usuarios.

Convenciones y reglas importantes en XP

1 Equipo de desarrollo del proyecto (Equipo)

En XP, todos los que contribuyen al proyecto deben ser miembros del proyecto equipo de desarrollo. Además, al menos una persona de este equipo debe tener una comprensión muy clara de las necesidades del usuario, poder proponer requisitos, determinar el valor comercial (prioridad) de cada requisito, ajustar el plan del proyecto de acuerdo con los cambios en los requisitos, etc.

Esta persona desempeña el papel de "cliente" y, por supuesto, es mejor que sea el usuario final real, porque todo el proyecto se centra en las necesidades del usuario final. Los programadores son miembros esenciales del equipo de desarrollo del proyecto. El equipo puede incluir evaluadores, que ayudan a los clientes a formular pruebas de aceptación; analistas, que ayudan a los clientes a determinar los requisitos y, por lo general, un entrenador, que es responsable de seguir el progreso del desarrollo, resolver algunos problemas encontrados durante el desarrollo y promover el proyecto. un director de proyecto que es responsable de asignar recursos, ayudar en la comunicación dentro y fuera del proyecto, etc. Hay tantos roles en el equipo del proyecto, pero eso no significa que el trabajo realizado por cada persona no pueda ser intervenido o interferido por otros. XP anima a todos a contribuir tanto como sea posible al proyecto. Llévense como iguales y aprendan de las fortalezas de los demás; este es el mejor equipo de desarrollo de XP.

2 Planificación de proyectos (PlanningGame), pruebas de aceptación, lanzamiento a pequeña escala (SmallReleases)

El equipo de desarrollo de XP utiliza una forma sencilla de planificar y desarrollar el proyecto, y predecir el progreso. de la situación del proyecto y determinar los pasos futuros. Según el valor comercial de los requisitos, el equipo de desarrollo lleva a cabo una serie de desarrollo e integración para un grupo de requisitos. Cada desarrollo producirá un sistema probado y utilizable.

Planificación de proyectos

El proceso de planificación de XP se centra en dos problemas en el desarrollo de software: predecir cuánto trabajo se puede completar antes de la fecha de entrega y qué hacer ahora y a continuación; Responder continuamente a estas dos preguntas sirve directamente para implementar y ajustar el proceso de desarrollo. Por el contrario, si espera definir con precisión qué hará todo el proceso de desarrollo y cuánto tiempo llevará cada cosa desde el principio, obtendrá el doble de resultado. con la mitad del esfuerzo. En respuesta a estos dos problemas, existen dos procesos principales correspondientes en XP:

Planificación de lanzamiento de software (ReleasePlanning). Los clientes establecen los requisitos y los desarrolladores estiman los costos y riesgos de desarrollo. El cliente desarrolla un plan aproximado del proyecto basado en los costos de desarrollo, los riesgos y la importancia de cada requisito. No es necesario (ni posible) que el plan inicial del proyecto sea muy preciso porque los costos de desarrollo, los riesgos y la importancia de cada requisito no están escritos en piedra. Además, este plan se ajustará continuamente para que sea más preciso durante el proceso de implementación.

Planificación de iteraciones (IterationPlanning). Durante el proceso de desarrollo, debe haber muchos planes de etapas (por ejemplo, un plan cada tres semanas). Los desarrolladores pueden realizar una reorganización y optimización interna (código y diseño) del sistema en un ciclo determinado, agregar nuevas funciones en un ciclo determinado o realizar ambos aspectos del trabajo al mismo tiempo en un ciclo determinado. Sin embargo, después de cada ciclo de desarrollo, los usuarios deberían poder obtener un sistema que haya implementado algunas funciones. Además, después de cada ciclo, los clientes propondrán requisitos que deberán completarse en el siguiente ciclo. En cada ciclo de desarrollo, los desarrolladores dividirán los requisitos en pequeñas tareas y luego estimarán el costo de desarrollo y el riesgo de cada tarea. Estas estimaciones se basan en la experiencia de desarrollo real. Cuanto más proyectos se realicen, más precisas y precisas serán las estimaciones. En el mismo proyecto, después de cada ciclo de desarrollo, la siguiente estimación tendrá más experiencia, referencia y base, por lo que Más. preciso. Estos sencillos pasos brindan a los clientes información rica y suficiente, lo que les permite controlar de manera flexible y efectiva el proceso de desarrollo. Cada dos o tres semanas, los clientes pueden ver los requisitos que los desarrolladores han completado. En XP, no existen términos vagos como "casi terminado" o "90 completados". O está terminado o no está terminado. Este enfoque parece tener ventajas y desventajas: la ventaja es que los clientes pueden saber inmediatamente lo que se ha completado, si las cosas hechas son adecuadas, qué se debe hacer o mejorar a continuación, etc.; la desventaja es que los clientes pueden ver lo que se está haciendo; realizado, Usted puede quedar insatisfecho o incluso rescindir el contrato. De hecho, el enfoque de XP es detectar y resolver problemas lo antes posible, en lugar de esperar hasta unos meses más tarde, cuando los usuarios finalmente vean el sistema desarrollado, y luego decirles que esto no funciona, que ha cambiado y que necesita cambiar. ser agregado.

Qué contenido y así sucesivamente.

Pruebas de Aceptación

El cliente define un número de pruebas de aceptación para cada requisito. Al realizar pruebas de aceptación, los desarrolladores y clientes pueden saber si el software desarrollado cumple con los requisitos. Los desarrolladores de XP consideran que estas pruebas de aceptación son tan importantes como las pruebas unitarias. Para no perder un tiempo valioso, lo mejor es automatizar estos procesos de prueba.

Liberar software con frecuencia a pequeña escala (SmallReleases)

Los requisitos de desarrollo de cada ciclo (Iteración) son lo que más necesitan los usuarios. En XP, los sistemas lanzados al finalizar cada ciclo deberían ser fáciles de evaluar para los usuarios o ya deberían estar listos para su uso práctico. De esta manera, el desarrollo de software ya no es algo invisible e intangible para los clientes, sino algo tangible. XP requiere lanzamientos de software frecuentes. Si es posible, se debe publicar una nueva versión todos los días y una nueva versión debe publicarse inmediatamente después de que se complete cualquier cambio, integración o nuevo requisito. La coherencia y fiabilidad de estas versiones están garantizadas mediante pruebas de aceptación y desarrollo basado en pruebas.

3 Diseño simple, programación en pares, desarrollo basado en pruebas, reorganización y optimización

Los programadores de XP no solo trabajan juntos como un equipo de desarrollo, sino que también trabajan juntos como dos personas en un pequeño equipo La unidad de desarrollo escribe el mismo programa. Los desarrolladores llevan a cabo diseños simples, escriben pruebas unitarias y luego escriben código que cumpla con los requisitos de la prueba y optimizan continuamente el diseño mientras satisfacen las necesidades.

Diseño simple

Esto es lo que más confunde a los principiantes en XP. XP requiere el método más simple para implementar cada pequeño requisito, siempre que el software desarrollado de acuerdo con estos diseños simples deba pasar la prueba. Siempre que estos diseños puedan satisfacer las necesidades actuales del sistema y de los clientes, no hay necesidad de diseños superfluos, y todos estos diseños se reorganizarán y optimizarán continuamente en el proceso de desarrollo posterior.

En XP, no existe un diseño general único para todas las necesidades en el modelo de desarrollo tradicional. En XP, el proceso de diseño recorre casi todo el desarrollo del proyecto: desde la formulación del plan del proyecto, hasta la formulación del plan para cada ciclo de desarrollo (Iteración), el diseño simple de cada módulo de requisitos, la revisión del diseño y constantemente. Remodelación y optimización intermitente del diseño. Todo el proceso de diseño es un proceso de avance y desarrollo continuo y en espiral. Desde esta perspectiva, XP ha logrado lo último en diseño.

Programación en pares

En XP, todo el código es escrito por dos programadores en la misma máquina; este es el aspecto más controvertido y difícil de XP. Un poco de implementación. Esto garantiza que todo el código, el diseño y las pruebas unitarias hayan sido revisados ​​por al menos otra persona, mejorando así la calidad del código, el diseño y las pruebas. Esto puede parecer un desperdicio de recursos humanos, pero diversos estudios demuestran que es todo lo contrario. ——Esta forma de trabajar mejora enormemente la intensidad y eficiencia del trabajo.

Muchos programadores se vieron obligados a intentar esto al principio (XP también necesita el apoyo de órdenes administrativas). Siempre es difícil acostumbrarse al principio y dos personas no son más eficientes que una. El efecto de este enfoque suele tardar unas semanas, uno o dos meses en notarse. Según las estadísticas, el 90% de todos los programadores que acaban de empezar a programar en pareja creen que esta forma de trabajar es más eficaz después de dos meses.

Durante el desarrollo del proyecto, todos cambiarán constantemente sus socios de coprogramación. Por lo tanto, la programación en pares no solo mejora la calidad del software, sino que también mejora el intercambio y las actualizaciones de conocimientos mutuos, y mejora la comunicación y la comprensión mutuas. Esto no sólo beneficia al individuo, sino también a todo el proyecto, el equipo de desarrollo y la empresa. Desde este punto de vista, PairProgramming no sólo es aplicable a XP, sino también a todos los demás métodos de desarrollo de software.

Desarrollo basado en pruebas

La retroalimentación es uno de los cuatro valores básicos de XP: en el desarrollo de software, solo se puede obtener suficiente retroalimentación mediante pruebas suficientes. Las pruebas propuestas en XP se pueden ver en otros métodos de desarrollo de software, como pruebas funcionales, pruebas unitarias, pruebas de sistema y pruebas de carga. La diferencia es que XP combina las pruebas en su tipo incremental en espiral único. Durante el desarrollo, las pruebas se acumulan como el; el proyecto avanza. Además, debido al énfasis en que todo el equipo de desarrollo sea propietario del código, las pruebas también las realizan todos de forma conjunta. Es decir, cualquiera debe ejecutar todas las pruebas antes de colocar un programa (CheckIn) en el código base; si alguien encuentra un ERROR, debe agregar inmediatamente una prueba para el ERROR en lugar de esperar a que la persona que escribió el programa lo haga. completo; cualquiera que se haga cargo de las tareas de otras personas, o modifique el código y el diseño de otras personas, si puede pasar todas las pruebas después de realizar los cambios, demuestra que su trabajo no dañó el sistema. De esta manera, las pruebas realmente pueden desempeñar un papel para ayudar a obtener retroalimentación y, a través de una priorización y acumulación continuas, las pruebas deberían poder cubrir básicamente todas las necesidades de desarrollo y de los clientes, para que los desarrolladores y los clientes puedan obtener la mayor cantidad de retroalimentación posible.

Refactorización

Programación. Aunque los desarrolladores llevan a cabo un diseño simple para cada HISTORIA DE USUARIO, también están mejorando constantemente el diseño. Este proceso se llama refactorización y optimización del diseño (Refactoring). Este nombre apareció por primera vez en el libro "Refactorización: mejora del diseño del código existente" escrito por Martin Fowler.

La refactorización se esfuerza principalmente por reducir las partes repetidas en programas y diseños y mejorar la reutilización de programas y diseños. El concepto de refactorización no fue iniciado por XP. Se ha propuesto durante casi 30 años y siempre se ha considerado una de las características del código de alta calidad. Sin embargo, XP enfatiza que para lograr lo último en refactorización, la refactorización debe realizarse en cualquier momento, en cualquier lugar y tanto como sea posible. Los programadores no deben sentirse mal por los programas que escribieron antes, sino mejorarlos sin piedad. Por supuesto, después de cada cambio, los programadores deben ejecutar programas de prueba para asegurarse de que el nuevo sistema aún cumpla con los requisitos predeterminados.

4 Integración frecuente, propiedad colectiva del código y estándares de programación

El equipo de desarrollo de XP a menudo integra diferentes módulos. Para mejorar la calidad del software, además del desarrollo basado en pruebas y la programación en pares, XP requiere que el código de todos cumpla con las especificaciones de programación. Cualquiera puede modificar el código escrito por otros y todos deben verificar activamente el código escrito por otros.

Integración frecuente (Integration)

En muchos proyectos, los desarrolladores suelen integrar varios módulos muy tarde. En estos proyectos, los desarrolladores a menudo encuentran muchos problemas durante el proceso de integración, pero no están seguros de quién es el programa que tiene el problema. Además, solo después de que se completa la integración, los desarrolladores comienzan a usar todo el sistema un poco, y luego lo hacen de inmediato; entregado a la aceptación del cliente. Los clientes, incluso si estos sistemas pueden pasar la prueba de aceptación final, no tienen mucha confianza debido a su corto tiempo de uso.

Para solucionar estos problemas, XP propone que durante todo el proceso del proyecto se integre la USERSTORY desarrollada con la mayor frecuencia posible (cada vez se integra una nueva USERSTORY). Para cada integración, se deben ejecutar las pruebas unitarias y las pruebas de aceptación correspondientes para garantizar el cumplimiento de los requisitos de desarrollo y del cliente. Después de la integración, se lanza un nuevo sistema de aplicación.

De esta manera, durante todo el proceso de desarrollo del proyecto, se lanzará un nuevo sistema casi cada uno o dos días y, en ocasiones, se lanzarán varias versiones al día. A través de este proceso, los clientes pueden comprender claramente las funciones completadas y el progreso del desarrollo, y comunicarse de manera efectiva y oportuna con los desarrolladores en función de estas situaciones para garantizar la finalización sin problemas del proyecto.

Propiedad colectiva del código

En el proceso de desarrollo de muchos proyectos, los desarrolladores solo mantienen su propio código y a muchas personas no les gusta que otros modifiquen su código a voluntad. Por lo tanto, aunque puede haber documentos de desarrollo correspondientes relativamente detallados, un programador rara vez y no está dispuesto a leer el código de otros programadores, además, porque no está claro qué funciones implementan los programas de otras personas, un programa que los miembros generalmente no se atreven a cambiar; el código de otras personas casualmente. Al mismo tiempo, debido a que mantiene su propio código, algunos problemas nunca se descubren o se resuelven mejor, tal vez debido a limitaciones de tiempo o técnicas. En respuesta a esto, XP defiende que todos son propietarios del código y que todos tienen el derecho y la obligación de leer otros códigos, descubrir y corregir errores y reorganizar y optimizar el código. De esta manera, estos códigos no los escriben solo una o dos personas, sino que los completa todo el equipo de desarrollo del proyecto. Los errores se reducirán mucho, la reutilización mejorará tanto como sea posible y la calidad del código será muy buena. bien.

Para evitar fallas del sistema causadas por la modificación del código de otras personas, todos deben ejecutar el programa de prueba después de realizar modificaciones. (A partir de este punto, podemos ver una vez más cómo las diversas convenciones y reglas de XP se combinan orgánicamente).

Estándares de programación

Todos en el equipo de desarrollo de XP Todos siguen un estándar unificado. estándar de programación, por lo que todo el código parece haber sido escrito por una sola persona. Debido a los estándares de programación unificados, es más fácil para cada programador comprender el código escrito por otros. Este es uno de los requisitos previos importantes para realizar CollectiveCodeOwnership.

5Metáfora (metáfora del sistema), sin horas extras

El proceso XP permite que todos tengan una comprensión común y concisa del sistema mediante el uso de algunas metáforas vívidas. XP cree que las horas extras son anormales porque indican que hay un problema con la estimación y organización del progreso del proyecto.

Metáfora (metáfora del sistema)

Para ayudar a todos a comprender claramente las necesidades del cliente y las funciones del sistema que deben desarrollarse, el equipo de desarrollo de XP utiliza muchas metáforas vívidas para describir el sistema. O cómo funciona el módulo de funciones. Por ejemplo, para un motor de búsqueda, su metáfora puede ser "un gran grupo de arañas, buscando cosas para atrapar en la red y luego llevándolas de regreso al nido".

Sin horas extra

Una gran cantidad de horas extras significa que el plan original es inexacto o que el programa no tiene nada claro qué trabajo puede completar y cuándo. Además, los gerentes de desarrollo y los clientes no pueden comprender con precisión la velocidad del desarrollo y los desarrolladores también están muy cansados. XP cree que si se produce una gran cantidad de horas extra, los gerentes de desarrollo (como Coach) deben trabajar con los clientes para determinar los motivos de las horas extra y ajustar los planes, cronogramas y recursos del proyecto de manera oportuna.

Introducción a algunos conceptos básicos en XP

UserStory: los desarrolladores requieren que los clientes escriban todos los requisitos en historias cortas independientes, cada una de las cuales solo toma unos días para completarse. Durante el proceso de desarrollo, los clientes pueden proponer una nueva UserStory o cambiar la UserStory anterior en cualquier momento.

StoryEstimates y velocidad de desarrollo: el equipo de desarrollo estima cada UserStory y calcula repetidamente la velocidad de desarrollo en función de la situación real en cada ciclo de desarrollo (Iteración). De esta forma, desarrolladores y clientes pueden saber cuántas UserStories se pueden desarrollar cada semana.

ReleasePlan y ReleaseScope: Durante todo el proceso de desarrollo, los desarrolladores seguirán lanzando nuevas versiones. Los desarrolladores y los clientes trabajan juntos para determinar la UserStory incluida en cada versión.

Iteración (ciclo de desarrollo) e IteraciónPlan: en un proceso de lanzamiento, los desarrolladores piden a los clientes que seleccionen la UserStory más valiosa como contenido de desarrollo para las próximas una o dos semanas.

TheSeed: Una vez completado el primer ciclo de desarrollo (Iteración), el sistema se envía al cliente. Aunque este no es el producto final, ha implementado varias historias que los clientes consideran las más importantes, y los desarrolladores agregarán gradualmente nuevos módulos.

Integración Continua (integración): Ensamblar uno a uno los módulos desarrollados de UserStory, y abordar e incluso completar paso a paso el producto final.

Pruebas de aceptación (pruebas funcionales): Para cada UserStory, el cliente definirá algunos casos de prueba y el desarrollador automatizará el proceso de ejecución de estos casos de prueba.

UnitTest (prueba unitaria): antes de comenzar a escribir un programa, los programadores primero escriben los programas de prueba correspondientes para la mayoría de los métodos de clase.

Refactorización (reorganización y optimización): elimina partes redundantes del código y aumenta la reutilización y escalabilidad del código.

Resumen

Uno de los factores de éxito de XP es el énfasis en los comentarios de los clientes: el propósito del desarrollo es satisfacer las necesidades de los clientes. El enfoque XP permite a los desarrolladores afrontar los cambios en las necesidades de los clientes con confianza en todo momento. XP enfatiza el trabajo en equipo y los gerentes, clientes y desarrolladores son todos miembros del equipo de desarrollo. El equipo se esfuerza por desarrollar software de alta calidad a través de una comunicación y cooperación total entre sí, utilizando XP, un método simple pero efectivo. El diseño de XP es simple y eficiente; los programadores obtienen comentarios de los clientes mediante pruebas y modifican el código y el diseño de acuerdo con los cambios. Siempre se esfuerzan por entregar el software a los clientes lo antes posible. Los programadores de XP tienen el coraje de afrontar cambios en los requisitos y la tecnología.

XP es muy parecido a un rompecabezas intelectual formado por muchas piezas pequeñas. Cada pequeña pieza no tiene sentido cuando se ve individualmente, pero una vez ensamblada, se presentará una hermosa imagen frente a usted.