The Lean Startup methodology, developed by Eric Ries in his 2011 book The Lean Startup, is a framework for building businesses and products efficiently in high-uncertainty environments. Drawing from Toyota’s lean manufacturing, it focuses on minimizing waste, accelerating learning, and validating ideas quickly. Its three core pillars are:
Small batch delivery: Releasing products or features in small iterations instead of large launches.
Scientific validation: Testing hypotheses with experiments, such as Minimum Viable Products (MVPs).
Rapid feedback cycles: Using the build-measure-learn loop to iterate based on customer data and reactions.
The goal is validated learning, discovering what customers truly want before significant investment. For instance, instead of building a full app, a startup might create a landing page to gauge demand.
Why is Lean Startup different?
Traditional business models rely on detailed plans, long timelines, and financial projections. These work in predictable markets but fail in innovation-driven contexts where customer needs are unclear. A customer saying “I wanted a button to do X” signals a product missed the mark — something Lean Startup avoids through constant validation.
Unlike the romanticized “garage entrepreneur” who tries endlessly without a method, Lean Startup blends creativity with structured management, using scientific experimentation to reduce risks.
Suggested image:
Description: Infographic of the build-measure-learn cycle, with circular arrows showing steps (Build → Measure → Learn) and icons (e.g., prototype for “Build,” chart for “Measure,” lightbulb for “Learn”).
Alt text: Infographic of the build-measure-learn cycle in the Lean Startup methodology, illustrating the steps of creation, measurement, and learning.
Purpose: Visualize the core process.
When Did Lean Startup Emerge?
The Lean Startup methodology was formalized by Eric Ries in 2011 with the release of The Lean Startup. Its roots trace back to the early 2000s, when Ries, working at startups like IMVU, noticed that long development cycles led to products misaligned with the market. Inspired by Toyota’s lean manufacturing — emphasizing just-in-time production, minimal inventory, and continuous improvement — Ries adapted these principles to entrepreneurship.
He combined agile development, customer feedback, and scientific experimentation, creating a globally adopted framework. The methodology has since influenced startups, corporations, and even government initiatives worldwide.
How to Apply the Lean Startup Methodology: A Practical Guide
Applying Lean Startup involves structured experimentation. Here’s a five-step guide, true to Ries’ book:
Identify hypotheses: Use the Lean Canvas to map assumptions about the problem, solution, target audience, and revenue model. Example: “Young professionals want a simple financial management app.”
Build an MVP: Create the simplest version of the product to test hypotheses, like a prototype, video, or landing page. Dropbox used a demo video as an MVP to validate demand for cloud storage.
Measure with actionable metrics: Avoid vanity metrics (e.g., total downloads) and focus on indicators like conversion rates or engagement. Example: How many users sign up via the MVP?
Learn and decide: Analyze data and feedback to choose between persevering (refining) or pivoting (changing strategy). Airbnb pivoted from conference rentals to a broader home-sharing platform after early feedback.
Iterate quickly: Use the build-measure-learn loop to release new versions, incorporating insights.
Recommended Tools
Tool
Purpose
Example
Lean Canvas
Map hypotheses
Plan a delivery app
Google Analytics
Track metrics
Measure clicks on a landing page
Figma
Build prototypes
Design an MVP interface
Typeform
Collect feedback
Send user surveys
Suggested image:
Description: Table comparing actionable metrics (e.g., conversion rate) vs. vanity metrics (e.g., total downloads), with check (✅) and warning (⚠️) icons.
Alt text: Table comparing actionable and vanity metrics in the Lean Startup methodology, highlighting practical examples.
Purpose: Clarify metric selection.
Lean Startup in Large Companies: The Innovation Sandbox
Large companies often resist Lean Startup, favoring traditional methods like waterfall, which plan everything upfront. This approach frequently leads to products that miss market needs, especially in fast-moving industries like tech.
Corporate Challenges
Fear of failure: Managers worry that limited-feature MVPs harm brand reputation.
Ries advocates for an innovation sandbox, a controlled space where teams test ideas without affecting the core business. Sandbox rules include:
Limited tests: Conduct A/B tests on specific product parts or customer segments (e.g., 5% of users).
Continuous oversight: One team monitors the experiment from start to finish.
Defined duration: Weeks for simple tests, longer for major innovations.
Standardized metrics: Evaluate with 5-10 actionable metrics (e.g., retention rate).
Active monitoring: Cancel experiments if negative reactions arise (e.g., social media backlash).
Example: General Electric used a sandbox to test IoT solutions for industrial equipment, validating concepts before scaling.
Suggested image:
Description: Diagram of an innovation sandbox, showing a parent company (building icon) and an isolated area (box with team and experiments), with arrows indicating limited tests.
Alt text: Diagram illustrating the innovation sandbox in the Lean Startup methodology, showing controlled tests in large companies.
Purpose: Visualize the sandbox concept.
Real-World Success Stories
In Brazil
Nubank: Launched an MVP with a no-fee credit card, testing demand for digital financial services. After validation, it expanded to accounts and investments.
Easy Taxi: Started as a taxi app but pivoted to ride-hailing after user feedback, becoming a Latin American leader.
Globally
Dropbox: Used a simple video as an MVP to demonstrate cloud storage, validating demand before building the product.
Airbnb: Tested its idea with a basic website offering rooms during a conference, iterating based on early feedback.
Suggested image:
Description: Carousel with four logos (Nubank, Easy Taxi, Dropbox, Airbnb) and brief MVP descriptions.
Alt text: Carousel showcasing successful MVP examples in the Lean Startup methodology, including Nubank, Easy Taxi, Dropbox, and Airbnb.
Purpose: Highlight practical cases.
Challenges and How to Overcome Them
Unclear hypotheses: Solution: Use the Lean Canvas to structure ideas.
Wrong metrics: Solution: Prioritize actionable metrics like engagement over vanity metrics.
Cultural resistance: Solution: Run Lean Startup workshops and start with small tests.
Over-iteration: Solution: Set clear deadlines for feedback cycles.
Frequently Asked Questions (FAQ)
What is an MVP in Lean Startup? A Minimum Viable Product is the simplest product version used to test hypotheses with minimal effort. Example: a landing page to gauge interest.
Does Lean Startup work for large companies? Yes, using innovation sandboxes, companies can test ideas without risking core operations, as General Electric did with IoT solutions.
How to choose actionable metrics? Focus on metrics reflecting user behavior, like conversion rates, rather than broad metrics like page views.
Suggested image:
Description: FAQ box with question-and-answer icons, highlighting the three questions above.
Alt text: Infographic of frequently asked questions about the Lean Startup methodology, with answers on MVP, large companies, and metrics.
Purpose: Capture featured snippets.
Conclusion
The Lean Startup methodology, pioneered by Eric Ries, empowers entrepreneurs and companies to innovate with less risk and greater efficiency. By prioritizing validated learning, MVPs, and rapid feedback cycles, it turns uncertainty into opportunity. Global successes like Dropbox and Airbnb, alongside Brazilian stars like Nubank, prove its impact, while large companies can leverage sandboxes to stay competitive.
To get started, build a simple MVP, measure actionable metrics, and iterate based on feedback. Lean Startup isn’t just a methodology — it’s a mindset for shaping the future.
Ready to apply Lean Startup? Share your idea in the comments or explore tools like Lean Canvas to kickstart your journey!
Considere o seguinte questionamento considerando o processo de desenvolvimento atual da equipe em que você trabalha:
Se algum cliente ou o gerente de produto trouxer uma nova ideia, como garantir que a entrega em produção seja feita o mais rápido possível garantiando a qualidade na entrega?
Em um produto já estabelecido, com múltiplos times cuidando de diversas soluções, é necessário ter preocupação com a capacidade de entrega em produção com agilidade. O mercado de produtos de tecnologia está cada vez mais aquecido, demandando que novas ideias sejam implantadas rapidamente. Além disso, problemas em produção surgem e devem ter suas correções entregues independente do estado em que o código se encontre no repositório compartilhado.
Sendo assim, para uma entrega “às pressas” podem haver pontos de atenção como os listados abaixo:
Outras funcionalidades ainda não testadas entrarão junto?
Quantas funcionalidades inacabadas terão seu código incluído na versão que irá para produção?
Será necessário criar mais uma branch além das branches que já existem atualmente?
Quanto tempo as equipes estão gastando para resolver conflitos de código?
A Entrega Contínua te ajuda a resolver esses problemas e nesse artigo falaremos sobre os príncipios e práticas que, se bem utilizados, te ajudará a implantar Entrega Contínua com sucesso.
Entrega Contínua é um modelo de entrega de software (software delivery) em que novas funcionalidades e soluções de bugs são entregues em produção rapidamente de forma segura e sem impacto negativo para os usuários.
Adicionalmente, tem como um dos objetivo resolver problemas relacionados a mudança de estratégia e prioridades, diminuíndo o impacto dessas mudanças no fluxo de trabalho do time uma vez que as alterações de código são continuamente entregues em produção.
Vale lembrar que o entendimento de entrega em produção é o termo usado para definir as etapas entre o commit/push dos desenvolvedores até as alterações serem percebidas pelos usuários, ou seja, ao menos um usuário estará habilitado a usar a nova funcionalidade.
No dia-a-dia, é comum relacionar a não adoção de Entrega Contínua por motivos de demandas muitos grandes que envolvem muitas alterações de código ou vários commits intermediários, ou ainda ser uma demanda complexa que demoraria algumas semanas para estar pronta. No entanto, a Entrega Contínua é exatamente o que simplifica o processo até mesmo nesses cenários.
Ainda, a adoção correta da Entrega Contínua depende de mudanças culturais. Para a implentação com sucesso, é necessário seguir algumas práticas e metodologias que você verá a seguir.
Princípios e práticas
Alguns princípios são essenciais para a adoção da Entrega Contínua. São eles:
Integração contínua em repositório de código
Feature Flags para entregas experimentais
Entregas em pequenos lotes
Automação de tarefas repetitivas
Qualidade de entrega
Automação de tarefas repetitivas
Monitoramento
Muito se fala sobre ferramentas e plataformas tidas como “necessárias” e “habilitadoras” da Entrega Contínua. Na maioria dos casos, com ferramentas simples é possível – e quase sempre mais fácil – implemetar com sucesso Entrega Contínua
Integração Contínua
A integração contínua (CI) é uma das práticas mais importantes da entrega contínua. A integração contínua automatiza o processo repetitivo de integração de código novo em um repositório de código compartilhado. Isso ajuda a garantir que o código novo seja integrado com o código existente continuamente.
A integração contínua se diferencia da entrega contínua pois esta última define fases além da integração de código, garantindo que o código seja devidamente empacotado, testado e entregue em produção.
Pipeline de Entrega Contínua: A entrega contínua compreende a integração (código) e o empacotamento com o deploy em produção na sequência.
Considero a integração contínua como sendo o primeiro grande desafio a ser vencido. Ora, a entrega começa na ação de commit/push dos desenvolvedores. Há várias estratégias usadas para implementar a integração contínua: branch única, gitflow, branch local, entre outras. Destaco aqui a estratédia de branch única.
Manter uma branch única simplifica o uso do controle de versão. Além disso, reforça a responsabilidade de commits pequenos que levam os desenvolvedores a pensar em alterações em pequenos lotes.
Feature Toggle
Manter o repositório de código atualizado com commits diários é o cenário perfeito para integração contínua. Porém, é necessário controlar a entrega de funcionalidades experimentais e inacabadas. Feature Toggles é o caminho para tal controle.
Em um ambiente tradicional, os desenvolvedores precisam esperar até que uma funcionalidade esteja totalmente desenvolvida e testada antes de poder liberá-la em produção. Isso pode levar meses.
Os feature toggles são uma técnica que permite aos desenvolvedores liberar recursos inacabados ou experimentais sem afetar a experiência do usuário. Um feature toggle é, em geral, uma variável de configuração que pode ser usada para habilitar ou desabilitar uma funcionalidade ou um fluxo de código em tempo de execução.
Logo, os desenvolvedores podem entregar em produção um código que será usando condicionalmente. Com isso, é possível liberar uma nova funcionalidade para um ambiente específico, um grupo de usuários específicos, ou até mesmo para usuários que dêm opt-in para funcionalidades experimentais.
Os feature toggles são uma ferramenta importante para a entrega contínua, pois permitem que os desenvolvedores:
Liberem novos recursos e funcionalidades mais rapidamente, sem afetar a experiência do usuário;
Testem novas funcionalidades com um pequeno grupo de usuários antes de liberá-las para toda a base de usuários;
Experimentem diferentes versões de uma funcionalidade para descobrir qual é a melhor em termos de desempenho, aceitação de usuário, etc.
É importante o uso de feature toggles com disciplina. Usar feature toggles para qualquer fluxo, sem uma definição de propósito pode levar a códigos complexos e sujos. Abaixo, uma lista de dicas para uso de feature toggles
Use feature toggles apenas quando necessário. Não use feature toggles para deixar um código inacabado por pressa;
Seja claro sobre o propósito de cada feature toggle. Na prática, é importante ter o cuidado de dar bons nomes assim como em classes e variáveis;
Documente cada feature toggle. Ele é parte da estratégia da entrega e é uma opção de fluxo em produção;
Use uma ferramenta de gerenciamento de feature toggles para facilitar o controle e a implantação de feature toggles. Firebase Remote Config e Config Cat são boas opções de plataforma.
Os feature toggles são uma ferramenta essencial para a entrega contínua. Ao usá-los de forma eficaz, os times de desenvolvimento podem liberar novos recursos, recursos inacabados e experimentos de forma mais rápida, segura e confiável.
Lotes Pequenos (Small Batches)
Um dos principais desafios da entrega contínua é a mudança cultural. Os times de desenvolvimento precisam mudar de uma mentalidade de “lançar o produto perfeito” para uma mentalidade de “lançar o produto o mais rápido possível e melhorar com o tempo”.
Com a integração contínua e os Feature Toggles já entende-se que é possível ter código integrado todo o tempo até mesmo para códigos que ainda não estão de fato lançados. Porém, para evitar commits com muitas alterações, ou mescla de código com quantidade elevada de arquivos modificados, é necessário ‘quebrar’ as demandas em pequenas entregas.
O conceito de “small batches” pode ajudar os times de desenvolvimento a superar esse desafio. Este conceito baseia-se na ideia de que é possível dividir grandes demandas em demandas menores, que em tese, seriam mais simples de gerenciar. Assim, ao adotar este conceito os times podem criar funcionalidades complexas de maneira incremental.
É importante começar com pequenas entregas. Em vários casos, a primeira entrega de uma funcionalidade complexa é o feature toggle. Como exemplo, a entrega de um dashboard pode ser dividida entre uma nova página e uma entrega para cada gráfico exigido. Com isso, tem-se:
Redução de riscos e erros. Lotes de alteração de código menores são mais fáceis de revisar e testar;
Ciclo de feedback do usuário é mais curto. A partir da primeira entrega é possível coletar métricas de usuário;
Complexidade gerenciável. Tanto em termos técnicos quanto de processos, tarefas menores se tornam mais simples de se gerenciar
Menor quantidade de conflitos de código. Isso reflete diretamente em tempo de desenvolvimento.
Parece simples, mas não é. Principalmente para times novos ou produtos em estágios iniciais, momentos de “viagem mental” é natural e acontece com frequência; de reuniões para definir solução para um problema saem mais dois ou três problemas. E é tentador tentar resolver tudo numa história de usuário só. A sugestão aqui é que comece por dividir uma demanda em tarefas. Realizar uma cerimônia de quebra de história de usuário é uma forma simples e eficaz de fazer essa divisão.
Além disso é importante que as tarefas menores sejam priorizadas. Em ambientes tradicionais de desenvolvimento em que funcionalidades não são divididas em pequenos lotes, é comum que as funcionalidades apresentem gorduras por desejos e anseios. Ao dividir tarefas complexas em lotes pequenos, fica fácil distinguir o que é útil e necessário e o que pode ser deixado para depois dos feedbacks.
Por fim, comece com o que é mais importante. Foque nos recursos e funcionalidades mais importantes para os usuários. E então, melhore continuamente, em pequenos passos metrificáveis.
Automação de tarefas repetitivas (pipeline de entrega)
Tarefas repetitivas consomem tempo, e nesse caso o tempo é multiplicado pela quantidade de vezes que essas tarefas são realizadas. Além do mais, é sustetível a erro executar tarefas sequênciais dentro de ambientes que sofrem alterações; são vários os momentos em que a sequência/processo precisa ser atualizada.
Esse cenário é compatível com entrega de software. Afinal, as várias etapas para entregar um software em produção em geral são etapas identicas, repetidamente realizadas pelos integrantes do time. O problema é o fator humano: em algum momento, a etapa de executar os testes é esquecida.
Entrega contínua define que haja rapidez e confiabilidade. Logo, as etapas de testes unitários, testes de aceitação, validação de disponibilidade de serviços de terceiros, se mantidas manuais, geram erros. A solução do preguiçoso é dizer que documentará o processo, que em algum momento estará desatualizado.
Lembra-se do lema “O teste é a melhor documentação do código”? Grave mais um lema: O pipeline de entrega é a melhor documentação do processo de entrega.
Embora o artigo seja sobre Entrega de Software, há outros aspectos além da entrega que podem ser automatizados: alertas, atualizações de bando de dados, envios de relatórios, entre outros. A automatização de tarefas repetitivas promove:
Mitigação de erro humano. Isso gera maior confiabilidade e eficácia;
Tempo de implatação reduzido. Não é necessário buscar informações em documentações no Confluence ou Sharepoint;
Consistência na entrega. Estando automatizado, todos os parâmetros necessários serão levados em consideração a cada entrega.
Adicionalemnte, é importante que desenvolvedores busquem conhecimento em shell script, ferramentas de gestão de pipelines como Jenkins, Gitlab CI ou Bitrise. Atentem-se em começar o pipeline de entrega pequeno, com um script simples e então ir melhorando-o continuamente. Ao implantar inicialmente uma automação complexa, demandará tempo dando manutenção em algo não necessário.
Teste e Qualidade de Software
“Se eu ‘commitar’ vai pra produção”? Quem nunca escutou essa pergunta trabalhando em um time de desenvolvimento? E a principal razão da cautela percebida nessa questão é culpa da Qualidade de Software (ou da falta dela).
Um dos princípios centrais de qualidade de software em ambientes de entrega contínua é a automação dos testes. Cenários de testes se repetem e a cada nova funcionalidade só aumentam. Considerando a seção anterior acredito que já tenha refletido que testes precisam ser sistematicamente realizados.
Há diferentes abordagens e níveis de testes que juntos podem ser usados para garantir qualidade de software. Neste artigo tratamos sobre Testes Unitários, Testes de Integração e Testes de Aceitação.
Testes Unitários
Tradicionamente, testes unitários são definidos como a prática de testar cada pequena parte única do código: funções, métodos, classes, módulos, etc., garantindo assim que, se cada parte funciona corretamente, então o todo também funciona. No entando, nem sempre isso é verdade.
Ora, a entrega contínua trata de entrega de funcionalidades em um software. Sendo assim, é possível definir teste unitário no nível da unidade de cada funcionalidade. Por exemplo, numa funcionalidade onde a entrega é uma nova URL em uma API que forneça a lista dos seguidores de um usuário e, ainda considerando que todo código escrito é código utilizado (sem códigos legados deixados por apego), é possível escrever cenários de testes que validem todos as entradas (incluindo entradas com erros e casos extremos) e todas as saídas possíveis (incluindo exceções e resultados de erros) escrevendo apenas testes que acessam apenas a URL.
O teste unitário deve então executar fluxos completos e não apenas testar funções ou classes. Dessa forma evita-se o uso de mocks de código pertencente ao código. Nunca se deve ‘mockar’ um código que não seja de terceiro.
Outrossim, não se deixe ser levado pela vaidade de ter 100% de cobertura nos testes. Certifique-se de que testou 100% dos cenários possíveis partindo do ponto de entrada da funcionalidade, criando mocks apenas de bancos de dados e API’s de terceiros; afinal, alguém já testou o banco de dados que estás usando.
Testes de Integração
Testes de integração vão um passo além dos testes unitários. Logo, o que antes era ‘mockado’ ou simulado, agora precisa ser de fato utilizado.
Em geral usa-se ambientes de homologação com a mesma versão que irá para produção para executar tais testes. Nesse caso, uma inserção em banco de dados é feita de fato no banco de dados de homologação e os testes devem validar os dados inseridos. Conexões com outros módulos ou microserviços também são testados nesse nível de testes.
Testes de Aceitação
O teste de aceitação é aquele realizado na perspectiva do usuário.
O que o teu usuário de fato vê e usa, uma tela num aplicativo iOS, Android ou website? Fazer essa pergunta irá te ajudar a definir o que deve ser testado no nível de teste de aceitação.
Testes de aceitação tem características mais robustas e em geral levam mais tempo para ser executados. Prefira nesse caso testar apenas as funcionalidades mais importantes que impediria os usuários de usar. Por exemplo.: uma tela de área administrativa, se não funcionar corretamente não inviabiliza o uso dos usuários comuns e pode ser evitada no nível de testes de aceitação.
Monitoramento
No mundo ideial, uma aplicação bem testada não apresentaria erros em tempo de execução. Porém, todo software tem ao menos um bug.
O monitoramento de aplicações é imprescindível levando em consideração que bugs em produção levarão a incidentes, que impactam a experiência do usuário. Seja por uma informação errada ou uma queda de desempenho, impactos negativos na experiência de usuário podem trazer insatisfação. Isso claramente irá refletir na reputação em lojas de aplicativos, por exemplo.
Com um bom monitoramento, é possível entender em tempo real o comportamento das aplicações, diminuir o tempo para identificação de problemas ou até mesmo detectá-los de maneira precoce, promover a melhoria contínua da qualidade, reduzir o tempo total de indisponibilidade e ainda auxiliar na tomada de decisões de negócios com o feedback rápido que o monitoramento permite.
Acontece que, monitorar corretamente um software não é uma tarefa simples. A visibilidade é limitada em diversos casos: aplicações modulares de backend e aplicativos embarcados dificultam a análise em tempo real dada a descentralização das ocorrências de erros.
Para implementar um bom monitoramento em aplicações sempre tenha em mente três pontos de atenção:
Defina objetivos e métricas. Um bom monitoramento tem propósito, seja técnico ou de negócios. A primeira etapa é definir o propósito a fim de entender quais métricas são necessárias. Monitorar métricas apenas por monitorar gera desperdício de tempo de desenvolvimento e manutenção, e não trará benefício prático algum.
Configure a infraestrutura de monitoramento: Definir quais ferramentas usar parece fácil mas tem algumas complicações. Curva de aprendizado e homologação em grandes corporações podem levar ao fracasso na criação do ambiente de monitoramente. Tenha em mente que o monitoramento faz parte do negócio, mas pode trazer complexidade caso as escolhas não sejam boas. Na dúvida faça o simples. No mercado há ferramentas e plataformas como Splunk, Kibana e Sentry que fazem o papel inclusive de agregação de métricas, algo necessário para sistemas de larga escala.
Analise e crie alertas: Monitorar por monitorar não é eficaz. O custo de manipular logs não agregados ou aguardar uma reclamação de um cliente para tomar uma ação é perigoso. Crie visões das métricas elencadas na primeira etapa e alertas para que a detecção de problemas seja precoce.
Logs e Tratamento de Exceções
É incrível como algo como testes e logs de aplicação sejam tão triviais para engenheiros de software e ao mesmo tempo seja negligenciado pela maior parte deles.
Da mesma forma como os testes, tenha em mente que a definição da estratégia de monitoramento faz parte da funcionalidade sendo desenvolvida. Em tempo de definição técnica de uma demanda é importante definir o que será monitorado e quais alertas precisam ser definidos.
Outro ponto importante e que muitas vezes por pressa ou não é deixado de lado, é o tratamento correto de exceções. Dica: utilize os cenários de testes definidos para guiar como escrever cada exceção em log.
Em resumo, nunca se esqueça:
Utilize uma ferramenta de gestão de logs
Configure alertas em canais de fácil acesso para todos do time
Crie visões para agregação de logs
Conclusão
A Entrega Contínua é muito mais do que apenas uma metodologia de desenvolvimento de software; é uma cultura que revoluciona a maneira como entregamos valor aos nossos clientes e como gerenciamos nossos projetos. Este artigo explorou os princípios e práticas essenciais da Entrega Contínua, desde a Integração Contínua até o monitoramento e tratamento de exceções.
A principal lição que podemos tirar é que a Entrega Contínua não é apenas sobre entregar mais rápido, mas também sobre entregar com qualidade e confiabilidade. Ela nos ensina a quebrar grandes demandas em pequenos lotes, automatizar tarefas repetitivas e garantir a qualidade do nosso software por meio de testes abrangentes.
Além disso, a Entrega Contínua nos lembra da importância do monitoramento, do tratamento adequado de exceções e da criação de alertas relevantes. Isso não apenas nos ajuda a identificar problemas precocemente, mas também a melhorar constantemente nossos processos e produtos.
Em resumo, a Entrega Contínua é uma abordagem holística para o desenvolvimento de software que nos permite entregar valor de forma rápida, confiável e com qualidade. Ao adotar seus princípios e práticas, as equipes de desenvolvimento podem enfrentar os desafios do mercado de tecnologia em constante evolução e fornecer soluções que atendam às demandas dos clientes de forma eficaz. Portanto, não apenas acelere a entrega de software, adote a Entrega Contínua e eleve a qualidade e a eficiência de seus projetos de desenvolvimento.
Preaqueça o forno a 180°C (temperatura média). Unte uma assadeira retangular pequena com manteiga e polvilhe cacau em pó.
Passe a farinha e o fermento em pó pela peneira para uma tigela. Reserve.
Escolha uma tigela de vidro (ou de inox) que encaixe sobre uma panela para fazer um banho-maria. Pique o chocolate meio amargo. Transfira para a tigela e junte a manteiga.
Coloque dois dedos de água na panela e leve ao fogo alto. Quando ferver, abaixe o fogo e encaixe a tigela com o chocolate e a manteiga sobre a panela. O segredo é não deixar a água encostar no fundo da tigela e tomar cuidado para que o encaixe dos recipientes seja perfeito, evitando o vazamento do vapor. Quando o chocolate começar a derreter, misture bem com a manteiga. Assim que a mistura ficar lisa, retire do banho-maria.
Numa batedeira, junte o açúcar e os ovos. Bata em velocidade alta por cerca de 3 minutos ou até que a mistura fique esbranquiçada. Desligue a batedeira e, aos poucos, misture com uma espátula o chocolate derretido. (Como o chocolate ainda estará quente, se colocado de uma vez, poderá cozinhar os ovos.)
Na tigela com a massa de chocolate, adicione aos poucos a mistura de farinha com fermento e as nozes, mexendo delicadamente. Transfira a massa para a assadeira untada.
Leve ao forno preaquecido para assar por cerca de 20 minutos (assim que a casquinha começar a trincar nas laterias estará pronto). A massa ainda deve estar úmida quando sair do forno (com a aparência de um bolo ligeiramente cru). Deixe esfriar e sirva com creme batido ou sorvete de creme. (Se assar demais, vira bolo, e não brownie.)
Se quiser servir o brownie quente, deixe esfriar e desenforme. Em seguida, leve ao forno preaquecido a 160ºC (temperatura média) por 5 minutos.
Dicas:
A noz pecan pode ser substituída por nozes, castanhas ou até amendoin.
