Explicación de los términos de desarrollo ágil

AM es una actitud, no un proceso descriptivo. AM es una colección de valores de los modeladores ágiles, principios adoptados por los modeladores ágiles y prácticas aplicadas por los modeladores ágiles. AM describe un estilo de modelado que, cuando se aplica en un entorno ágil, puede mejorar la calidad y la velocidad del desarrollo evitando simplificaciones excesivas y expectativas poco realistas. AM describe un estilo de modelado que, cuando se aplica en un entorno ágil, puede mejorar la calidad y la velocidad del desarrollo y, al mismo tiempo, evitar simplificaciones excesivas y expectativas poco realistas. Si busca orientación sobre detalles como la creación de un diagrama de secuencia UML o el dibujo de un diagrama de flujo de interfaz de usuario, consulte Modelado. Hay muchos libros de modelado listados en Artifacts, y recomiendo particularmente (aunque esto es injusto) mi libro Introducción a los objetos 2/e.

AM es un complemento de las metodologías existentes, no una metodología completa. El objetivo principal de AM es el modelado, seguido de la documentación. No obstante, las técnicas de AM pueden aumentar la efectividad del modelado basado en el uso de métodos ágiles por parte de su equipo (por ejemplo, programación extrema, método de desarrollo de sistemas dinámicos (DSDM), Crystal Clear).

AM también se puede utilizar con procesos tradicionales (p. ej., procesos unificados), aunque estos procesos se pueden utilizar para aumentar la eficacia del modelado.

La AM también se puede utilizar con procesos tradicionales como los Procesos Unificados, aunque la menor agilidad de dichos procesos hará que la AM tenga menos éxito.

AM es una forma eficaz de trabajar para satisfacer conjuntamente las necesidades de las partes interesadas del proyecto. Los desarrolladores ágiles trabajan en equipos con las partes interesadas del proyecto y se turnan para desempeñar un papel directo y proactivo en el desarrollo del sistema. No existe un "yo" en el diccionario ágil.

AM funciona y está empezando a funcionar. A medida que aprenda más sobre la fabricación aditiva, una cosa que podría molestarle es su enfoque casi implacable en la eficiencia. AM le dice: Maximizar la inversión de las partes interesadas en el proyecto; Construir modelos o documentos cuando haya un propósito y una audiencia claros que deban abordarse; Utilizar los artefactos adecuados para documentar la situación actual; Crear un modelo lo más simple posible en todo momento;

AM no es una panacea. El modelado ágil es, en el mejor de los casos, una técnica eficaz que puede mejorar los resultados de muchos desarrollos de software profesionales. No es una panacea para todos los problemas de desarrollo. Si trabaja duro en ello, si se concentra en ello y si adopta de todo corazón sus valores, principios y prácticas, entonces, como desarrollador, podrá mejorar sus resultados de desarrollo.

AM está dirigido a desarrolladores comunes, pero no excluye a aquellos desarrolladores capaces. Los valores, principios y prácticas de AM son simples y fáciles de entender, muchos de los cuales usted puede haber adoptado o esperar adoptar a lo largo de los años. La aplicación de la tecnología AM no requiere que practiques motos acuáticas, pero sí necesitas dominar algunas habilidades básicas de desarrollo de software. Lo más difícil de la AM es que te obliga a aprender una gama más amplia de técnicas de modelado, lo cual es una actividad continua a largo plazo. Aprender a modelar puede ser difícil al principio, pero puedes intentar superarlo aprendiendo una técnica a la vez.

AM no se opone a la documentación. La creación y mantenimiento de documentación aumenta la inversión del proyecto.

AM no se opone a la creación y mantenimiento de documentación, porque la creación y mantenimiento de documentación aumentará la inversión en el proyecto. La documentación ágil debe ser lo más simple posible, lo más pequeña posible y centrarse solo en lo que es directamente relevante para el sistema que se está desarrollando, al mismo tiempo que comprende completamente las necesidades de la audiencia.

AM tampoco está en contra de las herramientas CASE. Los modeladores ágiles utilizan herramientas que ayudan a los desarrolladores a mejorar los resultados y aumentar el valor. Y tratan de utilizar las herramientas más simples para realizar el trabajo.

¿Cuándo es ágil?

