Manter software funcionando, por mais tempo, demanda esforços de engenharia – seja para criação, modificação ou operação do software.
 | As leis de Lehman As “Leis de Lehman ajudam a entender o desafio de atender a necessidade de fazer adaptações em um software ao longo do tempo, preservando a complexidade – e os custos – sob controle. Conheça as leis de Lehman nesse episódio disponível em áudio e vídeo. |
Toda vez que faltar capacidade para realizar uma adaptação em um software, decorrente de uma mudança de negócios ou tecnológica, corre-se o risco de destruição de valor.
O que é engenharia de software
Engenharia compreende todas as políticas, práticas e ferramentas necessárias para manter um software funcionando, em produção, pelo tempo que for necessário, em dia com eventuais modificações tecnológicas e negócios, permitindo engajamento e colaboração entre times.
Para ser efetiva, a engenharia de software deve suportar mudanças de escala, ao longo do tempo, tanto de uso quanto da organização, preservando ou melhorando a eficiência.
 | Software Engineering at Google Como a Google, uma das maiores empresas de tecnologia do mundo, trata engenharia de software? Quais foram as lições aprendidas pela companhia ao longo de sua jornada? Essa é a temática desse livro fantástico. |
 | A eficiência da engenharia de software é demonstrada pela sustentação razoável dos custos em diversas dimensões (financeira, técnica, por transação ou oportunidades). |
Definição: Custo de Oportunidade
O custo de oportunidade está relacionado as vantagens que deixam de ser obtidas em função de atividades que não são executadas em função daquelas que se está executando.
A pergunta-chave para identificação de custos de oportunidade é: “O que estou deixando de fazer para fazer o que estou fazendo?”
Engenharia de software e o CTO
O CTO (acrônimo para Chief Technology Officer) é o responsável, dentro de uma organização, pela eficiência da engenharia de software. Aliás, um bom título alternativo para a posição, em Português, seria “Diretor de Engenharia”.
Aliás, é atribuição desse executivo, elevar aspectos de engenharia a relevância estratégica. Não há mais espaço, frente as demandas modernas de tecnologia, para que TI seja percebida como custo, asset ou mesmo partner. Tecnologia é enabler em qualquer organização moderna – dissociável de uma atividade fim.
| Como TI é percebida em sua empresa? Interessado em entender melhor as diferenças das percepções de TI como custo, asset, partner e enabler? Acompanhe esse episódio do Tech&Biz, sobre o tema, disponível em áudio e vídeo. |
 | A Seat at the Table: IT Leadership in the Age of Agility Nesse livro, Mark Schwartz compartilha insights importantes para elevar tecnologia e processos de engenharia a relevância estratégica. |
| O que faz um CTO? O que faz um CIO? Em muitas organizações, os títulos de CIO e CTO são utilizados de maneira “desleixada” e, com frequência, são considerados intercambiáveis. Isso acontece por causa da falta de entendimento das responsabilidades, do que e quem estes executivos gerenciam. Vamos resolver essa confusão? |
Relação entre engenharia e arquitetura de software
 | Manual do Arquiteto de Software Neste livro, disponível na íntegra on-line, formalizamos e demonstramos a disciplina de arquitetura de software, orientando sua execução. |
Software com boa arquitetura permite a implementação de adequações com adição mínima de complexidades. Enquanto disciplina, se conduzida de maneira apropriada, a arquitetura de software garante que decisões relevantes sejam tomadas, justificadas, comunicadas e obedecidas, garantindo que os objetivos de negócio sejam atingidos, restrições respeitadas e atributos de qualidade alcançados.
 | Como arquitetos de software tomam decisões Tomar decisões sempre é um desafio quando falamos de arquitetura de software, já que problemas arquiteturais, podem surgir a qualquer momento. E você, está preparado para enfrentá-los? Listamos 4 questionamentos de extrema importância que irão te ajudar neste processo. |
Métricas importantes para a engenharia de software
 | Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, e não há sucesso no que não se gerencia. William Deming |
A engenharia de software será tão eficiente quanto for capaz de permitir que software seja adaptado para atender mudanças tecnológicas e de negócios, durante o ciclo de vida de uma solução.
 | Accelerate: The Science of Lean Software and DevOps Neste livro são apresentadas e formalizadas as quatro métricas indicadas aqui apontando o relacionamento delas com o sucesso da área de engenharia e, por consequência, para a organização. |
As métricas geralmente associadas a eficiência da engenharia de software são:
- Delivery lead-time, ou seja, o tempo entre a implementação de uma adaptação ser realizada por um desenvolvedor e o deploy. Isso inclui tempos, por exemplo, relacionados com processos de build, integração, testes e, obviamente, deploy. Quanto menor for o delivery lead-time apurado, melhor.
- Frequência de deploys, que impacta diretamente no tamanho do batch, ou seja, na quantidade de adaptações presentes em cada deploy. Idealmente, quanto menor o tamanho do batch, logo, maior a frequência de deploys melhor.
- MTTR, ou tempo médio que para que sistemas em condição defeituosa sejam restaurados. Quanto menos tempo, melhor.
- Taxa de defeitos, indicando o percentual de modificações em ambiente produtivo – seja para atualização de sistema ou alteração de configurações de infraestrutura – que falham.
As duas primeiras métricas tem relação direta com a performance da engenharia, as duas últimas indicam a estabilidade dos sistemas de software produzidos.
| Conseguir obter os dados necessários para determinação das “quatro métricas” é fundamental para melhoria dos processos de engenharia. |
De muitas formas, a excelência nos resultados relacionados com as quatro métricas aqui recomendadas indicam times com prontidão para atender as demandas do negócio e responder adequadamente as mudanças tecnológicas.
| A eterna discussão sobre “prazos”, nas organizações, que gera tantos conflitos entre times de negócios e de engenharia, deveria ser substituída por “prioridades” (determinada pelo “negócio”) e “throughput” (garantido pelos times de engenharia). |
Topologia dos times de engenharia
Desenvolver software é atividade humana e coletiva. Logo, a topologia dos times é fundamento para a aplicação da boa engenharia.
 | Team Topologies: Organizing Business and Technology Teams for Fast Flow Neste livro ficam estabelecidas as relações entre as organizações dos times em uma organização e a performance alcançada. |
As implicações da lei de Conway são determinantes para o estabelecimento de uma organização de engenharia de alta-performance.
| As lei de Conway A “lei de Conway” indica que as estruturas dos sistemas de software são “espelhos” das estruturas das organizações que os desenvolvem. Conheça a lei de Conway nesse episódio disponível em áudio e vídeo. |
O papel do engenheiro de software
O engenheiro de software é todo profissional que aplica as políticas, práticas e adota as ferramentas determinadas pela engenharia para o desenvolvimento de software. O papel inclui analisar e modificar software existente, bem como projetar, implementar e testar sistemas de forma a atender as necessidades do negócio.
Para pensar…
Sendo as práticas de engenharia cada vez mais relevantes para o sucesso das organizações, é natural que elas sejam conduzidas de forma cada vez mais estruturada e suportada por métodos e metodologias.
O grande desafio da moderno é trazer capabilities de engenharia para empresas que não tem desenvolvimento de software como atividade fim. É fato que tais capabilities demandam das empresas procedimentos e competências que podem se afastar e muito do que é demandado pelo restante da organização.
A busca da excelência em engenharia de software é, antes de tudo, um desafio de transformação cultural.
