¿Por qué? ¿No pueden algunas tareas esperar hasta la próxima semana? ¿Es tan importante terminar absolutamente todo antes del fin de semana? No, no es tan importante. Y todo esto se debe al hecho de que "Realizar tareas es malo".
Scrum ya no es una metodología de desarrollo ágil
He llegado a la conclusión de que hay demasiado énfasis en el proceso de trabajo en Scrum. O, al menos, las personas le prestan demasiada atención, lo que se expresa en lo siguiente:
- Está bien terminar la historia del usuario el último día del sprint. Pero terminar el trabajo el próximo lunes ya es una "transferencia de tareas".
- - ( , ), , , , , .
- , , , . , , , ( , ).
Como resultado, resultó que Scrum ya no nos ayudó a lograr el objetivo. Este método de gestión de proyectos ahora nos limitaba.
Con todo lo anterior, puedo notar que los miembros de mi equipo comenzaron a sentirse insatisfechos con lo que estaba sucediendo. Esto afectó la calidad de lo que creamos. Los programadores estaban más preocupados por cumplir con los plazos que por alcanzar el nivel de calidad deseado.
En este punto, comenzamos a buscar otras formas de organizar el trabajo, buscando otro marco ágil que se adaptara mejor a nuestra forma de trabajar.
Luego encontramos Kanban (kanban).
¿Qué es kanban?
Kanban es un método de gestión de producción que se originó en Toyota en la década de 1950. En ese momento, Toyota utilizaba una tabla con tres columnas: planificada, en progreso, completada. Este marco permitió a Toyota asignar recursos de manera más eficiente en situaciones donde surgieron cuellos de botella en algún lugar de la línea de producción.
Luego, cuando quedó claro que el uso de Kanban podría aumentar la velocidad del desarrollo de software, Kanban fue transferido al campo de la tecnología.
Comparación de los marcos de Scrum y Kanban
En los últimos años, Scrum y Kanban han estado luchando para convertirse en el marco ágil líder. A pesar de que Scrum ocupa el primer lugar , kanban se está extendiendo gradualmente más y más. ¿Qué pasa si los comparas?
Si tomamos Scrum como base y lo comparamos con Kanban, obtenemos lo siguiente:
- , ().
- .
- «». , .
- , , .
- () -.
Una comparación más detallada entre Scrum y Kanban se puede encontrar aquí .
Kanban le da al equipo de desarrollo un nivel bastante alto de flexibilidad. Las historias de usuarios, en comparación con Scrum, se ejecutan de manera más libre. Pero la libertad es responsabilidad. Si bien Kanban no requiere que los desarrolladores se comprometan cada dos semanas, este método de gestión del desarrollo tiene sus propios controles. Estas son, por ejemplo, métricas como el tiempo de ciclo y el rendimiento del sistema.
Se trata de métricas
Es imposible evaluar la efectividad (o ineficiencia) del trabajo sin métricas especializadas. Echemos un vistazo a las métricas utilizadas en Scrum y Kanban.
▍Scrum Metrics
Al aplicar scrum, se utilizan las siguientes métricas y gráficos:
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
Es poco probable que estas métricas lo ayuden a mejorar su flujo de trabajo.
La "velocidad" no mide la velocidad a la que se liberan los subsistemas de productos terminados. Esta métrica solo mide el número de pasos de trabajo completados que son relevantes para una historia de usuario. Si una historia tarda más de lo planeado en completarse, esta métrica no tiene sentido.
"La relación del compromiso del desarrollador con el volumen de tareas completadas" no debe considerarse una medida en absoluto. Esta "métrica" compara el compromiso con los resultados. No es necesario decir que esto puede hacer que las personas cierren y vuelvan a abrir tareas solo para hacerlas.
El diagrama de agotamiento es algo a lo que nunca presté mucha atención. Esto se debe principalmente al hecho de que tales gráficos a menudo se parecen a los siguientes.
Diagrama de Burnout
¿Por qué es así? Digamos que comienza con un tablero en blanco y comienza a trabajar en paralelo, por ejemplo, con tres historias de usuario. Es probable que estas historias se trabajen a la misma velocidad, por lo que puede ver movimientos tan poderosos hacia abajo en el diagrama de agotamiento. Además, si solo hay un probador en el equipo que debe probar los resultados del trabajo en todas las tareas, entonces él será el cuello de botella del equipo.
▍Kanban métricas
Creo que las métricas son las fortalezas más importantes de Kanban. Kanban tiene muchas métricas diferentes para ayudarlo a comprender mejor lo que sucede con su equipo. Por ejemplo:
- Rendimiento del equipo El número de historias de usuarios que se completaron dentro de un período de tiempo determinado.
- Tiempo del ciclo El número de días que lleva completar el trabajo de historia desde el inicio del trabajo. Aquí se utilizan métricas como los intervalos de confianza. El más común es el 85% de confianza.
- Diagrama de flujo acumulativo Dicho diagrama le permite visualizar el proceso de resolución de problemas basado en historias de usuarios. Este diagrama debería parecerse al que se muestra a continuación.
Diagrama de flujo acumulativo
Hay un complemento para Jira que le permite aprovechar todas estas métricas. Esto es ActionableAgile para Jira - Agile Metrics . Ayuda a explorar métricas relevantes para el rendimiento del equipo utilizando la misma plataforma utilizada para administrar el trabajo.
Adaptación Kanban
El uso de kanban "puro" no proporciona algunas de las operaciones que se requieren al usar scrum. Pero este método de gestión de proyectos es lo suficientemente flexible como para permitir, si tales acciones parecen útiles, agregarse al flujo de trabajo.
Las retrospectivas son uno de los tipos más importantes de reuniones. Es en estas reuniones que los miembros del equipo pueden hablar sobre lo que han logrado, lo que no ha ido muy bien y lo que se puede mejorar. Una retrospectiva es un evento tranquilo donde puedes hablar sobre tus problemas y felicitar a aquellos que han hecho un excelente trabajo por su éxito.
Si bien los flashbacks no son necesarios en Kanban (se llevan a cabo al final de cada Sprint en Scrum), los encontramos valiosos y no quisimos omitirlos. De hecho, incluso comenzamos a hacerlo semanalmente, en lugar de cada dos semanas como solíamos hacerlo. Esto nos permitió reaccionar más rápidamente ante la aparición de cualquier problema. También utilizamos estas reuniones para analizar las métricas del equipo y verificar los flujos de trabajo en busca de problemas y cuellos de botella.
Hemos guardado un elemento más de nuestros tiempos de Scrum, que es opcional al usar kanban. Se trata de estimar el tiempo requerido para trabajar en una historia de usuario. Esto se hace en el curso de aclarar las tareas que pasan a la historia. Scrum usa estas estimaciones para comprender mejor qué encajará en el sprint. Puede pensar que, dado que no hay sprints en Kanban, la evaluación de la historia es innecesaria. Pero en realidad no lo es.
Estimar el tiempo que lleva completar una historia de usuario ayuda a garantizar que todos los miembros del equipo tengan la misma comprensión del alcance de las tareas que deben completarse mientras se trabaja en la historia. Si alguien le da a la historia una calificación de 8, y alguien - 3, es obvio que necesitamos continuar discutiendo este tema. Al evaluar el momento, alguien puede tener en cuenta algunos problemas que otros desconocen. En el entendimiento de alguien, el alcance del trabajo de la historia del usuario debe incluir algo que otros no consideran como tal.
De hecho, todo esto empuja a los miembros del equipo a discusiones.
Cuando sucede algo como esto, resulta obvio que no todos tienen una comprensión clara de cuánto trabajo hay que hacer en una determinada historia de usuario.
Otro escenario común se ve así: todo el equipo le da a la laboriosidad de la historia una calificación bastante alta (generalmente todo lo que supera los 8 puntos). Esto habla de incertidumbre. Esto significa que estamos hablando de mucho trabajo o de resolver problemas muy difíciles, lo que hace que los miembros del equipo sean desagradables. En tal caso, es mejor dividir la historia del usuario en varias historias más pequeñas y definir los objetivos del trabajo con mayor claridad.
Salir
Scrum permanecerá para siempre en nuestros corazones como la primera metodología ágil generalizada. Pero a medida que las empresas avanzan hacia esquemas de despliegue continuo, el uso de sprints de tiempo limitado ya no tiene sentido.
Siempre habrá proyectos especiales en los que Scrum puede funcionar bien. Sin embargo, dado el hecho de que las empresas utilizan cada vez más metodologías ágiles, Kanban irá ganando gradualmente, desplazando a Scrum.
¿Qué te queda mejor? Scrum o Kanban?