Para comprender la AM, es necesario comprender la diferencia entre modelos y modelos ágiles. Un modelo es un concepto abstracto que describe uno o más aspectos de un problema, o posibles soluciones para abordar un problema. Tradicionalmente, los modelos se han considerado diagramas acompañados de documentación. Sin embargo, también se pueden considerar modelos artefactos menos intuitivos, como un conjunto de tarjetas CRC, una descripción textual de una o más reglas comerciales o una descripción estructurada en inglés de un proceso comercial. Los modelos ágiles son modelos suficientemente buenos.

Pero, ¿cómo se puede saber si un modelo es lo suficientemente bueno? Un modelo ágil es suficientemente bueno cuando presenta las siguientes características:

El modelo ágil logra su propósito. A veces construyes un modelo para la comunicación, tal vez necesites decirle a los altos directivos el alcance de tu trabajo, a veces construyes un modelo para la comprensión, tal vez necesites definir una estrategia de diseño para implementar un conjunto de clases de Java. Que un modelo ágil sea lo suficientemente bueno depende de si logra la intención original cuando se creó.

Los modelos ágiles son fáciles de entender. Los modelos ágiles deben ser comprensibles para su público objetivo. Utilice un lenguaje empresarial que los usuarios puedan comprender para describir los modelos de requisitos, mientras que los modelos de arquitectura técnica deben utilizar términos técnicos con los que los desarrolladores estén familiarizados. La notación de modelado utilizada afecta la comprensibilidad: si los usuarios no comprenden el significado de los símbolos en un diagrama de casos de uso UML, entonces el diagrama de casos de uso no tiene ningún valor para ellos. En este caso, utilice otros métodos o enseñe a los usuarios técnicas de modelado. Los problemas de estilo también pueden afectar la comprensibilidad, como evitar cruzar líneas. Los diagramas desordenados son más difíciles de entender que los diagramas claros. El nivel de detalle de un modelo (ver más abajo) también afecta la comprensibilidad, ya que un modelo demasiado detallado es más difícil de entender que un modelo menos detallado. La brevedad (ver más abajo) también es un factor de comprensibilidad.

Desarrollo ágil

El modelo ágil es bastante correcto. Por lo general, no es necesario que los modelos sean 100% correctos, sólo lo suficientemente correctos. Por ejemplo, si un mapa de calles omite una calle, o si el mapa dice que una calle es transitable pero descubres que está cerrada por mantenimiento, ¿tiras el mapa y comienzas a acelerar por la ciudad cometiendo delitos? No es probable. Considerará actualizar el mapa y podría sacar un bolígrafo y editarlo usted mismo, o ir a una tienda local y comprar una copia de la última versión del mapa (su mapa original no está actualizado). Tal vez aún te conformes con ese mapa que no es perfecto, pero sí utilizable, porque es lo suficientemente bueno para ti. Aún puedes usar ese mapa para moverte porque sigue siendo un modelo correcto con la mayoría de las calles marcadas. La razón por la que no tiraste el mapa cuando descubriste que era incorrecto fue porque no te importaba si era perfecto. Del mismo modo, cuando encuentra un error en un modelo de requisitos o en un modelo de datos, elige actualizarlo o aceptarlo; no es perfecto, pero es lo suficientemente bueno. Algunos miembros del proyecto toleran esta inexactitud, otros no: depende de la naturaleza del proyecto, de la naturaleza de cada miembro del equipo y de la naturaleza de la organización. La corrección adecuada depende tanto de la audiencia del modelo como del problema en el que estás trabajando.

Los modelos ágiles son totalmente consistentes. Los modelos ágiles no necesitan ser completamente consistentes consigo mismos (u otros artefactos útiles). Si un caso de uso llama explícitamente a otro caso de uso en uno de sus pasos, entonces el diagrama de caso de uso correspondiente debe anotar la versión UML <> de la relación entre los dos casos de uso. Sin embargo, miras las fotos y te das cuenta de que no hacen eso. ¡Existe una inconsistencia entre los casos de uso y los diagramas! ¡El peligro es demasiado peligroso! ¡Alerta roja! Corre por tu vida. Espera, tu modelo de caso de uso es inconsistente, pero no es el fin del mundo. Sí, lo ideal es que todos tus artefactos sean exactamente iguales, pero eso normalmente no es posible. Cuando desarrollo un sistema empresarial simple, normalmente puedo tolerar algunas inconsistencias. Pero a veces no puedo tolerar la inconsistencia. La prueba más contundente es el sistema de medición de precisión utilizado por la NASA cuando lanzó la sonda espacial a Marte en 1999. Todo lo que se necesita para establecer un modelo ágil es un punto de vista suficientemente consistente y, por lo general, no es necesario utilizar un modelo tan perfecto.

