Carga horária no certificado: 180 horas

Nosso Curso Online de Gestão Ágil Scrum já começou!

Quais São os Elementos Essenciais do Scrum, Papéis e como Eles São Implementados na Prática para Gerenciar Projetos de Forma Ágil?

Papéis no Scrum:

O time Scrum é composto por 3 componentes:

1. Product Owner: O Product Owner (PO) é como o “guardião” do produto. Sua responsabilidade é definir o que deve ser adicionado ou melhorado no produto ou serviço do cliente de forma que atenda todas as necessidades dele. Exemplo: Se o projeto é desenvolver novas funcionalidades em um aplicativo, o Product Owner coleta feedback dos usuários, faz pesquisas de mercado e trabalha em estreita colaboração com a equipe de desenvolvimento para priorizar as funcionalidades que serão adicionadas à próxima versão do aplicativo. Ele se certifica de que a equipe está construindo as características certas com base na prioridade, relevância e importância para o cliente.

2. Scrum Master: O Scrum Master (SM) é como um “facilitador” na empresa. Ele é o “guardião” da metodologia Scrum. Se algo está “fugindo” dos princípios ágeis, o SM intervém imediatamente. Ele também remove obstáculos que possam atrapalhar o progresso, por exemplo, quando o time depende de informações ou recursos de outra equipe ou departamento que não estão sendo entregues conforme o esperado; a ausência de recursos necessários, como hardware, software ou pessoal, pode atrasar o progresso do desenvolvimento; desafios técnicos significativos que exigem mais tempo para resolução do que o previsto; conflitos não resolvidos dentro da equipe podem prejudicar a colaboração e o progresso do trabalho; processos internos complicados ou excessivamente burocráticos podem atrasar o time, etc.

3. Time de Desenvolvimento: O Time de Desenvolvimento é o grupo de pessoas que realmente constrói o produto. Eles são como os “construtores” das funcionalidades ou os “executores” das tarefas. O Time de Desenvolvimento trabalha juntamente com o Product Owner para entender as necessidades do cliente e criar as funcionalidades solicitadas. Se num primeiro momento o PO decide O QUE deve ser feito, o time de desenvolvimento define COMO será feito. Eles dividem o objetivo geral em tarefas menores. Durante a Sprint, eles trabalham colaborativamente para entregar as funcionalidades conforme planejado. Já iremos falar sobre a Sprint, a seguir!

Esses papéis trabalham em conjunto para garantir que o produto seja desenvolvido de forma eficiente, atendendo às necessidades dos clientes e seguindo as práticas do Scrum. Cada um desempenha um papel importante para o sucesso do projeto de desenvolvimento de software.

 

Os Elementos do Scrum

Grave bem os itens abaixo! Eles são a essência do Scrum.

Vou explicar cada um dos principais elementos que compõem o Scrum de forma simples:

1. Sprint: Uma Sprint é um período de tempo fixo e curto, geralmente de 2 a 4 semanas, durante o qual a equipe de desenvolvimento trabalha em um conjunto de tarefas definidas. É como um “mini projeto” dentro do projeto maior. Numa empresa de desenvolvimento de software, por exemplo, uma Sprint pode ser um período de 2 semanas em que a equipe se concentra em criar uma nova funcionalidade para um aplicativo móvel, que pode ser a implementação de um sistema de pagamento online, módulos de integração com rede social, desenvolver um sistema de notificações push que permite enviar mensagens personalizadas aos usuários com base em seus interesses e comportamento dentro do aplicativo, etc. Então, a Sprint é uma janela de tempo em que o time deve trabalhar para cumprir o “objetivo da vez”.

2. Backlog do Produto (Product Backlog): O Backlog do Produto é uma lista priorizada de todas as funcionalidades, melhorias e correções que podem ser adicionadas ao aplicativo móvel. É como uma lista de desejos ou requisitos que o cliente ou o proprietário do produto deseja para o aplicativo. É criada pelo PO. Por exemplo, o Backlog do Produto pode incluir itens como “Adicionar funcionalidade de pesquisa,” “Melhorar a segurança da conta do usuário” e “Criar uma opção de pagamento em dinheiro.”

3. Itens do Backlog da Sprint (Backlog Sprint): São as tarefas específicas que a equipe seleciona para trabalhar durante a Sprint. Essas tarefas são retiradas da “Backlog do Produto” e são priorizadas com base na importância para o cliente. Atenção: perceba que aqui as tarefas definidas pelo PO no Backlog do Produto são transformadas (ou quebradas) em tarefas menores pelo Time de Desenvolvedores. Por exemplo, para o item “Adicionar funcionalidade de pesquisa” do Backlog do Produto, o Time de Desenvolvimento poderia dividir essa funcionalidade em várias tarefas menores, como projetar a interface de pesquisa (onde um designer criará o layout e a aparência da caixa de pesquisa na interface do aplicativo); Desenvolver a lógica de pesquisa (onde os desenvolvedores precisarão escrever o código que permite que os usuários insiram consultas de pesquisa e recebam resultados relevantes); realizar testes de usuários (após implementar a funcionalidade, é importante conduzir testes com usuários reais para garantir que a pesquisa funcione como esperado e seja fácil de usar), etc.

