Métodos Ágeis

Métodos Ágeis: Introdução e Conceitos

O que são Métodos Ágeis?

• A gravação inicia com uma introdução aos métodos ágeis, abordando princípios e características comuns que contribuem para seu sucesso no mercado.

• Os métodos ágeis surgiram a partir do Manifesto Ágil, criado em fevereiro de 2001 por 17 especialistas em desenvolvimento de software, como resposta a problemas de atrasos e orçamentos estourados.

• A modelagem ágil é discutida como uma prática importante dentro dos métodos ágeis, focando na compreensão do design ao invés da documentação.

• O Extreme Programming (XP) é destacado como o método ágil mais famoso, com foco em seus valores e práticas.

• Também será abordado o Scrum, um método utilizado para planejamento e execução de projetos de software.

Características Comuns dos Métodos Ágeis

• Não existe uma definição única para métodos ágeis; as respostas variam entre profissionais. No entanto, algumas características são compartilhadas.

• Desenvolvimento iterativo é um conceito central; o trabalho é guiado por listas de tarefas priorizadas.

• O desenvolvimento "Baby Steps" permite que pequenas funcionalidades sejam implementadas gradualmente sem sobrecarregar a equipe.

• Equipes multifuncionais e auto-organizáveis são fundamentais; os times se organizam autonomamente para atender objetivos durante iterações chamadas Sprints no Scrum.

• A confiança entre membros da equipe e stakeholders é essencial para o sucesso dos projetos.

Entregas e Medidas de Progresso

• As entregas devem ser prontas para produção ao final das iterações; não se entrega apenas documentação, mas código funcional.

• A principal medida de progresso nos métodos ágeis é o código funcionando, não a documentação extensa.

• Testes automatizados e integração contínua são práticas comuns; cada commit deve passar por testes automáticos antes da produção.

Aceitação de Mudanças

• Os métodos ágeis aceitam mudanças constantes nos requisitos; isso requer inspeção contínua do desenvolvimento do projeto baseado em feedback regular.

Métodos Ágeis: Características e Princípios

Características dos Métodos Ágeis

• Os métodos ágeis permitem que planos, listas de tarefas e requisitos sejam refinados e evoluídos ao longo do projeto, sem uma análise de requisitos inicial detalhada.

• O planejamento evolutivo é fundamental; os requisitos são detalhados no momento oportuno para a implementação, evitando excessos de documentação.

• Um dos principais desafios no desenvolvimento de software é o abismo entre clientes (que entendem o negócio) e desenvolvedores (que entendem a tecnologia). Métodos ágeis promovem acompanhamento frequente com o cliente.

• A presença constante do cliente na equipe ajuda a esclarecer ambiguidades e foca nas funcionalidades que mais agregam valor ao produto final.

• Todos os métodos ágeis reconhecem a necessidade de se adaptar à natureza dinâmica do processo de construção de software.

O Manifesto Ágil

• Em fevereiro de 2001, 17 pensadores se reuniram em Utah para criar o Manifesto Ágil, visando resolver problemas comuns em projetos de software que não eram concluídos dentro do prazo ou orçamento.

• O manifesto surgiu como resposta às dificuldades enfrentadas na entrega pontual e com qualidade nos projetos, estabelecendo diretrizes para um desenvolvimento mais eficiente.

• O resultado foi um conjunto conhecido como Manifesto Ágil, que delineia valores e princípios fundamentais para melhorar a qualidade do desenvolvimento de software.

Valores Fundamentais do Manifesto Ágil

• Os valores centrais incluem priorizar indivíduos e interações sobre processos e ferramentas. Isso enfatiza a importância da colaboração entre todos os envolvidos no projeto.

• É mais importante ter software funcionando do que manter documentação abrangente. A colaboração contínua com o cliente é preferível à negociação contratual rígida.

• Responder rapidamente às mudanças é considerado mais valioso do que seguir estritamente um plano predefinido.

Princípios do Manifesto Ágil

• O primeiro princípio destaca a satisfação do cliente através da entrega contínua de software valioso.

