Muchos se refieren a Scrum como algo incomprensible, sobrevalorado, innecesario, algo de lo que puedes prescindir. Pero scrum no es solo una palabra de moda que aparece con frecuencia en las comunidades de desarrolladores.
Es una práctica y metodología, una forma de trabajo en equipo que trae resultados tangibles.
Es imposible describir lo que es Scrum en dos palabras e incluso en una frase. Sin embargo, podemos decir con certeza que es exactamente lo contrario de la metodología Waterfall, la forma secuencial tradicional de desarrollo.
En el siguiente artículo, aprenderás más sobre la metodología Scrum, sus ventajas y desventajas y los principios de trabajo.
La historia del surgimiento de Scrum como método de gestión de proyectos
Inicialmente, para crear los primeros productos de software, la mayoría de los desarrolladores utilizaron el llamado método de cascada (waterfull).
El proceso de trabajo en cascada constó de los siguientes pasos:
- Formación de una lista de requisitos para el producto.
- Elaboración de un plan, paso a paso, de todas las operaciones.
- Escribir código.
- Control de prueba.
Con este método sucedía lo siguiente: El cliente esbozaba la esencia del pedido, el equipo elaboró un plan de acción y se puso a trabajar (basado en los términos de referencia).
Se probó el producto terminado, en presencia de errores fue necesario reescribir grandes fragmentos de código y por supuesto, esto tomó mucho tiempo adicional.
Este esquema ha estado en funcionamiento durante años, pero en algún momento, un grupo de iniciativa de innovadores logró hacer la siguiente observación:
Los equipos más exitosos que producen resultados de alta calidad y siempre cumplen con los plazos, lo logran a través de un enfoque ágil del proceso.
Como resultado de observaciones a largo plazo, se extrajeron las conclusiones apropiadas y se formuló el Manifiesto para el desarrollo ágil de software.
Su esencia radica en los siguientes cuatro puntos:
- Lo principal en el proceso son las personas y solo entonces, las herramientas.
- La calidad del producto es más importante que la documentación del mismo.
- El entendimiento mutuo con el cliente es más importante que el propio contrato.
- No existe una clara adhesión a un plan (en principio) sino la voluntad de realizar rápidamente los cambios necesarios.
Estas reglas se tomaron como base de un enfoque Agile y un poco más tarde, un grupo de entusiastas describió 12 principios que ahora se utilizan en casi todos los métodos Agile:
- Desarrollar software de alta calidad y que satisfaga al cliente.
- Listos para hacer cambios en cualquier momento.
- Probar el software con mayor frecuencia mientras aún se está creando, logrando así su correcto funcionamiento.
- Organizar reuniones de equipo (esto es más efectivo que simplemente compartir datos).
- Es importante la participación conjunta en el proceso tanto de los desarrolladores como del cliente.
- Debes sentirte libre de confiar en otros para que realice parte de tu trabajo.
- La parte terminada del software funciona correctamente, con un progreso evidente.
- La flexibilidad es importante.
- La flexibilidad proviene de la atención a la calidad.
- Cuando el proceso se simplifica al máximo, se eliminan los pasos innecesarios.
- Los equipos deben ser capaces de autoorganizarse para lograr ser más efectivos.
- Es importante esforzarse constantemente para mejorar la eficiencia.
Jeff Sutherland y Beedle Mike hablaron por primera vez sobre la formación de su propio enfoque flexible para el desarrollo a principios de la década de 1990.
La idea nació sobre la base de las observaciones de cómo los militares, las fuerzas especiales e incluso los atletas de rugby realizan sus tareas.
Conceden gran importancia a la capacidad de trabajar de manera cohesionada, en equipo. Los mismos principios se tomaron como base de la metodología Scrum.
Los autores describieron su desarrollo en el libro Agile Software Development with SCRUM, publicado en 2002.
Entre los desarrolladores, este enfoque es ahora quizás el más popular.
¿Qué es la metodología Scrum?
El principio fundamental del método Scrum es la estrecha interacción entre los miembros del equipo. Scrum se traduce del inglés como lucha, en el rugby existe ese término.
Esto significa que un grupo de desarrolladores también debería poder organizarse, tener en cuenta la experiencia previa, los éxitos, los errores y esforzarse por mejorar. Scrum ayuda mucho con esto.
Básicamente, el alcance de Scrum es la creación de aplicaciones, pero sus principios funcionan bien en una variedad de áreas; razón por la cual el enfoque ha ganado tanta popularidad.
Los roles en el equipo Scrum se distribuyen durante las reuniones, las herramientas se seleccionan de inmediato para organizar y administrar el proceso.
Scrum es, de hecho, un enfoque heurístico. Al comienzo del proyecto, es posible que no se conozcan todas las condiciones, pero los miembros del equipo están constantemente aprendiendo (incluso de su propia experiencia) adaptándose a los cambios y teniendo en cuenta los nuevos requisitos del cliente.
El lanzamiento completo se divide en ciclos cortos y las prioridades pueden cambiar con frecuencia, lo que permite que el equipo aprenda y crezca activamente.
Scrum es una metodología estructurada y flexible que se puede adaptar fácilmente a una variedad de tareas. Las opiniones difieren en cuanto a qué aplicación es la más efectiva. En cualquier caso, los principios fundamentales de Scrum son la transparencia de los procesos, las interacciones y la mejora constante. Todo lo demás depende de cada usuario.
La diferencia entre Scrum, Kanban y Agile
Los conceptos de Scrum y Agile a menudo se confunden entre sí. O se habla de Scrum como una plataforma para implementar el enfoque Agile.
La razón es que en ambos casos, la idea principal es la mejora continua.
Sin embargo, Scrum es una metodología y Agile es un concepto más amplio que generalmente se refiere a una forma de pensar, cuya esencia es que cada miembro del equipo aprenda a mirar de manera diferente tanto el trabajo en sí como el sistema de valores de los clientes.
Esto no es fácil de hacer y puedes comenzar aplicando el método Scrum.
Poco a poco, los principios de Agile se convertirán en un hábito y se convertirán en la base de todo el proceso.
Kanban es uno de los marcos de trabajo del sistema Agile. Pero la esencia del enfoque de Scrum es su estructura y el principio fundamental de Kanban es el equilibrio, es decir, la distribución uniforme de tareas entre los miembros del grupo de trabajo.
No puede ser que alguien esté trabajando y alguien esté sentado sin hacer nada.
Un rasgo característico de Scrum es la descomposición de todo el proceso en sprints para cada uno de los cuales las tareas están claramente definidas.
En Kanban, se pueden agregar tareas a los participantes diariamente. Este es un flujo de trabajo continuo.
En Scrum, se asigna un tiempo específico para la finalización de cada trabajo.
La herramienta principal para administrar el progreso del desarrollo en Kanban son los tableros que muestran en qué etapa se encuentra una tarea en particular.
En Scrum, esto está determinado por el momento en que se completan los sprints, el tablero no se usa en este caso.
Pros y contras de Scrum
Por supuesto, el sistema de gestión Scrum tiene muchas ventajas. Es altamente adaptable, se enfoca en los intereses del cliente y permite cambiar los requisitos mientras se cambian las metas, que por cierto no se garantiza que se cumplan.
Pero a los clientes, por regla general, les gusta la posibilidad de realizar cambios en cualquier etapa del proceso.
Aprender Scrum es fácil. Permite evitar actividades no esenciales, lo que acelera enormemente el proceso de desarrollo.
Al final de cada sprint, tienes un producto funcional en tus manos.
Scrum contribuye a la autoorganización del equipo y ofrece multifuncionalidad, se minimiza la coordinación externa, pero se resuelven todas las tareas al mismo tiempo.
Esta es una herramienta particularmente valiosa para empresas nuevas o pequeñas empresas (no es necesario contratar o traer ejecutivos expertos).
Ahora veamos las desventajas de Scrum más importantes. Los requisitos en Scrum son bastante minimalistas y por lo tanto, bastante estrictos.
Esto socava el postulado de la orientación al cliente, porque al cliente no le interesa en qué tipo de reglas internas se apoya el equipo (y más si están asociadas a restricciones).
Por ejemplo, un cliente puede desear cambiar el trabajo pendiente de Sprint y sus deseos se cumplirán, aunque vaya en contra de los principios de Scrum.
A la complejidad se suma el hecho de que Scrum (que actúa como una herramienta del sistema Agile) no proporciona la elaboración de un plan para las interacciones y el tratamiento de los riesgos.
Como resultado, en caso de violación de las reglas existentes en Scrum, será muy difícil o incluso imposible resolver la situación por medios formales (legales o administrativos).
Otro punto débil de Scrum es el enfoque de la autoorganización y la multifuncionalidad del grupo de trabajo.
Por un lado, los costos de coordinación deberían disminuir, pero por otro lado, los costos de reclutamiento de especialistas, su motivación y capacitación serán crecientes.
Los principios fundamentales de Scrum
Todos los procesos en Scrum están orientados a satisfacer los intereses del cliente, es decir, se debe recibir el producto solicitado al precio más bajo y en el menor tiempo posible.
Así que los principios fundamentales son:
Todo el trabajo se divide en sprints (segmentos cortos)
Durante cada sprint (o ciclo) el equipo implementa una pieza terminada del producto. El proyecto no está planificado como un todo, sino por partes.
Flexibilidad, controles, ajustes
Esto se refiere a pruebas frecuentes (al final de cada sprint) y hacer los cambios necesarios. Los desarrolladores deben estar listos para cambiar la estrategia o la acumulación en cualquier momento.
Estrecha interacción entre el cliente y los usuarios
El cliente ciertamente debe estar involucrado en el proceso. En el enfoque de Scrum, se le asigna el rol de propietario del producto.
Puede realizarlo él mismo o designar a un representante que estará en contacto con los usuarios.
Por cierto, están involucrados en las pruebas casi desde el principio (porque todo el trabajo se divide en etapas cortas).
Tan pronto como pasa la prueba inicial, los usuarios obtienen acceso al producto y el propietario recibe comentarios de ellos.
La tarea del equipo después de eso es corregir las deficiencias y realizar las mejoras necesarias.
Comunicación dentro del equipo
El grupo de scrum debe ser un equipo muy unido de varias personas, unidas por el deseo de objetivos y resultados comunes.
Composición del equipo Scrum
En la mayoría de los casos, el equipo Scrum consta de 5 a 9 personas, a veces, de 3 a 4.
Scrum implica una estrecha interacción entre los eslabones de la cadena y si hay más personas involucradas, ya no será tan productivo, ni tendrá el mejor efecto en el resultado.
Hay tres roles principales en un equipo de Scrum y son:
Dueño del producto
Esta es la persona que ordenó el desarrollo, es decir, el propio cliente o un representante designado por él.
A veces, esto puede ser un representante del mercado en el que se supone que se utilizará el proyecto.
El propietario es responsable de recopilar toda la documentación necesaria. Estos son: Un plan de negocios que indica el resultado económico esperado, un plan de desarrollo (donde se indica el índice de recuperación del presupuesto para cada artículo).
Además, también se forma una lista de requisitos, donde los más importantes van primero y luego, en orden de importancia.
En realidad, todo el equipo está guiado por el propietario como centro de decisión.
Debes estar solo en el proyecto, de lo contrario, estas decisiones ya no se tomarán con la suficiente rapidez.
Esto es lo que debe hacer el propietario como parte de un proyecto Scrum:
- Desarrollar una visión común para el producto.
- Interactuar con el cliente y todas las partes interesadas, gestionar sus expectativas.
- Formar un backlock, priorizarlo.
- Establecer requisitos claros para el equipo que sean fáciles de probar.
- Comunicarse tanto con el grupo de trabajo como con el cliente.
- Al final de cada sprint, aceptar y evaluar el resultado.
Maestro de scrum
Este es un especialista cuya tarea es cumplir con los principios de Scrum en el trabajo.
Además, él mismo debe ser parte del equipo de desarrollo y no solamente controlar, sino participar en el proceso técnico.
Es responsable de establecer una interacción productiva entre todos los miembros del grupo. Supervisa la preservación de su alto rendimiento, resuelve los problemas que surgen, asegura la implementación del horario de trabajo.
Esto es lo que normalmente debe hacer un Scrum Master:
- Contribuir a la formación de un clima de confianza en el equipo.
- Participar en las reuniones generales, establecer una interacción fructífera entre los miembros del grupo.
- Eliminar posibles obstáculos.
- Identificar problemas y otras cuestiones que requieren soluciones.
- Asegurarse de que todas las prácticas del proceso se realicen correctamente.
Desarrolladores técnicos
Es decir, toda la parte técnica del proceso está en ellos. El equipo suele incluir de 5 a 9 desarrolladores. Lo primero que deben hacer es identificar objetivos alcanzables, predecibles, significativos e interesantes para cada iteración.
El segundo es garantizar que estas tareas se completen en cada iteración mientras se cumplen los plazos.
Está claro que los objetivos en diferentes proyectos son muy diferentes, por lo que la comprensión de su logro también diferirá.
En algunos casos, por ejemplo, será el momento en que se escriban todos los códigos y en otros, una de las condiciones será también la realización de las pruebas.
¿Qué debería ser capaz de hacer todo desarrollador? Planificar y evaluar objetivamente los pasos ya dados, comunicarse productivamente con todo el grupo.
Las responsabilidades del equipo de desarrollo son las siguientes:
- Evaluación de los componentes del backlock del producto.
- Crear un producto, proporcionárselo al cliente.
- Participar junto con el Scrum master en la evaluación de su propio progreso.
- Proporcionar al propietario del producto resultados finales.
4 Artefactos de la metodología Scrum
En el desarrollo de Scrum, solo 4 artefactos están involucrados. Eso:
Pila del producto
Incluye:
- Lista de requisitos a cumplir. Si no quedan requisitos en el Backlog, entonces el trabajo en el proyecto está completo.
- User Story (historia de usuario) es una plantilla especial según la cual se establecen los requisitos mencionados.
- La declaración de requisitos debe demostrar claramente lo valiosos que son para el usuario.
- Los requisitos se escriben en orden de prioridad, que se revisa de nuevo en cada etapa (sprint).
Acumulación de sprint
Scrum aborda los requisitos de listado de una manera extraordinaria. Aquí es importante formular todo lo más claramente posible.
Por lo tanto, no solo se escribe una lista de tareas, sino que se crean breves historias de usuarios, cada una con su propia trama y deseos sobre cómo debería resultar el producto final.
Supongamos, por ejemplo, que estamos hablando del deseo de un usuario sobre amazon.es.
Entonces el deseo podría ser algo como esto: “Yo, como consumidor, quiero ir a una gran librería en línea y comprar cualquier libro allí cuando quiera”.
La historia se debe dividir en fragmentos y luego adquirir funcionalidad.
Los siguientes son ejemplos de historias de usuarios para el enfoque Scrum, apropiados para una librería:
- Como consumidor, me será conveniente seleccionar libros, centrándome en ciertos géneros.
- Como consumidor, quiero poder agregar un libro seleccionado al carrito.
- Como administrador de libros nuevos, quiero ver qué están comprando los compradores para poder comprender y navegar por las solicitudes al crear ofertas.
Así es como se pueden ver los deseos de los usuarios y el equipo, debe encargarse de tenerlos en cuenta.
Es importante que la historia tenga un aspecto completo y la posibilidad de implementación práctica, independientemente de otras circunstancias que puedan resultar. Además, es necesario componer la historia de tal manera que se pueda evaluar qué tan factible es. Entonces se puede considerar completa y apta para trabajar.
Otros aspectos que se deben tener en cuenta en este apartado, son:
- Una lista de requisitos que deben cumplirse durante el próximo sprint.
- Los nuevos requisitos creados durante el sprint, no se pueden ingresar a la acumulación de Sprint.
- Los requisitos se dividen en tareas separadas, cada una de las cuales se evalúa.
De hecho, la cartera de pedidos de sprint es una lista de obligaciones que el equipo se compromete a cumplir en las próximas dos semanas.
Estos requisitos se presentan en forma de tareas breves recopiladas en un tablero Kanban.
Objetivo de carrera
Aquí se incluye:
- Un resumen del objetivo del sprint.
- El equipo debe justificar sus decisiones en base a ese objetivo.
Este artefacto permite a los desarrolladores elegir de forma independiente las soluciones más efectivas entre diferentes opciones (cuando hay varias).
El Product Owner debe establecer el Sprint Goal, luego el Sprint Goal garantiza las decisiones tomadas.
Gráfico de evolución de Sprint
Aquí se incluye:
- La traducción literal sería diagrama de quemado o quemado de etapas.
- ¿Qué es exactamente quemar? Horas-hombre o puntos de historia (las llamadas unidades ideales).
- Después de completar una tarea en particular, el diagrama se actualiza inmediatamente.
5 Etapas de trabajo en equipo según la metodología Scrum
Convencionalmente, hay cinco etapas que componen el proceso de desarrollo utilizando el enfoque Scrum.
Etapa 1: Planificación de tareas para cada sprint
El trabajo comienza cuando los miembros del equipo exploran colectivamente la cartera de pedidos general del producto e identifican las tareas para completar durante un sprint en particular.
Es decir, se prepara una lista de tareas (backlog para el sprint) para ello.
La duración de la iteración, la cantidad de trabajo y el resultado final se determinan teniendo en cuenta los posibles retrasos.
Etapa 2: Juntas generales ordinarias
No deben ser demasiado largos (15-30 minutos) y deben tener lugar, por ejemplo, todos los días o una vez a la semana.
Los participantes: El propietario del producto, scrum master y todo el equipo de desarrollo.
Durante una reunión de este tipo se deben responder varias preguntas:
- ¿Qué se ha hecho desde la última reunión y hasta el momento actual?
- ¿Qué se necesita hacer específicamente hoy?
- ¿Qué puede interponerse en el camino de los objetivos?
La tarea del Scrum Master es contribuir a ofrecer posibles soluciones cuando se descubren problemas.
Etapa 3: Formación del tablero de scrum
Se debe colgar en la sala donde se celebren dichas reuniones. El tablero estará dividido en tres columnas: “por hacer”, “haciendo ahora” y “hecho” o similares.
Las tareas se escriben en pegatinas de varios colores que se pegan en la sección deseada del tablero. Lo ya hecho se debe ir trasladando al lugar adecuado.
Entonces, todo el flujo de trabajo para cada sprint se ve lo más claro posible y siempre es visible por todos los miembros del grupo.
Etapa 4: Realizar cambios en la iteración actual
Las actividades deben ser lo más transparentes posible.
Un empleado que no tenga tiempo para hacer su parte del trabajo a tiempo debe informar al propietario del producto al respecto.
Se revisará la asignación de tareas y se distribuirá el tiempo de trabajo para no violar los plazos.
Si algo se completa más rápido de lo planeado, el curso de acción es el mismo: El gerente ingresa nuevos objetivos en la cartera de pedidos y luego todo el proceso se acelera.
Etapa 5: Seguimiento de resultados
Al final de cada iteración, se prueba el software terminado (con la participación de usuarios potenciales representados por el grupo focal).
Según los comentarios recibidos, el propietario considera el curso de acción adicional y toma las decisiones apropiadas.
El equipo necesita alrededor de tres meses para trabajar en Scrum, comenzar a adaptarse y demostrar un rendimiento aceptable.
Si la composición no cambia y algunas condiciones externas insuperables no interfieren, en un año estos especialistas se convertirán en verdaderos expertos, capaces de resolver cualquier tarea compleja sobre la marcha y dedicar mucho menos tiempo que antes de que se aplicara Scrum.
Pero puede llevar años lograr tales resultados si se cometieron errores durante la implementación de Scrum.
Entonces el líder puede abandonar por completo esta técnica, ¿Cuáles son estos posibles errores?
Errores comunes al implementar el método de gestión de proyectos Scrum
Hay varias razones por las que el enfoque de Scrum se revisa negativamente, se lo llama no funcional o ineficaz.
La implementación de Scrum se toma incorrectamente o no se utiliza por completo
Como principal fuente de información fiable, los autores de la metodología apuntan a la experiencia empírica.
El requisito principal en la aplicación de Scrum es su implementación precisa y completa, porque todos los procesos son atípicos pero sin existir un líder como tal.
Una débil motivación del equipo de desarrollo
En cuanto al equipo, en Scrum se hace hincapié en su autoorganización y multifuncionalidad.
Los sociólogos (basados en los resultados de la investigación) argumentan que solo el 15% de los ciudadanos sin discapacidad realmente saben cómo auto-motivarse.
Resulta que solo ellos pueden mostrar una alta eficiencia en Scrum sin cambios en la distribución de los roles de Scrum master y Product Owner.
Pero luego va en contra de los principios de Scrum y como resultado, el método se implementa de manera incorrecta o incompleta.
Los requisitos para el producto tomado en desarrollo son contrarios a los principios de Scrum
Básicamente, Scrum es una creación de Agile, y esto significa que debería ser posible cambiar el Backlog del Producto (es decir, los requisitos del producto) en cualquier momento.
Pero para proyectos de costo fijo/tiempo fijo, este enfoque no es adecuado.
De acuerdo con la ideología Scrum, no tiene sentido planificar todo el proyecto a la vez porque es imposible prever todos los cambios que se avecinan por adelantado.
Aquí, la planificación justo a tiempo (dentro de la iteración actual) se muestra mucho más eficiente y esta no es la única limitación.
Incomprensión inicial por parte de los participantes de las áreas de responsabilidad
Por ejemplo, el propietario del producto no tiene la autoridad suficiente para desarrollar la visión y estructura general del producto: Actúa más como un “analista comercial” y no tiene derecho a rechazar a un cliente.
- No busca conocer mejor los problemas del cliente, por lo que no es capaz de ofrecer las soluciones más adecuadas.
- No revela deseos inútiles o incluso dañinos (para el resultado general) del cliente. Resulta que el cliente, por la falta de una visión normal (fortalecida por los hechos) se pierde y no entiende lo que necesita puesto que el dueño del producto no controla el proceso.
La situación se vuelve más complicada cuando se hace un producto para varios clientes y no se puede llegar a un acuerdo entre ellos.
- Un propietario de producto inteligente y empoderado encontrará la manera de llevar a los clientes a la mesa de negociaciones y llegar a una solución común. Y luego solo tendrá que elaborar una visión común del producto que se adapte a todos y al orden del proceso de desarrollo.
- Cuando el propietario del producto no tiene suficiente experiencia ni autoridad, cada cliente requiere algo diferente del equipo y, como resultado, se obtiene un producto débil, con el que ninguna de las partes está completamente satisfecha.
También surgen problemas debido a un malentendido del alcance de la responsabilidad del Scrum Master.
- Muy a menudo, desempeña el papel de líder de equipo; es decir, distribuye tareas y supervisa su implementación.
- Aún más a menudo sucede así: El maestro de Scrum no distribuye tareas, pero toda la gestión de procesos está colgada de él. Organiza reuniones de Scrum y las dirige (e incluso las diarias, que los propios desarrolladores deberían organizar), toma notas, lleva las decisiones tomadas a los miembros del grupo. Además, él mismo elimina problemas, por ejemplo, habla con empleados “difíciles” que no están de acuerdo con la opinión global, etc.
- Sucede que se asigna un Scrum Master para trabajar con cuatro equipos a la vez (¡al menos!), así es como las empresas intentan ahorrar dinero.
Con este enfoque, el Scrum Master no tendrá tiempo para entrenar o usar otros métodos modernos para capacitar al equipo en autogestión y multifuncionalidad.
Como resultado, Scrum no aumenta la efectividad del equipo, sino que solo agrega más (y completamente innecesarios) formalismos a todo el proceso de desarrollo.
¿Scrum funciona sin Agile?
En muchos casos, la transición a Scrum se ve como tableros de Scrum y cuatro reuniones obligatorias (reuniones diarias, planificación, revisión, verificación de sprint).
Esto es lo que termina sucediendo al final:
- Las reuniones son aburridas porque son similares entre sí y el escenario es inusual para el equipo.
- El tablero se percibe como una especie de elemento extraño (donde ahora todas las acciones deben pintarse al detalle) que han sido reemplazadas por una herramienta de control normal.
A veces, es complicados que todos los elementos de Scrum estén presentes. Hay un tablero, un backlog, reuniones todos los días e incluso un seguimiento de los resultados de las iteraciones.
Pero al mismo tiempo, no se siguen los principios fundamentales de Agile.
Por ejemplo, una demostración de sprint parece un informe para el jefe (y él, por cierto, es una “parte interesada” del producto en la terminología de Scrum) quien, durante la revisión solo reprende a los empleados por desviarse de los puntos objetivos.
En vez de aplicarse en su tarea de buscar soluciones y llegar a acuerdos junto con el equipo, para darles la motivación suficiente.
El propósito de las revisiones de sprint es establecer una estrecha interacción entre los desarrolladores y los usuarios finales o vendedores del producto.
Con respecto al tablero Scrum, debes tener en cuenta lo siguiente:
- Desempeña el papel de una fuente de información visual y máximamente comprensible (sin una acumulación excesiva de detalles técnicos) . El tablero debe estar frente al equipo todos los días y de un vistazo dar una idea de los posibles problemas durante la ejecución del sprint.
- La junta debe reunir a los miembros del grupo. Por ejemplo, se decidió hacer tres columnas en el tablero en lugar de una columna “En progreso”: “Análisis”, “Desarrollo” y “Prueba”. Como resultado, alguien, habiendo hecho su parte del trabajo se quedará inactivo, porque la prueba ya no es su problema. Con este enfoque, existe una alta probabilidad de no completar los sprints y no cumplir con los plazos. Por ejemplo, es en el momento de la prueba que algunos elementos del backlog pueden “congelarse” y todo porque cada uno hace solo “su trabajo” y luego espera a que otros lo hagan (pero ¿dónde está entonces la asistencia mutua?). En principio, este es un enfoque completamente funcional (cuando se asigna una columna separada para cada paso) pero se debe ser consciente de tales riesgos.
El equipo no podrá trabajar rápida e independientemente en Scrum si no hay un pensamiento ágil desde el principio. Entonces, tanto los clientes como los gerentes estarán insatisfechos y el producto no será de alta calidad, ni exitoso.
Debes tener en cuenta que no es suficiente simplemente colgar el tablero (y pensar que ahora ya has implementado Scrum o Kanban) ese es solamente el primer paso.
Luego necesitas reunir a las personas, enseñarles a comunicarse productivamente, interactuar.
De hecho, en Scrum o Kanban, eso es incluso más importante que cualquier otra habilidad práctica.
Más sobre metodologías de trabajo
- ¿Qué metodologías ágiles existen?
- ¿Qué diferencia existe entre Enfoques Ágiles y en Cascada?
- Guía Completa de la Metodología Agile enfocada a la empresa
- 5 ceremonias Scrum: claves para la gestión de procesos
- Mejores Cursos Gratis de Flujos de Trabajo
- ¿Qué es la integración y entrega continua o CI/CD?
- ¿Qué es la interoperabilidad dentro de la Entrega Continua?