1. Colaboración y Cultura de Desarrollo

Prácticas y patrones para equipos de desarrollo efectivos, colaborativos y sostenibles.

1.1 🤝 Colaboración en Desarrollo

Qué: Trabajar juntos efectivamente para crear mejor software.

Por qué: Software complejo requiere múltiples perspectivas. Colaboración > suma individual.

Quién: Todo el equipo de desarrollo.

Cuándo: Diario, en todas las fases del desarrollo.

Esfuerzo: Inversión en comunicación y coordinación que multiplica productividad.

1.2 👥 Pair Programming

Qué: Dos desarrolladores trabajando juntos en la misma máquina/pantalla.

Por qué: Menos bugs, mejor diseño, conocimiento compartido, onboarding efectivo.

Cuándo: Código complejo, onboarding, debugging crítico, aprendizaje.

Roles:

Driver: Escribe código, foco en táctico
Navigator: Piensa estratégico, revisa, sugiere

Rotación: Cada 30 minutos cambiar roles.

Tipos:

Estilo	Qué	Cuándo
Driver-Navigator	Clásico: uno escribe, otro guía	General
Ping Pong	TDD: uno escribe test, otro implementa, alternan	TDD estricto
Strong-Style	Navigator dicta ideas, Driver implementa sin cuestionar	Enseñar patterns

Beneficios:

15% más lento escribir código
15% menos bugs
Mejor diseño
Knowledge transfer

Herramientas remotas: VS Code Live Share, Tuple, Pop

1.3 👨‍👩‍👧‍👦 Mob Programming

Qué: Todo el equipo (3-8 personas) trabajando en el mismo problema simultáneamente.

Por qué: Decisiones colaborativas, problemas complejos, alineación total.

Cuándo: Arquitectura crítica, decisiones importantes, spikes, workshops.

Formato:

Typist/Driver: Escribe sin decidir (15 min rotación)
Mob: Discute y decide qué escribir
Facilitador: Mantiene proceso, timekeeper

Proceso:

Problema claramente definido
Rotación cada 15 min con timer
Commits frecuentes (WIP OK)
Breaks cada 90 min

Cuándo NO usar:

Tareas simples, repetitivas
Features independientes
Solo para llenar tiempo

Ventajas:

Decisiones de calidad inmediata
Cero handoffs
Todo el equipo con contexto completo

1.4 🔍 Code Review

Qué: Revisión sistemática de código por pares antes de merge.

Por qué: Detectar bugs, mejorar diseño, compartir conocimiento, mantener estándares.

Cuándo: Todo código antes de merge a main (sin excepciones).

1.4.1 Best Practices - Autor

Práctica	Por qué	Cómo
PRs pequeños	Más rápido revisar, menos errores	<400 líneas, 1 concepto
Descripción clara	Contexto para reviewer	Qué, por qué, cómo testear
Self-review primero	Catch obvious issues	Revisar diff antes de pedir review
Tests incluidos	Validación	Tests pasan, coverage OK
Screenshots/GIFs	Para cambios UI	Mostrar antes/después

1.4.2 Best Practices - Reviewer

Práctica	Por qué	Cómo
Revisar pronto	No bloquear	<24 horas, idealmente <4h
Ser constructivo	Ambiente de confianza	"¿Consideraste X?" vs "Esto está mal"
Explicar el por qué	Educativo	"Esto podría causar N+1 queries"
Distinguir niveles	Priorización	"Nit:" menor, "Blocker:" crítico
Aprobar con comentarios	No re-review trivial	Si cambios menores, aprobar + sugerencias

1.4.3 Checklist Reviewer

[ ] Código cumple requisitos
[ ] Lógica correcta, sin bugs obvios
[ ] Tests adecuados, pasando
[ ] Sin código comentado/debug
[ ] Nombres claros y descriptivos
[ ] Sin complejidad innecesaria
[ ] Performance aceptable
[ ] Seguridad considerada
[ ] Documentación actualizada

Herramientas: GitHub PR, GitLab MR, Gerrit

1.5 📋 Blameless Post-Mortems

Qué: Análisis retrospectivo de incident sin culpar individuos.

