BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Bate papo sobre o livro Engineering the Digital Transformation

Bate papo sobre o livro Engineering the Digital Transformation

Favoritos

Pontos Principais

  • É difícil transformar o modo como desenvolvemos softwares, até começarmos a focar na qualidade;

  • Antes de começar a criar qualidade, é importante garantir que tenhamos um indicador de qualidade estável;

  • Precisamos tornar os processos de desenvolvimento e entrega de software visíveis antes de pedirmos a empresa para investir em melhorias;

  • Transformar os processos de desenvolvimento e entrega de software são grandes mudanças culturais que são melhor conduzidas pelo modelo top-down;

  • Os processos de melhoria contínua funcionarão melhor se conseguirem envolver todas as pessoas, da presidência passando pela gerência até o chão de fábrica de uma empresa, e isso exigirá uma abordagem muito bem estruturada.

O livro Engineering the Digital Transformation, de Gary Gruver, fornece uma abordagem sistemática para melhorar de maneira contínua as empresas, explorando como podemos alavancar e modificar as práticas de engenharia e fabricação para abordar as características e capacidades exclusivas do desenvolvimento de software.

Os leitores do InfoQ podem baixar uma amostra do Engineering the Digital Transformation e utilizar o voucher de 10% de desconto que está incluído no link.

O InfoQ entrevistou Gary Gruver sobre a história do desenvolvimento de software e o que está faltando na maneira como desenvolvemos, como podemos tornar visíveis os produtos e a maneira como são desenvolvidos, discutimos sobre as melhorias na qualidade do software, como criar uma cultura de melhoria contínua e como tirar mais proveito dela, além de falar sobre a abordagem sistemática em relação ao gerenciamento de software.

InfoQ: O que motivou a escrever o livro?

Gary Gruver: Escrevi este livro porque estava vendo muitos clientes sofrendo na tentativa de progredir, mas não conseguiram nenhum resultado na tentativa de transformar os processos de desenvolvimento e entrega de software mais rápido. Estavam implementando todas as práticas recentes de Agile e DevOps, mas não estavam conseguindo ver os resultados nos negócios, e sabia que eram possíveis de serem feitos. Cheguei à conclusão de que, se o setor iria se transformar na taxa exigida pelos negócios, precisávamos de uma abordagem muito mais sistemática para a melhoria contínua.

InfoQ: Para quem o livro é destinado?

Gruver: É destinado a qualquer pessoa que trabalhe em uma empresa que precisa de um software para oferecer uma vantagem competitiva e está frustrado porque ela não consegue se desenvolver rápido o suficiente.

InfoQ: Quais são as principais abordagens que moldaram a história do desenvolvimento de software e qual foi o impacto?

Gruver: As pessoas começaram a gerenciar o desenvolvimento de software da mesma maneira que gerenciavam outros tipos de desenvolvimento de produtos com o processo de P/D (Pesquisa e Desenvolvimento), mas no caso do software chamavam de, ciclo de vida de desenvolvimento de software. Com o tempo, as pessoas descobriram que isso não funcionava muito bem porque a tecnologia de software muda tão rapidamente que era impossível planejar com precisão necessária, semelhante ao desenvolvimento tradicional de produtos. Além disso, é muito mais fácil mudar o software do que os produtos tradicionais, então as pessoas começaram a perceber que precisavam de uma abordagem diferenciada.

O primeiro grande passo para mudar como estava sendo gerenciado o desenvolvimento de software, foi mudar o modelo cascata (ciclo de vida de um projeto) para o Agile. Essa abordagem foi baseada em princípios sólidos, mas algumas empresas focaram tanto nos rituais da metodologia que perderam a essência dos fundamentos. Os Poppendiecks tentaram corrigir isso, concentrando-se nos princípios Lean que apoiavam o Agile, em vez de ficar apenas nos processos. Todas essas etapas ajudaram a dar um passo na direção correta, mas as pessoas ainda estavam lutando com o princípio Agile de liberar o código dos clientes com mais frequência para obter feedback, que foi perdido à medida que o Agile escalava para outras áreas da empresa. Isso coloco em foco o DevOps, muito utilizado para enfrentar esses desafios.

Essas foram melhorias boas e significativas, porém como trabalhei com os clientes para entender mais sobre os resultados de negócios que tive na HP, senti que as abordagens poderiam ser melhoradas. Senti que, se os clientes alcançariam os resultados de negócios que mereciam, precisavam de uma abordagem mais sistemática que pudesse envolver todas as pessoas na jornada de melhoria contínua.

InfoQ: Na sua opinião, qual é o principal aspecto que falta na maneira como desenvolvemos softwares?

