MTRICAS QUE SE UTILIZAN EN MTODOS GILES 1.

INTRODUCCIN Medir los proyectos es algo necesario, por eso, las organizaciones de software estn volteando cada vez ms, y en especial en este periodo de crisis global, a procesos giles que les permitan obtener resultados en sus proyectos que de una forma ms rpida y econmica sin sacrificar calidad. De manera interesante, esto se est logrando al mismo tiempo que se aumenta la motivacin de los equipos de desarrollo debido al uso de las prcticas recomendadas en dichos procesos. No por nada los procesos giles tienen un auge tremendo a nivel internacional. Desafortunadamente en los pases latinoamericanos el progreso no necesariamente se da al mismo ritmo que en otras naciones, y las opciones que tiene la industria para preparar formalmente a sus desarrolladores en dichas tcnicas son muy escasas. Las metodologas de desarrollo gil se basan fundamentalmente en la colaboracin con los usuarios de software durante todo el proceso de desarrollo, la facilidad para adaptar el producto a cambios en requerimientos y en la entrega incremental del producto. Basadas en el Manifiesto gil (se explica ms adelante), han sido aceptadas y son utilizadas con xito en proyectos donde los requerimientos detallados son inicialmente desconocidos y se van construyendo durante el proceso de desarrollo a partir de interacciones con los usuarios y de la retroalimentacin obtenida a partir de las mismas. Tradicionalmente, los procesos de desarrollo de software llevan asociado un marcado acento en el control del proceso. Definen actividades, artefactos y documentacin a producir, herramientas y notaciones a ser utilizadas, orden de ejecucin de las actividades, entre otras definiciones. Si bien existen varios procesos de desarrollo (ejemplo: Proceso Unificado), la mayora de estos procesos se derivan del Modelo de Cascada propuesto por Boehm. Estos procesos, denominados tradicionales, han demostrado ser efectivos en proyectos de gran tamao, particularmente en lo que respecta a la administracin de recursos a utilizar y a la planificacin de los tiempos de desarrollo. Sin embargo, el enfoque propuesto por estos mtodos no resulta el ms adecuado para el desarrollo de proyectos donde los requerimientos del sistema son muy cambiantes, donde se pide reducir drsticamente los tiempos de desarrollo y al mismo tiempo producir un producto de alta calidad. Como alternativa a los mtodos tradicionales de desarrollo, surgen las Metodologas giles. Manteniendo prcticas esenciales de las metodologas tradicionales, las metodologas giles se centran en otras dimensiones del proyecto, como por ejemplo: la colaboracin con los usuarios durante todas las etapas del proceso de desarrollo, y el desarrollo incremental del software con iteraciones muy cortas que entregan una solucin a medida. Las prcticas giles estn especialmente indicadas para productos cuya definicin detallada es difcil de obtener desde el comienzo, o que si se definiera, tendra menor valor que si el producto se construye con una retro-alimentacin continua durante el proceso de desarrollo. 2. METODOLOGAS GILES En una reunin celebrada en febrero de 2001 en Utah-EEUU, nace el trmino gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
1

tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. Varias de las denominadas metodologas giles ya estaban siendo utilizadas con xito en proyectos reales, pero les faltaba una mayor difusin y reconocimiento. Tras esta reunin se cre The Agile Alliance, una organizacin, sin fines de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto gil, un documento que resume la filosofa gil. 2.1. EL MANIFIESTO GIL El Manifiesto comienza enumerando los principales valores del desarrollo gil. Se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. Desarrollar software que funciona ms que conseguir una buena documentacin. La colaboracin con el cliente ms que la negociacin de un contrato. Responder a los cambios ms que seguir estrictamente un plan.

Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son las caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros son generales y resumen gran parte del espritu gil. 3. DIFERENCIAS ENTRE METODOLOGA GIL Y METODOLOGA TRADICIONAL A continuacin, se enumeran las principales diferencias entre las metodologas tradicionales y las giles. La siguiente tabla, recoge esquemticamente estas diferencias que no se refieren slo al proceso en s, sino tambin al contexto de equipo y organizacin que es ms favorable a cada uno de estas filosofas de procesos de desarrollo de software.

Aunque los creadores e impulsores de las metodologas giles ms populares han suscrito el manifiesto gil y coinciden con los principios enunciados anteriormente, cada metodologa tiene caractersticas propias y hace hincapi en algunos aspectos ms especficos. A continuacin se resumen algunas metodologas giles. 4. SCRUM SCRUM es una metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al mximo la productividad de un equipo. Reduce al mximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo (cada 30 das), por medio de iteraciones o Sprints. Ideal para proyectos con un rpido cambio de requerimientos.

4.1. CONTEXTO SCRUM Slo abarca prcticas de gestin sin entrar en las prcticas de desarrollo como puede hacer XP. Delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo ms productivos posibles y, le da gran protagonismo a las reuniones que realicen a lo largo del proyecto. Sus races tericas estn en las teoras de la auto-organizacin.

4.2. ACTORES SCRUM Equipo: Responsable de transformar el Backlog de la iteracin en un incremento de la funcionalidad del software. Scrum Master: Responsable del proceso Scrum.

