Capítulo 4. Subproceso de Gestión
Anuncio
Índice de contenido 4. Caracterización del Subproceso de Gestión del Proyecto......................................................................2 4.1. Descripción de la Actividades del procedimiento “ Gestión del Proyecto”.......................................4 4.2. Guias...................................................................................................................................................8 4.2.1. Organización del Equipo de Trabajo................................................................................................8 4.2.2. Autogestión en el equipo de trabajo.................................................................................................9 4.2.3. Elaboración del Plan General del Proyecto....................................................................................10 Propósito.........................................................................................................................................10 Pasos...............................................................................................................................................11 Lista de Verificación.......................................................................................................................12 4.2.4. Elaboración del Plan de Iteración..................................................................................................12 Propósito.........................................................................................................................................12 Pasos ..............................................................................................................................................13 Lista de Verificación ......................................................................................................................14 4.2.5. Elaboración de Lista de Unidades de Trabajo................................................................................15 Propositos.......................................................................................................................................15 Opciones de Representación...........................................................................................................15 Lista de verificación ......................................................................................................................15 4.2.6. Reuniones diarias ..........................................................................................................................16 4.2.7. Estimación ágil...............................................................................................................................17 4.2.8. Gestionar la iteración.....................................................................................................................19 Proposito.........................................................................................................................................19 Pasos...............................................................................................................................................20 4.2.9. Evaluar los resultados obtenidos de la Iteración ...........................................................................21 Propósito.........................................................................................................................................21 Pasos...............................................................................................................................................21 4.2.10. Gestionar posibles cambios en una iteración ..............................................................................22 4.2.11. Manejo de la Retrospectiva .........................................................................................................22 1 4. Caracterización del Subproceso de Gestión del Proyecto 2 Capitulo 4: Subproceso – Gestión del Proyecto 3 Capitulo 4: Subproceso – Gestión del Proyecto 4.1. Descripción de la Actividades del procedimiento “ Gestión del Proyecto” Nombre de la Actividad Descripción Responsables Artefactos Relacionados (Procductos) 1. Definición de roles y respon­ Para desarrollor cualquier proyecto es in­ Líder del Proyecto sabilidades del equipo de tra­ despensable definir los roles y responsa­ bilidades requeridos por el proyecto, el lí­ bajo. der del proyecto conforma el equipo to­ mando en cuenta las necesidades del pro­ 2. Conformación del equipo de yecto, las competencias, experiencia e in­ trabajo tereses de los posibles aspirantes. 3. Preparar el ambiente de tra­ bajo (Marco de desarrollo e in­ fraestructura) Cuando se inicia un proyecto de software Equipo de Desarrollo se debe contar con la infraestrura tecnolo­ gica apropiada, para ello el equipo de tra­ bajo debe instalar y configurar el entorno de desarrollo adecuado. Además esta acti­ vidad debe ir de la mano con la gestión del proceso de desarrollo que guia el mar­ co de trabajo del proyecto. 4. Planificación general del proyecto (Plan General del Proyecto) Con base en las necesidades y requeri­ Líder del Proyecto mientos de los interesados y las directri­ ces organizacionales, el lider del proyecto inicia la elaboración del documento Plan General que contiene los lineamientos que guiran el que, como, con que y para que del proyecto. Es importante anotar que este documento debe ser comunicado y avalado por los interesados. 4 Guías ­Organización del equipo de trabajo ­Autogestión del equipo de desarrollo. Plan General del Pro­ yecto ­ Elaboración del Plan General del Proyecto Capitulo 4: Subproceso – Gestión del Proyecto 5. Definición de criterios de seguimiento y control para de­ sarrollar el Plan General del Proyecto Para llevar un control juicioso de los objeti­ Líder del Proyecto vos y metas trazadas en el proyecto se de­ berá definir criterios de seguimiento y con­ trol que permitan medir su efeciencia y efi­ cacia . 6. Iniciar fase del proyecto Una vez se defina en el plan general del Equipo de Desarrollo proyecto las fases, hitos y actividades a largo plazo con sus respectivas fechas y objetivos se procederá a iniciar y dar cumplimiento a la fase que corresponda del proceso y del proyecto. 7. Definir plan de iteración Las fases estan constituidas por iteració­ Equipo de Desarrollo nes, las cuales deben ser planificadas por parte del equipo de desarrollo y consolida­ das en el documento “ Plan de Iteración”, este artefacto contienen los hitos, activida­ des y objetivos a mediano plazo , defini­ dos en un periodo de tiempo con una fe­ cha inicial y final, Al igual que en el Plan General del Pro­ Líder del Proyecto 8. Definir criterios de segui­ miento y control del plan de Ite­ yecto, el Plan de Iteración debe tambien ser controlado a traves de criterios o pun­ ración tos de control, que permitan asegurar el cumplimiento de los objetivos trazados. 5 Plan General del Pro­ yecto Plan de Iteración Plan de Iteración ­Elaboración del Plan de Iteración ­Estimación ágil ­Gestionar Plan de Iteración Capitulo 4: Subproceso – Gestión del Proyecto 9. Definir lista de unidades de trabajo diario para desarrollar plan de Iteración Tomando en cuenta la fase en la que se Equipo de Desarrollo encuentra el proyecto, el Plan General y el Plan de Iteración vigente, cada uno de los miembros del equipo de trabajo, deberá elaborar diariamente una lista de unidades de trabajo que permita dar cumplimiento a corto plazo de los objetvos y actividades trazadas a mediano y largo plazo. Listas de Unidades de ­Elaboración de lis­ Trabajo tas de unidades de trabajo. ­Estimación ágil 10. Hacer seguimiento de listas Diariamente el Ingeniero de Proceso y el ­Ingeniero de Proceso Lider del proyecto desarrollaran reuniones ­ Líder del Proyecto de unidades de trabajo a dia­ cortas (Max 20 min.) con el equipo de tra­ rio. bajo con el objetivo de avaluar el grado de cumplimiento de las actividades a corto plazo planificadas y asi definir y ejecutar acciones de mejora cuando sea necesario. ­ Reuniones diarias Una vez finalice la Iteración presupuesta­ Ingeniero de Proceso da con la fecha de finalización prevista, el equipo de desarrrollo y el ingeniero de 12. Revisar criterios de evalua­ proceso, deberán evaluar el cumplimiento Líder del Proyecto de los objetivos y actividades planificadas ción de plan de Iteración en el Plan de Iteración y registrar los resul­ 13. Revisar criterios de evalua­ tados en el documento “ Cierre de Itera­ Ingeniero de Proceso Líder del Proyecto ción de Plan General del pro­ ción”. yecto Se desarrollará una sesión de trabajo que Jefe de Proyecto permita veficar y medir los criterios de eva­ 14. Verificación de cumplimien­ luación definidos en el Plan de Iteración y Ingeniero de Proceso a su vez en el Plan General del Proyecto. Líder del Proyecto to de criterios de evaluación Jefe de Proyecto del plan de iteración 11. Cerrar plan de Iteración 6 Cierre de Iteración ­Evaluar los resulta­ dos de la iteración. Capitulo 4: Subproceso – Gestión del Proyecto 15. Verificación de cumplimien­ to de criterios de evaluación del Plan General del Proyecto Ingeniero de Proceso Líder del Proyecto Jefe de Proyecto Director del Proyecto 16. Refinar la planificación del Tomando encuenta los resultados de los Lider del Proyecto cierres de iteración y las condiciones ac­ proyecto tuales del proyecto , el lider del proyecto refinara el documento del “ Plan General del Proyecto” de tal manera que se en consideración los principios fundamenta­ les del proceso de desarrrollo openup que obedecen a un proceso iterativo en incre­ mental. 17. Socializar avances del pro­ yecto a los interesados A medida que se ejecutan las actividades ­Equipo de Desarrollo planificadas a largo, mediano y corto pla­ zo, es necesario que los interesados co­ nozcan gradualmente los resultados y avances del proyecto de tal manera que sean participes de la solución y mejora del mismo. 18. Finalizar fase del proyecto Con base en los objetivos propios de cada ­Líder del Proyecto una de las fases del proceso desarrrollo cuando corresponda openup/oas y el cumplimiento de las me­ tas trazadas a corto, mediano y largo pla­ ­Líder del Proyecto 19. Finalizar proyecto cuando zo por el equipo de desarrollo con respec­ ­Jefe de Proyecto corresponda to al proyecto, se evaluara la pertinencia ­Director del Proyecto de pasar de una fase a otra, y se repetira el mismo procedimiento definido anterior­ mente por fase, hasta que se termine el proyecto. 7 Plan General del Pro­ yecto Manejo de la Retros­ pectiva 4.2. Guias 4.2.1. Organización del Equipo de Trabajo Esta guía pretende orientar como se organiza un equipo de trabajo al interior de un proyecto de desarrollo de software. Para obtener un buen desarrollo de software se requiere de un equipo constituido por un conjunto de personas que colaboren de manera eficaz. Cómo se conforme el equipo dependerá la productividad del proyecto. Cuando se conforme un equipo de trabajo para un proyecto de software, considere los siguientes consejos: 1. Incluya personas que compartan la visión y cultura actual del equipo de desarrollo. Los buenos equipos no aparecen por arte de magia en un día, sino que se cultivan y alimentan a través del tiempo, invitando a la gente que aportará un valor agregado al equipo y, además, que no le serán perjudiciales. Del mismo modo, es posible que tenga que invitar a alguien a dejar el equipo si no se ajustan bien dentro de él y no demuestran ser capaces de cambiar. 2. Convoque personas que crean en el proyecto. Las personas son mucho más productivas cuando están trabajando en un proyecto en el que creen y quieren ver triunfar. 3. Construya su equipo con “especialistas generalizados”. Este especialista es la persona que cuenta con una o más especialidades técnicas, y que trata activamente de obtener nuevas habilidades tanto en su especialidad como en otras áreas, incluyendo áreas de dominio y técnicas. Estos especialistas le añaden valor al equipo porque tienen los conocimientos especializados que este necesita, al tiempo que aprecian el rango completo de los hechos que un proceso de desarrollo de software y un dominio de negocios ofrecen. 4. Incluya a los interesados. Las partes interesadas tales como los interesados en el negocio, usuarios finales y técnicos como el grupo de operación, añaden un significativo valor a su equipo. En lugar de simplemente entrevistarlos para obtener información de ellos, o pedirles que revisen su trabajo, ¿por qué no los incluyen como participantes activos en el equipo? 5. Incluya especialistas a corto plazo para trabajos específicos. Los especialistas pueden agregar valor a un equipo de desarrollo ágil, especialmente cuando tienen conocimientos específicos y experiencia que los miembros del equipo no tienen. A menudo puede ser más eficaz que un especialista en el equipo este durante un corto período de tiempo para ayudar con una tarea específica, como la instalación y configuración de un servidor de aplicaciones o simplemente participar en una evaluación interna. 8 6. Bríndele a las personas oportunidades para desarrollar sus habilidades. Al comienzo de un proyecto, el equipo puede no tener toda las habilidades que necesita, o quizás unos pocos integrantes pueden no tener las competencias necesarias para cumplir las funciones que se están requiriendo. Este es uno de los riesgos mas comunes asumidos por la mayoría de los equipos en un proyecto, por el simple motivo que a menudo no se puede encontrar la combinación perfecta de las personas que van constituir el equipo de trabajo, aún a pesar de ofrecer oportunidades de crecimiento profesional. 4.2.2. Autogestión en el equipo de trabajo Un desarrollo de software ágil depende en gran medida de como este organizado el equipo de trabajo. La "Autonomía o Autogestión del equipo" implica que sus miembros tienen la autoridad para definir la manera más apropiada y pertinente para asumir la responsabilidad del trabajo que van a desarrollar. Algunos aspectos importantes de la auto organización de un equipo son: 1. El equipo define sus propias metas. Al comienzo de la iteración el equipo colectivamente selecciona los Temas de Trabajo y de la Lista de Unidades de Trabajo priorizada, tomando en cuenta sus limitaciones, las prioridades establecidas por las partes interesadas, la duración prevista de la iteración, el presupuesto y las habilidades de los miembros del equipo. 2. Los miembros del equipo están facultados para elegir su propio trabajo. Se asume que si un miembro del equipo se encuentra desarrollando un rol especifico dentro del proyecto, es porque es bueno y hace su trabajo de manera eficaz, porque quiere ganar más experiencia en lo que hace y espera mejorar sus habilidades mediante el trabajo en equipo. Aunque una persona cumpla con una o más funciones dentro de un proyecto, esto no implica que este obligada a hacer sólo determinados tipos de trabajo. 3. El equipo determina la forma de realizar el trabajo. Al comienzo de una iteración el equipo llevará a cabo reuniones de planificación donde se determina la estrategia general y las tareas necesarias para cumplir con las metas. Tenga en cuenta que el equipo está limitado por las normas de su organización, infraestructura técnica y los reglamentos, entre otras cosas. 4. Cada miembro del equipo se compromete. El equipo se compromete A la ejecución de las actividades que se han acordado para finalizar la iteración. Aunque algunas de ellas, en la medida que avanza la iteración, podrían ser replanteadas si fuese necesario. 5. Autocontrol permanente por parte del equipo de trabajo. Para garantizar que el trabajo presupuestado se lleva a cabo, el equipo debe coordinar sus esfuerzos de manera eficaz, para ello se suelen hacer reuniones diarias o conversaciones improvisadas entre los miembros del equipo. Se trata de crear un ambiente participativo que permita la buena toma de decisiones, donde todos tengan la oportunidad de aportar ideas, se potencialice el equipo, obtengan la responsabilidad y autoridad para realizar el trabajo y, en consecuencia, mejore la motivación entre los miembros del equipo y su productividad. 9 El Lider del proyecto debe: 1. Mediar desacuerdos. El líder debe estar preparado para intervenir y tomar una decisión cuando entre los otros miembros del equipo no es posible llegar a ella. 2. Asegurarse que las habilidades de los miembros del equipo crezcan en conjunto. De vez en cuando el líder del proyecto debe motivar a los miembros del equipo para asumir nuevas tareas que están fuera de su zona de confort o a trabajar con otros para ayudarles a adquirir nuevas competencias. 3. Asegurarse que el equipo sea consiente de sus límites y restricciones. Las decisiones que toma el equipo están en el ámbito de su responsabilidad, eso no significa que no deban tener en cuenta directrices institucionales. Por ejemplo, el equipo de desarrollo debe ajustarse a la infraestructura técnica y a las estrategias y políticas de su organización. Cuando un tema está fuera de su ámbito de responsabilidad el equipo debe aceptarlo o colaborar con las otras partes interesadas. 4. Dar cuenta a los directivos de la gestión desarrollada. Otras partes interesadas, tales como los altos directivos o jefes de dependencia, no participan activamente con el equipo, pero pueden querer saber el estado actual del proyecto. El líder del proyecto contribuye a resumir y comunicar esta información oportunamente. Esto es lo que no es: El concepto de autocontrol en los equipos a menudo suena como anarquía y no como la gestión tradicional en proyectos de Tecnología de la Información, pero nada podría estar más lejos de la verdad, aunque se basa en la autogestión de los miembros responsables del equipo y madura con la guía de un buen líder del proyecto. También es moderado por las normas de la organización, la infraestructura y las reglamentaciones externas, lo que no significa que usted tiene total libertad para hacer lo que desee. La Autogestión no es necesariamente un enfoque basado en el consenso, o bien a veces las personas aceptan una decisión, o bien eligen de acuerdo con la voluntad del equipo. 4.2.3. Elaboración del Plan General del Proyecto Propósito Esta actividad bosqueja los acuerdos iniciales de cómo se obtendrá en el tiempo el producto de software que se define en el documento Visión. Provee una descripción del proyecto en un resumen ejecutivo. El propósito es obtener autorización por parte de los interesados para iniciar el proyecto y obtener un compromiso del equipo en cuanto al desarrollo del mismo. Este plan puede ser actualizado a través del avance del proyecto basado en la retroalimentación por parte de los usuarios o los cambios que se van presentando en el desarrollo de la aplicación. 10 Al desarrollar el plan general del proyecto se tiene una oportunidad para que el equipo de trabajo llegue a acuerdos en cuanto al ámbito, objetivos, duración y entregables del proyecto. Permite que el equipo demuestre capacidad de auto­organización al definir los criterios de éxito y el proceso de desarrollo que va a ser utilizado. La colaboración y el consenso entre todos los participantes claves del proyecto es lo que se persigue al hacer el plan, sin embargo, el líder del proyecto tiene la responsabilidad de que todos estén de acuerdo con el plan. Este artefacto reúne toda la información requerida para administrar el proyecto. Su componente principal consiste en un plan de grano grueso que contiene las fases del proyecto y los hitos. El propósito del Plan General del Proyecto es proveer un documento central donde cualquier integrante del equipo del proyecto pueda encontrar información acerca de como el proyecto debe ser administrado. El responsable de desarrollar el plan de proyecto es el líder del proyecto, trabajando de forma muy cercana con los demás integrantes del equipo. El plan de proyecto permite a los interesados y otros integrantes del equipo obtener una visión general y aproximada de que se espera y a que nivel de funcionalidad. También se utiliza para registrar las diferentes experiencias aprendidas a lo largo del desarrollo del proyecto. Pasos Una vez se tenga conformado el equipo de trabajo, el lider del proyecto puede desarrollar las siguientes tareas: a. Determinar el plazo y alcance del proyecto Se hacen estimaciones del tiempo aproximado que se requiere para cubrir los objetivos de alto nivel del proyecto, tomando en cuenta las necesidades plasmadas en la Visión, luego éstas se debaten y priorizan con las partes interesadas, tomando en cuenta las limitaciones del proyecto. Si el proyecto se impulsa por los objetivos que se deben cumplir, el equipo deberá definir la cantidad de personas necesarias para realizar estos trabajos, lo que le permite ganar así un alto nivel de comprensión de la duración del proyecto, del perfil de los integrantes del equipo y su alcance. Si el proyecta gira entorno al tiempo, el equipo evalúa los resultados que se pueden obtener en el plazo dado y con el equipo disponible. b .Evaluar los riesgos El equipo identifica los riesgos del proyecto, realiza un análisis cualitativo del riesgo a fin de evaluar su magnitud y actualiza el Artefacto: Plan de Riesgos. El líder del proyecto toma la decisión sobre los riesgos a los que se debe responder y estar atentos. 11 Las respuestas o tratamientos pueden incluir evitar o mitigar los riesgos, explorar las oportunidades para incrementar la probabilidad y el impacto positivo de la situación de riesgo. Según el caso, se deben agregar o eliminar unidades de trabajo para asegurarse que se de respuesta oportuna a los riesgos, dándoles una prioridad y administrándolos con el equipo y el trabajo del proyecto. Como no es posible planificar las respuestas de todos los riesgos identificados, el equipo puede decidir aceptar algunos de ellos. Los Riesgos que están en vigilancia serán comunicados a las partes interesadas y debe permanecer en la lista de riesgos. c. Estructurar el ciclo de vida del proyecto La lista de unidades de trabajo que se defina en cada iteración se establecerá de acuerdo a la agilidad del equipo y las estimaciones para cada tema . De acuerdo a los productos de trabajo, el equipo define las características que se deben aplicar en cada iteración, tomando como prioridades las listas de trabajo mas importantes e incluyendo las medidas de control y mitigación a los mayores riesgos y oportunidades. Las iteraciones del proceso OPENUP/OAS se organizan en una serie de fases. Cada fase en el ciclo de vida del proyecto termina en un hito destinado a proporcionar a los interesados seguimiento y control de los recursos destinados al proyecto, el alcance, el manejo de los riesgos identificados y otros aspectos del proceso de desarrollo (Véase el concepto: Ciclo de vida del proyecto). No se necesita pasar demasiado tiempo planificando, el plan del proyecto debe documentar sólo un breve resumen de los hitos del proyecto, uno o tres objetivos por cada iteración y no deben tener en cuenta tareas de bajo nivel como listas de unidades de trabajo, ya que esto obliga a crear demasiada planificación innecesaria. El objetivo es crear un plan de alto nivel que expondrá cómo el equipo puede construir la aplicación en un conjunto dado de repeticiones. El nivel de detalle adicional se logrará en otras sesiones de planificación a lo largo del proyecto, , ya que es posible que se tenga que volver al plan de iteración anterior y adaptarlo. d. Proyectar y evaluar los costos del proyecto Desarrollar una idea aproximada del costo asociado a los recursos necesarios para desarrollar los objetivos del proyecto. A través de simplificar el modelo al multiplicar el costo aproximado del recurso humano requerido durante una iteración y calcular el impacto financiero en curso, es decir, estimando el costo por iteración. Esta primera ronda de planificación debe ser muy flexible, el objetivo es articular los costos contra las limitaciones presupuestales del proyecto y ayudar a las partes interesadas a decidir si vale la pena seguir adelante con el proyecto o no. Si es necesario, proponga opciones para reducir gastos, tales como la eliminación de elementos de trabajo de alto valor. Lista de Verificación Una vez se obtenga el Plan General del Proyecto se pueden proceder hacer una serie de preguntas para verificar que artefacto está estructurado de forma coherente tales como: 12 ­ El plan ha sido elaborado con el equipo? La planificación del proyecto no debe hacerse en forma aislada, cada uno de los miembros del equipo deben participar. ­ Tiene el equipo conocimiento del proceso de desarrollo que guía el proyecto? ¿Qué funciones y rol desempeña en el equipo? ¿Cuánto tiempo duran las iteraciones? ¿Qué normas de codificación deben seguirse? ¿Qué herramientas debe utilizarse en la etapa de desarrollo, construcción y prueba? ¿Qué medidas y métrica se utilizarán para el seguimiento de los progresos? ­ Los hitos del proyecto han sido definidos? ¿Cuáles son los principales hitos? La estrategia de despliegue ha sido objeto de discusión? ¿Cómo va a ser entregado el producto al cliente? 4.2.4. Elaboración del Plan de Iteración Propósito Los objetivos principales del plan de iteración es brindar al equipo un lugar central para la información con respecto a los objetivos de la iteración, un plan detallado con tareas asignadas y resultados de la evaluación. Este artefacto también ayuda al equipo a monitorear el progreso de la iteración. Las asignaciones de tareas para una iteración dada son un subconjunto de todas las tareas sobre el Artefacto Listas de Unidades de Trabajo, por consiguiente el plan de iteración idealmente referencia esos elementos de trabajo. Opciones de Representación El nivel de detalle o formalidad del plan debe ser adaptado a los objetivos que usted necesita alcanzar satisfactoriamente. El plan podría, por ejemplo, ser capturado • sobre un tablero (o pizarra) listando los objetivos, las asignaciones de tareas y los criterios de evaluación, • como un documento de una página listando los objetivos y criterios de evaluación de la iteración, como también haciendo referencia a la Lista de Elementos de Trabajo para asignaciones para esta iteración o • un documento más complejo, soportado por un diagrama de Gantt o Pert en una herramienta de planeación de proyectos. 13 Durante la planificación del proyecto se identifican ciertas iteraciones, pero como las estimaciones tienen un grado de incertidumbre debido a la falta de detalle en el momento de su creación, se deben complementar y comunicar, permitiéndole al equipo aumentar, a lo largo del proyecto, la precisión de las estimaciones a medida que se conocen más detalles. El Administrador del Proyecto es el responsable de garantizar que el equipo se compromete a una cantidad razonable de trabajo para la iteración basada en el desempeño del equipo en anteriores iteraciones. Pasos a. Priorizar Unidades de Trabajo Al planificar la siguiente iteración se debe priorizar las listas de unidades de trabajo considerando lo que ha cambiado desde la última iteración, tales como las solicitudes de cambio, cambio de prioridades de los interesados o los nuevos riesgos que se han encontrado. b. Perfeccionar el Plan General de proyecto En función de los resultados de la evaluación de las iteraciónes ya ejecutadas, el líder del Proyecto podría tener que revisar el Plan de Proyecto y efectuar algunos cambios en cuanto a tiempo o recursos requeridos para dar cumplimiento a los objetivos trazados en el mismo. Si el cambio afecta a ciertos hitos definidos en el proyecto, el líder del Proyecto deberá consultar con las partes interesadas antes de comprometerse con ellos. c. Definir los objetivos de la iteración Es preciso trabajar con el equipo para afinar los objetivos de la iteración que se encuentra en el Plan del Proyecto y el Plan de Iteración con el fin de definir los objetivos de alto nivel de la iteración. Los objetivos los deben impulsar los interesados sobre la base de prioridades y, a su vez, se revisarán una vez finalice el plan de iteración. Estos objetivos, que generalmente se definen como de alto nivel, deben ser probados durante la iteración con el fin de ofrecer mayor valor al usuario. d. Comprometerse a trabajar la iteración El líder del proyecto trabaja con el resto del equipo para identificar y priorizar las Unidades de Trabajo que deben abordarse. Los objetivos de alto nivel proporcionan orientación sobre qué unidades se deben considerar. El Plan de Iteración de la iteración anterior debe incluir una evaluación de los resultados, y también se puede utilizar como insumo para la planificación de la iteración actual. De acuerdo con la capacidad de trabajo del equipo se determina la cantidad de trabajo que se puede hacer dentro de la iteración. El equipo desagrega tareas de acuerdo a los temas de trabajo que están asignados a la iteración y estima el esfuerzo requerido para desarrollar cada tarea. (Véase la directriz: Estimación Ágil). Las tareas habituales van desde un día a dos días de duración. Cuando un equipo ha decidido llevar a cabo una unidad de trabajo, ésta se asignará a uno o varios miembros del equipo. Idealmente, el equipo las proyecta, ya que esto hace que sus miembros se motiven y comprometan a hacer el trabajo, sin embargo, algunas veces, sobre la base de la cultura existente, el líder del proyecto asigna el trabajo. 14 e. Examen de riesgos A lo largo del proyecto, pueden surgir nuevos supuestos y preocupaciones. El equipo identifica, prioriza y actualiza el Plan de Riesgos ,como parte de la planificación de la iteración Las medidas de control y prevención a los riesgos se añaden a la Lista de Unidades de Trabajo, con lo cual se influye sobre la labor en desarrollo de la iteración. f. Definir criterios de evaluación Cada iteración debe incluir la aplicación de pruebas detalladas como parte de la evaluación. Otros criterios de evaluación pueden incluir con éxito las manifestaciones favorables o de uso a las principales partes interesadas, por parte de un pequeño grupo de usuarios objetivo. (Véase Documento de criterios de evaluación en el Plan de Iteración). Lista de Verificación Se han elaborado el plan de iteración con el equipo de trabajo? La planificación de la Iteración no deberia ser hecha aisladamente, todos los miembros del equipo deberian estar involucradas en este proceso Son claros los objetivos de la Iteración? Los objetivos de la iteración estan basados en las prioridades de los interesados? Han sido identificados los hitos para la iteración? Esto puede incluir las fechas para los cierres de iteración, los controles y revisiones retrospectivas. Los miembros del equipo siente confianza en las unidades de trabajo asignadas? Observando los resultados de iteraciones anteriores, es factible efectuar el trabajo definido para la actual iteración ? Si el equipo de trabajo siente que hay mucho por hacer, debe discutir con los interesados si algunas unidades de trabajo podrian ser parte de futuras iteraciones. 4.2.5. Elaboración de Listas de Unidades de Trabajo Propositos • Proporciona una lista con todas las demandas de capacidades adicionales o mejoras para la aplicación. Note que algunas de estas demandas podrían no ser implementadas o ser implementadas en iteraciones posteriores. • Proporciona una lista de todos los trabajos priorizados, estimados y asignados dentro del proyecto. Adicionalmente, por separado, se prioriza la lista de riesgos. • Proporciona al equipo de desarrollo un lugar donde encontrar lo que se necesita hacer, obtener 15 referencias a los materiales requeridos para llevar a cabo el trabajo y un lugar donde reportar los progresos realizados. Los Elementos de Trabajo pueden ser bastante amplios en su alcance, especialmente cuando capturan demandas para mejoras, tales como "Planear el Soporte Financiero" para una aplicación financiera personal. El Elemento de Trabajo se analiza y divide en pequeños Elementos de Trabajo tal que puedan ser asignados a una iteración, por ejemplo, el escenario de caso de uso "Calcular Precio Neto". Además de dividir puede ser necesario identificar tareas susceptibles de ser asignadas a desarrolladores, tal como "Desarrollar IU para Calcular Precio Neto". Esto significa que los Elementos de Trabajo frecuentemente tiene una relación padre / hijo. Opciones de Representación Como una hoja de cálculo o base de datos La Lista de Elementos de Trabajo se puede capturar como artefacto separado, representado a través de una hoja de calculo o una tabla de bases de datos. En herramientas específicas Otras opciones para capturar la lista de trabajos a realizar son Administración del Proyecto, Administración de Requisitos y herramientas para Cambiar Solicitudes. El Subconjunto como parte del Plan de Iteración El artefacto del Plan de Iteración referencia típicamente Unidades de Trabajo que están asignados a la iteración en ejecución. Si el equipo esta capturando el Plan de Iteración, por ejemplo sobre un Tablero (pizarra), el equipo podría referenciar unidades de trabajo de alto nivel en la Lista de Unidades de Trabajo para ser asignados a la iteración y mantener pequeños elementos de trabajo de bajo nivel para rastrear el trabajo día a día sólo dentro de un plan de iteración. Lista de verificación Esta lista es usada para verificar que cada tipo de trabajo que deba ser hecho en el proyecto esta registrado. Las unidades de trabajo están descritas sin ambigüedad? ¿Cada unidad de trabajo tiene un nombre y una descripción clara? Esto ayuda al equipo de trabajo a estimar el tamaño de la unidad. Si es necesario, incluir enlaces de los productos asociados a la lista de unidades de trabajo como material de referencia. Se han sido priorizado las unidades de trabajo? Cada unidad de trabajo ha sido priorizada por el valor de importancia para la iteración o el proyecto? Esto ayuda a seleccionar el equipo y a liberar los productos que serán entregados en cada iteración. 16 Se han sido estimado las unidades de trabajo? Cada unidad de trabajo ha sido priorizada por el valor de importancia para la iteración o el proyecto? Esto ayuda a seleccionar el equipo a liberar los productos de que serán entregados en cada iteración. Las unidades de trabajo se pueden auditar? ¿Cada unidad de trabajo tiene definido un estado de acuerdo a sus características? Esto ayuda al equipo a vislumbrar cómo está el desarrollo del proyecto. Tienen el tamaño correcto las unidades de trabajo programadas en la agenda? Si una unidad de trabajo está prevista para una iteración, entonces debería ser desglosada en temas de trabajo que se puede completar en un plazo razonable (de un par de horas a unos pocos días). Esto ayudará a que el equipo sea más productivo. 4.2.6. Reuniones diarias Esta directriz describe cómo el equipo puede sincronizar su trabajo y el progreso, haciendo un seguimiento diario del estado de las actividades planteadas en la Iteración o el proyecto, evaluando el grado de cumplimiento y los impedimentos encontrados. Las reuniones diarias son los latidos del corazón del proyecto. Todos los miembros del equipo están obligados a asistir a ella. Las reuniones se celebran en el mismo lugar a una hora fijada cada día y no deben durar más de 15 minutos. Cualquier persona que participa directamente también puede asistir como observador, no obstante, se debe tener cuidado, porque demasiadas personas en la reunión pueden causar trastornos e impedir el intercambio de información. En este tipo de reuniones diarias deben asistir como máximo 10 personas. Durante la sesión diaria, cada miembro del equipo puede hacerse este tipo de preguntas: 1. Qué hice ayer ? 2. Qué voy a hacer hoy? 3. Qué está obstaculizando mi trabajo? Estas 3 preguntas tienen unos propósitos específicos: La primera pregunta es la prueba del equipo que evidencia que sí fue o no terminado un trabajo previsto para la iteración actual. Al responder la segunda pregunta se revisa la estrategia del proyecto en el día a día, y el equipo se reorienta teniendo en cuenta los cambios que se han puesto de manifiesto en la pregunta anterior. La tercera pregunta permiten vislumbrar los problemas u obstáculos que se pueden presentar en la ejecución de nuevas tareas en la lista Unidades de trabajo. El efecto más importante de esta pregunta 17 es crear una lista de preguntas para los directivos. El equipo debe esperar la gestión para ayudar a eliminar los cuellos de botella. Este es el número mínimo de preguntas para cumplir con los objetivos de las reuniones diarias. Otros equipos con experiencia tienden a aumentar una pregunta adicional para mejorar el trabajo en equipo: "¿Qué he aprendido o decidido de importancia para el equipo?" . "¿Qué puede ayudar u obstaculizar a otros a cumplir sus compromisos? Para los equipos auto­dirigidos, el libro diario de reuniones es un mecanismo para informar rápidamente al equipo sobre el estado del proyecto y las personas, apoya la apertura, permite la resolución de conflictos en tiempo real, y en definitiva construye un equipo. La eficacia de los equipos se construye en la regularidad por comunicar, compartir compromisos y ayudarse unos a otros. 4.2.7. Estimación ágil Esta guía explica los tres conceptos claves de la estimación ágil y cómo se relacionan unos con otros. Se describen los conceptos de tamaño, velocidad y esfuerzo. Tamaño: Es una estimación de alto nivel que normalmente se mide utilizando una unidad neutral como por ejemplo puntos. Rendimiento: Nos dice cuántos puntos puede ofrecer dentro de una iteración el equipo del proyecto Esfuerzo: Se hace la equivalencia del tamaño, medido en puntos, a una estimación del esfuerzo requerido en unidades efectivas o reales como días u horas. La estimación de esfuerzo indica cuánto tiempo tomará el o los miembros del equipo para completar el trabajo asignado al tema. Estimación de Tamaño La estimación del tamaño suele hacerse usando una medida relativa llamada puntos. El equipo decide que tan grande es un punto, y sobre la base de ese tamaño, determina cuántos puntos se le otorga a una unidad de trabajo. Para realizar la estimación más ágil, utilice puntos con números enteros 1, 2, 3, 5, 8, y así sucesivamente, en lugar de fracciones de un punto, por ejemplo, 0,25, o 1,65 puntos. Para empezar, defina el valor del punto mas alto y mas bajo que se le pueden dar a las unidades de trabajo según el esfuerzo requerido. Tenga en cuenta que los puntos se utilizan para las estimaciones de alto nivel, así que no pase demasiado tiempo en un mismo tema, así se evitará la pérdida de esfuerzo en cosas que probablemente no van a ser abordadas durante la actual iteración. Estimación del Rendimiento El rendimiento es un factor clave en la planificación de la iteración. Se indica el número de puntos que se van a obtener dentro de una iteración por un determinado equipo y proyecto. Por ejemplo, un equipo 18 planifico lograr 20 puntos en la primera iteración. Al final de la iteración, se observó que sólo entregó 14 puntos, su velocidad, por lo tanto, fue 14. Para la próxima iteración, el equipo plantea un menor número de puntos, digamos 18 punto y así cumplir mejor que en la iteración anterior. En esta iteración, entregó 17 puntos, dando una velocidad de 17. El rendimiento cambia de iteración a iteración. Algunas iteraciones resultan mas sencillas que otras, y los puntos no siempre son idénticos en términos de esfuerzo. Algunos miembros del equipo son más eficaces que otros, algunos problemas terminan siendo más difíciles que otros. Además, los cambios en las funciones y roles del equipo, el aprendizaje y nuevas habilidades adquiridas, un mejor trabajo en equipo, o la atención de tareas ajenas al proyecto impacta la velocidad. En general, la velocidad normalmente aumenta durante el proyecto a medida que el equipo desarrolla nuevas habilidades y conocimientos. Las diferencias de rendimiento al interior del equipo se compensan en términos de cuán grande es es el valor del punto. Supongamos que los equipos Alfa y Beta son igualmente eficaces en el desarrollo de software y ejecutan el mismo proyecto en paralelo. Sin embargo, en el equipo Alfa evalúan sus unidades de trabajo con un valor de 3 veces lo equivalente a un punto en el equipo Beta. El equipo Alfa evalúa las unidades de trabajo A, B, C y D y le corresponde 30 puntos, y se estima que al equipo Beta, con las mismas unidades de trabajo, le corresponden 10 puntos. Ambos equipos entregan 4 unidades de trabajo en la siguiente iteración, pero el equipo Alfa tiene una velocidad de 30, mientras que el equipo Beta una velocidad de 10. Puede sonar como si el equipo Alfa fuese más eficaz, pero veamos lo que ocurre en el próximo plan de iteración. Ambos quieren llevar a cabo las mismas unidades de trabajo E y H. En este caso el equipo Alfa ha estimado en 30 puntos su velocidad, y el equipo de Beta la ha estimado como normal a 1 / 3 puntos, o 10 puntos. El resultado final es que no importa cuan grande que es un punto, siempre y cuando este sea compatible con su equipo. La eficiencia de los diferentes miembros del equipo se refleja en el rendimiento promedio. Veamos un ejemplo: Supongamos que Ann siempre funciona 3 veces más rápido que Jack y Jane. Ann quizás entrega 9 puntos por iteración, y Jack y Jane 3 puntos por cada iteración. La velocidad por persona es de 3 y del equipo será de 15 puntos. Como se mencionó anteriormente, Ann y Jack pueden no estar de acuerdo sobre cuánto esfuerzo se asocia con una unidad de trabajo, pero pueden ponerse de acuerdo sobre cuántos puntos vale la pena. El rendimiento del equipo es de 15, lo cual se traduce automáticamente en la cantidad de trabajo que puede ser asumido. Como los miembros del equipo pueden cambiar, o se vuelven más o menos eficaces, su velocidad va a cambiar, por tanto se pueden obtener más o menos puntos. Esto, sin embargo, no requiere de un cambio de la estimación del tamaño. El tamaño sigue siendo el mismo. 19 Estimación de Esfuerzo La estimación del esfuerzo traduce el tamaño medido en puntos a una estimación real y detallada de los esfuerzos requeridos por las unidades de trabajo efectivas en días u horas. Por ejemplo, un plan de iteración que tiene como unidad de trabajo diseñar, implementar y probar una hipótesis, puede tener un tamaño de 5 puntos. Dado que se trata de una gran unidad de trabajo es razonable dividirla en un número de 4 de unidades de trabajo menores y separarlas por detalle así: detalle, diseño, pruebas en el servidor y ejecución y pruebas con los clientes. A los miembros del equipo se les pide que describan las tareas que se deben realizar y, a continuación, que detallen la estimación del esfuerzo, medido en horas o días, para su ejecución. En el presente ejemplo se establecieron, dentro del paréntesis, las siguientes estimaciones reales con la persona responsable: ● Detalle del escenario (Ann): 4 horas ● Diseño de escenario (Ann y Jack): 6 horas ● Implementación y pruebas del escenario del lado del servidor (Jack): 22 horas ● Implementación y pruebas del escenario del lado del cliente (Ana): 12 horas ● Estimación del esfuerzo total de Escenario: 44 horas La estimación de las horas podría cambiar si hay otras personas para asignar a las tareas. Por tanto, no tiene sentido hacer estimaciones detalladas hasta que se tenga claro que trabajo se va a llevar a cabo y los posibles problemas asociados. A menudo, es preciso hacer el análisis y diseño a la unidad de trabajo que se va a desarrollar para hacer una estimación mas razonable. Recuerde que las estimaciones siguen siendo estimaciones, y una persona asignada a una tarea debe sentirse libre y en caso necesario, se la debe alentar a en volver a estimar el esfuerzo necesario para completar la tarea, así obtenemos una visión realista de progreso dentro de una iteración. 4.2.8. Gestionar la iteración Propósito Gestionar la itera ción Incluye: ­ Evaluar el estado del proyecto e identificar los obstáculos y oportunidades. ­ Identificar y gestionar excepciones, problemas y riesgos. ­ Comunicar el estado del proyecto y gestionar la expectativa de los interesados. El propósito de esta guia es: ­ Ayudar al equipo a cumplir con los objetivos de la iteración y mantener el proyecto en marcha. 20 ­ Gestionar las expectativas de los interesados a partir de los descubrimientos técnicos y prácticos dados durante la ejecución del proyecto. El desarrollo o madurez del equipo es parte fundamental de la ejecución del proyecto. El líder del proyecto es responsable de la mejor interacción de los miembros del equipo y la confianza entre ellos. La gestión se efectúa basada en los objetivos y no por el tiempo requerido para cumplir con ciertas actividades. El líder del proyecto guiará el equipo a cumplir con los objetivos de la iteración mediante el control de los avances y el trabajo pendiente por terminar. Cuando el equipo se está rezagando, el líder del proyecto ayudará al equipo a evaluar sobre cómo se puede reducir el trabajo y seguir cumpliendo los objetivos de la iteración. Las necesidades de los interesados se deben resolver continuamente durante toda la iteración. A su vez, los interesados pueden participar en la aprobación de los cambios y acciones que les afectan. Pasos a. Capturar y comunicar el estado de la iteración El líder del proyecto debe: ­ Vigilar continuamente el proyecto para asegurarse de su adecuado progreso ­ Permitir que el equipo reaccione tan pronto como sea posible a cualquier cambio Existen medios alternativos que se pueden utilizar para realizar seguimiento a la Iteración. Las reuniones diarias con el equipo del proyecto son útiles para comprender lo que los miembros del equipo han realizado desde la última reunión, y lo que planea realizar antes de la próxima reunión. También permite al equipo identificar inquietudes que se deben tratar. Otro medio es la colección de parámetros básicos, idealmente en forma automática o montados manualmente. Los gráficos son uno de las métricas más útiles para medir el progreso del proyecto. Muestran el número de unidades de trabajo que se han realizado en las iteraciones anteriores o en el proyecto. Comunicar el estado del proyecto es tan importante como la recopilación de la misma. Mantenga la información visible para los interesados y el equipo del proyecto en todo momento. b. Manejar las excepciones y problemas Uno de las tareas claves del líder del proyecto es conocer los problemas e inquietudes del equipo del proyecto. Debe centrarse en aquellos problemas que bloquean el progreso de la Iteración. Una rápida sesión diaria es una buena manera de controlar esos problemas e inquietudes haciendo un registro de los mismos. Es preciso identificar la causa y el impacto de los problemas y las excepciones que puedan surgir. Identificar, para los problemas que tienen un impacto inmediato en el corto plazo, las posibles soluciones, metas y objetivos, y determinar quiénes deben participar en la implementación de la solución. Luego, definir las acciones correctivas y ponerlas en práctica. 21 Identificar y gestionar los riesgos Identificar los riesgos tan pronto como se inicia el proyecto y continuar la identificación y gestión de riesgos a lo largo del proyecto. El plan de Riesgo se debe revisar semanalmente o, como mínimo, una vez por iteración. Todo el equipo debe participar en la identificación y la mitigación de riesgos. Gestión de objetivos Cuando un equipo se está quedando significativamente atrás, o se producen problemas críticos que impiden el cumplimiento de los objetivos de la iteración, puede ser necesario evaluar y gestionar las listas de unidades de trabajo para garantizar que el equipo ofrezca un producto útil con un incremento al final de la iteración, mientras se maximiza el valor de las partes interesadas . El líder del proyecto debería trabajar con el equipo y las partes interesadas para revisar el Plan de Iteración y, en caso necesario, reducir el énfasis en tareas que no son de importancia crucial y buscar su aplazamiento para iteraciones posteriores. En raros casos, si los objetivos de la iteración se hacen imposibles de ser cumplidos, el equipo podría considerar la posibilidad de poner fin a la iteración o reformular una nueva iteración con otro objetivo. 4.2.9. Evaluar los resultados obtenidos de la Iteración Propósito Esta guia pretende orientar como se debe evaluar los resultados obtenidos producidos durante la iteración y aplicar las lecciones aprendidas para mejorar el proceso de desarrollo. Para poder ajustar las expectativas de desarrollo en intervalos regulares dentro del proyecto, es de utilidad generar lluvias de ideas en torno a los incrementos del producto y adaptar el comportamiento de acuerdo al conocimiento adquirido. El lider del Proyecto es responsable de la coordinación de la valoración. El (o ella) discute con el equipo como deben presentar los resultados de la iteración de forma que se resalten los logros y que los interesados en el proyecto decanten de forma eficiente los alcance logrados. El líder del proyecto también recoge los partes del equipo en cuanto a las fallas y éxitos durante el desarrollo de la iteración. Este conocimiento deberá volverse objetivo de tal forma que ayude a todos los involucrados a tomar decisiones documentadas en la planificación de las siguientes iteraciones y en la determinación del mejor camino de acción para el proyecto. Esta tarea debe ser desarrollada al final de cada iteración y al final del proyecto. 22 Pasos Evaluación de los resultados de la iteración Hacia el final de la iteración, el equipo debe evaluar conjuntamente si los objetivos con los criterios de evaluación establecidos en el Plan de iteración sí se cumplieron, y si el equipo llevo a cabo las actividades a las que se comprometió a desarrollar. Es conveniente fijar objetivos medibles en lo posible para evaluar que las unidad de trabajo trazadas se completaron exitosamente. Presentar los resultados y obtener retroalimentación El equipo debe presentar los resultados obtenidos de la iteración a los usuarios finales y otras partes interesadas del proyecto, con el fin de recabar sus comentarios, o mejor aún, brindarles funcionalidades especificas del producto final. Esto se debe hacer a lo largo de la iteración, o hacia el final de la misma. Trabajo que no se completa no debe ser presentado. Conocimientos obtenidos, como nuevas funciones, cambios solicitados y defectos se registran en la Lista de Unidades de Trabajo, a fin de que las prioridades de los proyectos, el alcance y la duración puedan ser refinadas en la próxima iteración. Realizar una retrospectiva Es indispensable realizar una revisión juiciosa con el equipo sobre el proceso de desarrollo adoptado, la eficacia del entorno de trabajo y otros factores. Es preciso discutir qué cosas ha ido bien, que cosas podría haber sido mejor y que se puede hacer para obtener mejores resultados. Se deben capturar los resultados de la evaluación del Plan de Iteración inmediato y las acciones que deben adoptarse para mejorar el enfoque de desarrollo para la próxima iteración. Cierre de proyecto Este paso debe realizarse únicamente cuando la revisión de la iteración coincide con el final del proyecto. Involucre al equipo y las partes interesadas en la evaluación final para la aceptación del producto de software. 4.2.10. Gestionar posibles cambios en una iteración Esta guía promueve las mejores prácticas para aislar a los miembros del equipo de cambios perturbadores en la iteración en curso. Las solicitudes de cambio se reciben y priorizan durante la iteración actual, pero no se actúa hasta que se asignen a una iteración futura. 23 La mayoría de procesos de desarrollo de software de tipo iterativo recomienda no introducir cambios durante una iteración. La idea esencial es que las iteraciones deben ser cortas y con un alcance claramente definido como para que puedan ser encajadas en el tiempo. Para limitar el alcance dentro de una iteración, se revisan las solicitudes de cambios y se priorizan tan pronto como sea posible, pero no se asignan hasta una futura iteración a través de la Lista de Unidades de Trabajo. Debido a que las iteraciones son relativamente cortas no causan una demora indebida en relación con los cambios urgentes o peticiones importantes. Se puede dar una excepción si se descubre un defecto durante las pruebas que impide que el equipo cumpla con los objetivos propuesto en la iteración. En este caso es razonable asignar una nueva unidad de trabajo para la iteración actual, ya que no representa un cambio de alcance y garantiza que el trabajo se termine. 4.2.11. Manejo de la Retrospectiva La retrospectiva que se aplica en el desarrollo de software se describe como: "Un evento celebrado al final de una iteración, hito o proyecto que pretende aprender de las experiencias y dificultades y definir un plan de cambios para mejorar el próximo esfuerzo." Aunque la retrospectiva se realiza al final de un proyecto es importante que este proceso sea continuo, llevadolo a cabo en sus principales hitos, al final de las iteraciones y en general inmediatamente después de sucesos claves. La aplicación de la retrospectiva está íntimamente relacionada con los procesos del proyecto donde la madurez del equipo está en constante vigilancia, la evolución del proyecto es fácil de medir y el equipo toma conciencia de sus oportunidades de mejora aumentando la productividad. Surge entonces una relación entre un proceso de desarrollo evolutivo y una retrospectiva que apoya los diversos métodos de inspección y de adaptación. Las iteraciones se diseñan, en parte, para medir el progreso del equipo con los objetivos del proyecto. Existen varios métodos que se pueden utilizar para incentivar la retrospectiva del equipo y comenzar el trabajo de investigación colectiva. Algunas preguntas que pueden conducir al equipo a la restrospectiva son : "¿Qué funcionó bien durante las últimas iteraciones o el proyecto, y así sucesivamente?", "Qué no funcionó bien durante los últimas iteraciones o el proyecto, y así sucesivamente?" y "¿Qué debemos hacer de manera diferente o qué mejoras debemos realizar para nuestra próxima iteración o el proyecto, y así sucesivamente?". Al resolver las preguntas se espera que se generen acciones que ayuden al equipo en la priorización de propuestas de mejora para el proyecto. La retrospectiva facilita crear un entorno propicio para las diversas prácticas de inspección, adaptación y control del proyecto. Estos mecanismos pretenden asumir y responder a la existencia de la complejidad, lo imprevisible y el cambio constante. En el contexto de una retrospectiva, los métodos de inspección y adaptación producen un circulo de retroalimentación a partir del cual la flexibilidad, la capacidad de respuesta y la confiabilidad se hacen realidad. 24 La mera ejecución de una retrospectiva es insuficiente sin un compromiso con la organización y una cultura de colaboración. El éxito de la Retrospectiva genera un entorno de motivación y cumplimiento de los intereses del equipos, no del individuo, y fomenta la comunicación abierta y frecuente. Las Retrospectivas encarnan el espíritu de colaboración de los equipos y la auto­reflexión, ofreciendo un entorno en el que los miembros se animan a proporcionar información e identificar las lecciones aprendidas [DER06]. Los participantes que se reúnen en el marco de una retrospectiva constituyen más que un "grupo de trabajo". Los participantes se deben considerar como "un pequeño número de personas con habilidades complementarias que están comprometidos con un propósito común, objetivos de desempeño y un enfoque de mutua responsabilidad." [KAT93]. Los participantes deben ser individuos que desarrollen diferentes funciones dentro del período de tiempo del proyecto o proyectos a los que se llevará a cabo la retrospectiva. El tamaño del equipo es importante. Lograr un ambiente participativo de retrospectiva puede ser difícil con un gran grupo superior a 25 personas, lo mejor es que sea un grupo de participantes pequeño represente suficientemente los grupos funcionales. La persona que se designa para asumir el papel de facilitador o líder retrospectivo debe poseer habilidades básicas facilitando un enfoque de gestión: "Un facilitador es una persona que permite a los grupos y organizaciones trabajar más eficazmente y que contribuye a lograr la sinergia del equipo. Ella o él debe ser neutral y no tomar partido o defender un punto de vista durante la reunión, debe ser abierto, inclusivo y emplear procedimientos para realizar trabajo de grupo. Un facilitador permite diálogo de aprendizaje y guía para ayudar a un grupo en el modo de inferir profundamente sobre sus procesos y el contexto sistemático". [KAN96] Manejo de un proyecto con retrospectiva Esta directriz se refiere a cómo llevar a cabo, paso a paso, un proyecto en retrospectiva. Inicie la retrospectiva del proyecto mediante el establecimiento de la duración, objetivos, y expectativas de la reunión. Por ejemplo: Iteración: 2 a 4 horas Incidente: 15 a 45 minutos Proyecto: 1 a varios días Si el equipo está llevando a cabo la primera retrospectiva, el grupo tendrá que crear las normas que seguirá para las futuras retrospectivas ya que es preciso establecer un "contrato social" que claramente describa el " trabajo en equipo basado en valores y acuerdos", este contrato debe incluir las directrices institucionales y los principios inviolables que rigen la conducta y la ética del equipo. Ejemplos de acuerdos de trabajo son: llegar tarde no es aceptable, los teléfonos celulares deben estar apagados durante la sesión de trabajo, todos los participantes deben estar presentes durante la reunión o pedir el permiso del grupo para salir entre otras. 25 Los acuerdos a los que llegue el grupo debe ser visibles en las sesiones que se efectúen. Recoger y analizar datos El equipo debe comenzar este paso con una revisión significativa de las características de la iteración, la implementacion de una funcionalidad especifica, un período de tiempo del proyecto y, en general, una situación particular. La labor del equipo en este paso incluye efectuar una crítica a la evolución del proceso, los resultados obtenidos, las mediciones calculadas en el proyecto (rendimiento, número de defectos, entre otros) y a la revisión de los artefactos del proyecto (tal como artefactos de requisitos o de los planes del proyecto). Motive al equipo para la captura de esta información (los datos del proyecto, opiniones, etc) mediante el uso de diversas herramientas (pizarras, cartas, calendarios) que proporcionan una representación visual para que el equipo puede identificar las relaciones. Las preguntas guían al equipo en la recolección y análisis de datos significativos del proyecto. Se puede utilizar preguntas claves para obtener la información pertinente tales como: Se reunió el equipo para definir las metas y objetivos? ¿El producto final es de buena calidad? ¿Se reducen o eliminan los riesgos?, ¿Se identificaron nuevos riesgos? ¿Los trabajos y temas previstos fueron tratados? ¿Cuál es la velocidad del equipo en relación con el plan? ¿Los usuarios finales hacen parte activa de la iteración? ¿El plan del proyecto requiere cambios? ¿Se han presentado cambios en la definición de los interesados o en los requisitos? ¿Fue el proceso de desarrollo adecuado? ¿Cómo puede ser ajustado a las necesidades específicas de este proyecto? Luego de resolver estas preguntas, el equipo generá una lista de temas en los que centrará su análisis e investigación. Con base en ellos, el equipo evaluará estos factores, preguntándose que éxitos y fracasos obtuvo y cómo puede mejorar. . Éxito: "¿Qué funcionó bien para el equipo durante las últimas iteraciones (fase o proyecto ...)?" Fracasos: "Qué no funcionó bien para el equipo durante las últimas iteraciones (fase o proyecto ...)?" Oportunidades de mejora: "¿Qué debe cambiar el equipo o que acciones de mejora debe emprender en la próxima iteración (fase o proyecto ...)?" 26 Después de que el equipo ha recopilado y analizado información clave para un proceso de retrospectiva, evaluará los elementos principales del proyecto y podrá saber lo que ha funcionado bien, lo que no y qué hay que hacer para que sea diferente y mejor la próxima vez. Establecer prioridades Tomando como referencia la información recogida y analizada del proyecto en el paso anterior, el equipo crea una lista de posibles mejoras y le asigna una prioridad a cada elemento de la lista. Luego se seleccionan algunas mejoras y se aplican en la próxima iteración. Es preciso definir unos compromisos por parte de los miembros que soporten las acciones de mejoras propuestas. Las mejoras propuestas que no fueron priorizadas se deberán trabajar en la próxima iteración, esto preservará la labor de la retrospectiva. Toda la documentación del proceso de análisis y mejoras estará disponibles para su fácil acceso y permitir seguimiento continuo. 27
