Práctica de modelado ágil
Prácticas principales:
Participación activa de las partes interesadas. Ampliamos el concepto de clientes en el sitio de XP: los desarrolladores deben mantenerse en contacto con los usuarios en el sitio; los usuarios en el sitio deben tener suficiente autoridad y capacidad para proporcionar información relacionada con el sistema en construcción y tomar decisiones oportunas relacionadas con los requisitos; y determinar sus prioridades. AM amplía la práctica de "cliente en vivo" de XP para "involucrar activamente a las partes interesadas en el proyecto". Este concepto de partes interesadas del proyecto incluye a los usuarios directos, sus gerentes, altos directivos, operadores y personal de soporte. Esta participación incluye: las decisiones oportunas de asignación de recursos de la alta dirección, el apoyo público y privado de la alta dirección al proyecto, la participación activa del personal de operaciones y soporte en la fase de desarrollo de requisitos y sus modelos relevantes en sus respectivos campos.
Usar los artefactos correctamente. Cada artefacto tiene su propia aplicación. Por ejemplo, el diagrama de actividad de UML es adecuado para describir procesos de negocio. En cambio, la estructura estática de una base de datos se representa mejor mediante datos físicos o un modelo de datos. Muchas veces un diagrama es más útil que el código fuente y una imagen vale más que mil palabras. De manera similar, un modelo es mucho más útil que 1K de código fuente, siempre que se use correctamente (tomando prestado el vocabulario de los "Requisitos de software" de Karl Wieger). Porque cuando estás estudiando el plan de diseño, puedes discutirlo con tus compañeros, dibujar algunos diagramas en la pizarra o puedes sentarte y desarrollar algunos ejemplos de código tú mismo. El primer método es mucho más efectivo. . ¿Qué quiere decir esto? Necesitarás conocer los pros y los contras de cada artefacto, lo cual no es tan fácil cuando tienes muchos modelos para elegir.
Propiedad colectiva. Todos pueden usar y modificar cualquier modelo y cualquier artefacto del proyecto durante el tiempo que sea necesario.
Pon a prueba tu pensamiento. Cuando construyes un modelo, debes preguntarte constantemente: "¿Cómo pruebo esto?" Si no puedes probar el software que estás desarrollando, no deberías desarrollarlo. En varios procesos de software modernos, las actividades de prueba y control de calidad se ejecutan a lo largo de todo el ciclo de vida del proyecto. Algunos procesos incluso proponen el concepto de "escribir pruebas primero y luego escribir software" (esta es una práctica de XP: "probar primero").
Crear modelos en paralelo. Debido a que cada modelo tiene sus ventajas y desventajas, ningún modelo puede satisfacer completamente las necesidades de modelado. Por ejemplo, cuando reúne requisitos, necesita desarrollar algunos casos de uso básicos o materiales de usuario, un prototipo de interfaz de usuario básico y algunas reglas comerciales. Luego, combinado con la práctica y el cambio a otro artefacto, los modeladores ágiles descubrirán que desarrollar múltiples modelos en cualquier momento es mucho más eficiente que simplemente centrarse en un modelo.
Crea contenido sencillo. Debe mantener su modelo (requisitos, análisis, arquitectura, diseño) lo más simple posible, pero solo si satisface las necesidades de las partes interesadas de su proyecto. Esto significa que no debe simplemente agregar funciones a su modelo a menos que tenga una buena razón: si no tiene una funcionalidad certificada por el sistema, no debe agregarla a su modelo. Si tiene tanto coraje, una vez que se le solicite agregar esta función, podrá hacerlo de inmediato. Esto es lo mismo que el enfoque de "diseño simple" de XP.
Modelado sencillo. Cuando piensa en todos los diagramas que puede utilizar (diagramas UML, diagramas de interfaz de usuario, modelos de datos, etc.), encontrará rápidamente que la mayoría de las veces sólo necesita algunos de estos diagramas. Un modelo simple puede mostrar la funcionalidad principal que desea comprender, como un diagrama de clases, siempre que muestre las principales responsabilidades de las clases y las relaciones entre clases. Sí, no hay nada de malo en que los estándares de codificación le indiquen que necesita agregar código marco a su modelo, como todas las operaciones get y set, pero ¿cuánto valor proporciona esto? Me temo que son muy pocos.
Muestra tu modelo públicamente. Debes mostrar tus modelos públicamente. El soporte del modelo se llama "muro de modelado" o "muro de maravillas".
Esta práctica crea una atmósfera de comunicación abierta y honesta entre su equipo y entre usted y las partes interesadas de su proyecto porque todos los modelos están actualmente disponibles para ellos y usted no tiene nada que informarles. Pegas tu modelo en la pared de modelado, donde es visible para todos los desarrolladores y partes interesadas del proyecto. Una pared de modelado puede ser física, una pizarra diseñada para su diagrama de arquitectura o una copia impresa de un modelo de datos físico, o puede ser virtual, como una página web que almacena imágenes escaneadas. Si desea obtener más información, puede consultar "Especificar las necesidades con el muro maravilloso" de Ellen Gottesdiener.
Cambiar a otro artefacto. Cuando esté desarrollando un artefacto (como un caso de uso, una tarjeta CRC, un diagrama de secuencia o incluso un código fuente), se encontrará atascado. En este momento, debería considerar cambiar temporalmente a otro artefacto. Cada artefacto tiene sus propias ventajas y desventajas, y cada artefacto es adecuado para un determinado tipo de trabajo. Siempre que te quedes atrapado en un artefacto, no podrás continuar, lo que significa que tendrás que cambiar a otro artefacto. Por ejemplo, si está creando casos de uso básicos, pero tiene dificultades para describir reglas comerciales, entonces debería intentar desviar su atención a otros artefactos, que pueden ser prototipos básicos de interfaz de usuario, modelos CRC, reglas comerciales, casos de uso del sistema, o cambiar casos de uso. Después de cambiar a otro artefacto, es posible que no se quede estancado inmediatamente porque puede continuar trabajando en el otro artefacto. Además, si cambias tu perspectiva, a menudo encontrarás la razón por la que estabas estancado en primer lugar.
Pequeño modelado incremental. Al utilizar el desarrollo incremental, puede dividir una gran carga de trabajo en pequeñas partes listas para su lanzamiento, con cada incremento limitado a unas pocas semanas o uno o dos meses. Esto le permite entregar software a los usuarios más rápido y aumentar su agilidad.
Modelar con otros. Cuando modelas con un propósito, descubrirás que puedes estar modelando para entender algo, para comunicar tus ideas a otros o para establecer una visión para tu proyecto. Esta es una actividad de grupo, que requiere que todos cooperen de manera efectiva. Descubre que su equipo de desarrollo debe trabajar en conjunto para crear un conjunto básico de modelos que sean importantes para su proyecto. Por ejemplo, para crear la imagen y la arquitectura de un sistema, es necesario trabajar con miembros del mismo grupo para crear una solución en la que todos estén de acuerdo y al mismo tiempo mantenerla lo más simple posible. Muchas veces, lo mejor que se puede hacer es discutir el tema con otra persona.
Verificar con código. Un modelo es una abstracción que refleja correctamente algún aspecto del sistema que estás construyendo. ¿Pero puede funcionar? Para conocer los resultados, debes verificar tu modelo con código. ¿Ya ha creado un boceto de la información de su dirección de pago utilizando algunas páginas HTML? Escriba código, muestre la interfaz de usuario final a los usuarios y obtenga comentarios. ¿Ha creado un diagrama de secuencia UML que represente una lógica de reglas comerciales compleja? Escriba código de prueba, código comercial y ejecute pruebas para asegurarse de que lo está haciendo bien. Nunca olvide utilizar un enfoque iterativo para el desarrollo de software (que es una práctica estándar para la mayoría de los proyectos) y nunca olvide que el modelado es solo una tarea entre muchas. Realice un período de modelado, codificación y prueba (entre otras actividades).
Utiliza las herramientas más sencillas. La mayoría de los modelos se pueden dibujar en una pizarra, papel o incluso en el reverso de un pañuelo de papel. Si desea guardar estos íconos, puede tomarles una foto con una cámara digital o simplemente transcribirlos en papel. Esto se debe a que la mayoría de los gráficos se pueden desechar. Sólo son valiosos cuando dibujas un modelo y piensas en un problema. Una vez solucionado este problema, ya no tienen sentido. De esta manera, la pizarra y el etiquetado suelen ser las mejores opciones para sus herramientas de modelado: utilice herramientas de dibujo para crear diagramas y presentarlos a las partes interesadas importantes del proyecto. Podemos utilizar herramientas de modelado sólo si pueden aportar valor a nuestros esfuerzos de programación (como la generación automática de código). Puedes pensarlo de esta manera: si estás creando modelos simples, estos modelos pueden descartarse. El propósito de su modelado es comprender. Una vez que se comprende el problema, el modelo ya no es necesario y se puede descartar sin necesidad de herramientas de modelado sofisticadas.
Ejercicios adicionales:
Utilizar estándares de modelado.
Esta práctica pasó a llamarse según los estándares de codificación XP. El concepto básico es que los desarrolladores deben aceptar y adherirse a un conjunto de estándares de modelado en proyectos de software. Es valioso seguir las mismas convenciones de codificación: seguir las pautas de codificación que usted elija da como resultado un código conciso y comprensible que es mucho mejor que el código que no lo hace. De manera similar, seguir los mismos estándares de modelado tiene un valor similar. Hay muchos estándares de modelado disponibles, incluido el Lenguaje de modelado unificado (UML) desarrollado por Object Management Group (OMG), que define la notación y la semántica de un modelo común orientado a objetos. UML ha tenido un buen comienzo, pero no es suficiente: como vio en "Frente a UML", UML no cubre todos los artefactos de modelado posibles. Además, no proporciona ninguna guía de estilo de modelado para construir diagramas claramente visibles. Entonces, ¿cuál es la diferencia entre una guía de estilo y un estándar? Para el código fuente, un estándar podría dictar que NombreAtributo debe tener el formato NombreAtributo, mientras que una guía de estilo podría dictar sangría de código para estructuras de control (declaraciones if y bucles) dentro de una unidad. Para los modelos, un estándar podría ser usar rectángulos para modelar clases, una guía de estilo podría ser que las subclases en el diagrama deben colocarse debajo de la clase principal.
Aplica el patrón gradualmente. Los modeladores eficaces aprenderán patrones arquitectónicos, patrones de diseño y patrones de análisis comunes y los aplicarán adecuadamente a sus modelos. Sin embargo, como señala Martin Fowler en Is Design Dead, los desarrolladores deberían sentirse cómodos usando patrones y aplicándolos de forma incremental. Esto refleja valores simples. En otras palabras, si sospecha que se puede aplicar un patrón, debe modelarlo de esta manera: primero implemente el alcance mínimo que necesita ahora, pero dejará un presagio para una reconstrucción posterior. De esta manera, implementará un modelo completo de la forma más sencilla posible. Simplemente no vayas más allá de tu patrón. Por ejemplo, en su diseño, encuentra que hay un lugar donde el patrón de estrategia GoF es adecuado, pero en este momento solo tiene dos algoritmos para implementar. La forma más sencilla es encapsular el algoritmo en una clase separada y crear una operación que pueda seleccionar el algoritmo correspondiente y pasar la entrada relevante al algoritmo. Esta es una implementación parcial del patrón Estrategia, pero ya has sentado las bases. Si hay que implementar más algoritmos en el futuro, puede refactorizar su diseño. Debido a las necesidades del modelo estratégico, no es necesario establecer todos los marcos. Este enfoque le permite utilizar el patrón fácilmente.
Descartar el modelo temporal. La mayoría de los modelos que crea son modelos temporales: bocetos de diseño, prototipos de baja precisión, fichas, posibles arquitecturas/diseños, etc. - y no proporciona ningún valor adicional después de cumplir su propósito. Es normal que el modelo pierda rápidamente la sincronización con el código. Debe tomar una decisión: si la práctica de "actualizar modelos sincrónicamente" puede agregar valor a su proyecto, entonces actualice los modelos simultáneamente o, si la inversión en actualizarlos compensará todo el valor que pueden proporcionar (beneficios negativos), luego descártenlo ellos.
El modelo de contrato debe ser formal. Necesita un modelo de contrato cuando los recursos de información que requiere su sistema están controlados por organizaciones externas, como bases de datos, sistemas heredados y servicios de información. El modelo de contrato requiere un acuerdo mutuo y está sujeto a cambios según el tiempo y la necesidad. Ejemplos de modelos de contrato son documentación detallada de API, descripciones de formularios de almacenamiento, DTD XML o modelos de datos físicos que describen * * * una base de datos compartida. Como contrato legal, un modelo de contrato generalmente requiere que usted invierta importantes recursos en su desarrollo y mantenimiento para garantizar que sea correcto y detallado. Su objetivo es minimizar el modelo de contrato de su sistema, que sea consistente con los principios de XP. Tenga en cuenta que casi siempre necesitará herramientas electrónicas para crear un modelo de contrato porque el modelo debe mantenerse a lo largo del tiempo.
Modelado de comunicación. La segunda razón para modelar es comunicarse con personas fuera del equipo o construir un modelo de contrato. Debido a que algunos modelos están destinados a clientes fuera de su equipo, debe invertir tiempo en embellecerlos utilizando herramientas como un procesador de textos, un conjunto de herramientas de dibujo o incluso la herramienta CASE "publicitada".
Para comprender el modelado, las aplicaciones más importantes del modelado son explorar un espacio problemático para identificar y analizar los requisitos de un sistema, o comparar y contrastar posibles opciones de diseño para identificar la solución más simple posible. probable que cumpla con los requisitos. Según esta práctica, se crean diagramas pequeños y simples para algún aspecto del software, como un diagrama de ciclo de vida de clase o una secuencia de pantalla. Estos diagramas generalmente se descartan después de haber completado su propósito (comprensión).
Reutilizar recursos existentes. Se trata de una gran cantidad de información que los modeladores ágiles pueden aprovechar. Por ejemplo, tal vez algunos patrones de análisis y diseño sean adecuados para aplicar al sistema, tal vez pueda beneficiarse de los modelos existentes, como modelos de requisitos empresariales, modelos de procesos comerciales, modelos de datos físicos o incluso describir cómo implementar el sistema entre sus usuarios. modelo comunitario. Sin embargo, aunque a menudo se busca el modelo adecuado, la realidad es que en la mayoría de las organizaciones estos modelos no existen o están desactualizados.
No actualizar a menos que sea absolutamente necesario. Sólo debe actualizar el modelo cuando realmente lo necesite, es decir, cuando el costo de no actualizar el modelo exceda el costo de actualizar el modelo. Con este enfoque, encontrará que la cantidad de modelos actualizados es mucho menor que antes, porque la realidad es que no existen modelos tan perfectos que aporten valor. He usado el mapa de calles de mi ciudad natal durante 5 años y la ubicación de mi calle no ha cambiado desde que llegué aquí, por lo que este mapa todavía me resulta útil. Sí, podría comprar un mapa nuevo y publicarlo una vez al año, pero ¿para qué molestarme? La ausencia de algunas calles no me duele lo suficiente como para justificar la inversión en un nuevo mapa. En pocas palabras, no tiene sentido gastar dinero en mapas nuevos cada año cuando los mapas todavía son útiles. Se ha desperdiciado demasiado tiempo y dinero manteniendo sincronizados los modelos, la documentación y el código fuente cuando la sincronización es imposible. ¿No sería mejor invertir tiempo y dinero en software nuevo?