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

Tengo dos problemas con Scrum en sistemas integrados. Primero, hay muchas tareas que hacer, especialmente en las primeras etapas, que no son demostrables. Comenzamos con una placa de desarrollo, sin sistema operativo, sin pantalla, sin comunicación en serie, etc. No tuvimos nuestra pantalla para seis sprints.

Los primeros cuatro sprints fueron:

• Poner en funcionamiento el RTOS
• Crear tareas para escribir controladores de red y en serie
• Escribir rutinas de interrupción para botones, comunicación, etc.
• Escribir las clases y métodos de la base de datos primaria
• Escribir un menú de depuración en serie

La mayoría de estas tareas no son adecuadas para historias de usuarios. De hecho, la única interfaz en todo el sistema era el menú de depuración en serie, integrado en el sprint 3, por lo que no había nada que demostrar al final de los sprints. Incluso el menú en serie estaba destinado a uso interno y no a un usuario final. Sin embargo, todavía quiero rastrear y administrar estas actividades de desarrollo a través de Scrum.

Terminamos escribiendo frases de "historias de usuarios" como "Como desarrollador ...", algo con lo que no estoy contento, pero al usar Target Process (www.targetprocess.com), no existe el concepto de un elemento acumulado que sea una tarea o tarea

En segundo lugar, ¿cómo maneja las versiones y las pruebas? Es un verdadero dolor para nosotros porque los probadores no tienen los depuradores de hardware, por lo que tenemos que construir versiones flash del código y grabarlas en sus placas de desarrollo para probar. Los probadores no son técnicamente tan precisos como los desarrolladores y a menudo requieren mucho apoyo para que las cosas funcionen en las primeras etapas (restablecer la placa, conectar la comunicación en serie, etc.), o incluso para comprender la salida.

Finalmente, con respecto a la definición de hecho, un sprint no puede completarse hasta que todas las historias estén completas. Todas las historias no están completas hasta que sean verificadas por los evaluadores. No hay forma de evitar "robar" el tiempo del desarrollador para dar a los evaluadores. En otras palabras, si las últimas tres historias de usuario en el sprint demorarán cinco días en probarse, deben codificarse y probarse en la unidad cinco días antes del final del sprint. ¿Qué se supone que debe hacer el desarrollador? ¿Para de trabajar?

Estoy siendo gracioso, pero es un verdadero problema tratar de cumplir con las reglas. Ahora, estoy de acuerdo con cambiar las reglas, pero el problema que tengo es que arruina todas mis métricas de carga si no puedo marcar las cosas hasta que se prueben.

Me encantaría saber cómo otros han manejado estas situaciones.

Está utilizando una metodología en un producto que no es compatible en mi humilde opinión.

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, reordenable o reemplazable.

En la forma en que la mayoría de la gente define la cascada es que el trabajo se presenta en secuencia por adelantado a partir de un esfuerzo de arquitectura significativo al principio.

Las tareas que enumeras arriba me parecen una gran cascada. Tienen que estar en un cierto orden, y no son negociables.

No estoy diciendo que tenga que cumplir con la opinión de nadie de ningún proceso, pero al menos para estas tareas parece que está en un proyecto no ágil para mí. Intentar convertir eso en un proceso ágil será, en el mejor de los casos, descuidado.

Si el resto del proyecto es adecuado para ágil, no me preocuparía demasiado si la configuración inicial no es adecuada, pero el hecho de que mencione RTOS y placas de desarrollo me hace sospechar que todo estaría mejor en algo más como cascada (una larga secuencia de dependencias inamovibles).

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

Lo que forma parte de Scrum es la idea de ofrecer funciones completas que estén completamente probadas y potencialmente implementables en un entorno en vivo cada Sprint. Cuando comienzas desde cero el primer día de cualquier tipo de proyecto, el valor real de cualquier tipo de funcionalidad que puedas ofrecer en Sprint 1 es bastante pequeño. Esto se debe a que cada cosa pequeña necesita toneladas y toneladas de infraestructura construida para que funcione. Pero el punto es que solo construye suficiente infraestructura para hacer que cada característica funcione. Y luego lo construyes a medida que agregas más funciones.

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

Si está decidido a escribir historias de usuarios, recuerde que los usuarios no tienen que ser personas. Entonces escribes cosas como, "Como un controlador de interrupciones CMOS, necesito poder detectar el estado del indicador de modulación de la pila whozzit de bingle cuando el compresor fluxotronic señala una sobrecarga de derivación pasiva". Absolutamente no escriba historias de usuario "Como desarrollador ...".

Utiliza Scrum en un área muy específica y viola el supuesto proceso en cada paso. Su pregunta probablemente debería ser: ¿Existe otra metodología ágil que se adapte 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, entonces sus historias de usuario probablemente estén mal definidas. Si necesita crear una herramienta o cualquier otra cosa para poder ofrecer valor comercial, entonces el producto se puede dividir en dos partes / lanzamientos: construir una herramienta y construir un valor comercial. En tal caso, sus historias de usuario "Como desarrollador ..." serán completamente válidas, porque se crea una herramienta para desarrolladores.

  El problema aquí es cómo comunicar esto con el cliente, porque su participación en la primera versión es cero. Si no hay ningún 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 las características comerciales más importantes primero, pero necesita dos meses para entregar las primeras. Scrum y el conjunto ágil adoptan el cambio: ¿qué sucederá si, después de entregar las primeras funciones, el cliente requiere algún cambio que regrese a todos sus sprints iniciales?

• Pruebas. Otro fracaso porque un equipo en Scrum se considera como un grupo de miembros multifuncionales. Significa que todo el mundo desarrolla y prueba, y debido a eso no hay situaciones descritas en su punto final (o al menos no cinco días). No significa que no pueda haber un control de calidad por separado para hacer algunas 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. Necesita desarrollar por separado el desarrollo y las características de prueba y aprobación entre ellos.