Como adotar uma metodologia ágil para o desenvolvimento de firmware / software de sistemas embarcados?

Sempre me perguntei como aplicar métodos ágeis realmente existem em softwares de sistemas embarcados complexos e grandes (mais de 100 engenheiros). O desenvolvimento do firmware tem algumas características únicas que dificultam a agilidade (por exemplo, o hardware não está disponível até o final do ciclo de desenvolvimento; depois que o produto é lançado, não é possível atualizar facilmente o firmware; etc ...)

A norma nesse tipo de desenvolvimento é a documentação espessa e as exaustivas revisões por pares. Você não pode obter uma correção de código simples, como renomear uma variável sem 2-3 assinaturas. (Eu exagerei um pouco, mas isso é típico. Além disso, muitas pessoas usam atalhos e os gerentes de projeto até os aprovam, especialmente diante dos prazos rígidos do mercado.)

Gostaria de ouvir algumas dicas ou diretrizes sobre como adotar a metodologia ágil para projetos de desenvolvimento de firmware.

Eu acho que duas técnicas são fundamentais:

• Desenvolva um simulador completo ou ambiente de teste para o hardware, para que você possa desenvolver o software como se tivesse hardware real. Não economize ou use atalhos aqui: o desenvolvimento de um bom simulador será recompensado.

• Escreva vários testes de unidade no simulador.

Depois que você fizer essas coisas e as pessoas tiverem certeza de que o simulador e os testes de unidade fornecerão uma idéia precisa de como as coisas funcionarão com o hardware, será mais fácil adotar outras técnicas ágeis (iterações curtas, refatoração implacável etc.) .

O impacto do Agile em um processo de desenvolvimento envolvendo vários fornecedores pode ser comparado ao que acontece quando uma empresa faz JIT.

Para entregar o JIT, cada um dos fornecedores da empresa deve entregá-lo.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

Da mesma forma, se você deseja que um produto complexo seja desenvolvido de acordo com as metodologias Agile, todos os subgrupos da cadeia devem funcionar dessa maneira.

Em termos de desenvolvimento 'incremental' (também conhecido como Tracer Bullets de 15 anos atrás), isso implicaria que o 'núcleo' seja lançado muito em breve para o motorista, e que o driver básico esteja disponível para o integrador e que a GUI ser desenvolvido, com um único botão e uma caixa de edição, ao mesmo tempo.

A parte difícil é convencer os projetistas de hardware, provenientes de uma sólida disciplina de engenharia inovadora, a ingressar na nossa sociedade de consertadores.

A segunda parte mais difícil é encontrar uma maneira de permitir o desenvolvimento incremental em um mundo onde uma impressão de hardware deve ser solicitada com três semanas de antecedência. Estou pensando emuladores, FPGA está aqui. Eu não sou um cara de hardware, no entanto.

Se você deseja optar pelo desenvolvimento incremental de hardware, pode, assim como nos limites de uma cadeia JIT, prever um mecanismo de buffer que permita que as equipes Agile avancem.

Não sejamos cegos: o Agile também precisa lidar com processos pesados! Não peça à equipe do Agile para 'refatorar' agora sua base de código Java para Python no próximo sprint. É apenas porque algumas das partes são realmente estáveis ​​que podemos dançar nossos movimentos ágeis em cima delas.

Manifesto Ágil: http://agilemanifesto.org/

"Indivíduos e interações sobre processos e ferramentas"

• Conheça mais. Empurre menos papel.

"Software que trabalha sobre uma documentação completa"

• Protótipo e construção de picos de tecnologia cedo e frequentemente.

• Resolva o problema real do usuário em vez de continuar a criar aderência exigente a uma especificação. Isso significa soluções evolutivas . A idéia de que precisamos construí-la da maneira correta, porque nunca mais podemos construí-la de novo, está errada. Planeje a iteração. Faça parte da estratégia de marketing e implementação.

"Colaboração do cliente sobre negociação de contrato"

• Os processos hiper-complexos de controle de alterações são apenas maneiras de dizer "não" ao cliente.

• O bloqueio antecipado de todos os requisitos e a imposição do controle de alterações é outra maneira de dizer "não".

• Se você já planeja mais de uma versão, poderá adiar mais facilmente os requisitos para uma versão posterior. Depois que o cliente tiver o dispositivo com o software incorporado, a próxima versão mudará em suas prioridades.

"Respondendo à mudança seguindo um plano"

• Embora a integração complexa exija um plano complexo, o "programa" geral (ou sequência de projetos) não pode ser concretizado cedo demais.

Uma metodologia totalmente ágil (ou seja, scrum) pode não fazer sentido para um sistema incorporado.

O manifesto Agile, no entanto, fornece maneiras de permitir que as mudanças sejam possíveis sem permitir o caos simples.

Meu problema com o scrum em sistemas embarcados é que há muitas tarefas a serem executadas, especialmente nos estágios iniciais, que não são demonstráveis. Começamos com uma placa de desenvolvimento, sem sistema operacional, sem tela, sem comunicação serial, etc. Não tivemos nossa tela por 6 sprints.

Os 4 primeiros sprints foram: Instalando o RTOS Criando tarefas Criando drivers de rede e serial Criando rotinas de interrupção para botões, comunicações, etc. Criando classes e métodos principais de banco de dados Criando um menu de depuração serial

A maioria dessas tarefas não é adequada para histórias de usuários. De fato, a única interface em todo o sistema era o menu de depuração serial, construído no sprint 3, portanto não havia nada para demonstrar no final dos sprints. Até o menu serial era para uso interno e não para o usuário final.

Obviamente, cada classe que escrevemos tem testes de unidade associados e usamos uma estrutura de teste de unidade para automatizar a execução de todos os testes.

Acabamos escrevendo frases de "histórias de usuários" como "Como desenvolvedor ...", com as quais não estou feliz, mas ao usar o Target Process (www.targetprocess.com), não existe o conceito de um item de backlog que é uma tarefa ou tarefa.

Eu adoraria ouvir como os outros lidaram com essas situações.