Business Intelligence Latin America

Inteligencia de Negocios en Español

Metodologías Agiles
Introducción
Una metodología Ágil es una metodología efectiva par a modelar y documentar un proyecto de software, es una colección de valores principios y practicas para modelar software que puede ser aplicados de manera simple y ligera.
La metodología Agil tiene varios principios que la diferencian sobre las metodologías tradicionales reflejados en un Manifiesto que enuncia cuatro valores que son :
1. Los individuos y sus relaciones sobre las personas y los procesos .- con este principio se hace manifiesto el énfasis de esta metodología sobre las personas , ya que ellas son de las que depende el éxito o el fracaso de un proyecto, es a las que se les debe motivar
2. Un Software funcional, que trabaje sobre la documentación mas completa .- con este principio se trata de decir que lo mas importante es que el software trabaje , cumpla con las necesidades de negocio, no hacer de la documentación un fin en si mismo, ya que esta es solo para dar soporte , no es el objetivo primario del desarrollo, existen situaciones en donde incluso la documentación podría ser innecesaria, por ejemplo una pequeña aplicación emergente, que una vez pasada la emergencia , esta aplicación desaparece, el cargar de documentación de requerimientos, arquitectura , testeo etc. Podría considerarse de sobra, sin embargo eso no quiere decir que no es necesaria la documentación, esta debe existir pero solo la suficiente
3. Colaboración el cliente sobre el contrato de negocio .- Se trata de colaborar con el cliente el mayor tiempo no de luchar con el sobre un contracto minucioso , esto puede ser difícil ya que los clientes no están acostumbrados, ellos están acostumbrados a trabajar sobre un contrato con el que puedan defenderse si las cosas van mal
4. Ser capaz de responder a los cambios y no obsesionarse sobre el seguimiento de un plan .-Es tener la capacidad de adaptación, no decir NO A LOS CAMBIOS, aceptar las sugerencias de los usuarios, sin por eso hacer un lado la planificación
Estos valores han dado lugar a doce principios que son :
1. La satisfacción del cliente
2. Bienvenida a los cambios que puedan ocurrir
3. Entregar regularmente software que trabaje
4. Gente de negocios y desarrolladores trabajan diariamente en conjunto
5. Construcción de proyectos alrededor de individuos motivados para esto
6. Las comunicaciones cara a cara son las mejores
7. Software que trabaje es la mejor medida del progreso
8. Atención continua a la excelencia y al buen diseño
9. Promover el desarrollo sostenible
10. Simplicidad
11. Las mejores arquitecturas, requerimientos , y diseños emergen de equipos auto-organizados
12. Introspección , los equipos deben regularmente hacerse una revisión hacia si mismos y sus procesos para intentar mejorar
Modelado Agil
En el modelado Agil se trata de hallar el equilibrio ente exceso de modelado y carencia de este, se intenta que el modelado no se convierta en una carga, que sea suficiente para documentar el sistema, se pueden aprovechar el modelado de un proyecto RUP , esto es la documentación UML, se intenta promover procesos ligeros.
Con la modelación Agil se siguen tres objetivos que son:
• Promover y definir un grupo de valores, practicas y principios que ayudan a producir los modelos adecuados
• Orientación de cómo aplicar el modelado de proyectos agiles
• Orientación de cómo aplicar el modelado Agil a otro tipo de procesos o metodologías (por ejemplo RUP)
Criterios para un meldado Agil
Un modelado Agil debe seguir estos criterios :
• Deben dar valor positivo, deben servir realmente de ayuda para dar un software funcional
• Deben solo cumplir su propósito y no mas , esto es dar a entenderse solo con los suficiente, no usar herramientas pesadas, por ejemplo las ofrecidas por Rational Rose, no ser tan estricto
• Debe ser comprensible para su audiencia, no para todos, el nivel de detalle debe ser comprensible de acuerdo a la audiencia a la que se le presente
• Deben ser lo suficientemente precisos
• Deben ser lo suficientemente consistentes , modelos mas detallados que otros pueden causar confusión a las audiencias a las que van dirigidos.
• Deben ser lo suficientemente detallados, muchos detalles pueden ser irrelevante de acuerdo a quien se dirige el modelo.
• Tan simples como sea posible.
La documentación de las metodologías agiles debe ser tan simple como sea posible y de acuerdo a la audiencia a la que vaya dirigida, no es un modelado tan prescriptivo, no da recetas de diseño, no crea documentación innecesaria, se puede usar cualquier tipo de diseño o documentación que nos ayude, puede haber procesos que sea difícil capturarlos con los diagramas conocidos, pero si otros, una metodología Agil podría asociarlos.
Ejemplos de metodologías consideradas Agil son
• Programación Extrema
• Scrum
• MSF 4.0 Microsoft
• RAD *
• Cristal
• RUP Agil
• Otras ..

