BT

O desenvolvimento ágil funciona em projetos de hardware?

por Shane Hastie , traduzido por Rafael Buzon em 25 Out 2011 |

Vários profissionais de TI tem trazido à tona recentemente a questão da aplicação das práticas ágeis no desenvolvimento de hardware. Nil Johnson escreveu um artigo na Electronic Engineering Times (EETimes): Desenvolvimento ágil de hardware - sem sentido ou necessidade?

Ele colocou a questão:

Deve haver um debate quando se trata de aplicar o Agile no desenvolvimento de hardware? Deveriam os valores e princípios que guiam as equipes ágeis de software também guiar os times que desenvolvem para sistema operacional (System on Chip teams) ; ou as diferenças entre estas duas disciplinas seria muito grande?

Ele continua com uma discussão sobre os valores do Manifesto Ágil e como estes valores formam a base da abordagem ágil no desenvolvimento de software. Ele coloca a questão - Poderia o mesmo funcionar para o desenvolvimento de hardware? -  e comenta:

Para qualquer um que vê o desenvolvimento de hardware como um processo criativo, é difícil negar que os valores do manifesto são diretamente aplicados. Mas apenas considerar um conjunto de valores não é suficiente. De certo modo, valores abstratos precisam se traduzir na prática. Felizmente, times de software têm criado práticas que abordam os valores ágeis e muitas delas podem ser aplicadas diretamente também no desenvolvimento de hardware.

Ele reconhece as diferenças entre as abordagens do desenvolvimento de software e de hardware encorajando os times de hardware a abraçarem as práticas ágeis. Ele usa a prática do continuous delivery (entrega contínua) como um exemplo:

Uma prática de destaque é aquela de implantação rápida e contínua aos clientes. Para muitos times ágeis de software, implantação contínua é absolutamente crítico para o sucesso. Infelizmente, sua aplicabilidade no desenvolvimento de hardware - ou a falta dela - tende a ser usado para desacreditar o Agile totalmente. Para desenvolvimento ASIC em particular, implantação contínua não é realista; mas uma prática não ser realista não deve ser motivo de descrédito do conjunto de práticas. Nenhum time ágil de software realiza todas as práticas ao pé da letra; logo não se pode esperar o mesmo de um time de desenvolvimento de hardware.

Ele conclui com um pedido de mudança no foco das organizações de hardware:

Mudanças acontecem no desenvolvimento de hardware. Independentemente se são mudanças nas especificações, na rotatividade de funcionários, na dinânica do time ou novas tecnologias. Não há como evitar isso. As equipes que deixarem de lado os conceitos de Dilbert e as políticas internas para uma forma mais apurada e uma visão mais humana do desenvolvimento de hardware, retratada pelo manifesto, vai fazer desta mudança uma vantagem. Aos times que não se abrirem a esta mudança, irá restar o exercício fútil de tentar encaixar o "quadrado" dos tradicionais processos bem definidos no "buraco redondo" que é o desenvolvimento de hardware atual.

Larry Maccherone escreveu recentemente algo similar sobre as As 10 questões principais sobre quando usar Agile em projetos de hardware.

Ele elenca uma lista de questões e respostas a fim de auxiliar nas decisões sobre a aplicação de abordagens ágeis em projetos de hardware:

  1. As práticas e processos ágeis são efetivos na condução de projetos que não são de software (firmware, eletrônicos, mecânicos, etc.)?
  2. Quais ajustes são necessários no framework de procesos Scrum para funcionar bem para estes projetos?
  3. Quais ajustes são necessários em nossas expectativas sobre funcionalidades comerciais mínimas, design emergente e definição de Scrum?
  4. Quais ajustes em nossas expectativas são necessárias acerca de histórias?
  5. Como fica a questão de priorizar histórias estritamente pelo valor gerado ao usuário final?
  6. Deveriam as histórias de usuário ser nossa única ferramenta de gerenciamento de requisitos?
  7. Se histórias de usuário não são nem requisitos oficiais do Scrum, então porque não devemos usar somente nossas práticas tradicionais de requisitos?
  8. O que fazer quando precisamos enviar um protótipo ao fornecedor e não é possível ser feito dentro de uma iteração?
  9. O que fazer com dependências e analise do caminho crítico?
  10. Talvez não precisemos da analise contínua do caminho crítico, mas ainda temos especialistas que não são dedicados permanentemente ao time. Como lidar com isso?

Para cada questão que ele lista uma resposta curta é dada seguida de uma discussão de abordagens práticas para resolver as potenciais incompatibilidades e como endereça-las.

As práticas ágeis poderiam ser usadas no desenvolvimento de hardware? Quais mudanças seriam necessárias faze-las funcionar neste contexto?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

hardware pode ser ágil by Doubleday Francotti

Trabalho em desenv. hard/firm/soft... no desenv. de hard. tentamos agregar alguns pontos do framework scrum... mais sem sucesso por não haver uma aceitação de imediato pela alta gestão.
Atualmente estamos em processo de melhorias... tenho certeza que teremos novas informações pra postar sobre o novo desafio.

Re: hardware pode ser ágil by Rafael Buzon

Que bom! Será interessante compartilhar sua experiência conosco.
Quais pontos do Scrum vocês buscaram aplicar e qual o principal motivo da alta gestão não aceitar? Seria legal conhecer também.
Grande Abraço,
Buzon

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT