De vez en cuando, nuestro producto necesita hacer frente a nuevos protocolos de red que vienen en grandes archivos de especificaciones (~100+ páginas). Por lo general, la recopilación de los requisitos de la especificación no puede ser realizada por una sola persona, ya que es un proceso extenso y propenso a errores. Por otro lado, el equipo de desarrollo se siente desmotivado haciendo este tipo de análisis.
Dado eso, ¿cuáles son las alternativas para recopilar requisitos de grandes archivos de especificación con Scrum? ¿Debería el PM encargarse de ello con un equipo de especificación? ¿O el equipo de desarrollo debería ser más adecuado para este tipo de tareas? ¿El análisis de especificación debe incluirse en el tiempo del sprint o se produce antes de que se pueda aplicar Scrum?
Dado eso, ¿cuáles son las alternativas para recopilar requisitos de grandes archivos de especificación con Scrum?
Me temo que no hay ninguno. Es el propietario del producto, el equipo Scrum o ellos juntos. Otra opción podría ser contratar a un experto que pueda ayudar con la tramitación de la documentación.
¿Debería el PM encargarse de ello con un equipo de especificación?
De forma predeterminada, sí, pero en caso de una gran cantidad de trabajo complejo, es bueno que el propietario del producto coopere con el equipo Scrum.
¿O el equipo de desarrollo debería ser más adecuado para este tipo de tareas?
Yo diría que sí. Parece que tienes que hacer este tipo de trabajo regularmente. Supongo que estas grandes especificaciones son vitales para su negocio, lo que significa que alguien tiene que hacerlo. Si el propietario del producto no es suficiente, el equipo debería ayudar. Tal vez pueda compensar la parte aburrida con algún "día de fedex" como actividades, como que los miembros del equipo puedan elegir lo que harán durante un día.
¿El análisis de especificación debe incluirse en el tiempo del sprint o se produce antes de que se pueda aplicar Scrum?
Si es posible, esta es la mejor solución. Puede procesar iterativamente el documento e implementar las características. Si tiene una acumulación (historias de usuario) para 2-3 Sprints por delante, está bien, y en realidad es lo mejor, porque no genera demasiado desperdicio al definir historias de usuario que pueden no implementarse.
En otras palabras, no es obligatorio procesar toda la especificación de requisitos antes de iniciar el proyecto. Usted crea suficientes historias de usuario para que los equipos puedan comenzar a trabajar y, mientras trabajan, el propietario del producto continúa procesando el gran archivo de requisitos y coloca las nuevas historias de usuario en la cartera de pedidos.
Me gustaría abordar la parte "desmotivadora" de su problema. La herramienta más efectiva que he encontrado para abordar este tipo de problemas es dividir el tiempo que los desarrolladores dedican a actividades que no son de desarrollo. Lo curioso de los programadores: la mayoría de ellos solo quieren programar. Ellos no quieren hacer doc. Ciertamente no quieren hacer control de calidad. Y la mayoría de ellos no están interesados en cumplir con los requisitos.
Pero en los casos en que hay una gran cantidad de material que debe procesarse para los requisitos, es mucho más aceptable para los desarrolladores si lo hacen en partes. Esto puede funcionar o no con el documento de 100 páginas que se le presenta. Es posible que deba revisarlo todo y proporcionar estimaciones de tiempo a la gerencia lo antes posible. En ese caso, no hay mucho que puedas hacer.
Y vea si puede trabajar con el equipo que le proporciona estos documentos. Si les dice que está tratando de dividir las cosas para hacerles la vida más llevadera a sus desarrolladores, es posible que puedan estructurar el documento de manera un poco diferente para respaldar sus esfuerzos.
Además, intente el enfoque de "emparejamiento" de XP para este problema. El emparejamiento toma dos programadores medianos y los convierte en un solo mejor programador. Muchas veces a las personas no les gusta hacer algo porque sienten que no son buenos en eso o no están seguros de sí mismos. Si empareja a los desarrolladores para masticar varias piezas del documento de requisitos, se autoorganizarán y optimizarán para sus propias fortalezas y debilidades. Podría introducir un poco de competencia y energía en un proceso que de otro modo sería aburrido.
Depende de quién esté disponible para ti, por supuesto, pero creo que es una buena experiencia para los desarrolladores hacer esto. A medida que se realiza este análisis, es de esperar que estén contemplando el diseño y, en última instancia, propongan un mejor diseño. Estoy de acuerdo en que es posible que deba hacerse en lotes más pequeños si es posible, para evitar el agotamiento y la desviación de la atención.
He sido desarrollador durante más de 25 años y tengo poca tolerancia con los desarrolladores que "solo quieren hacer código". Por supuesto, vengo de un entorno de pequeña empresa donde es necesario llevar sombreros diferentes. En mi experiencia, siempre es beneficioso probar diferentes roles, para que puedas ver el trabajo desde una perspectiva diferente.
Habiendo dicho eso, el Product Owner debería al menos confirmar el nivel de soporte para la especificación (si hay variaciones).
andres claro