metodologia - Scrum: ¿un buen método solo para equipos con desarrolladores "a tiempo completo en sprints"?

scrum significado (9)

Somos una empresa de desarrollo de software. Hemos introducido Scrum.
El problema es que los desarrolladores no pueden dedicar tiempo completo a Scrum Sprints como muchas otras compañías. ¡Tienen que hacer un montón de no-desarrollo, fuera de las tareas del proyecto SCRUM!
He leído eso: Scrum no permite desarrolladores a tiempo parcial

Entonces, ¿cuál es tu experiencia al respecto?
¿Es Scrum un buen método solo para equipos con desarrolladores que solo dedican tiempo a las tareas de desarrollo centradas en los sprints de SCRUM?

Gracias por tu tiempo

¿No veo cómo Scrum no permite temporizadores parciales? He estado en muchos equipos de scrum y casi siempre tenemos un recurso que no es de tiempo completo. O tenemos un recurso que se divide entre un par de proyectos. Manejamos esto haciendo que el desarrollador dedique un tiempo específico al proyecto y planeamos alrededor de ese tiempo asignado. Las soluciones de gestión de proyectos más ágiles permiten este estilo de gestión de recursos.

Aunque no tengo el mayor kilometraje con SCRUM, pero la regla general es que cuando SCRUM no funciona tan bien como debería, generalmente se debe a que el sprint está demasiado centrado y el equipo tiene muchas tareas y responsabilidades que se extienden más allá del alcance del sprint. Que no se tienen en cuenta. Como tales, estas tareas son percibidas como una molestia por el equipo dentro del scrum y el scrum percibido como una molestia por las personas que quedan afuera.

Aún no hemos probado SCRUM por completo, sin embargo, hice algunas experiencias aquí de muchas maneras en que se pudo implementar y los mejores resultados fueron cuando el equipo incluyó personas de varios departamentos (Prueba, Control de calidad, Implementación, Desarrollo, Arquitectura, Marketing). Esto implica que estas personas no están a tiempo completo en el equipo, pero el hecho de que tengan tareas asignadas en el ámbito del proyecto actual significa que, por lo general, están más dispuestas a dedicar tiempo al mismo.

El siguiente gran beneficio es que es posible reservar algo de tiempo de búfer para incógnitas, como dev devoluciones pero críticas. Cuando esto ocurre, un equipo más pequeño se forma y sale temporalmente del scrum principal para resolver el problema.

Finalmente, cosas como instalaciones, configuraciones, etc. son parte del scrum y, como tal, están relacionadas con él.

Otro enfoque que intentaré a continuación es extender la idea para que, en lugar del enfoque de scrum-to-the-regla-todos, intente establecer equipos más pequeños para cada necesidad específica. El principal problema con esto por ahora es que no muchas personas pueden asumir el rol de scrum master, por lo que no es más pollo y huevo.

En una nota más general, usé SCRUM aquí, pero nunca aplico cosas por el libro. Considero estas técnicas y enfoques como grupos de ideas a partir de los cuales se puede experimentar para obtener la mejor combinación posible para nuestras necesidades. Sin embargo, para que esta experimentación funcione, a veces tiene que hacerse de forma subversiva (usted hace scrum pero nunca formaliza que lo hace). Creo que es la mejor manera de suavizarlos para adoptar nuevos enfoques y eliminar más fácilmente la resistencia al cambio inherente con la que siempre nos enfrentamos.

Hasta ahora, al hacer esto, el flujo de trabajo evoluciona de forma natural hacia el tipo scrum-XP-agile-TDD y lentamente hace que eviten la terrible cascada en la que están tan invadidos. Con suerte, con el tiempo se darán cuenta de que el césped es mucho más verde en mi lado de la valla :-)

Defina un factor de enfoque , la proporción de tiempo que cada desarrollador puede trabajar solo en el contenido de Sprint. Este factor de enfoque representa el tiempo que no puede trabajar en los elementos de Sprint (correo electrónico, asistencia, reuniones ...).

En Sprint Planning, solo planea lo que se puede lograr de acuerdo con ese factor de enfoque: si el Equipo tiene 600 horas al 80%, solo planificarás 480 horas.

El valor inicial se puede decidir de forma arbitraria o en función de lo que se logró durante el Sprint anterior: 60 días planificados y 45 días completos dan un factor de enfoque del 75%.

Luego se trata de la administración del tiempo, si las tareas que no son de Scrum no son interrupciones, entonces es mejor tenerlas al mismo tiempo (por ejemplo, el viernes, todos los miembros del equipo trabajan en estas otras tareas, no en las tareas de Sprint).

Este factor de enfoque no tiene que ser idéntico para cada miembro del equipo. Esto también permite tener un miembro a tiempo parcial en un equipo.

Donde trabajo, hemos hecho que los desarrolladores se retiren del proyecto para cosas como solicitudes de soporte o el líder del equipo tiene reuniones sobre otros proyectos, por lo que hay veces en que alguien dice "No proyecto", por lo que se comunica que esta persona no está Actualmente contribuimos al Sprint.