4. Reunião de Planejamento da Sprint (Sprint Planning): É uma reunião no início de cada Sprint, onde a equipe decide quais tarefas serão trabalhadas e como serão divididas em etapas menores. Isso ajuda a equipe a entender o que precisa ser feito e como. Aqui, todo o time Scrum se reúne para resolver essas questões. Normalmente dura até 8 horas, dependendo do período da Sprint. Normalmente, para cada semana de Sprint leva-se 2 horas de reunião de planejamento.

5. Quadro Scrum: É um quadro visual que ajuda a equipe a acompanhar o progresso das tarefas durante a Sprint. Ele possui colunas representando os estados das tarefas, como “A fazer,” “Em andamento” e “Concluído”. A ideia aqui é simples. Você insere a lista de atividades no campo “A Fazer”. No campo “Em Andamento” ficam as tarefas que já iniciaram mas ainda estão em progresso. No campo “Concluído” vão as tarefas que já foram finalizadas, testadas e aprovadas pelo PO, por exemplo. O próprio time Scrum irá “negociar” entre eles o que significa “Concluído”, ok?!

6. Reunião Diária (Daily Scrum ou apenas Daily): Uma reunião rápida e diária, geralmente com 15 minutos de duração, onde a equipe compartilha o que fizeram no dia anterior, o que farão no dia atual e se enfrentaram algum obstáculo. Isso mantém todos atualizados e ajuda a resolver problemas. Caso haja obstáculos (ou impedimentos, como preferir chamar), o Scrum Master é o responsável por solucionar o problema, exceto quando o obstáculo é de nível técnico, onde o próprio Time de Desenvolvedores podem resolver entre eles ali em poucos minutos.

7. Revisão da Sprint (Review): Após o término da Sprint, a equipe realiza uma reunião de revisão para mostrar o trabalho concluído ao cliente ou ao interessado. É uma oportunidade para receber feedback e ajustar as próximas prioridades. É talvez a etapa mais importante, pois você tem o verdadeiro feedback do mercado, e não mais só do time Scrum. Isso abre caminho principalmente para novos entendimentos sobre o projeto e sugestões de novas funcionalidades.

8. Retrospectiva da Sprint (Retrospective ou apenas Retro): Logo após a revisão, a equipe realiza uma retrospectiva para avaliar o próprio processo interno do time. Discute o que funcionou bem, o que pode ser melhorado e como fazer essas melhorias na próxima Sprint. Aqui, temos o “elefante branco na sala”, onde fazemos uma avaliação do time, e aqui podem haver conflitos, principalmente se a Sprint tiver atrasos por “culpa de alguém”. Enfim, é o momento de lavagem da roupa suja. É papel do Scrum Master aplicar técnicas para conduzir o bom andamento da Retrospectiva.

Esses são os principais elementos do Scrum. Perceba que esses elementos existem para permitir que as equipes entreguem valor de forma mais eficiente e estejam sempre abertas a melhorias contínuas no processo de trabalho, afinal, quando falamos em Scrum, estamos falando de processos iterativos e incrementais. Mas, o que é isso?!

 

Processos Iterativos e Incrementais no Scrum

A gestão ágil Scrum é uma abordagem de gerenciamento de projetos que se baseia em um processo iterativo e incremental.

O processo iterativo significa que, em vez de planejar todo o projeto de uma só vez e seguir esse plano rigidamente, o Scrum divide o projeto em pequenas partes chamadas “iterações” ou “sprints”. Então, sim, iterações são as Sprints que abordamos anteriormente.

Cada iteração é um ciclo de trabalho com um tempo definido, geralmente de duas a quatro semanas, e a equipe trabalha intensamente para concluir essas tarefas dentro do prazo da iteração.

Após cada iteração, a equipe revisa o que foi feito, coleta feedback e ajusta o plano para a próxima iteração. Isso permite que a equipe se adapte às mudanças nas necessidades do projeto ou nos requisitos do cliente de forma flexível.

O processo incremental significa que, a cada iteração, o projeto fica um pouco mais completo. Cada ciclo de trabalho adiciona funcionalidades ou melhorias ao produto, aumentando gradualmente seu valor e qualidade. Por conta disso, chamamos cada nova entrega de “incremento”.

O que tudo isso significa para a empresa é que ela pode responder mais rapidamente às mudanças nas demandas do mercado e às necessidades dos clientes. Ela pode entregar partes do produto de forma mais frequente e obter feedback mais cedo, o que ajuda a garantir que o produto final atenda às expectativas.

Em outras palavras, em vez de seguir um plano rígido e detalhado, como é a abordagem tradicional (também chamada de “cascata” ou “preditiva”), a gestão ágil permite que a equipe trabalhe de forma mais colaborativa e flexível, respondendo rapidamente às mudanças e oportunidades que surgem.

Além disso, a abordagem ágil Scrum promove a colaboração e a comunicação eficaz dentro da equipe, o que leva a um ambiente de trabalho mais produtivo e engajado. Isso também ajuda a reduzir os riscos associados a projetos complexos, uma vez que as falhas podem ser identificadas e corrigidas mais cedo no processo.