Por qué: Aprender de fallos, mejorar sistemas, cultura psicológicamente segura.

Cuándo: Después de cada outage/incident significativo.

Estructura:

1.5.1 1. Timeline de Eventos

14:23 - Deploy v2.3.4 a producción
14:31 - Alertas de error rate 15%
14:35 - Equipo notificado vía PagerDuty
14:42 - Identificado problema en migration
14:50 - Rollback iniciado
15:05 - Servicio restaurado

1.5.2 2. Impacto

Usuarios afectados: 5,000
Duración: 42 minutos
Revenue perdido: $2,500
Reputación: 23 quejas en redes

1.5.3 3. Causa Raíz (5 Porqués)

Migration falló
Script no validó datos existentes
No había test para ese edge case
No testeamos en staging con datos prod-like
Causa raíz: Proceso de migrations sin validación obligatoria

1.5.4 4. Qué funcionó bien

Monitoring detectó rápido (8 min)
Comunicación efectiva en Slack
Rollback funcionó correctamente

1.5.5 5. Action Items

Acción	Owner	Deadline	Status
Agregar validación migrations	@alice	2015	Done ✅
Actualizar runbook rollback	@bob	2010	Done ✅
Setup staging con prod data anonymized	@carol	2020	In Progress

Principio clave: "We blame systems, not people." Foco en cómo prevenir, no quién causó.

1.6 🔄 Retrospectivas

Qué: Reunión regular para reflexionar sobre proceso y mejorar.

Por qué: Mejora continua, equipo más feliz y productivo.

Cuándo: Cada sprint (2 semanas), después de milestones.

Formato:

1.6.1 1. Set the Stage (5 min)

Check-in: "Una palabra que describe tu sprint"
Recordar Prime Directive: "Todos hicieron lo mejor con lo que sabían"

1.6.2 2. Gather Data (15 min)

1.6.2.1 Técnica: Start-Stop-Continue

Start	Stop	Continue
Daily standups async	Meetings de 2h	Pair programming viernes
Code reviews en <4h	Interrupciones constantes	Pizza Fridays 🍕

1.6.2.2 Alternativa: Mad-Sad-Glad

😡 Mad: Frustraciones
😢 Sad: Decepciones
😊 Glad: Celebraciones

1.6.3 3. Generate Insights (15 min)

Agrupar temas similares
Votar (3 votos por persona)
Identificar patrones

1.6.4 4. Decide What To Do (15 min)

Elegir 1-3 acciones concretas
Asignar owner
Definir "done"

1.6.5 5. Close (5 min)

Resumen de acciones
Appreciation shoutouts

Facilitación:

Rotar facilitador
Timeboxear estricto
Ambiente seguro (no managers si coarta)
Seguir actions del retro anterior

1.7 🎯 Working Agreements

Qué: Acuerdos explícitos de cómo trabaja el equipo.

Por qué: Expectativas claras, menos fricción, autonomía.

Cuándo: Al formar equipo, revisar cada 6 meses.

Ejemplos:

1.7.1 Comunicación

Slack: responder en <4h horas hábiles
Urgent: llamar directamente
Updates asíncronos en daily doc, no meetings
No mensajes fuera 9-18h salvo emergencia

1.7.2 Code

Main branch siempre deployable
PR aprobado en <24h
Coverage >80% en features nuevas
Breaking changes requieren RFC

1.7.3 Meetings

No meetings antes 10am
Máximo 2h focus time protegido (9-11am)
Todas las reuniones con agenda
Default 25/50 min (no 30/60)

1.7.4 On-call

Rotación semanal
Handoff Lunes 10am
Runbooks actualizados
Post-mortem dentro 48h de incident

1.8 🗣️ Comunicación Efectiva

1.8.1 Async-First

Por qué: Respeta tiempo, permite deep work, inclusivo para time zones.

Cómo:

Documentar decisiones por escrito
Updates en Slack/Notion vs meetings
Grabar meetings para ausentes
Threads organizados por tema

1.8.2 RFC (Request for Comments)

Qué: Documento para proponer cambios técnicos significativos.