Busca en todas las páginas de la documentación
Los marcos ágiles son herramientas, no objetivos. Los equipos de Python adaptan capas de Scrum, Kanban o SAFe para que las ceremonias mejoren la retroalimentación, el WIP se mantenga razonable y la Definición de Hecho incluya pruebas, observabilidad y despliegues seguros, no teatro de puntos de historia.
Tarjeta de receta de referencia rápida, lista para copiar y pegar.
## Definición de Hecho (Servicio Python)
- [ ] Enlace a la especificación o RFC para trabajo M/L
- [ ] pytest en verde; cobertura en nuevas rutas
- [ ] Ruff + pyright limpios en paquetes tocados
- [ ] Registros estructurados / métricas para nuevos flujos
- [ ] Bandera de funcionalidad o reversión anotada en PR
- [ ] Desplegado en staging; humo documentado
- [ ] Notas de lanzamiento si es visible para el clienteCuándo usar esto:
## Cadencia del equipo (Scrum/Kanban híbrido)
**Planificación (quincenal, 90 min):** Capacidad = velocidad menos 20% de plataforma
**Diaria (15 min):** Solo bloqueos; discusiones profundas fuera de línea
**Revisión (quincenal):** Demo en staging + instantánea DORA
**Retrospectiva (quincenal):** Un elemento de acción experimental
**Kanban:** WIP máximo 3 por ingeniero; límites de columna en Revisión
**Capa SAFe (trimestral):** Entrada de planificación PI = documento de ingeniería de 1 página solamente
**Omitir:** resumen de métricas SAFe a nivel de equipo si no se usa# Ejemplo de automatización del tablero - vincular ticket al estado de despliegue
DONE_CRITERIA = {
"merged": False,
"staging_deploy": False,
"prod_behind_flag": True, # aceptable para características grandes
}Lo que esto demuestra:
| Ceremonia | Señal saludable | Señal poco saludable |
|---|---|---|
| Planificación | El compromiso coincide con la capacidad | Desbordamiento cada sprint |
| Diaria | Los bloqueos se resuelven en <24h | Informe de estado al gerente |
| Retrospectiva | Elemento de acción cerrado | Misma queja 3 veces |
| Revisión | Los interesados ven staging | Solo diapositivas, sin software |
## Regla de desbordamiento de sprint
Si la migración no está probada en staging a mitad de sprint, dividir la historia; no llevar DDL sin probar a la demostración.| Alternativa | Usar Cuándo | No Usar Cuándo |
|---|---|---|
| Kanban Puro | Pesado en soporte/operaciones | Lanzamientos de marketing fijos |
| Shape Up | Apuestas de seis semanas | Microservicios SLA continuos |
| Scrumban | Flujo mixto | El equipo necesita predictibilidad estricta del sprint |
| Sin sprints | Despliegue continuo maduro | Equipo nuevo que necesita ritmo |
90 min para un sprint de dos semanas con especificaciones preparadas; cancelar si el backlog no está preparado.
Usar promedio móvil; separar opcionalmente el rendimiento de plataforma frente a características.
A menudo excesivo; tomar prestado solo el calendario de planificación PI si las dependencias entre equipos son reales.
Reestimar; dividir; investigar el sobrecompromiso sistémico en la retrospectiva.
Reducido: prueba + ruta de reversión + monitorización post-despliegue; ticket de seguimiento de DoD completo.
Comentarios asíncronos de preparación; planificación/revisión en vivo; demostraciones grabadas.
Planificar un búfer del 15-20% o una columna de interrupción explícita en Kanban.
Historias de "spike" para incógnitas de datos; "hecho" incluye el umbral de la métrica de evaluación.
Experimento de retrospectiva del equipo; el EM elimina los bloqueos organizacionales.
CFR, latencia de revisión, antigüedad de WIP: un gráfico supera los debates de opinión.
Versiones de Stack: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.
Revisado por Chris St. John·Última actualización: 16 jul 2026