• Aceitar mudanças nos requisitos mesmo nas fases finais é crucial para garantir vantagens competitivas ao cliente.

• Entregar software funcional frequentemente deve ser priorizado, favorecendo iterações curtas para reduzir o abismo entre clientes e desenvolvedores.

• A colaboração diária entre executivos relacionados aos negócios e desenvolvedores é essencial durante todo o projeto para garantir alinhamento nas expectativas.

Princípios Ágeis e Modelagem

Comunicação e Sustentabilidade no Desenvolvimento

• O primeiro princípio ágil enfatiza a importância da comunicação face a face entre os envolvidos no projeto, promovendo um ambiente colaborativo.

• O conceito de ritmo sustentável é destacado, onde equipes devem manter um fluxo constante de trabalho sem sobrecarga, evitando burnout e garantindo produtividade a longo prazo.

Excelência Técnica e Simplicidade

• A atenção à excelência técnica é crucial; práticas como testes automatizados e refatoração melhoram o design dos aplicativos, facilitando manutenção e expansão.

• O décimo princípio ágil aborda a simplicidade, que envolve maximizar o trabalho que não precisa ser feito, focando em funcionalidades que realmente trazem retorno ao cliente.

Auto-organização e Reflexão Contínua

• Times auto-organizáveis são fundamentais para emergir as melhores arquiteturas e designs, promovendo autonomia na equipe.

• A reflexão regular permite que as equipes ajustem suas práticas com base em feedback contínuo, otimizando seu desempenho ao longo do desenvolvimento.

Modelagem Ágil: Práticas e Valores

• Scott Ambler introduz a modelagem ágil como uma prática para entender designs sem necessidade de documentação excessiva.

• É recomendado usar ferramentas simples para modelagem colaborativa, permitindo que várias pessoas contribuam simultaneamente para o entendimento do design.

Importância da UML e Criação Colaborativa

• A UML cresceu significativamente nos últimos anos; no entanto, deve-se utilizar apenas os elementos necessários que agreguem valor ao projeto.

• Os modelos devem ser criados pelos desenvolvedores para facilitar sua compreensão pessoal e comunicação com outros membros da equipe.

Diferenças entre Modelagem Ágil e Engenharia Dirigida por Modelos

• A engenharia dirigida por modelos (MDA) difere da modelagem ágil; enquanto MDA utiliza modelos como força motriz para gerar código executável, a modelagem ágil foca na colaboração e entendimento do design.

XP: Um Método Ágil Focado em Adaptação

Introdução ao Extreme Programming (XP)

Conceitos Fundamentais do XP

• O Extreme Programming (XP) reúne regras já conhecidas no desenvolvimento de software, mas as organiza de uma nova maneira para que funcionem em conjunto.

• As principais variáveis de controle em projetos segundo o PMBOK são custo, tempo, qualidade e escopo; no XP, há uma ênfase especial na priorização do escopo.

• O XP prioriza funcionalidades que trazem maior valor para o negócio; se necessário reduzir o escopo, as funcionalidades menos valiosas são adiadas ou canceladas.

Valores Centrais do XP

• Os valores fundamentais do XP incluem comunicação diária entre todos os membros da equipe e simplicidade nas soluções propostas.

• Feedback rápido é essencial; a entrega frequente de software permite ajustes contínuos com base nas necessidades dos usuários.

• A coragem é um valor importante: todos devem ser transparentes sobre o progresso e as estimativas. O respeito entre todos os envolvidos também é crucial.

Regras de Planejamento no XP

• O planejamento no XP é baseado em histórias de usuário escritas pelo cliente; liberações pequenas e frequentes são essenciais.

• As interações começam com planejamento onde os desenvolvedores estimam esforços necessários; isso se alinha com práticas do Scrum.

Gestão e Dinâmica da Equipe

• No XP, promove-se um ambiente de trabalho aberto e sustentável, com semanas limitadas a 40 horas sem horas extras permitidas.

• Reuniões diárias rápidas ajudam a monitorar o progresso e identificar problemas rapidamente.

