Diferencia entre revisiones de «Sprint De Release»
(Página nueva: En Scrum, cuando el Dueño Del Producto y los Stakeholders identifican que existe suficiente funcionalidad en el sistema para brindar valor inmediato al negocio, pueden elegir...) |
|||
| Línea 1: | Línea 1: | ||
| + | [[Category:Scrum]] | ||
En [[Scrum]], cuando el [[Dueño Del Producto]] y los Stakeholders identifican que existe suficiente funcionalidad en el sistema para brindar valor inmediato al negocio, pueden elegir poner esta funcionalidad en producción. Usualmente se realiza un "Sprint de Release" que contiene todos las tareas en el [[Backlog Del Sprint]] para poner el sistema en producción. Estas tareas no deberían contener funcionalidad adicional, a menos que incluyan: | En [[Scrum]], cuando el [[Dueño Del Producto]] y los Stakeholders identifican que existe suficiente funcionalidad en el sistema para brindar valor inmediato al negocio, pueden elegir poner esta funcionalidad en producción. Usualmente se realiza un "Sprint de Release" que contiene todos las tareas en el [[Backlog Del Sprint]] para poner el sistema en producción. Estas tareas no deberían contener funcionalidad adicional, a menos que incluyan: | ||
* Instalar el código en el entorno productivo | * Instalar el código en el entorno productivo | ||
Revisión actual del 19:02 31 jul 2008
En Scrum, cuando el Dueño Del Producto y los Stakeholders identifican que existe suficiente funcionalidad en el sistema para brindar valor inmediato al negocio, pueden elegir poner esta funcionalidad en producción. Usualmente se realiza un "Sprint de Release" que contiene todos las tareas en el Backlog Del Sprint para poner el sistema en producción. Estas tareas no deberían contener funcionalidad adicional, a menos que incluyan:
- Instalar el código en el entorno productivo
- Población de datos productivos
- Configurar la administración, sistemas de operaciones y procesos
- Entrenamiento y capacitación al staff de soporte
- Planificación de contingencia y vuelta atrás
Un Sprint de Release no debería ser más largo que un Sprint normal, sin importar cuántos Sprints estén agrupados en el release. Es una buena práctica asegurarse seguido que el sistema esté en un estado tal que un sólo Sprint alcance para ponerlo en producción. Si la respuesta es negativa, entonces el equipo debería mejorar la calidad del código existente y verificar que su concepto de "Terminado" es lo suficientemente completo como para calidad productiva.
