EGA Futura » Capacitación y Soporte
El sprint es la unidad de tiempo de Scrum, y todo lo demás del marco ocurre dentro de él.
Dura un mes o menos, y esa duración se elige una vez y se sostiene, en lugar de decidirse trabajo por trabajo.
Apenas termina uno, empieza el siguiente, sin pausas intermedias, y de esa cadencia continua viene la mayor parte de su valor.
En un proyecto tradicional, cuando el trabajo no entra en el plazo, se corre el plazo.
En un sprint ocurre lo contrario: el plazo es lo único fijo y lo que se ajusta es cuánto entra adentro.
Esa inversión obliga a una conversación incómoda pero útil, que es decidir qué queda afuera.
Y produce un efecto secundario valioso: como los sprints duran siempre lo mismo, se pueden comparar entre sí.
Cada sprint tiene un objetivo único, que explica por qué este período de trabajo vale la pena.
Ese objetivo le da coherencia a un conjunto de tareas que de otro modo sería una lista suelta.
También cumple una función práctica durante el sprint: ninguna decisión del período debería poner en riesgo ese objetivo.
El alcance concreto, en cambio, sí puede aclararse y renegociarse a medida que el equipo aprende, siempre que el objetivo quede en pie.
La planificación abre el sprint y responde tres preguntas: por qué es valioso, qué se puede hacer y cómo se va a hacer.
El Daily Scrum es una reunión diaria de quince minutos donde el equipo revisa su avance hacia el objetivo y ajusta el plan del día.
La revisión cierra el sprint mostrando el incremento a quienes tienen interés en él, y recogiendo su devolución.
La retrospectiva es el último evento y mira hacia adentro: qué funcionó en la forma de trabajar y qué conviene cambiar.
Los cuatro tienen tiempo máximo, que para un sprint de un mes es de ocho horas la planificación, cuatro la revisión y tres la retrospectiva, y se acorta en proporción cuando el sprint es más breve.
El resultado de un sprint no es un avance parcial sino un incremento utilizable.
Utilizable quiere decir que cumple con la definición de terminado acordada por el equipo, no que esté casi listo.
Esa exigencia es lo que evita la acumulación de trabajo a medio hacer, que es la deuda más cara de un proyecto.
El límite superior es un mes, y la razón es de control del riesgo: cuanto más largo el ciclo, más tarde se descubre un rumbo equivocado.
Los sprints más cortos dan devolución más frecuente, a cambio de más tiempo dedicado a los eventos.
Los más largos reducen esa carga pero acumulan más incertidumbre entre una revisión y la siguiente.
Un sprint puede cancelarse antes de tiempo, y ocurre en un solo caso: cuando su objetivo quedó obsoleto.
La autoridad para cancelarlo es exclusiva del Product Owner, la persona responsable de maximizar el valor del producto.
Es una situación poco frecuente, porque un período tan corto rara vez alcanza para que el contexto cambie tanto.
Muchos equipos miden cuánto trabajo completan por sprint y llaman velocidad a ese número.
Conviene saber que es una práctica extendida y no una regla del marco, así que su definición varía de un equipo a otro.
Su uso sano es proyectar hacia adentro, y su uso dañino es comparar equipos entre sí, porque cada uno estima con su propia escala.
El Proyecto declara con qué metodología se conduce, mediante un campo de lista de selección.
Las opciones son Cascada, Scrum, Kanban e Híbrida, y esa elección es la que ubica al proyecto en un enfoque o en otro.
Elegir Scrum o Kanban es lo que le da sentido a las piezas que se describen abajo.
El Epic es un registro propio, con su nombre, su descripción, su Estado y su Prioridad.
Cada Tarea de proyecto puede apuntar a un Epic, y así el trabajo queda agrupado por objetivo y no solo por proyecto.
Esa agrupación es la que permite mirar un conjunto de tareas como una unidad con valor propio.
Las tareas se relacionan entre sí con motivos explícitos, y son siete.
Están Bloqueada por, Depende de y Requiere, que expresan que algo no puede arrancar todavía.
Está Precede, que expresa el orden, y Parte de, que expresa pertenencia a un trabajo mayor.
Y están Relacionada a y Duplicada de, para los vínculos que no son de secuencia.
Ese mapa de dependencias es exactamente lo que se necesita para decidir qué puede entrar en un período corto de trabajo.
La Tarea de proyecto tiene dos tipos de registro, y cada uno expone su propio juego de estados.
El tipo estándar ofrece Planificada, En progreso y Completada, que es el recorrido mínimo de cualquier tablero.
El tipo de implementación de plataforma ofrece un recorrido más largo: Planificado, Diseño, Desarrollo, Testing, Deploy, Completado y Descartada.
Ese segundo juego se corresponde con las columnas típicas de un tablero de desarrollo.
Cada tarea guarda Horas estimadas y Horas reales, y el sistema calcula el Desvío de horas entre ambas.
Esa comparación acumulada es la base sobre la que un equipo puede afinar sus estimaciones de un período al siguiente.
La Prioridad ordena el trabajo con cuatro valores, Crítica, Alta, Normal y Baja.
Y la casilla Tarea bloqueada, junto con la Razón del bloqueo, deja registrado lo que impide avanzar, que es la información que alimenta cualquier reunión diaria.
Un mes o menos, y la duración elegida se mantiene constante entre un sprint y el siguiente.
Las duraciones de una, dos y tres semanas son las más usadas, y dos semanas es la más frecuente.
El sprint termina igual, porque la fecha no se mueve.
Lo que no se completó vuelve al conjunto de trabajo pendiente y se vuelve a evaluar en la planificación del siguiente.
El alcance puede aclararse y renegociarse a medida que el equipo aprende, pero sin poner en riesgo el objetivo del sprint.
Agregar por agregar es la forma más rápida de que el objetivo deje de cumplirse y el ritmo se pierda.
En la práctica se usan como sinónimos, pero sprint es el nombre específico de Scrum.
Otros enfoques ágiles usan iteración como término general, sin las reglas particulares que Scrum define para su período.
La metodología del proyecto se guarda en EGAFutura__Proyecto__c, campo EGAFutura__Methodology__c, de tipo Picklist y sin valor por omisión.
Ahí hay una trampa que conviene tener presente: dos de las cuatro etiquetas no coinciden con el valor almacenado.
La etiqueta Cascada guarda Waterfall y la etiqueta Híbrida guarda Hybrid, mientras que Scrum y Kanban sí coinciden con su valor.
Cualquier filtro por API o por Apex tiene que escribir Waterfall y Hybrid, no las etiquetas en español.
Es EGAFutura__Epic__c, con Name de tipo Text de 80 y EGAFutura__Descripcion__c de tipo Rich Text.
Sus dos listas de selección también guardan en inglés: EGAFutura__Status__c muestra Nuevo, Activo, Completado y Cancelado, y almacena New, Active, Completed y Canceled, con New por omisión.
Conviene notar que Canceled va con una sola ele, que es la grafía que espera el filtro.
El campo EGAFutura__Priority__c muestra Alta, Media y Baja, y almacena High, Medium y Low.
El vínculo con el trabajo está del lado de la tarea, en EGAFutura__Proyecto_Tarea_proyecto__c.EGAFutura__Epic__c, un Lookup a Epic.
Viven en EGAFutura__ProjectTaskRelation__c, un objeto de unión con EGAFutura__ParentProjectTask__c en Master-Detail y EGAFutura__RelatedProjectTask__c como Lookup obligatorio.
El motivo es EGAFutura__RelationReason__c, y sus siete valores también difieren de la etiqueta: Blocked By, Related To, Duplicate Of, Requires, Part Of, Depends On y Precedes.
La tarea tiene dos tipos de registro, Standard y PlatformImplementation, y sus juegos de estados no se superponen.
En Standard los tres valores coinciden con su etiqueta: Planificada, En progreso y Completada, con Planificada por omisión.
En PlatformImplementation los valores almacenados son Planned, Design, Development, Testing, Deploy, Completed y Discarded, con Planned por omisión.
La confusión típica es entre Planificada y Planificado, que se distinguen a la vista solo por la vocal final y guardan valores completamente distintos.
El indicador visual es EGAFutura__StatusIndicator__c, una fórmula de texto, y el vencimiento es EGAFutura__IsOverdue__c, una fórmula de casilla.
El bloqueo se lee con EGAFutura__Tarea_bloqueada__c y EGAFutura__Razon_bloqueo__c.
Los tres campos de esfuerzo son EGAFutura__Horas_estimadas__c, EGAFutura__ActualHours__c y la fórmula EGAFutura__HoursVariance__c.