O Que a Maioria dos "Gurus" Ágeis Erra Sobre o Desenvolvimento de Hardware

A metodologia Ágil, enraizada no mundo do desenvolvimento de software, tem sido aclamada como uma força transformadora na indústria da tecnologia. No entanto, à medida que nos aventuramos no desenvolvimento de hardware e eletrônicos, a adaptação aparentemente suave dos princípios Ágeis encontra um labirinto de desafios e equívocos. Em nossa primeira parte desta exploração em três partes, analisamos desafios Ágeis decorrentes das diferenças entre o desenvolvimento de hardware e software. Neste artigo, examinamos os mitos propagados pelos "gurus" Ágeis.

Antes de nos aprofundarmos nas complexidades do Ágil no desenvolvimento de hardware eletrônico, é importante esclarecer que nossa intenção não é desmerecer os coaches e consultores Ágeis. Reconhecemos e apreciamos suas boas intenções e entusiasmo em ajudar os clientes a colher os benefícios das metodologias Ágeis. Embora algumas críticas possam surgir de um entendimento limitado das nuances do hardware, a intenção não é criticar, mas adaptar os princípios Ágeis de forma eficaz para atender às demandas específicas do desenvolvimento de hardware. Nosso foco é personalizar as táticas Ágeis para aproveitar seus benefícios neste contexto único, modificando a abordagem, mas preservando os princípios.

Mito #1: Você Deve Permanecer Flexível e Adaptar-se

Os gurus do Agile corretamente exaltam as virtudes da execução iterativa, ciclos de feedback, e adaptabilidade rápida que prosperaram no domínio digital do software. No entanto, a transição desses princípios para a paisagem tangível do hardware e da eletrônica introduz uma camada de complexidade não encontrada no espectro puramente digital. Soluções físicas, ao contrário de seus equivalentes de software, precisam estar "prontas" para encomendar peças, fabricar moldes e atender a necessidades de fabricação rigorosas. O chamado do Agile para mudança constante colide com a natureza implacável do efeito cascata do hardware quando até mesmo mudanças menores são necessárias tarde demais.

Em resposta, modificar o Agile para o desenvolvimento de hardware requer uma mudança de paradigma. Não se trata de modificações incessantes, mas de adaptações estratégicas e informadas e prototipagem. Estas são baseadas em ciclos rápidos de aprendizado e execução que visam maximizar o valor dentro das restrições de tempo, orçamento e recursos. A dança entre a agilidade do Agile e as demandas da finalidade do produto físico exige um planejamento de iteração mais consciente e um compromisso profundo com a redução de riscos ao longo do projeto.

Mito #2: Você Deve Desenvolver um Protótipo Funcional a Cada Sprint

Enquanto o desenvolvimento de um protótipo totalmente funcional a cada duas ou três semanas, um "sprint" é frequentemente propagado por puristas do Agile como um "deve" universal para ser Agile, a viabilidade prática dessa abordagem se desfaz diante da realidade do desenvolvimento de hardware e eletrônicos (e orçamento). A ideia de construir algo, demonstrar progresso e usar esse resultado para obter feedback técnico e comercial valioso para informar sua próxima iteração está correta. No entanto, cada projeto de hardware é uma entidade distinta com seus próprios objetivos, dependências, restrições de tempo de execução, áreas de inovação necessárias e risco. E cada projeto merece sua própria abordagem única para prototipagem e aprendizado.

Para realmente abraçar o desenvolvimento de produtos de hardware Ágil, as equipes devem abandonar a mentalidade de que uma única solução serve para todos. Em vez disso, devem fazer um exame cuidadoso das necessidades do projeto e, então, colaborar para derivar uma estratégia criativa, de aprendizado e de prototipagem. É importante reconhecer que um "protótipo" pode ser qualquer saída demonstrável, variando desde um folheto preliminar até uma maquete de espuma (como a famosa maquete do iPod de Steve Jobs que cabe "1000 músicas no seu bolso"), e pode até incluir protótipos parcialmente ou totalmente funcionais.

Mito #3: Adicione Histórias ao Backlog e Simplesmente Comece

