¿De qué vamos a hablar hoy? Estrategia ágil vs. estrategia tradicional Scrum: ciclo de proyecto, roles Planificación ágil Seguimiento de un proyecto Desarrollo ágil en acción: Rational Team Concert

Expectativas no cumplidas Caos!? Resultado de los proyectos The CHAOS Report (1994) Baja calidad Demoras en la entrega Fuente: The Standish Group (www.standishgroup.com) Succeeded: finalizado en tiempo y presupuesto, con toda la funcionalidad especificada Challenged: finalizado y operativo pero superando tiempo, presupuesto y con menos funcionalidad que la especificada Failed: cancelado en algún punto del ciclo de desarrollo Succeeded: finalizado en tiempo y presupuesto, con toda la funcionalidad especificada Challenged: finalizado y operativo pero superando tiempo, presupuesto y con menos funcionalidad que la especificada Failed: cancelado en algún punto del ciclo de desarrollo Expectativas no cumplidas Presupuesto excedido The Standish Group http://www.standishgroup.com

La estrategia tradicional Basada en documentos Trabajo individual con entregas entre roles especializados Cambios tardíos = alto costo Fecha de fin poco predecible, especialmente en fase de estabilización (pruebas y corrección de defectos)

Agilidad = Adaptabilidad It is not the strongest of the species that will survive or the most intelligent. It is the one most adaptable to change. -Charles Darwin Los métodos tradicionales asumen que los requerimientos son conocidos y pueden ser congelados antes de comenzar el diseño y la construcción Controlar el cambio es deseable Los métodos ágiles surgieron en ambientes donde esto no era posible o apropiado El cambio es alentado

La estrategia ágil Equipos interdisciplinarios, que incluyen al cliente (o un representante) Entrega frecuente de software funcionando Fuerte foco en la calidad Builds y tests automatizados, integración al menos una vez por día

Ciclo de un proyecto Scrum Planificación de Sprint (Sprint planning): El Product Owner selecciona los requerimientos mas prioritarios del Product Backlog que desea incluir El Team determina cuanto puede convertir en funcionalidad al final del Sprint Se agregan las tareas al Sprint Backlog (que sigue evolucionando a lo largo del Sprint) Scrum diario (Daily Scrum): Objetivo: sincronizar el trabajo de los miembros del Team y resolver inconvenientes a medida que surgen Enfocada en contestar 3 preguntas: Qué hice para este proyecto desde la última reunión? Qué pienso hacer hasta la próxima reunión? Qué impedimentos tuve para cumplir mis compromisos? Revisión de Sprint (Sprint review): Objetivos: Validar cumplimento de expectativas y definir próximos pasos Se demuestra la funcionalidad completa al ProductOwner y otros Stakeholders del proyecto Se presenta qué salió bien y qué salió mal en el Sprint Se toma nota de los cambios que pide el cliente Retrospectiva sobre el Sprint (Sprint retrospective): Objetivos: Analizar el resultado del Sprint y proponer mejoras en el proceso para el siguiente Sprint Las reuniones de Planificación de Sprint, Scrum diario, Revisión de Sprint y Retrospectiva de Sprint constituyen las prácticas empíricas de inspección y adaptación de Scrum. K.Schwaber - Agile Project Management With Scrum

Roles en Scrum ScrumMaster Product Owner Team Coach Facilitador Representa al cliente / usuarios Define las prioridades Team Roles Scrum Master (Project Manager): Dueño del proceso Es responsable de : Enseñar Scrum a los involucrados en el proyecto Implementar Scrum de forma que encaje en la cultura de la organización Garantizar que todos cumplan las reglas de Scrum Product Owner (Product Manager / Key User / Business Analyst): Dueño de la definición de “éxito” del proyecto Establece los objetivos de ROI Crea la lista inicial de requerimientos (Product Backlog) Establece el plan preliminar de entregas Es responsable de: Usar el Product Backlog para garantizar que la funcionalidad que más valor agrega al negocio sea construida primero. Team: Autogestionado e interdisciplinario Incluye todos los roles necesarios para construir el producto: desarrolladores, analistas, testers, documentadores, ... Dueño de los procesos de producción e ingeniería. Define cómo transformar el Product Backlog en un incremento de funcionalidad al final de la siguiente iteración Es colectivamente responsable del éxito de cada iteración y del proyecto en su totalidad. Se recomienda que no sea de más de 7 o 10 integrantes --> para más gente scrum-de-scrum Interdisciplinario Auto-organizado