Design e Prototipagem no XP

• O design dentro do XP busca simplicidade; utiliza-se metáforas para facilitar a compreensão entre desenvolvedores e gerentes sobre o produto final.

• Técnicas como cartões CRC (Classe e Responsabilidade dos Colaboradores), TDD (Desenvolvimento Orientado a Testes), refatoração e Domain Driven Design são utilizadas para melhorar o design dos objetos.

Minimização de Riscos com Spikes

• "Spikes" são protótipos funcionais criados para mitigar riscos associados a histórias de usuário complexas ou incertas.

Objetivos do XP e Refatoração

Refatoração no XP

• A refatoração é uma parte essencial do método XP, que se baseia no conceito de desenvolvimento orientado a testes (TDD). A refatoração ocorre após a criação dos testes unitários.

• O XP recomenda a definição de padrões de codificação desde o início do projeto para facilitar a manutenção do código. Isso garante que todos os desenvolvedores sigam as mesmas diretrizes.

Programação em Pares

• Estudos mostram que a programação em pares pode reduzir o tempo de desenvolvimento em até 88%, enquanto a taxa de erros diminui pela metade quando comparada ao trabalho individual.

• No XP, apenas um par integra o código por vez, promovendo integrações frequentes com testes automatizados para garantir qualidade contínua.

Integração Contínua

• O XP utiliza integração contínua para automatizar as integrações frequentes. Um servidor dedicado é configurado para executar testes automaticamente sempre que um novo requisito é comitado.

• O conceito de propriedade coletiva do código permite que qualquer membro da equipe altere o código, desde que todos os testes necessários sejam aprovados.

Testes no XP

Regras para Testes

• Todo código desenvolvido sob o XP deve ter testes unitários e passar por eles antes da liberação. Novos testes são criados sempre que um bug é encontrado.

• Os resultados dos testes são publicados frequentemente, garantindo transparência e acompanhamento das alterações realizadas no código.

Histórias de Usuário

Captura de Requisitos

• As histórias de usuário são fundamentais no planejamento e na liberação dentro do método ágil conhecido como XP. Elas ajudam a determinar requisitos e cenários para os testes de aceitação.

• Cada história representa um cenário específico dentro de um caso de uso mais amplo, permitindo uma abordagem focada nas necessidades reais dos usuários.

Diretrizes para Histórias

• O acrônimo INVEST é utilizado como diretriz para criar boas histórias: Independente, Negociável, Valiosa, Estimável, Pequena e Testável.

• As histórias devem descrever claramente os objetivos do usuário em relação ao sistema, destacando seu papel e valor esperado.

Template para Histórias de Usuário

Estrutura Proposta

• Um template sugerido por Mike Cohn ajuda na escrita das histórias: "Como [tipo de usuário], eu quero [objetivo] para que [valor]". Esse formato facilita a clareza durante as reuniões de planejamento.

Importância das Histórias de Usuário no Desenvolvimento Ágil

Casos de Uso e o Acrônimo INVESTE

• Bill Wake introduz o acrônimo INVESTE para guiar a escrita de histórias de usuário, enfatizando a importância da Independência entre elas.

• As histórias devem ser negociáveis, não funcionando como contratos rígidos, permitindo flexibilidade na definição dos requisitos.

• A história deve ter um objetivo claro e valor definido, com detalhes que podem ser explorados posteriormente conforme necessário.

Características das Histórias de Usuário

• As histórias precisam demonstrar valor para os clientes e stakeholders, sendo essenciais para a negociação eficaz.

• Devem ser estimáveis, apresentando detalhes suficientes para que o esforço necessário seja avaliado adequadamente.

• O tamanho das histórias deve ser adequado; recomenda-se que sejam pequenas o suficiente para serem completadas em uma iteração (não mais que duas semanas).

Estrutura e Testabilidade das Histórias

• As histórias podem começar em um nível alto de abstração (Epic), sendo detalhadas posteriormente conforme se aproxima do desenvolvimento.

