Scrum: Principios y Prácticas Clave

El Scrum Master y la administración proveen recursos y remueven obstáculos. Es el reto más fuerte para la adopción de Scrum. Compromiso: El Scrum Team se compromete a metas definidas por iteración y se le da la autonomía y autoridad para decidir cómo alcanzarla. La Administración y el Scrum Manager se comprometen a no introducir nuevo trabajo, eliminar obstáculos y proveer recursos. El Product Owner se compromete a definir y priorizar el Product Backlog, guiar los objetivos por iteración y revisar y ofrecer “feedback” iteración a iteración. Enfoque: El Scrum Team se enfoca en los objetivos establecidos de la iteración, sin distracciones. El Scrum Master y la administración se enfocan en proveer recursos, remover obstáculos y evitar interrupciones al equipo. Apertura: El Product Backlog está disponible para visualizar el trabajo y las prioridades. Las Daily Scrums hacen visible el estado general de los individuos y sus compromisos. La velocidad del trabajo y su tendencia es visible con el Backlog graph. Respeto: Los miembros del equipo se respetan por sus debilidades y fortalezas y no por sus fallas en las iteraciones. Coraje: La administración tiene el coraje de planear y guiar adaptativamente y confiar en el equipo evitando decirles qué tienen que hacer. El equipo tiene el coraje de tomar la responsabilidad de la auto-dirección y la auto-gestión. Scrum es un framework general basado en control empírico para entregar resultados con el máximo valor del negocio en el menor lapso de tiempo posible a través de un equipo auto-organizado, el aprendizaje y la auto-mejora del equipo Scrum. Prácticas clave: Equipos auto-dirigidos y auto-organizados; Una vez escogido, no se agrega trabajo adicional a una iteración; Reunión diaria “de pie” con preguntas especiales; Iteraciones de 30 días; Demo a los stakeholders al final de cada iteración; Cada iteración, planeación adaptativa dirigida por los clientes. Escala de ciclos y ceremonia: Preciso en la longitud de las iteraciones (30 días), no en el número de iteraciones; Flexible en el grado de ceremonialidad pero se recomienda “as little ceremony as possible”. Equipos:1 equipo de Scrum debe ser de 7 o menos participantes; Múltiples equipos pueden formar un proyecto; Pueden tenerse “Scrum de Scrums” donde varios equipos pequeños trabajan juntos y tienen una reunión diaria con representantes de cada equipo; Scrum es complementario a otras prácticas de tal forma que puede aplicarse a otros dominios de software (desde misión crítica hasta más casuales); Promueve valores y prácticas de gestión de proyectos (más que de requisitos, implementación, análisis, diseño, etc.). Por eso puede combinarse con otros métodos.Mayor énfasis en procesos empíricos que en predefinidos. Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce; Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo; Tres pilares soportan toda la implementación del control de procesos empírico: transparencia, inspección y adaptación. Transparencia: Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. Inspección: Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones. Su inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos, en el mismo lugar de trabajo. Adaptación: Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores. Scrum Master: Es el responsable de asegurar que Scrum es entendido y adoptado. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum. Product Owner: es el responsable de maximizar el valor del producto y del trabajo del Scrum Team. Es la única persona responsable de gestionar la Lista del Producto (Product Backlog – PB): Expresar claramente los elementos del Product Backlog; Ordenar los elementos en el Product Backlog para alcanzar los objetivos y misiones; Optimizar el valor del trabajo desempeñado por el Scrum Team; Asegurar que el Product Backlog sea visible, transparente y clara para todos, y que muestra aquello en lo que el equipo trabajará a continuación; Asegurar que el Scrum Team entiende los elementos del Product Backlog al nivel necesario. El Scrum Master da servicio al Product Owner: Encontrar técnicas para gestionar el PB de manera efectiva; Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de PB claros y concisos; Entender la planificación del producto en un entorno empírico; Asegurar que el Product Owner conozca cómo ordenar el Facilitar los eventos (Sprint Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective) de Scrum según se requiera o necesite. Scrum Team: Consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de producto “Terminado”, que potencialmente se pueda poner en producción, al final de cada Sprint; Solo los miembros del Scrum Team participan en la creación del Incremento; Son auto-organizados. Nadie indica al Scrum Team cómo convertir elementos de la Lista del Producto en Incrementos de funcionalidad potencialmente desplegables; Son multifuncionales, contando como equipo con todas las habilidades necesarias para crear un Incremento de producto; Scrum no reconoce títulos para los miembros de un Scrum Team; Scrum no reconoce sub-equipos en los equipos de desarrollo; Usuarios o clientes: beneficiarios finales del producto, son los que viendo el progreso pueden aportar ideas, sugerencias o necesidades (feedback). Stakeholders: representan los patrocinadores del proyecto. Usuarios: representa los usuarios finales. Workproducts: El Product Backlog; El Sprint Backlog; El gráfico del Sprint Backlog. Product Backlog: Incluye una lista de todos los “items” concebibles del sistema, priorizados y solo modificado por el Product Owner; Es una lista maestra de toda la funcionalidad deseada en el producto; Incluye estimados (en horas hombre de esfuerzo) de los “items”, refinadas una vez que los miembros del equipo se comprometen.Sprint Backlog: lista de tareas que el Scrum Team obtenida a base de PB se compromete a hacer para el Sprint actual; las tareas Son tomadas por los miembros del equipo del modo que les parezca oportuno nunca asignadas; Se actualiza diariamente por cada miembro o por algún responsable común; el equipo selecciona los items y el tamaño del Sprint Backlog; definir el estimado diario de horas restantes para cada tarea; Sprint Backlog graph: es un resumen visual de la estimación de tiempo restante de las tareas del Sprint Backlog (el dato del proyecto más crítico).Pre-juego Planeación y montaje: Todos los stakeholder pueden contribuir para crear una lista de características, UC, extensiones, defectos, etc. y registrar en el Product Backlog; Se designa un Product Owner y las solicitudes se hacen a través del mismo; Se identifica el Release Backlog, un subconjunto del Product Backlog que definirá al siguiente producto operacional; Spint: El trabajo generalmente se organiza en iteraciones de 30 días de calendario; Se da potencia al equipo con autorización y recursos de tal forma que caminen a su ritmo y resuelvan sus problemas. Errores comunes y malos entendidos: No ser equipo auto-dirigido; los administradores o el Scrum Manager dirigen u organizan el equipo; No actualizar diariamente el Sprint Backlog; Agregar nuevo trabajo individual o a la iteración; El Product Owner no se involucra o no decide; No hay Sprint Review; Muchos masters; La documentación es mala; Scrum meetings muy largas o no enfocadas; La iteración no termina en un producto parcial integrado y probado; Planeación predictiva. Planeación tipo PERT.