Qual modelo de desenvolvimento de software funcionou melhor para equipes de software com forte dependência de equipes de hardware?

Existem várias práticas recomendadas concorrentes para o desenvolvimento de software. Pelo que descobri, muitas equipes se beneficiaram das práticas ágeis em alguns casos. No entanto, em alguns outros casos, o uso do Processo Unificado foi promovido por grandes empresas como a IBM.

Os temas comuns que encontro parecem funcionar bem para equipes que desenvolvem principalmente software.

Estou interessado em saber o que funcionou melhor para pessoas que trabalharam em lojas onde existe uma equipe do outro lado que produz o hardware em que seu software está sendo executado. Por exemplo, uma equipe monta uma caixa com vários hardwares personalizados; enquanto você precisa desenvolver o software que seria executado nessas caixas. Não consigo encontrar um modelo de desenvolvimento (ágil, espiral ...) que funcione melhor nesse caso.

Qualquer sabedoria nesta área será bem-vinda.

Realmente depende de como sua equipe de hardware fornecerá artefatos úteis que sua equipe de software pode usar para desenvolver e como as equipes estão configuradas para se comunicarem.

Normalmente, você encontrará que a equipe de hardware criará um produto, levará para um estágio de protótipo para teste e somente então a equipe de software obterá qualquer tipo de documentação de requisitos da equipe de hardware. Escusado será dizer que nem sempre é o melhor caminho a percorrer, pois o software geralmente é desenvolvido muito tarde no processo, e você geralmente se encontra com poucas opções a não ser trabalhar com uma metodologia baseada em cascata. Do ponto de vista da equipe de hardware, se eles precisarem mudar algo repentinamente, a equipe de software não precisará modificar seu software. O problema aqui, é claro, é que o pessoal de hardware médio precisa desenvolver produtos dessa maneira e espera que qualquer coisa que o beneficie com a ajuda da equipe de software.

Como alternativa, se sua equipe de hardware estiver construindo um produto e atualizando os requisitos de software à medida que avançam, e melhor ainda, se envolverem a equipe de software logo que cada recurso de hardware estiver sendo planejado e simulado, você terá a oportunidade de equipe de software para trabalhar de uma maneira muito mais ágil. Naturalmente com isso, quero dizer que a equipe de hardware é o cliente e fornece à equipe de software uma lista de problemas que precisam ser resolvidos no software. A equipe de software pode discutir com seus clientes as prioridades relativas de cada requisito e, assim que o protótipo de hardware estiver pronto, o software provavelmente estará disponível em um formato de release antecipado e poderá ser usado para ajudar no teste do hardware. Se os requisitos forem alterados, esperamos que a equipe de software tenha a agilidade de alterar o software à medida que avançam, e pode fornecer feedback antecipado à equipe de hardware antes que o design do hardware seja comprometido com o protótipo. A equipe de software também tem acesso direto ao cliente desde o início do projeto, o que significa que eles podem ter uma idéia melhor sobre o que precisam zombar - e como fazê-lo - enquanto aguardam o teste do hardware.

Realisticamente, você não encontrará uma metodologia ideal que se encaixe imediatamente, e posso garantir que você terá muitos ajustes para fazer, independentemente da metodologia que escolher adotar ou desenvolver. O problema real é que você deseja tentar facilitar a gestão da sincronização entre as equipes e significa que você precisa encontrar uma maneira de aumentar a quantidade de contato e de entrada entre as duas equipes o mais cedo possível no processo, mesmo que pareça "inútil" ou "contra-intuitivo" fazê-lo. Esse é um grande problema na empresa com a qual estou trabalhando atualmente. Nosso "pai" europeu está lutando com esse problema exato, enquanto a equipe aqui em Oz parece capaz de manter as coisas funcionando um pouco mais suavemente, e é "

Provavelmente sou tendencioso, tendo trabalhado mais no lado do hardware de grandes equipes de desenvolvimento de produtos de hardware e software. O hardware pode ser muito caro para revisar se for arquitetado ou projetado incorretamente. Muitas vezes, um erro no design do hardware é tão caro que significa cancelar todo o projeto. Corrigir um erro de máscara de chip pode custar mais do que o salário anual de dezenas de engenheiros. Portanto, vejo que o objetivo principal da equipe de software nos primeiros 50% + do ciclo de desenvolvimento é garantir que a equipe de hardware não falhe. Isso pode significar esquecer o código final do aplicativo e seu design em primeiro lugar, e apenas trabalhar em simulações de arquitetura e desempenho de hardware, ferramentas para ajudar a equipe de hardware a concluir e verificar seu design,

Espere ser ágil, não apenas sobre as especificações do cliente, mas também sobre várias peculiaridades / bugs surpreendentes na plataforma de hardware, onde uma solução alternativa de software pode ter muito menos impacto no cronograma do que uma rotação de hardware.

Um dos principais inquilinos do Agile é "falhar cedo". Com o hardware, isso não poderia ser mais verdadeiro. O hardware de produção em massa é extremamente caro. Além disso, o hardware físico não pode simplesmente ser "corrigido" como o software. Exacerbando esses problemas, as equipes de hardware tendem a ser menos voltadas para o cliente do que as equipes de software na prática e tendem a se acostumar com o modelo de desenvolvimento "big bang".

Por esses motivos, não capturar problemas de hardware o mais rápido possível é geralmente mais caro do que deixar de detectar problemas de software mais cedo. Os clientes esperam exigir atualizações de software; eles podem parar de trabalhar com você inteiramente se tiverem que lidar com um recall de hardware.

Em resumo, não esperar e se preparar para problemas de hardware cedo é o maior desafio de um modelo de desenvolvimento ao desenvolver software e hardware em paralelo.

Você absolutamente deve antecipar o fracasso. Obtenha um protótipo mais cedo. Use o protótipo para desenvolver contra. Espere que seja um fracasso. Aprenda com o fracasso. Enxágüe. Repetir. Certifique-se de que todos esperam que os protótipos de hardware sejam revisados ​​/ criticados / reprojetados com base no feedback das partes interessadas.