Dominio V: Detección y resolución de problemas.
Los problemas son inevitables en cualquier proyecto. Identificarlos y resolverlos proactivamente es crucial. Avanzar esperando que el problema desaparezca puede dañar el proyecto tanto en términos de tiempo como de costo.
Se han desarrollado varias herramientas, técnicas, conjuntos de conocimientos y habilidades para permitir que los equipos diagnostiquen y resuelvan problemas de manera temprana.
Identificando problemas.
Las actividades de diagnóstico (como la medición de tiempos de ciclo y tendencias) pueden ayudar a detectar problemas antes de que surjan, mientras que herramientas como los «defectos escapados» identifican problemas que ya han ocurrido. Las prácticas discutidas en esta sección se enfocan en identificar cuestiones y problemas.
Tiempo del ciclo.
El tiempo de ciclo es el período de tiempo necesario para completar una tarea, como desarrollar una característica o un ítem en el backlog. El tiempo de ciclo y el Trabajo en Proceso (WIP, por sus siglas en inglés) están estrechamente relacionados, ya que grandes cantidades de WIP pueden generar cuellos de botella. Si surgen problemas, pueden crear grandes cantidades de reprocesos, lo que incrementa el tiempo de ciclo. Por lo tanto, es importante limitar el WIP.
El tiempo de ciclo de un ítem es el tiempo transcurrido entre el inicio y la finalización del ítem. El tiempo de ciclo de una iteración es el promedio de todos los tiempos de ciclo de las tareas dentro de esa iteración. La productividad (throughput) se refiere a la cantidad de trabajo que un equipo es capaz de realizar. Utilizando el WIP y la productividad, se puede calcular el tiempo de ciclo. La fórmula es:
Tiempo de ciclo = WIP / productividad
Cuanto más tiempo se dejen los defectos sin resolver, más costoso será solucionarlos. En otras palabras, la tasa de costo del cambio es proporcional al tiempo que se tarda en resolver un problema. Esto se debe a que el trabajo construido sobre defectos puede necesitar ser deshecho o reprocesado. Los problemas también pueden afectar negativamente a las partes interesadas si los defectos persisten más tiempo en el ciclo de desarrollo.
Defectos escapados.
A pesar de los mejores esfuerzos, algunos defectos pueden escapar a los procesos de control de calidad y llegar a los clientes. Los defectos escapados ocupan el primer lugar en un gráfico de costo de cambio. Rastrear defectos escapados en un gráfico puede ayudar a evaluar y mejorar los procesos de control de calidad.
Proyecto y estándares de calidad.
La detección y resolución de problemas depende en gran medida de las prácticas de gestión de calidad implementadas en el proyecto. Existen varios estándares y prácticas de calidad que los equipos pueden utilizar para garantizar la calidad:
-
- Asegurarse de que las pruebas sean parte de cada iteración.
- Corregir más de las tres cuartas partes de los defectos en la siguiente iteración.
- Asegurar que el equipo de aseguramiento de calidad trabaje con los desarrolladores y los requisitos comerciales para obtener una comprensión completa de los requisitos.
- Automatizar las pruebas con la mayor frecuencia posible.
- Considerar que los defectos están solucionados solo cuando los representantes del negocio acepten que han sido corregidos.
Modos de falla y alternativas.
En su libro Agile Software Development: The Cooperative Game (2ª edición), Alistair Cockburn enumera cinco modos de fallo:
-
- Las personas cometen errores.
- Las personas prefieren fallar de manera conservadora.
- Las personas prefieren inventar soluciones en lugar de buscar entre las soluciones existentes para ver si pueden ser utilizadas.
- Las personas son criaturas de hábitos.
- Las personas tienden a ser inconsistentes en la aplicación de nuevos enfoques.
Cockburn también sugiere que las personas poseen cualidades positivas que actúan como contrapeso a los modos de fallo:
-
- Las personas son buenas para observar y notar cambios.
- Las personas descubren nuevas formas de corregir errores y mejorar sus habilidades.
- Las personas están abiertas al cambio y son receptivas a nuevas ideas.
- Las personas se sienten orgullosas de su trabajo y pueden ir más allá de su descripción laboral cuando trabajan en un proyecto.
Para superar los modos de fallo, Cockburn sugiere las siguientes estrategias:
-
- Establecer y fomentar la adopción de una forma de trabajo estandarizada, pero que incluya margen para la tolerancia y el perdón.
- Crear una representación concreta de la solución final.
- Alterar o modificar un diseño existente que pueda servir como marco para la solución en lugar de empezar desde cero.
- Asignar trabajo en función de los tipos de personalidad de los diferentes miembros del equipo.
- Atraer y retener el mejor talento.
- Proporcionar retroalimentación rápida y continua.
Análisis de varianza y tendencia.
La varianza es la medida de cuán lejos está un resultado real de un resultado esperado. Aunque la varianza es normal y aceptable dentro de ciertos límites, es importante saber cómo gestionarla cuando excede los límites aceptables.
W. Edwards Deming clasifica la varianza en dos categorías: variación de causa común y variación de causa especial. La variación de causa común es la diferencia en el rendimiento del trabajo en un escenario diario o semanal causada por factores normales. Las variaciones de causa especial se refieren a la variación debida a nuevos desarrollos o factores especiales. Deming dice que, al tratar con varianzas, los gerentes pueden confundir la variación de causa común con la variación de causa especial y viceversa. La variación de causa común es normal y aceptada, y no requiere intervención, mientras que la variación de causa especial se debe a un problema subyacente que debe ser abordado.
Límites de control.
Los límites de control pueden proporcionar señales de advertencia sobre problemas que podrían ocurrir. Calcular la velocidad y determinar un límite mínimo, por debajo del cual una disminución en la velocidad podría causar problemas, es un ejemplo de un límite de control. Los tableros de tareas son una buena herramienta para que el equipo aplique los límites de control, ya que impiden que el equipo asuma demasiadas tareas.
Resolviendo problemas.
Integración continua.
Usando técnicas de integración continua, los desarrolladores envían código nuevo y modificado al repositorio de código siempre que sea posible. Esto mitiga el problema de que varios miembros del equipo hagan cambios en código obsoleto, asegurando que solo se trabaje con el código más reciente. Esto evita cualquier problema de compatibilidad. En caso de que exista código incompatible, se advierte al equipo para corregir el error. El código también puede revertirse a su estado anterior sin errores si es necesario.
Pico basado en riesgo.
Un pico basado en riesgos es un ejercicio en el que se analiza un problema. Se realiza un experimento aislado para encontrar una solución al problema. Si el experimento es exitoso, el problema se elimina. Los picos basados en riesgos suelen utilizarse al principio de proyectos que intentan desarrollar nuevas tecnologías antes de avanzar demasiado en el desarrollo del proyecto.
En caso de que el riesgo no pueda ser eliminado por ningún método, llegamos a una condición llamada “fallo rápido.” Esto indica que el proyecto habría fracasado si hubiera continuado. Los fondos y recursos restantes pueden ser utilizados para otros proyectos.
Verificación y validación frecuente.
La verificación y validación frecuentes son una característica continua y a varios niveles en los proyectos ágiles. Con esta práctica, es más fácil garantizar que el proyecto progresa según lo planeado y que no hay errores.
La figura anterior muestra ciclos entrelazados de verificación en diferentes etapas del proyecto y el tiempo que toma la verificación en cada nivel.
Pasos para resolver problemas.
Los proyectos ágiles enfatizan el diagnóstico y la resolución de problemas, por lo que es importante saber qué hacer cuando surgen problemas. La resolución de problemas implica los siguientes pasos.
Paso 1: Recolección de datos
En este paso, se recopilan datos sobre el problema. Los datos deben tener una visión compartida (es decir, los miembros del equipo deben tener un entendimiento común del problema). Se pueden utilizar varias actividades, como cronogramas, «triple nickels», histogramas de satisfacción, radar del equipo y puntos de código de color, para recopilar datos.
Métodos comúnmente utilizados:
-
- Triple Nickels: Es una actividad grupal durante la cual cada miembro del equipo escribe los problemas que cree que deben abordarse. El papel se pasa al siguiente miembro, y este proceso se repite hasta que todos hayan terminado de escribir sus ideas. Luego, se discuten las ideas de cada miembro.
- Histograma de Satisfacción: Durante esta actividad, se pide a los miembros del equipo que califiquen qué tan satisfechos están con diferentes aspectos del proyecto. Luego, esta información se representa en un histograma para identificar problemas.
- Puntos de Código de Color: Se crea una línea de tiempo de los eventos que ocurrieron durante el proyecto y, a continuación, los miembros del equipo asignan a cada evento un color que signifique diferentes estados de ánimo. El rojo puede indicar insatisfacción, el azul puede representar satisfacción, y así sucesivamente.
Paso 2: Generar ideas
Después de recopilar el conjunto de datos, el equipo analiza y genera ideas sobre el problema antes de decidir un plan de acción. Las actividades que pueden generar ideas incluyen lluvia de ideas, diagrama de espina de pescado, identificación de temas y «Cinco Porqués».
-
- Cinco Porqués: Los miembros del equipo identifican un problema y preguntan “¿por qué?”. La respuesta al primer porqué se reformula como una pregunta, y los miembros vuelven a preguntar “¿por qué?”. Este proceso continúa durante cinco iteraciones para generar ideas más profundas sobre el problema y su causa raíz.
- Lluvia de Ideas: A los miembros del equipo se les ofrece un entorno libre y abierto para listar tantas causas del problema como sea posible. Esta lista extensa de posibles causas se convierte en el insumo principal para el siguiente paso.
Paso 3: Decidir qué hacer
Usando actividades como temas breves, objetivos SMART, un juego de planificación retrospectiva, análisis de campo de fuerzas y círculo de preguntas, los miembros del equipo formulan y validan enfoques para resolver el problema.
-
- Objetivos SMART: El objetivo de esta actividad es establecer metas que sean específicas, medibles, alcanzables, realistas y oportunas.
- Círculo de Preguntas: Todos se reúnen en círculo y cada persona hace una pregunta a la persona a su derecha, quien responde y luego formula otra pregunta a la persona a su derecha. Este proceso se repite varias veces.
- Análisis de Campo de Fuerzas: Los equipos identifican soluciones y discuten cómo estas impulsarán o frenarán el proyecto.