Procesos Internos de Desarrollo¶

Workflows y procesos del equipo de desarrollo del Sistema A3 de A Terceros Inmobiliaria.

Ciclo de Desarrollo¶

1. Sprint Planning¶

Frecuencia: Cada 2 semanas (bi-semanal) Duración: 1-2 horas Participantes: Todo el equipo de desarrollo + Product Owner Responsable: Product Owner + Tech Lead

Agenda: 1. Review del sprint anterior 2. Presentación de nuevos tickets/features en backlog 3. Estimación de tareas (story points) 4. Asignación de tareas a desarrolladores 5. Definir goal del sprint

Herramienta: [Jira/Trello/etc.]

2. Development¶

Workflow: 1. Ticket asignado en planning o por Tech Lead 2. Desarrollador mueve ticket a "In Progress" 3. Crea branch desde master: feature/TICKET-123-descripcion 4. Implementa cambios siguiendo estándares 5. Escribe tests (guía de testing) 6. Ejecuta tests localmente 7. Commit y push a GitHub 8. Abre Pull Request

Prioridades: - P0 (Crítico): Sistema caído, afecta a todos los usuarios - SLA: 2 horas - P1 (Alto): Feature principal afectada - SLA: 1 día - P2 (Medio): Funcionalidad secundaria - SLA: 1 semana - P3 (Bajo): Nice-to-have, mejoras - SLA: Backlog

3. Code Review¶

Ver guía completa de PRs.

Proceso: 1. Desarrollador abre PR 2. Asigna reviewer según módulo (ver tabla de reviewers) 3. Reviewer revisa en max 24h hábiles 4. Feedback y cambios solicitados 5. Desarrollador implementa cambios 6. Re-review 7. Aprobación (mínimo 1 reviewer)

SLA: 24 horas hábiles para review inicial

4. QA y Testing¶

Ambientes: - Local: Desarrollo en máquina del desarrollador - Staging: [URL] - Para QA antes de producción - Producción: [URL] - Ambiente live

Proceso QA: 1. PR mergeado a master 2. Deploy automático a Staging 3. QA manual del equipo de QA (si existe) o desarrollador 4. Si pasa QA → Aprobado para producción 5. Si falla QA → Crear bug ticket, volver a desarrollo

Responsable de QA: [QA Lead o equipo] (si no existe, el mismo desarrollador valida)

5. Deployment¶

Ver detalles en guía de PRs - sección deployment.

Proceso: 1. PR aprobado y mergeado a master 2. CI/CD ejecuta tests (GitHub Actions) 3. Deploy automático a Staging 4. QA en staging 5. Deploy manual a Producción (ejecutado por DevOps)

Responsable: [DevOps Lead - nombre]

Horarios permitidos (Producción): - Lunes a Jueves: 10:00 AM - 4:00 PM - Viernes: Solo hotfixes críticos - Fines de semana: Solo emergencias

Notificaciones: - Deploys automáticos a staging aparecen en #sistema-a3-deploys - Deploys a producción requieren anuncio manual en #sistema-a3-deploys

Ceremonias del Equipo¶

Daily Standup¶

Frecuencia: Lunes, Miércoles, Viernes Hora: 9:00 AM Duración: 15 minutos máximo Formato: Presencial o por Slack/Zoom

Cada persona comparte: 1. ¿Qué hice desde el último standup? 2. ¿Qué voy a hacer hoy/hasta el próximo standup? 3. ¿Tengo algún blocker?

Reglas: - Máximo 2 minutos por persona - Solo blockers críticos se discuten (lo demás offline) - No es reunión de reporte a managers, es sync del equipo

Sprint Retrospectiva¶

Frecuencia: Cada 2 semanas (al final del sprint) Duración: 30-45 minutos Participantes: Todo el equipo de desarrollo

Agenda: 1. Qué salió bien en el sprint 2. Qué salió mal o puede mejorar 3. Acción items para el próximo sprint

Formato: Start/Stop/Continue

Nota: Es espacio seguro para feedback honesto. Lo que se dice en retro, se queda en retro (salvo action items acordados).

Tech Sync¶

Frecuencia: Semanal (Martes) Hora: 2:00 PM Duración: 30 minutos Participantes: Solo equipo técnico (sin PO)

Agenda: - Discusiones técnicas profundas - Decisiones de arquitectura - Tech debt - Tooling y mejoras de proceso - Compartir aprendizajes técnicos

Comunicación¶

Reportar Bugs¶

En Desarrollo (bugs nuevos encontrados durante desarrollo)¶

Crear issue en GitHub con template "Bug Report"
Etiquetar con bug y prioridad (P0-P3)
Asignar a Tech Lead o dejar sin asignar para planning
Mencionar en #dev-sistema-a3 si es urgente

En Producción (bugs reportados por usuarios)¶

