Scrum para dispositivos con sistema incorporado

8

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?

scrum embedded-systems

— Mohamed Fawzy
fuente

Debe dividir sus problemas en pasos más pequeños, al igual que debe dividir su párrafo en varias oraciones. Si no puede dividir sus problemas en pasos más pequeños, entonces quizás scrum no sea el camino a seguir.

— Kevin Workman

1

Puede encontrar que para el desarrollo integrado, algunas tareas (como esos controladores) serán más grandes de lo que comúnmente se recomienda. Esto a veces es inevitable y tendrás que vivir con ello.

— Bart van Ingen Schenau

1

El problema es que te estás enfocando en cómo quieres que se logren los resultados. Esto simplemente no funciona en ágil. Concéntrese en lo que quiere su cliente, comenzando por lo básico, y luego corte estas características verticalmente sin especificar cómo lograrlas. El punto no es "escribir un controlador" sino "qué hace nuestro cliente con un controlador".

— Sklivvz

1

Tengo serias dudas de que Scrum sea el mejor enfoque para los sistemas integrados. Puede hacer ágil basado en scrum, no Scrum. Mi principal preocupación son los conceptos de Scrums que chocan con el mundo real de los tiempos y ciclos de desarrollo de hardware. ¿Has considerado otros métodos ágiles?

— mattnz

1

@Blrfl, sí, el problema de expresar que algo es necesario para entregar valor comercial, pero no es suficiente por sí solo. Muchos productos de manera realista solo son valiosos como conjuntos integrados, donde su valor puede cuantificarse por el hecho de su venta, y sin valor (o casi sin valor) como partes.

— Steve

11

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"

— Ampt
fuente

2

¿Qué hacer si (a) agregar código de manejo SPI es bastante complejo (es decir, alrededor de tantos puntos como podría manejar en un sprint, tal vez incluso más), y (b) hay varias historias de usuarios que requieren código de manejo SPI?

— desviarse

En realidad, esta es mi preocupación, lo que conducirá a una gran cantidad de requisitos técnicos que se heredan para un requisito de valor comercial. Entonces, al final, la cartera de productos contendrá muchos requisitos técnicos que no son un valor comercial, ¿es aceptable o estoy violando uno de los conceptos ágiles?

— Mohamed Fawzy

No debería obsesionarse demasiado con los inquilinos de Agile. como dijo Bryan, no debes obsesionarte demasiado con el dogma y simplemente hacer lo que funcione para ti. Mi punto principal aquí es que debes tratar de tener en cuenta el valor comercial. Es posible que lo que haga no agregue valor comercial directamente al final de la historia, pero debería conducir a ese objetivo.

— Ampt

1

Ejemplo extremo que defiende a los demonios: ¿Qué sucede si no hago la interfaz SPI porque no la necesito? (Scrum dogma), entonces un día sí la necesito. Implemento el SPI y encuentro un defecto de hardware. Ignorando que ya podría haber enviado hardware, el tiempo de entrega para el hardware fijo es de 6 meses (bastante común), pero Scrum me pidió que lo implementara justo antes de que lo necesitara. ¿Cuál es la solución de Scrum para esto?

— mattnz

@mattnz Esto es un poco tarde, pero la respuesta de scrum sería que debería tener un interés comercial en eliminar los defectos de hardware temprano, y ejercer la interfaz SPI temprano tendría un valor comercial. Debe prestar atención a sus necesidades reales, que no siempre es un simple proceso ingenuo. Como con todos los flujos de trabajo, fallará una implementación ingenua de Scrum. Del mismo modo, una implementación ingenua de EVMS o cualquier otro enfoque pesado de arriba hacia abajo también fallará.

— Cort Ammon

5

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.

— Bryan Oakley
fuente

¿Cuál era el dogma de Scrum en la pregunta original? La mala interpretación no es dogma. Dogma sería si Scrum tuviera prácticas que no fueran aplicables.

— Dave Hillier

3

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".

— Beto
fuente

Nunca creo que la analogía de la producción automotriz con el software sea muy adecuada. Los autos han tenido un diseño bastante estable durante un siglo, y son construidos solo por las compañías más grandes que crean y retienen especialistas experimentados en todo tipo de campos. De todos modos, los automóviles de hoy en día están sujetos principalmente a características atornilladas y mejoras menores, no diseñadas y construidas desde abajo hacia arriba, y los cambios de diseño aún llevan años. El desarrollo de software realmente tiene poca relación con el negocio del automóvil.

— Steve

1

@ Steve no está haciendo una analogía. Él está dando un ejemplo de una historia que puede encontrar en la cartera de pedidos de un equipo automotriz.

— RubberDuck

@RubberDuck, creo que debe percibir implícitamente (e intentar que el lector perciba) alguna analogía con la producción automotriz o un proceso de fabricación similar; exactamente lo que se percibe como analogía puede ser tácito y poco definido, pero eso no significa No es un momento apropiado para comentar y refutar la analogía, y cómo los procesos empleados en la fabricación se utilizan en circunstancias y condiciones muy diferentes de las que existen para gran parte del desarrollo de software.

— Steve

1

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.

— jramirez
fuente