Percebeu como a gestão ágil Scrum permite que as empresas se adaptem às mudanças de forma ágil, entreguem produtos de maior qualidade e melhorem a satisfação do cliente? Ela faz tudo isso enquanto mantêm uma equipe de trabalho altamente colaborativa e eficiente. Esse talvez seja o maior motivo da ascensão de gestão ágil em empresas.

Vamos falar mais um pouquinho de Gestão Ágil antes de nos aprofundarmos mais no Scrum? Essa base teórica será importantíssima mais para frente.

 

Como a Gestão Ágil é Aplicada na Prática e como Ela Contribui para a Flexibilidade e Eficiência em Projetos e Equipes?

A Gestão Ágil na Prática é uma abordagem de gestão de projetos e processos que se concentra na flexibilidade, colaboração e entrega contínua de valor. Ela se baseia em princípios e valores que promovem a adaptação às mudanças, a comunicação eficaz e a participação ativa das equipes.

Vou explicar os principais conceitos da Gestão Ágil com exemplos para tornar mais didático:

1. Equipes Multidisciplinares: Na Gestão Ágil, as equipes são compostas por membros com diferentes habilidades e conhecimentos para que possam abordar problemas de forma holística. Por exemplo, em uma equipe de desenvolvimento de software, pode haver programadores, designers e testadores trabalhando juntos.

2. Iterações (Sprints): A Gestão Ágil divide o trabalho em iterações curtas e focadas, geralmente chamadas de “sprints”. Você já sabe disso! Então, sprint é uma “janela de tempo” ou “Timebox” de trabalho. Por exemplo, em uma equipe de marketing, eles podem ter uma sprint de duas semanas para criar e lançar uma campanha publicitária.

3. Priorização (Backlog): As tarefas são organizadas em um backlog, isto é, uma lista de prioridades. A equipe seleciona as tarefas mais importantes e factíveis para serem realizadas durante uma sprint. Por exemplo, em uma equipe de desenvolvimento de produto, o backlog pode conter recursos como “adicionar funcionalidade de pesquisa”, “criar a interface do site” e “corrigir bugs críticos”.

4. Feedback Contínuo: A Gestão Ágil enfatiza a obtenção de feedback constante dos stakeholders (interessados) e dos clientes. Isso ajuda a ajustar o trabalho conforme necessário. Por exemplo, em uma equipe de design de produto, eles podem mostrar protótipos para os usuários e ajustar o design com base no feedback recebido.

5. Mudança de Requisitos: A abordagem ágil reconhece que os requisitos podem mudar ao longo do tempo. Em vez de tentar prever tudo no início do projeto, a equipe está preparada para se adaptar às mudanças à medida que surgem. Por exemplo, em um projeto de desenvolvimento de software, se os usuários descobrem que precisam de uma nova funcionalidade, a equipe pode ajustar o backlog para incluí-la em sprints futuros.

6. Transparência e Comunicação: A Gestão Ágil promove uma comunicação aberta e transparente dentro da equipe e com os stakeholders. Isso ajuda a evitar mal-entendidos e a manter todos informados sobre o progresso e os desafios. Por exemplo, em uma equipe de gerenciamento de projetos, eles podem realizar reuniões diárias curtas (reuniões de stand-up) para compartilhar atualizações sobre o trabalho em andamento.

7. Melhoria Contínua: A Gestão Ágil incentiva a reflexão constante e a busca por melhorias. Após cada sprint, a equipe realiza uma retrospectiva para identificar o que funcionou bem e o que pode ser aprimorado. Isso ajuda a equipe a se tornar mais eficiente e eficaz ao longo do tempo.

E em que tipos de empresas a Gestão Ágil se Aplica? A Gestão Ágil é amplamente aplicada em áreas como desenvolvimento de software, marketing, gerenciamento de projetos e muitas outras, permitindo que as equipes alcancem resultados melhores e mais alinhados com as necessidades dos clientes e stakeholders.

 

Quais São os Principais Frameworks da Metodologia Ágil e como Eles Diferem em Abordagens e Aplicações?

Dentro da metodologia ágil existem vários frameworks, que são conjuntos de práticas e diretrizes específicas para ajudar as equipes a implementar os princípios ágeis de forma mais estruturada e eficaz. O Kanban é uma delas.

Vou explicar brevemente alguns dos frameworks ágeis mais populares:

1. Scrum: Concentra-se na gestão de projetos e no desenvolvimento de produtos, usando sprints, reuniões diárias e papéis bem definidos, como Scrum Master e Product Owner.

2. Kanban: Como você já aprendeu, é um framework visual que se concentra na gestão do fluxo de trabalho, usando quadros Kanban para visualizar as tarefas em diferentes etapas do processo.

3. Lean: Baseia-se em princípios de redução de desperdícios e melhoria contínua, visando entregar valor ao cliente de forma eficiente.

4. XP (Extreme Programming): Foca na qualidade do software, promovendo práticas como desenvolvimento orientado a testes, integração contínua e programação em par.

5. Crystal: Oferece várias abordagens leves (Crystal Clear, Crystal Yellow, entre outras) adaptáveis a diferentes tipos de projetos e equipes.

