Haciendo que el Proceso Funcione (Scrum/Kanban/SAFe)
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.
Receta
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:
- Las retrospectivas se sienten repetitivas sin cambios
- Las historias completadas carecen de despliegue en producción
- La sobrecarga de SAFe excede el valor
- Tablero Kanban con WIP infinito
Ejemplo de Trabajo
## 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:
- DoD explícito para la preparación de producción en Python
- Los límites de WIP evitan la acumulación de revisiones
- SAFe reducido a las entradas de planificación que importan
- "Hecho" permite la producción detrás de una bandera con criterios documentados
Profundización
Cómo Funciona
- Bucles de retroalimentación - Bucles más cortos superan procesos más pesados.
- Límites de WIP - Eficiencia del flujo; menos cambios de contexto en migraciones asíncronas.
- Contrato DoD - PM e ingeniería acuerdan qué significa "hecho" antes del inicio del sprint.
- Experimentos de retrospectiva - Un cambio por retrospectiva, medido el próximo ciclo.
- Ajuste del marco - Kanban para operaciones pesadas; Scrum para cadencia de características; SAFe solo donde la coordinación de cartera es real.
Chequeo de Salud de la Ceremonia
| 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 |
Notas de Python
## 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.Trampas
- Puntos como métrica de productividad - Manipulación y estrés. Solución: Usar rendimiento y CFR para la salud.
- DoD sin despliegue - "Hecho" en Jira, no en producción. Solución: Mínimo en staging; producción detrás de una bandera es aceptable si está documentado.
- SAFe en todas las capas - Impuesto sin necesidad de cartera. Solución: Mantener las entradas de PI; eliminar rituales ART no utilizados.
- Omitir acciones de retrospectiva - Cinismo. Solución: Un propietario de experimento nombrado en el ticket.
- PM como despachador de tareas - Ingenieros pasivos. Solución: Los ingenieros aportan el desglose y los riesgos en la planificación.
Alternativas
| 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 |
Preguntas Frecuentes
¿Cuánto tiempo debe durar la planificación?
90 min para un sprint de dos semanas con especificaciones preparadas; cancelar si el backlog no está preparado.
¿Velocidad para equipos de Python?
Usar promedio móvil; separar opcionalmente el rendimiento de plataforma frente a características.
¿SAFe en una empresa pequeña?
A menudo excesivo; tomar prestado solo el calendario de planificación PI si las dependencias entre equipos son reales.
¿Historias arrastradas?
Reestimar; dividir; investigar el sobrecompromiso sistémico en la retrospectiva.
¿DoD para hotfixes?
Reducido: prueba + ruta de reversión + monitorización post-despliegue; ticket de seguimiento de DoD completo.
¿Ceremonias remotas?
Comentarios asíncronos de preparación; planificación/revisión en vivo; demostraciones grabadas.
¿Interrupción de errores en la capacidad?
Planificar un búfer del 15-20% o una columna de interrupción explícita en Kanban.
¿Trabajo de ML en sprints?
Historias de "spike" para incógnitas de datos; "hecho" incluye el umbral de la métrica de evaluación.
¿Quién decide el cambio de proceso?
Experimento de retrospectiva del equipo; el EM elimina los bloqueos organizacionales.
¿Métricas en la retrospectiva?
CFR, latencia de revisión, antigüedad de WIP: un gráfico supera los debates de opinión.
Relacionado
- Estimación y Riesgo - entrada de planificación
- Comunicación con Stakeholders - demostraciones de revisión
- Mejores Prácticas de Entrega - DoD de despliegue
- Cultura de Revisión de Código - revisión de WIP
- Métricas DORA - datos de retrospectiva
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+.