Principios del modelado ágil
2. Principios del modelado ágil
El modelado ágil (AM) define una serie de principios básicos y principios auxiliares que sientan las bases para las prácticas de modelado en los proyectos de desarrollo de software. Algunos de estos principios se han tomado prestados de XP y se describen en detalle en Explicación de la programación extrema. Algunos de los principios de XP se derivan de una conocida ingeniería de software. ¡Las ideas de reutilización se pueden encontrar en todas partes! Básicamente, la explicación de estos principios en este artículo se centra en cómo afectan el trabajo de modelado. De esta manera, podemos ver estos principios tomados de XP desde otra perspectiva;
Principio básico
Abogar por la simplicidad Cuando trabaje en desarrollo, debe defender que la solución más simple es la mejor. No construyas demasiado tu software. En términos de AM, si no necesita esta funcionalidad adicional ahora, no la agregue al modelo. Tenga el coraje: no necesita sobremodelar el sistema ahora. Solo necesita modelarlo en función de los requisitos existentes y luego reconstruir el sistema cuando los requisitos cambien en el futuro. Mantenga el modelo lo más simple posible.
Acepte el cambio. Las necesidades cambian todo el tiempo y la comprensión de las personas sobre las necesidades también cambia todo el tiempo. A medida que avanza el proyecto, las partes interesadas del proyecto pueden cambiar: nuevas personas se unen y las antiguas se van. Las opiniones de las partes interesadas del proyecto también pueden cambiar, y los objetivos y criterios de éxito de sus esfuerzos también pueden cambiar. Esto significa que a medida que avanza el proyecto, el entorno del proyecto cambia constantemente, por lo que sus métodos de desarrollo deben poder reflejar esta realidad.
Su segundo objetivo es la sostenibilidad Incluso si su equipo ha entregado un sistema funcional a los usuarios, su proyecto aún puede fallar, satisfaciendo las necesidades de las partes interesadas del proyecto. Esto incluye que su sistema debe ser lo suficientemente robusto como para adaptarse. futura expansión. Como suele decir Alistair Cockburn, cuando estás en una competencia de desarrollo de software, tu segundo objetivo es prepararte para la próxima competencia. La sostenibilidad puede referirse a la próxima versión importante del sistema o al funcionamiento y soporte del sistema que está construyendo. Para hacer esto, no solo debe crear software de alta calidad, sino también crear suficiente documentación y materiales de soporte para garantizar que el próximo juego se pueda jugar de manera efectiva. Debes considerar muchos factores, incluido si tu equipo actual aún puede participar en el próximo juego, el entorno del próximo juego y la importancia del próximo juego para tu organización. En pocas palabras, cuando te estás desarrollando, debes poder imaginar el futuro.
Cambio incremental. Un concepto importante relacionado con el modelado es que no es necesario tenerlo todo listo desde el principio. De hecho, incluso si quisieras hacer esto, es poco probable. Además, no es necesario que incluyas todos los detalles en tu modelo, solo necesitas los suficientes. No es necesario intentar construir un modelo que lo abarque todo al principio. Simplemente puede desarrollar un modelo pequeño, o un modelo resumido, para sentar las bases y luego mejorarlo lentamente o descartarlo cuando ya no sea necesario. . Ésta es la idea de incremento.
Maximice la inversión de las partes interesadas. Para desarrollar software que satisfaga sus propias necesidades, las partes interesadas de su proyecto deben invertir tiempo, dinero, equipos y otros recursos. Las partes interesadas deberían poder elegir la mejor forma de invertir y también pueden pedirle a su equipo que no desperdicie recursos. Además, todavía tienen la última palabra a la hora de decidir cuántos recursos invertir. Si estos recursos son suyos, ¿quiere que se hagan mal uso de sus recursos?
Modelado intencionado Con respecto a sus artefactos, como modelos, código fuente y documentos, muchos desarrolladores están preocupados por si son lo suficientemente detallados, si son demasiado detallados o si lo son. lo suficientemente correcto.
No debes modelar sin sentido. Primero debes preguntarte por qué quieres construir este artefacto y para quién quieres construirlo. En relación con el modelado, tal vez debería saber más sobre un determinado aspecto del software. Tal vez para garantizar el buen progreso del proyecto, necesite comunicar sus métodos a los altos directivos. Tal vez necesite crear documentos que describan el sistema. que otros puedan operarlo, mantener y mejorar el sistema. Si ni siquiera sabes por qué modelas y para quién, ¿por qué deberías seguir preocupándote? Primero, debe determinar el propósito del modelado y la audiencia del modelo. Sobre esta base, asegúrese de que el modelo sea correcto y lo suficientemente detallado. Una vez que un modelo logra sus objetivos, puede dejar de trabajar y pasar a otras tareas, como escribir código para probar el funcionamiento del modelo. Este principio también se puede aplicar para cambiar un modelo existente: si se va a cambiar algo, tal vez un patrón familiar, se deben tener las razones correctas para realizar el cambio (tal vez para respaldar un nuevo requisito o para reestructurar el modelo). estructurado para garantizar la simplicidad). Una implicación importante de este principio es que debes conocer a tu audiencia, incluso si esa audiencia eres tú mismo. Por ejemplo, si está creando un modelo para mantenedores, ¿qué necesitan exactamente? ¿Es suficiente un documento detallado de 500 páginas o es suficiente una descripción general del trabajo de 10 páginas? ¿No lo sabes? Ve a hablar con ellos y descubre lo que quieres.
Múltiples modelos. El desarrollo de software requiere el uso de múltiples modelos porque cada modelo solo puede describir un único aspecto del software "¿Qué tipo de modelos necesitamos para desarrollar las aplicaciones comerciales actuales?" del software actual, su caja de herramientas de modelado debe contener una gran cantidad de técnicas útiles (para obtener una lista de artefactos, consulte Artefactos de modelado de AM). Es importante tener en cuenta que no es necesario desarrollar todos los modelos para un sistema, pero debe seleccionar algunos modelos en función de las condiciones específicas del sistema. Diferentes sistemas utilizan diferentes partes del modelo. Por ejemplo, al igual que con las reparaciones del hogar, cada trabajo no requiere que utilice todas las herramientas de la caja de herramientas, sino que utilice una herramienta a la vez. Por poner otro ejemplo, es posible que prefiera determinadas herramientas y, de la misma manera, es posible que prefiera un modelo determinado. ¿Cuántos artefactos de modelado hay disponibles? Si desea obtener más detalles sobre esto, he enumerado las partes relevantes de UML en Sea realista sobre UML. Si desea obtener más información, puede consultar el documento técnico. -- Introducción a las técnicas de modelado ágil.
Trabajo de calidad A nadie le gusta el mal trabajo. A las personas que hacen este trabajo no les gusta porque no hay sensación de logro; a las personas que son responsables de refactorizar este trabajo en el futuro (por alguna razón) no les gusta porque es difícil de entender y actualizar para los usuarios finales; No me gusta porque es demasiado frágil, propenso a errores y no cumple con sus expectativas.
Retroalimentación rápida El tiempo entre la toma de acción y la obtención de retroalimentación sobre la acción es crucial. Desarrolle modelos junto con otras personas y obtenga comentarios inmediatos sobre sus ideas, especialmente si trabaja con técnicas de modelado compartidas, como pizarras blancas, tarjetas CRC o materiales de modelado básicos, como notas adhesivas. Al trabajar estrechamente con sus clientes para comprender sus necesidades, analizarlas o desarrollar una interfaz de usuario que satisfaga sus necesidades, brinda la oportunidad de recibir comentarios rápidamente.
El software es su objetivo principal El objetivo principal del desarrollo de software es producir software que satisfaga las necesidades de las partes interesadas del proyecto de manera eficiente, en lugar de producir documentos irrelevantes, artefactos irrelevantes para la gestión o incluso modelos irrelevantes. . Cualquier actividad que no cumpla con este principio y no contribuya al logro de los objetivos debe ser revisada o incluso cancelada.
Mueve la luz. Construyes un artefacto y luego decides conservarlo. Con el tiempo, estos artefactos requieren mantenimiento.
Si decide mantener 7 modelos, cada vez que algo cambia (se proponen nuevos requisitos, se actualizan los requisitos originales, el equipo acepta un nuevo enfoque, adopta una nueva tecnología...), debe considerar el impacto de los cambios en estos 7 modelos. y tomar las medidas correspondientes. Y si solo quieres mantener 3 modelos, obviamente te llevará mucho menos esfuerzo implementar el mismo cambio, y tu flexibilidad mejorará porque avanzas con ligereza. De manera similar, cuanto más complejo y detallado sea su modelo, más probable será que los cambios sean más difíciles de implementar (cada modelo es "más pesado" y, por lo tanto, más complicado de mantener). Cada vez que decide conservar un modelo, debe sopesar qué tan beneficiosa es la información contenida en el modelo para el equipo (de ahí la necesidad de fortalecer la comunicación entre los equipos y entre los equipos y las partes interesadas del proyecto). Nunca subestimes la seriedad de las compensaciones. Si una persona quiere cruzar el desierto debe llevar un mapa, un sombrero, buenos zapatos y una botella de agua. Si hubiera traído cientos de galones de agua, todas las herramientas de supervivencia imaginables y una pila de libros sobre el desierto, ¿podría sobrevivir en el desierto? De la misma manera, si un equipo de desarrollo decide desarrollar y mantener un documento de requisitos detallado, un conjunto detallado de modelos de análisis, un conjunto de modelos de arquitectura detallados y un conjunto de modelos de diseño detallados, pronto se descubrió que la mayoría de su tiempo no se dedicó a escribir el código fuente, sino a actualizar la documentación.
Principios complementarios:
El contenido es más importante que la representación. Hay muchas formas de representar un modelo. Por ejemplo, puede crear una especificación de interfaz de usuario (prototipo básico/de baja precisión) colocando notas adhesivas en una hoja de papel. Puede representarse como un boceto en papel o una pizarra, como un prototipo tradicional construido utilizando herramientas de creación de prototipos o herramientas de programación, o como un documento formal que incluye una interfaz visual y una descripción textual. Es interesante observar que un modelo no es necesariamente un documento. A menudo se utilizan como entrada para otros artefactos, como el código fuente, pero no es necesario procesarlos en documentos formales, ni siquiera en diagramas complejos creados con herramientas CASE. Reconozca esto y aproveche los beneficios del modelado en lugar de gastar energía creando y manteniendo documentación.
Debe haber un maestro entre nosotros. No puedes dominar completamente una determinada tecnología. Siempre tienes la oportunidad de aprender nuevos conocimientos y ampliar tu campo de conocimiento. Aprovecha esta oportunidad para trabajar con otros, aprender de los demás, probar nuevas formas de hacer las cosas y pensar qué hacer y qué no hacer. La tecnología cambia muy rápidamente. Las tecnologías existentes (como Java) están mejorando a una velocidad increíble y también se producen nuevas tecnologías (como C# y .NET) con regularidad. La mejora de la tecnología de desarrollo existente será relativamente lenta, pero también está experimentando una mejora continua: la industria informática es una industria y hemos dominado los principios básicos de las pruebas, pero todavía investigamos, practicamos y mejoramos constantemente nuestra comprensión de él. Trabajamos en una industria donde el cambio es la norma y debemos aprovechar cada oportunidad para aprender nuevas formas de hacer las cosas a través de la capacitación, la educación, el pensamiento, la lectura y el trabajo con otros.
Comprenda sus modelos Debido a que utilizará varios modelos, debe comprender sus fortalezas y debilidades para poder utilizarlos de manera efectiva.
Conozca sus herramientas. El software (como herramientas de dibujo, herramientas de modelado) tiene varias características. Si vas a utilizar una herramienta de modelado, debes saber cuándo es apropiada y cuándo no usarla.
Ajuste local. Su método de desarrollo de software debe poder reflejar su entorno. Este entorno incluye las características de la organización, las características de las partes interesadas del proyecto y las características del proyecto en sí. Los problemas que pueden verse afectados por esto incluyen: las técnicas de modelado que utiliza (quizás sus usuarios insisten en ver una interfaz de usuario detallada en lugar de un boceto inicial o un prototipo básico); cámara) presupuesto, o ya tiene una licencia para una herramienta CASE); el proceso de software que sigue (su organización adopta el proceso de desarrollo de XP, o RUP, o su propio proceso).
Así podrás ajustar tu enfoque, ya sea específico del proyecto o personal. Por ejemplo, algunos desarrolladores tienden a utilizar cierto tipo de herramienta y otros no. Algunas personas ponen mucho esfuerzo en codificar y apenas modelan, mientras que otras prefieren invertir más tiempo en modelar.
Comunicación abierta y honesta. Las personas deben poder hacer sugerencias libremente y deben poder sentirse libres. Las sugerencias pueden ser ideas relacionadas con el modelo: tal vez alguien proponga un nuevo método de diseño para una determinada pieza, o una nueva comprensión de un determinado requisito, las sugerencias también pueden ser algunas malas noticias, como retrasos en el cronograma o simplemente un informe de estado del trabajo; . La comunicación abierta y honesta permite a las personas tomar mejores decisiones porque la información en la que se basan será más precisa.
Utiliza la intuición de las buenas personas. A veces sentirás que algo anda mal, que hay una inconsistencia o que algo simplemente no se siente del todo bien. De hecho, este sentimiento probablemente sea cierto. A medida que aumente su experiencia en el desarrollo de software, su intuición se volverá más aguda. Lo que su intuición le dice inconscientemente puede ser la clave de su trabajo. Si su instinto le dice que un requisito no tiene sentido, entonces no tiene que invertir mucha energía en discutirlo con los usuarios. Si su intuición le dice que parte de la arquitectura no satisface sus necesidades, necesita construir un prototipo técnico rápido para verificar su teoría. Si su intuición le dice que el método de diseño A es mejor que el método de diseño B, y no hay ninguna razón sólida que respalde su elección de un determinado método, entonces siga adelante y elija el método A. El valor del coraje ya te dice que si el futuro demuestra que tu intuición está equivocada, tú también tienes la capacidad de salvar la situación. Es importante que tengas esta confianza.