• É crucial que as histórias sejam testáveis, com critérios de aceitação claros e testes automatizados sempre que possível.

Exemplo Prático de História de Usuário

• Um exemplo prático é: "Enquanto usuário registrado, eu quero poder pesquisar no catálogo online", destacando a necessidade do benefício desejado.

• Cartões são frequentemente usados nas reuniões para indexar essas histórias, podendo incluir layouts ou narrativas sobre fluxos.

Papel do Scrum Master e Product Owner

• Os testes de aceitação são fundamentais junto à definição pronta, ajudando a equipe a verificar se os requisitos foram atendidos corretamente durante as iterações.

• O método ágil prescreve papéis importantes como os "porcos" (envolvidos diretamente no projeto) e "galinhas" (stakeholders interessados mas não envolvidos diariamente).

Responsabilidades do Product Owner

• O Product Owner é responsável por gerenciar o backlog do produto e garantir o valor do trabalho desenvolvido pela equipe.

O Papel do Product Owner e da Equipe Scrum

Funções do Product Owner

• O Product Owner é responsável pelo retorno de investimento do projeto, priorizando itens no Product Backlog.

• Ele aceita os resultados do trabalho e deve garantir que as prioridades não atrapalhem o objetivo da equipe.

Características da Equipe Scrum

• A equipe Scrum é multifuncional e auto-organizável, idealmente composta por 5 a 9 pessoas.

• O time define o objetivo de cada Sprint, comprometendo-se a demonstrar os resultados ao final.

Papel do Scrum Master

• O Scrum Master gerencia interesses entre o Product Owner e a equipe, promovendo bem-estar e produtividade.

• Ele estimula comunicação e cooperação entre todos os membros da equipe, removendo impedimentos que afetam a produtividade.

Remoção de Impedimentos

• É responsabilidade do Scrum Master eliminar barreiras para que a equipe trabalhe focada nos objetivos da Sprint.

• Ele garante que os princípios e regras do Scrum sejam respeitados durante todo o processo.

Artefatos no Método Ágil

• Os principais artefatos incluem visão do produto, product backlog, plano de liberações, sprint backlog e lista de impedimentos.

Introdução ao Método Scrum

Artefatos e Ciclo de Vida do Projeto

• O método Scrum envolve a produção e monitoramento de artefatos simples durante o ciclo de vida do projeto.

• É importante entender conceitos fundamentais dentro do Scrum, como o "Time Box", que ajuda a equipe a se concentrar em objetivos sem perder tempo com tarefas desnecessárias.

Conceito de Time Box

• O "Time Box" é um pilar essencial do Scrum, permitindo que atividades sejam cronometradas para agregar valor rapidamente.

• Reuniões diárias têm um limite máximo de 15 minutos, enquanto reuniões de planejamento de Sprint são divididas em duas partes de 4 horas cada.

Impedimentos e Definição de Pronto

• Impedimentos são problemas enfrentados pela equipe que podem impedir o alcance dos objetivos da Sprint; devem ser reportados ao Scrum Master.

• A definição de "pronto" é crucial no Scrum; um item só é considerado pronto quando está potencialmente implantável.

Importância da Definição de Pronto

• No Scrum, funcionalidades não são consideradas prontas se estiverem apenas parcialmente concluídas; isso contrasta com abordagens tradicionais.

• A funcionalidade deve estar pronta para entrar em produção assim que o Product Owner decidir, baseado na definição acordada entre a equipe.

Exemplos da Definição de Pronto

• Exemplos incluem: análise completa da história do usuário, testes unitários realizados e documentação gerada.

• A definição deve ser visível para todos os membros da equipe para garantir entendimento claro sobre as expectativas durante a Sprint.

Foco em Objetivos no Método Scrum

• O método Scrum planeja, executa e reporta progresso baseado em objetivos claros, não em porcentagens ou tarefas isoladas.

Ciclo de Vida do Projeto no Scrum

• O ciclo inclui planejamento, execução e monitoramento contínuo utilizando uma abordagem ágil iterativa e incremental.

