Kaizen y 5S, aplicados al desarrollo de software

Respuesta Es una palabra japonesa formada por "kai" (cambio) y "zen" (bueno), por lo que su significado literal es "cambio para mejorar". Nació en la industria japonesa de posguerra y se consolidó como filosofía de gestión en Toyota.

Respuesta Una mejora Kaizen es pequeña, continua y acumulativa: se prueba a baja escala, se mide y solo si funciona se adopta como estándar, con participación de todo el equipo. Una reforma radical busca un cambio grande y de una sola vez, normalmente impulsado desde la dirección, sin ese proceso progresivo de prueba y verificación.

Respuesta Toda la organización. La guía señala que la mejora es responsabilidad de todo el equipo, no solo de un líder o de la dirección.

Justificación Es al contrario: uno de los principios clave del Kaizen es que los problemas se hacen visibles, no se ocultan, porque se consideran oportunidades de mejora.

Respuesta Por ejemplo: ningún proceso es perfecto, siempre existe una forma de mejorarlo; y se prioriza el cambio pequeño y verificable sobre el rediseño total. También son válidos: que la mejora es tarea de todo el equipo, que los problemas se hacen visibles, o que la disciplina sostiene la mejora en el tiempo.

Respuesta Porque cada S se apoya en la anterior: no tiene sentido ordenar (Seiton) algo que aún no se clasificó (Seiri), ni limpiar (Seiso) un espacio que no está ordenado, ni estandarizar (Seiketsu) una práctica que no se limpió ni ordenó antes. La disciplina (Shitsuke) solo puede sostenerse cuando ya existe una norma establecida.

Justificación Shitsuke es la S de "Disciplina": significa sostener el hábito de las otras 4S en el tiempo, sin necesidad de supervisión. No se limita a la limpieza física, que corresponde más bien a Seiso.

Respuesta El repositorio, el código, las pruebas y el flujo de entrega del equipo. Mientras en una fábrica las 5S ordenan herramientas y espacios físicos, en desarrollo ese mismo orden se aplica sobre estos elementos digitales.

Respuesta Revisar el repositorio periódicamente para eliminar código muerto, ramas que ya nadie usa y dependencias obsoletas que solo generan ruido y ocupan espacio sin aportar valor.

Respuesta Ambas sostienen en el tiempo las buenas prácticas del equipo sin depender de un recordatorio constante del líder técnico. La integración continua y la revisión de código entre pares convierten la calidad en un hábito automático del equipo, que es justamente lo que representa Shitsuke.

Respuesta Por ejemplo: las retrospectivas cortas al cerrar cada sprint y las revisiones de código entre pares. También son válidas la refactorización incremental en lugar de reescrituras completas, o el seguimiento de métricas simples de calidad.

Respuesta El tiempo de compilación, la cobertura de pruebas y la cantidad de bugs reabiertos.

Ejemplo aplicado Un equipo detecta que su repositorio tiene 14 ramas sin fusionar desde hace más de 6 meses y una librería de fechas que ya no se usa desde que migraron a otra. En una sesión de 20 minutos al cierre del sprint, eliminan las ramas obsoletas, quitan la dependencia sin uso del package.json y documentan el motivo en el commit.

Ejemplo aplicado En lugar de mezclar componentes, servicios y pruebas en una sola carpeta, el equipo adopta una estructura fija: /src/components, /src/services, /tests. Cualquier persona nueva sabe, sin preguntar, dónde debe crear un archivo nuevo.

Ejemplo aplicado Durante una revisión, dos desarrolladores notan que la misma función de validación de correos está copiada en tres módulos distintos. La extraen a una sola utilidad compartida y eliminan las copias, reduciendo el riesgo de que una corrección se aplique en un lugar y se olvide en los otros.

Ejemplo aplicado El equipo configura un linter y un formateador que corren automáticamente antes de cada commit, y agrega una plantilla de pull request con una checklist ("¿tiene pruebas?", "¿actualiza la documentación?"). Así el estilo de código deja de depender de la memoria de cada persona.

Ejemplo aplicado Meses después de implementar las prácticas anteriores, nadie tiene que recordarle al equipo que revise su código o limpie ramas viejas: la integración continua rechaza automáticamente el código que no pasa las pruebas, y la limpieza del repositorio ya es parte natural del cierre de cada sprint.

Respuesta modelo Elijo el punto de Seiri: "¿Existen archivos, ramas o dependencias que ya nadie usa?". Lo aplicaría reservando un momento fijo, por ejemplo al cerrar cada sprint, para revisar el repositorio, eliminar ramas ya fusionadas, borrar dependencias que quedaron sin usarse tras algún cambio, y documentar por qué se eliminaron, de modo que el repositorio se mantenga liviano y comprensible para cualquier integrante nuevo.

Respuesta Por ejemplo: menor tiempo perdido buscando archivos, funciones o configuraciones; y una incorporación más rápida de nuevos integrantes al equipo. También son válidos: menos errores en producción por código limpio y bien probado, o una cultura de mejora sostenida en lugar de estar "apagando incendios".

Respuesta modelo Esa frase quiere decir que la calidad no se logra con un esfuerzo puntual, como ordenar el código una sola vez antes de una entrega, sino que se construye repitiendo buenas decisiones día a día hasta que se vuelven costumbre. Aplicado a mi formación como futuro profesional de TI, significa que revisar mi código, documentar lo que hago y aprender de mis errores no deberían ser acciones aisladas cuando "hay tiempo", sino parte natural de mi manera de trabajar, igual que las 5S proponen sostener el orden sin necesidad de que alguien más lo recuerde.