Gerenciamento de projeto - Unidade II

Prévia do material em texto

<p>60</p><p>Unidade II</p><p>Unidade II</p><p>3 PLANEJAMENTO, EXECUÇÃO E GESTÃO ÁGIL</p><p>No contexto do desenvolvimento de software e gerenciamento de projetos, o planejamento, a</p><p>execução e a gestão ágil se destacam como abordagens essenciais para garantir a entrega de valor</p><p>contínuo e adaptativo às necessidades do cliente.</p><p>A priorização de backlog e a elaboração de roadmaps ágeis são etapas cruciais neste processo,</p><p>pois permitem que a equipe de desenvolvimento se concentre nas funcionalidades e melhorias que</p><p>trazem maior benefício ao produto final. A definição de um backlog claro e bem priorizado é fundamental</p><p>para direcionar os esforços de uma equipe, assegurando que os itens de maior valor sejam trabalhados</p><p>primeiro, conforme a visão estratégica e os feedbacks recebidos dos usuários.</p><p>Considerando tal aspecto, é preciso termos claro que os ciclos de desenvolvimento iterativos,</p><p>conhecidos como sprints, são a espinha dorsal das metodologias ágeis. Durante cada sprint, que</p><p>geralmente dura de uma a quatro semanas, a equipe se dedica a um conjunto específico de tarefas</p><p>do backlog, com o objetivo de entregar incrementos funcionais do produto. A execução desses ciclos</p><p>iterativos permite ajustes rápidos e respostas ágeis às mudanças, facilitando a incorporação de novas</p><p>demandas e a correção de problemas identificados ao longo do desenvolvimento.</p><p>As reuniões diárias, ou Daily Stand-ups, também desempenham um papel vital na sincronização</p><p>da equipe durante os sprints. Essas reuniões rápidas e focadas permitem que cada membro da equipe</p><p>compartilhe o progresso realizado, identifique obstáculos e alinhe as atividades do dia. A comunicação</p><p>contínua e transparente promovida pelos Daily Stand-ups é essencial para manter a coesão da equipe e</p><p>garantir que todos estejam cientes do andamento do projeto e das prioridades em constante mudança.</p><p>A gestão de backlogs e iterações é um processo contínuo que exige atenção constante e adaptação.</p><p>O  backlog do produto, que lista todas as funcionalidades desejadas, melhorias e correções, é</p><p>frequentemente revisitado e reavaliado à medida que novos insights e feedbacks são obtidos. O papel</p><p>do Product Owner é crucial nesta fase, pois cabe a ele tomar decisões informadas sobre quais itens</p><p>priorizar, com base na estratégia do negócio e nas necessidades dos stakeholders.</p><p>Ao final de cada sprint, é realizada uma revisão detalhada para avaliar o trabalho concluído, discutir</p><p>o que funcionou bem e identificar áreas de melhoria. Essa retrospectiva é uma oportunidade valiosa</p><p>para a equipe refletir sobre o desempenho do sprint e planejar ajustes para os próximos ciclos, visando</p><p>aumentar a eficiência e a qualidade das entregas futuras.</p><p>61</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Assim, a integração harmoniosa das práticas de priorização de backlog, ciclos de desenvolvimento</p><p>iterativos, Daily Stand-ups e gestão contínua de backlogs e iterações constitui o núcleo da gestão ágil.</p><p>Essa abordagem promove um ambiente de trabalho dinâmico, adaptável e centrado no cliente, em que</p><p>o foco constante na entrega de valor e na melhoria contínua assegura que o produto final atenda às</p><p>expectativas e necessidades do mercado de modo eficiente e eficaz.</p><p>3.1 Priorização de backlog e roadmaps ágeis</p><p>No contexto dos métodos ágeis, os conceitos de backlog e roadmap são fundamentais para a</p><p>organização e planejamento do desenvolvimento de um produto. O backlog, frequentemente referido</p><p>como backlog do produto, é uma lista ordenada de tudo o que é necessário para um produto. Ele</p><p>contém todas as funcionalidades, melhorias, correções de bugs, requisitos técnicos e qualquer outro</p><p>trabalho que precisa ser realizado pela equipe de desenvolvimento.</p><p>Este backlog é dinâmico e está em constante evolução, conforme novas necessidades surgem e</p><p>prioridades mudam. Cada elemento no backlog é conhecido como um item de backlog e pode variar</p><p>em tamanho e complexidade, desde pequenas correções até grandes funcionalidades. Exemplos de item</p><p>de backlog são “Adicionar funcionalidade de pagamento via PayPal” ou “Corrigir bug na tela de login”.</p><p>A responsabilidade pela gestão do backlog geralmente recai sobre o Product Owner, que deve</p><p>garantir que os itens estejam bem definidos e priorizados conforme o valor de negócio e a urgência.</p><p>A priorização é feita de maneira que os itens de maior valor e impacto sejam trabalhados primeiro.</p><p>A lista é constantemente revisada e ajustada com base no feedback dos usuários, nas mudanças de</p><p>mercado e nas novas descobertas técnicas.</p><p>Essa priorização envolve ordenar e selecionar os itens de trabalho que devem ser abordados pela</p><p>equipe de desenvolvimento. O Product Owner utiliza critérios como valor de negócio, feedback de</p><p>usuários, urgência e viabilidade técnica para decidir quais itens devem ser priorizados. Por exemplo, se</p><p>um produto de e-commerce está prestes a lançar uma grande campanha de marketing, a integração</p><p>de um novo sistema de pagamento pode ser priorizada para coincidir com a campanha, maximizando,</p><p>assim, o impacto positivo no número de transações.</p><p>Um método comum utilizado na priorização de backlog é a matriz de Eisenhower, que classifica as</p><p>tarefas com base em sua urgência e importância. Outra técnica amplamente usada é o WSJF (Weighted</p><p>Shortest Job First), que considera o custo do atraso e o tamanho do trabalho para determinar a ordem</p><p>de implementação dos itens. Um exemplo prático do WSJF pode ser visto em uma equipe que precisa</p><p>decidir entre implementar uma nova funcionalidade de busca ou corrigir um bug crítico que afeta a</p><p>experiência do usuário. O cálculo do WSJF ajuda a determinar qual tarefa tem o maior impacto relativo</p><p>e deve ser abordada primeiro.</p><p>62</p><p>Unidade II</p><p>A figura a seguir mostra esses dois métodos diferentes de priorização de backlog em ação.</p><p>Prioridade por WSJF</p><p>Atualização de segurança</p><p>Adicionar filtro de produtos</p><p>Implementar pagamento via PayPal</p><p>Corrigir bug na tela de login</p><p>Melhorar a velocidade do site</p><p>Redesign da página inicial</p><p>0.0 2.5 5.0 7.5 10.0</p><p>WSJF</p><p>Matriz de Eisenhower</p><p>Im</p><p>po</p><p>rt</p><p>ân</p><p>ci</p><p>a</p><p>10</p><p>9</p><p>8</p><p>7</p><p>6</p><p>5</p><p>4</p><p>4 6 8</p><p>Urgência</p><p>Implementar pagamento via PayPal</p><p>Corrigir bug na tela de login</p><p>Melhorar a velocidade do site</p><p>Adicionar filtro de produtos</p><p>Redesign da página inicial</p><p>Atualização de segurança</p><p>Figura 9 – Exemplo de priorização de backlog: matriz de Eisenhower e WSJF</p><p>A matriz de Eisenhower, à esquerda da figura apresentada anteriormente, organiza as tarefas com</p><p>base em dois critérios: urgência e importância. As tarefas são plotadas em um gráfico, onde o eixo</p><p>horizontal representa a urgência e o eixo vertical representa a importância. A linha divisória em 5 para</p><p>ambos os eixos cria quatro quadrantes, conforme descrito a seguir.</p><p>•	 Tarefas urgentes e importantes (prioridade alta): devem ser feitas imediatamente. Inclui</p><p>“Corrigir bug na tela de login” e “Implementar pagamento via PayPal”, indicando alta prioridade e</p><p>necessidade de ação imediata.</p><p>•	 Tarefas não urgentes e importantes (planejamento): devem ser planejadas e agendadas, como</p><p>“Redesign da página inicial”.</p><p>•	 Tarefas urgentes e não importantes (delegação): devem ser delegadas, se possível.</p><p>•	 Tarefas não urgentes e não importantes (baixa prioridade): devem ser eliminadas ou adiadas.</p><p>Inclui “Atualização de segurança”.</p><p>À direita da figura apresentada, observamos um gráfico que mostra a priorização pelo método WSJF.</p><p>Nele, as tarefas são avaliadas com base em três critérios: valor ao usuário, criticidade do tempo e redução</p><p>de risco, e são divididas pelo tamanho do trabalho (job size). Assim, temos que a fórmula do WSJF é:</p><p>WSJF =</p><p>Valor do usuário + Criticidade do tempo + Redução de risco</p><p>Tamanho do trabalho</p><p>63</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>As tarefas são ordenadas de acordo com o valor WSJF resultante. No exemplo, “Redesign da página</p><p>inicial” tem o maior valor WSJF, indicando que deve ser priorizada primeiro, seguida por “Melhorar</p><p>a velocidade do site” e “Corrigir bug na tela de login”. Essa priorização ajuda a garantir que</p><p>CI/CD, que é uma série de etapas automatizadas que o código</p><p>percorre desde a integração até a entrega. O pipeline em geral inclui a compilação do código, execução de</p><p>testes automatizados e, eventualmente, a implantação em ambientes de produção. O pipeline garante que</p><p>cada alteração no código seja validada e testada consistentemente, minimizando erros e aumentando a</p><p>confiabilidade do processo.</p><p>Um pipeline geralmente começa com a CI, na qual as mudanças no código-fonte são automaticamente</p><p>detectadas e uma série de etapas é desencadeada para verificar a qualidade e a integridade do código.</p><p>Essas etapas típicas podem incluir a construção do código, a execução de testes automatizados, a</p><p>análise de código estático e a geração de artefatos de construção. Cada uma dessas etapas é projetada</p><p>para identificar e corrigir problemas o mais cedo possível no ciclo de desenvolvimento, garantindo que</p><p>apenas um código de alta qualidade avance para as fases subsequentes.</p><p>Após a CI, o pipeline pode incluir etapas de CD, em que o software é preparado para implantação em</p><p>ambientes de teste, homologação e produção. Essas etapas podem envolver a implantação do software</p><p>em um ambiente de teste para verificações adicionais, a execução de testes de aceitação do usuário (UAT)</p><p>e a aprovação das partes interessadas antes da implantação final em produção. A automação dessas</p><p>etapas garante que o software esteja sempre em um estado implantável, facilitando lançamentos</p><p>frequentes e confiáveis. Em um pipeline de CI/CD típico, as etapas principais podem incluir diversas</p><p>atividades, como indicadas na figura 15.</p><p>87</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Quando um desenvolvedor faz um commit de código em</p><p>um repositório, o pipeline é acionado automaticamente.</p><p>Ferramentas como Jenkins, GitLab CI ou CircleCI monitoram</p><p>o repositório em busca de mudanças</p><p>Commit e</p><p>detecção de</p><p>mudanças</p><p>O código-fonte é compilado em um formato executável.</p><p>Dependendo da linguagem de programação e do projeto,</p><p>isso pode envolver ferramentas de construção como Maven,</p><p>Gradle ou Make</p><p>Construção</p><p>Uma série de testes automatizados são executados para</p><p>garantir que o novo código não quebre funcionalidades</p><p>existentes. Isso pode incluir testes unitários, testes de</p><p>integração e testes de sistema</p><p>Testes</p><p>automatizados</p><p>Ferramentas de análise estática de código, como SonarQube,</p><p>podem ser usadas para verificar a qualidade do código,</p><p>buscando por padrões de código ruim, vulnerabilidades de</p><p>segurança e aderência a padrões de codificação</p><p>Análise de</p><p>qualidade</p><p>de código</p><p>O código construído e testado é empacotado em artefatos</p><p>que podem ser distribuídos, como arquivos JAR, WAR ou</p><p>contêineres Docker</p><p>Empacotamento</p><p>e criação</p><p>de artefatos</p><p>Os artefatos são implantados em ambientes de teste para</p><p>verificações adicionais. Isso pode envolver a configuração de</p><p>ambientes de teste semelhantes ao ambiente de produção</p><p>Implantação</p><p>em</p><p>ambientes</p><p>de teste</p><p>Testes de aceitação do usuário (UAT) e outros testes finais</p><p>são realizados para garantir que o software atende aos</p><p>requisitos especificados</p><p>Testes de</p><p>aceitação</p><p>Após a aprovação final, o software é implantado no ambiente</p><p>de produção. Isso pode ser feito de forma automática ou</p><p>manual, dependendo das políticas da organizaçãoImplantação</p><p>em produção</p><p>Figura 15 – Um pipeline de CI/CD típico</p><p>Cada uma das etapas no pipeline é configurada para ser executada automaticamente, reduzindo a</p><p>necessidade de intervenção manual e minimizando o risco de erros humanos. Sua automação permite um</p><p>ciclo de desenvolvimento mais rápido e eficiente, facilitando a entrega contínua de valor aos usuários finais.</p><p>Além disso, os pipelines podem ser altamente personalizados para atender às necessidades</p><p>específicas de diferentes projetos e equipes. As ferramentas de CI/CD, como Jenkins, permitem que</p><p>os desenvolvedores definam pipelines complexos com várias ramificações, paralelização de tarefas</p><p>e condições específicas que determinam o fluxo de execução. Isso proporciona uma flexibilidade</p><p>significativa no modo como os pipelines são configurados e executados.</p><p>Dentre as principais etapas, temos o processo de compilação, conhecido como build, que verifica</p><p>se o novo código pode ser integrado com o existente sem erros. Após a compilação, um conjunto de</p><p>testes automatizados é executado. Eles podem incluir testes unitários, que verificam partes individuais</p><p>88</p><p>Unidade II</p><p>do código, testes de integração, que conferem se diferentes partes do sistema funcionam bem juntas e</p><p>testes funcionais, que verificam se o software atende aos requisitos especificados. A execução frequente</p><p>deles ajuda a identificar rapidamente erros introduzidos por novas alterações. Se os testes falharem ou se</p><p>ocorrer algum problema durante a compilação, a equipe de desenvolvimento é notificada imediatamente.</p><p>A notificação imediata, por sua vez, permite que os desenvolvedores corrijam os problemas enquanto</p><p>ainda estão frescos em suas mentes, o que é muito mais eficiente do que tentar resolver problemas que</p><p>surgiram há semanas ou meses. A CI, portanto, contribui significativamente para a estabilidade e a</p><p>qualidade do software.</p><p>Além disso, ela facilita a integração de novas funcionalidades de modo contínuo e ágil, permitindo</p><p>que a equipe entregue versões do software mais rapidamente e com maior confiança. Desse modo, a</p><p>CI se torna um pilar no desenvolvimento ágil de software, promovendo um ciclo de feedback rápido</p><p>e contínuo que melhora tanto o produto final quanto o processo de desenvolvimento.</p><p>Considerando tal contexto, é importante destacarmos a inteligência artificial (IA), que está sendo</p><p>cada vez mais empregada na CI para aprimorar e automatizar diversas etapas do ciclo de desenvolvimento</p><p>de software, resultando em processos mais eficientes, confiáveis e escaláveis. A integração da IA com CI</p><p>oferece, portanto, uma série de benefícios que vão desde a otimização da construção e testes de código</p><p>até a previsão de falhas e a recomendação de melhorias.</p><p>Uma das principais aplicações da IA na CI é a automação e otimização dos testes de software. A IA</p><p>pode ser utilizada para analisar o histórico de testes e identificar padrões que indicam quais partes do</p><p>código são mais propensas a falhas. Com base nessas análises, algoritmos de aprendizado de máquina</p><p>podem priorizar os testes mais críticos e focar nas áreas que apresentam maior risco, reduzindo o</p><p>tempo necessário para executar a suíte completa de testes e melhorando a detecção de bugs. Além</p><p>disso, a IA pode ajudar a criar testes mais eficazes, gerando casos de teste automáticos com base no</p><p>comportamento observado do software.</p><p>Outra área em que a IA tem um impacto significativo é na análise e revisão de código estático.</p><p>Ferramentas de CI habilitadas com IA podem escanear o código em busca de vulnerabilidades de</p><p>segurança, padrões de código inadequados e outros problemas de qualidade. Essas ferramentas podem</p><p>aprender com as revisões de código anteriores, para fornecer sugestões mais precisas e contextualmente</p><p>relevantes, ajudando os desenvolvedores a melhorar a qualidade do código de maneira contínua.</p><p>A previsão de falhas e a detecção proativa de problemas também são aprimoradas com o uso da IA</p><p>na CI. Algoritmos de aprendizado de máquina podem ser treinados para prever falhas futuras com base</p><p>em dados históricos de construção e desempenho. Isso permite que as equipes de desenvolvimento</p><p>identifiquem e resolvam problemas potenciais antes que eles afetem a produção. A análise preditiva</p><p>pode fornecer insights sobre a estabilidade do código, ajudando a equipe a tomar decisões informadas</p><p>sobre quando é seguro lançar novas versões.</p><p>89</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>A IA também pode otimizar a gestão de recursos e a escalabilidade do ambiente de CI. Por exemplo,</p><p>algoritmos de IA podem ajustar dinamicamente os recursos de computação necessários para construir</p><p>e testar o software com base na carga atual e nas previsões de demanda. Isso não apenas melhora a</p><p>eficiência, mas também reduz custos, alocando recursos de maneira mais inteligente e evitando</p><p>o desperdício.</p><p>Além disso, ela pode facilitar a análise de logs e a monitoração contínua. Ferramentas habilitadas por</p><p>IA podem analisar grandes volumes de dados de logs em tempo real, detectando anomalias e padrões</p><p>que poderiam passar despercebidos para os humanos. Isso acelera a identificação de problemas e permite</p><p>uma resposta mais rápida e precisa, melhorando a confiabilidade do sistema.</p><p>A CD é uma prática no desenvolvimento de software ágil que busca garantir que o código possa</p><p>ser lançado para produção de maneira rápida, segura e contínua. Em termos simples, é sobre tornar o</p><p>processo de disponibilizar novas funcionalidades e correções aos usuários o mais automático e livre de</p><p>erros possível.</p><p>No desenvolvimento de software tradicional, as novas versões são lançadas em intervalos longos,</p><p>como meses ou até anos. Esse método pode levar a grandes lançamentos que contêm muitas mudanças,</p><p>tornando difícil identificar a causa de qualquer problema que possa surgir. Além disso, se algo der</p><p>errado, pode ser complicado reverter as mudanças.</p><p>A CD, por outro lado, adota uma abordagem diferente. Nela, as alterações no código são feitas em</p><p>pequenas partes e integradas ao sistema de modo contínuo. Isso significa que novas funcionalidades,</p><p>melhorias e correções de bugs são lançadas regularmente, comumente várias vezes ao dia. A principal</p><p>vantagem dessa abordagem é que, ao fazer mudanças pequenas e frequentes, os desenvolvedores</p><p>podem identificar e corrigir problemas mais rapidamente, antes que se tornem grandes e complexos.</p><p>Assim como a CI, o processo de CD geralmente envolve várias etapas automatizadas.</p><p>Primeiro, quando um desenvolvedor finaliza uma alteração no código, ele a envia para um repositório</p><p>central. Em seguida, esse código é automaticamente testado por um conjunto de testes automatizados,</p><p>que verificam se a nova alteração funciona corretamente e não quebra nada no sistema existente. Se os</p><p>testes forem aprovados, o próximo passo é a construção do software, momento em todas as partes do</p><p>código são compiladas e integradas.</p><p>Uma vez que o software é construído com sucesso e todos os testes são aprovados, ele está pronto</p><p>para ser lançado em um ambiente de produção, no qual os usuários finais podem acessá-lo. Com a CD,</p><p>esse processo de lançamento é automatizado, reduzindo significativamente o risco de erros humanos e</p><p>garantindo que o novo código chegue aos usuários rapidamente.</p><p>Um dos principais benefícios da CD é a capacidade de fornecer feedback rápido. Assim, quando uma</p><p>nova versão do software for lançada, os desenvolvedores poderão monitorar seu desempenho e coletar</p><p>feedback dos usuários. Isso permite que eles façam ajustes e melhorias de modo ágil, respondendo</p><p>rapidamente às necessidades e problemas dos usuários.</p><p>90</p><p>Unidade II</p><p>Além disso, a CD melhora a colaboração dentro da equipe de desenvolvimento. Como o código é</p><p>integrado e testado constantemente, todos os membros da equipe têm uma visão clara do estado atual</p><p>do projeto e podem trabalhar juntos de maneira mais eficaz.</p><p>Lembrete</p><p>A integração contínua (CI) e a entrega contínua (CD) são conceitos</p><p>relacionados, mas distintos, no desenvolvimento de software ágil.</p><p>Desse modo, é importante analisarmos com mais detalhes a CD para evitarmos qualquer confusão.</p><p>A CD é uma prática no desenvolvimento de software que visa garantir que o código esteja sempre</p><p>em um estado, pronto para ser implantado em produção. Isso significa que o software pode ser lançado</p><p>a qualquer momento com um esforço mínimo.</p><p>Assim, a principal diferença entre CI e CD é que a primeira foca em integrar e testar o código</p><p>continuamente, enquanto a segunda vai além, assegurando que o código integrado e testado possa ser</p><p>rápida e automaticamente implantado em produção.</p><p>No processo de CD, após o código ser integrado e testado (etapas da CI), ele passa por uma série de</p><p>etapas adicionais para garantir que esteja realmente pronto para a implantação. Estas etapas incluem</p><p>testes mais extensivos, como testes de aceitação, de desempenho e de segurança, além de revisões e</p><p>verificações finais.</p><p>Uma vez que o código passa por todas essas verificações e é aprovado, ele é automaticamente</p><p>preparado para implantação. A automação é fundamental nesse processo, pois permite que a equipe de</p><p>desenvolvimento implemente novas versões do software de forma rápida e com confiança, minimizando</p><p>o risco de erro humano.</p><p>Para ilustrarmos tais aspectos, imaginemos uma equipe de desenvolvimento que está criando uma</p><p>aplicação web. Com DC, qualquer alteração no código, como uma nova funcionalidade ou uma correção</p><p>de bug, é automaticamente testada e integrada ao sistema. Em seguida, essa versão atualizada do software</p><p>passa por uma série de testes automatizados que garantem que está funcionando corretamente e que</p><p>está pronta para ser usada pelos usuários finais. Se todos os testes forem aprovados, a nova versão pode</p><p>ser implantada em produção com um simples clique ou até mesmo de modo totalmente automático.</p><p>Um dos maiores benefícios da DC é a capacidade de lançar novas funcionalidades e correções de</p><p>maneira rápida e frequente. Isso permite que as empresas respondam rapidamente às necessidades dos</p><p>clientes, lancem novas funcionalidades com maior rapidez e corrijam problemas de maneira mais ágil.</p><p>Além disso, como cada mudança é pequena e frequentemente implantada, é mais fácil identificar e</p><p>corrigir qualquer problema que possa surgir.</p><p>91</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Além da melhoria na velocidade e na qualidade das entregas, a CD também promove uma cultura de</p><p>colaboração e responsabilidade compartilhada dentro das equipes de desenvolvimento. Todos na equipe</p><p>estão cientes do estado atual do projeto e trabalham juntos para garantir que o software esteja sempre</p><p>em um estado pronto para implantação.</p><p>Sumarizando os conceitos, a CD é uma prática que estende os princípios da CI para incluir a</p><p>automação e a preparação para a implantação em produção. Ao garantir que o software esteja sempre</p><p>pronto para ser lançado, a CD melhora significativamente a agilidade, a qualidade e a confiabilidade do</p><p>desenvolvimento de software, permitindo uma resposta rápida às mudanças e uma entrega contínua de</p><p>valor aos usuários finais.</p><p>4.3 Testes automatizados e TDD (Test Driven Development)</p><p>Testes automatizados são programas que verificam se outras partes do software estão funcionando</p><p>como esperado. Em vez de um desenvolvedor manualmente testar cada funcionalidade, os testes</p><p>automatizados fazem isso automaticamente. Eles são executados rapidamente e podem ser repetidos</p><p>quantas vezes forem necessárias, o que é muito útil quando o código é modificado. A automação dos</p><p>testes garante que o software continue funcionando como esperado, mesmo após múltiplas alterações</p><p>e atualizações.</p><p>Eles são vitais para garantir a qualidade e a robustez do software, durante seu desenvolvimento e</p><p>manutenção, e permitem que os desenvolvedores verifiquem automaticamente se o código funciona</p><p>conforme o esperado, sem a necessidade de realizar testes manuais repetitivos. Existem várias categorias</p><p>de testes automatizados, cada uma focada em diferentes aspectos do software.</p><p>Primeiramente, os testes unitários verificam partes individuais do código, como funções ou</p><p>métodos, de modo isolado. O objetivo é garantir que cada unidade de código funcione corretamente</p><p>por si só. Por exemplo, se uma função deve somar dois números, um teste unitário verificará se essa</p><p>função retorna o resultado correto para diferentes combinações de números. Esses testes são rápidos de</p><p>executar e ajudam a detectar erros de maneira precoce.</p><p>Além dos testes unitários, os testes de integração verificam se diferentes partes do sistema</p><p>funcionam bem juntas. Por exemplo, se uma aplicação web tem uma função que depende de outra</p><p>função para obter dados de um banco de dados, um teste de integração verificará se ela ocorre sem</p><p>dificuldades. Isso é crucial para identificar problemas que podem surgir quando diferentes módulos do</p><p>sistema interagem.</p><p>Testes de sistema ou testes end-to-end verificam o software como um todo, simulando  o</p><p>comportamento do usuário para garantir que todas as funcionalidades estejam funcionando</p><p>conforme o esperado. Por exemplo, em um site de comércio eletrônico, um teste automatizado pode</p><p>simular o processo de um usuário navegando pelos produtos, adicionando itens ao carrinho, fazendo</p><p>o checkout e concluindo uma compra. Esses testes são mais complexos e demorados de executar, mas</p><p>fornecem uma garantia abrangente de que o sistema completo funciona corretamente.</p><p>92</p><p>Unidade II</p><p>Além dos testes unitários, de integração e de sistema, temos os testes de regressão, que são parte</p><p>crucial do processo de testes automatizados. Eles verificam se novas alterações ou adições ao código</p><p>não introduziram novos erros em partes do sistema que antes funcionavam corretamente. O objetivo</p><p>desses testes é garantir que funcionalidades existentes continuem operando como esperado após a</p><p>implementação de novas funcionalidades ou correções. A regressão pode ocorrer devido a interações</p><p>imprevistas entre o novo código e o código existente, o que pode resultar em falhas inesperadas.</p><p>Os testes de regressão são especialmente importantes em projetos em que o código é frequentemente</p><p>alterado e atualizado, como é comum no desenvolvimento ágil. Eles são geralmente automatizados para</p><p>garantir que possam ser executados rapidamente e de modo eficiente a cada nova alteração no código.</p><p>Por exemplo, sempre que um desenvolvedor faz uma alteração no código, o conjunto de testes de</p><p>regressão é executado para verificar se nada foi inadvertidamente quebrado.</p><p>Existem várias ferramentas populares que auxiliam na criação e execução de testes automatizados.</p><p>Por exemplo, o JUnit é amplamente utilizado para testes unitários em Java, e o PyTest é uma escolha</p><p>comum para testes em Python. Para testes de integração e de sistema, o Selenium é uma ferramenta</p><p>popular que permite a automação de navegadores web, facilitando a simulação de interações do usuário</p><p>neste tipo de aplicação. Outra ferramenta é o Jenkins, que, embora seja conhecida principalmente como</p><p>um servidor de CI, também pode orquestrar a execução de testes automatizados, integrando-se com</p><p>outras ferramentas de teste.</p><p>Um exemplo prático de testes automatizados pode ser ilustrado com uma aplicação web de vendas.</p><p>Imaginemos que uma equipe de desenvolvimento implementa uma nova funcionalidade que permite</p><p>ao usuário aplicar cupons de desconto no checkout. Para garantir que essa aplicabilidade funcione</p><p>corretamente, eles escrevem testes unitários para verificar se o cálculo do desconto está correto. Em</p><p>seguida, criam testes de integração para garantir que a aplicação do desconto funcione corretamente</p><p>em conjunto com o cálculo de impostos e a geração de faturas.</p><p>Assim, testes end-to-end são escritos para simular um usuário aplicando um cupom de desconto e</p><p>completando uma compra, verificando se o desconto é refletido corretamente no preço final. Além disso,</p><p>testes de regressão são executados para assegurar que a nova funcionalidade não causou problemas</p><p>em outras partes do sistema, como a navegação de produtos, o cálculo de frete e o processamento</p><p>de pagamentos, garantindo que todas as funcionalidades existentes continuem operando, conforme</p><p>esperado após a implementação da nova funcionalidade.</p><p>A automação desses testes significa que toda vez que uma mudança é feita no código, todos</p><p>eles serão executados automaticamente para garantir que nada foi quebrado. Isso proporciona uma</p><p>confiança significativa de que o software funciona conforme esperado, mesmo após múltiplas alterações</p><p>e atualizações. Em resumo, os testes automatizados são uma prática essencial no desenvolvimento de</p><p>software moderno, proporcionando eficiência, confiabilidade e qualidade contínua.</p><p>93</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Saiba mais</p><p>A seguir, indicaremos um livro que oferece uma visão abrangente sobre</p><p>testes ágeis, abordando diversas práticas e técnicas de testes automatizados,</p><p>além de fornecer insights sobre a colaboração entre testadores e</p><p>desenvolvedores.</p><p>CRISPIN, L.; GREGORY, J. Agile testing: a practical guide for testers and</p><p>agile teams. Londres: Addison-Wesley Professional, 2009.</p><p>O papel da QA é fundamental no contexto dos testes automatizados, pois ele garante que o software</p><p>atenda aos padrões de qualidade desejados e funcione conforme especificado. A QA envolve uma série</p><p>de atividades que vão além da simples execução de testes. Inclui planejamento, design, execução e</p><p>análise de testes, bem como a implementação de processos de melhoria contínua.</p><p>No desenvolvimento de software ágil, a integração da QA com testes automatizados começa no início</p><p>do ciclo de desenvolvimento. A equipe de QA trabalha em estreita colaboração com os desenvolvedores</p><p>e outras partes interessadas para definir os requisitos de qualidade e os critérios de aceitação para</p><p>novas funcionalidades. Essa colaboração inicial ajuda a garantir que todos compreendam os objetivos</p><p>de qualidade e que os testes sejam projetados para verificar esses critérios desde o início.</p><p>Os engenheiros de QA são responsáveis por criar e manter os testes automatizados. Eles escrevem</p><p>scripts de teste que cobrem uma variedade de cenários, incluindo testes unitários, de integração,</p><p>de sistema e de regressão. Por exemplo, em uma aplicação web de vendas, um engenheiro de QA pode</p><p>escrever testes unitários para verificar se o cálculo do desconto funciona corretamente, testes de</p><p>integração para garantir que a aplicação do desconto interaja corretamente com o cálculo de impostos</p><p>e a geração de faturas, e testes end-to-end para simular um usuário aplicando um cupom de desconto e</p><p>completando uma compra.</p><p>Os testes de regressão também são uma parte importante do trabalho da QA. À medida que novas</p><p>funcionalidades são adicionadas e o código existente é modificado, os engenheiros de QA executam</p><p>testes de regressão automatizados para garantir que nenhuma funcionalidade antiga tenha sido</p><p>comprometida. Isso é crucial para manter a estabilidade e a confiabilidade do software ao longo do tempo.</p><p>Além de escrever e executar testes, os engenheiros de QA analisam os resultados dos testes para</p><p>identificar defeitos e áreas de melhoria. Eles trabalham com os desenvolvedores para resolver os</p><p>problemas encontrados e reexecutam os testes para verificar as correções. Esse ciclo contínuo de testes</p><p>e correções ajuda a detectar e corrigir problemas rapidamente, melhorando a qualidade do software de</p><p>modo incremental.</p><p>94</p><p>Unidade II</p><p>O desenvolvimento orientado por testes (TDD), por sua vez, é uma abordagem específica de</p><p>desenvolvimento de software que prioriza a criação de testes antes mesmo do código, que implementa</p><p>a funcionalidade, ser escrito. O processo de TDD segue três etapas principais, frequentemente chamadas</p><p>de vermelho-verde-refatorar.</p><p>Primeiro, o desenvolvedor escreve um teste automatizado para uma nova funcionalidade que deseja</p><p>implementar. Este teste inicialmente falha, porque a funcionalidade ainda não foi desenvolvida. Assim,</p><p>temos o estágio vermelho, indicando que o código ainda não está completo. Em seguida, o desenvolvedor</p><p>escreve o código mínimo necessário para fazer o teste passar, ou seja, para que a funcionalidade seja</p><p>implementada e o teste tenha sucesso. Este é o estágio verde, em que o teste agora passa e indica que</p><p>a funcionalidade básica está correta. Por fim, o desenvolvedor refatora o código, que é o processo de</p><p>melhorar sua estrutura e eficiência sem alterar seu comportamento. O objetivo aqui é garantir que o</p><p>código seja limpo, eficiente e fácil de manter. Após a refatoração, todos os testes automatizados devem</p><p>continuar passando, garantindo que as melhorias não introduziram novos problemas.</p><p>Refatorar envolve aprimorar a estrutura interna do código sem alterar seu comportamento externo</p><p>e</p><p>no contexto do TDD, essa é uma etapa crítica. Inicialmente, o desenvolvedor escreve o código para</p><p>passar nos testes, mas depois melhora-o para seguir boas práticas de programação. Por exemplo, um</p><p>desenvolvedor pode renomear variáveis para serem mais descritivas, facilitando a compreensão do código.</p><p>Para entender como o TDD pode ser aplicado, vamos considerar como exemplo o desenvolvimento de</p><p>um aplicativo para delivery de comidas. Focaremos em uma funcionalidade específica: calcular o valor</p><p>total de um pedido após aplicar um cupom de desconto.</p><p>No TDD, nosso processo começa escrevendo um teste automatizado antes mesmo de escrever o</p><p>código da funcionalidade. Então, primeiramente, o desenvolvedor escreve um teste para a funcionalidade</p><p>que deseja implementar. Este teste define o comportamento esperado do código. Em C#, usando NUnit</p><p>para testes, ele pode ser:</p><p>using NUnit.Framework;</p><p>[TestFixture]</p><p>public class PedidoTests</p><p>{</p><p>[Test]</p><p>public void</p><p>CalcularValorComDesconto_DeveRetornarValorCorreto()</p><p>{</p><p>// Arrange</p><p>decimal precoOriginal = 50m;</p><p>decimal porcentagemDesconto = 10m; //</p><p>10% de desconto esperado</p><p>decimal valorEsperado = 45m; // 50 – (50 * 0.10)</p><p>Pedido pedido = new Pedido(precoOriginal);</p><p>95</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>// Act</p><p>decimal valorComDesconto =</p><p>pedido.CalcularValorComDesconto(porcentagemDesconto);</p><p>// Assert</p><p>Assert.AreEqual(valorEsperado, valorComDesconto);</p><p>}</p><p>}</p><p>Este teste inicialmente falha, porque a funcionalidade CalcularValorComDesconto ainda não</p><p>foi implementada. Assim, temos o estágio vermelho. Em seguida, o desenvolvedor escreve o código</p><p>mínimo necessário para fazer o teste passar. Com isso, implementamos a classe Pedido com a</p><p>funcionalidade desejada:</p><p>public class Pedido</p><p>{</p><p>private decimal precoOriginal;</p><p>public Pedido(decimal precoOriginal)</p><p>{</p><p>this.precoOriginal = precoOriginal;</p><p>}</p><p>public decimal CalcularValorComDesconto</p><p>(decimal porcentagemDesconto)</p><p>{</p><p>return precoOriginal – (precoOriginal</p><p>* porcentagemDesconto / 100);</p><p>}</p><p>}</p><p>Agora, ao executar o teste novamente, ele deve passar, indicando que a funcionalidade básica está</p><p>correta. Este é o estágio verde. Com isso, o próximo passo é refatorar o código para melhorar sua</p><p>qualidade e eficiência, sem alterar seu comportamento. Desse modo, devemos garantir que o código</p><p>seja claro e fácil de manter:</p><p>public class Pedido</p><p>{</p><p>private decimal precoOriginal;</p><p>public Pedido(decimal precoOriginal)</p><p>{</p><p>this.precoOriginal = precoOriginal;</p><p>}</p><p>96</p><p>Unidade II</p><p>public decimal CalcularValorComDesconto</p><p>(decimal porcentagemDesconto)</p><p>{</p><p>decimal desconto =</p><p>CalcularDesconto(porcentagemDesconto);</p><p>return precoOriginal – desconto;</p><p>}</p><p>private decimal CalcularDesconto(decimal</p><p>porcentagemDesconto)</p><p>{</p><p>return precoOriginal * (porcentagemDesconto /</p><p>100);</p><p>}</p><p>}</p><p>Após a refatoração, o desenvolvedor executa todos os testes novamente para garantir que ainda</p><p>passam. Se todos os testes estiverem bem, a refatoração foi bem-sucedida.</p><p>Outra prática comum na refatoração é a remoção de duplicação de código, melhorando a reutilização</p><p>e reduzindo erros. Identificarmos blocos de código repetidos e movê-los para uma função reutilizável é</p><p>uma maneira eficaz de alcançar isso. A aplicação de padrões de design também é uma parte importante</p><p>da refatoração. Por exemplo, usarmos objetos e classes para encapsular comportamentos relacionados</p><p>pode tornar o código mais orientado a objetos e fácil de expandir.</p><p>Buscarmos pela melhoria da eficiência do código é outra área na qual a refatoração pode ser aplicada.</p><p>Se o código original possui um loop ineficiente, o desenvolvedor pode reescrevê-lo para usar algoritmos</p><p>mais eficientes, reduzindo o tempo de execução e o consumo de recursos.</p><p>Saiba mais</p><p>Em seus estudos, Beck nos explica os princípios do TDD com exemplos</p><p>práticos, mostrando como escrever testes antes do código e como refatorar</p><p>continuamente para melhorar a qualidade de um software. Desse modo,</p><p>consulte o livro a seguir.</p><p>BECK, K. Test Driven Development: by example. Londres: Addison-Wesley</p><p>Professional, 2021.</p><p>97</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>A prática de TDD, portanto, oferece vários benefícios. Como os testes são escritos primeiro, os</p><p>desenvolvedores têm uma compreensão clara dos requisitos antes de começarem a escrever o código.</p><p>Isso ajuda a evitar mal-entendidos e garante que o software atenda exatamente às necessidades</p><p>especificadas. Além disso, como os testes são executados automaticamente, os desenvolvedores</p><p>recebem feedbacks imediatos sobre qualquer problema introduzido durante o desenvolvimento. Isso</p><p>permite identificar e corrigir problemas mais cedo, reduzindo o custo e o esforço necessários para</p><p>resolvê-los mais tarde.</p><p>Em resumo, testes automatizados e TDD são práticas que ajudam a garantir a qualidade e a</p><p>confiabilidade do software. Os testes automatizados verificam automaticamente se um software</p><p>funciona corretamente, enquanto o TDD orienta o desenvolvimento do código a partir dos testes,</p><p>garantindo que cada funcionalidade seja implementada de modo preciso e eficiente. Essas práticas não</p><p>só melhoram a qualidade do software, elas também tornam o processo de desenvolvimento mais ágil</p><p>e colaborativo.</p><p>4.4 Deployment e monitoramento em ambientes ágeis</p><p>A implantação ou deployment é uma fase crucial que envolve a entrega do software desenvolvido</p><p>para um ambiente de produção, no qual ele pode ser utilizado pelos usuários finais. Em ambientes</p><p>ágeis, essa prática é caracterizada pela sua frequência e automatização, visando garantir que novas</p><p>funcionalidades e melhorias sejam disponibilizadas de maneira contínua e rápida.</p><p>Um ambiente, no contexto de desenvolvimento de software, refere-se a um conjunto específico de</p><p>condições e configurações em que o software é executado. Esses ambientes são criados para suportar</p><p>diferentes fases do ciclo de vida do desenvolvimento de softwares, permitindo que as equipes trabalhem</p><p>de maneira eficiente e segura. Existem vários tipos de ambientes que desempenham papéis distintos,</p><p>cada um com seu propósito e características.</p><p>O ambiente de desenvolvimento, por exemplo, é o lugar no qual os programadores escrevem e</p><p>testam o novo código. Esse ambiente é configurado para permitir experimentação e iteração rápida,</p><p>fornecendo as ferramentas e recursos necessários para os desenvolvedores criarem e modificarem o</p><p>software. Frequentemente, inclui um ambiente integrado de desenvolvimento (IDE), sistemas de controle</p><p>de versão e ferramentas de depuração. No ambiente de desenvolvimento, os programadores podem</p><p>introduzir mudanças, corrigir erros e testar novas funcionalidades sem afetar outros ambientes.</p><p>O ambiente de teste, por outro lado, é o lugar no qual o software é submetido a uma série de testes</p><p>rigorosos para garantir que ele funcione conforme o esperado antes de ser implantado no ambiente de</p><p>produção. Existem diferentes tipos de testes que podem ser realizados nesse ambiente, incluindo testes</p><p>unitários, de integração, de sistema e de aceitação. O ambiente de teste é projetado para simular o</p><p>ambiente de produção o mais fielmente possível, mas em uma configuração controlada, para detectar</p><p>e corrigir problemas antes que o software alcance os usuários finais.</p><p>98</p><p>Unidade II</p><p>O ambiente de homologação, também conhecido como ambiente de pré-produção ou staging,</p><p>é um estágio intermediário entre o ambiente de teste e o de produção. Nele, o software é testado em</p><p>condições que se assemelham ainda mais ao ambiente de produção, permitindo uma última verificação</p><p>antes da implantação definitiva. O objetivo do ambiente de homologação é garantir que tudo esteja</p><p>funcionando perfeitamente e que não haja surpresas ao mover o software para o ambiente de produção.</p><p>Por fim, o ambiente de produção é o lugar no qual o software é executado e utilizado</p><p>pelos usuários</p><p>finais. É o mais crítico, no qual a confiabilidade, segurança e o desempenho são de extrema importância.</p><p>Alterações nesse ambiente devem ser feitas com cautela e, muitas vezes, são implementadas através de</p><p>processos automatizados de CD para minimizar riscos e garantir a estabilidade.</p><p>Em suma, o ambiente de produção é o palco final no qual o software desempenha seu papel essencial</p><p>para os usuários finais, sendo fundamental para a operação bem-sucedida de muitos sistemas e serviços</p><p>modernos. Diferentemente de outros ambientes como o de desenvolvimento ou o de teste, no ambiente</p><p>de produção o software é executado em sua capacidade plena.</p><p>Os ambientes de produção devem ser cuidadosamente gerenciados para garantir a segurança,</p><p>a disponibilidade e o desempenho do software. Isso inclui a configuração adequada dos servidores, a gestão</p><p>de bancos de dados, a monitorização contínua do desempenho, a aplicação de patches de segurança</p><p>e a realização de backups regulares para prevenir a perda de dados. A confiabilidade do ambiente de</p><p>produção é essencial, pois qualquer indisponibilidade ou problema pode resultar em perda de receita,</p><p>danos à reputação e insatisfação dos clientes.</p><p>Considerando tais contextos, temos a automação, que é um pilar do deployment em ambientes</p><p>ágeis. Ferramentas de CI e CD são amplamente utilizadas para automatizar o processo de build, teste</p><p>e implantação de software. A CI assegura que o código escrito por diferentes membros da equipe seja</p><p>regularmente integrado em um repositório central e automaticamente testado para detectar defeitos</p><p>rapidamente. Isso reduz o risco de conflitos e falhas na integração de novas funcionalidades.</p><p>Como destacamos anteriormente, a CD vai um passo além, automatizando a entrega do software</p><p>para um ambiente de produção ou pré-produção. Sempre que um novo pedaço de código passa por</p><p>todos os testes automatizados, ele é automaticamente preparado para ser implantado, garantindo que</p><p>o software esteja sempre em um estado que possa ser entregue aos usuários finais. Isso permite uma</p><p>resposta rápida às necessidades dos usuários e correções de bugs, proporcionando um ciclo de feedback</p><p>contínuo e eficiente.</p><p>Além disso, a automação do deployment reduz significativamente o tempo e o esforço necessários</p><p>para entregar novas funcionalidades e corrigir problemas. Em vez de esperar semanas ou meses para</p><p>lançar atualizações, as equipes ágeis podem fazer deploys diários, ou até várias vezes ao dia, dependendo</p><p>das necessidades do projeto e da organização. Essa agilidade permite que as equipes de desenvolvimento</p><p>se adaptem rapidamente às mudanças nos requisitos do cliente e às condições de mercado, mantendo</p><p>a competitividade e a relevância do software.</p><p>99</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Observação</p><p>O fazer deploys diários refere-se à prática de implantar novas versões</p><p>ou atualizações de um software em produção todos os dias. Essa prática</p><p>é uma característica comum em ambientes de desenvolvimento ágil e é</p><p>facilitada pela cultura DevOps e pelas ferramentas de automação.</p><p>No desenvolvimento tradicional, as atualizações de software podem ser</p><p>lançadas em ciclos longos, como mensais ou trimestrais. Isso pode levar</p><p>a grandes lançamentos que incorporam muitas mudanças, o que pode</p><p>aumentar o risco de introduzir bugs ou falhas. Em contraste, fazer deploys</p><p>diários implica lançar atualizações menores e mais frequentes.</p><p>Além da automação, a colaboração entre as equipes de desenvolvimento e operações é fundamental</p><p>para o sucesso do deployment em ambientes ágeis. A cultura DevOps, que integra desenvolvedores e</p><p>operadores, promove uma comunicação aberta e colaboração contínua, assegurando que as necessidades</p><p>de infraestrutura e operacionais sejam consideradas desde o início do ciclo de desenvolvimento. Isso</p><p>resulta em um processo de deployment mais robusto e menos propenso a erros.</p><p>A cultura DevOps é uma abordagem que integra as práticas e ferramentas de desenvolvimento de</p><p>software (Dev) com as operações de tecnologia da informação (Ops), promovendo uma colaboração</p><p>mais estreita entre as duas áreas. Essa cultura surgiu como uma resposta às limitações dos modelos</p><p>tradicionais de desenvolvimento e operações, que frequentemente funcionavam em silos separados,</p><p>resultando em processos de desenvolvimento lentos e ineficientes, além de falta de comunicação</p><p>e colaboração.</p><p>Em um ambiente tradicional, os desenvolvedores escrevem o código e entregam-no às equipes</p><p>de operações, que são responsáveis por implantar e gerenciar o software em ambientes de produção.</p><p>Esse modelo pode levar a uma série de problemas, incluindo atrasos na implantação, dificuldades na</p><p>resolução de problemas e falta de responsabilidade compartilhada. A cultura DevOps visa eliminar essas</p><p>barreiras, incentivando uma abordagem mais integrada e colaborativa.</p><p>Além da automação, a cultura DevOps enfatiza a comunicação e colaboração contínuas entre as</p><p>equipes de desenvolvimento e operações. Isso é frequentemente alcançado através de práticas como</p><p>reuniões diárias, uso de ferramentas de colaboração e compartilhamento de responsabilidades. A ideia é</p><p>que ambas as equipes trabalhem juntas desde o início do ciclo de desenvolvimento até a implantação,</p><p>além de compartilhar objetivos e responsabilidades comuns.</p><p>Outra característica importante da cultura DevOps é a monitorização contínua e o feedback rápido.</p><p>Ao monitorar continuamente o desempenho do software em produção e coletar feedback dos usuários,</p><p>as equipes podem identificar e resolver problemas mais rapidamente, melhorando a qualidade e a</p><p>confiabilidade de um software.</p><p>100</p><p>Unidade II</p><p>A cultura DevOps também valoriza a implementação de infraestrutura como código (IaC), que</p><p>é uma prática na qual a configuração e o gerenciamento da infraestrutura são tratados de maneira</p><p>semelhante ao desenvolvimento de software, utilizando scripts e ferramentas de automação. Isso</p><p>permite que a infraestrutura seja facilmente replicável, escalável e gerenciada de modo consistente.</p><p>Portanto, o deployment em ambientes ágeis se caracteriza pela sua frequência, automatização e</p><p>colaboração entre equipes, permitindo que um software seja entregue de maneira rápida, contínua</p><p>e com alta qualidade. Essa abordagem maximiza a capacidade de resposta às mudanças e a satisfação</p><p>do cliente, elementos fundamentais no desenvolvimento de um software ágil.</p><p>Já o monitoramento desempenha um papel fundamental na garantia da qualidade e desempenho</p><p>contínuos do software em produção. Monitoramento refere-se ao processo de observar, registrar e</p><p>analisar o comportamento de um sistema ou aplicação em tempo real, com o objetivo de identificar</p><p>problemas, medir o desempenho e garantir que tudo esteja funcionando conforme o esperado.</p><p>Em ambientes ágeis, nos quais a entrega de software é frequente e iterativa, o monitoramento é</p><p>essencial para manter sua estabilidade e confiabilidade após cada atualização. A cultura ágil valoriza</p><p>a entrega contínua de valor aos usuários e a adaptação rápida às mudanças, o que significa que um</p><p>software está em constante evolução. Nesse cenário, o monitoramento ajuda a garantir que cada</p><p>nova versão dele não introduza novos problemas e que qualquer anomalia seja detectada e corrigida</p><p>rapidamente.</p><p>Uma parte crucial do monitoramento é a coleta de métricas de desempenho. Elas podem incluir</p><p>tempo de resposta das aplicações, uso de recursos como CPU e memória, taxas de erro, entre outras.</p><p>Ao monitorar essas métricas, as equipes de desenvolvimento podem entender como o software está</p><p>se comportando em diferentes condições e identificar gargalos ou problemas de desempenho que</p><p>possam impactar a experiência do usuário. Esse entendimento permite que as equipes façam ajustes e</p><p>otimizações contínuas, melhorando a eficiência de um software.</p><p>Outro aspecto importante do monitoramento em ambientes ágeis é a detecção e resolução rápida</p><p>de falhas. Quando um problema é detectado, as equipes de operações e desenvolvimento</p><p>podem</p><p>agir rapidamente para diagnosticar e resolver a causa raiz. Ferramentas de monitoramento muitas</p><p>vezes incluem alertas automatizados que notificam as equipes sobre problemas críticos, permitindo</p><p>uma resposta imediata. Isso é particularmente importante em ambientes de produção, nos quais a</p><p>indisponibilidade do software pode ter impactos significativos nos negócios e nos usuários finais.</p><p>O monitoramento também fornece feedbacks valiosos para o processo de desenvolvimento. Em</p><p>um ambiente ágil as equipes estão constantemente iterando e lançando novas versões do software e o</p><p>feedback rápido é crucial para a melhoria contínua. As informações coletadas através do monitoramento</p><p>ajudam as equipes a entender o impacto das mudanças recentes, permitindo que ajustem suas estratégias</p><p>de desenvolvimento e priorizem correções e melhorias com base em dados reais.</p><p>101</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Além disso, o monitoramento em ambientes ágeis facilita uma abordagem proativa à gestão de</p><p>software. Em vez de esperar que os usuários relatem problemas, as equipes podem antecipar e resolver</p><p>questões antes que elas afetem os usuários finais. Isso contribui para uma experiência de usuário mais</p><p>estável e confiável, aumentando a satisfação do cliente e a confiança no software.</p><p>O monitoramento em ambientes ágeis é um componente essencial que sustenta a CD e iterativa de</p><p>softwares de alta qualidade. Ele permite que as equipes detectem e resolvam problemas rapidamente,</p><p>compreendam o desempenho do software em tempo real e façam ajustes contínuos com base em</p><p>feedbacks concretos. Essa abordagem assegura que um software evolua de modo estável e eficiente,</p><p>alinhando-se aos princípios ágeis de flexibilidade, adaptação e foco na satisfação do cliente.</p><p>102</p><p>Unidade II</p><p>Resumo</p><p>Nesta unidade, abordamos a importância do planejamento, execução e</p><p>gestão ágil no contexto do desenvolvimento de software e gerenciamento</p><p>de projetos. Compreendemos que a gestão ágil se destaca por garantir</p><p>a entrega contínua de valor e adaptação às necessidades do cliente,</p><p>priorizando backlog e elaborando roadmaps ágeis. Além disso, trabalhamos</p><p>com a definição e priorização de um backlog bem estruturado, que é crucial</p><p>para direcionar os esforços de uma equipe de desenvolvimento, garantindo</p><p>que as funcionalidades de maior valor sejam trabalhadas primeiro, alinhadas</p><p>com a visão estratégica e os feedbacks dos usuários.</p><p>Discutimos sobre os ciclos de desenvolvimento iterativos, conhecidos</p><p>como sprints, que são essenciais nas metodologias ágeis. Cada sprint dura</p><p>de uma a quatro semanas, durante as quais uma equipe se dedica a um</p><p>conjunto específico de tarefas do backlog, com o objetivo de entregar</p><p>incrementos funcionais do produto. Assim, vimos que as reuniões do</p><p>sprint no Scrum incluem o planejamento do sprint, a reunião diária (Daily</p><p>Stand-up), a revisão do sprint (Sprint Review) e a retrospectiva do sprint</p><p>(sprint retrospective). Cada um desses eventos é projetado para manter a</p><p>equipe alinhada, focada e continuamente melhorando.</p><p>Também abordamos a importância da qualidade e dos testes no</p><p>desenvolvimento de software, abordando tanto as metodologias</p><p>tradicionais do PMI quanto as abordagens ágeis. Entendemos que a CI</p><p>e a CD são práticas essenciais nesse contexto. A CI envolve a integração</p><p>frequente do código desenvolvido em um repositório compartilhado, com</p><p>verificações automáticas por meio de testes automatizados, permitindo a</p><p>detecção rápida de defeitos e redução dos riscos de integrações tardias.</p><p>A CD, por sua vez, automatiza não apenas a integração, mas também a</p><p>entrega de um software em ambientes de produção, garantindo que ele</p><p>esteja sempre em um estado pronto para ser liberado.</p><p>Entendemos, assim, que os testes automatizados desempenham um</p><p>papel crucial nessas práticas, assegurando que cada mudança no código seja</p><p>rigorosamente testada antes de ser integrada ou liberada. Apresentamos</p><p>o Test Driven Development (TDD), que é uma prática em que os testes são</p><p>escritos antes do código de produção, promovendo um design mais limpo</p><p>e modular e facilitando a manutenção do código.</p><p>103</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Por fim, compreendemos que as práticas de qualidade, testes e CD</p><p>são fundamentais no desenvolvimento de software usando frameworks</p><p>ágeis. Elas garantem que o software seja desenvolvido e entregue com alta</p><p>qualidade, respondendo rapidamente às necessidades do mercado e aos</p><p>feedbacks dos usuários. Além disso, que CI, a CD, os testes automatizados</p><p>e o monitoramento contínuo trabalham juntos para criar um ciclo de</p><p>desenvolvimento dinâmico e eficiente, no qual a qualidade é integrada</p><p>em cada etapa do processo, resultando em produtos mais robustos e</p><p>satisfatórios para os clientes.</p><p>104</p><p>Unidade II</p><p>Exercícios</p><p>Questão 1. (UFMT/2021, adaptada) Leia o texto a seguir.</p><p>Se você já leu ou fez algum curso de administração do tempo, provavelmente assimilou algumas</p><p>técnicas para administrar seus compromissos. No entanto, quando as coloca em prática, você descobre</p><p>que muito do seu tempo é dependente do tempo de outras pessoas. Afinal, vivemos no mundo do</p><p>conhecimento, onde o indivíduo não trabalha mais sozinho, e sim em grupo. Aí, você aprende a palavra</p><p>mágica chamada delegação. Mas será que aprender a delegar é suficiente no mundo de hoje? Mais: será</p><p>que todos estão em posição de delegar tarefas e responsabilidades?</p><p>BARBOSA, C. A tríade do tempo: um modelo comprovado para organizar sua vida e</p><p>aumentar sua produtividade e seu equilíbrio. São Paulo: Buzz Editora, 2018.</p><p>Para gerir o tempo, há uma ferramenta de gestão que é dividida em quatro quadrantes, nos quais as</p><p>tarefas podem ser classificadas em:</p><p>•	 urgentes e importantes;</p><p>•	 importantes, mas não urgentes;</p><p>•	 urgentes, mas não importantes;</p><p>•	 não urgentes nem importantes.</p><p>De qual ferramenta estamos falando?</p><p>A) Gráfico de Pareto.</p><p>B) Matriz de Eisenhower.</p><p>C) Fluxograma vertical.</p><p>D) Matriz BCG.</p><p>E) WSJF.</p><p>Resposta correta: alternativa B.</p><p>105</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Análise da questão</p><p>No contexto de metodologias ágeis, uma técnica muito usada na priorização das tarefas do backlog</p><p>é a matriz de Eisenhower, que classifica as tarefas com base em sua urgência e em sua importância.</p><p>As tarefas são plotadas em um plano cartesiano, onde o eixo horizontal representa a urgência e o eixo</p><p>vertical representa a importância.</p><p>As tarefas são organizadas em quatro quadrantes, classificados conforme exposto a seguir.</p><p>•	 Tarefas urgentes e importantes: devem ser feitas imediatamente.</p><p>•	 Tarefas não urgentes e importantes: devem ser planejadas e agendadas.</p><p>•	 Tarefas urgentes e não importantes: devem ser delegadas, se possível.</p><p>•	 Tarefas não urgentes e não importantes: devem ser eliminadas ou adiadas.</p><p>Questão 2. (Ibade/2022, adaptada) DevOps é uma prática de desenvolvimento de software que visa</p><p>integrar equipes de desenvolvimento (Dev) e de operações (Ops) em um ciclo contínuo de entrega e</p><p>de feedback rápido. Ao adotar uma cultura de DevOps, as equipes ganham a capacidade de responder</p><p>melhor às necessidades dos clientes.</p><p>Em um modelo DevOps, existe um método para entregar aplicações com frequência aos clientes,</p><p>visando integração, entrega e implantação contínuas. Chamamos esse método de:</p><p>A) Git.</p><p>B) Pipeline.</p><p>C) Flowchart.</p><p>D) Reentrante.</p><p>E) CI/CD.</p><p>Resposta correta: alternativa E.</p><p>Análise da questão</p><p>O método para entregar aplicações com frequência aos clientes, visando à integração, entrega e</p><p>implantação contínuas, é chamado de CI/CD (Continuous Integration/Continuous Deployment). Em</p><p>português, chamamos CI de integração contínua e CD de entrega contínua.</p><p>106</p><p>Unidade II</p><p>A ideia central da CI é garantir que o código escrito por diferentes desenvolvedores seja integrado</p><p>regularmente em um repositório central, permitindo a detecção precoce de problemas e facilitando</p><p>a colaboração entre a equipe. Já o CD é uma prática no desenvolvimento de software ágil que busca</p><p>garantir que o código possa</p><p>ser lançado para produção de maneira rápida, segura e contínua.</p><p>A principal diferença entre CI e CD é que a CI foca em integrar e testar o código continuamente,</p><p>enquanto a CD vai além, assegurando que o código integrado e testado possa ser rápida e automaticamente</p><p>implantado em produção.</p><p>a equipe</p><p>trabalhe nas tarefas que oferecem maior valor e impacto no menor tempo possível.</p><p>Gráficos como esse ilustram como diferentes metodologias podem ser aplicadas para determinar</p><p>a priorização das tarefas no backlog, ajudando as equipes a focarem nos itens que trarão mais valor e</p><p>impacto ao produto final.</p><p>O roadmap, por outro lado, é uma representação visual e estratégica do planejamento de longo</p><p>prazo do desenvolvimento do produto, como visualizamos na figura a seguir. Ele fornece uma visão de</p><p>alto nível dos principais objetivos e entregas planejadas ao longo do tempo. Enquanto o backlog é mais</p><p>detalhado e operacional, o roadmap é mais estratégico, ajudando a comunicar a direção e as metas do</p><p>produto para todas as partes interessadas.</p><p>Figura 10 – Perspectiva artística de um roadmap de produto. Imagem produzida pelo próprio autor com tecnologia DALL-E,</p><p>uma ferramenta de IA desenvolvida pela OpenAI</p><p>Um roadmap ágil não é rígido, ele é flexível e adaptável, permitindo que a equipe de desenvolvimento</p><p>ajuste o curso conforme necessário. Ele pode incluir diferentes horizontes temporais, como trimestral,</p><p>semestral ou anual, e destacará marcos importantes, como lançamentos de novas funcionalidades ou</p><p>integração com outras plataformas. Por exemplo, o roadmap de um aplicativo de saúde pode incluir</p><p>fases como “Integração com dispositivos de medição de pressão arterial” no primeiro trimestre,</p><p>“Monitoramento de atividade física” no segundo trimestre e “Funcionalidade de telemedicina” no</p><p>terceiro trimestre.</p><p>64</p><p>Unidade II</p><p>A principal diferença entre o backlog e o roadmap é o nível de detalhe e o propósito. O backlog é</p><p>detalhado, operacional e focado nas tarefas específicas que precisam ser executadas pela equipe de</p><p>desenvolvimento. Já o roadmap é mais abstrato, estratégico e focado em comunicar a direção e as</p><p>metas de longo prazo do produto. Ambos são essenciais para garantir que a equipe esteja alinhada com</p><p>os objetivos do negócio e possa responder rapidamente a mudanças e novas informações.</p><p>Integrando backlog e roadmap, as equipes ágeis conseguem planejar e executar o desenvolvimento</p><p>do produto de maneira eficiente e adaptativa. Enquanto o backlog garante que as tarefas prioritárias</p><p>sejam realizadas, o roadmap oferece uma visão clara e compartilhada do caminho a ser seguido,</p><p>facilitando o alinhamento das expectativas e a coordenação entre diferentes partes interessadas.</p><p>3.2 Ciclos de desenvolvimento iterativos: sprints</p><p>Os ciclos de desenvolvimento iterativos, conhecidos como sprints, são uma prática central nas</p><p>metodologias ágeis, especialmente no framework Scrum. Eles representam períodos fixos, geralmente</p><p>de uma a quatro semanas, durante os quais a equipe de desenvolvimento trabalha para completar</p><p>um conjunto específico de tarefas do backlog. Cada sprint é uma mini-iteração do projeto completo,</p><p>permitindo que o produto evolua de maneira incremental e adaptativa.</p><p>Saiba mais</p><p>No contexto das metodologias ágeis, o time boxing é uma técnica de</p><p>gerenciamento de tempo na qual uma atividade é limitada a um período</p><p>específico de tempo, chamado de time box. Dentro dessa janela de tempo, a</p><p>equipe se concentra exclusivamente na realização das tarefas atribuídas, sem</p><p>permitir que o escopo do trabalho se expanda além do que foi planejado.</p><p>No caso do sprint, a time box é geralmente de uma a quatro semanas.</p><p>Durante esse período, a equipe de desenvolvimento trabalha intensivamente</p><p>para completar um conjunto de itens do backlog, que foram selecionados</p><p>e priorizados na reunião de planejamento do sprint. A definição clara da</p><p>duração do sprint permite que a equipe tenha uma meta tangível e um</p><p>horizonte temporal concreto para medir seu progresso. Sobre a importância</p><p>do time boxing, e outros temas importantes sobre as metodologias ágeis,</p><p>sugerimos a leitura do livro a seguir.</p><p>COHN, M. Agile estimating and planning. Londres: Pearson, 2005.</p><p>A utilização do time boxing nos sprints traz diversos benefícios. Primeiramente, ajuda a criar um</p><p>ritmo sustentável de trabalho, evitando a sobrecarga e promovendo um ciclo contínuo de entrega de</p><p>valor. Além disso, a duração fixa do sprint facilita a previsão e o planejamento, permitindo que a equipe</p><p>e os stakeholders tenham uma compreensão clara do que pode ser realizado dentro de cada ciclo.</p><p>65</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Outro benefício significativo é a capacidade de adaptação rápida às mudanças. Ao final de cada sprint,</p><p>há uma oportunidade para revisar o trabalho realizado, coletar feedback e ajustar o plano conforme</p><p>necessário, antes de iniciar o próximo sprint. Isso promove uma abordagem iterativa e incremental, na qual</p><p>o produto evolui continuamente com base nas necessidades e prioridades em constante mudança. Além</p><p>disso, contrasta com os métodos tradicionais de desenvolvimento, em que o feedback só é incorporado no</p><p>final do ciclo de desenvolvimento, muitas vezes levando a ajustes mais demorados e dispendiosos.</p><p>Devido ao seu papel estruturado e repetitivo dentro do ciclo de desenvolvimento, as reuniões do sprint</p><p>no Scrum são frequentemente referidas como “rituais” ou “cerimônias”, que incluem o planejamento</p><p>do sprint (Sprint Planning), a reunião diária (Daily Stand-up), a revisão do sprint (Sprint Review) e</p><p>a retrospectiva do sprint (Sprint Retrospective). Cada um desses eventos é projetado para manter a</p><p>equipe alinhada, focada e continuamente melhorada, sendo esses elementos essenciais para a eficácia</p><p>do Scrum. Considerando tais elementos, analisemos as etapas do sprint em mais detalhes a seguir.</p><p>O ciclo de um sprint começa com a reunião de planejamento, na qual a equipe e o Product Owner</p><p>se reúnem para discutir e selecionar os itens do backlog que serão trabalhados durante o sprint. Esses</p><p>itens são escolhidos com base em sua prioridade e no valor que agregam ao produto. A equipe então</p><p>define uma meta clara para o sprint e cria um plano detalhado para atingir essa meta.</p><p>No entanto, algumas práticas comuns, conhecidas como Scrum Buts, podem comprometer a eficácia</p><p>dos sprints. Um exemplo de má prática é a equipe não conseguir completar as tarefas planejadas para</p><p>o sprint. Isso geralmente ocorre devido a uma má estimativa de esforço ou a interrupções constantes</p><p>durante o sprint. Quando a equipe frequentemente não cumpre as metas planejadas, torna-se necessário</p><p>ajustar o escopo dos próximos sprints com base no aprendizado obtido e melhorar a priorização</p><p>das tarefas.</p><p>Outra má prática é a expansão do escopo durante o sprint. Alterar o escopo do trabalho, adicionando</p><p>novas tarefas ou mudando prioridades, compromete a estabilidade e o foco da equipe. O escopo deve ser</p><p>congelado durante o sprint, permitindo que a equipe se concentre em completar o trabalho planejado.</p><p>Qualquer nova demanda ou mudança de prioridade deve ser revisada e incorporada na próxima reunião</p><p>de planejamento do sprint.</p><p>Observação</p><p>Scrum-But é um termo utilizado na metodologia ágil para descrever</p><p>uma situação em que uma equipe adota práticas do Scrum, mas faz</p><p>modificações ou omissões que comprometem a essência da metodologia.</p><p>A expressão Scrum But geralmente é seguida por uma descrição de como</p><p>a prática original do Scrum foi alterada, por exemplo, “fazemos Scrum,</p><p>mas...”. Essa abordagem pode levar a uma implementação ineficaz do Scrum</p><p>e, consequentemente, a resultados muito aquém do esperado.</p><p>66</p><p>Unidade II</p><p>A estrutura do Scrum But envolve três componentes principais: a prática original do Scrum, a</p><p>modificação ou omissão feita, e o impacto dessa mudança. Um exemplo típico poderia ser: “fazemos</p><p>Scrum, mas nossos sprints são flexíveis e podem ser estendidos se não completarmos o trabalho”.</p><p>Nesse caso, a prática original de ter sprints de duração fixa foi modificada, resultando na perda</p><p>de uma das principais vantagens do Scrum, que é a capacidade de prever e planejar ciclos de trabalho</p><p>curtos e iterativos.</p><p>Outro exemplo pode ser: “fazemos Scrum, mas nossas reuniões diárias geralmente duram 30 minutos</p><p>ou mais</p><p>porque discutimos detalhes técnicos extensivamente”. Porém, as Daily Stand-up são projetadas</p><p>para serem breves, geralmente não ultrapassando 15 minutos, para manter a equipe sincronizada sem</p><p>perder muito tempo.</p><p>Durante o sprint, a equipe realiza reuniões diárias, conhecidas como Daily Stand-ups, que são</p><p>breves encontros. Essas reuniões ajudam a manter todos sincronizados e permitem a identificação</p><p>rápida de problemas que podem ser resolvidos antes que se tornem obstáculos significativos.</p><p>As Daily Stand-ups são projetadas para serem rápidas e focadas, com duração máxima de</p><p>15 minutos. No entanto, uma má prática é permitir que essas reuniões se estendam por muito tempo,</p><p>transformando-se em discussões gerais. Isso não só desperdiça tempo, mas também pode reduzir o</p><p>engajamento da equipe. As reuniões diárias devem permanecer dentro do tempo estipulado e focar</p><p>apenas no progresso, nos obstáculos e nos planos para o próximo dia.</p><p>Ao final do sprint, a equipe realiza duas reuniões importantes: a revisão do sprint e a retrospectiva</p><p>do sprint. Na revisão do sprint, a equipe apresenta o trabalho concluído aos stakeholders e coleta</p><p>feedback sobre o incremento do produto desenvolvido. Esta é uma oportunidade valiosa para garantir</p><p>que o trabalho esteja alinhado com as expectativas e necessidades do cliente.</p><p>Uma prática prejudicial é realizar a revisão do sprint sem a presença dos principais stakeholders.</p><p>A revisão do sprint é uma oportunidade para a equipe apresentar o trabalho concluído e obter feedback</p><p>valioso. Sem a presença dos stakeholders, a revisão perde seu propósito principal e pode resultar em um</p><p>desalinhamento entre o que a equipe está entregando e as expectativas dos stakeholders. Portanto, é</p><p>crucial garantir que os principais stakeholders participem ativamente dessas reuniões.</p><p>Na retrospectiva do sprint, a equipe reflete sobre o processo do sprint, discutindo o que funcionou</p><p>bem, o que não funcionou e como podem melhorar nos próximos sprints. Este ciclo contínuo de avaliação</p><p>e melhoria é fundamental para o sucesso a longo prazo das equipes ágeis. Por isso, ignorar ou minimizar</p><p>a importância da retrospectiva do sprint é outra má prática.</p><p>A retrospectiva é fundamental para a melhoria contínua, permitindo que a equipe reflita sobre o</p><p>que funcionou bem e o que pode ser melhorado. Negligenciar essa reunião pode levar a uma repetição</p><p>de erros e a uma estagnação no desenvolvimento de práticas mais eficazes. A equipe deve levar a</p><p>retrospectiva a sério e implementar as ações de melhoria identificadas.</p><p>67</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>É preciso termos claro que os sprints promovem uma cultura de CD e de alta qualidade. Cada</p><p>incremento do produto deve ser funcional e potencialmente utilizável, o que incentiva a equipe a</p><p>manter altos padrões de qualidade em todas as etapas do desenvolvimento. Além disso, a abordagem</p><p>iterativa e incremental dos sprints ajuda a gerenciar o risco, pois permite que a equipe detecte e resolva</p><p>problemas rapidamente, minimizando o impacto no projeto como um todo.</p><p>3.3 Daily Stand-ups e sincronização de equipe</p><p>O principal objetivo das Daily Stand-ups é garantir que todos na equipe estejam cientes do que está</p><p>acontecendo e possam colaborar de maneira mais eficaz. Sua estrutura típica é simples e direta. Cada</p><p>membro da equipe responde a três perguntas fundamentais: o que fizeram desde a última reunião,</p><p>o que planejam fazer até a próxima reunião e se há algum impedimento que esteja dificultando o</p><p>progresso. Essa estrutura ajuda a manter a reunião focada e eficiente, geralmente limitando sua duração</p><p>a 15 minutos, independentemente do tamanho da equipe.</p><p>A prática de realizar essas reuniões em pé (daí o nome stand-up) visa reforçar a brevidade e a objetividade</p><p>das discussões. O quadro a seguir apresenta os participantes da reunião e seus respectivos papéis.</p><p>Quadro 3 – Participantes e papéis na daily</p><p>Equipe de Desenvolvimento Scrum Master Product Owner</p><p>Os membros da equipe de</p><p>desenvolvimento são os</p><p>principais participantes da</p><p>Daily Stand-up. Eles discutem</p><p>o progresso do trabalho,</p><p>identificam impedimentos e</p><p>ajustam suas atividades diárias</p><p>para garantir que as metas do</p><p>sprint sejam atingidas</p><p>O Scrum Master facilita a</p><p>reunião diária, garantindo</p><p>que ela permaneça dentro do</p><p>tempo estipulado (geralmente</p><p>15 minutos) e que a discussão</p><p>permaneça focada nos três</p><p>tópicos principais: o que foi</p><p>feito desde a última reunião,</p><p>o que será feito até a próxima</p><p>e quaisquer impedimentos</p><p>no caminho. O Scrum Master</p><p>também atua para remover os</p><p>impedimentos identificados</p><p>pelos membros da equipe</p><p>A participação do Product</p><p>Owner é opcional. Embora o</p><p>PO não precise participar da</p><p>Daily Stand-up diariamente,</p><p>sua presença ocasional</p><p>pode ser útil para fornecer</p><p>esclarecimentos rápidos sobre</p><p>as prioridades do backlog ou</p><p>mudanças nos requisitos. No</p><p>entanto, o foco da reunião</p><p>deve permanecer na equipe</p><p>de desenvolvimento e suas</p><p>atividades diárias</p><p>A sincronização de equipe promovida pelas Daily Stand-ups é vital para o sucesso das metodologias</p><p>ágeis. Ao compartilhar atualizações diárias, os membros da equipe podem identificar rapidamente</p><p>quaisquer desvios do plano original e ajustar suas ações conforme necessário. Por exemplo, se um</p><p>desenvolvedor encontra um problema técnico que pode atrasar a entrega de uma funcionalidade, ele</p><p>pode comunicar isso imediatamente, permitindo que a equipe tome medidas corretivas ou redistribua</p><p>tarefas para minimizar o impacto no sprint.</p><p>Além de melhorar a comunicação e a colaboração, as Daily Stand-ups ajudam a criar um ambiente</p><p>de transparência e responsabilidade. Cada membro da equipe tem a oportunidade de compartilhar seu</p><p>progresso e desafios, o que fomenta uma cultura de apoio mútuo e resolução conjunta de problemas.</p><p>Essa transparência é crucial para construir confiança dentro da equipe e assegurar que todos estejam</p><p>comprometidos com os objetivos do sprint.</p><p>68</p><p>Unidade II</p><p>Para entender melhor a criticidade da sincronização da equipe no processo ágil, consideremos, por</p><p>exemplo, que o termo Scrum utilizado na metodologia ágil deriva do scrum do jogo de rúgbi, que é a</p><p>formação de reinício do jogo, como mostra a figura a seguir, na qual os jogadores de ambas as equipes</p><p>se interligam e se empurram uns contra os outros para ganhar a posse da bola. Essa formação exige uma</p><p>intensa coordenação, comunicação e trabalho em equipe para ser bem-sucedida. Cada jogador tem um</p><p>papel específico e deve colaborar estreitamente com seus companheiros para avançar no campo de jogo.</p><p>Figura 11 – Scrum para reinício de uma partida de rúgbi. Imagem produzida pelo</p><p>próprio autor com tecnologia DALL-E, uma ferramenta de IA desenvolvida pela OpenAI</p><p>Analogamente, no desenvolvimento de software ágil, o framework Scrum enfatiza o trabalho</p><p>colaborativo e a auto-organização das equipes. Assim como no rúgbi, no qual o sucesso do scrum</p><p>depende da coordenação e do esforço coletivo, no Scrum ágil, o sucesso de um projeto depende da</p><p>capacidade da equipe de colaborar efetivamente, ajustar-se rapidamente às mudanças e focar em</p><p>entregas incrementais de valor.</p><p>As cerimônias e os papéis definidos no Scrum são projetados para promover a comunicação</p><p>contínua, a inspeção e a adaptação, elementos essenciais para enfrentar a complexidade e a incerteza</p><p>do desenvolvimento de software.</p><p>69</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>O termo Scrum foi popularizado, no contexto de desenvolvimento de produtos, por Hirotaka Takeuchi</p><p>e Ikujiro Nonaka no artigo “The new new product development game” (Takeuchi; Nonaka, 1986). Eles</p><p>usaram o termo para descrever uma abordagem de desenvolvimento de produto que enfatizava a</p><p>flexibilidade, a velocidade e a inovação, inspirada pelo jogo de rúgbi. Ken Schwaber e Jeff Sutherland, os</p><p>criadores do framework Scrum, adotaram esse conceito para nomear a metodologia que desenvolveram,</p><p>destacando a importância da colaboração e da equipe multifuncional.</p><p>Atualmente, várias ferramentas de software</p><p>são usadas para auxiliar na condução de Daily Stand-ups,</p><p>melhorando a comunicação, a visibilidade e a eficiência das reuniões. A seguir apresentaremos alguns</p><p>exemplos concretos, que iremos tratar com mais detalhes adiante.</p><p>•	 Jira: é uma das ferramentas mais populares para equipes ágeis. Ela oferece suporte completo</p><p>para Scrum, incluindo a gestão de backlog, sprints e tarefas. Para as Daily Stand-ups, fornece</p><p>quadros de tarefas (Kanban ou Scrum boards) que permitem que os membros da equipe visualizem</p><p>rapidamente o progresso, as tarefas pendentes e os impedimentos. A funcionalidade de relatórios</p><p>e gráficos, como o gráfico de burndown, ajuda a monitorar o progresso do sprint.</p><p>•	 Trello: é uma ferramenta de gestão de projetos baseada em Kanban que é simples e intuitiva. As</p><p>equipes podem criar cartões para cada tarefa e movê-los entre colunas que representam diferentes</p><p>estados do trabalho (por exemplo, “A Fazer”, “Em Progresso”, “Concluído”). Durante a Daily Stand-up,</p><p>a equipe pode rapidamente revisar e atualizar o status das tarefas diretamente no quadro.</p><p>•	 Microsoft teams: é uma ferramenta de colaboração que integra diversas funcionalidades úteis</p><p>para Daily Stand-ups, especialmente para equipes remotas. Além de permitir videoconferências</p><p>rápidas para a reunião diária, o Microsoft teams pode ser integrado com outras ferramentas como</p><p>Jira ou Trello para exibir o status das tarefas diretamente nas reuniões. As funcionalidades de chat</p><p>e canais ajudam a manter a comunicação contínua.</p><p>•	 Slack: é uma ferramenta de comunicação que facilita as Daily Stand-ups, especialmente para</p><p>equipes distribuídas. Utilizando bots como Standuply ou Geekbot, Slack automatiza a coleta de</p><p>atualizações diárias dos membros da equipe. Esses bots perguntam automaticamente aos membros</p><p>sobre o progresso, planos e impedimentos, e compilam as respostas em um canal específico,</p><p>permitindo que todos vejam as atualizações sem necessidade de uma reunião síncrona.</p><p>•	 Zoom: é uma plataforma de videoconferência amplamente utilizada para Daily Stand-ups,</p><p>especialmente em tempos de trabalho remoto. A funcionalidade de salas de reunião (breakout</p><p>rooms) permite que grandes equipes se dividam em grupos menores, se necessário, para discussões</p><p>mais focadas. A gravação de reuniões e a integração com outras ferramentas de gestão de projetos</p><p>tornaram o Zoom uma escolha popular.</p><p>•	 Miro: é uma ferramenta de quadro branco on-line e colaborativa, que é útil para Daily Stand-ups,</p><p>especialmente quando a equipe precisa de uma abordagem visual para discutir o progresso e</p><p>os impedimentos. Os quadros brancos de Miro podem ser usados para criar mapas mentais,</p><p>fluxogramas e quadros Kanban, facilitando a visualização e a atualização das tarefas em tempo real.</p><p>70</p><p>Unidade II</p><p>Uma vez que preparar uma reunião diária é um aspecto crucial da metodologia ágil, na figura a</p><p>seguir podemos verificar algumas orientações práticas para preparar uma reunião eficaz.</p><p>Defina um horário fixo para a Daily Stand-ups,</p><p>preferencialmente no início do dia de trabalho. Isso cria</p><p>uma rotina e garante que todos os membros da equipe</p><p>estejam disponíveis</p><p>Estabelecer um</p><p>horário fixo</p><p>Escolha um local específico para a reunião. Pode ser uma</p><p>sala de conferências ou um espaço aberto no escritório.</p><p>Em equipes remotas, utilize uma plataforma de</p><p>videoconferência confiável</p><p>Definir o local</p><p>Limite a reunião a 15 minutos. O objetivo é garantir</p><p>que a comunicação seja eficiente e que a equipe possa</p><p>rapidamente voltar ao trabalho</p><p>Manter a</p><p>reunião curta</p><p>e objetiva</p><p>Utilize um formato padrão no qual cada membro da equipe</p><p>responda a três perguntas: o que foi feito desde a última</p><p>reunião? O que será feito até a próxima reunião? Quais são</p><p>os impedimentos ou bloqueios que precisam ser resolvidos?</p><p>Seguir um</p><p>formato</p><p>estruturado</p><p>Todos os membros da equipe de desenvolvimento devem</p><p>participar e compartilhar suas atualizações. Isso inclui</p><p>desenvolvedores, testers, designers e qualquer outro membro</p><p>envolvido diretamente no trabalho diário</p><p>Envolver todos</p><p>os membros</p><p>da equipe</p><p>A Daily Meeting não é o momento para resolver problemas</p><p>detalhadamente, mas sim para identificar impedimentos.</p><p>Qualquer discussão aprofundada deve ser marcada para após</p><p>a reunião, com os envolvidos diretamente no problema</p><p>Focar em</p><p>progresso e</p><p>impedimentos</p><p>Utilize quadros Kanban, Scrum boards ou outras ferramentas</p><p>visuais para acompanhar o progresso. Isso ajuda a visualizar</p><p>o trabalho e a identificar rapidamente quaisquer desvios</p><p>ou bloqueios</p><p>Usar</p><p>ferramentas</p><p>de suporte</p><p>Incentive um ambiente em que todos se sintam confortáveis</p><p>para falar abertamente sobre seu progresso e desafios.</p><p>A comunicação transparente é fundamental para o sucesso</p><p>da Daily Meeting</p><p>Promover a</p><p>comunicação e</p><p>a colaboração</p><p>Esteja aberto a ajustar a estrutura da reunião conforme</p><p>necessário para atender melhor às necessidades da equipe.</p><p>Se algo não estiver funcionando, discuta durante a</p><p>retrospectiva e faça as alterações necessárias</p><p>Adaptar</p><p>conforme</p><p>necessário</p><p>Mantenha um registro dos impedimentos levantados</p><p>durante a reunião e acompanhe o status de sua resolução.</p><p>Isso ajuda a garantir que os problemas não sejam esquecidos</p><p>e que sejam resolvidos em tempo hábil</p><p>Registrar</p><p>impedimentos</p><p>Figura 12 – Orientações práticas para Daily Stand-ups eficazes</p><p>Ao seguirmos essas orientações, a Daily Meeting pode se tornar uma ferramenta poderosa para</p><p>manter a equipe alinhada, identificar e resolver impedimentos rapidamente e garantir que todos</p><p>estejam focados nos objetivos comuns. A chave é manter a reunião breve, estruturada e focada na</p><p>comunicação clara.</p><p>71</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Além disso, para que as Daily Stand-ups sejam eficazes, é importante evitarmos algumas armadilhas</p><p>comuns. Uma má prática, por exemplo, é permitir que as reuniões se estendam além do tempo</p><p>alocado, transformando-se em discussões detalhadas que desviam do foco principal. Para evitar isso,</p><p>qualquer discussão que precise de mais tempo deve ser agendada para depois da reunião, com os</p><p>membros relevantes.</p><p>Outra prática prejudicial é a falta de preparação por parte dos participantes, o que pode levar</p><p>a atualizações vagas e pouco úteis. É essencial que cada membro da equipe venha preparado para</p><p>fornecer informações claras e concisas. Os membros da equipe devem vir preparados para as Daily</p><p>Stand-ups por várias razões importantes.</p><p>Primeiro, a reunião é time-boxed em 15 minutos, exigindo que cada participante forneça atualizações</p><p>concisas e relevantes. A preparação garante que o tempo seja usado eficientemente e que todos os</p><p>pontos importantes sejam cobertos sem desvios desnecessários.</p><p>Segundo, a preparação ajuda a identificar e articular claramente quaisquer impedimentos que</p><p>estejam bloqueando o progresso. Quando os membros da equipe chegam preparados, eles podem</p><p>rapidamente destacar os problemas que precisam ser resolvidos, permitindo que o Scrum Master tome</p><p>as ações necessárias para removê-los.</p><p>Terceiro, a preparação promove a responsabilidade e o compromisso com as tarefas atribuídas. Cada</p><p>membro da equipe deve estar ciente de suas responsabilidades e do progresso esperado, o que ajuda a</p><p>manter todos alinhados com os objetivos do sprint.</p><p>Finalmente, a preparação para a Daily Stand-up facilita a comunicação e a colaboração eficazes.</p><p>Quando todos os membros estão bem informados sobre o estado atual do projeto e suas próprias tarefas,</p><p>eles podem colaborar de maneira mais eficiente, ajudando a equipe a superar desafios rapidamente e a</p><p>manter o ritmo de desenvolvimento.</p><p>3.4 Gestão de backlogs e iterações</p><p>Um backlog é uma lista organizada e priorizada de tarefas, requisitos, melhorias e funcionalidades que</p><p>precisam ser desenvolvidas em um projeto de software. No contexto do desenvolvimento ágil, o backlog</p><p>é um instrumento essencial para gerenciar o trabalho a ser realizado pela equipe de desenvolvimento.</p><p>Ele serve como um repositório centralizado de tudo o que pode ser necessário</p><p>no produto, permitindo</p><p>uma visão clara e estruturada das prioridades e dos itens que devem ser abordados ao longo do ciclo</p><p>de vida do projeto. Existem diferentes tipos de backlog, dependendo do nível de detalhe e do foco</p><p>específico. Os dois principais tipos são: o Product Backlog e o Sprint Backlog.</p><p>O Product Backlog é uma lista abrangente que contém todas as tarefas e requisitos conhecidos para</p><p>um produto. Ele é gerenciado pelo Product Owner, que é responsável por priorizar os itens com base no</p><p>valor de negócio, nas necessidades do cliente e na estratégia do produto. O Product Backlog é dinâmico,</p><p>sendo atualizado continuamente à medida que novas informações surgem. Além disso, os requisitos são</p><p>adicionados, modificados ou removidos.</p><p>72</p><p>Unidade II</p><p>Por outro lado, o Sprint Backlog é uma lista mais específica que contém os itens selecionados do</p><p>Product Backlog para serem trabalhados durante uma iteração ou sprint. Esse backlog é gerenciado</p><p>pela equipe de desenvolvimento e detalha as tarefas necessárias para completar tais itens. Durante a</p><p>reunião de planejamento do sprint, a equipe decide quais itens do Product Backlog serão movidos para o</p><p>Sprint Backlog, considerando a capacidade da equipe e as prioridades estabelecidas.</p><p>A boa gestão do backlog envolve a definição clara e detalhada dos itens, garantindo que cada um</p><p>seja compreensível e estimável pela equipe de desenvolvimento. Cada item do backlog, frequentemente</p><p>chamado de user story, ou história do usuário, deve descrever uma funcionalidade ou requisito, buscando</p><p>destacar o valor para o usuário final. A técnica de user story é uma prática vital no desenvolvimento ágil</p><p>de software, utilizada para capturar requisitos de maneira simples e centrada no usuário.</p><p>Uma user story é uma descrição curta e informal, de uma funcionalidade do sistema, escrita do</p><p>ponto de vista do usuário final. O objetivo é facilitar a comunicação entre os membros da equipe de</p><p>desenvolvimento e os stakeholders, assegurando que todos compreendam claramente as necessidades</p><p>do usuário. Uma user story típica segue um formato simples e estruturado da seguinte maneira:</p><p>Como [tipo de usuário], eu quero [ação ou funcionalidade], para que [benefício ou valor].</p><p>Esse formato ajuda a esclarecer quem é o usuário, o que ele deseja fazer e qual é o benefício</p><p>esperado. Por exemplo, uma user story poderia ser: “como um comprador on-line, eu quero poder</p><p>salvar itens no meu carrinho de compras, para que eu possa continuar comprando mais tarde sem</p><p>perder minha seleção”.</p><p>As user stories têm várias características importantes. Elas são escritas em linguagem simples,</p><p>evitando jargões técnicos, para garantir que todos os envolvidos no projeto, independentemente de seu</p><p>background ou conhecimento técnico, possam compreendê-las.</p><p>As histórias são centradas nas necessidades e objetivos dos usuários finais, garantindo que o</p><p>desenvolvimento seja guiado pela perspectiva de quem utilizará o sistema. Além disso, user stories</p><p>promovem a comunicação e a colaboração entre desenvolvedores, Product Owners, stakeholders e</p><p>usuários, servindo como base para discussões sobre requisitos e funcionalidades.</p><p>Cada história representa uma pequena parte do sistema, permitindo que o desenvolvimento seja</p><p>realizado de maneira incremental e iterativa, facilitando o feedback contínuo e ajustes rápidos conforme</p><p>necessário. É essencial que cada user story inclua critérios de aceitação claros e específicos, que definem</p><p>as condições que precisam ser atendidas para que a história seja considerada completa. Isso garante que</p><p>a funcionalidade atenda às expectativas do usuário e facilite o processo de teste.</p><p>Sendo assim, os benefícios da utilização das user stories são numerosos. Elas promovem uma</p><p>abordagem de desenvolvimento centrada no usuário, melhoram a comunicação entre todos os envolvidos</p><p>no projeto e permitem mais flexibilidade e adaptabilidade no desenvolvimento. Ao serem pequenas e</p><p>manejáveis, facilitam a entrega contínua de valor e a obtenção de feedback rápido.</p><p>73</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>No entanto, a criação eficaz de user stories exige prática e atenção. É importante garantirmos</p><p>que as histórias sejam suficientemente detalhadas para serem entendidas e estimadas, mas não tão</p><p>detalhadas a ponto de se tornarem documentos longos e complexos. O equilíbrio entre simplicidade</p><p>e detalhe é crucial.</p><p>Além disso, esses itens devem ser priorizados de acordo com critérios como valor de negócio,</p><p>urgência, dependências e complexidade técnica. Manter o backlog organizado e priorizado é uma tarefa</p><p>contínua que requer colaboração entre o Product Owner, a equipe de desenvolvimento e os stakeholders.</p><p>A clareza e a precisão dos itens do backlog, portanto, são cruciais para evitar mal-entendidos e garantir</p><p>que a equipe esteja sempre focada nas tarefas mais importantes.</p><p>Lembrete</p><p>User stories são utilizadas para estimar o esforço necessário para</p><p>implementar uma funcionalidade, ajudando no planejamento de sprints e</p><p>na definição de prioridades no backlog. Além disso, é preciso termos claro</p><p>que há técnicas de priorização do backlog que usam user stories.</p><p>Assim, revisões regulares do backlog, através de reuniões de refinamento ou grooming, ajudam</p><p>a manter a qualidade dos itens e a ajustar as prioridades conforme necessário. No contexto do</p><p>desenvolvimento ágil, grooming refere-se ao processo de refinar e revisar os itens do backlog.</p><p>Observação</p><p>O termo backlog grooming tem sido substituído em muitos casos</p><p>por backlog refinement para evitar conotações negativas associadas</p><p>ao termo grooming.</p><p>Independentemente do termo utilizado, o conceito permanece o mesmo. Ele é uma atividade</p><p>contínua, em que a equipe de desenvolvimento, juntamente com o Product Owner, revisa e ajusta os</p><p>itens do backlog para garantir que estejam prontos para serem trabalhados em futuras iterações. Este</p><p>processo envolve várias atividades importantes. Vejamos a seguir.</p><p>•	 Esclarecimento de requisitos: os itens do backlog são detalhados e clarificados. Isso pode incluir</p><p>a decomposição de histórias de usuários grandes em histórias menores e mais manejáveis, além</p><p>de adicionar detalhes e critérios de aceitação para cada item.</p><p>•	 Priorização: o Product Owner revisa as prioridades dos itens do backlog, ajustando-as conforme</p><p>necessário, para refletir as necessidades do negócio, o feedback dos usuários e as  mudanças</p><p>de mercado.</p><p>74</p><p>Unidade II</p><p>•	 Estimação: a equipe de desenvolvimento fornece estimativas para os itens do backlog, ajudando</p><p>a planejar o trabalho futuro e a entender o esforço necessário para completar cada item.</p><p>•	 Identificação de dependências: durante o refinamento, a equipe identifica dependências entre</p><p>itens do backlog e outros aspectos do projeto, o que é crucial para o planejamento eficaz e a</p><p>mitigação de riscos.</p><p>•	 Remoção de itens obsoletos: itens que não são mais relevantes ou que perderam prioridade são</p><p>removidos do backlog para manter a lista limpa e focada.</p><p>Embora o backlog não seja necessariamente uma tabela, é frequentemente organizado de maneira</p><p>tabular para facilitar a visualização e o gerenciamento das tarefas. Quando representado como uma</p><p>tabela, ele geralmente inclui várias colunas que ajudam a descrever e priorizar seus itens. Verifiquemos</p><p>a seguir quais são eles.</p><p>•	 ID: identificador único para cada item para ajudar a rastrear e referenciar itens facilmente.</p><p>•	 Título: breve e descritivo para o item que resume a funcionalidade ou requisito.</p><p>•	 Descrição: frequentemente escrita no formato de user story para fornecer contexto e clareza.</p><p>•	 Prioridade: ordem de importância do item, geralmente definida pelo Product Owner, indicando</p><p>quais itens devem ser abordados primeiro.</p><p>•	 Estimativa: do esforço necessário para completar o item, frequentemente medida em pontos de</p><p>história ou horas.</p><p>•	 Status: estado atual do item, como novo, em andamento, em revisão, completo etc.</p><p>•	 Critérios de aceitação: condições específicas que devem ser atendidas para que</p><p>o item seja</p><p>considerado completo e aceito.</p><p>•	 Responsável: membro da equipe responsável por trabalhar no item.</p><p>•	 Data de criação: data em que o item foi adicionado ao backlog.</p><p>•	 Data de conclusão: data em que o item foi concluído e aceito.</p><p>•	 Tags/labels: palavras-chave ou etiquetas que ajudam a categorizar e organizar os itens do backlog</p><p>por tema, funcionalidade ou sprint.</p><p>75</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Essas colunas permitem uma organização clara e estruturada, facilitando a comunicação e o</p><p>planejamento. Usar uma tabela ou uma ferramenta de gerenciamento de projetos com funcionalidades</p><p>semelhantes ajuda a equipe a manter o controle sobre os itens do backlog, priorizar tarefas de maneira</p><p>eficaz e acompanhar o progresso de forma transparente.</p><p>A partir das informações apresentadas, imaginemos o backlog de produto para um sistema de</p><p>e-commerce. Esse sistema tem várias funcionalidades que atendem tanto às necessidades dos usuários</p><p>quanto às operações internas da loja on-line. As funcionalidades incluídas no backlog são fundamentais</p><p>para a experiência do usuário, permitindo que ele faça login, navegue na página inicial, adicione itens ao</p><p>carrinho de compras, finalize suas compras e receba notificações por e-mail sobre o status dos seus pedidos.</p><p>Cada uma dessas funcionalidades foi planejada e priorizada de acordo com a importância e o impacto</p><p>na satisfação do usuário, e na eficiência do sistema. Considerando isso, o quadro a seguir mostra parte</p><p>desse backlog. Trata-se de uma parte, pois ele tem apenas cinco itens, enquanto um backlog real pode</p><p>ter centenas de itens e, portanto, centenas de linhas.</p><p>Quadro 4 – Parte do backlog de um sistema de e‑commerce de um exemplo ilustrativo</p><p>ID Título Descrição Prioridade Estimativa Status Critérios de</p><p>aceitação Responsável Data de</p><p>criação</p><p>Data de</p><p>conclusão Tags/labels</p><p>1 Login de</p><p>usuário</p><p>Como um</p><p>usuário, eu</p><p>quero fazer</p><p>login no</p><p>sistema para</p><p>acessar minhas</p><p>informações</p><p>pessoais</p><p>Alta 5 Novo</p><p>Usuário pode</p><p>fazer login com</p><p>credenciais</p><p>válidas, ver</p><p>mensagem</p><p>de erro para</p><p>credenciais</p><p>inválidas</p><p>João 01/04 Login</p><p>2 Página</p><p>inicial</p><p>Como um</p><p>usuário, eu</p><p>quero ver</p><p>a página</p><p>inicial com</p><p>informações</p><p>relevantes</p><p>para facilitar a</p><p>navegação</p><p>Média 3 Em</p><p>andamento</p><p>Página inicial</p><p>carrega em</p><p>menos de 2</p><p>segundos, exibe</p><p>informações</p><p>personalizadas</p><p>Maria 01/04 UI</p><p>3 Carrinho de</p><p>compras</p><p>Como um</p><p>usuário, eu</p><p>quero adicionar</p><p>itens ao</p><p>carrinho de</p><p>compras para</p><p>que eu possa</p><p>comprá-los</p><p>posteriormente</p><p>Alta 8 Novo</p><p>Usuário pode</p><p>adicionar e</p><p>remover itens</p><p>do carrinho,</p><p>ver resumo do</p><p>carrinho</p><p>Carlos 02/04 E-commerce</p><p>4 Finalização</p><p>de compra</p><p>Como um</p><p>usuário, eu</p><p>quero finalizar</p><p>minha compra</p><p>para completar</p><p>minha</p><p>transação</p><p>Alta 8 Novo</p><p>Usuário</p><p>pode inserir</p><p>informações</p><p>de pagamento</p><p>e envio, ver</p><p>confirmação de</p><p>compra</p><p>Ana 02/04 E-commerce</p><p>5 Notificações</p><p>por e-mail</p><p>Como um</p><p>usuário, eu</p><p>quero receber</p><p>notificações por</p><p>e-mail sobre</p><p>o status dos</p><p>meus pedidos</p><p>Média 3 Em revisão</p><p>Usuário recebe</p><p>e-mails de</p><p>confirmação de</p><p>pedido, envio e</p><p>entrega</p><p>Lucas 02/05 Notificações</p><p>76</p><p>Unidade II</p><p>Uma vez os itens do backlog organizados, sua transformação de backlog de produto em backlog</p><p>do sprint é um processo essencial no framework ágil de desenvolvimento de software, sobretudo</p><p>no Scrum. Esse processo envolve a seleção e priorização de itens do backlog de produto que serão</p><p>trabalhados no próximo sprint.</p><p>Lembrete</p><p>Antes do início de cada sprint, ocorre uma reunião chamada Sprint</p><p>Planning. Nela, o Product Owner apresenta ao time de desenvolvimento os</p><p>itens do backlog de produto que ele considera prioritários.</p><p>O time de desenvolvimento, por sua vez, avalia os itens selecionados, levando em consideração a</p><p>capacidade e o tempo disponível durante o sprint. Esse processo envolve discussões detalhadas sobre cada</p><p>item, e o time pode fazer perguntas para esclarecer requisitos, estimar o esforço necessário e identificar</p><p>possíveis obstáculos.</p><p>Com base nessas discussões, o time de desenvolvimento seleciona os itens do backlog de produto que</p><p>acredita ser capaz de concluir durante o sprint. Depois, eles são movidos para o backlog da sprint, que é</p><p>uma lista mais curta e focada contendo tudo o que será trabalhado nas próximas semanas.</p><p>Uma vez que o sprint começa, o consumo do backlog do sprint é monitorado através de</p><p>várias práticas e ferramentas. As reuniões diárias permitem que o time se reúna para discutir o</p><p>progresso, identificar obstáculos e ajustar os planos conforme necessário. Cada membro do time</p><p>compartilha o que fez no dia anterior, o que planeja fazer no dia atual e quaisquer impedimentos que</p><p>estejam enfrentando.</p><p>Além disso, gráficos de burndown, como o da figura a seguir, são usados como uma ferramenta</p><p>visual para mostrar o progresso do sprint, exibindo a quantidade de trabalho restante ao longo do tempo.</p><p>Idealmente, a linha no gráfico deve descer continuamente, indicando que o trabalho está</p><p>sendo concluído conforme planejado. Se a linha permanece no mesmo ponto ou sobe, pode ser</p><p>um sinal de que a equipe está enfrentando dificuldades. No caso apresentado a seguir, temos, no</p><p>eixo horizontal, os dias de trabalho no sprint e no eixo vertical, o número de pontos já consumidos</p><p>(story points concluídos).</p><p>77</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>50</p><p>45</p><p>40</p><p>35</p><p>30</p><p>25</p><p>20</p><p>15</p><p>10</p><p>5</p><p>0</p><p>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15</p><p>Figura 13 – Gráfico de burndown para visualizar o consumo do backlog do sprint</p><p>Outra prática comum é o uso de quadros Kanban, que ajudam a visualizar o fluxo de trabalho</p><p>durante o sprint. Kanban é uma metodologia de gerenciamento de trabalho originada no sistema de</p><p>produção enxuta da Toyota, destinada a melhorar a eficiência e a visibilidade do fluxo de trabalho. Seu</p><p>nome, que em japonês significa cartão visual, ou sinalização, reflete seu foco na utilização de cartões</p><p>visuais para monitorar o progresso das tarefas.</p><p>No contexto do desenvolvimento de software ágil, o Kanban ajuda equipes a gerenciar e otimizar</p><p>seu fluxo de trabalho, promovendo a entrega e a melhoria contínua.</p><p>A principal característica do Kanban é seu quadro visual, onde as tarefas são representadas por</p><p>cartões que se movem através de diferentes colunas, cada uma representando um estágio do processo</p><p>de trabalho. As colunas típicas podem incluir: a fazer, em progresso e concluído, embora possam ser</p><p>adaptadas conforme necessário para refletir as etapas específicas do fluxo de trabalho de uma equipe.</p><p>O movimento dos cartões entre as colunas oferece uma visualização clara do estado atual do trabalho,</p><p>permitindo que todos os membros da equipe entendam facilmente o que está sendo feito, o que está</p><p>pendente e o que já foi concluído.</p><p>Uma das premissas fundamentais do Kanban é a limitação do trabalho em progresso (WIP, do inglês</p><p>Work In Progress). Essa prática impede que a equipe se sobrecarregue com muitas tarefas ao mesmo</p><p>tempo, promovendo um foco maior nas atividades que estão sendo realizadas. Ao limitar o número de</p><p>tarefas em cada estágio, o Kanban ajuda a identificar gargalos e ineficiências no processo, incentivando</p><p>a equipe a resolver esses problemas para melhorar o fluxo de trabalho.</p><p>A figura 14 mostra um exemplo simples de quadro Kanban para uma equipe de desenvolvimento</p><p>de um site de e-commerce. Os itens do backlog do sprint são representados por cartões que se movem</p><p>através de diferentes colunas, como pendente, em andamento e entregue. Isso ajuda a equipe a ver</p><p>rapidamente o estado atual de cada item e identificar gargalos no processo.</p><p>78</p><p>Unidade II</p><p>Pendente Em andamento Entregue</p><p>De</p><p>ve</p><p>lo</p><p>pm</p><p>en</p><p>t</p><p>De</p><p>si</p><p>gn</p><p>M</p><p>ar</p><p>ke</p><p>tin</p><p>g</p><p>Implementar</p><p>gateway de</p><p>pagamento</p><p>Redesign</p><p>da página</p><p>de checkout</p><p>Otimizar</p><p>carregamento</p><p>de páginas</p><p>Corrigir bug</p><p>no cálculo</p><p>de frete</p><p>Adicionar</p><p>recomendações</p><p>de produtos</p><p>Integrar</p><p>sistema de</p><p>feedbacks</p><p>dos clientes</p><p>Atualizar</p><p>políticas de</p><p>privacidade</p><p>Figura 14 – Exemplo de um quadro de Kaban simples</p><p>No final de cada sprint, a equipe</p><p>realiza uma Sprint Review, demonstrando o trabalho concluído</p><p>para as partes interessadas e coleta de feedback. Em seguida, na Sprint Retrospective, a equipe reflete</p><p>sobre o que funcionou bem, o que poderia ser melhorado e como todos podem ser mais eficientes nas</p><p>próximas sprints. Cada uma dessas reuniões tem objetivos específicos e contribui de maneiras distintas</p><p>para a melhoria contínua do processo de desenvolvimento e para a gestão eficaz do backlog do produto.</p><p>Lembrete</p><p>A Sprint Review tem como objetivo inspecionar o incremento do</p><p>produto desenvolvido durante o sprint e adaptar o backlog do produto</p><p>conforme necessário. O Scrum Team, composto pelo Product Owner, Scrum</p><p>Master e os desenvolvedores, participa da Sprint Review, juntamente com</p><p>stakeholders e qualquer outra pessoa interessada no progresso do projeto.</p><p>O Product Owner é o responsável por convocar a Sprint Review e preparar a reunião, embora todos os</p><p>membros do Scrum Team contribuam com a apresentação do trabalho concluído. Durante a revisão,</p><p>os desenvolvedores demonstram o que foi construído e discutem as funcionalidades implementadas,</p><p>bem como quaisquer desafios encontrados.</p><p>Essa é uma oportunidade para obter feedback direto dos stakeholders, que podem sugerir melhorias</p><p>e novos requisitos. Esse feedback é essencial, pois permite que o Product Owner atualize o backlog do</p><p>produto, adicionando novos itens ou ajustando os existentes para alinhar melhor o desenvolvimento às</p><p>expectativas e necessidades do usuário final.</p><p>79</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Por outro lado, a Sprint Retrospective é uma reunião interna do Scrum Team que ocorre após a</p><p>Sprint Review e antes do início do próximo sprint. O principal objetivo da Sprint Retrospective é refletir</p><p>sobre o processo de trabalho da equipe e identificar oportunidades de melhoria contínua. A seguir,</p><p>apresentaremos diversos tópicos que podem ser abordados numa reunião, que é facilitada pelo Scrum</p><p>Master, que busca garantir que a discussão seja produtiva e focada em melhorias práticas.</p><p>Durante a Sprint Retrospective, o Scrum Team discute o que funcionou bem no sprint anterior, o</p><p>que poderia ser melhorado e quais ações podem ser implementadas para aprimorar o desempenho</p><p>no próximo sprint. Diferentemente da Sprint Review, stakeholders externos não participam desta</p><p>reunião. A natureza introspectiva da Sprint Retrospective permite um ambiente seguro para a equipe</p><p>abordar problemas internos e buscar soluções colaborativas. As ações de melhoria identificadas são</p><p>frequentemente adicionadas ao backlog do sprint ou diretamente ao backlog do produto como itens de</p><p>prioridade a serem abordados nos próximos sprints.</p><p>A relação entre essas cerimônias e a gestão do backlog é direta e significativa. A Sprint Review ajuda</p><p>a ajustar e refinar o backlog do produto com base no feedback dos stakeholders e nas demonstrações</p><p>práticas do incremento do produto. Já a Sprint Retrospective foca em aprimorar os processos</p><p>internos da equipe, o que pode influenciar a eficiência e a qualidade das entregas futuras, refletindo,</p><p>consequentemente, no backlog de trabalho.</p><p>A responsabilidade de preparação para ambas as cerimônias é compartilhada, embora com papéis</p><p>definidos: o Product Owner lidera a preparação para a Sprint Review e o Scrum Master facilita a Sprint</p><p>Retrospective. Todos os membros do Scrum Team são participantes ativos e contribuem para o sucesso</p><p>dessas reuniões.</p><p>Considerando tais aspectos, podemos considerar os seguintes tópicos, que podem ser abordados em</p><p>uma Sprint Retrospective.</p><p>•	 Comunicação da equipe: como foi a comunicação interna durante o sprint? Houve algum</p><p>problema de comunicação que levou a mal-entendidos ou atrasos? Todos os membros se sentiram</p><p>ouvidos e puderam contribuir com suas ideias?</p><p>•	 Colaboração entre membros da equipe: como foi a colaboração durante o sprint? Houve uma</p><p>boa divisão de tarefas? Todos os membros tiveram a oportunidade de trabalhar nas áreas de suas</p><p>especialidades? Algum membro se sentiu sobrecarregado?</p><p>•	 Cumprimento de prazos: as estimativas de tempo para as tarefas foram precisas e conseguiram</p><p>cumprir os prazos estabelecidos? Houve algum problema que causou atrasos? Como esses</p><p>problemas podem ser evitados no futuro?</p><p>•	 Qualidade do código: qual é a qualidade do código produzido durante o sprint? Foram seguidas</p><p>as melhores práticas de codificação? Houve muitos bugs ou problemas de integração? Como esses</p><p>aspectos podem ser melhorados?</p><p>80</p><p>Unidade II</p><p>•	 Feedback dos stakeholders: qual foi o feedback recebido dos stakeholders durante o sprint?</p><p>Houve alguma crítica ou sugestão que precisa ser levada em conta? Como a equipe pode melhorar</p><p>a satisfação dos stakeholders?</p><p>•	 Ferramentas e processos: qual é a eficácia das ferramentas e processos utilizados durante o</p><p>sprint? Alguma ferramenta ou processo foi um obstáculo ao invés de ajudar? Existe alguma nova</p><p>ferramenta ou método que poderia ser adotado para melhorar a eficiência?</p><p>•	 Moral da equipe: como estava o moral e o bem-estar dos membros durante o sprint? Algum</p><p>membro se sentiu desmotivado ou estressado? Como a equipe pode criar um ambiente de trabalho</p><p>mais saudável e motivador?</p><p>•	 Adaptação a mudanças: como a equipe lidou com mudanças de requisitos ou prioridades</p><p>durante o sprint? Foi fácil se adaptar? Alguma mudança causou problemas significativos? Como</p><p>a equipe pode se preparar melhor para mudanças futuras?</p><p>•	 Aprendizados técnicos: como foi o compartilhamento de novos conhecimentos ou técnicas</p><p>aprendidas durante o sprint? Houve algum desafio técnico que foi superado com uma solução</p><p>inovadora? Como esses aprendizados podem ser aplicados em sprints futuros?</p><p>•	 Planejamento do sprint: como foi a eficácia do planejamento do sprint? As histórias de usuário</p><p>e tarefas estavam bem definidas? Alguma tarefa foi subestimada ou superestimada? Como o</p><p>planejamento pode ser melhorado para os próximos sprints?</p><p>Portanto, a Sprint Review e a Sprint Retrospective são essenciais para garantir a transparência, a</p><p>inspeção e a adaptação contínua, pilares do Scrum, que promovem um ciclo de feedback constante</p><p>e a melhoria contínua do processo de desenvolvimento e do produto em si.</p><p>Essas práticas combinadas ajudam a garantir que o backlog do sprint seja consumido de maneira</p><p>eficiente e que a equipe esteja constantemente melhorando seu processo de trabalho. O objetivo é</p><p>entregar incrementos de valor ao produto de modo contínuo e previsível, respondendo de maneira ágil</p><p>às mudanças nas necessidades dos clientes e do mercado.</p><p>Em essência, o backlog é uma ferramenta vital para a gestão ágil de projetos, proporcionando uma</p><p>visão clara das tarefas a serem realizadas e permitindo uma adaptação rápida às mudanças e novas</p><p>demandas. Ele facilita a comunicação e o alinhamento entre todos os envolvidos no projeto, assegurando</p><p>que a equipe de desenvolvimento trabalhe de maneira eficiente e eficaz, sempre direcionada para</p><p>entregar valor ao cliente e atender às metas do negócio.</p><p>81</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>4 QUALIDADE, TESTES E PRÁTICAS DE ENTREGA CONTÍNUA (CD)</p><p>A importância da qualidade e dos testes no desenvolvimento de software é amplamente reconhecida</p><p>tanto nas abordagens tradicionais do PMI quanto nas metodologias ágeis.</p><p>No contexto do PMI, a qualidade é gerida através de processos bem definidos e rigorosos, que</p><p>incluem planejamento, garantia e controle da qualidade. Esses processos visam assegurar que o produto</p><p>final atenda aos requisitos especificados e satisfaça as expectativas dos stakeholders.</p><p>Os testes são uma parte fundamental deste processo, realizados em fases distintas do ciclo de</p><p>desenvolvimento para identificar e corrigir defeitos antes da entrega final.</p><p>A agilidade, no entanto, incorpora e expande esses conceitos ao enfatizar a CI da qualidade e dos</p><p>testes ao longo de todo o processo de desenvolvimento. Em vez de tratar a qualidade como uma fase</p><p>final, as metodologias ágeis integram práticas de qualidade desde o início, promovendo</p><p>uma abordagem</p><p>iterativa e incremental. Isso permite a identificação precoce de problemas e a adaptação rápida às</p><p>mudanças, assegurando que o produto esteja continuamente alinhado com as necessidades do cliente.</p><p>A CI e a CD são práticas essenciais no desenvolvimento ágil que suportam essa abordagem,</p><p>justamente, contínua de qualidade. A CI envolve a integração frequente do código desenvolvido pela</p><p>equipe em um repositório compartilhado. Cada integração é verificada automaticamente por meio de</p><p>testes automatizados, o que permite a detecção e correção rápida de defeitos.</p><p>Essa prática reduz significativamente os riscos associados a integrações tardias, promove a</p><p>colaboração entre os desenvolvedores e garante que o código esteja sempre em um estado funcional.</p><p>A CD, por sua vez, vai além da CI ao automatizar não apenas a integração, mas também a entrega</p><p>do software em ambientes de produção. A CD garante que o software esteja sempre em um estado</p><p>pronto para ser liberado para os usuários finais. Isso é alcançado através da automação de todo o</p><p>pipeline de entrega, incluindo testes, configuração e deployment.</p><p>A principal vantagem da CD é a capacidade de entregar novas funcionalidades e correções de</p><p>maneira rápida e confiável, proporcionando um feedback contínuo dos usuários e permitindo ajustes</p><p>rápidos conforme necessário.</p><p>Observação</p><p>No contexto do desenvolvimento de software utilizando frameworks</p><p>ágeis, o termo deployment refere-se ao processo de colocar uma aplicação</p><p>ou atualização de produção, tornando-a disponível para os usuários finais.</p><p>Esse processo envolve várias etapas, incluindo a preparação, configuração</p><p>e instalação do software em um ambiente de produção, garantindo que</p><p>ele esteja pronto para uso. O objetivo principal do deployment é entregar</p><p>novas funcionalidades, correções de bugs ou melhorias de desempenho de</p><p>modo rápido, seguro e eficiente.</p><p>82</p><p>Unidade II</p><p>Os testes automatizados desempenham um papel crucial nessas práticas, assegurando que cada</p><p>mudança no código seja rigorosamente testada antes de ser integrada ou liberada. A abordagem de</p><p>Test Driven Development (TDD) é uma prática fundamental nesse contexto. No TDD, os testes são escritos</p><p>antes do código de produção.</p><p>Esse método assegura que o código desenvolvido atenda aos requisitos especificados desde o início</p><p>e promove um design mais limpo e modular. O TDD também facilita a manutenção do código e reduz a</p><p>incidência de defeitos, pois os desenvolvedores são incentivados a considerar cenários de teste desde</p><p>o início do desenvolvimento.</p><p>O deployment e o monitoramento em ambientes ágeis são igualmente críticos para garantir a</p><p>qualidade contínua do software. O deployment automatizado permite que novas versões do software</p><p>sejam liberadas de maneira rápida e sem intervenção manual, minimizando erros humanos e acelerando</p><p>o ciclo de entrega.</p><p>Ferramentas de automação de deployment, como Jenkins, Travis CI e GitLab CI/CD, são amplamente</p><p>utilizadas para gerenciar este processo, garantindo que cada nova versão seja configurada e implantada</p><p>de acordo com padrões pré-definidos. O monitoramento contínuo pós-deployment é vital para garantir</p><p>que o software funcione conforme esperado em produção.</p><p>Já as ferramentas de monitoramento, como Prometheus, Grafana e New Relic, permitem a coleta e</p><p>análise de métricas de desempenho e logs em tempo real. Isso facilita a detecção precoce de problemas,</p><p>como falhas de desempenho ou erros de aplicação, e permite uma resposta rápida para mitigar</p><p>quaisquer impactos negativos. O monitoramento contínuo também fornece insights valiosos sobre o</p><p>uso do software e o comportamento dos usuários, informando futuras melhorias e ajustes no produto.</p><p>Em resumo, as práticas de qualidade, testes e CD são vitais no desenvolvimento de software usando</p><p>frameworks ágeis e serão detalhadas a seguir. Elas garantem que o software seja desenvolvido e</p><p>entregue com alta qualidade, respondendo rapidamente às necessidades do mercado e aos feedbacks</p><p>dos usuários. A CI, a CD, os testes automatizados e o monitoramento contínuo trabalham juntos para</p><p>criar um ciclo de desenvolvimento dinâmico e eficiente, no qual a qualidade é integrada em cada etapa</p><p>do processo, resultando em produtos mais robustos e satisfatórios para os clientes.</p><p>4.1 A importância da qualidade e testes nas abordagens tradicionais do PMI</p><p>e como a agilidade incorpora e expande esses conceitos</p><p>Para o PMI, a qualidade é definida como o grau em que um conjunto de características inerentes</p><p>cumpre requisitos. Em outras palavras, qualidade refere-se à capacidade de um produto ou serviço</p><p>atender às expectativas e necessidades especificadas pelos stakeholders. A gestão da qualidade no PMI</p><p>envolve três componentes principais: planejamento, garantia e controle da qualidade.</p><p>O planejamento estabelece políticas, objetivos e responsabilidades para a qualidade, garantindo que</p><p>um projeto cumpra os padrões e requisitos definidos, isto é, a garantia da qualidade busca que os</p><p>processos usados durante o projeto sejam adequados para atingir seus objetivos. O controle da qualidade</p><p>83</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>monitora os resultados específicos do projeto para garantir que eles estejam de acordo com os padrões</p><p>de qualidade e identificar formas de eliminar causas de desempenho insatisfatório.</p><p>Quando se trata de qualidade de software, essa definição é ampliada para incluir atributos específicos</p><p>que garantem que o software atenda não apenas aos requisitos funcionais, mas também aos não funcionais.</p><p>Qualidade de software, portanto, envolve como um software atende aos requisitos funcionais, como</p><p>funcionalidades e desempenho, e os requisitos não funcionais, como segurança, usabilidade, eficiência,</p><p>confiabilidade e manutenção.</p><p>Um software de alta qualidade deve funcionar corretamente sob condições especificadas, ser livre</p><p>de defeitos e vulnerabilidades, ser fácil de usar e manter, e proporcionar uma experiência satisfatória</p><p>ao usuário. Sua qualidade envolve atividades contínuas de verificação e validação ao longo do ciclo de</p><p>vida do desenvolvimento do software. Isso inclui a definição clara dos requisitos, o uso de processos</p><p>padronizados e boas práticas de engenharia, testes rigorosos e uma revisão contínua do desempenho e</p><p>da funcionalidade do software.</p><p>O objetivo é assegurar que o software entregue esteja em conformidade com as especificações,</p><p>seja robusto e confiável, e satisfaça as necessidades dos usuários e stakeholders. Para isso, o PMI usa o</p><p>termo gold plating para se referir à prática de adicionar funcionalidades ou melhorias extras que não</p><p>foram solicitadas pelo cliente ou pelos stakeholders. Essas adições vão além dos requisitos inicialmente</p><p>acordados e muitas vezes são feitas na tentativa de exceder as expectativas do cliente ou para aumentar</p><p>a percepção de qualidade do trabalho realizado.</p><p>Embora a intenção por trás do gold plating possa parecer positiva, essa prática é geralmente</p><p>desencorajada por várias razões. Primeiramente, adicionar funcionalidades não solicitadas pode desviar</p><p>recursos, tempo e esforço de outras partes críticas do projeto, resultando em atrasos e aumento de</p><p>custos. Além disso, essas adições podem introduzir novos riscos e defeitos ao sistema, comprometendo</p><p>a estabilidade e a segurança do produto final.</p><p>Em projetos de software o gold plating pode manifestar-se como características extras, as quais</p><p>os desenvolvedores decidem incluir por acreditarem que melhorarão a experiência do usuário ou</p><p>que aumentarão o valor do produto. No entanto, essas funcionalidades extras podem complicar</p><p>a manutenção futura do software, dificultar o processo de teste e integração, e até mesmo causar</p><p>problemas de usabilidade, se não forem bem alinhadas com as necessidades reais dos usuários.</p><p>O Capability Maturity Model Integration (CMMI) define a qualidade de software como a medida</p><p>em que ele atende às necessidades dos usuários e aos requisitos especificados. A qualidade de software</p><p>no contexto do</p><p>CMMI envolve um conjunto abrangente de práticas que garantem que o produto final</p><p>funcione conforme o esperado e seja confiável, eficiente, utilizável e possa ser mantido.</p><p>O CMMI foca na melhoria contínua dos processos de desenvolvimento, enfatizando a importância de</p><p>práticas organizacionais maduras e bem definidas para alcançar altos níveis de qualidade. Esse modelo</p><p>categoriza a maturidade dos processos de uma organização em cinco níveis, começando com processos</p><p>imprevisíveis e mal controlados e evoluindo para processos bem caracterizados, compreendidos e</p><p>84</p><p>Unidade II</p><p>controlados usando métodos quantitativos e qualitativos, culminando em focar na melhoria contínua</p><p>dos processos, através de inovações tecnológicas e incrementais.</p><p>Dentro do CMMI, a qualidade de software é garantida através de práticas estruturadas como</p><p>gerenciamento de requisitos, planejamento de projetos, monitoramento e controle, garantia de</p><p>qualidade  de processos e produtos, e verificação e validação. Essas práticas asseguram que o</p><p>desenvolvimento de software siga um processo disciplinado que resulte em um produto de alta qualidade.</p><p>A abordagem do CMMI é metodológica e detalhada, proporcionando uma estrutura clara para avaliar e</p><p>melhorar os processos organizacionais, com o objetivo de garantir que os produtos de software sejam</p><p>desenvolvidos de maneira eficiente e eficaz.</p><p>Os testes, dentro dessa abordagem tradicional, são realizados em fases específicas e muitas vezes</p><p>são concentrados na parte final do ciclo de desenvolvimento, conhecido como ciclo em cascata. Esse</p><p>método visa assegurar que todos os requisitos do cliente sejam atendidos e que o produto esteja</p><p>livre de defeitos antes de sua entrega. As fases de teste incluem testes unitários, de integração, de</p><p>sistema e de aceitação, cada um desempenhando um papel crucial na validação da funcionalidade e na</p><p>identificação de defeitos.</p><p>A agilidade, por sua vez, não apenas incorpora esses conceitos de qualidade e testes, mas também</p><p>os expande significativamente. Nas metodologias ágeis, a qualidade é integrada de maneira contínua</p><p>ao longo de todo o processo de desenvolvimento, em vez de ser tratada como uma fase final. Isso é</p><p>alcançado através de ciclos de desenvolvimento iterativos e incrementais, e cada iteração, ou sprint,</p><p>inclui atividades de planejamento, desenvolvimento, teste e revisão.</p><p>Essa abordagem permite que os problemas sejam identificados e corrigidos mais cedo, reduzindo</p><p>o risco de defeitos e melhorando a qualidade do produto ao longo do tempo. Nos métodos ágeis, o</p><p>tratamento do gold plating é abordado de modo muito rigoroso para assegurar que o foco permaneça</p><p>nas necessidades reais do cliente e nos requisitos previamente acordados. A filosofia ágil enfatiza a</p><p>entrega contínua de valor ao cliente e a adaptação às mudanças de requisitos, mas sempre dentro dos</p><p>limites claramente definidos e priorizados do backlog do produto.</p><p>Os frameworks ágeis tratam o gold plating através de práticas rigorosas de gestão do backlog, ciclos</p><p>de desenvolvimento iterativos e incrementais, e comunicação contínua entre a equipe e os stakeholders.</p><p>O foco constante em entregar valor real ao cliente, aliado a processos de revisão e retrospectiva, ajuda a</p><p>garantir que somente as funcionalidades necessárias e aprovadas sejam implementadas, evitando</p><p>a adição de funcionalidades extras não solicitadas.</p><p>O CMMI incorporou práticas ágeis em seu modelo de várias maneiras, reconhecendo que muitas</p><p>organizações estão adotando metodologias ágeis e que essas práticas podem ser altamente eficazes</p><p>quando bem implementadas. O CMMI V2.0 foi projetado para ser mais flexível e adaptável, permitindo</p><p>uma integração mais harmoniosa com metodologias ágeis. Essa versão enfatiza a importância de</p><p>princípios ágeis como entregas incrementais, feedback contínuo e melhoria contínua.</p><p>85</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Para integrar práticas ágeis ao CMMI, o modelo foi atualizado para incluir práticas que suportam o</p><p>desenvolvimento iterativo e incremental. Por exemplo, a gestão de requisitos e de mudanças no CMMI</p><p>passou a reconhecer a necessidade de responder rapidamente às mudanças e priorizar o trabalho com</p><p>base no valor entregue ao cliente. Neste caso, o uso de retrospectivas ágeis e reuniões diárias de stand-up</p><p>são práticas que podem ser alinhadas com os requisitos do CMMI para garantir comunicação contínua,</p><p>avaliação de desempenho e identificação de melhorias.</p><p>Além disso, o CMMI V2.0 inclui áreas de prática que são compatíveis com métodos ágeis, como a</p><p>gestão  de desempenho do trabalho, que enfatiza a definição de metas de desempenho, a medição</p><p>e a análise do progresso e a implementação de melhorias baseadas em dados. O modelo também incentiva a</p><p>utilização de abordagens ágeis para garantir a qualidade do produto, como testes automatizados e CI,</p><p>que são fundamentais para manter altos padrões de qualidade em um ambiente de desenvolvimento</p><p>rápido e iterativo.</p><p>Observação</p><p>Em 2023, o CMMI liberou a nova versão (v3.0), que trouxe dois novos</p><p>domínios: Data e People.</p><p>Os testes no contexto ágil são uma atividade contínua e integrada. Em vez de esperar até o final</p><p>do desenvolvimento para testar o software, os testes são realizados em cada iteração. Isso inclui testes</p><p>unitários automatizados, que verificam a funcionalidade de pequenos pedaços de código, e testes de</p><p>integração, que asseguram que os diferentes módulos do software funcionem juntos como esperado.</p><p>Adicionalmente, a abordagem ágil enfatiza o uso de testes de aceitação baseados em comportamento (BDD)</p><p>e desenvolvimento orientado a testes (TDD), que são escritos antes mesmo do código de produção. Esse</p><p>método garante que o código atenda aos requisitos desde o início e facilita a criação de um código mais</p><p>limpo e modular.</p><p>Os frameworks ágeis integram garantia de qualidade QA (Quality Assurance) e testes de maneira contínua</p><p>e iterativa. Assim, a agilidade promove a colaboração constante entre as equipes de desenvolvimento,</p><p>QA e outras partes interessadas, garantindo que a qualidade seja uma responsabilidade compartilhada</p><p>e presente em cada etapa do desenvolvimento.</p><p>Ao integrar e expandir os conceitos tradicionais de qualidade e testes, a abordagem ágil cria um</p><p>ciclo de desenvolvimento mais dinâmico e eficiente. A qualidade não é mais um objetivo a ser alcançado</p><p>apenas no final do projeto, mas sim uma responsabilidade contínua e compartilhada por toda a equipe</p><p>ao longo do ciclo de vida do desenvolvimento.</p><p>Portanto, a CI de qualidade e testes assegura que o produto final não apenas atenda, mas</p><p>frequentemente exceda as expectativas do cliente, adaptando-se rapidamente às mudanças e feedbacks</p><p>e entregando valor de forma consistente e previsível.</p><p>86</p><p>Unidade II</p><p>4.2 Integração contínua (CI) e entrega contínua (CD)</p><p>A CI é uma prática fundamental no desenvolvimento de softwares ágeis, voltada para a melhoria da</p><p>qualidade do código e a eficiência no processo de desenvolvimento. A ideia central da CI é garantir que</p><p>o código escrito por diferentes desenvolvedores seja integrado regularmente em um repositório central,</p><p>permitindo a detecção precoce de problemas e facilitando a colaboração entre a equipe.</p><p>No desenvolvimento de software tradicional, as integrações de código ocorrem de maneira</p><p>esporádica, geralmente no final de um ciclo de desenvolvimento. Isso pode resultar em conflitos difíceis</p><p>de resolver, bugs inesperados e atrasos na entrega do produto final. A CI, por outro lado, propõe uma</p><p>abordagem em que as integrações são frequentes, muitas vezes várias ao dia. Cada desenvolvedor envia</p><p>suas alterações para o repositório central e elas são automaticamente testadas e validadas.</p><p>Quando um desenvolvedor finaliza uma parte do código, ele envia (faz o commit) essas alterações</p><p>para o repositório central de forma contínua e regular. Cada vez que um commit é feito, um servidor de</p><p>CI (Jenkins, Travis CI ou CircleCI) automaticamente compila o código.</p><p>Este processo é parte de um pipeline de</p>