Después de un periodo bastante amplio, por fin encontré el tiempo para terminar esta publicación sobre un tema me parece fascinante tanto por su utilidad en la industria del software como por su complejidad relativa al contexto en el que se implementa, así como de los actores que intervienen. Se trata del proceso de RCA.
El Análisis de Causa Raíz o RCA (por sus siglas en inglés) es un proceso utilizado en Six Sigma que permite a un equipo comprender de la manera más completa posible un problema. En el caso de Ingeniería de Software este proceso se aplica comúnmente cuando ocurren defectos dentro del proyecto, lo que da como resultado la identificación de sus causas principales (o más probables). Los objetivos principales del Análisis de Causa Raíz son:
- Definir mejor la criticidad del problema mediante la identificación de sus causas
- Evaluar mejor el impacto y sus implicaciones
- Identificar e implementar medidas de mitigación de riesgos para reducir el riesgo (o incluso evitar) futuras incidencias
Se trata de llegar al origen de los problemas (variaciones, problemas o defectos) mediante el uso de herramientas que pueden ser de naturaleza estadística y no estadística.
Proceso
El proceso de RCA se encuentra bien documentado en diferentes fuentes, pero los pasos generales son los siguientes:
- Definición de problema
- Identificación de la causa o causas a través de herramientas como:
- Diagramas de causa y efecto
- Matrices y diagramas relacionales
- Análisis de los 5 porqués
- Análisis de árbol de fallas (FTA)
- Elaboración reporte escrito
- Redefinición de problemas (si es necesario)
- Análisis de impacto
- Evaluación de la criticidad
- Categorización del problema
- Propuestas de medidas de mitigación
Para mayor información sobre RCA y cada uno de los pasos y herramientas, pueden consultar literatura específica sobre el tema o sobre six sigma.
Propuesta de acciones y responsabilidades para el RCA en un proyecto de software ágil
Según el entorno en el que se identificó el problema o hasta dónde se filtró en la cadena de los entornos (o ambientes) dentro del ecosistema de desarrollo de software, existen diferentes responsabilidades y acciones que pueden variar entre los roles definidos para un proyecto. Los roles considerados para la siguiente propuesta son aquellos definidos generalmente para proyectos de tipo Scrum como el ingeniero desarrollador de software (Dev), ingeniero de calidad de software (QA), el Scrum Master (SM) y Product Owner (PO).
Ambientes de desarrollo y pruebas
Si el problema o defecto se identificó en los entornos de desarrollo (local / dev) o pruebas (qa / testing), se infiere que el problema fue detectado como parte del proceso de aseguramiento de calidad por lo que únicamente se proponen las siguientes acciones y responsabilidades:
- QAs: Responsables del registro del problema, la diligencia debida y el informe escrito. Los QAs también pueden ayudar en la depuración (debugging) del problema (por ejemplo, preparando datos de prueba para la reproducibilidad del problema) y debe realizar el esfuerzo de pruebas de la solución implementada.
- Devs: Responsable de determinar la causa real y proporcionar toda la información necesaria para el informe escrito, así como de presentar soluciones potenciales e implementar aquella que haya sido aprobada.
- SM: Valida el correcto registro de la información en el historial del proyecto (p.e. la bitácora de defectos vinculado al reporte escrito del RCA)
Ambientes no productivos
Si el problema o defecto se encontró en ambientes inferiores, que no son de desarrollo y tampoco son productivos (p.e. staging, uat, pre-prod) adicionalmente a las acciones descritas para los ambientes de dev y qa, cada rol debe:
- QAs: Encontrar el proceso de calidad que no detectó o detuvo el problema en el entorno anterior para que este no se “escapara” (revisión de la estrategia de pruebas y los puntos de verificación de calidad). También son responsables de supervisar la implementación (actualización o creación) del proceso, guía, política o punto de verificación de calidad que permita reducir o incluso evitar incidencias similares.
- Devs: Responsable de desarrollar el análisis de impacto (p.e. número de usuarios afectados, tipo y nivel de afectación) así como proporcionar información técnica y funcional en colaboración con analistas de negocio (BAs), PO y usuarios finales para determinar el nivel de criticidad (en caso necesario).
- SM: Se asegura de que se discutan en la retrospectiva las ideas propuestas como medidas de mitigación (p.e. procesos de mejora) derivados del RCA y coordina su subsecuente implementación. También es responsable de revisar la eficacia de los cambios que resultan de la implantación de dichas medidas de mitigación.
- PO: Es informado del problema o defecto inicial, el resultado del RCA, así como sobre la solución que se le dio. Apoya en la priorización de la atención del problema y proporciona retroalimentación al equipo sobre las soluciones propuestas.
Ambientes productivos
Si el problema o defecto se encontró en los entornos productivos, se asume que el impacto se traslada a los usuarios finales por lo cual se proponen las siguientes acciones adicionales a las descritas para los ambientes anteriores:
- QAs: Apoyo en la identificación funcionalidades, condiciones y escenarios con un potencial de riesgo de ocurrencia del mismo problema o defecto y su inclusión como sugerencias de revisión en las medidas de mitigación del RCA.
- Devs: Liderear la colaboración con otros roles (como QA y DevOps) para analizar y reforzar los procesos y controles de despliegue en los ambientes, así como la determinación de la solución y el esfuerzo requerido para resolver las funcionalidades identificadas con potencial de riesgo de ocurrencia del mismo incidente.
- SM: Documentación del Backlog resultante de la identificación de los escenarios con potenciales de riesgo similar. Preparación y presentación del informe detallado del incidente de producción al PO.
- PO: Recibe y da el visto bueno del informe detallado del incidente de producción, colabora con el equipo en las sesiones de propuestas de mitigación. Se encarga del seguimiento de las acciones propuestas que están fuera del alcance del equipo.
Cabe destacar que las acciones y responsabilidades propuestas por cada rol, se van acumulando conforme avanza en la cadena de despliegue de entornos, es decir, las acciones y responsabilidades así como el número de roles involucrados, aumentan conforme el problema o defecto se presenta más tarde en el ciclo de desarrollo o en los ambientes más cercanos a producción, haciendo que el proceso y sus evidencias se vuelven más complejas y específicas, requiriendo una mayor y más estrecha colaboración conforme aumenta el número de roles involucrados. Sin embargo, se advierte que todos los miembros del equipo (todos los roles) son responsables de las propuestas de mejoras de proceso o medidas de mitigación para cada incidente, tanto desde la perspectiva de su propio rol como de la perspectiva de los procesos y herramientas compartidas, así como la dinámica general del equipo.
Adicionalmente, se sugiere que las acciones propuestas se lleven a cabo dentro del periodo del Sprint en el que se detecta el problema o defecto; sin embargo, en los casos en los que estos se clasifiquen con una prioridad baja, todas las acciones (exceptuando el registro del defecto en la bitácora) se pueden postergar, con la consecuente acumulación de la deuda técnica para el equipo.
¿Cuáles son los entregables que corresponden a esta propuesta?
El proceso de RCA está diseñado para proporcionar información “accionable”, es decir, sobre la cual se puedan tomar decisiones y acciones consecuentes. Para ello se requiere el desarrollo de los siguientes documentos y entregables durante el proceso:
- Informe del RCA: es un documento formal donde se describen los pasos que se siguieron durante el análisis, así como los resultados de cada uno de ellos. Este documento debe incluir las fechas (o periodos) que comprenden desde la inyección del problema en el entorno, su identificación y hasta su resolución, la clasificación de la criticidad del problema o defecto y su categoría (ver publicación sobre categorización de defectos de software), así como los nombres de las personas involucradas en análisis, solución y su aprobación.
- Problema/defecto correctamente actualizado: en muchas ocasiones, el proceso de RCA lleva a definir de manera más clara el problema, por lo que debe actualizarse su descripción (por ejemplo, en la bitácora de defecto). Un ejemplo es cuando un usuario reporta el problema “No hay internet” y al efectuar el análisis se determina que sí hay conectividad de red entre la computadora del usuario y la Internet, pero la causa de la falla es que el servicio de DNS (uno de los componentes principales que habilita entre otras cosas la navegación web) no está funcionando. El problema entonces se redefine como “Mal funcionamiento del sistema DNS” y se procede a determinar las causas.
- Causa / Diagnóstico: En este apartado se describen de manera detallada la posible causa o causas determinadas por el análisis, así como el proceso que se utilizó para llegar a ellas y toda la información técnica o documental de soporte.
- Propuestas para la mitigación de la ocurrencia de nuevas instancias: En este documento se describen las medidas propuestas para disminuir o cancelar la posibilidad de que el problema o defecto se repita o no sea detectado a tiempo, incluyendo el detalle de su implementación, la planeación, la estimación del esfuerzo requerido, así como los responsables de llevarla a cabo y supervisarla.
Ejemplos de medidas generales de mitigación
A continuación, se enumeran algunos ejemplos de medidas de mitigación generales que pueden servir como punto de partida para un proceso de RCA.
- Determinación de necesidades de capacitación técnica, funcional o de procesos de negocio para los miembros del equipo
- Actualización de entregables de aseguramiento de calidad (p.e. escenarios y casos de prueba, plan y/o estrategia de pruebas, automatizaciones, datos de prueba)
- Establecimiento de puntos de control de calidad en el proceso de desarrollo y depuración (p.e. revisión de código o code reviews, mayor cobertura de pruebas unitarias, uso de herramientas automáticas de análisis estático de código o ejecución desatendida de pruebas automatizadas por despliegue o “deployment” y por ambiente o “nightly builds”)
- Correcta asignación de tareas de acuerdo con el rol y experiencia de los miembros del equipo
- Establecimiento de políticas, guías y procesos, así como su documentación, conocimiento y accesibilidad para los miembros de los equipos
- Documentación y administración del conocimiento del equipo, así como entrenamientos cruzados (cross-training)
- Calendarización de eventos que afecten la capacidad del equipo (p.e. vacaciones de los miembros más experimentados)
- Énfasis en la identificación y comunicación de interdependencias técnicas o con equipos externos durante la planeación del sprint
- Registro y seguimiento del progreso del esfuerzo por rol durante el Sprint (p.e. para evitar causar un cuello de botella al retrasar el despliegue de código o reduciendo los tiempos estimados para la preparación de ambientes, datos y ejecución de pruebas)
Comentarios finales
Como se puede observar, el proceso de RCA puede ser una herramienta de mucho valor para determinar las causas y proponer soluciones a problemas inherentes al desarrollo de software, independientemente de su causa y el contexto en el que surjan. Sin embargo, aunque existen varios ejemplos de casos de éxito en diversas industrias, en ocasiones no hay claridad en la definición de las acciones, ni del el tipo y nivel de involucramiento de los roles de un equipo de desarrollo de software.
También me he encontrado con quienes se rehúsan a utilizar RCA en equipos ágiles argumentando aspectos como que “los procesos formales le quitan la agilidad al equipo” o “ágil prioriza software funcional, la documentación quita tiempo valioso”. En estos casos, la experiencia me ha comprobado que los equipos ágiles son perfectamente capaces de adaptarse para el uso de RCAs como parte de su dinámica y que sus ventajas sobrepasan los argumentos en su contra (especialmente cuando el proyecto se ve en dificultades por falta de calidad).
Cabe destacar que esta publicación hace énfasis en las acciones y responsabilidades propuestas para los roles involucrados, así como en la utilidad de las evidencias entregables, mas no profundiza en el proceso de RCA en sí. Esto es con la intención de mantener el texto breve y enfocado a la propuesta, ya que el proceso de RCA está muy bien documentado en muchas y muy variadas fuentes.
Espero que esta información sea de utilidad para iniciar las conversaciones sobre cómo implementar RCA en tu propio equipo.
Si tienes preguntas o comentarios sobre esta publicación, puedes hacerlas en mi Linkedin o en Twitter.
