Los valores del desarrollo ágil
Los valores del Modelado Ágil (AM) incluyen los cuatro valores de XP (Extreme Programming: Programación Extrema): comunicación, sencillez, retroalimentación, valentía, y además amplía el quinto valor: humildad.
El desarrollo ágil es un nuevo modelo de desarrollo que surge de las deficiencias del modelo de desarrollo en cascada tradicional. El objetivo es mejorar la eficiencia y la capacidad de respuesta del desarrollo. Además de los principios y las prácticas, los patrones también son muy importantes. Estudiar los patrones y sus aplicaciones puede brindarle una comprensión más profunda del desarrollo ágil. ◆Defiende la simplicidad
Cuando trabajas en desarrollo, debes argumentar 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 que tienen las personas de 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 - - Implementar las necesidades de las partes interesadas del proyecto, incluido su sistema debe ser lo suficientemente robusto como para adaptarse a una 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 tener 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 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
Para sus propios artefactos, como modelos, código fuente y documentos, muchos desarrolladores se preocupan por si son lo suficientemente detallados o demasiado detallados. sobre si son lo suficientemente correctos. 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é necesitamos para desarrollar las aplicaciones comerciales actuales? " ¿Que tipo de modelo? "Dada la complejidad del software actual, su caja de herramientas de modelado debe incluir una gran cantidad de tecnicas utiles (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 un 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.
◆Comentarios rápidos
El tiempo entre la acción y la recepción de comentarios 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 efectiva, en lugar de producir documentos irrelevantes y documentos irrelevantes. Artefactos para la gestión, incluso modelos no relacionados. Cualquier actividad que no cumpla con este principio y no contribuya al logro de los objetivos debe ser revisada o incluso cancelada.
◆Mover luz
Construyes un artefacto y luego decides conservarlo. A medida que pasa el tiempo, estos artefactos necesitan 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. Lo más importante es satisfacer las necesidades de los clientes mediante la entrega temprana y continua de software valioso.
Agradecemos los cambios en los requisitos, incluso en las últimas etapas del desarrollo. Los procesos ágiles gestionan el cambio y mantienen la ventaja competitiva de los clientes.
Entregue software que funcione con frecuencia, desde semanas hasta meses, cuanto más breve, mejor.
Los empresarios y los desarrolladores deben trabajar juntos día y noche durante todo el proyecto.
Realizar el desarrollo de software alrededor de personas motivadas, proporcionar a los desarrolladores un entorno adecuado, satisfacer sus necesidades y confiar en ellos para completar la tarea.
La forma más eficiente y eficaz de transmitir información en un equipo de desarrollo es la conversación cara a cara.
El software que funciona es la principal medida del progreso.
Los procesos ágiles promueven el desarrollo sostenible. Los financiadores, desarrolladores y usuarios siempre deben mantener una cadencia constante.
La búsqueda continua de la excelencia técnica y el buen diseño ayudará a aumentar la agilidad.
Simplicidad – El arte de minimizar el trabajo es esencial.
La mejor arquitectura, requisitos y diseños surgen de equipos autoorganizados.
A intervalos regulares, el equipo revisará cómo ser más eficiente y luego ajustará su comportamiento en consecuencia.