Reunião Inicial: Planejamento da Sprint

• A reunião inicial (Sprint Planning) tem como objetivo detalhar requisitos, priorizá-los e estimar esforços necessários.

Desenvolvimento Durante a Sprint

Ciclo de Vida do Sprint e Planejamento

Detalhamento do Product Backlog

• O processo de grooming é essencial para o detalhamento do Product Backlog antes da reunião de planejamento do Sprint, onde as funcionalidades desenvolvidas são apresentadas ao Product Owner.

• Funcionalidades aceitas pelo Product Owner resultam em um incremento de produto, que é considerado "potencialmente implantável", podendo ser colocado em produção imediatamente.

Reuniões no Ciclo do Sprint

• O ciclo se repete com a reunião de planejamento, seguida pela revisão e retrospectiva do Sprint, permitindo melhorias contínuas no processo.

• Sprints curtos são preferidos; idealmente, devem durar entre uma a quatro semanas para facilitar a aproximação com o cliente.

Iniciação do Projeto

• A primeira reunião de planejamento deve ser precedida por um Business Case ou documento visão que delineie funcionalidades e stakeholders principais.

• É crucial ter todos os envolvidos na criação do Product Backlog para identificar requisitos relevantes.

Estimativa e Priorização

• O objetivo final da reunião é ter um Product Backlog priorizado e estimado, permitindo que a equipe divida as tarefas durante o Sprint.

• Todas as histórias de usuário devem estar estimadas ao final da reunião, mesmo aquelas que não serão incluídas no Sprint atual.

Importância do Prod Backlog

• O plano de liberação é um artefato importante que fornece previsibilidade sobre quando determinadas funcionalidades serão entregues.

• O Prod Backlog contém características e requisitos essenciais; recomenda-se usar histórias de usuário como técnica principal para sua elaboração.

Responsabilidades no Prod Backlog

Reunião de Planejamento do Sprint no Scrum

Importância da Colaboração

• A colaboração intensa entre todos os membros do time de desenvolvimento é essencial para a criação de um Product Backlog adequado durante a reunião de planejamento do Sprint.

Estrutura da Reunião de Planejamento

• A reunião é dividida em duas partes: a primeira foca na criação do Product Backlog priorizado, enquanto a segunda parte define o Sprint Backlog.

• O objetivo principal é planejar quais itens serão finalizados dentro do período do Sprint, que pode ser, por exemplo, 30 dias.

Detalhamento dos Artefatos

• Na primeira parte, o Scrum Master e o Product Owner detalham o Product Backlog, que pode ser representado em documentos ou planilhas com todas as funcionalidades necessárias.

• Na segunda parte, eles se reúnem para planejar o Sprint baseado no Product Backlog atualizado. O foco deve estar na ordem das tarefas e não nos prazos.

Retorno sobre Investimento

• Durante a primeira parte da reunião, é crucial discutir o retorno sobre investimento (ROI), onde o Product Owner decide quais itens agregam mais valor ao software.

Estimativas e Tarefas

• Na segunda parte da reunião, os desenvolvedores estimam os esforços necessários para implementar os itens selecionados do Product Backlog usando técnicas como Planning Poker.

• É importante que cada item seja potencialmente implantável ao final do Sprint, resolvendo problemas reais dos stakeholders.

Técnicas de Estimativa

• Para evitar influências nas estimativas individuais dentro do grupo, utiliza-se a técnica Planning Poker. Cada membro recebe cartas com números que representam suas estimativas.

Estimativas em Scrum: Técnicas e Práticas

Importância da Granularidade nas Estimativas

• O uso de números como 13 e 21 não é recomendado, pois aumenta a dificuldade no planejamento dos sprints. Objetivos menores permitem uma gestão melhor e estimativas mais precisas.

• Itens que não serão trabalhados no sprint atual são planejados para o futuro, utilizando cartas maiores conhecidas como temas e epics, com estimativas variando entre 20 a 100.

Processo de Estimativa com Planning Poker

• O Product Owner não deve estar presente durante as estimativas para evitar influenciar o time de desenvolvimento. Cada membro do time utiliza suas próprias cartas para estimar o esforço necessário.

• Os membros do time apresentam suas cartas simultaneamente, discutindo os motivos por trás das estimativas apresentadas. Isso gera um ciclo de reflexão e reavaliação até que se chegue a um consenso.

Exemplos Práticos de Estimativa

• Um exemplo prático é a história do usuário "pesquisar catálogo", que foi estimada pelo time com um esforço de tamanho 3. A granularidade ideal é uma história de usuário conforme se desce na lista do backlog.

• À medida que se avança no backlog, a granularidade aumenta; histórias mais complexas podem ser descritas em formato de caso de uso, enquanto histórias simples seguem o formato padrão.

Priorização e Planejamento Futuro

• Histórias que não serão implementadas imediatamente devem ser priorizadas com cartas maiores. A equipe pode decidir quais histórias implementar baseando-se na capacidade percebida para o sprint atual.

• As histórias devem ser detalhadas apenas quando forem priorizadas pelo Product Owner, evitando sobrecarga desnecessária no backlog.

Conceito de Estimativa Relativa

• A técnica de estimativa relativa permite comparar esforços entre diferentes histórias. Por exemplo, se uma história tem esforço 3 e outra 1, isso indica que a primeira requer três vezes mais esforço.

• Investir muito tempo em detalhes pode levar à diminuição da acurácia das estimativas após certo ponto. É importante encontrar um equilíbrio entre detalhamento e eficiência nas estimativas.

Conclusão sobre Planejamento Ágil

Desenvolvimento Ágil e Métricas no Scrum

Importância da Flexibilidade no Desenvolvimento de Software

• O desenvolvimento de software é dinâmico, e tentar detalhar todos os itens do Product Backlog (PB) no início pode ser um desperdício de tempo, pois muitos itens mudam ao longo do projeto.

Conceito de Velocidade no Scrum

• No Scrum, utilizamos métricas como a "velocidade" para garantir prazos a partir de uma lista de funcionalidades. A consistência da equipe e baixa rotatividade são essenciais para otimizar essas métricas.

Analogias com Futebol

• A analogia com futebol ilustra que equipes que trabalham juntas por mais tempo desenvolvem um melhor ritmo e compreensão mútua, o que se traduz em maior produtividade na equipe Scrum.

Rotatividade e Multifuncionalidade da Equipe

• Embora a rotatividade possa ocorrer entre diferentes partes do sistema, uma equipe multifuncional permite que membros assumam diversas tarefas conforme sua especialização ou conforto.

Estimativas Relativas em vez de Horas

• As estimativas devem ser relativas (como pontos), não atreladas a unidades de tempo. Utilizamos cartas de Fibonacci para medir esforço relativo, evitando estimativas em horas.

Performance Esperada Dentro do Sprint

• A velocidade representa a performance esperada dentro do Sprint, considerando restrições ambientais e riscos. É calculada dividindo o esforço pelo tempo necessário.

Medindo Esforço com Pontos

• Para projetos de software, usamos pontos para medir o esforço do PB. Esses pontos representam tamanho funcional e complexidade técnica dos itens.

Planejamento das Sprints

• Durante as primeiras Sprints, a incerteza sobre a produtividade é alta; portanto, perguntamos à equipe o que acreditam conseguir entregar até o final da Sprint.

Exemplo Prático: Previsão Inicial do Product Backlog

• Se a velocidade estimada for 8 pontos por Sprint e houver 37 pontos totais no PB, podemos prever aproximadamente 5 Sprints para completar as histórias necessárias.

Plano de Liberação

Planejamento do Sprint e Criação do Sprint Backlog

O que é o Sprint Backlog?

• O Sprint backlog é um artefato produzido na segunda parte da reunião de planejamento do Sprint, refletindo as histórias de usuário priorizadas e estimadas.

• Durante a criação do Sprint backlog, o time de desenvolvimento quebra as histórias em tarefas menores, frequentemente mensuradas em horas.

Estimativas no Scrum

