Sin embargo, Agile no es un enfoque uniforme. Como enfoque general para organizar el proceso de desarrollo, el desarrollo ágil de software establece los mismos valores y principios para hacer que el proceso de desarrollo sea más simple, más eficiente y más receptivo al cambio. Estos valores y principios se pueden encontrar en el Manifiesto Ágil, que también contiene métodos recomendados para establecer un proceso de desarrollo.
En la vida real, estos principios ágiles han generado bastantes marcos de desarrollo de software y se han aplicado en la práctica. Kanban y Scrum son los marcos de desarrollo más populares y utilizados. Aunque el objetivo de ambos enfoques es el mismo, que es crear un proceso de desarrollo eficiente, todavía existen algunas diferencias entre ellos. De eso es de lo que vamos a hablar hoy.
Comprender los principios de funcionamiento del método Scrum y el método Kanban puede ayudar a los clientes y desarrolladores a comprender el ritmo de trabajo del equipo de desarrollo y elaborar los planes de desarrollo correspondientes.
Antes de profundizar en las diferencias entre Scrum y Kanban, echemos un vistazo a los conceptos principales de ambos marcos. De esta forma, nos resulta más fácil comparar Kanban y Scrum. Ambos están diseñando procesos para formar equipos autoorganizados; sin embargo, adoptan enfoques diferentes;
El nombre Scrum proviene del término rugby, que significa que los jugadores forman una formación y ocupan el balón. En el desarrollo de software, Scrum se refiere a un método de organizar equipos con el objetivo de desarrollar productos de software complejos de manera más eficiente.
¿La filosofía del método Scrum se basa en suposiciones o en hechos? -El equipo de desarrollo no conoce el resultado final del proyecto al principio, pero lo comprende continuamente y realiza ajustes de prueba durante el proceso de desarrollo para completar la entrega. Scrum simplifica este ajuste restableciendo las prioridades al comienzo de cada iteración, lo que se denomina "sprint" en la terminología de Scrum.
Echemos un vistazo a un concepto central de Scrum-sprint, que es un ciclo de iteración de 2 a 4 semanas, durante el cual se debe completar una cantidad clara de tareas de desarrollo. Sprint ayuda a dividir el alcance del proyecto en paquetes de tareas más manejables y a entregar componentes de software procesables con mayor frecuencia. Presentemos brevemente los detalles de la planificación del sprint, los ajustes del plan y la finalización del plan.
Desarrollar en base al plan de sprint, enfocándose en las tareas que se deben completar en cada sprint, flexibilizando el plan de desarrollo. El equipo comienza cada nuevo sprint con una "lista de tareas en blanco" y desarrolla un plan de desarrollo para el nuevo sprint basado en los cambios en la situación actual y las necesidades del proyecto.
El método Kanban fue inventado originalmente por Toyota para optimizar el inventario de la fábrica. En japonés, "kanban" se refiere a un tablero o tarjeta de anuncios. En la práctica inicial, el departamento de producción de la fábrica enviaba un "kanban" al almacén por algunas piezas insuficientes, solicitando reposición. Luego, el almacén envía un kanban al proveedor para pedir más piezas correspondientes.
Como se puede observar en este ejemplo, el método Kanban se centra en las capacidades actuales, que es también el concepto principal que introduce en el campo del desarrollo de software. A diferencia de Scrum, el método Kanban no tiene límite de tiempo, sino que limita la cantidad de trabajo que se puede realizar simultáneamente;
Uno de los principales indicadores del tablero Kanban son las “tareas en progreso”, que son tareas que se encuentran actualmente en ejecución. Según el método Kanban, para lograr la máxima eficiencia, las tareas en curso deben limitarse a un número apropiado a las capacidades del equipo para reducir el riesgo de cuellos de botella en las tareas.
Kanban también se adapta bien a los cambios, lo cual es importante porque los cambios pueden ocurrir en cualquier etapa del proyecto y deben agregarse al grupo de tareas para su ejecución en cualquier momento.
Si queremos comparar Scrum y Kanban, debemos observar la forma en que ambos marcos organizan los flujos de trabajo y las principales formas y definiciones que utilizan.
La asignación de roles es la primera gran diferencia entre Scrum y Kanban. En Scrum, siempre puedes encontrar tres roles principales en el equipo:
Por el contrario, Kanban no tiene requisitos estrictos para los roles del equipo. Puede haber un propietario de producto que gestione las tareas del trabajo pendiente del proyecto, pero aparte de eso, el equipo se autoorganiza.
Hemos dicho que el desarrollo de Scrum se realiza en iteraciones, y Scrum define las tareas a completar en cada iteración. Los tableros Kanban limitan la cantidad de tareas actualmente en progreso, pero no hay un límite de tiempo específico. Veamos ambos métodos en acción.
La planificación del proyecto comienza con la definición del backlog, que es una lista de historias de usuarios del producto que se debe entregar. En este caso, Scrum utiliza los siguientes conceptos principales para ayudarnos a comprender el proceso de planificación y lanzamiento:
Cada sprint comienza con la fase de planificación, seleccionando las tareas a completar en el siguiente sprint. Para el proceso de planificación suele participar todo el equipo, incluidos el Product Owner y el Scrum Master. El equipo decide qué comprometerse al final del sprint y selecciona las historias de usuario correspondientes del trabajo pendiente del producto. De esta manera, el equipo integra el backlog del sprint.
Durante la fase de sprint, el equipo celebrará una "reunión diaria de pie" todos los días para discutir su progreso y posibles problemas. El propósito de las reuniones diarias es identificar problemas lo antes posible y encontrar soluciones rápidamente sin interrumpir el proceso de sprint.
Una vez completado el sprint, el cliente revisará la funcionalidad completada. Durante la revisión del sprint, el equipo tiene la oportunidad de recibir comentarios y solicitudes de cambio (si las hay) sobre sus entregables.
Al mismo tiempo, el equipo llevará a cabo una reunión de revisión del sprint para analizar el sprint que acaban de completar y descubrir dónde pueden mejorar. Una vez completada la revisión, comienza una nueva iteración y un nuevo sprint en la fase de planificación.
En el método Kanban no existe un cronograma en el que se deban completar un número determinado de tareas. En cambio, Kanban se centra en hacer coincidir las capacidades de desarrollo del equipo con la cantidad de tareas actualmente en curso.
El proceso del proyecto Kanban comienza con una lista de tareas pendientes que incluye todas las tareas que deben completarse. Cada miembro del equipo selecciona una tarea para sí mismo del trabajo pendiente y se concentra en completarla. Cuando se completa una tarea, el miembro selecciona la siguiente tarea de la lista de tareas pendientes, y así sucesivamente hasta que la lista de tareas pendientes esté vacía. El trabajo pendiente coloca las tareas más urgentes en la parte superior en orden de prioridad, lo que facilita que los miembros del equipo elijan primero.
Durante un proyecto Kanban es muy importante que el número de tareas en curso no supere la capacidad de trabajo del equipo. Para ello, se pueden establecer cuotas para varios tipos de tareas laborales en función de la cantidad de trabajo que se puede asignar.
El propietario del producto puede establecer o ajustar la prioridad de las tareas en el trabajo pendiente en cualquier momento según sea necesario, porque la gestión del trabajo pendiente no afectará el desempeño laboral del equipo de desarrollo. El equipo de desarrollo solo se preocupa por las tareas de trabajo en curso y prestará atención al trabajo pendiente una vez completadas las tareas actuales.
Cada tarea sigue la ruta de estado de "Por hacer" - "En curso" - "Completada". Por supuesto, Kanban también soporta la definición del concepto de "hecho", es decir, los criterios de aceptación de cada tarea.
Finalmente, las tareas completadas forman componentes del producto para medir el tiempo requerido para entregar el producto. En Kanban se denomina "tiempo de ciclo" y la medición del tiempo de ciclo ofrece muchas oportunidades para la optimización del proceso. Por supuesto, todos los miembros del equipo están trabajando arduamente para acortar el tiempo del ciclo tanto como sea posible y encontrar formas de resolver los cuellos de botella de desarrollo (si los hay).
En este caso, es muy importante que los miembros del equipo tengan una variedad de habilidades. Si sólo una persona posee una determinada habilidad (por ejemplo, si sólo tienes un evaluador), las pruebas se convierten en un cuello de botella. Todas las tareas de prueba estarán en cola y, por lo tanto, se retrasará la entrega del producto.
En resumen, podemos decir que la principal diferencia entre ambos métodos es que el método Scrum se esfuerza en que el equipo complete las tareas programadas dentro del tiempo estipulado, mientras que el método Kanban asegura que las tareas en curso Nunca exceder la carga de trabajo máxima establecida por el equipo.
Hablando de Scrum y Kanban, no podemos pasar por alto sus tableros de tareas. Ambos métodos utilizan un tablero de tareas como herramienta visual para planificar y monitorear el progreso del proyecto. El tablero de tareas refleja los conceptos principales de Scrum y Kanban, y la organización correspondiente.
Aunque existen muchas herramientas para crear y administrar tableros de tareas de Scrum y Kanban (por ejemplo, tanto Gila como TargetProcess lo admiten, y Trello es originalmente una herramienta Kanban, pero también se puede extender a Scrum), pero también puedes utilizar una pizarra blanca normal con etiquetas y notas adhesivas. La clave es aprender a utilizar el tablero de tareas, independientemente de la herramienta específica.
El tablero de tareas de Scrum debe contener al menos tres columnas, denominadas "Pendientes", "En curso" y "Listo". Si es necesario, también puede agregar una columna "Historia de usuario" para mostrar todas las historias de usuario, o insertar una columna "Prueba" antes de "Completado", pero al final el progreso de la tarea actual se mostrará a tiempo.
Al comienzo de cada sprint, todas las tareas están en la primera columna. Al final del sprint, según la definición de "completado", deben moverse a la última columna "completado". Luego podrás limpiar el tablero de tareas y prepararte para el próximo sprint.
Los tableros de tareas de Scrum siempre pertenecen a equipos que desarrollan el mismo producto. Normalmente, los miembros del equipo Scrum son multifuncionales e incluyen todas las habilidades, desde desarrolladores y arquitectos hasta evaluadores y redactores de documentos técnicos.
El tablero de tareas Kanban se ve y funciona igual que Scrum, pero hay una diferencia importante: los límites de las tareas se muestran en la columna "En progreso". El número de tareas en curso no puede exceder este límite.
Los tableros Kanban existen durante todo el ciclo de trabajo. Como no están vinculados a ningún período de tiempo específico, no es necesario restablecerlos.
Debido a que los tableros Kanban se utilizan durante todo el ciclo de trabajo, no pertenecen a un equipo determinado y pueden ser compartidos entre diferentes equipos. En Kanban, los tableros de tareas se pueden utilizar para tareas específicas, como los tableros de tareas de marketing.
Si estabas esperando una respuesta clara a esta pregunta, es posible que te hayamos decepcionado. Hasta ahora, esperamos haber demostrado que ambos enfoques tienen sus propios méritos y que ambos son útiles para establecer un proceso de desarrollo ágil. Por supuesto, ofrecemos algunas sugerencias para ayudarle a elegir el mejor enfoque para su equipo.
Utiliza el método Scrum si:
Utiliza el método Kanban si:
¡Los dos métodos siempre se pueden combinar! Incluso existe un método llamado Scrumban, que combina los métodos Scrum y Kanban. En el enfoque Scrumban, puedes completar el trabajo en iteraciones cortas y mantener la carga de trabajo dentro de ciertos límites. Las tareas que superen el límite desencadenarán una nueva iteración.
Como puedes ver, tienes la libertad y flexibilidad para elegir el método de gestión de proyectos que desees. No existen reglas estrictas y rápidas. Puede personalizar, combinar y utilizar métodos de gestión de proyectos para satisfacer las necesidades de su proyecto. De hecho, el criterio principal para elegir un método de gestión de proyectos es siempre el éxito de su proyecto y la satisfacción del equipo con el proceso de trabajo.
Kanban vs scrum: elegir el mejor marco ágil de gestión de proyectos