Scrum para dispositivos de sistema embarcado

8

Em nossa empresa, entregaremos um novo produto que será usado para notificações em massa, por isso é um projeto de software incorporado e usaremos o SCRUM como uma estrutura para o produto.

Começamos a anotar o backlog do produto. Com base no que entendi, o backlog do produto deve refletir um valor comercial para cada item. A natureza do software incorporado é que ele possui muitos detalhes técnicos que consumirão muito tempo para criar drivers para microcontroladores, como SPI, UART, Ethernet, WIFI, etc.

por exemplo, o sistema está tocando ao reproduzir mensagem para notificação, portanto, é bastante óbvio que reproduzir uma mensagem é um valor comercial, mas para atingir esse objetivo, preciso anotar os requisitos que também não são como - para muitos motoristas como o SPI, driver de chip de decodificador de MP3, driver de cartão SD e, finalmente, o FAT, portanto, todos os drivers anteriores têm requisitos que devem ser gravados na lista de pendências do produto, de modo que os requisitos iniciam com um requisito de um valor comercial enquanto ele possui muitas informações técnicas. sub-requisitos.

Isso não reflete um valor comercial para o cliente; alguém pode me dizer como vou criar a lista de pendências do meu produto?

scrum embedded-systems

— Mohamed Fawzy
fonte

Você deve dividir seus problemas em etapas menores, assim como você deve dividir seu parágrafo em várias frases. Se você não conseguir dividir seus problemas em etapas menores, talvez o scrum não seja o caminho a seguir.

— 21714 Kevin Workman

1

Você pode achar que, para o desenvolvimento incorporado, algumas tarefas (como esses drivers) serão maiores do que o normalmente recomendado. Isso às vezes é inevitável e você terá que conviver com isso.

— Bart van Ingen Schenau

1

O problema é que você está se concentrando em como deseja que os resultados sejam alcançados. Isso simplesmente não funciona em ágil. Concentre-se no que seu cliente deseja, começando do básico e, em seguida, corte esses recursos verticalmente, sem especificar como alcançá-los. A questão não é "escrever um driver", mas "o que nosso cliente faz com um driver".

— 21414 Sklivvz

1

Tenho sérias dúvidas de que o Scrum seja a melhor abordagem para sistemas embarcados. Você pode fazer agilidade com base no scrum, não no Scrum. Minha principal preocupação é com os conceitos do Scrums que colidem com o mundo real dos prazos e ciclos de desenvolvimento de hardware. Você já considerou outros métodos ágeis?

— mattnz

1

@Blrfl, sim, o problema de expressar que algo é necessário para agregar valor ao negócio, mas não é, por si só, suficiente para isso. Muitos produtos realisticamente são valiosos apenas como conjuntos integrados, onde seu valor pode ser quantificado pelo fato de sua venda e inúteis (ou quase inúteis) como peças.

— Steve

11

Onde trabalho, criamos sistemas embarcados e também usamos o scrum para o nosso desenvolvimento. Você está vendo as coisas de uma perspectiva técnica , não de uma perspectiva de recursos .

A primeira coisa que você deve perguntar é "Por que precisamos implementar isso?" Por exemplo: Por que você precisa de SPI? Será usado na EEPROM para que você possa armazenar números de série? Ou talvez conectar um controlador de vídeo para que os usuários possam ver itens em um monitor? Existem muitas boas razões para criar um driver SPI, mas criá-lo apenas para que ele não seja um desses motivos.

Com o Scrum, você deve adotar uma política " Não precisamos disso até precisarmos " , ou seja, você não deve perder tempo com SPI ou wifi ou qualquer outra coisa até que exista uma necessidade comercial que exija que essas tecnologias sejam implementadas. realizar. Então essa necessidade comercial se torna a história.

Tente "Adicionar EEPROM para armazenamento de configuração" em vez de "Criar código SPI"

e "Criar conexão com o servidor para gerenciamento remoto" em vez de "Localizar documentação para WIFI e implementar"

— Ampt
fonte

2

O que você faz se (a) adicionar o código de manuseio da SPI for bastante complexo (por exemplo, em torno de tantos pontos quanto você pode lidar em um sprint, talvez até mais) e (b) existirem várias histórias de usuários que exijam o código de manuseio da SPI?

— detly

na verdade, essa é minha preocupação que levará a um conjunto de requisitos técnicos herdados para um requisito de valor comercial. Portanto, no final, o backlog do produto conterá muitos requisitos técnicos que não são de valor comercial. É aceitável ou estou violando um dos conceitos ágeis?

— Mohamed Fawzy

Você não deve ficar muito preocupado com os inquilinos do ágil. como Bryan disse, você não deve ficar muito preocupado com o dogma e apenas fazer o que funciona para você. Meu ponto principal aqui é que você deve apenas tentar manter o valor comercial em mente. O que você faz pode não agregar valor comercial diretamente no final da história, mas deve levar a esse objetivo.

— Ampt

1

Exemplo extremo de interpretar demônios defende: O que acontece se eu não faço a interface SPI porque não preciso dela (dogma do Scrum), então um dia eu preciso disso. Eu implemento o SPI e encontro um defeito de hardware. Ignorando que eu já tenha enviado o hardware, o prazo de entrega para o hardware fixo é de 6 meses (bastante comum), mas o Scrum exigiu que eu o implementasse pouco antes de precisar. Qual é a solução Scrum para isso?

— mattnz