• No Scrum, os itens do product backlog são estimados em Pontos de História, enquanto as tarefas resultantes no Sprint backlog são mensuradas em horas.

• A gestão de projetos no Scrum envolve planejamento, execução, controle e avaliação. Após o planejamento, segue-se a execução e ao final do Sprint ocorre a avaliação.

Quebra das Tarefas

• Recomenda-se que cada tarefa não ultrapasse 16 horas para facilitar o gerenciamento e obter feedback mais rápido sobre o progresso.

• A quebra das histórias em tarefas menores ajuda a identificar problemas precocemente e facilita o trabalho em equipe.

Importância da Comunicação

• É crucial que o time consulte o Scrum Master e o Product Owner durante a quebra das tarefas para esclarecer dúvidas.

• O detalhamento adequado dos itens do product backlog é necessário para garantir que estejam prontos para serem trabalhados durante o Sprint.

Exemplo Prático

• Um exemplo prático mostra como uma história de usuário pode ser subdividida em várias tarefas específicas (ex: criar página de busca).

• A definição de "pronto" deve ser compartilhada por todos os membros da equipe para orientar a quebra das tarefas corretamente.

Início do Sprint

Ciclo Iterativo no Desenvolvimento

• Após a reunião de planejamento, inicia-se o ciclo real do Sprint com desenvolvimento, testes e criação de testes automatizados.

• Cada iteração (Sprint) tem um período fixo onde algo valioso deve ser demonstrado aos usuários ao final.

Duração dos Sprints

• Sugere-se um máximo de 30 dias para um Sprint; empresas podem ter Sprints mais curtos (até um dia), mas isso pode complicar agendar reuniões necessárias.

• Para iniciantes, recomenda-se Sprints entre duas a três semanas para entender melhor os tempos necessários para desenvolver valor.

Auto-organização da Equipe

Implementação do Scrum e Gestão de Impedimentos

Seleção e Transformação de Tarefas

• As tarefas são selecionadas e transformadas em realidade conforme a definição de "pronto" compartilhada por todos.

• Em caso de impedimentos, recomenda-se o uso de uma coluna no Sprint backlog para listá-los, sendo responsabilidade do Scrum Master resolver esses problemas com apoio do Product Owner.

Estrutura dos Sprints

• O modelo Scrum é baseado em ciclos interativos chamados Sprints, que devem ter duração máxima de 30 dias.

• Cada Sprint começa com uma reunião de planejamento onde os itens do Product Backlog são priorizados e detalhados.

Planejamento e Execução

• Durante o planejamento, o time cria estimativas dos itens do Product Backlog e divide as histórias em tarefas menores.

• O último dia do Sprint é dividido entre a apresentação das funcionalidades ao Product Owner e uma retrospectiva para avaliar o que funcionou ou não.

Práticas Recomendadas no Desenvolvimento Ágil

Liberdade nas Técnicas de Desenvolvimento

• Embora o Scrum defina um ciclo de vida para gestão, ele não especifica técnicas ou práticas de desenvolvimento; as equipes têm liberdade nesse aspecto.

Integração Contínua e Testes Automatizados

• É recomendado usar práticas como integração contínua, independentemente da ferramenta escolhida (ex: Jenkins, Cruise Control).

• Testes automatizados são essenciais tanto para testes unitários quanto para testes funcionais durante o desenvolvimento.

Ferramentas Visuais no Scrum

Gráfico Burn Down

• O gráfico Burn Down é utilizado pelo time para reportar o andamento do projeto, mostrando a evolução das horas restantes versus a duração do Sprint.

Interpretação do Gráfico

• A interseção entre as horas trabalhadas e a linha azul indica se a equipe está acima ou abaixo da velocidade planejada. Se estiver acima, pode haver risco de não cumprir prazos.

Gráfico Release Burn Down

Sprint e Reuniões no Scrum

Visão de Longo Prazo e Sprints

• A abordagem do Scrum envolve uma visão a longo prazo, com 525 pontos de história a serem cumpridos em 10 a 15 sprints. O foco do Sprint Burn é nas horas dentro de um sprint específico, destacando diferentes níveis de granularidade.

