¿Cómo hacer que Scrum funcione para un equipo con roles definidos?

En realidad, su forma actual de trabajar no está tan alejada de Scrum como podría pensar.

En Scrum, también obtiene un conjunto inicial de requisitos, los implementa y demuestra el resultado. En función de la demostración, se le pueden dar nuevos requisitos o los interesados pueden decidir que el producto es lo suficientemente bueno como para que no haya más desarrollo. es necesario.
En su situación, al "cliente" del que habló se le podría asignar el rol de Product Owner en Scrum (parece que ya cumplen ese rol al establecer las prioridades dentro de un proyecto y decidir cuándo está listo para ser implementado). br> Un gran cambio podría ser la duración de una iteración. En Scrum, una iteración debe durar entre 1 y 4 semanas.

En cuanto a la composición del equipo y la falacia del uso de todos los oficios: Scrum no no requiere que todos sean un tipo de intercambio de oficios. Scrum solo requiere que el equipo en su conjunto tenga todas las competencias necesarias para obtener el producto de una lista de requisitos a algo que se haya implementado o pueda implementarse.
En su situación, podría ver fácilmente un equipo por proyecto compuesto por uno o más desarrolladores (que realizan principalmente el trabajo de implementación y prueba) y un miembro del "personal de implementación" que se centra principalmente en crear los manuales y el material de capacitación para las características que los desarrolladores están implementando.

Una vez que el cliente / propietario del producto haya dado luz verde para la implementación, el trabajo para el equipo de scrum se realizará en su mayor parte, de modo que los desarrolladores puedan ir a otro proyecto (y estar disponibles solo a pedido para solucionar problemas posteriores a la implementación) y el personal de implementación puede cambiar a realizar la capacitación y apoyar el despliegue.

El hecho de que haya una fecha límite no es un problema real, siempre que haya suficiente flexibilidad en lo que la funcionalidad debe estar en esa versión.

Pides alternativas, así que voy a decir eXtreme Programming (XP). Específicamente, creo que la programación en pares podría ayudarlo aquí.

Al juntar a personas con diferentes habilidades, no importa en qué habilidad: hacer café, hacer pruebas, entrenar, etc., puedes distribuir las habilidades en todo el equipo.

Pero para ser honesto, no suena como SCRUM está tan lejos para ti. Parte de SCRUM es ser flexible y encontrar lo que es mejor para su equipo. Parte de XP es respetar a tu equipo y adaptarse. Tal vez dentro de 100 años tengamos una profesión más desarrollada con reglas duras y rápidas (aunque lo dudo) pero por ahora, todo lo que tenemos para ti es hacer lo que te funciona. Lo importante es tener bucles de retroalimentación. Si algo no funciona, entonces el equipo debe discutir eso e intentar cosas nuevas hasta que encuentren algo que funcione.

¿Cómo hacer que Scrum funcione para un equipo con roles definidos?

Solo hazlo. De acuerdo con la guía scrum , todos somos desarrolladores, pero aquí en el planeta Tierra, diferentes personas aportarán cosas diferentes al mesa. I casi se linchó cuando sugerí que algunas personas son realmente probadores mientras que otros escriben el software.

Algunas cosas que podrías querer abordar:

Impresiones

Parece que tienes una fase de desarrollo inicial seguida de una serie de lo que son aparentemente sprints. Considera romper esto. No solo el cliente verá algo temprano, sino que también obtendrá una mejor idea de los hitos de desarrollo a medida que se producen.

Plazos fijos

Esto surge una y otra vez y, de hecho, es una espina persistente en el lado de los desarrolladores donde trabajo actualmente. Scrum establece estimaciones para el sprint, nada más. Sí, puede alcanzar el objetivo después de una serie de carreras de velocidad, pero una vez que el cliente tenga interés en las versiones anteriores, es probable que el alcance se incremente significativamente. Esto no es un problema en sí mismo, pero se debe informar al cliente de que se realizarán más trabajos en las etapas posteriores y que están por encima de los requisitos conocidos.

Su situación podría ser una mejor combinación para Kanban, ya que puede comenzar con lo que tiene e iterar desde allí. Esto significa que no tendría una gran introducción que interrumpa sus proyectos actuales; simplemente comience visualizando las tareas en una pizarra y adoptando algunas de las prácticas, como retrospectivas y reuniones diarias.

Tienes que ser un poco más cuidadoso que con Scrum porque no es tan prescriptivo: por lo que tiene una tendencia a desviarse a lo que fue antes en lugar de inculcar una mentalidad ágil adecuada.

Scrum no funciona bien con proyectos separados que se superponen, ya que no tienes un conjunto estable de personas trabajando en un proyecto para el sprint completo. Por lo tanto, es probable que conceptos como verbosidad, etc., simplemente te depriman.

Pero primero tome la historia que le da el mejor costo / beneficio al cliente, e implementándola, incluyendo pruebas completamente automatizadas, a una calidad que sea lo suficientemente buena para ser implementada, antes de trabajar en la siguiente historia es un concepto útil. Del mismo modo, se requiere que todo el código escrito para una historia sea revisado por otro desarrollador antes de que la historia se considere "hecha".

Supongo que el personal de implementación debe escribir los documentos de capacitación y de referencia, se pueden escribir (primer borrador) para cada historia antes de que se escriba el código, convirtiéndose en las pruebas de aceptación.

Espero que encuentre que al comienzo de cada proyecto donde los aportes del personal de implementación sean de gran ayuda para los desarrolladores, están 100% comprometidos con la implementación del proyecto anterior. Por lo tanto, considere si el personal de implementación puede estar trabajando en escribir las historias y la documentación del usuario para el próximo proyecto, mientras que los desarrolladores están escribiendo el código para el proyecto actual.

El "desarrollo impulsado por el comportamiento" con el personal de implementación que escribe el ejemplo que se usa en las pruebas puede funcionar.

Así que hay un poco de Scrum que te ayudará, pero intenta utilizar Scrum en lugar de usar Scrum.