Uma força inerente das metodologias Ágeis reside na sua capacidade de iniciar um projeto muito mais rapidamente do que as abordagens tradicionais em cascata. De fato, para projetos de hardware eletrônico Ágeis, observamos uma redução significativa no período desde a identificação do conceito até o início do desenvolvimento. Esse período, que muitas vezes se estendia por vários meses ou até anos sob uma abordagem tradicional em fases, foi condensado para questão de semanas ou dias com os métodos Ágeis. Claro, parte desse resultado dramático é como definimos "início do desenvolvimento".

Para software, isso é direto. Gurus ágeis defendem a escrita de Histórias de Usuário para definir funcionalidades do software, priorizá-las em um backlog e iniciar um Sprint. No entanto, em hardware, pelo menos um mínimo de planejamento prévio é necessário para guiar o projeto na direção certa com um entendimento da arquitetura, atributos desejados chave, restrições e outros fatores. Esse esforço inicial pode aparentemente entrar em conflito com os princípios Ágeis de "software em funcionamento é a principal medida de progresso" e "bem-vindas mudanças de requisitos, mesmo tarde no desenvolvimento."

A reconciliação está em encontrar um equilíbrio adaptando táticas Ágeis comumente entendidas para a frente do desenvolvimento de produto. A gestão de projetos Ágil para hardware permite uma iniciação rápida alinhando-se à intenção estratégica do projeto e aceitando muito mais desconhecidos do que abordagens tradicionais. As equipes podem então colaborar usando a aprendizagem iterativa do Ágil para definir a solução ótima, juntamente com uma mentalidade aberta a mudanças estratégicas que aumentem o valor do produto enquanto permanecem dentro das restrições de cronograma e recursos.

Mito #4: Defina Todos os Seus Itens de Trabalho como Histórias de Usuário

Uma diretriz crítica que muitos gurus Agile defendem é que todo o trabalho de desenvolvimento deve ser definido como Histórias de Usuário. O conselho continua dizendo que componentes do sistema, interfaces, outros engenheiros, etc., devem ser tratados como "Usuários". Esse conselho tem deixado a maioria dos desenvolvedores de eletrônicos e hardware confusos e lutando para cumprir.

Uma razão principal pela qual as equipes de software adotaram tão prontamente as práticas Agile é porque documentar as necessidades do cliente com documentos de requisitos tradicionais e casos de uso detalhados era extremamente desperdiçador e agregava pouco valor à equipe. Por que não apenas declarar o que o usuário está tentando fazer, escrever uma História de Usuário para documentar o recurso e, em seguida, tratar isso como uma tarefa de desenvolvimento? Isso não é apenas auto-documentado, mas se essas histórias são consistentemente priorizadas e validadas com os clientes, temos o sistema fechado perfeito para responder a mudanças e otimizar o valor. Legal!

Esta tentativa de escrever Histórias de Usuário diretamente como itens de trabalho para o desenvolvimento de hardware, enquanto as rastreia até resultados valiosos para o cliente, é frequentemente o ponto de ruptura do Agile para muitas equipes de hardware. Definir hardware é simplesmente diferente de definir software. Documentos de Requisitos do Produto (PRDs) tradicionais e especificações funcionais não são apenas reconfortantes para os desenvolvedores de hardware, mas também fornecem os detalhes necessários para decompor e entregar seu trabalho. Pedir aos desenvolvedores para escrever uma História de Usuário como: "Como uma unidade de processamento, eu preciso de regulação de tensão para garantir uma entrada limpa..." derrota o propósito de capturar o valor do cliente através de Histórias de Usuário e adiciona desperdício sem valor que os desenvolvedores de software estavam tão ansiosos para remover com os princípios Agile.

Como Mike Cohn, um dos primeiros líderes de pensamento em Agile para software, define: "Uma História de Usuário é uma descrição curta e simples de uma funcionalidade contada pela perspectiva da pessoa." A palavra-chave aqui é "pessoa". Agile para equipes de hardware pode obter um valor significativo ao escrever Histórias de Usuário, mas deve usá-las para capturar as necessidades do cliente de pessoas, não definir itens de trabalho. Essas histórias devem então ser traduzidas para atributos do produto e itens de trabalho relacionados que satisfaçam os resultados desejados com técnicas que façam sentido para os desenvolvedores de hardware.

Mito #5: Você Deve Ter Membros Dedicados na Equipe