En este documento hablaremos de las primeras cuatro metodologías, estas metodologías pueden combinarse , por ejemplo Programación Extrema y Scrum , RAD puede integrarse con otras etc.
Aspectos de las Metodologias Agiles
Requisitos para poder utilizar Scrum
Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de proyectos como Scrum:
• Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continua.
• Compromiso del cliente .- Scrum exige del cliente una alta implicación y una dedicación regular:.
• Compromiso de la Dirección de la organización para resolver problemas endémicos y realizar cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación.
• Compromiso conjunto y colaboración de los miembros del equipo.
• Relación entre proveedor y cliente .- las dos partes asumen que habrá cambios para que el cliente obtenga lo que realmente necesita, no lo que está escrito en un documento
• Facilidad para realizar cambios en el proyecto. Para poder utilizar Scrum se debe poder ir incorporando requisitos de manera incremental en el producto del proyecto
• Tamaño de cada equipo entre 5 y 9 personas (con técnicas de colaboración entre equipos que trabajan en el mismo proyecto).
• Equipo trabajando en un mismo espacio común para maximizar la comunicación.
• Dedicación del equipo a tiempo completo.
• Estabilidad de los miembros del equipo

Herramientas documentales - Historias de Usuario
En la programación XP, suele utilizarse algo similar a lo utilizado en la Metodologia RUP, esto es los casos de uso, pero en esta Metodologia, el concepto cambia, ya no es un formato preciso, es mas anecdótico, se trata de referir la manera en que los usuarios pueden usar el sistema, las historias de usuario son escritas para los usuarios no para el equipo de desarrollo
Las historias de Usuario no son requerimientos detallados, pueden obtenerse durante las iteraciones, como una experiencia de uso del sistema resultado de una iteracion, deben usar la terminología del usuario , un lenguaje de negocios , no la de un desarrollador, deben ser cortas un ejemplo ser algo tan simple como esto que refleja esta Story Card (que es donde se pueden apuntar aspectos de historias de usuario) y dice :
Un usuario puede mandar su resumen a través de una pagina Web
Mas importante que una Story Card, que es la parte visible de la historia, son las conversaciones entre clientes y desarrolladores
Una Historia de Usuario describe una funcionalidad, un propósito de un sistema o software, son tradicionalmente escritas a mano y se componen de tres aspectos
1. Uno que describa la historia y como planeación y recordatorio
2. Conversaciones que puedan servir para reflejar detalles de la historia
3. Test que puedan documentar cuando una historia ha sido completada
Puede tenerse un proyecto inicial de historias pero pueden surgir otras durante todo el proyecto, pueden apilarse historias cortas durante una iteración para su atención, pueden priorizarse en pilas para su desarrollo en cada iteración

Visitas: 234

Comentar

¡Necesitas ser un miembro de Business Intelligence Latin America para añadir comentarios!

Participar en Business Intelligence Latin America

© 2012   Creado por Eliezer Cavazos.   Tecnología de .

Emblemas  |  Reportar un problema  |  Términos de servicio