• O término do Sprint não depende da conclusão das funcionalidades; mesmo que itens do backlog não estejam prontos, as datas devem ser respeitadas. Um Sprint fixo é crucial para medir a produtividade real da equipe.

Importância das Funcionalidades e Datas

• É preferível perder funcionalidades do que comprometer as datas, um conceito central no Scrum. As reuniões diárias são essenciais para manter todos os envolvidos informados sobre o progresso.

• As reuniões diárias têm duração máxima de 15 minutos e envolvem o Scrum Master, a equipe e interessados no projeto. Cada membro deve responder três perguntas básicas sobre seu trabalho.

Estrutura das Reuniões Diárias

• A reunião diária deve ser cronometrada; durações excessivas comprometem a produtividade da equipe. Os membros devem relatar o que fizeram, o que farão e se enfrentam impedimentos.

• Realizar as reuniões diariamente no mesmo horário promove organização e comprometimento entre os participantes.

Revisão do Sprint

• No último dia do Sprint ocorre a revisão, onde o time apresenta software funcional ao Product Owner. Essa reunião é fundamental para demonstrar entregas potencialmente implantáveis.

• A entrega de apenas documentos ao final do Sprint é inaceitável na filosofia Scrum; espera-se sempre um produto funcional.

Avaliação da Velocidade da Equipe

• Se menos pontos forem entregues do que o planejado (por exemplo, 11 em vez de 12), isso pode indicar uma velocidade menor que a prevista pela equipe.

• O backlog deve ser constantemente atualizado durante o projeto, exigindo replanejamento frequente conforme novas informações surgem.

Retrospectiva do Sprint

• A reunião de retrospectiva é crucial para avaliar acertos e erros durante o Sprint. Foca na melhoria contínua dos processos sem rigidez.

• Durante essa reunião, discutem-se lições aprendidas e ajustes necessários para planejar novos Sprints eficazmente.

Estrutura das Reuniões de Retrospectiva

Métodos Ágeis: Reflexões e Melhorias

Características do Scrum e Desafios Enfrentados

• O uso do Scrum trouxe maior visibilidade na gestão, mas as reuniões de Scrum foram consideradas longas e precisam ser revisadas para otimizar o tempo.

• Os testes unitários não atenderam às expectativas; a equipe deve refletir sobre melhorias durante o último dia do Sprint, após a entrega das funcionalidades ao cliente.

Importância da Transparência e Adaptação Contínua

• A reunião tem como objetivo promover transparência interna no time; é crucial que o Scrum avalie os pontos apresentados e forneça recursos para mudanças necessárias.

• A adaptação contínua é um fundamento importante em projetos críticos, sendo essencial valorizar as lições aprendidas durante o processo.

Ciclo de Vida do Sprint

• Após a reunião de retrospectiva, haverá uma nova reunião de planejamento do Sprint para priorizar itens do backlog, detalhar e estimar tarefas.

• O ciclo continua com práticas complementares entre Scrum e XP (Extreme Programming), destacando conceitos como retrospectivas, reuniões diárias e Burn Down Chart.

Integração entre Métodos Ágeis

• Práticas do XP se encaixam bem nas regras do Scrum; ambos compartilham princípios fundamentais que favorecem a colaboração e eficiência nas equipes.

• Existem diversos outros métodos ágeis além de Scrum e XP que também são utilizados no mercado, todos compartilhando características comuns.

Outros Métodos Ágeis Relevantes

• Destacam-se métodos como XPM (versão adaptada do XP), APM, FDD (Feature Driven Development), entre outros que podem ser explorados por quem deseja aprofundar-se em agilidade.

• É importante notar que muitos dos princípios discutidos estão presentes em outros métodos ágeis não listados aqui.

Conclusão da Apresentação

• A apresentação foi elaborada atendendo à solicitação de um orientador acadêmico; está disponível para qualquer interessado em pesquisa sobre métodos ágeis.