Uma enquete no LinkedIn realizada pela Vitality Chicago mostrou que 54% dos praticantes de Agile dizem que ter uma equipe dedicada de Scrum ou Agile (implicando membros de equipe dedicados) é uma regra essencial do Agile. Embora não haja discussão sobre equipes dedicadas no Manifesto Ágil, muitos gurus do Agile tratam isso como uma regra, e é difícil argumentar que não haveria muitos benefícios em ter membros da equipe 100% focados em um projeto. Haveria poucas desculpas para não cumprir compromissos, nada para distrair o sucesso, e ninguém dizendo: "Este outro projeto é uma prioridade maior esta semana!"

Contudo, se você já trabalhou em um ambiente de desenvolvimento de hardware, sabe que ter membros dedicados na equipe seria um luxo que poucas organizações podem se dar ao luxo. A natureza do desenvolvimento de hardware é que arquitetos, designers líderes e outros especialistas no assunto (SMEs) são frequentemente necessários em múltiplos projetos. Uma empresa pode ter um especialista em frequência de rádio que é chamado quando sua expertise é necessária, um especialista em layout que é necessário em momentos chave, etc. Equipes de desenvolvimento de hardware ainda podem adotar e aproveitar métodos Ágeis, mas ter membros dedicados na equipe geralmente não é uma opção. Portanto, ter uma abordagem de gestão de recursos que apoie o Ágil é crítico para o sucesso a longo prazo do Ágil.

#Mito 6: Ágil é a Soma de Seus Papéis, Rituais, Cerimônias e Vocabulário Definidos

Duas equipes estão trabalhando lado a lado em uma empresa: uma equipe de hardware usando uma abordagem tradicional em cascata e uma equipe de software usando métodos Scrum. Um desenvolvedor de hardware passa pela sala de conferência onde os desenvolvedores de software estão reunidos em círculo e ouve, "Ok, bem-vindos ao nosso standup. Durante o último sprint, tivemos dificuldades com as estimativas de pontos de história do usuário e critérios de aceitação. Nosso scrum master compartilhou nosso último burn-up e facilitou uma retrospectiva para abordar os problemas no grooming do nosso backlog para que possamos aumentar a velocidade. Vamos fazer um punho-a-cinco sobre como estamos nos sentindo em relação às mudanças." Uma variedade de configurações de punhos e dedos rapidamente se levanta.

O desenvolvedor de hardware, embora intrigado, não pode deixar de se sentir um pouco perplexo com esse ritual bizarro e a abundância de termos desconhecidos, perguntando-se como essas metodologias Ágeis poderiam possivelmente se traduzir em seu mundo de desenvolvimento de hardware tangível. "Será que eu entrei em um culto?!" ele se pergunta.

Muitas vezes, os gurus do Agile estão tão imersos na linguagem e cultura do Agile para software que acreditam que as equipes de hardware devem adotar exatamente as mesmas cerimônias, papéis, ferramentas e linguagem para verdadeiramente "serem Ágeis". Ironicamente, o primeiro princípio no Manifesto Ágil afirma, "Indivíduos e interações acima de processos e ferramentas." Acho que podemos construir sobre isso e afirmar ainda, "Indivíduos e interações acima de processos, ferramentas, rituais e dogmas." Embora concordar sobre a linguagem, formatos de reuniões e atividades específicas para construir uma mentalidade Ágil e uma forma sistemática de trabalhar sejam todos críticos para o sucesso, adotar os rituais e vocabulário específicos do Scrum ou Ágil para software não é. As equipes de hardware devem olhar para o propósito e intenção de cada elemento Ágil, cerimônia e papel e determinar o que e como cada um pode melhor atender às suas necessidades.

Superando o Abismo Ágil-Hardware

À medida que você pondera se uma abordagem Ágil é adequada para seus esforços de desenvolvimento de hardware e eletrônicos, a "sabedoria" convencional propagada por gurus Ágeis bem-intencionados muitas vezes fica aquém em orientar a abordagem mais matizada e adaptativa necessária pelo desenvolvimento de produtos físicos. O caminho para uma implementação Ágil bem-sucedida em hardware envolve uma mistura cuidadosa de flexibilidade, preparação prévia, planejamento iterativo e uma abordagem consciente para convergir na solução mais valiosa possível no menor tempo.

No segmento de conclusão da nossa série de três partes, vamos aprofundar ainda mais em como aproveitar as vantagens do Agile modificado para o desenvolvimento de hardware eletrônico, mantendo os princípios fundamentais da metodologia Agile. Está interessado em explorar o tema com mais detalhes? Assista ao webinar!