En ninguna de las guías de scrum hablan sobre un Sprint 0 (cero) pero es de las recomendaciones que he recibido de quienes nos han hecho coach en scrum.
Este sprint realmente no tiene ítemes de producto, corresponde a todas las actividades preparatorias para poder comenzar a ejecutar el proyecto, dentro de este sprint se pueden realizar cualquiera (o todas) de las actividades siguientes:
- Definir los releases y plan del producto (se puede emplear una técnica como el user story mapping)
- Definir la arquitectura base del producto sobre la cual se va a evolucionar.
- Definir las pruebas a realizar
- Definir los lineamientos gráficos del sistema (si aplica)
- Realizar todas las instalaciones en los diferentes ambientes (desarrollo, pruebas, pre-producción y producción)
- IDEs
- Servidores de aplicaciones
- motores de bases de datos
- Nota: Que todos los ambientes sean lo más similares entre sí posibles (sistemas operativos, versiones de productos, conectividad, etc)
- Preparar y configurar los repositorios de control de versiones
- Configurar los scripts para el servidor de integración continua de forma que logremos que una linea de codigo quede probado y desplegado en los respectivos ambientes
- Escribir el 'hola mundo" que logre pasar por:
- el repositorio del control de versiones
- probado por las diferentes pruebas definidas
- que en los diferentes servidores automáticamente quede:
- código validado con reglas automáticas
- compilado
- probado
- y desplegado en los diferentes ambientes
- Nota: Es como tender la carretera pavimentada para que las líneas de código pasen sin inconvenientes de inicio a fin.
- Escribir las historias de usuario para el primer planning. Posiblemente mostrarlas al equipo para que realice un primer acercamiento.
- Definir herramientas de gestión que utilizará el equipo
- Kanban
- Burndowns
- hojas de cálculo
- Definir la DoD (Defnition of Done( (Definición de Hecho/Realizado/Completado) para el proyecto
- Definir los criterios de liberación del producto / liberación de releases
- Aprobaciones
- historias completadas
- valor de negocio entregado
- Definir como se calculará el ROI del proyecto y/o el éxito del mismo
- Definir forma de puntuar las historias
- si con pivote funcional o,
- pivote de días ideales
- Definir estándares de codificación y documentación del código
- Definir documentación a emplear y como se va a actualizar en el proyecto
- Definir tamaño de los sprints
Suficientes tareas, ¿no cierto?
Unas recomendaciones:
- Cree Historias de Usuario Técnicas asociadas a cada una de las tareas definidas, y recuerde ponerle criterios de aceptación, de manera que se verifique que puede cumplirlas
- Realice estimaciones sobre las Historias de Usuario Técnicas, realice el "taskeo" (identifique las tareás)
- No olvide a scrum para este sprint:
- Defina la duración: Definir un timebox (tiempo definido fijo) para este sprint (consideraría 2 semanas suficientes, pero la casuística me impide afirmarlo categóricamente), con el objeto de no eternizarnos en la planeación y definición, cayendo en un antipatrón de la gerencia del proyectos llamado (parálisis por análisis o en inglés Analysis Paralysis)
- Realice el daily con todos los involucrados en este sprint
- Si es el Scrum Master, realice la debida gestión de impedimentnos y si es team member por favor notifíquelos
- Al final realicen review y retrospectiva, identifiquen las lecciones aprendidas y feliz comienzo del sprint 1.
Saludos ágiles y
hasta la próxima
No hay comentarios.:
Publicar un comentario