Somos una pequeña empresa emergente que está creciendo rápidamente.
Tenemos 4 departamentos: (Desarrollo backend [2 pers], Desarrollador frontend [2 pers], Control de calidad [2 pers] y un administrador de sistemas)
Antes de usar la metodología Scrum, no teníamos una idea clara sobre nuestro progreso, en qué estaban trabajando los demás, etc. Ahora superamos este problema, pero ahora enfrentamos un gran problema; parece que el equipo no se conforma con la metodología actual.
Para darle una visión clara de nuestro caso, así es como procedemos a manejar un proyecto:
Tenemos una reunión de trabajo pendiente con el propietario del producto. El equipo define el trabajo pendiente de lanzamiento en otra reunión (basándose en la prioridad establecida por el propietario del producto). Cada departamento divide el trabajo pendiente de lanzamiento y enumera todas las tareas que deben realizarse en el siguiente sprint. Por ejemplo, el grupo de back-end comenzará a trabajar en una API, el front-end se ocupará de los diseñadores y preparará las plantillas listas, el equipo de control de calidad leerá y comprenderá las historias, y los administradores del sistema deben definir la próxima prioridad de acuerdo con el proyecto actual.
Cada departamento crea su propio sprint. (Es raro, lo sé :s) y al final tenemos 5 sprints. (El quinto es para empresarios. Bueno, quieren ser parte de la metodología, jajaja).
Antes de comenzar a usar Scrum, estábamos respetando un ciclo de dos semanas, y después de implementar Scrum, el gerente del proyecto sugirió que los sprints se deben realizar en dos semanas. Sin embargo, acabamos de descubrir que un sprint puede tardar más :s.
Según nuestro caso, tengo una lista de preguntas que me vienen a la cabeza.
¿El control de calidad, el backend, el frontend y la administración del sistema se ajustan a la metodología Scrum? ¿Qué podemos hacer si el control de calidad y la administración del sistema tienen tareas diarias? ¿Podemos usar solo un Sprint en lugar de 5?
En Scrum tradicional, todos estos roles se consideran parte del mismo equipo Scrum. Los elementos del backlog de la versión se mueven al backlog del sprint cuando todo el equipo los compromete (independientemente de la función que tengan los miembros individuales del equipo) y luego los asignan (nuevamente, todo el equipo).
La razón por la que scrum generalmente no separa las áreas funcionales del equipo es 1) solo porque usted es control de calidad no significa que no tenga algo para contribuir a las discusiones de los desarrolladores y 2) todos están trabajando en lo mismo producto y debe tener alguna vista/entrada en el producto como un todo para que pueda detectar cualquier conflicto entre las áreas funcionales. Sus desarrolladores front-end necesitan saber qué están haciendo sus desarrolladores back-end y viceversa, por ejemplo.
Donde las áreas funcionales realmente entran en juego es cuando los miembros del equipo extraen elementos de su carril 'No iniciado' de su muro de tarjetas. Si soy un tipo de control de calidad, primero voy a sacar tareas para trabajar que sean específicas de control de calidad. Si soy un desarrollador front-end, voy a realizar tareas en las que trabajar relacionadas con la interfaz de usuario. Depende de cada miembro individual del equipo trabajar en elementos relacionados con su área funcional.
La pregunta que siempre viene después es: ¿Qué pasa si no quedan tareas para mi área funcional? La respuesta es: prueba otra cosa. Si nadie está trabajando en ello, no te hará daño intentarlo. Eso no solo le dará una idea de cómo funcionan las otras áreas funcionales, sino también cómo funciona su producto en áreas que quizás no vea regularmente. Siempre puede entregar la tarea a alguien de esa área funcional más tarde (cuando esté disponible) y habrá aprendido algo de la experiencia.
Eso es scrum tradicional, que es como se formuló la pregunta. Si está buscando consejos específicos para su escenario, esa es una discusión completamente diferente y entrará en las razones por las que está haciendo las cosas de la manera en que lo hace.
Pasarse a Scrum es difícil ya que no es tan simple como tener un equipo, la parte difícil es hacer que los miembros del equipo trabajen juntos como una sola unidad (un equipo) y romper los viejos hábitos de trabajar de forma aislada. Es mucho más fácil decirlo que hacerlo en realidad.
Esta es la razón principal por la que tenemos sprints cortos y una retrospectiva, lo que permite al equipo inspeccionar cómo trabajan juntos y buscar formas de mejorar. El Scrum Master debe estar atento a estos problemas de comportamiento y mencionarlos en retrospectiva, preguntándole al equipo cómo van a cambiar su forma de trabajar.
Estos son algunos pero todos los problemas comunes que veo con los nuevos equipos; pueden o no aplicarse a usted.
El equipo está pensando como títulos de trabajo y no como responsabilidad conjunta de hacer
No existe una definición clara de hecho que impulse la calidad.
Los equipos no se organizan a sí mismos y Scrum Masters o gerentes aún intentan controlar el equipo.
Los equipos no aprenden a inspeccionar y adaptarse, sino que simplemente circulan los mismos problemas
Los probadores creen que son los únicos responsables del control de calidad.
Scrum Masters no busca debilidades y oportunidades para mejorar, luego las presenta al equipo; preguntando al equipo cómo lo arreglarán
A los miembros del equipo no se les ha explicado Scrum
Las herramientas suelen ser deficientes en muchas empresas, lo que impide que los equipos adopten buenas prácticas
Inicialmente, Scrum resaltará muchos problemas, pero muchos se ignoran
Los maestros novatos de Scrum no reconocen la diferencia entre cambios buenos y malos, ya que no han aprendido las lecciones difíciles.
Incorporar Scrum a una empresa requiere un entrenamiento muy sólido por parte de profesionales capacitados y experimentados. El cambio organizacional es una olla de pescado diferente y no debe hacerse sin la experiencia adecuada.
El concepto principal detrás de scrum es reunir a todos (DB, UI, Dev, QA). Esto funciona de maravilla ya que ahora el desarrollador sabría qué problemas enfrenta el control de calidad durante las pruebas y estaría más atento a los problemas que normalmente ignoraría antes de pasarlos al control de calidad. Del mismo modo, el control de calidad sabría cómo funciona el desarrollo día a día y ayudaría. Esto proviene del principio de responsabilidad conjunta de scrum. Todo el equipo es responsable de la entrega. No puedo decir que la entrega falló porque el desarrollo se completó tarde o el control de calidad no terminó a tiempo.
Todos comienzan a pensar en las mejoras que pueden hacer al sistema y eso contribuye al éxito del equipo. Reunir a todos sus equipos rompería los silos que pueden existir. Hay un buen preso sobre la mentalidad de equipo de Linda Rising aquí .
La metodología que estás usando se llama ScrumBut.
http://www.scrum.org/ScrumBut
En cuanto a mí, está bien hacer cualquier modificación en Scrum para obtener un entorno más cómodo para el equipo. Pero, después de hacer esas modificaciones, ya no lo llames Scrum.
Solíamos seguir el proceso Scrum en nuestro proyecto. La experiencia fue horrible. Luego, durante un año hicimos muchas modificaciones. Todavía tenemos retrospectivas, reuniones de planificación (ad-hock), sprints de dos semanas, una pequeña acumulación, demostración al final del sprint. No medimos la velocidad y tenemos sprints adicionales para pruebas de regresión y corrección de errores. Unimos Demo y retrospectiva juntos.
Como probador, no tengo la oportunidad de realizar pruebas profundas para la función que se completó 2 horas antes de la demostración final, por lo que estoy hablando de eso en la reunión Demo+Retrospective. Por lo general, tomo esos días de prueba del próximo sprint.
Eso no es Scrum, pero eso funciona para nosotros.
Ampliando lo que @NightMan y @Nikhil Gupta escribieron en sus respuestas: puede ser muy contrario a la intuición para usted y su equipo, pero únalos a todos como un solo equipo y trabajen en un Sprint.
Sí, será difícil al principio, pero creará un sentido de objetivo común y, sobre todo, comenzará a mejorar su organización.
Algunas de las áreas de ejemplo que cambiarán/mejorarán:
Problema: no podemos hacer esto durante el mismo Sprint ya que terminamos de codificar 10 minutos antes de que finalice el Sprint . Solución: Introducir la automatización de pruebas, los desarrolladores y evaluadores desde el comienzo de la codificación de un elemento del Backlog en particular también automatizar las pruebas , ya que casi no hay forma de obtener suficiente tiempo para realizar las pruebas durante el Sprint. A largo plazo obtendrá un gran beneficio de productividad.
Problema: No podemos poner a nuestro DBA como parte del equipo Scrum, él/ella es un "recurso compartido". Solución: inclúyalos aunque sea parcialmente en el equipo y déjelos emparejarse con otros miembros del equipo, con el tiempo comenzarán a adquirir parte de su conjunto de habilidades y no dependerán tanto de una persona en particular.
La conclusión es: consígalos como un solo equipo, pruébelo y se sorprenderá de cuánto se beneficiará de ello.
He dirigido equipos muy similares antes y lo que he encontrado es increíblemente vital: hacer que todos los roles funcionen como el mismo equipo.
En primer lugar, creo que definitivamente deberías dirigir un solo equipo. La razón es esta: los miembros de su equipo están trabajando hacia un objetivo común. Todo lo relacionado con la estructura de su equipo debería funcionar en ese sentido. Un solo equipo de scrum tiene compromisos comunes en sus objetivos de sprint, una fecha límite común y necesitan trabajar juntos para lograrlo. Si agrega separación artificial, le pide a la gente que juegue el juego de la culpa. No puedo contar la cantidad de veces que escuché cosas como "Bueno, está hecho, simplemente no se ha probado" o "No pudimos hacer nuestro trabajo porque Bob estaba enfermo y no configuró el servidor". Claro, eres más eficiente cuando dejas que las personas se centren en su área de especialización, pero cuando todo el equipo está comprometido por igual con el cumplimiento de los objetivos, descubres que hay
En segundo lugar, creo que perderá gran parte de la ventaja del scrum. Para leer un poco sobre su caso, menciona que el equipo de BE está trabajando en la API. Si esto se hace de forma aislada del equipo de FE y del grupo empresarial, ¿cómo eligen lo que escriben? Puede ser muy difícil mostrar que al final de cada sprint están entregando un conjunto de funcionalidades liberables que brindan valor al cliente final. Esta es una situación que he visto demasiadas veces. Cuando se me preguntó qué valor está creando el trabajo, escuché "Bueno, ninguno en este momento, pero en junio, cuando todo lo demás esté hecho, será bastante clave". Esto es genial mientras lleguemos a junio. He sido parte de algunos proyectos que se cancelaron antes de tiempo y la compañía estaba muy frustrada porque habían desperdiciado todo el tiempo del proyecto y no habían obtenido nada de él.
Espero que esto ayude.
Eso suena demasiado interesante... Siempre enfrentará algunos obstáculos cuando migre a SCRUM... Para resolver el problema al que se enfrenta...
Shannon Davis
Luceos
Ravi Parek
Ravi Parek