¿Cómo maneja el trabajo no funcional con Scrum en sistemas integrados?

Está utilizando una metodología en un producto que no es compatible con IMHO.

En la forma en que la mayoría de las personas define ágil, todo el trabajo es negociable en función de las prioridades cambiantes, reordenables o reemplazables.

La forma en que la mayoría de la gente define la cascada es que el trabajo se presenta en secuencia de antemano desde un esfuerzo significativo de arquitectura al principio.

La tarea que enumeras arriba me parece muy catastrófica, tienen que estar en un cierto orden y no son negociables.

No estoy diciendo que tengas que respetar el punto de vista de nadie de ningún proceso, pero al menos para estas tareas parece que estás en un proyecto no ágil para mí. Tratar de golpear eso en un proceso ágil va a ser un ajuste descuidado en el mejor de los casos.

Si el resto del proyecto se adapta bien a ágil, no me preocuparía demasiado que la configuración inicial sea mala, pero el hecho de que menciones RTOS y las placas de desarrollo me hace sospechar que todo irá mejor. en algo más como cascada (una larga secuencia de dependencias inamovibles).

Bien, no sé nada sobre la construcción de sistemas integrados, pero por lo que puedo ver, no hay nada que haga que Scrum sea inapropiado para tal desarrollo. Es fácil quedar atrapado en preocuparse por no tener realmente la funcionalidad de usuario enfrentada, por lo que es difícil escribir "historias de usuario" con tener usuarios. Excepto que las historias de los usuarios no son realmente parte de Scrum, a menudo se usan con Scrum, sino en realidad como una herramienta.

Lo que forma parte de Scrum es la idea de ofrecer funciones completas que se hayan probado y puedan implementarse en un entorno real en cada Sprint. Cuando comienza desde cero el primer día de cualquier tipo de proyecto, el valor real de cualquier tipo de funcionalidad que pueda ofrecer en Sprint 1 es bastante pequeño. Eso se debe a que cada cosa pequeña necesita toneladas y toneladas de infraestructura construida para que funcione. Pero el punto es que solo construyes suficiente infraestructura para hacer que cada característica funcione. Y luego lo desarrollas a medida que agregas más funciones.

La idea es que NO pases meses y meses construyendo una infraestructura que no tiene forma de ser detectada desde fuera del sistema. ¿Por qué? Porque hasta que no construyes las cosas que realmente hacen cosas, no sabes exactamente qué debe ser la infraestructura. Eso es lo que aprendes a medida que construyes las características reales del sistema. Si construye la infraestructura al principio, entonces la está construyendo cuando sabe menos acerca del sistema.

Si no tienes tiempo para escribir historias de usuarios, recuerda que los usuarios no tienen que ser personas. Entonces, escribe cosas como: "Como un controlador de interrupciones CMOS, necesito poder detectar el estado del indicador de modulación de la pila de Bingle Whozzit cuando el compresor fluxotronic señala una carga insuficiente de bypass pasivo". Absolutamente no escribas "Como desarrollador ..." historias de usuarios.

Usas Scrum en un área muy específica y violas el supuesto proceso en cada paso. Su pregunta probablemente debería ser: ¿Existe otra metodología ágil que se ajuste mejor a mi entorno? Simplemente es muy difícil ayudarlo a mejorar Scrum si su entorno no lo permite. Los problemas que veo en tu descripción:

• No hay tareas demostrables que puedan considerarse tareas de infraestructura. Si necesita varios sprints para hacer algo que no se considera un valor comercial, es probable que sus historias de usuario estén mal definidas. Si necesita crear una herramienta o cualquier otra cosa para poder entregar valor comercial, entonces el producto se puede dividir en dos partes / lanzamientos: crear una herramienta y crear un valor comercial. En tal caso, sus historias de usuario "Como desarrollador ..." serán completamente válidas porque la herramienta se crea para los desarrolladores. El problema aquí es cómo comunicar esto al cliente porque su participación en la primera versión es cero. Si no hay valor comercial para los clientes, ¿cómo pueden participar? ¿Cómo puede el propietario del producto definir la prioridad comercial? Creo que el principal problema aquí es que esto no es algo que se ajuste a Scrum. Scrum intenta entregar primero las funciones comerciales más importantes, pero necesita dos meses para entregar la primera. Scrum y Agile integran el cambio: ¿qué ocurrirá si después de entregar las primeras funciones, el cliente requiere algún cambio que se remonta a todos los sprints iniciales?
• Pruebas. Otro fracaso porque el equipo en Scrum se considera como un grupo de miembros de funciones cruzadas. Significa que todo el mundo hace desarrollo y prueba y, debido a eso, no hay situaciones descritas en su punto final (o al menos 5 días de duración). No significa que no pueda haber un control de calidad separado para realizar pruebas más complejas y sofisticadas, pero el equipo debe proporcionar una función ya probada / verificada. En su caso, realmente parece que Scrum no es lo que necesita. Usted necesita que el desarrollo se maneje por separado y las funciones de prueba y aprobación entre ellos.