Existen compensaciones obvias entre corrección y coherencia. Si mantiene un artefacto (lo que llamamos "custodia"), entonces necesita dedicar recursos para actualizarlo con el tiempo. De lo contrario, caducará y no te será de utilidad. Por ejemplo, puedo tolerar un mapa con una o dos calles mal etiquetadas, pero no puedo tolerar un mapa con tres cuartas partes de las calles mal etiquetadas. Existe una compensación en la cantidad de esfuerzo que se debe poner para garantizar que los artefactos sean lo suficientemente correctos. Demasiado esfuerzo innecesario ralentizará el proyecto, mientras que un compromiso insuficiente no garantizará los resultados correctos.

Los modelos ágiles tienen suficiente detalle. No es necesario que una hoja de ruta etiquete cada casa en cada calle. Eso sería demasiado detallado y dificultaría el uso del mapa. Sin embargo, cuando se construye una carretera, estoy seguro de que el equipo de construcción tendrá un mapa de calles detallado que incluye cada edificio, línea de alcantarillado, caja eléctrica, etc., suficiente detalle para que el mapa sea útil.

Sin embargo, este mapa no necesariamente tiene que mostrar todos los patios y las rutas hacia ellos. Porque eso sería demasiado problema. Un nivel suficiente de detalle es relevante tanto para el público como para el propósito para el cual utilizarán el modelo: los conductores necesitan mapas que muestren las carreteras, los constructores necesitan mapas que muestren detalles de ingeniería civil.

Con un modelo arquitectónico en mente, un conjunto de diagramas en una pizarra puede ser suficiente; actualice estos diagramas a medida que avanza el proyecto y tal vez necesite usar la herramienta CASE para generar algunos diagramas que puedan requerir Realice registros detallados basados ​​en circunstancias específicas. Diferentes proyectos tienen diferentes necesidades. En cada caso, en realidad está desarrollando y manteniendo un modelo arquitectónico con suficiente detalle, pero el concepto de "suficiente detalle" depende del contexto.

Los modelos ágiles aportan valor positivo. Un requisito básico para cualquier artefacto en un proyecto es que proporcione un valor positivo. ¿Puede un modelo arquitectónico aportar valor a su proyecto que exceda el costo total de desarrollo y mantenimiento (opcional)? Los modelos arquitectónicos ciertamente tienen valor porque refuerzan la visión del equipo. Sin embargo, si cuesta más que eso, significa que no ofrece un valor positivo. Vea lo imprudente que es invertir 100.000 dólares para desarrollar un modelo de arquitectura detallado y documentado cuando puede lograr su utilidad gastando 5.000 dólares simplemente dibujando unos cuantos diagramas en una pizarra.

Los modelos ágiles deben ser lo más simples posible. Mientras puedas hacer esto, debes esforzarte por hacer que tu modelo sea lo más simple posible. El nivel de detalle del modelo afecta el nivel de simplicidad, al igual que la gama de símbolos utilizados. Por ejemplo, los diagramas de clases UML contienen una gran cantidad de símbolos, incluido el OCL del lenguaje de restricciones de objetos, pero la mayoría de los diagramas se pueden completar utilizando solo un pequeño conjunto de símbolos. Por lo tanto, generalmente no es necesario utilizar todos los símbolos; puede limitarse a un subconjunto de símbolos que sea suficiente para realizar el trabajo.

Por lo tanto, la definición de un modelo ágil es: un modelo que logra su propósito sin agregar contenido adicional; un modelo que es comprensible para su público objetivo; un modelo que es suficiente; sea ​​correcto, suficientemente consistente y suficientemente detallado; uno que proporcione un valor positivo a la inversión en la creación y el mantenimiento del modelo;

Una pregunta filosófica común es si el código fuente es un modelo y, más importante aún, si es un modelo ágil. Si me hicieran esta pregunta fuera de nuestro artículo, respondería: Sí, el código fuente es un modelo, aunque muy detallado, porque es una abstracción del software. También diría que un buen código también es un modelo ágil. Pero aquí también necesito diferenciar entre los dos, todavía hay una diferencia entre el código fuente y el modelo ágil: el modelo ágil le ayuda a obtener el código fuente.