4.3. METODOLOGA DE TRABAJO En la primera reunin se explica al equipo la forma de trabajo, especificando que son reuniones cortas para coordinar trabajo y no para solucionar problemas. Se establecen los criterios para arreglar los errores por prioridades (base del xito del sistema). Al inicio de cada iteracin se revisa el trabajo pendiente en el proyecto y se selecciona la parte a la cual se le incrementara funcionalidad, para al final de la iteracin incorporarla al SW y presentrsela a las partes involucradas. En cada reunin las preguntas claves a contestar son: Qu es lo que se hizo desde la ltima reunin? Qu es lo que se va a hacer hasta la siguiente reunin? Cmo se va a llevar a cabo? 4.4. ARTEFACTOS SCRUM Sprint Es la base del desarrollo Scrum. Su duracin mxima es de 30 das.
3

Se llevan a cabo las tareas pre-establecidas y no se puede modificar el trabajo acordado en el backlog. Slo el ScrumMaster puede abortar un sprint si lo considera no viable por alguna de las siguientes razones: Las circunstancias del negocio han cambiado. La tecnologa acordada no funciona. El equipo ha tenido interferencias.

Product Backlog Crea un listado con los requisitos de los usuarios o propietarios del sistema para planificar el proyecto. No es una lista completa y definitiva. Es slo una estimacin inicial de los requisitos. Es un documento dinmico que incorpora las constantes necesidades del sistema y se mantiene durante todo el ciclo de vida.

Sprint Backlog Especifica la serie de tareas que se van a desarrollar segn los requisitos sealados. Estas tareas tienen una duracin de entre 4 y 16 hrs. de trabajo. Las de mayor duracin intentar descomponerlas en Sub-Tareas dentro de ese rango de tiempo. Al final del sprint se busca un incremento en la funcionalidad.

5. XP PROGRAMACIN EXTREMA Es un proceso ligero, gil, de bajo riesgo, flexible, predecible, cientfico y divertido de desarrollar software. Est orientado hacia quien produce y usa el software (retroalimentacin continua cliente y desarrollador). Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema. Combina las que han demostrado ser las mejores prcticas para desarrollar software, y las lleva al extremo.

5.1. CONTEXTO SCRUM Cliente bien definido y en colaboracin constante. Los requisitos pueden y van a cambiar (voltiles). Reduce los tiempos de desarrollo manteniendo la calidad. Desarrollo incremental y continuo para responder a los cambios. Grupo pequeo y muy integrado.

5.2. CARACTERSTICAS XP Metodologa creada a base de prueba y error. nfasis en el desarrollo del software ms que una buena documentacin. Empieza en pequeo y aade funcionalidad con retroalimentacin continua.
4

No introduce funcionalidades antes de que sean necesarias. El cliente o el usuario se convierte en miembro del mismo equipo. Su utilidad es medida con cuatro valores: Simplicidad en las soluciones implementadas. Comunicacin. Retroalimentacin. Coraje (si funciona mejralo).

6. MTRICAS GILES Y CUADRO DE MANDOS INTEGRAL PARA SCRUM La mtrica ms importante en un proyecto gil como Scrum es el valor que se est dando al cliente. Mediante esta mtrica, el cliente puede conocer la velocidad con que retorna su inversin y saber cundo ya no es necesario seguir con el proyecto, por que los beneficios pendientes de obtener ya no compensan sus costos. Sin embargo, cuando se mide a una persona o a un equipo de una determinada manera, sus acciones pueden desviarse en exceso hacia ese objetivo y descuidar otros aspectos tambin importantes como, por ejemplo, la calidad, los costos, los riesgos, la sostenibilidad de la velocidad con que obtienen objetivos, etc. Por ello, puede ser necesario utilizar un conjunto de mtricas de diferentes aspectos relacionados, creando de esta manera un cuadro de mandos integral gil (agile balanced scorecard).

6.1. MTRICAS GILES DEL CUADRO DE MANDOS La mayora de las mtricas ms importantes derivan de las herramientas propias de Scrum (la lista de requisitos priorizada, la lista de tareas de la iteracin y los grficos de trabajo pendiente), por lo que el momento natural para actualizar este cuadro de mandos es tras la retrospectiva de la iteracin. Notar que en una gestin gil de proyectos carece de sentido utilizar algunas de las mtricas ms utilizadas en proyectos tradicionales o en cascada, como por ejemplo:

El porcentaje de completitud de un objetivo o requisito: en un proyecto gil, para poder determinar cundo se completa un requisito o entrega se utiliza concepto de esfuerzo pendiente. Los diagramas de Gantt: no aportan ms informacin que la que aportan las herramientas propias de Scrum.

Las mtricas de uso ms comn se muestran en negrita, las que no aparecen en negrita se muestran como ejemplos de mtricas que se pueden utilizar de manera ms temporal para analizar problemas concretos. Mtricas de productividad y efectividad de la entrega