6. Dynamic Systems Development Method (DSDM): É um framework ágil voltado para projetos de desenvolvimento de software, com ênfase na entrega de produtos de alta qualidade no prazo e dentro do orçamento.

7. Feature-Driven Development (FDD): Divide o desenvolvimento de software em pequenas funcionalidades e se concentra em projetar, construir e inspecionar essas funcionalidades de forma iterativa.

8. SAFe (Scaled Agile Framework): É um framework para a escala de práticas ágeis em organizações maiores, com estruturas para coordenar equipes e programas ágeis em larga escala.

9. Nexus: É um framework para escalar o Scrum, projetado para ajudar várias equipes Scrum a trabalhar em conjunto em projetos maiores.

10. Less (Large-Scale Scrum): É uma abordagem para escalar o Scrum em grandes organizações, mantendo a simplicidade e a agilidade do Scrum.

11. Disciplined Agile Delivery (DAD): É um framework que incorpora conceitos de várias metodologias ágeis e oferece orientações para equipes e organizações escolherem as práticas adequadas ao seu contexto.

12. Holacracy: Embora não seja estritamente um framework ágil, é uma abordagem de governança organizacional que enfatiza a distribuição de autoridade e responsabilidade, promovendo uma estrutura organizacional mais flexível e adaptável.

Estes são apenas alguns dos frameworks ágeis disponíveis, cada um com suas próprias características e abordagens específicas. A escolha do framework adequado depende das necessidades da equipe e do contexto do projeto.

 

Quais são os 4 Valores do Manifesto Ágil? 

O manifesto ágil é constituído por quatro valores fundamentais e 12 princípios de apoio que orientam a abordagem ágil no desenvolvimento de software. Vamos começar falando aqui pelos valores.

Cada metodologia ágil que vimos acima implementa os quatro valores de maneira única, mas eles estão sempre presentes para guiar o desenvolvimento e a entrega de software funcional e de alta qualidade. Vamos conhecê-los:

1. Priorizar indivíduos e interações em vez de processos e ferramentas: O primeiro valor do manifesto ágil enfatiza a importância da comunicação e colaboração entre as pessoas envolvidas no projeto. Valoriza-se mais as contribuições das pessoas do que a rigidez dos processos ou a dependência de ferramentas. Até porque todo trabalho é feito por pessoas para pessoas venderem para outras pessoas (feito por times de desenvolvimento para clientes vendem para seus próprios clientes). As ferramentas são apenas um meio para o desenvolvimento!

2. Focar em software em funcionamento em vez de documentação extensa: Historicamente, muito tempo era gasto na elaboração de documentação detalhada durante o desenvolvimento. Isso resultava em atrasos significativos. No entanto, o método ágil não elimina a documentação, mas a torna mais ágil e orientada para a ação. Documentos como histórias de usuário são suficientes para orientar os desenvolvedores, permitindo que eles comecem a trabalhar sem a sobrecarga de detalhes excessivos. Menos é mais!

3. Promover a colaboração contínua com o cliente em vez de negociação de contratos: Colaboração e negociação são abordadas de maneira diferente. Enquanto a negociação geralmente envolve acordos contratuais rígidos, a colaboração significa que o cliente está envolvido em todas as fases do desenvolvimento. O cliente é um membro ativo da equipe e participa de reuniões como as revisões (reviews), garantindo que o produto esteja atendendo às necessidades de seus negócios.

4. Adaptar-se a mudanças em vez de seguir um plano fixo: Na abordagem tradicional, as mudanças eram consideradas dispendiosas e a intenção era seguir planos detalhados. No entanto, o método ágil reconhece que as mudanças são inevitáveis e as abraça. Prioridades podem ser ajustadas a cada iteração, e novos recursos podem ser incorporados. A visão ágil é que as mudanças sempre podem melhorar o projeto e agregar valor. As metodologias ágeis permitem que a equipe adapte o processo conforme necessário.

 

Quais são os 12 Princípios do Manifesto Ágil? 

Além dos 4 valores que falamos anteriormente, também existem 12 princípios.

Os 12 princípios do manifesto ágil são os alicerces que orientam as diversas metodologias inclusas no movimento ágil. Eles delineiam uma cultura que acolhe mudanças e coloca o cliente como a peça central do processo de desenvolvimento. O objetivo é alinhar o desenvolvimento de software às necessidades do negócio.

Os 12 princípios do desenvolvimento ágil compreendem:

1. Satisfação do cliente através de entregas contínuas e antecipadas de software: Clientes se sentem mais satisfeitos quando recebem entregas regulares de software funcional, em oposição a longos intervalos entre versões.

2. Acomodação de mudanças nos requisitos durante todo o processo de desenvolvimento: A capacidade de se adaptar a alterações nos requisitos ou solicitações de recursos sem causar atrasos significativos.

3. Entrega frequente de software funcional: O Scrum abraça esse princípio por meio de iterações regulares, garantindo entregas periódicas de software em funcionamento.

4. Colaboração entre partes interessadas do negócio e desenvolvedores durante todo o projeto: Melhores decisões são tomadas quando as equipes técnicas e comerciais estão alinhadas.

5. Apoio, confiança e motivação das pessoas envolvidas: Equipes motivadas têm mais probabilidade de fornecer seu melhor trabalho.