En nuestro equipo tenemos tareas de soporte incluidas en el sprint. Para cada sprint, calculamos cuánto tiempo de soporte necesitará cada uno de los productos y los agregamos como tareas en el sprint. De esa manera, el sprint no sufre, a menos que la demanda de soporte sea mucho mayor de lo esperado (lo que, por supuesto, puede afectar el tiempo reservado para el soporte en los próximos sprints).

Estoy trabajando para una empresa donde esto también es un problema. Estamos tratando de usar Scrum, pero tenemos problemas con lo siguiente:

Si hay un problema de soporte importante, tenemos que abandonar todo lo que hacemos para resolver ese problema, arruinando el sprint.
La administración llega directamente a algunos desarrolladores con tareas específicas que desean realizar.
Algunos desarrolladores tienen tareas específicas que deben realizar de vez en cuando (llámenlo al soporte técnico de productos antiguos específicos)
A veces, uno de los desarrolladores se elimina del sprint para realizar una instalación importante.
Los equipos han cambiado a menudo, basados en ideas de mejora de la administración.

Con todas estas cuestiones es imposible hacer Scrum por el libro. La velocidad para cada sprint es básicamente inútil cuando la cantidad de personas en el equipo cambia todo el tiempo.

Todavía he encontrado que obtienes algunos beneficios:

Las personas trabajan en equipo y se inspiran y potencian con eso.
Las tareas que aún pasan por el sprint son mejores que si Scrum / sprints no se utiliza en absoluto, ya que el ciclo de retroalimentación es mucho más corto que cuando no se realizan sprints. El consenso ahora es que dos semanas es un buen momento.
A lo largo del tiempo, la velocidad parece promediarse después de todo, lo que brinda al menos la capacidad de la gerencia para tener una idea de cuánto trabajo se puede hacer durante un período de tiempo más largo.

Mi sugerencia es por lo tanto ir a Scrum. Al igual que en mi empresa, cuando la administración y los desarrolladores comienzan a ver algunos de los beneficios de los ciclos cortos, etc., comenzarán a hacer cambios para que la mayor parte del trabajo que se considera no una tarea de sprint se convierta en una tarea de sprint después de todo . Así que todavía veo los beneficios de tratar de hacer Scrum. De todos modos, no hay una forma 100% correcta de hacer Scrum, no importa lo difícil que sean algunos libros.

Hay muchos enfoques para scrum, honestamente no he visto una compañía que haga scrum "puro". Si puedes organizar bien tu scrum, puedes obtener ganancias de esto. Pero debes pensar por qué quieres cambiar tu proceso a scrum, maby no tiene sentido.

Creo que deberías probar scrum y ver si valió la pena.

La eficiencia viene de poder concentrarse en las tareas incluidas en el sprint. No es algo que otro modelo de desarrollo pueda solucionar. Pero a los desarrolladores a los que se les asignan "otras tareas" todavía son una realidad, como soporte, capacitación o preventa técnica.

El soporte es inherentemente impensable para la mayoría de los lugares. La capacitación y la pre-venta tienden a ser algo más de tiempo, como en "El Sr. X pasa N días con el cliente".

Le sugiero que intente dividir a los desarrolladores en dos o más equipos. Tener la tarea de tomar apoyo durante este ciclo de sprint entre equipos. Ese equipo solo debe tener tareas que uno pueda permitirse fallar en cumplir. Debe hacer todo lo posible para resolver los problemas de soporte sin interrumpir a otros equipos.

Hemos visto buenos resultados con esto.

El conocimiento se difunde cada vez que hay algo que el equipo de soporte no sabe, reúne información de otros equipos. El equipo de soporte sigue siendo el equipo que responde a los tickets de soporte y aprende mientras lo hace.
Los equipos sin soporte pueden trabajar mucho más enfocados en sus tareas. No tener que cambiar de tareas es muy productivo.
El tiempo real empleado en soporte y eventos no planificados recibe un número en las horas dedicadas a él.

Parece que la administración descrita no está realmente en el barco con scrum. Sugiero sprints muy cortos, 1 semana más o menos. Por lo tanto, cada vez que obtenga un agente de ventas o una gerencia que quiera interrumpir, pruébelo si puede esperar para que se lleve a cabo su tarea y hacer el próximo sprint que está a menos de una semana. Scrum no debería ser algo que los desarrolladores estén haciendo solos. Necesita estar en toda la cadena para el cliente.

Muy buena pregunta por cierto. He visto esta afirmación: "todos los miembros deben estar a tiempo completo" en casi todos los artículos, artículos, libros, etc. Tengo rojo en Scrum, pero aún no he visto ningún argumento sobre por qué este es el caso. Espero que tengas desarrolladores que no hagan nada más, pero en organizaciones pequeñas debe ser muy común tener desarrolladores que no puedan comprometerse al 100% en el sprint, ¡y Scrum está diseñado para equipos pequeños! El factor de enfoque debe ser capaz de manejar esto como cualquier otra cosa.