@mattnz Isso é um pouco tarde, mas a resposta do scrum seria que você deveria ter interesse comercial em eliminar defeitos de hardware mais cedo, e o exercício da interface SPI cedo teria um valor comercial. Você deve prestar atenção às suas necessidades reais, o que nem sempre é um processo simples. Como em todos os fluxos de trabalho, uma implementação ingênua do Scrum falhará. Da mesma forma, uma implementação ingênua do EVMS ou qualquer outra abordagem pesada de cima para baixo também falhará.

— Cort Ammon

5

Não se desligue do dogma do scrum. O Scrum existe para torná-lo mais ágil. Qualquer coisa que atrapalhe isso pode ser ignorada.

É verdade que você não deve fazer um trabalho que não dê valor aos negócios, mas o valor vem de várias formas. Você valoriza ter um driver ethernet? Eu suspeito que sim, porque sem ele você não pode fornecer determinados recursos. "Como desenvolvedor, preciso de um driver Ethernet para poder implementar os recursos que requerem conectividade à Internet".

Portanto, não olhe o valor apenas como recursos visíveis ao usuário. Valor é algo que melhora o seu produto, mesmo que seja invisível para o usuário final.

Alguns dirão que não é uma história válida, e as histórias devem ter apenas recursos visíveis ao usuário. Eu acho que tudo bem também, até o ponto em que isso causa problemas assim. Novamente, o objetivo do scrum é ajudá-lo e melhorar o foco e a comunicação. Não deixe que o que você pensa que deve fazer atrapalhe sua execução. Seja pragmático e honesto. Se você acha que precisa desenvolver uma determinada coisa, responda à pergunta "por que" e "para quem é?". A resposta nem sempre precisa ser a mesma pessoa.

— Bryan Oakley
fonte

Qual foi o dogma do Scrum na pergunta original? Interpretação incorreta não é dogma. Dogma seria se Scrum tivesse práticas inaplicáveis.

— 21714 Dave Hillier #

3

Um dos principais desafios do uso do Scrum com desenvolvimento incorporado, na minha experiência, é que as melhores equipes do Scrum oferecem fatias de funcionalidade de pilha cheia. Das tripas mais profundas à exposição do usuário. Isso mantém os problemas de integração dentro de uma equipe e dentro de um sprint. E prova o valor comercial, porque o usuário final pode ver e experimentar o resultado.

Mesmo para software puro, pode ser desafiador tornar a história fina o suficiente em cada nível, para que toda a história possa ser construída em um sprint ou dois. Mas, para os incorporados, isso pode ser impossível, porque as tripas mais profundas envolvem hardware que não se adapta tão rapidamente quanto o software, porque está fundamentado no mundo físico.

A solução ideal é aprimorar seus recursos de hardware para que eles possam pedalar mais rápido ... com simuladores, execuções rápidas de execução rápida, modelos e assim por diante. Mas isso pode ser caro. Portanto, um compromisso frequentemente usado, que eu acho que se aplica à sua situação, é relaxar o conceito de valor comercial e incluir recursos mais gerais que seus usuários finais e seu aplicativo exigem.

Por exemplo, se você precisar criar WiFi, é melhor haver um motivo para o usuário final ou por que você está fazendo isso. Encontre isso e coloque-o na definição da história do usuário, como esta para o setor automotivo: "Forneça funções de controle dos ocupantes sem fio, para atender às necessidades dos passageiros e ao mesmo tempo reduzir custos e aumentar a confiabilidade e a manutenção".

— Prumo
fonte

Eu nunca acho que a analogia da produção automotiva com o software seja muito adequada. Os carros têm um design bem estabelecido há um século e são construídos apenas pelas maiores empresas que criam e mantêm especialistas experientes em todos os tipos de campos. De qualquer forma, hoje em dia os carros estão sujeitos principalmente a recursos aparafusados e pequenos aprimoramentos, não projetados e construídos de baixo para cima, e as mudanças de design ainda levam anos. O desenvolvimento de software realmente tem pouca relação com o negócio de automóveis.

— Steve Steve

1

@ Steve, ele não está fazendo uma analogia. Ele está dando um exemplo de uma história que você pode encontrar no backlog de uma equipe automotiva.

— precisa

@RubberDuck, acho que ele deve implicitamente perceber (e pretende que o leitor perceba) alguma analogia com a produção automotiva ou processo de fabricação semelhante - exatamente o que a analogia é percebida pode ser tácita e sub-definida, mas isso não significa não é o momento apropriado para comentar e refutar a analogia, e como os processos empregados na fabricação são usados em circunstâncias e condições bastante diferentes das existentes para o desenvolvimento de muito software.

— Steve

1

Encontrei este link que, entre outras coisas, fala sobre histórias de usuários em desenvolvimento incorporado (certifique-se de rolar para baixo para acessar a seção Histórias)

Histórias

Teremos que examinar as histórias com mais profundidade, porque um dos grandes desafios do desenvolvimento Agile é dividir o sistema em histórias que permitem um progresso visível e incremental no produto. O desenvolvimento ágil incorporado tem ainda mais desafios na definição de histórias devido à complexidade adicional das interações de hardware / software.

As histórias são geralmente chamadas de histórias de usuário. Prefiro chamá-los de Histórias de produtos. Muitas vezes, o trabalho que fazemos no desenvolvimento incorporado não é visível para o usuário final. o nome História do produto parece se encaixar melhor.

Uma história de produto agrega valor, mostra progresso ou reduz alguns riscos e pode ser concluída em uma iteração.

— jramirez
fonte