6. Possibilidade de interações presenciais: A comunicação é mais eficaz quando as equipes de desenvolvimento compartilham um local de trabalho.

7. Software funcional como principal medida de progresso: Avaliar o progresso com base na entrega de software funcional ao cliente é fundamental.

8. Processos ágeis para manter um ritmo de desenvolvimento consistente: Estabelecer uma velocidade de desenvolvimento repetível e sustentável é crucial.

9. Ênfase em detalhes técnicos e design para aumentar a agilidade: Habilidades e um bom design são essenciais para manter um ritmo constante e melhorar continuamente o produto.

10. Simplicidade: Desenvolva apenas o necessário para cumprir as necessidades atuais.

11. Equipes auto-organizáveis produzem arquiteturas, requisitos e designs excelentes: Membros de equipe capacitados e motivados, com autonomia para tomar decisões, são a chave para o sucesso.

12. Reflexões periódicas para aumentar a eficácia: O autoaperfeiçoamento, a melhoria de processos, o desenvolvimento de habilidades e técnicas contribuem para uma equipe mais eficiente.

A intenção subjacente ao método ágil é alinhar o desenvolvimento de software com as necessidades de negócios. O sucesso dessa abordagem é notável, uma vez que os projetos ágeis priorizam o cliente e incentivam sua participação ativa.

Como resultado, o método ágil se disseminou amplamente na indústria de software, tornando-se uma abordagem essencial para o desenvolvimento de software em diversos setores.

 

Quais são os Pilares, Artefatos e Cerimônias no Scrum?

Voltando ao Scrum agora! O Scrum é um framework (“linha de trabalho”) ágil de gerenciamento de projetos que fornece uma estrutura para a entrega contínua de produtos de alta qualidade.

Já vimos sobre os papéis e elementos do Scrum, então agora vai ficar bem fácil de você entender e gravar os pilares, artefatos e cerimônias. Vamos lá!

 

Os 3 Pilares Scrum

O Scrum é baseado em três pilares: transparência, inspeção e adaptação. 

1. Transparência: refere-se à visibilidade total do trabalho, dos processos e dos problemas dentro da equipe. Aqui, todo conhecimento adquirido pelo time deve ser compartilhado com o próprio time. No português claro, ninguém deve esconder nada de ninguém, seja uma ferramenta nova no mercado que facilitou o trabalho ou qualquer coisa do tipo. Todos devem ter acesso às informações e melhores ferramentas!

2. Inspeção: envolve a avaliação constante do progresso e da qualidade do trabalho realizado, bem como a identificação de obstáculos. A inspeção é principalmente vista na reunião diária (daily).

3. Adaptação: implica na capacidade de ajustar e melhorar continuamente com base nas informações obtidas através da inspeção, buscando aprimorar o desempenho e atender às mudanças nas necessidades do cliente e do projeto. A adaptação é percebida principalmente na revisão (review), onde há o feedback do mercado (cliente e stakeholders) e na retrospectiva (retro), onde o time se autoavalia.

Esses três pilares trabalham em conjunto para promover uma abordagem ágil que seja responsiva, eficaz e centrada no cliente.

Para atingir esses pilares, o Scrum utiliza artefatos e cerimônias.

 

Os 3 Artefatos no Scrum

1. Product Backlog. É uma lista de itens que descrevem as funcionalidades, requisitos e melhorias que precisam ser entregues para atender às necessidades do cliente. O Product Backlog é gerenciado pelo Product Owner (PO), lembra?!.

2. Sprint Backlog. É uma lista de tarefas que o Time de Desenvolvimento precisa realizar durante o sprint atual. O Sprint Backlog é gerenciado pelo Time de Desenvolvimento. É a “quebra” das tarefas principais para tarefas menores que facilitam o gerenciamento do Time de Devs.

3. Incremento. É o resultado do trabalho realizado durante um sprint, que adiciona valor ao produto final. É a entrega.

 

Os 5 Eventos Scrum

Já falamos sobre eles:

1. Sprint: Sim, a própria sprint é considerada um evento, embora ela ocorra “naturalmente”, sem que haja uma reunião do time Scrum para isso.

2. Reunião de Planejamento de Sprint. É uma reunião onde o Product Owner define as prioridades do Product Backlog e o Time de Desenvolvimento “quebra” e define as tarefas (isso também é chamado de “refinamento”) que serão realizadas durante a sprint atual.

3. Reunião Diária (Daily). É uma reunião diária de curta duração onde o Time de Desenvolvimento discute o progresso, impedimentos e planeja as próximas atividades. As perguntas que orienta essa reunião são: O que fiz ontem para contribuir com o objetivo da sprint? O que farei hoje para contribuir com o objetivo da sprint? O que está me impedindo de contribuir com o objetivo da sprint?

4. Revisão de Sprint. É uma reunião onde o Time de Desenvolvimento apresenta o incremento entregue no sprint atual ao cliente e a outros stakeholders (partes interessadas) relevantes, para que possam fornecer feedback.

5. Retrospectiva de Sprint. É uma reunião onde o Time de Desenvolvimento reflete sobre o sprint anterior e identifica o que funcionou bem e o que precisa ser melhorado para o próximo sprint. Lavagem de roupa suja, lembra?!

 

