Cinco veces porqué: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Meta-bok|min=3}} | {{Meta-bok|min=3}} | ||
'''Cinco veces porqué''' (''Five Whys'' en inglés) es una técnica de análisis de causa raíz que se usa durante la [[retrospectiva]] para identificar por qué se ha producido un determinado problema. Consiste en preguntar "¿por qué?" de forma iterativa hasta cinco veces, profundizando en cada respuesta hasta llegar a causas subyacentes que no son evidentes a primera vista. | '''Cinco veces porqué''' (''Five Whys'' en inglés) es una técnica de análisis de causa raíz que se usa durante la [[retrospectiva]] para identificar por qué se ha producido un determinado problema. Consiste en preguntar "¿por qué?" de forma iterativa hasta cinco veces, profundizando en cada respuesta hasta llegar a causas subyacentes que no son evidentes a primera vista. | ||
Fue desarrollada por Sakichi Toyoda y es parte del Sistema de Producción Toyota (TPS). En retrospectivas ágiles se usa habitualmente en la tercera fase, dedicada a generar conocimiento sobre lo ocurrido durante el sprint. Dura entre 15 y 20 minutos y se trabaja en parejas o grupos reducidos. | Fue desarrollada por Sakichi Toyoda y es parte del Sistema de Producción Toyota (TPS). En retrospectivas ágiles se usa habitualmente en la tercera fase, dedicada a generar conocimiento sobre lo ocurrido durante el sprint. Dura entre 15 y 20 minutos y se trabaja en parejas o grupos reducidos. | ||
== Cuándo usarla == | == Cuándo usarla == | ||
* Cuando el equipo ha identificado un problema recurrente o significativo y quiere entender sus causas antes de proponer soluciones. | |||
* Después de actividades de recopilación de datos como [[Patterns and shifts]], que identifican qué ha pasado; los Cinco porqués ayudan a entender el por qué. | |||
* Cuando las soluciones que el equipo suele proponer son siempre las mismas y no resuelven el problema de fondo. | |||
== Cómo aplicarla == | |||
# El equipo ha identificado previamente los problemas que quiere analizar. | |||
# Se forman parejas o grupos pequeños. Cada grupo se centra en un problema concreto. | |||
# Una persona pregunta "¿por qué?" y otra responde. Se continúa preguntando "¿por qué?" sobre cada respuesta, hasta cinco veces. | |||
# El objetivo es llegar a causas que estén fuera de la manera habitual de pensar sobre el problema. Los porqués cuarto y quinto son los más reveladores: suelen apuntar a causas sistémicas o culturales, no a causas inmediatas. | |||
# Cada grupo apunta las respuestas surgidas del cuarto y quinto porqué. | |||
# Al terminar, los grupos comparten sus descubrimientos para usarlos en la siguiente fase de la retrospectiva. | |||
== Ejemplo práctico == | == Ejemplo práctico == | ||
Problema: "Entregamos tarde la funcionalidad de pagos". | '''Problema: "Entregamos tarde la funcionalidad de pagos".''' | ||
* ¿Por qué? → Porque los tests tardaron más de lo previsto. | |||
* ¿Por qué? → Porque había muchos casos de borde no contemplados. | |||
* ¿Por qué? → Porque los criterios de aceptación no los especificaban. | |||
* ¿Por qué? → Porque el refinamiento se hizo con prisas la semana anterior. | |||
* ¿Por qué? → Porque no tenemos tiempo protegido para el refinamiento en el sprint. | |||
La causa raíz no es "los tests tardaron" sino "no hay tiempo protegido para el refinamiento". La solución también es diferente. | |||
== Cómo moderarla == | == Cómo moderarla == | ||
La actividad debe centrarse en acontecimientos, comportamientos y procesos, no en personas. El objetivo es el análisis constructivo de causas sistémicas, no la asignación de culpas. El facilitador debe intervenir si la conversación deriva hacia señalar a alguien en concreto. | La actividad debe centrarse en acontecimientos, comportamientos y procesos, no en personas. El objetivo es el análisis constructivo de causas sistémicas, no la asignación de culpas. El facilitador debe intervenir si la conversación deriva hacia señalar a alguien en concreto. | ||
| Line 35: | Line 35: | ||
== Recursos == | == Recursos == | ||
<div class="bok-recurso"> | <div class="bok-recurso"> | ||
📄 [https://www.scrummanager.com/blog/2023/10/tercera-fase-de-una-retrospectiva-crear-conocimiento/ | 📄 [https://www.scrummanager.com/blog/2023/10/tercera-fase-de-una-retrospectiva-crear-conocimiento/ '''Tercera fase de una retrospectiva: crear conocimiento''']<span class="detalle">Scrum Manager Blog · oct 2023</span> | ||
</div> | </div> | ||
== Referencias == | == Referencias == | ||
Derby, Esther; Larsen, Diana. (2006). ''Agile Retrospectives: Making Good Teams Great''. Pragmatic Bookshelf. | |||
Ohno, Taiichi. (1988). ''Toyota Production System: Beyond Large-Scale Production''. Productivity Press. | Ohno, Taiichi. (1988). ''Toyota Production System: Beyond Large-Scale Production''. Productivity Press. | ||