Velocidad con que se completan objetivos/requisitos en cada iteracin (en funcin de su estimacin al inicio de la iteracin). Permite ir extrapolando la fecha de finalizacin del proyecto en funcin de cuando se vaya a completar todo su alcance. Tiempo de entrega de un requisito tras su peticin o Lead Time (responsividad a necesidades del cliente, Time to Market, tiempo de servicio), en funcin del tipo del tipo de requisito (urgente, etc.) y cumplimiento de los Acuerdos de Nivel de Servicio (ANS / SLA). Urgencias y prioridad/valor de los requisitos completados, para comprobar si existe desalineamiento con los objetivos del proyecto y/o la estrategia de la organizacin.

Mtricas de resultados del proyecto

Velocidad con que se aporta valor al negocio (desde el punto de vista del cliente). Valor acumulado. Requisitos completados en la iteracin. Prximos requisitos a desarrollar. Cambios y requisitos aadidos sobre el alcance del proyecto. Nmero de requisitos completados respecto al total de requisitos (mtrica que tambin permite observar cambios de alcance). Das de trabajo ideales pendientes (mtrica que permite proyectar la fecha de finalizacin del proyecto). Desviacin de resultados de proyecto respecto a planificacin inicial.

Mtricas de situacin financiera

Retorno de Inversin (ROI) pendiente, el valor pendiente respecto al coste pendiente, para saber cundo finalizar el proyecto. Presupuesto disponible y/o presupuesto gastado. Desviacin financiera respecto a la planificacin inicial.
6

Mtricas de calidad Expectativas:

Satisfaccin del cliente/usuario, respecto a los resultados del proyecto y a la colaboracin con el equipo. Ambiente en el equipo

Calidad funcional:

Incidencias (defectos encontrados por el cliente o usuarios del producto), por estado y por criticidad. Errores (defectos detectados internamente, bugs), por estado y por criticidad. Cobertura de las pruebas. Trazabilidad.

Mantenibilidad:

Cumplimiento de estndares de codificacin, normativas, regulaciones, etc. Comentarios en el cdigo. Complejidad ciclomtica del producto. Tamao de las operaciones. Calidad de la documentacin (existencia y cobertura de la documentacin funcional, tcnica, de pruebas, de implantacin, operativa, etc.).

Mtricas de riesgos, impedimentos, proceso y mejora continua

Riesgos (severidad y mitigaciones) e impedimentos: considerando las dependencias o sinergias con otros equipos o proyectos, la implicacin del cliente, los problemas tecnolgicos, el resultado de las retrospectivas, etc. Lecciones aprendidas. Actividades de mejora a planificar (comunicaciones, formaciones, soporte, herramientas, etc.). Uso de prcticas especficas: nmero de integraciones, tiempo de refactorizacin, de TDD, revisiones expertas, etc. Situaciones anmalas: sobreesfuerzo, requisitos no completados, terminaciones anormales de iteracin, interrupciones, sospechas de mala aplicacin del proceso (por ejemplo, si el cliente se muestra sorprendido en la demostracin de la iteracin), etc. Porcentaje de personas que no intervienen en las reuniones diarias de sincronizacin.

Conclusiones sobre el estado del proyecto Este apartado debe contener un resumen con las mtricas ms importantes y las relaciones entre ellas, as como las lecciones aprendidas y prximas acciones de mejora (tras un anlisis causal de problemas como, por ejemplo, el que se realiza en una retrospectiva), de manera que el cliente pueda tomar decisiones informadas y dirigir los resultados del proyecto. 7. MTRICAS BSICAS EN UN PROYECTO GIL

Se debe tener slo las mtricas realmente necesarias, dado el costo que implica tanto recoger como interpretar cualquier mtrica. Cuando se recoge una mtrica, las personas intentan quedar bien respecto a esa mtrica. Por ello, es conveniente disponer de un conjunto de mtricas balanceadas que detecten si se est obteniendo unos resultados a costa de otros. Por ejemplo, puede ser que la productividad est aumentando pero a expensas de un descenso de calidad. Notar que las mtricas tambin permiten tener una proactividad y detectar un posible problema antes de que se manifieste completamente. Las mtricas giles ms importantes son: o El valor que se va entregando el cliente (Product Owner), que permite saber: Si el proyecto est cumpliendo con las expectativas del cliente (un objetivo no aprobado tiene valor 0). Cuando ya no es interesante seguir con el proyecto. o La velocidad de desarrollo del equipo, que permite: Extrapolar la fecha de finalizacin del proyecto y/o saber de qu objetivos/requisitos se dispondr en una fecha determinada. Planificar un nuevo proyecto a partir de la historia anterior. Medir le aprendizaje del equipo, ya que es una mtrica que debera aumentar con el tiempo. o Mtricas de calidad como el nmero de defectos.

8. REFERENCIAS: http://www.proyectosagiles.org/ http://www.egov.iist.unu.edu/.../Un+Framework+para+Evaluacion+de+Metodologias+Agiles.pdf http://www.e-market.cl/dir/.../GRUPO_1_PROGRAMACION_AGIL.ppt http://www.willydev.net/descargas/masyxp.pdf - Metodologas giles para el desarrollo de software: eXtreme Programming (XP)