Product Backlog Product Backlog Visión + ROI Requerimientos Mas beneficio Menos Visión + ROI El proyecto comienza con la definición de los objetivos de negocio, la visión del producto que se quiere construir y el ROI pretendido Con esta información se genera una primera lista de requerimientos, priorizados según el beneficio que aportan. Los requerimientos pueden tener distinta granularidad (los menos prioritarios tal vez sean menos granulares) Puede haber Casos de Uso completos, Escenarios de CU o features (o User Stories) + requerimientos no funcionales Beneficio para el negocio: Aumento de productividad Reducción de costos Aumento de los ingresos Mejora en el nivel de servicio Mejora en la calidad Diferenciación en el mercado

¡Los cambios son bienvenidos! Product Backlog Mas beneficio Menos beneficio Sprint 1  No se admiten cambios Sprint 2 en proceso Eliminado Cambio de prioridad Nuevo Sprint: iteración de 1 a 4 semanas de duración En cualquier momento durante el proyecto (en el ejemplo, Sprint 1 terminado y Sprint 2 en proceso): Se pueden eliminar requerimientos Se pueden agregar nuevos requerimientos Los requerimientos pueden cambiar de prioridad Sin embargo, no se admite ningún cambio sobre el trabajo definido para el Sprint actual

¿Porqué priorizar el backlog? Porcentaje de utilización de features Mas beneficio Menos beneficio Product Backlog ¿Cuál es la importancia de mantener en todo momento el Product Backlog priorizado? Al construir primero los features con mayor beneficio se puede llegar a una primera versión útil e implementable del sistema en menos tiempo. De esta forma, el retorno de inversión comienza antes de que esté finalizado el proyecto. Se puede interrumpir el proyecto en un punto dado si resulta que los features pendientes ya no agregan suficiente valor al producto comparado con el costo de desarrollarlos. Se minimiza el riesgo de construir features que finalmente no serán utilizados por los usuarios del sistema. The Standish Group - 2002 http://www.standishgroup.com

Planificación de release Seleccionar largo sprint Definir condiciones de satisfacción Estimar backlog Estimar velocidad Definir alcance y fecha de terminación El objetivo de un plan de release es proveer un marco de referencia de forma tal que las iteraciones se combinen para construir un producto coherente y útil. Sin un buen plan de release, las iteraciones se sucederían un detrás de la otra sin una dirección clara. Un plan de realease suele abarcar entre tres y seis meses. Se utiliza la velocidad (estimada o promedio) del equipo para determinar cuánto trabajo puede ser completado en el período determinado para el release. Condiciones de satisfacción Determinar cuáles serán los criterios por los cuales el proyecto será considerado un éxito o un fracaso. Dependiendo el caso, puede ser más importante cumplir una fecha (date-driven) o terminar cierta funcionalidad mínima (feature-driven). Estimar backlog Estimar el tamaño relativo de los ítems del backlog. La estimación de cada ítem representará el costo de implementación de cada uno. En función de la relación costo-beneficio el Product Owner puede priorizar el backlog. Priorizar backlog

Planificación del Sprint Ajustar prioridades del backlog Estimar velocidad para el sprint Goal del sprint Seleccionar ítems del backlog Descomponer en tareas Estimar las tareas

¿Cómo va el proyecto? Release burndown Burndown alternativo Gráfico de burndown El gráfico de Burndown muestra visualmente la correlación entre la cantidad de trabajo restante (para terminar) en cualquier momento en el tiempo y el progreso que realiza el equipo para reducir esa cantidad. La intersección de la línea de tendencia y eje horizontal indica la fecha más probable en que terminará el proyecto, según la información disponible en ese momento específico en el tiempo. Este artefacto permite análisis del tipo especulativo ("what if") en cuanto a eliminar funcionalidad para cumplir con la fecha comprometida o aplazar la fecha de entrega para incluir toda la funcionalidad. Permite contrastar la realidad del proyecto (trabajo realizado y velocidad) con respecto a lo planificado o estimado. A nivel Versión: muestra el trabajo restante al final de cada Sprint en alguna medida de tamaño relativa (ej: story-points) A nivel Sprint: muestra la cantidad de horas hombre restantes al final de cada día Gráfico de burndown alternativo Muestra simultáneamente la velocidad del equipo y el ritmo en el que cambia el alcance del proyecto Release burndown Burndown alternativo

Desarrollo ágil ¡En acción! Rational Team Concert

¡Muchas gracias! Alejandro Torres Castañeda Baufest acastaneda@baufest.com.mx Analía Baño abano@baufest.com