Scrum para dispositivos con sistema incorporado

En nuestra empresa, vamos a entregar un nuevo producto que se utilizará para notificaciones masivas, por lo que es un proyecto de software integrado y vamos a utilizar el SCRUM como marco para el producto.

Hemos empezado a escribir la cartera de pedidos del producto. Según lo que entendí, el trabajo atrasado del producto debe reflejar un valor comercial para cada artículo. La naturaleza del software incorporado es que tiene muchos detalles técnicos que consumirán una gran cantidad de tiempo para crear controladores para microcontroladores, como SPI, UART, ethernet, WIFI, etc.

por ejemplo, el sistema suena al reproducir un mensaje para notificación, por lo que es bastante obvio que reproducir un mensaje es un valor comercial, pero para lograr este objetivo tengo que escribir los requisitos, que son lo que no es cómo, para muchos conductores como el SPI, controlador de chip decodificador de MP3, controlador de tarjeta SD y, finalmente, FAT, por lo que todos los controladores anteriores tienen requisitos que deben escribirse en la cartera de pedidos del producto, de modo que los requisitos comenzaron con un requisito de valor de un negocio, mientras que tiene muchos aspectos técnicos requisitos secundarios

Estos no reflejan un valor comercial para el cliente; ¿Alguien puede decirme cómo voy a crear la cartera de pedidos de mi producto?

Donde trabajo, creamos sistemas integrados y también utilizamos scrum para nuestro desarrollo. Estás mirando las cosas desde una perspectiva técnica , no desde una perspectiva característica .

Lo primero que debe preguntar es "¿Por qué necesitamos implementar esto?" Por ejemplo: ¿Por qué necesitas SPI? ¿Se utilizará para EEPROM para que pueda almacenar números de serie? ¿O tal vez se conecte a un controlador de pantalla para que los usuarios puedan ver los elementos en una pantalla? Hay muchas buenas razones para crear un controlador SPI, pero crearlo solo para tenerlo no es una de esas razones.

Con Scrum, debería adoptar una política de " No la necesitamos hasta que la necesitemos " , lo que significa que no debe perder el tiempo con SPI o wifi o cualquier otra cosa hasta que haya una necesidad comercial que requiera esas tecnologías para realizar. Entonces esa necesidad comercial se convierte en la historia.

Pruebe "Agregar EEPROM para el almacenamiento de configuración" en lugar de "Crear código SPI"

y "Crear conexión al servidor para la administración remota" en lugar de "Buscar documentación para WIFI e implementar"

No te obsesiones con el dogma scrum. Scrum existe para hacerte más ágil. Cualquier cosa que se interponga en el camino puede ser ignorada.

Es cierto que no debe hacer un trabajo que no le dé valor comercial, pero el valor se presenta en muchas formas. ¿Obtiene valor de tener un controlador de ethernet? Sospecho que sí, porque sin él no puedes ofrecer ciertas funciones. "Como desarrollador, necesito un controlador de ethernet para poder implementar las funciones que requieren conectividad a Internet".

Por lo tanto, no mire el valor solo como características visibles para el usuario. El valor es cualquier cosa que mejore su producto, incluso si es invisible para el usuario final.

Algunos dirán que no es una historia válida, y las historias solo deberían tener características visibles para el usuario. Creo que también está bien, hasta el punto en que te causa problemas como este. Una vez más, el objetivo de scrum es ayudarte y mejorar el enfoque y la comunicación. No dejes que lo que crees que se supone que debes hacer te impida hacer las cosas. Sé pragmático y honesto. Si cree que necesita desarrollar cierta cosa, responda la pregunta "¿por qué" y "para quién es esto?". La respuesta no siempre tiene que ser la misma persona.

Según mi experiencia, uno de los desafíos clave que utiliza Scrum con desarrollo integrado es que los mejores equipos Scrum ofrecen funcionalidades de trabajo completas. Desde las entrañas más profundas hasta la exposición del usuario. Esto mantiene los problemas de integración dentro de un equipo y dentro de un sprint. Y demuestra el valor comercial porque el usuario final puede ver y probar el resultado.

Incluso para el software puro puede ser un desafío hacer que la historia sea lo suficientemente delgada en cada nivel para que la historia completa se pueda construir en un sprint o dos. Pero para embebido, esto puede ser imposible porque las entrañas más profundas involucran hardware que no se adapta tan rápido como el software porque se basa en el mundo físico.

La solución ideal es elevar las capacidades de su hardware para que puedan circular más rápido ... con simuladores, ejecuciones rápidas de respuesta corta, modelos, etc. Pero eso puede ser costoso. Por lo tanto, un compromiso de uso frecuente, que creo que se aplica a su situación, es relajar el concepto de valor comercial y dejar que incluya capacidades más generales que requieren sus usuarios finales y su aplicación.

Entonces, por ejemplo, si necesita construir WiFi, es mejor que haya una razón para el usuario final o por qué lo está haciendo. Encuéntrelo y póngalo en la definición de la historia del usuario, como esta para automotriz: "Proporcione funciones de control de ocupantes de forma inalámbrica, para satisfacer las necesidades de los pasajeros, al mismo tiempo que reduce los costos y aumenta la confiabilidad y el mantenimiento".

Encontré este enlace que, entre otras cosas, habla sobre historias de usuarios en desarrollo integrado (asegúrese de desplazarse hacia abajo para llegar a la sección Historias)

Cuentos

Tendremos que analizar las historias con mayor profundidad porque uno de los grandes desafíos del desarrollo ágil es dividir el sistema en las historias que permiten un progreso incremental y visible en el producto. El desarrollo ágil integrado tiene aún más desafíos para definir historias debido a la complejidad adicional de las interacciones hardware / software.

Las historias generalmente se denominan historias de usuario. Prefiero llamarlos historias de productos. A menudo, el trabajo que hacemos en el desarrollo integrado no es visible para el usuario final. el nombre Product Story parece encajar mejor.

Una historia de producto ofrece valor, muestra progreso o reduce algunos riesgos y puede completarse en una iteración.