Gruver: Provavelmente a maior transformação que permite diversas mudanças é a transição para a construção de qualidade. A manufatura fez essa transição há muito tempo e mudou fundamentalmente, a eficácia e a eficiência das fábricas. A maioria das software houses não fez essa mudança na abordagem, portanto não podem alterar o restante dos processos de desenvolvimento e de entrega. Como os testes tradicionais de software são manuais, lentos e caros, a empresa agrupa grandes quantidades de alterações para testar a qualidade tardiamente no processo, normalmente quando atingem um certo momento, como a finalização do desenvolvimento. Isso é ineficiente e leva a processos muito complexos de triagem e correção de defeitos, além de limitar a capacidade de receber feedback dos clientes regularmente.

Os testes automatizados estão começando a mudar essa realidade, mas a maioria das pessoas faz isso somente para tornar os testes manuais mais baratos, não descobriram como utilizá-lo para alterar os recursos da empresa. Isso requer a execução do teste automatizado com mais frequência e muito mais próximo dos desenvolvedores, além de exigir que respondam a esse feedback enquanto escrevem o código. Esta é uma grande mudança cultural para a maioria das empresas e é onde vejo a maioria das transformações patinarem. Não seguem essa etapa ou, quando a fazem, começam a exigir que os desenvolvedores respondam aos comentários do teste antes de terem um indicador de qualidade estável. Depois de ver muitas empresas sofrendo com esse problema, cheguei à conclusão de que precisava alertar as pessoas para evitar esse erro e criar uma abordagem mais sistemática para garantir um indicador de qualidade estável. Essa foi uma das maiores motivações para escrever o livro.

InfoQ: Foi mencionado que o fato do software não ser um produto físico é um dos desafios para se fazer as melhorias. Como podemos deixar visíveis os produtos e a maneira como são desenvolvidos?

Gruver: Precisamos entender a arquitetura e, posteriormente, mapear o pipeline de implantação para que fique visível à todos. A arquitetura tem um impacto significativo no design do pipeline de implantação, e ele tem um impacto significativo na produtividade das equipes de desenvolvimento de software. Precisamos tornar isso visível se esperamos que as pessoas invistam em melhorias e envolva a empresa como um todo na melhoria contínua.

O livro tem vários exemplos de diferentes tipos de arquiteturas e aplicações além das implicações nos pipelines de implantação. Enquanto trabalho com diferentes empresas, acho que a maneira mais fácil de levar as pessoas a documentar os pipelines de implantação é fazê-las descrever todos os diferentes ambientes que usam nos processos de desenvolvimento e de entrega. Começam com o código em uma estação de trabalho do desenvolvedor e, quando fazem o check-in, seguem para o caminho da produção? Vai para um ambiente de desenvolvimento integrado posteriormente? Ou para o controle de qualidade? Talvez um UAT? Ou para o staging? Algumas vezes, alterando diretamente na produção. Essas etapas definem o pipeline de implantação e todas as aplicações que existem nesses ambientes de teste integrados imediatamente antes da produção representam a arquitetura fortemente acoplada. Com isso, podemos criar uma visão simples do pipeline de arquitetura e de implantação.

Essa é realmente uma forma de mapeamento do fluxo de valor, mas achei muito útil como forma específica para destacar os problemas e as oportunidades de melhoria no desenvolvimento e fornecimento de software. Comecei usando abordagens padrão do setor para o mapeamento do fluxo de valor e descobri que, mesmo com empresas de manufatura que tinham facilitadores com décadas de experiência em mapeamento do fluxo de valor, não estavam destacando muito bem os problemas. Além disso, embora o processo de mapeamento fosse valioso para as pessoas na sala, normalmente era tão complexo que era difícil compartilhar as informações além das pessoas que criaram o mapa. Essas experiências levaram-me a ser muito específico sobre os tipos de mapas que queremos criar e os dados que queremos preencher dentro deles.

InfoQ: Como podemos melhorar a qualidade do software?