Quais as Técnicas de Estimativa Ágil Mais Comuns e Como Utilizá-las?

As técnicas de estimativa ágil são usadas para estimar o esforço necessário para concluir um item do Product Backlog ou uma tarefa da Backlog Sprint. Essas técnicas são diferentes das técnicas tradicionais de estimativa, pois são mais flexíveis, colaborativas e orientadas para o valor. 

Algumas das técnicas de estimativa ágil mais comuns são:

1. Planning Poker: Imagine que uma equipe de desenvolvimento está trabalhando em um projeto de desenvolvimento de um aplicativo móvel. Eles têm um item no Product Backlog que envolve a implementação de um novo recurso de chat no aplicativo. Para estimar o esforço necessário, cada membro da equipe recebe um conjunto de cartas numeradas, que podem ser, por exemplo, 1, 2, 3, 5, 8, 13 e 20 (sequência Fibonacci, na qual cada termo subsequente corresponde à soma dos dois anteriores). Aqui, o Time de Devs discutem o item do Backlog e, em seguida, votam em segredo nas cartas para indicar sua estimativa de esforço. Se houver diferenças nas estimativas, a equipe discute as razões por trás delas até que cheguem a um consenso. Por exemplo, um membro pode acreditar que a criação de uma interface do site do cliente é um esforço de 5, enquanto outro acredita que é um 8 devido à complexidade. Eles discutiriam os detalhes até chegarem a um acordo sobre a estimativa, como um 8. As regras são feitas pelo próprio time. Por exemplo, se a maioria votou no “8”, então define-se o 8. Se a maioria votou no “8”, mas alguns membros votaram no 5 e outros no 13, pode haver um debate rápido seguido de uma nova votação.

2. Estimativa em t-shirt: Suponha que a equipe tenha outro item no Product Backlog, que envolve a criação de uma nova página de perfil de usuário. Eles decidem usar a técnica de estimativa em t-shirts. Sim, são como os tamanhos de camisetas, uma vez que essa estimativa é de fácil associação para todos, afinal todo mundo já comprou uma camiseta, né?! Após analisar o item do Backlog, a equipe decide, por exemplo, que é de tamanho “M” (Médio) porque envolve várias atualizações na interface do usuário e integração com o banco de dados. Em vez de fornecer uma estimativa numérica específica, eles se concentram na classificação “M” para indicar que o item está dentro de um certo intervalo de complexidade e esforço. Esse tamanho pode ser “convertido” posteriormente em horas, dias ou semanas, dependendo da escala ou padrão percebido. Por exemplo, o Scrum Master pode perceber, depois de analisar as entregas do time, que uma tarefa de tamanho “M” significa 5 dias.

3. Estimativa em pontos de história: Considere que outro item no Product Backlog é a adição de uma funcionalidade de pesquisa ao aplicativo. A equipe decide utilizar a técnica de estimativa em pontos de história. Eles atribuem pontos de história com base na complexidade, onde tarefas simples podem ser 3 pontos, tarefas médias 5 pontos e tarefas mais complexas 8 pontos. Lembrando que esses pontos não precisam seguir necessariamente a sequência Fibonacci.

4. Estimativa em tempo: Agora, suponha que um membro da equipe precise estimar o tempo necessário para corrigir um bug crítico no aplicativo. Eles decidem usar a técnica de estimativa em tempo. Após revisar o bug, eles estimam que levará cerca de 16 horas de trabalho para corrigi-lo. Essa abordagem é usada quando a equipe precisa de uma estimativa mais precisa em termos de horas ou dias para planejamento. Depois de estimar em horas, basta converter em horas de trabalho por dia. 16 horas, por exemplo, levaria 2 dias de trabalho de um membro da equipe.

5. Estimativa em porcentagem concluída: Digamos que a equipe esteja trabalhando em uma fase de teste de usabilidade do aplicativo. Eles têm uma lista de itens de teste e decidem estimar o progresso em termos de porcentagem concluída. Após uma semana de testes, eles determinam que concluíram cerca de 30% dos testes planejados, o que ajuda a equipe e o Product Owner a entender o status do trabalho. Essa estimativa se torna mais complexa devido à natureza das tarefas, mas ainda sim é um dado relevante para gerir estimativas.

Essas são maneiras práticas de aplicar diferentes técnicas de estimativa ágil no contexto do desenvolvimento de software, permitindo que a equipe tenha uma compreensão mais clara do esforço e da complexidade envolvidos em cada item do Product Backlog.

 

Como o PO Faz Gestão de Backlog do Produto na Prática?

O Product Backlog é uma lista de requisitos, funcionalidades e melhorias priorizadas do produto que precisam ser implementados.

É responsabilidade do Product Owner gerenciar o Product Backlog, garantindo que ele esteja sempre atualizado e refletindo as necessidades e prioridades do cliente.

A gestão do Product Backlog por parte do PO envolve as seguintes etapas:

1. Estimativa: O PO trabalha em estreita colaboração com o Time de Desenvolvimento para estimar o esforço necessário para cada item do backlog. Isso, como vimos, é feito no Planejamento da Sprint. Nesse momento, o PO e os DEVs “negociam” para ver quais itens cabem naquela Sprint.

2. Adição e remoção de itens: Durante a revisão do Product Backlog, o PO percebe que há uma nova solicitação de recurso dos clientes: a adição de um sistema de avaliação de produtos. Eles discutem essa mudança com a equipe de desenvolvimento e decidem adicionar esse novo item ao backlog, pois acreditam que ele trará mais valor aos clientes. Ao mesmo tempo, o PO pode remover um item que já não seja relevante ou necessário. Novamente, as adições e remoções de itens são negociadas com o time de Devs, principalmente se a Sprint já tiver iniciado. Essa negociação ocorre porque pode acontecer do time de Devs não querer se comprometer com novas tarefas, que irão ultrapassar o prazo da Sprint (que não pode ser alterado depois de iniciado) ou qualquer outro motivo plausível.

3. Refinamento: Para garantir que os itens do backlog sejam claros e compreensíveis, o PO realiza sessões de refinamento com a equipe de desenvolvimento. Por exemplo, ao detalhar o item “Implementação do sistema de recomendações”, eles podem quebrá-lo em tarefas menores, como “coletar dados de navegação do usuário” e “desenvolver algoritmo de recomendação”. Isso ajuda a evitar problemas de comunicação e atrasos durante a Sprint.

4. Comunicação: O PO garante que o Product Backlog seja compartilhado com todos os membros da equipe. Eles também se comunicam regularmente com os desenvolvedores para esclarecer dúvidas e garantir que todos estejam cientes das prioridades. Por exemplo, o PO realiza reuniões semanais com a equipe de desenvolvimento para revisar o backlog e discutir qualquer alteração nas prioridades.

5. Acompanhamento: O PO acompanha o progresso do Product Backlog, monitorando o que foi concluído durante cada Sprint. Eles também revisam e ajustam as prioridades à medida que novas informações são obtidas dos clientes ou à medida que o mercado muda. Por exemplo, se surgirem feedbacks dos clientes sobre a necessidade de melhorias na interface do usuário, o PO pode ajustar as prioridades do backlog para incluir essas melhorias.

Essas etapas refletem a prática do Product Owner em uma empresa de desenvolvimento de software, onde a gestão eficaz do Product Backlog é fundamental para o sucesso do Scrum e para atender às necessidades do cliente em constante evolução.

 

Como Garantir a Colaboração de Equipes Remotas?

O Scrum pode ser utilizado em equipes distribuídas e remotas, embora seja necessário adaptar algumas práticas para que funcionem melhor nesse contexto.

Algumas das práticas e ferramentas que podem ajudar equipes distribuídas e remotas a trabalharem com Scrum incluem:

1. Ferramentas de comunicação online. As ferramentas de comunicação online são essenciais para equipes distribuídas e remotas. As opções mais comuns são: Zoom, Microsoft Teams, Slack, Google Meet, Skype e Discord. As videoconferências podem ser realizadas para as cerimônias do Scrum, como o Sprint Planning (planejamento da Sprint), a Daily Scrum (reunião diária ou apenas Daily) e a Sprint Review (revisão ou simplesmente “review”). As ferramentas de chat também são importantes para manter a comunicação constante entre a equipe. Não existe melhor ferramenta de comunicação online, mas sim aquela que melhor se adapta ao time mediante seus recursos e funcionalidades.

2. Repositórios de código online. Os repositórios de código online, como o GitHub, GitLab ou Bitbucket, podem ser usados para compartilhar o código fonte e permitir que os membros da equipe colaborem de forma eficiente.

3. Ferramentas de gerenciamento de projetos. Existem várias ferramentas de gerenciamento de projetos online que podem ser utilizadas para gerenciar o Product Backlog e acompanhar o progresso do Sprint. Algumas opções populares incluem o Trello, Jira e Asana.

4. Comunicação clara e frequente. É importante que a equipe distribuída e remota tenha uma comunicação clara e frequente para garantir que todos estejam alinhados em relação ao trabalho. As dúvidas devem ser esclarecidas imediatamente e a comunicação deve ser mantida regularmente, inclusive fora das cerimônias, se for o caso.

5. Estabelecimento de horários de trabalho. Equipes distribuídas e remotas podem trabalhar em diferentes fusos horários e, por isso, é necessário estabelecer horários de trabalho que funcionem para todos. Isso pode significar que alguns membros da equipe precisem trabalhar em horários não convencionais para garantir que todos estejam disponíveis para as cerimônias. Além dos fusos horários, membros da equipe podem produzir mais durante a manhã, como outros podem produzir mais no período noturno. Essa flexibilidade e adaptação deve ser levada em consideração também!

6. Foco na transparência: O Scrum enfatiza a transparência, e isso é ainda mais importante em equipes distribuídas e remotas. Todos devem ter acesso ao Product Backlog, saber o que os outros membros da equipe estão trabalhando e ter uma visão clara do progresso do Sprint. Nada fica debaixo do tapete e todos devem estar motivados para o cumprimento dos objetivos, uma vez que todas as “peças do time” são únicas.

 

Como Criar e Fechar Um Sprint no Jira?

 

Como Fazer o Gerenciamento de Riscos na Gestão Ágil? 

O gerenciamento de riscos e bloqueios é uma parte importante do Kanban, pois ajuda a minimizar os problemas e atrasos no fluxo de trabalho. 

Aqui estão algumas práticas que podem ser usadas para gerenciar riscos e bloqueios (impedimentos) no Kanban:

1. Identificar os Riscos: Identificar os riscos em uma empresa de software é como revisar o plano de desenvolvimento antes de iniciar um projeto. Durante as reuniões de planejamento, a equipe pode identificar um possível risco, como a dependência de uma tecnologia específica que ainda está em versão beta e pode ter problemas de estabilidade. Além disso, pode haver a escassez de especialistas nessa nova tecnologia necessária. Tudo isso pode afetar a entrega do projeto.

2. Priorizar os Riscos: Depois de identificar os riscos, é importante priorizá-los com base em sua gravidade. Por exemplo, se a equipe perceber que a dependência da tecnologia beta é um risco mais provável e impactante do que a falta de recursos de hardware, eles devem focar mais recursos e atenção na mitigação desse risco.

3. Desenvolver Estratégias de Mitigação: Desenvolver estratégias de mitigação no contexto de uma empresa de software é como preparar um plano de contingência. Para lidar com o risco da tecnologia beta, a equipe pode planejar alternativas, como ter um plano de backup para migrar para uma tecnologia mais antiga, porém mais estável, caso ocorram problemas inesperados.

4. Monitorar os Riscos: Monitorar os riscos é como usar ferramentas de monitoramento para acompanhar o desempenho de um aplicativo em tempo real. A equipe de gerenciamento de projetos de software pode manter um registro de riscos e revisá-lo regularmente para garantir que as estratégias de mitigação estejam funcionando. Por exemplo, eles podem monitorar continuamente a estabilidade da tecnologia beta e tomar medidas corretivas conforme necessário.

5. Lidar com Bloqueios: Lidar com bloqueios (ou impedimentos) em uma empresa de software é semelhante a resolver problemas técnicos que surgem durante o desenvolvimento. Se um bloqueio ocorrer, como uma falha crítica na tecnologia beta, a equipe deve agir rapidamente para minimizar o impacto no projeto. Isso pode incluir a alocação de recursos adicionais, como engenheiros de software, para solucionar o problema o mais rápido possível.

 

Integração do Scrum com Outras Metodologias Ágeis

A integração com outras metodologias ágeis é uma prática comum em ambientes de desenvolvimento de software. 

É óbvio que isso se expande e funciona em outros setores também!

Algumas das metodologias ágeis mais populares incluem Scrum, Kanban, Lean e XP (Extreme Programming). A integração pode ocorrer de várias maneiras, dependendo das necessidades e dos requisitos da equipe de desenvolvimento.

Uma abordagem comum é combinar elementos de diferentes metodologias ágeis para criar um processo personalizado que atenda às necessidades da equipe.

Por exemplo, uma equipe pode usar o Scrum para gerenciar o backlog de produtos e sprints, enquanto utiliza o quadro Kanban para gerenciar o fluxo de trabalho diário. Isso permite que a equipe aproveite os pontos fortes de ambas as metodologias, aumentando a eficiência e a eficácia do processo.

Outra abordagem é utilizar as práticas de uma metodologia ágil para melhorar outra. Por exemplo, a equipe Scrum pode utilizar as práticas de testes automatizados e integração contínua do XP para melhorar a qualidade do produto e o tempo de entrega. Isso permite que a equipe aproveite as práticas eficazes do XP sem precisar adotar a metodologia completa.

A integração com outras metodologias ágeis pode trazer benefícios significativos para as equipes de desenvolvimento de software. Isso pode ser feito através da combinação de elementos de diferentes metodologias ou utilizando as práticas eficazes de uma metodologia para melhorar outra. O importante é avaliar as necessidades da equipe e adaptar o processo de acordo com as necessidades da equipe e do projeto.

 

E ficamos por aqui…

A gestão ágil Scrum tem se mostrado uma abordagem eficaz para o desenvolvimento de software, permitindo que as equipes entreguem produtos de alta qualidade de forma eficiente e eficaz. 

A metodologia Scrum é baseada em princípios ágeis, como a colaboração, a comunicação constante e a adaptação a mudanças.

A gestão ágil Scrum é baseada em sprints, ciclos curtos de trabalho que geralmente duram de uma a quatro semanas. Cada sprint tem uma meta clara e um backlog de produtos priorizados que guiam o trabalho da equipe. 

Durante o sprint, a equipe se reúne diariamente para discutir o progresso do trabalho e identificar possíveis obstáculos.

Um dos principais benefícios da gestão ágil Scrum é a transparência do processo, permitindo que as partes interessadas tenham uma visão clara do andamento do projeto e possam fazer ajustes no caminho. 

Além disso, a metodologia Scrum é flexível e adaptável, permitindo que as equipes respondam rapidamente às mudanças e ajustem o processo de acordo com as necessidades do projeto.

Esperamos que tenha gostado desse curso online gratuito de Gestão Ágil Scrum.

Agora você pode solicitar os certificados de conclusão em seu nome. Desejamos a você muito sucesso! Até o próximo curso! 🙂