Crítico (P0 - Sistema caído o feature principal rota):
Notificar inmediatamente en #sistema-a3-urgente
Mencionar a @tech-lead y @devops
Crear ticket en sistema de incidencias
Iniciar hotfix inmediatamente
No crítico (P1-P3):
Crear ticket en GitHub
Notificar en #dev-sistema-a3
Se priorizará en siguiente planning

Proponer Nuevas Features¶

Proceso:

Discusión inicial con Product Owner [nombre]
Explica el problema que resuelve
Propón solución high-level
Obtén feedback preliminar
Si es cambio arquitectónico grande:
Crear RFC (Request for Comments)
Documento de diseño técnico
Presentar en Tech Sync
Obtener aprobación de Tech Lead
Presentar en Sprint Planning:
PO incluye en backlog
Equipo estima complejidad
Se prioriza vs otras features
Aprobación y asignación:
PO aprueba para development
Se asigna en planning o por Tech Lead

No implementes features sin aprobación de PO, aunque creas que son buena idea.

Solicitar Ayuda¶

Dudas Técnicas¶

Primero: Busca en docs, código existente, Google (max 30 min atascado)
Segundo: Pregunta en #dev-sistema-a3
Describe el problema claramente
Qué has intentado
Error específico (con logs/stack trace)
Tercero: Si es muy urgente, DM a tu mentor o senior dev

Dudas de Negocio/Producto¶

Procesos del negocio: Contactar al stakeholder del departamento
Ventas: [contacto]
RH: [contacto]
Finanzas: [contacto]
Prioridades o requerimientos: Product Owner [nombre]

Problemas de Infraestructura¶

Accesos, permisos: IT Support [email/extensión]
Heroku, deployment: DevOps [contacto]
Base de datos: DBA o DevOps [contacto]

SLA de Resolución¶

Tiempos esperados de resolución según prioridad:

Prioridad	Descripción	SLA de Resolución	Ejemplo
P0	Sistema caído, afecta a todos	2 horas	Base de datos inaccesible
P1	Feature principal rota, afecta a muchos usuarios	1 día hábil	Login no funciona
P2	Funcionalidad secundaria afectada	1 semana	Reporte específico no se genera
P3	Nice-to-have, mejoras	Backlog	Mejorar UX de un formulario

Nota: SLA de resolución es tiempo desde que se detecta hasta que se despliega el fix a producción, no solo hasta que se abre el ticket.

Escalación de Problemas¶

Cuando Escalar¶

Escala a Tech Lead cuando: - Llevas >48h bloqueado sin solución - PR lleva >48h sin review - Hay conflicto técnico entre desarrolladores - Necesitas decisión arquitectónica importante - Problema de producción P0/P1

Cómo Escalar¶

Slack: Mensaje en #dev-sistema-a3 mencionando @tech-lead
Email: Si no hay respuesta en Slack en 2 horas (solo para urgentes)
Llamada/WhatsApp: Solo para P0 críticos fuera de horario laboral

Roles y Responsabilidades¶

Tech Lead¶

Decisiones arquitectónicas
Mentorship de desarrolladores
Code reviews de cambios complejos
Manejo de escalaciones
Coordinación con DevOps y PO

Contacto: [nombre] - [email/slack]

Product Owner¶

Definir prioridades de features
Backlog management
Aceptar o rechazar features
Comunicación con stakeholders del negocio

Contacto: [nombre] - [email/slack]

DevOps Lead¶

Infraestructura (Heroku, AWS, BD)
Deployments a producción
Monitoring y alertas
Manejo de incidentes de infraestructura

Contacto: [nombre] - [email/slack]

Desarrolladores Senior¶

Desarrollo de features complejas
Code reviews
Mentorship de juniors
Decisiones técnicas dentro de su módulo

Desarrolladores Mid/Junior¶

Desarrollo de features asignadas
Code reviews (también!)
Aprender y crecer técnicamente
Pedir ayuda cuando sea necesario

Métricas del Equipo¶

Tracked en Planning/Retros¶

Velocity: Story points completados por sprint
Cycle time: Tiempo desde "In Progress" hasta "Deployed"
Lead time: Tiempo desde creación de ticket hasta deployed
Bug rate: Bugs encontrados en producción post-deploy

Objetivos (aprox)¶

Velocity estable entre sprints (± 20%)
Cycle time < 5 días para features normales
Bug rate < 10% de tickets deployados

Nota: Estas métricas son para mejorar el proceso, no para evaluar desarrolladores individuales.

Mejora Continua¶

Documentación¶

Cuando encuentres algo no documentado: 1. Documéntalo tú mismo (PR a /docs) 2. O crea ticket para que alguien más lo documente

Tech Debt¶

Dedicar ~20% del tiempo de sprint a tech debt
Proponer tech debt en Tech Sync
Tech Lead prioriza qué tech debt abordar

Postmortems¶

Para incidentes P0/P1 en producción: 1. Resolver el incidente primero 2. Escribir postmortem (template en GitHub) 3. Identificar root cause 4. Definir action items para prevenir recurrencia 5. Presentar en próxima retro

Ver también: - Guía de Desarrollo - Pull Requests - Estándares de Código