Gruver: A principal mudança que é necessária, é passar da inspeção de qualidade em grandes lotes para incorporá-la à medida que o software é desenvolvido. Isso, exige que tenhamos uma qualidade estável, o que é um grande desafio para a maioria das grandes empresas, pois precisam reservar um tempo para garantir que entendam e tratem de todas as fontes de instabilidade antes de começarem a tentar melhorar a qualidade, ou então a transformação vai sofrer e perder força. Há um exercício muito simples que recomendo a todos os clientes para garantir um sinal de qualidade estável. Primeiro, selecione um ambiente ao longo do pipeline de implantação para o exercício. Tente escolher o mais próximo da produção, pois isso influenciará a empresa a mudar. Um ambiente mais longínquo ajudará apenas os desenvolvedores que trabalham nele, os próximos a produção não tem influência suficiente para implementar as alterações necessárias para um indicador de qualidade estável. Em seguida, faça todos os testes automatizados e execute-os 20 vezes seguidas nesse ambiente na mesma versão de código. Coloque o resultado em um banco de dados e represente graficamente as taxas de aprovação. A maioria dos clientes acredita que tem alguns testes que sempre irão passar, alguns que vão falhar algumas vezes devido a algum defeito e vários irão ficar alternando entre sucesso e falha. Esses testes que ficam alternando não podem ser usados ​​como um sinal de qualidade estável e precisam ser reservados para retrabalho. E os testes com falha precisam ser deixados de lado até que o defeito esteja corrigido. Agora, faça todos os testes que foram dados como sucesso e execute-os novamente em ordem aleatória. Isso destacará todos os testes adicionais que precisam ser retrabalhados antes que possam ser usados ​​como um sinal de qualidade estável. Isso nos leva a um conjunto de testes estáveis ​​que podemos usar para avaliar a estabilidade do restante do sistema.

Agora, tomamos esse conjunto e os executamos em paralelo no ambiente de teste para ver se conseguem lidar com toda a carga. Na maioria das vezes, veremos que este processo descobrirá mais instabilidades que precisam ser avaliadas e corrigidas. Em seguida, queremos garantir que tenhamos um processo de implantação que seja repetível e estável. Use o mesmo ambiente, mas desta vez vamos implantar o código e executar o teste. Em seguida, implante o código novamente e execute o teste. Faça isso 20 vezes seguidas e inclua os resultados no banco de dados para procurar problemas de implantação. Se encontrar algum, precisam ser corrigidos antes de continuar. Por fim, desejamos executar o mesmo experimento 20 vezes seguidas, começando com a criação do ambiente do zero.

Esse processo juntamente com o conjunto de experimentos obriga a corrigir os problemas que estão causando instabilidade no indicador de qualidade. Só agora estaremos prontos para começar a realmente criar qualidade. Muitas empresas ignoram esta etapa e descobrem que executar os testes automatizados com mais frequência é muito difícil, porque acabamos constantemente criando problemas associados aos testes, implantações e ambientes que não têm nada a ver com os problemas de qualidade do código que estamos tentando encontrar.

InfoQ: O que pode ser feito para criar uma cultura de melhoria contínua?

Gruver: Minha experiência diz que se for liderado por executivos, ela funciona melhor, razão pela qual passo muito tempo realizando workshops com a gerência. Foi também uma motivação para escrever meu segundo livro, Leading the Transformation. Existem muitos recursos no setor para ajudar os engenheiros a descobrir como implementar novas tecnologias, mas não muitos para os executivos que estão trabalhando para criar uma cultura de melhoria contínua. Leading the Transformation, e este livro, Engineering the Digital Transformation, foram desenvolvidos para ajudar a preencher essa lacuna.

Os executivos precisam entender que necessitam definir a expectativa do trabalho de todos, não apenas do próprio trabalho, mas também para tentar descobrir como fazer um trabalho melhor. Precisam ajudar a fornecer a largura de banda para fazer melhorias e fornecer uma abordagem estruturada para gerá-las. Se conseguirmos que cumpram esse papel, a transformação será muito mais fácil.

Caso contrário, podemos fazer algumas coisas para criar a cultura de bottom-up, mas a maioria desses esforços diminui com o tempo, à medida que as pessoas se cansam de brigar com os sistemas engessados. É por isso que tento o máximo possível que os clientes consigam que os executivos se envolvam na liderança da transformação.

InfoQ: Qual é o conselho para as empresas que desejam adotar uma abordagem mais sistemática no gerenciamento de software?

Gruver: Precisam começar com um entendimento comum da abordagem que será usada em toda a empresa. As pessoas precisam de uma estrutura comum para analisar os problemas, se quiserem concordar com o que precisa ser melhorado. O objetivo deste livro é fornecer a estrutura comum que pode ser utilizada para criar este entendimento único. O livro não pretende ser a resposta final para a abordagem sistemática de software, mas sim um ponto de partida projetado para abordar os recursos e características exclusivos do software que podem ser ajustados e aprimorados pelas grandes mentes, como aconteceu no processo de fabricação.

Sobre o autor do livro

Gary Gruver é um executivo experiente, com um histórico comprovado de transformação de processos de desenvolvimento e entrega de software em grandes empresas. Sua paixão atual é ajudar o maior número possível de pessoas a obter resultados semelhantes por meio de consultoria, webinars, palestras e livros. 

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT