Prévia do material em texto
Práticas gerenciais com Scrum Utilização dos métodos ágeis com base no Scrum para agregação de valor nas organizações. Prof. Eduardo Montes 1. Itens iniciais Propósito Capacitar pessoas e organizações a desenvolver projetos com Scrum, promovendo um ambiente colaborativo e formando equipes de alto desempenho baseadas em transparência, inspeção e adaptação. Objetivos Reconhecer os pilares, os valores e os papéis no Scrum. Empregar os eventos do Scrum e seus artefatos. Aplicar técnicas para cálculo, monitoramento e facilitação dos eventos do Scrum. Identificar as melhores e as piores práticas na implementação do Scrum. Introdução Em um cenário cada vez mais competitivo e com o crescimento do trabalho remoto, formar equipes motivadas, auto-organizadas e de alto desempenho tornou-se imprescindível para a sobrevivência das organizações. O Scrum, o método ágil mais adotado mundialmente, é um dos melhores caminhos para trilhar essa jornada. Neste conteúdo, você aprenderá os componentes necessários para implementá-lo com sucesso. Vamos começar entendendo por que o Scrum foi criado. Em seguida, explicaremos seus pilares, os valores que orientam sua aplicação, os papéis da equipe, os eventos e os artefatos envolvidos. Depois, apresentaremos técnicas eficazes para planejar, revisar e acompanhar o andamento do projeto. E, para fechar, mostraremos os desafios mais comuns na implementação do Scrum e como superá-los. • • • • 1. Conceitos básicos O Manifesto Ágil Você sabe o que levou à criação dos métodos ágeis? Quais são as principais diferenças entre os métodos ágeis e os aqueles que existiam anteriormente? No vídeo a seguir, veja um breve histórico que revela essas respostas. Vamos assistir! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Apresentação: princípios e características Na década de 1990, cresceu a insatisfação com a forma tradicional de gerenciar projetos de desenvolvimento de software. Esse modelo, conhecido como cascata, organiza o trabalho em fases sequenciais, em que cada etapa depende da conclusão da anterior. Embora funcione bem em projetos com alta previsibilidade — como os das áreas de manufatura e construção, para as quais o método foi inicialmente pensado — o modelo em cascata se mostrou pouco eficaz em ambientes mais dinâmicos, como o desenvolvimento de software. As principais reclamações estavam associadas a dois fatores. Confira! Muitos processos e documentações exigidos. Complexidade para adaptar às necessidades de mudanças. Alguns críticos consideravam esse método muito “pesado” para desenvolver softwares devido à sobrecarga de trabalho necessária para gerar toda a documentação. Em oposição a essa abordagem, começavam a surgir na época métodos conhecidos como “leves”, como, entre outros exemplos, o: Scrum XP (Extreme Programming) Crystal Em 2001, 17 dos maiores representantes desses métodos mais leves se encontraram para discutir formas de aprimorá-los. A partir desse encontro, foi publicado o Manifesto Ágil. Seus quatro valores e 12 princípios serviram como base para tais métodos, que passaram a se conhecidos como métodos ágeis. O Manifesto Ágil expõe seus valores da seguinte forma: “estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo” (Beck et al., 2001a). Dessa forma, interaja e confira os itens valorizados pelo Manifesto Ágil! • • • Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Ou seja, mesmo havendo valor nos itens à direita (itens 2 e 3), valorizamos mais os itens à esquerda (itens 1 e 4). Como vimos, os valores criados fazem parte de um grande aprendizado prático, analisando as causas dos fracassos e dos sucessos e passando a valorizar aquilo que realmente importa. Veja a seguir outras características desses itens, encontradas no manifesto. Confira! Indivíduos e interações mais que processos e ferramentas Por melhores que sejam o processo e as ferramentas usadas, eles não ajudarão muito se as pessoas não estiverem engajadas e não se comunicarem de forma adequada. Software em funcionamento mais que documentação abrangente Por melhor e mais detalhada que seja a documentação, de nada adiantará se ela não for transformada em um software funcionando. Colaboração com o cliente mais que negociação de contratos É muito mais importante criar um ambiente que favoreça a colaboração com o cliente do que investir na negociação com os fornecedores. Os fornecedores são contratados para atender às necessidades dos clientes. Responder a mudanças mais que seguir um plano Não adianta nada ter um escopo atendido conforme o planejado se ele não atende mais às necessidades do cliente. Agilidade para adaptar as mudanças é um fator-chave no sucesso do desenvolvimento de software. Fique agora com os princípios do Manifesto Ágil. Veja! Satisfação do cliente Nossa maior prioridade é satisfazer o cliente por meio da entrega contínua e adiantada de software com valor agregado. Abertura a mudanças Mudanças nos requisitos são bem-vindas, mesmo que tardiamente, no desenvolvimento. Processos ágeis se beneficiam das mudanças visando à vantagem competitiva para o cliente. Entrega frequente Entregar frequentemente um software funcionando de poucas semanas a poucos meses, com preferência para a menor escala de tempo. Colaboração contínua Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto ao longo de todo o projeto. Times motivados Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário, confiando neles para fazer o trabalho. Comunicação direta O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é por meio da conversa face a face. Software como medida Software funcionando é a medida primária de progresso. Ritmo sustentável Os processos ágeis promovem um desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Excelência técnica Contínua atenção à excelência técnica e bom design aumentam a agilidade. Simplicidade Simplicidade (a arte de maximizar a quantidade de trabalho não realizado) é essencial. Auto-organização As melhores arquiteturas, requisitos e designs emergem de equipes auto- organizáveis. Melhoria contínua Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, então, refina e ajusta seu comportamento de acordo. O que são os métodos ágeis Métodos ou frameworks usados para elaborar projetos que compartilham valores e princípios do Manifesto Ágil são considerados métodos ágeis. Kanban, XP, ScrumBan e Scrum são alguns desses métodos disponíveis. Entre eles, o mais conhecido e usado mundialmente é o Scrum, que detalharemos a seguir. Uma das pesquisas mais famosas do mercado sobre os métodos ágeis, a State of Agile, mostra o percentual de adoção por método ágil. Quando usar os métodos ágeis Os métodos ágeis foram criados inicialmente para projetos de desenvolvimento de software, mas eles têm sido usados com sucesso em vários outros tipos de projeto. Eis algumas das características para as quais o uso de métodos ágeis é mais adequado. Confira! Previsibilidade do escopo do projeto Quanto maior a incerteza daquilo que será feito e maior a necessidade de se adaptar o produto à medida que ele for desenvolvido, mais adequado será o método ágil. Formas de entrega dos produtos sendo desenvolvidos Produtos que podem ser entregues de forma incremental e iterativa são adequados ao método ágil. Riscos Quanto menor o risco relacionado ao produto, ou seja, quanto menor o impacto relacionado a um problema nas entregas, melhor será o uso do método ágil. Em projetos que envolvem um alto impacto relacionado às suas entregas, como um prédio, uma ponte ou uma indústria, em que a possibilidade de erro pode causar uma catástrofe, deve ser escolhida uma abordagem mais preditiva. Nem todo projetoowner e de alguns developers (de 3 a 9 developers, dependendo do tamanho do piloto). Veja algumas dicas para iniciar um projeto-piloto. Comece pelo Scrum master Líder servidor, mestre da arte do Scrum e responsável pela eficiência do Scrum team. É fundamental que sua organização tenha alguém muito bem preparado para treinar o Scrum team a fim de que ele saiba obter os melhores resultados do Scrum. Uma consultoria especializada poderá acelerar o processo de aprendizado e a disseminação do Scrum entre o Scrum team. Crie um ambiente propício para a colaboração O ambiente deve favorecer a transparência e a colaboração entre o Scrum team. Recomendamos a criação de um quadro Kanban físico ou virtual, assim como o uso de ferramentas complementares para facilitar a colaboração. Complemente o Scrum com o Kanban Defina o fluxo de trabalho com seus elementos. Treine o Scrum team Capacite todo o Scrum team antes de iniciar o piloto baseado no ambiente de colaboração e no fluxo de trabalho já criado. Procure uma boa consultoria É importante o apoio de uma consultoria especializada para alavancar os resultados e acelerar a curva de aprendizado. Foque a sprint retrospective Talvez seja o evento mais estratégico para o piloto, pois é por meio dessa sprint que os pontos de melhoria necessários são identificados. Desse modo, é fundamental que, na reunião, ocorram as seguintes ações: Discussão dos principais problemas enfrentados e das mudanças necessárias para corrigi-los. Identificação e seleção dos pontos de melhorias para a próxima sprint. O Scrum é empírico e deve ser adaptado para obter os melhores resultados a cada sprint. A sprint retrospective é a reunião para discutir como os processos, as ferramentas e as métricas poderão ser adaptados conforme as necessidades que forem surgindo em cada sprint. Após a formação do Scrum team e a apresentação dos benefícios do piloto, defina a melhor estratégia para a expansão segundo as necessidades da organização. Faça isso sem perder de vista a criação de uma cultura na organização baseada nos valores e nos princípios do Manifesto Ágil. Principais barreiras Tendo como base a 15ª edição da pesquisa State of Agile, os sete maiores obstáculos para a adoção dos métodos ágeis são os seguintes: Barreira % Processos e práticas inconsistentes entre as equipes 46% Cultura organizacional em conflito com valores ágeis 43% Resistência geral da organização à mudança 42% Falta de habilidades/experiência com métodos ágeis 42% Participação de liderança insuficiente 41% Apoio de gestão e patrocínio inadequados 40% Treinamento e educação insuficientes 35% Tabela: Quais são as barreiras mais significativas para adotar e expandir as práticas Agile em sua organização atual? Digital.ai, 2021, p. 12, adaptado por Eduardo Montes. Confira as porcentagens no detalhe, de uma maneira mais visual, na imagem! • • Conteúdo interativo Acesse a versão digital para ver mais detalhes da imagem abaixo. Sete maiores obstáculos para a adoção dos métodos ágeis. Para superar esses obstáculos, algumas estratégias podem ser adotadas a depender de cada situação. Acompanhe cada uma seguir! Patrocínio da alta direção Sem um patrocínio de peso, alguém que possa trazer os recursos e reduzir as resistências com as lideranças envolvidas nos projetos, a implementação do Scrum tem grandes chances de naufragar nos primeiros obstáculos que aparecerem. Desse modo, a primeira questão é encontrar pessoas na alta direção para patrocinar e apoiar a implementação. Um bom patrocinador atuará de forma efetiva para que haja a participação suficiente das lideranças e o apoio adequado de outros gestores. Iniciar com um piloto e expandir gradualmente Siga as fases para a implementação do Scrum já explicadas. Contratação de especialista em Scrum Também é muito importante a contratação de uma boa consultoria especializada em Scrum para treinar as pessoas e ajudar na implementação do método. Especialistas com sucesso comprovado em outras organizações ajudam a reduzir a resistência à mudança e a convencer as pessoas graças aos resultados obtidos internamente ou em outras empresas. Essa estratégia possui um impacto significativo na maioria das barreiras identificadas. Destacaremos dois exemplos a seguir. Falta de habilidades/experiência com métodos ágeis: o especialista habilita as pessoas, trazendo sua experiência e os atalhos para remover os impedimentos e identificar as melhores soluções. Treinamento e educação insuficientes: o especialista treina as pessoas de forma adequada. Interações constantes entre os Scrum masters É importante que os Scrum Teams compartilhem entre si as melhores práticas adotadas e os pontos de melhoria identificados nas sprint retrospectives. Sempre que possível, as soluções encontradas devem beneficiar toda a organização. Também deve haver interações frequentes entre os Scrum Masters das diferentes equipes, promovendo alinhamento na definição de processos e práticas. Como muitos problemas tendem a se repetir entre os times, soluções semelhantes podem ser aplicadas, gerando ganhos em escala, aprendizado e padronização. Essa abordagem contribui diretamente para superar a barreira dos processos e práticas inconsistentes entre as equipes. Troca de alguns membros resistentes aos valores ágeis Uma empresa em que as pessoas são pouco valorizadas e possuem pouca autonomia, normalmente terá dificuldades para adaptar-se aos valores e aos princípios do Manifesto Ágil. A maioria delas adapta-se bem aos valores e aos princípios ágeis, porém, dentro da minoria que não se adapta, pode ser necessário haver algumas trocas para demonstrar a importância dos valores ágeis e motivar as pessoas comprometidas. Monitoramento e divulgação dos resultados de forma consistente Por meio da interação dos Scrum masters ou até mesmo da criação de um escritório de projetos, é importante haver a divulgação das melhorias obtidas pelos Scrum teams por meio da adoção do Scrum. O especialista contratado pode, por exemplo, ajudar a fazer essa divulgação ou a estabelecer sua periodicidade. A consistência nos resultados é o melhor remédio para solucionar os conflitos e as resistências, além de evitar a penetração dos métodos tradicionais de desenvolvimento. Como superar os principais obstáculos na implementação do Scrum Neste vídeo, falaremos sobre as principais barreiras na implementação do Scrum e como superá-las. Vamos lá! • • Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Verificando o aprendizado Questão 1 Qual das alternativas a seguir constitui um dos sete maiores obstáculos na adoção dos métodos ágeis identificados na 15ª edição da pesquisa State of Agile? A Processos e práticas inconsistentes entre as equipes. B Profissionais não certificados como Scrum master. C Treinamento e educação com ênfase nos métodos tradicionais. D Cultura organizacional baseada na liderança servidora. E Resistência geral da organização às novas tecnologias. A alternativa A está correta. Processos e práticas inconsistentes entre as equipes são o maior obstáculo para a adoção dos métodos ágeis segundo a pesquisa. Ter profissionais certificados pode ajudar a implementação do Scrum, porém isso não é um dos principais obstáculos identificados na 15ª edição da pesquisa State of Agile. As demais são variações incorretas dos obstáculos identificados na pesquisa. Questão 2 Qual das alternativas abaixo é uma das estratégias sugeridas para reduzir os obstáculos (identificados na 15ª edição da pesquisa State of Agile) na adoção de métodos ágeis? A Patrocínio da equipe operacional. B Contratação de especialista certificado PMP. C Patrocinar curso e exame para certificação como Scrum master. D Interações constantes entre os gerentes de projetos. E Monitoramento e divulgação dos resultados de forma consistente. A alternativa E está correta. Monitoramento e divulgação dos resultados de forma consistente são algumas das estratégias sugeridas para reduzir os obstáculos.As demais são variações incorretas das estratégias sugeridas ou não foram estratégias sugeridas. 5. Conclusão Considerações finais Como vimos, os métodos ágeis foram criados para desenvolver softwares valorizando mais as pessoas e suas interações, assim como o software em funcionamento, a colaboração com o cliente e as respostas ágeis às necessidades de mudanças. Frisamos, por isso, que são muito mais do que métodos: eles constituem princípios e valores que estão revolucionando as organizações. Método ágil mais conhecido e usado mundialmente, o Scrum fornece um conjunto de pilares, papéis, eventos e artefatos que habilita as pessoas e suas organizações a gerar valor por meio dos seus produtos. Apontamos, contudo, que o Scrum é um framework que precisa de técnicas complementares para ser implementado com sucesso. Entre elas, destacamos o MoSCoW; a análise de decisão, que envolve critérios múltiplos para priorizar os itens do product backlog; o Scrum poker, para estimar os itens de trabalho; e principalmente o método Kanban, que vem sendo muito utilizado para complementar o Scrum. A implementação do Scrum deve ocorrer de forma gradual, seguindo o próprio princípio do empirismo que fundamenta o método. Uma abordagem eficaz é iniciar com um projeto-piloto, estruturando um Scrum team dedicado. Para isso, é importante preparar bem esse projeto, começando pela escolha do Scrum master e promovendo um ambiente colaborativo para a equipe. Na sequência, o uso do Kanban pode complementar o Scrum, auxiliando na visualização do fluxo de trabalho. Todo o time deve passar por um treinamento adequado, sempre com foco na construção de uma cultura organizacional alinhada aos valores e princípios do Manifesto Ágil. Por fim, apresentamos maneiras de lidar com as principais barreiras identificadas, propondo estratégias para reduzir ou eliminar seus impactos. Destacamos também a importância de contar com um bom patrocinador, contratar um especialista em Scrum para apoiar a implementação, e promover interações entre os Scrum masters, favorecendo o compartilhamento e o aprimoramento das práticas. Além disso, é essencial monitorar os resultados obtidos com a adoção do Scrum e divulgá-los de forma transparente. Explore + Acesse a página do Scrum para se aprofundar nos seguintes conteúdos: Scrum – Consulte o Guia do Scrum para entender o framework em detalhes. Integração do Kanban com o Scrum – Leia The Kanban guide for Scrum teams e conheça como aplicar as duas abordagens de forma complementar. Referências BECK, K. et al. Manifesto para desenvolvimento ágil de software. Manifesto for Agile Software Development. 2001a. Consultado na internet em: 31 ago. 2021. BECK, K. et al. Princípios por trás do Manifesto Ágil. Manifesto for Agile Software Development. 2001b. Consultado na internet em: 31 ago. 2021. DUARTE, L. Scrum e métodos ágeis: um guia prático. Gravataí, RS: LuizTools, 2016. • • PROJECT MANEGEMENT INSTITUTE. Guia PMBOOK. 7. ed. Guia do conhecimento em gerenciamento de projetos. Consultado na internet em: 15 maio 2025. SCHWABER, K.; SUTHERLAND, J. O Guia do Scrum – o guia definitivo para o Scrum: as regras do jogo. Nov. 2020. Consultado na internet em: 31 ago. 2021. SCRIBD. 15th Annual State of Agile Report. Digital.AI. Consultado na internet em: 15 maio 2025. STATE OF AGILE. The 17th State of Agile is Report. Digital.AI. Consultado na internet em: 14 maio 2025. Práticas gerenciais com Scrum 1. Itens iniciais Propósito Objetivos Introdução 1. Conceitos básicos O Manifesto Ágil Conteúdo interativo Apresentação: princípios e características Muitos processos e documentações exigidos. Complexidade para adaptar às necessidades de mudanças. Conteúdo interativo Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Satisfação do cliente Abertura a mudanças Entrega frequente Colaboração contínua Times motivados Comunicação direta Software como medida Ritmo sustentável Excelência técnica Simplicidade Auto-organização Melhoria contínua O que são os métodos ágeis Quando usar os métodos ágeis Previsibilidade do escopo do projeto Formas de entrega dos produtos sendo desenvolvidos Riscos Estudo de caso: missão ágil – decisões baseadas em valores e princípios Cenário Cadastrar provas Entregar trabalhos Definir metas de estudo Escopo das tarefas Situações da missão ágil Conteúdo interativo Entrega Utilize o PowerPoint para a entrega da atividade Rubricas para autoavaliação Conteúdo interativo O Scrum Histórico e definição Recomendação Os pilares do Scrum Transparência Inspeção Adaptação Os valores do Scrum Compromisso Foco Abertura Respeito Coragem Scrum team SM PO DEVs Desenvolvedores (developers) Conteúdo interativo Criar um plano para a sprint, representado pelo sprint backlog. Garantir a qualidade de forma contínua, seguindo a definição de pronto. Ajustar diariamente o plano conforme a meta da sprint. Assumir responsabilidade mútua como profissionais. Product owner (PO) Scrum master (SM) Os pilares e o Scrum team Conteúdo interativo Verificando o aprendizado 2. Eventos e artefatos Eventos do Scrum A sprint Conteúdo interativo Sprint planning Daily Scrum Sprint review Sprint retrospective Sprint planning Conteúdo interativo Clareza nas entregas Estimativas realistas Planejamento detalhado Daily Scrum Sprint review Comentário Sprint retrospective Sprint Sprint planning Daily Scrum Sprint review Sprint retrospective Artefatos do Scrum O product backlog, o sprint backlog e o incremento Conteúdo interativo Product backlog Histórias de usuário (user stories) Atenção Tarefas (tasks) Exemplo e prática Conteúdo interativo Sprint backlog Conteúdo interativo Incremento Atenção Conteúdo interativo Os eventos e os artefatos do Scrum Conteúdo interativo Vamos à prática! Estudo de caso: é hora de colocar a mão na massa! Cenário Definição da meta da sprint Criação de histórias de usuário (User stories) Quebra em tarefas Criação da sprint backlog Verificando o aprendizado 3. Técnicas Técnicas complementares ao Scrum Técnicas para priorizar Relembrando MoSCoW Must have Should have Could have Won’t have Análise de decisão envolvendo critérios múltiplos Priorizar qualquer lista de itens ou de ideias. Solicitar mudanças, requisitos, projetos, pessoas e itens do product backlog no Scrum. Conteúdo interativo Técnicas para estimar: Scrum poker Reflexão Descrição do item Esclarecimento de dúvidas Seleção da carta Votação Carta 0 – Já foi! Carta 1 – É moleza! Carta 2 – Rapidinho, mas com calma Carta 3 – Simples… mas não subestime! Carta 5 – Dia cheio pela frente Carta 8 – Agora complicou um pouco Carta 13 – Missão da semana Carta 20 – Grande demais para ser estimada Carta ? – Não entendi nada! Carta ∞ – Essa tarefa não cabe em lugar nenhum! Carta Café – Vamos dar um tempo? Velocidade Exemplo Vamos jogar para planejar? Cenário Materiais e ferramentas Passo a passo da atividade Revise seu sprint backlog Estime o esforço de cada tarefa Selecione as tarefas da sprint Justifique suas escolhas Método Kanban Conteúdo interativo Importância do Kanban como complemento ao Scrum 1° lugar 2° lugar 3° lugar Físico Virtual Como implementar o Kanban no Scrum Práticas do Kanban aplicadas ao Scrum Visualização do fluxo de trabalho Limitação do trabalho em progresso Gestão ativa de itens de trabalho em andamento Inspeção e adaptação da definição do fluxo de trabalho Métricas do Kanban Trabalho em progresso Tempo de ciclo Idade do item de trabalho Taxa de entrega Vamos organizar esse fluxo! Estudo de caso: na rotatória, vire à quarta direita: cuidado para não voltar ao mesmo lugar! Passo a passo da atividade Monte seu quadro Kanban com 4 colunas Organizesuas tarefas Simule o andamento das tarefas Aplique um limite de WIP (Work in progress) Capture uma imagem ou exporte seu quadro Conteúdo interativo Conteúdo interativo Conteúdo interativo Transforme sua prática em vitrine! Técnicas para facilitar eventos Sprint planning Relembrando Daily Scrum O que estou fazendo? Quais os impedimentos? O que vou fazer? Sprint review Person Product owner Groups Developers Sprint retrospective Facilitação pelo Scrum Master Participação de todo o time Discussão de impedimentos Inspeção do fluxo de trabalho Registro de melhorias Adoção de ao menos uma melhoria Verde Amarelo Vermelho Técnicas complementares ao Scrum Conteúdo interativo Verificando o aprendizado 4. Boas práticas Fases para a implementação Conteúdo interativo Patrocínio da alta direção Resultados consistentes no curto prazo Implantação por fases Fases para implementação do Scrum Conteúdo interativo Abordagem: montar um Scrum team para um projeto-piloto Scrum team Relembrando Comece pelo Scrum master Crie um ambiente propício para a colaboração Complemente o Scrum com o Kanban Treine o Scrum team Procure uma boa consultoria Foque a sprint retrospective Principais barreiras Conteúdo interativo Patrocínio da alta direção Iniciar com um piloto e expandir gradualmente Contratação de especialista em Scrum Interações constantes entre os Scrum masters Troca de alguns membros resistentes aos valores ágeis Monitoramento e divulgação dos resultados de forma consistente Como superar os principais obstáculos na implementação do Scrum Conteúdo interativo Verificando o aprendizado 5. Conclusão Considerações finais Explore + Referênciascombina com métodos ágeis. Agora é a sua vez de colocar o conhecimento em prática! Leia as situações apresentadas e decida qual abordagem é mais adequada: ágil ou tradicional. Responda ao quiz a seguir e descubra se você já está pensando como um verdadeiro agilista! Hora do Quiz! Vamos testar seus conhecimentos até aqui! Responda as perguntas a seguir e no final confira o resultado! Questão 1 Uma startup de tecnologia está desenvolvendo um novo aplicativo de bem-estar mental. A equipe ainda está testando quais funcionalidades geram mais engajamento entre os usuários. O projeto deve seguir um método ágil? A Sim, método ágil. B Não, método ágil não é o ideal. A alternativa A está correta. Correto! Projetos com escopo incerto e espaço para experimentação se beneficiam muito de métodos ágeis. Continue explorando ideias com flexibilidade! 1/4 Questão 2 Uma construtora vai executar a obra de um viaduto em uma área urbana movimentada. O projeto tem requisitos técnicos rígidos e prazos legais para entrega. O projeto deve seguir um método ágil? A Sim, método ágil. B Não, método ágil não é o ideal. A alternativa B está correta. Perfeito! Projetos com alto risco e baixa margem de erro demandam controle rígido. Excelente percepção! 2/4 Questão 3 Uma editora está desenvolvendo uma nova plataforma digital para cursos on-line. A equipe quer lançar versões com funcionalidades mínimas e ir aprimorando a partir do feedback dos usuários. O projeto deve seguir um método ágil? A Sim, método ágil. B Não, método ágil não é o ideal. A alternativa A está correta. Exatamente! Lançar versões iterativas e evoluir com base no uso real é o coração do ágil. Ótima escolha! 3/4 Questão 4 Um hospital vai implementar um novo sistema de radioterapia. Os requisitos são fixos, e qualquer erro pode comprometer a segurança dos pacientes. O projeto deve seguir um método ágil? A Sim, método ágil. B Não, método ágil não é o ideal. A alternativa B está correta. Muito bem! Projetos com alto risco à segurança humana exigem precisão. Você fez uma ótima escolha! 4/4 Chegou a hora de colocar a mão na massa! Nesta atividade, você vai descobrir na prática como os valores e princípios do Manifesto Ágil ajudam equipes de alto desempenho a tomar boas decisões, mesmo em situações inesperadas. A ideia é sair do “teórico” e entrar no mundo real, refletindo sobre como agir de forma mais colaborativa, flexível e focada no que realmente importa. Vamos lá experimentar o que é ser ágil de verdade! Estudo de caso: missão ágil – decisões baseadas em valores e princípios Cenário Você faz parte de uma pequena equipe multidisciplinar contratada por uma escola para criar uma plataforma simples de organização de tarefas para estudantes do ensino médio. O objetivo é permitir que os alunos façam as tarefas descritas a seguir. Confira! Cadastrar provas Entregar trabalhos Definir metas de estudo A equipe tem quatro semanas para entregar um protótipo funcional. Durante o projeto, surgem situações inesperadas que vão exigir decisões rápidas e alinhadas a valores. Embora sua equipe não conheça metodologias específicas como Scrum ou Kanban, vocês decidiram adotar os valores e princípios do Manifesto Ágil como norte para suas ações. Escopo das tarefas Para cada situação descrita a seguir, reflita e responda: Qual valor ou princípio do Manifesto Ágil pode orientar a decisão da equipe? Qual seria uma decisão coerente com o Manifesto Ágil? Explique por que essa decisão é mais eficaz do que outras possíveis. Situações da missão ágil Confira algumas situações e tente decidir pensando qual das opções está mais alinhada com o Manifesto Ágil. Lembre-se que não existem respostas certas ou erradas, porém suas decisões e priorizações sempre terão reflexos na agilidade e qualidade do projeto. Vamos lá! 1. 2. 3. Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Para cada situação, o Manifesto Ágil valoriza adaptação, colaboração, software funcionando e interação humana. As opções mais alinhadas são sempre as que privilegiam responder rápido às mudanças, aproximar o cliente e fortalecer o time. Você pode usar essas opções no PowerPoint, inclusive como caminhos alternativos ou colocar uma “resposta ideal” e “resposta menos alinhada” para ajudar na compreensão. Entrega Monte um mapa visual em PowerPoint com os seguintes itens: Uma decisão fundamentada para cada situação, baseada nos valores e princípios do Manifesto Ágil. Um resumo visual dos 4 valores e dos 12 princípios, do seu jeito, para ajudar outras pessoas a entendê-los de forma prática. Utilize o PowerPoint para a entrega da atividade Estrutura sugerida para a apresentação: Capa Título: Missão ágil – decisões com o Manifesto Ágil Subtítulo: Atividade prática sobre valores e princípios ágeis Espaço para nome dos integrantes Slide 1: Introdução Breve explicação da atividade Link para o conteúdo do Manifesto Ágil (opcional) Slides 2 a 5: Situações do Estudo de Caso Cada slide com: Situação descrita Três campos editáveis: Valor ou princípio relacionado • • • • • • • 1. 2. • Decisão proposta Justificativa Slide Final: Mapa visual dos valores e princípios Espaço com post-its ou caixas editáveis para colocar o resumo visual dos quatro valores e 12 princípios. Rubricas para autoavaliação Confira as rubricas e as pontuações correspondentes que você pode utilizar para uma autoavaliação! Critério Rubricas Pontos Aplicação dos valores e princípios do Manifesto Ágil Apliquei corretamente os valores e princípios em todas as situações, com justificativas claras e bem alinhadas. 4 Apliquei a maioria dos valores e princípios de forma adequada, com justificativas razoáveis. 3 Apliquei poucos valores ou princípios, com justificativas vagas ou parciais. 2 Não apliquei os valores e princípios ou respostas estão em branco. 0 Clareza e coerência das decisões Todas as decisões foram coerentes, bem explicadas e demonstram raciocínio crítico. 4 Algumas decisões foram coerentes e bem explicadas, mas outras foram genéricas ou confusas. 3 Poucas decisões foram coerentes; explicações superficiais. 2 Nenhuma decisão foi apresentada ou todas estavam incoerentes. 0 Qualidade do material produzido (criatividade, visual, organização) Material visual bem estruturado, criativo e organizado; uso eficaz de recursos visuais. 2 Material com organização e estética adequadas, mas com pouca originalidade. 1 Material com baixa organização ou visual pouco claro. 0,5 Material não foi feito ou está incompleto. 0 Tabela: Rubrica para autoavaliação. Curtiu o que você fez aqui? Então aproveite para começar a montar o seu portfólio! Os resultados das atividades práticas do curso podem (e devem!) ser registrados e organizados – assim, além de acompanhar • • • sua própria evolução, você ainda pode mostrar seu trabalho para colegas, professores e, quem sabe, até para recrutadores no futuro. Você pode criar seu portfólio de forma gratuita com o Adobe Express, que é super intuitivo e on-line. Veja a imagem a seguir do texto do parágrafo anterior feito na plataforma! Conteúdo interativo Acesse a versão digital para ver mais detalhes da imagem abaixo. Exemplo de imagem com texto criada no Adobe Express. https://www.adobe.com/br/express/create/online-portfolio O Scrum Histórico e definição Criado por Ken Schwaber e Jeff Sutherland, o Scrum foi apresentado em 1995 na conferência OOPSLA (Object- Oriented Programming, Systems, Languages and Applications). Alinhado com os valores e os princípios do Manifesto Ágil, o Scrum foi criado inicialmente para projetos de desenvolvimento de software, embora atualmente seja usado em outras áreas, como marketing, pesquisa e inovação. Segundo Schwaber e Sutherland (2020), o Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor com soluções adaptativas para problemas complexos. Ele é baseado no empirismo, segundo o qual o conhecimento vemda experiência e da tomada de decisão com base no que foi observado, e no lean thinking, que significa reduzir o desperdício e concentrar-se no essencial. Recomendação Revisite o tópico Quando usar os métodos ágeis para saber se o Scrum é a melhor opção para seu projeto ou sua organização. Os pilares do Scrum O Scrum tem como base três pilares. Confira! Transparência Este pilar reflete o valor do Manifesto Ágil que prioriza indivíduos e interações mais que processos e ferramentas. Para valorizar as pessoas e suas trocas, todos devem estar informados sobre os pontos mais relevantes do projeto. Os artefatos precisam ser claros e acessíveis, facilitando a compreensão e a inspeção. Inspeção Permite corrigir rapidamente qualquer impedimento ou desvio em relação ao que foi planejado. É aplicada com eventos específicos e conduz à necessidade de adaptação. Adaptação Diante de mudanças, desvios, impedimentos ou resultados indesejados, é importante identificar as causas e ajustar o que for necessário para evitar que os problemas se repitam. As pessoas envolvidas devem ter autonomia para agir rapidamente, aplicando os aprendizados obtidos durante a inspeção. Os valores do Scrum Essenciais para o sucesso dos projetos, os seguintes valores do Scrum devem ser incorporados pelo Scrum team (equipe scrum). Compromisso Todo Scrum team assume o compromisso de alcançar os objetivos traçados — como a meta da sprint — e apoiar uns aos outros. Foco A meta e os eventos da sprint, como a daily Scrum, esclarecem as atividades a serem cumpridas no dia e na sprint, direcionando os esforços de cada membro da equipe e mantendo o foco naquilo que precisa ser feito. Abertura Todos precisam estar abertos às sugestões dos demais. Alguns eventos do Scrum são propícios para identificar oportunidades de melhoria. Por isso, todos têm de estar prontos para ouvir, agregar e viabilizar essas melhorias. Respeito É fundamental para estimular as interações entre a equipe. Exercer a empatia, colocando-se no lugar do outro, melhora a convivência e os resultados da equipe como um todo. Coragem É necessário ter coragem de propor mudanças e de inovar, sem medo de errar. Os membros da equipe precisam assumir responsabilidades e acreditar que são capazes disso. Scrum team A base do Scrum é uma equipe de pessoas, o Scrum team, formado pelos seguintes elementos. Confira! SM Um Scrum master. PO Um product owner. DEVs Alguns desenvolvedores. O Scrum team também possui várias funções. Seus membros devem ter todas as habilidades e competências necessárias para gerar valor a cada sprint (evento principal do Scrum). Ele é estruturado, autogerenciável ou auto-organizado e empoderado pela organização, ou seja, seus membros têm autonomia e poder suficiente para definir o responsável por cada atividade e como colaborar uns com os outros. Para Schwaber e Sutherland (2020), o Scrum team deve ser pequeno o suficiente para se manter ágil e suficientemente grande para concluir um trabalho significativo dentro de uma sprint. Isso inclui normalmente um grupo de 10 pessoas ou menos. Equipes menores favorecem interações, melhorando a comunicação e a produtividade. Quanto maior a equipe, maior a complexidade – e não é só pela quantidade de pessoas. A fórmula para calcular isso é simples: multiplicamos o número de pessoas (N) pelo número de pessoas menos um e dividimos por dois. O resultado (R) é a quantidade de relacionamentos ou conexões necessárias dentro da equipe: Veja os exemplos: Em uma equipe com 4 pessoas, temos 6 conexões: R = 4 × (4 – 1) ÷ 2 Já em uma equipe com 6 pessoas, o número de conexões sobe para 15: R = 6 × (6 – 1) ÷ 2 Ou seja, adicionar mais pessoas significa aumentar muito mais as interações necessárias – e isso pode tornar a comunicação e a coordenação mais desafiadoras. Confira a imagem para entender e fixar! R = N × (N – 1) ÷ 2 • • Ilustração de uma equipe de Scrum e sua complexidade de comunicação. Lembre-se, não existem cargos, hierarquia e equipes especializadas no Scrum. Todos do Scrum team são responsáveis pela entrega. O sucesso ou o fracasso é da equipe, portanto, e nunca de um indivíduo. Desenvolvedores (developers) Neste vídeo, falaremos sobre os desenvolvedores (developers) e a importância de seu papel na construção do produto final. Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Executam as atividades que agregam valor ao produto que está sendo construído, sendo os responsáveis para gerar valor a cada sprint. Por esse motivo, eles devem possuir todas as funções, habilidades e competências necessárias para entregar o produto de forma iterativa e incremental. Segundo Schwaber e Sutherland (2020), os desenvolvedores são responsáveis por: Criar um plano para a sprint, representado pelo sprint backlog. Garantir a qualidade de forma contínua, seguindo a definição de pronto. Ajustar diariamente o plano conforme a meta da sprint. Assumir responsabilidade mútua como profissionais. Product owner (PO) Responsável por entender as necessidades dos clientes em relação ao produto, traduzi-las e priorizá-las para gerar o maior valor possível. Para isso, gerencia o product backlog, uma lista priorizada com tudo o que é necessário para melhorar o produto. Scrum master (SM) É o líder-servidor responsável pela eficiência do Scrum team. Como o próprio nome diz, ele é o mestre do Scrum e deve: Orientar todo o Scrum team para obter o melhor resultado do Scrum com todos os seus componentes. Proporcionar um ambiente favorável para a colaboração, para a melhoria contínua e para a autonomia da equipe. Identificar, propor e implementar formas de aumentar a produtividade e o desempenho de todas as pessoas da equipe. Ajudar e dar as condições adequadas para o Scrum team incorporar os valores do Scrum. Remover qualquer impedimento ao progresso do Scrum team. Os pilares e o Scrum team Neste vídeo, apresentamos as principais causas que levaram à criação do Scrum, bem como seus pilares de sustentação, os valores que devem ser incorporados e os papéis exercidos pela equipe. Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Verificando o aprendizado Questão 1 Qual dos valores a seguir faz parte do Manifesto Ágil? A Produtividade e desempenho mais que planejamento e execução. B Indivíduos e interações mais que processos e ferramentas. • • • • • C Software em funcionamento menos que documentação abrangente. D Contratos bem feitos levam à colaboração com o cliente. E Um bom plano reduz a necessidade de mudanças. A alternativa B está correta. "Indivíduos e interações mais que processos e ferramentas" é o único valor do Manifesto Ágil entre as opções listadas. Apesar de a produtividade e o desempenho serem preocupações dos métodos ágeis, esse não foi um dos valores incluídos no Manifesto Ágil. As demais são variações com erros dos outros valores. Questão 2 Qual das situações a seguir é a mais adequada para o uso dos métodos ágeis? A Tenho muitas dúvidas das funcionalidades do meu produto e gostaria de construí-lo por módulos e de forma incremental. B Quero construir um edifício de 12 andares. C Estou participando de uma licitação do governo para construir uma ponte. D Minha empresa foi contratada para construir um software que já tem todos os módulos e funcionalidades bem definidas em contrato com multas altas por atraso. E Estou iniciando em uma ONG que captou recursos do governo para um projeto com escopo muito bem definido, prestação de contas mensal e devolução integral do investimento no caso de não cumprimento do contrato. A alternativa A está correta. Os métodos ágeis se encaixam em um projeto desenvolvido de forma iterativa e incremental. Projetos nos quais o que será feito está muito bem definido e os riscos relacionados são muito altos não são adequados para o uso desses métodos. Nesse caso, o ideal seria uma abordagem de desenvolvimento do projeto mais preditiva. 2. Eventos e artefatos Eventosdo Scrum Os eventos no Scrum são rituais necessários para garantir o sucesso do projeto. Eles reduzem as necessidades de reuniões complementares e contribuem para manter o Scrum team focado nas entregas. Todo evento Scrum obedece a uma sequência dentro do seu evento maior (a sprint) e tem duração máxima e objetivos específicos. A sprint Neste vídeo, falaremos sobre a sprint e o papel que ela desempenha no Scrum. Apresentaremos seu funcionamento e como os demais eventos do Scrum se relacionam com a sprint. Vamos lá! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. A sprint é o coração do Scrum. Nela ocorrem os demais eventos de forma sequencial. Confira! Sprint planning Reunião de planejamento da sprint Ínicio da sprint Daily Scrum Reunião diária Ocorre todos os dias no mesmo horário e local. Sprint review Revisão da sprint Finalização da daily scrum (reunião diária). Sprint retrospective Retrospectiva ou retro Retrospectiva da sprintá feita como finalização da sprint. Após a conclusão da primeira sprint, inicia-se a segunda, e assim por diante, até o final do projeto. Veja a seguir a imagem que representa o ciclo dos eventos do Scrum: Ciclo dos eventos do Scrum. Sprint planning Tem como objetivo definir o trabalho que será feito na sprint. Sua duração máxima é de oito horas para uma sprint mensal, havendo durações menores para sprints mais curtas. De acordo com Schwaber e Sutherland (2020), o sprint planning aborda as seguintes questões: Por que essa sprint é valiosa? O que pode ser feito nessa sprint? Como o trabalho escolhido será realizado? Primeiramente, o product owner mostra o que pode agregar mais valor ao produto na sprint. Baseado nisso, o Scrum team colabora para definir a meta da sprint e verificar como ela agregará valor ao produto. Depois, com base na meta definida e nos itens do product backlog priorizados pelo product owner, os developers selecionam os itens que serão feitos. No processo de seleção, o product owner poderá fornecer explicações adicionais, e fornecer mais detalhes quando necessário. Confira o fluxograma a seguir para expandir a compreensão desse processo e interaja para ver a aplicação em um exemplo prático! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Embora seja desafiador escolher itens que possam ser totalmente concluídos durante a sprint, alguns fatores importantes contribuem para aumentar as chances de cumprir esse compromisso. Confira! 1 Clareza nas entregas Os developers devem saber claramente o que precisa ser feito para concluir os itens selecionados. • • • 2 Estimativas realistas Os developers precisam saber estimar baseando-se no desempenho passado e na capacidade futura. 3 Planejamento detalhado Para cada item do product backlog selecionado, os developers planejam o trabalho necessário decompondo cada item em atividades menores. Construídos no sprint planning, a meta da sprint, os itens selecionados do product backlog e o planejamento para entregá-los compõem o sprint backlog. Daily Scrum Tem como objetivo revisar o que será feito no dia e inspecionar o que foi realizado versus o que foi planejado, medindo, para tal, o progresso em direção à meta da sprint. Essa inspeção diária pode levar a ajustes no sprint backlog, havendo correções no detalhamento do que foi planejado e até nos itens selecionados. A daily Scrum ocorre diariamente sempre no mesmo horário e local para reduzir sua complexidade. Tem duração máxima de 15 minutos e conta com a participação de todos os developers. Ela é responsável por: Reduzir de forma significativa reuniões adicionais. Aumentar a coesão dos developers. Agilizar a tomada de decisão, a remoção de impedimentos e a adaptação sempre que necessário. No final da sprint, ocorrem dois eventos com objetivos distintos: sprint review e sprint retrospective. Veremos mais detalhes a seguir. Sprint review Tem como objetivo inspecionar o resultado da sprint e adaptar o que for necessário. Sua duração máxima é de quatro horas para uma sprint mensal, ocorrendo durações menores para sprints mais curtas. Normalmente, os developers apresentam o que foi realizado e aquilo que foi agregado ao produto. Com base na apresentação, os participantes colaboram para definir os próximos passos. Comentário Durante a sprint review, é comum que o product backlog seja ajustado, com revisões no detalhamento e na priorização. Esses ajustes servirão de base para a próxima sprint planning. • • • Sprint retrospective Trata-se do evento que conclui a sprint. Seu objetivo é identificar oportunidades de melhoria de desempenho e qualidade. A duração máxima é de três horas para uma sprint mensal, havendo durações menores para sprint mais curtas. O Scrum team avalia os resultados da sprint considerando as interações entre as pessoas, além dos processos e das ferramentas utilizados. Desvios, impedimentos e suas causas são discutidos, assim como a necessidade de ações preventivas para que não se repitam. Ao identificar oportunidades relevantes, é importante encaminhá-las e, se necessário, incluí-las no sprint backlog. Recapitulando os eventos, confira a seguir os objetivos e as particularidades de cada evento! Sprint Duração máxima e características: um mês. Objetivo: criar um incremento no produto que pode ser liberado. Sprint planning Duração máxima e características: oito horas para uma sprint de um mês. Objetivo: definir o sprint backlog. Daily Scrum Duração máxima e características: quinze minutos; mantida no horário e local todos os dias para reduzir a complexidade; participação obrigatória dos developers. Objetivo: inspecionar o progresso em direção à meta da sprint. Sprint review Duração máxima e características: quatro horas para uma sprint de um mês; reunião informal com apresentação do incremento para motivar, obter feedback e promover a colaboração; participam o Scrum team e, eventualmente, clientes convidados pelo product owner. Objetivo: Inspecionar o resultado da sprint. Sprint retrospective Duração máxima e características: três horas para uma sprint de um mês; ocorre no último dia da sprint depois da sprint review para "fechá-la". Objetivo: identificar pontos de melhoria a serem implementados na próxima sprint. Artefatos do Scrum São usados para documentar o que será feito, garantindo o alinhamento entre os envolvidos e a transparência para o Scrum team. Artefatos do Scrum também servirão de referência para a inspeção e para avaliar o progresso do trabalho, sendo adaptados sempre que for necessário. O product backlog, o sprint backlog e o incremento Neste vídeo, falaremos sobre as características e quais são os atores na construção do product backlog, sprint backlog e o incremento. Vamos lá! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Product backlog De acordo com Duarte (2016), o product backlog é uma lista ordenada por prioridade de tudo aquilo que deve ser necessário no produto e a origem única dos requisitos para qualquer mudança a ser feita nele. A imagem a seguir ilustra o product backlog. Veja! Product backlog. Gerenciado exclusivamente pelo product owner, o product backlog é atualizado continuamente. Para evitar distrações com demandas futuras, deve ser mantido fora do foco dos developers. Além disso, precisa conter uma meta do produto, que representa o objetivo de longo prazo e orienta o trabalho do Scrum team, funcionando como um compromisso compartilhado. Histórias de usuário (user stories) São pedidos do cliente escritas como histórias — narrativas breves sob a perspectiva do usuário. Devem ser claras, acionáveis e pequenas o bastante para serem concluídas dentro de uma sprint. As histórias devem ser redigidas no formato: Como usuário eu quero algo, para que eu consiga atingir determinado objetivo – framework: Como [tipo de usuário], eu quero [ação], para que [benefício]. Atenção Como cliente, eu quero fazer login com a possibilidade de utilizar single signon pela conta corporativa Google para que o acesso seja rápido e seguro. Tarefas (tasks) São as atividades que a equipe precisa realizar para concluir uma história de usuário. Geralmente, essas atividades são definidas por quem executa o trabalho (desenvolvedores), enquanto as histórias de usuário costumam ser criadas pelo product owner. Exemplo e prática Agora que vimos o conceito de backlog do produto, histórias de usuários e as tarefas (tasks), que tal exercitarmos esse conhecimento de maneira prática? Para isso, te convidamos a avaliar o cenário, vestir a capa de product owner e preparar o backlog do seu produto. Vamos lá! Cenário do projeto: aplicativo de agendamento para clínicas médicas Você foi contratado como product owner (PO) para um projeto de desenvolvimento de um aplicativo que permita aos pacientes agendarem consultas médicas em clínicas particulares. O objetivo do produto é facilitar o processo de marcação de consultas, oferecendo uma experiência rápida, intuitiva e segura, tanto para os pacientes quanto para os profissionais da clínica. Seu desafio é construir os primeiros elementos do product backlog com base nesse contexto. Sua tarefa: Defina uma meta geral do produto (objetivo de longo prazo). Crie de três histórias de usuário com base nas necessidades dos usuários do app. Para cada história, proponha pelo menos duas tarefas que poderiam ser executadas por desenvolvedores durante a sprint. Agora que o cenário foi apresentado, utilize a ferramenta a seguir para montar seu backlog! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Agora que você fez seu trabalho como product onwer e montou o backlog, vamos avaliar e comparar nosso exemplo com suas respostas. Veja nosso exemplo de backlog do produto! Sprint backlog O sprint backlog é criado na sprint planning e adaptado sempre que necessário. Algumas questões ajudam no direcionamento de sua criação. Confira! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. A sprint backlog é de responsabilidade dos developers e serve como foco e compromisso de entrega até o final da sprint, etapa em que ele será revisado e validado na sprint review. No decorrer da sprint, os itens e o detalhamento da sprint backlog são adaptados e refinados. • • • https://stensineme.blob.core.windows.net/hmlgrepoh/hubexp/objetos_customizados_cms/141500/postit/fixo.html Incremento É a entrega em forma de valor para o produto em desenvolvimento, o qual precisa atingir a meta do produto. Em outras palavras, trata-se da materialização do product backlog em produto a ser consumido por seus clientes. Um incremento só é considerado válido quando atende à definição de pronto — uma descrição que estabelece os critérios de qualidade necessários para garantir que o item esteja conforme os padrões exigidos para o produto. Cada sprint gera um novo incremento, que é adicionado aos incrementos anteriores. Juntos, eles devem funcionar de forma integrada, compondo o produto a ser usado pelos seus clientes. A decisão de liberar o incremento e o produto para seus clientes tem de ser feita baseada na meta do produto e na estratégia da organização. Cada sprint deve criar um ou mais incrementos, os quais, por sua vez, são apresentados e validados na sprint review. Atenção Em situações específicas, o incremento pode ser liberado independentemente da sprint review. Recapitulando os artefatos, veja no quadro a seguir quem são os responsáveis por cada um deles e qual é sua respectiva meta. Artefato Responsável Meta a ser atingida Product backlog Product owner Meta do produto Sprint backlog Developers Meta da sprint Incremento Scrum team Definição de pronto Quadro: Resumo dos artefatos do Scrum. Eduardo Montes. Para fixar de maneira visual, confira no infográfico a seguir o Scrum framework! Conteúdo interativo Acesse a versão digital para ver mais detalhes da imagem abaixo. Scrum framework. Os eventos e os artefatos do Scrum Neste vídeo, falaremos sobre os artefatos e os eventos do Scrum, e como usá-los para obter sucesso nos projetos. Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Vamos à prática! Agora é a sua vez de experimentar como funciona o planejamento de uma sprint! Você vai assumir o papel de quem realmente faz acontecer em uma equipe ágil e simular o primeiro passo de um projeto real. É uma forma divertida e prática de entender o que rola por trás dos bastidores do Scrum. Então, vamos lá! Crie suas histórias, pense nas tarefas e monte seu primeiro sprint backlog. Ah, e não precisa ficar perfeito – o mais importante é aprender fazendo! Estudo de caso: é hora de colocar a mão na massa! Cenário Você recebeu um convite de uma startup fictícia para ajudar no planejamento da primeira sprint de um projeto de criação de uma landing page para um curso on-line. Seu desafio é planejar essa sprint, assumindo o papel de product owner e developer, além de gerar os elementos fundamentais da sprint planning. Você vai realizar essa atividade, utilizando um quadro no Miro (modelo visual com post-its). Caso ainda não tenha uma conta no Miro, veja as dicas para criá-la: Acesse o site da ferramenta. Selecione [Login] no menu superior direito. Escolha a opção que permite o login com sua conta Microsoft 365. Aceite as permissões solicitadas. • • • • https://miro.com/pt/ Em Qual é o nome do seu time?, entre com o nome do seu curso. Em Que tipo de trabalho você faz?, selecione [Professor/Estudante]. Em Qual é a sua função?, selecione [Contribuidor individual]. Responda se já usou o Miro alguma vez. Em Qual é o tamanho da sua empresa?, selecione [Somente eu]. Clique em [Continuar]. Em convidar colegas de time, selecione [Ignorar por enquanto] e [Pular passo] Pronto! Agora você já pode utilizar o Miro para criar o seu quadro. Confira o que você precisa entregar! Definição da meta da sprint Escreva uma frase clara que defina o objetivo principal da sprint, como: “Criar o primeiro protótipo navegável da landing page com formulário de contato funcional". Criação de histórias de usuário (User stories) Crie de 3 a 5 histórias de usuário relacionadas à landing page. Use o formato: Como [tipo de usuário], eu quero [ação], para que [benefício]. Exemplos: Como visitante, eu quero ver uma apresentação clara do curso, para eu entender seus diferenciais. Como estudante, eu quero preencher um formulário rápido, para eu receber informações por e-mail. • • • • • • • • • • Quebra em tarefas Para cada história de usuário, liste de 2 a 4 tarefas técnicas que você realizaria como developer. Exemplo (para a história do formulário): Criar o layout do formulário. Conectar o formulário a um sistema de e-mail. Testar o funcionamento do envio de dados. Criação da sprint backlog Organize tudo que foi definido (meta + histórias + tarefas) como se estivesse criando sua sprint backlog. Você vai fazer o sprint backlog em um quadro visual com post-its em colunas no Miro. Veja o exemplo: Exemplo de sprint backlog. O que deverá conter no quadro do Miro: Meta da sprint. De 3 a 5 user stories. Tarefas associadas a cada história. Sprint backlog montado. Lembre-se que a prática ajuda a aperfeiçoar cada vez mais seu entendimento. Sempre mantenha o hábito da prática e tente estar antenado às plataformas e ferramentas disponíveis no mercado! • • • • • • • Verificando o aprendizado Questão 1 Qual é o evento do Scrum no qual somente a participação dos developers é obrigatória? A Sprint B Sprint planning C Daily Scrum D Sprint review E Sprint retrospective A alternativa C está correta. A daily Scrum é o único evento que somente a participação dos developers é suficiente. A participação do Scrum master e do product owner é opcional. Questão 2 Qual é o artefato do Scrum que contém o que deve ser feito para o produto? A Product gap B Sprint backlog C Product backlog D Incremento E Meta doproduto A alternativa C está correta. O product backlog contém todos os itens a serem construídos para o produto e é a única origem dos requisitos para qualquer mudança a ser feita nele. 3. Técnicas Técnicas complementares ao Scrum O guia do Scrum não inclui ferramentas e técnicas explicando como os itens de backlog devem ser estimados ou priorizados, tampouco demonstra como os eventos têm de ser conduzidos ou monitorados. Você conhecerá a partir de agora algumas das técnicas mais usadas no mercado e consideradas essenciais para o sucesso do Scrum. Técnicas para priorizar Vamos começar pelas técnicas usadas para priorizar o product backlog, etapa essencial para definir quais itens devem ser selecionados com foco em gerar o maior valor possível para o produto. A responsabilidade por essa priorização é do product owner. Já a escolha dos itens que serão trabalhados ocorre durante o sprint planning, primeiro evento da sprint, resultando na criação do sprint backlog. Relembrando O product backlog e o sprint backlog são artefatos do Scrum. Já o sprint planning constitui um evento do Scrum. MoSCoW É uma técnica muito usada em gestão de projetos para priorizar o escopo, os requisitos e as solicitações de mudanças. Nos métodos ágeis, ele serve para priorizar os itens do product backlog devido à facilidade de uso, à simplicidade e à rápida priorização. MoSCoW é um acrônimo em inglês usado para classificar cada um dos itens do product backlog em quatro categorias possíveis: Must have Deve ter Item obrigatório para o produto (prioritário para a próxima sprint). Should have Deveria ter Item muito importante para o produto, mas não obrigatório. Could have Pode ter Item desejado, porém não tão importante quanto o should have. Won’t have Não terá Não será necessário conhecê-lo por enquanto. Você pode customizar a técnica e até reduzir as categorias para a classificação conforme a necessidade da sua organização. Uma variação comum é o uso de só duas categorias: must have (obrigatório) e nice to have (desejado). Análise de decisão envolvendo critérios múltiplos Significa selecionar dois ou mais critérios e estipular um peso para cada um dos critérios. Ela retira um pouco da subjetividade da classificação por estabelecer critérios bem definidos e discutidos previamente. Essa análise pode ser usada para: Priorizar qualquer lista de itens ou de ideias. Solicitar mudanças, requisitos, projetos, pessoas e itens do product backlog no Scrum. Neste vídeo, veja como a análise de decisões envolvendo critérios múltiplos pode ser aplicada e como ela funciona. Vamos lá! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Técnicas para estimar: Scrum poker Também conhecido como planning poker, o Scrum poker é uma técnica usada para estimar por meio de um jogo de cartas baseado em consenso (que, aliás, vem ganhando a cada dia mais adeptos nos métodos ágeis). Ele parte da premissa de que quem executa deve ser o mesmo que estima. Os developers são mais comprometidos quando estimam o esforço das suas atividades. Reflexão Você se compromete com aquilo que você fala, com sua palavra ou com sua estimativa, mas não o faz com algo sobre o qual não foi consultado e nem sabe se é possível cumpri-lo. Antes de definir estimativas, há duas atividades que precisam ser realizadas. Confira! Para cada item selecionado, detalham-se as atividades necessárias e estima-se o esforço para cada atividade (no momento que se inicia o Scrum poker). Usaremos, então, como premissa a hipótese de que já possuímos as atividades relacionadas, aguardando somente suas estimativas. Veja agora os passos para aplicar essa técnica. Descrição do item Primeiramente, o product owner descreve o item a ser estimado. Esclarecimento de dúvidas Os developers o avaliam e tiram suas dúvidas. Item esclarecido para os developers, pode-se iniciar a votação. Seleção da carta Cada developer seleciona a carta com os pontos de acordo com o esforço necessário para o item baseado em critérios bem definidos. Votação Cada developer apresenta sua carta de forma simultânea para comparação. Se existir consenso, será possível seguir para o próximo item; caso contrário, inicia-se um debate – normalmente, com as argumentações da maior e da menor carta – e vota-se novamente. O processo se repete até haver um consenso. Observe a seguir a proposta de seleção para cada carta: Carta 0 – Já foi! Nome da carta: Tarefa inexistente Descrição: Essa tarefa nem precisa ser feita. Pode ser que ela já esteja pronta, não faça mais sentido ou esteja duplicada no backlog. Quando usar: Quando você perceber que alguém adicionou uma tarefa que não tem mais valor, ou cuja entrega já aconteceu por outro caminho. Mensagem para o time: “Essa aqui já foi. Melhor focarmos o que realmente importa agora”. 1º Definição da meta da sprint. 2º Seleção dos itens do product backlog para a sprint. Carta 1 – É moleza! Nome da carta: Tarefa muito simples Descrição: Essa tarefa é bem rápida de resolver. Provavelmente leva menos de uma hora para ser concluída. Não exige grandes discussões nem planejamento. Quando usar: Ideal para tarefas como: ajustar um texto, trocar uma imagem, corrigir um link quebrado ou revisar um pequeno trecho de código. Mensagem para o time: “Deixa comigo, antes do café eu já termino isso". Carta 2 – Rapidinho, mas com calma Nome da carta: Tarefa simples Descrição: É uma tarefa tranquila, mas que exige um pouco mais de atenção. Provavelmente será resolvida em meio turno de trabalho, como uma manhã ou uma tarde. Quando usar: Boa para tarefas como ajustar um layout, revisar um documento, escrever uma funcionalidade pequena, ou montar um rascunho de algo mais elaborado. Mensagem para o time: "Deixa que eu pego essa. Ainda dá tempo de terminar antes do almoço" Carta 3 – Simples… mas não subestime! Nome da carta: Tarefa simples, porém trabalhosa Descrição: A tarefa parece simples, mas exige mais tempo ou esforço. Ela pode até ser feita em um turno de trabalho, mas vai tomar energia e foco. Não é só apertar um botão! Quando usar: Boa para tarefas como montar um formulário completo, revisar um conteúdo extenso, ou reorganizar um fluxo simples, mas cheio de detalhes. Mensagem para o time: “Parece fácil, mas já vi tarefa assim virar maratona. Bora fazer direito!”. Carta 5 – Dia cheio pela frente Nome da carta: Tarefa de complexidade média Descrição: Essa tarefa exige atenção, organização e um bom tempo de trabalho. Provavelmente tomará um dia inteiro de um desenvolvedor ou membro da equipe, se não houver impedimentos. Quando usar: Ideal para tarefas como desenvolver uma funcionalidade nova do sistema, criar um documento técnico, ou testar algo com vários cenários. Mensagem para o time: “Essa aqui é do tipo que preenche a agenda do dia. Bora focar e entregar bem!”. Carta 8 – Agora complicou um pouco Nome da carta: Tarefa complexa Descrição: Essa tarefa envolve mais incertezas, estudo ou várias etapas de execução. Provavelmente levará de 2 a 3 dias de trabalho intenso. Quando usar: Use para tarefas que exigem investigar, testar, prototipar, ou integrar sistemas diferentes. Também vale quando há dependência de outras pessoas ou times. Mensagem para o time: “Essa a gente precisa planejar direitinho. Não dá para sair fazendo sem pensar”. Carta 13 – Missão da semana Nome da carta: Tarefa muito complexa Descrição: Essa tarefa é robusta, cheia de detalhes e incertezas. Vai demandar estudo, discussão e um bom tempo de desenvolvimento. Leva em média a semana inteira de um profissional para ser realizada com qualidade. Quando usar: Use para tarefas como montar uma nova feature com várias etapas, criar uma integração grande entre sistemas, ou refatorar uma parte crítica da aplicação. Mensagem para o time: “Essa tarefa merece atenção total. Vamos dividi- la bem para entregar valor sem nos atropelar”. Carta 20 – Grande demais para ser estimada Nome da carta: Tarefa complexa demais Descrição: Essatarefa é tão grande ou indefinida que não vale a pena tentar estimar como está. Ela precisa ser quebrada em partes menores para que o time consiga entender e planejar melhor. Quando usar: Quando a descrição da tarefa é vaga, envolve várias entregas diferentes, ou parece que vai consumir várias semanas sem um caminho claro. Mensagem para o time: “Antes de estimar isso aqui, vamos quebrar em pedaços menores. Assim conseguimos ver onde estamos pisando”. Carta ? – Não entendi nada! Nome da carta: Tarefa incompreendida Descrição: Essa carta é usada quando a tarefa está mal explicada, confusa ou cheia de lacunas. Você precisa de mais informações antes de fazer qualquer estimativa. Quando usar: Quando o item do backlog parece um enigma ou está mal descrito: não dá para saber o que precisa ser feito, como, nem por quê. Mensagem para o time: "Alguém pode explicar melhor isso aqui? Porque agora é tudo um grande mistério”. Carta ∞ – Essa tarefa não cabe em lugar nenhum! Nome da carta: Tarefa impossível no momento Descrição: Essa tarefa é tão longa, complexa ou fora da realidade atual que simplesmente não cabe no pipeline de desenvolvimento. É praticamente irrealizável da forma como foi descrita. Quando usar: Quando a tarefa é desproporcional, sem início, meio ou fim definidos, ou quando exigiria semanas ou meses de trabalho sem clareza. Mensagem para o time: “Essa aqui vai precisar virar outra coisa. Ou a gente quebra, ou a gente conversa sério com o product owner”. Carta Café – Vamos dar um tempo? Nome da carta: Pausa estratégica Descrição: Essa carta não tem valor de estimativa. Ela aparece quando o time já está saturado de tantas estimativas, discussões ou tarefas puxadas – e precisa de uma pausa para arejar as ideias e retomar o foco. Quando usar: Quando o clima estiver tenso, a energia cair ou as estimativas começarem a virar um “chute” automático. É o sinal de que é hora de levantar, tomar um café, respirar… e voltar melhor. Mensagem para o time: “Já deu por agora. Bora tomar um café e depois a gente continua com a cabeça mais leve.” Agora que você já entendeu cada carta, baixe e utilize seu Baralho Scrum. Também é possível utilizar outra variação on-line, o AgilePoker. Velocidade Como todos os itens têm seus pontos calculados, a capacidade de entrega de pontos da equipe (denominada velocidade) é verificada dentro de cada sprint. A velocidade se torna um parâmetro fundamental para determinar a quantidade de itens a serem incluídos em cada sprint. Exemplo Se a velocidade da equipe é igual a 100 pontos, não se pode escolher um número de itens, os quais, somados, superem os 100 pontos. Vamos jogar para planejar? Chegou a hora de usar seu baralho de planejamento ágil e mostrar que você manda bem na arte de estimar tarefas! Nessa atividade, você vai olhar para as tarefas do seu sprint backlog, dar pontos de esforço com base nas cartas e decidir o que realmente cabe na sprint, respeitando a velocidade do time. É como montar um quebra-cabeça de produtividade – e você é quem escolhe as peças certas. Vamos lá praticar de um jeito leve, visual e com foco no que importa! Cenário Você atuará como parte de uma equipe Scrum que está planejando sua primeira sprint. A meta da sprint e as histórias de usuário já foram definidas na atividade anterior (Sprint planning), e agora você precisa atribuir pontos de esforço a cada tarefa do sprint backlog, usando as cartas do baralho de planejamento ágil como referência. Além disso, a capacidade de entrega da equipe nesta sprint foi estimada como sendo 40 pontos (velocidade). Isso significa que a soma dos pontos das tarefas que você selecionará não pode ultrapassar 40 pontos. Materiais e ferramentas Confira o que será necessário para a atividade: https://cdn-conteudo.ensineme.com.br/Baralho_Scrum_29b26b3faa.pdf https://agilepoker.app/ Seu sprint backlog da atividade anterior. O baralho de planejamento ágil (referência a seguir). O quadro do Miro da atividade anterior. Passo a passo da atividade Atenção ao passo a passo! Revise seu sprint backlog Abra seu arquivo anterior da atividade de sprint planning e revise as histórias de usuário e as tarefas relacionadas a cada uma delas. Estime o esforço de cada tarefa Para cada tarefa, atribua um ponto com base no baralho de planejamento ágil, usando as seguintes cartas como referência: 0, 1, 2, 3, 5, 8, 13, 20, ?, ∞ e Café (pausa). Atenção: se você usar as cartas [20], [∞] ou [?] para alguma tarefa, isso indica que ela não deve entrar na sprint por estar mal definida ou grande demais. Selecione as tarefas da sprint Com base nos pontos atribuídos e no limite da velocidade de 40 pontos, escolha apenas as tarefas que cabem nesse limite. Exemplo: se você estimou 8 tarefas e elas somam 52 pontos, será preciso priorizar e selecionar apenas aquelas que somem até 40 pontos. Justifique suas escolhas Para pelo menos 3 tarefas estimadas, escreva brevemente o motivo da pontuação atribuída com base na descrição do baralho. Exemplo: A tarefa Criar página de login recebeu 5 pontos porque exige montar layout, testar e integrar com back-end, o que representa aproximadamente um dia inteiro de trabalho. Agora volta lá no seu portfólio e acrescenta mais essa entrega. Como vai ficar o seu quadro no Miro: Lista de tarefas com pontuação atribuída (carta). • • • • Total de pontos da sprint. Indicação de quais tarefas entraram na sprint (até 40 pontos). Justificativas de pelo menos três tarefas. Método Kanban Neste vídeo, apresentaremos o quadro Kanban, falaremos de suas origens e como ele funciona e pode ajudar seu fluxo de trabalho no desenvolvimento ágil com o Scrum tema. Vamos lá! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Importância do Kanban como complemento ao Scrum A 15ª edição da pesquisa State of Agile apresenta uma classificação dos métodos ágeis mais adotados: 1° lugar Scrum Presente em 66% das organizações da pesquisa. 2° lugar ScrumBan Presente em 9% das organizações da pesquisa. 3° lugar Kanban Presente em 6% das organizações da pesquisa. O ScrumBan é o uso do Scrum complementado pelo método Kanban, que será explorado neste tópico. Criado por Taiichi Ohno em 1953, na Toyota, o Kanban é um método de gestão visual do trabalho que ajuda a definir, organizar e melhorar processos. A palavra Kanban, de origem japonesa, significa cartão. O método é simples de aplicar e torna o fluxo de trabalho mais visível, além de melhorar a comunicação entre os envolvidos. O Kanban utiliza um quadro — o chamado quadro Kanban — onde cartões representam as tarefas e avançam conforme o trabalho progride. Um exemplo comum é o uso de um quadro com três listas: Para fazer, Fazendo e Feito. As tarefas são criadas na primeira lista, movidas para a segunda quando a execução começa e, após a conclusão, seguem para a terceira lista. • • • Um exemplo mais comum dele é um quadro Kanban para controlar pendências em que a pendência é criada na lista “Para fazer”. Quando se inicia a atividade, movimenta-se para “Fazendo”. Por fim, ao finalizar, a atividade é movimentada para “Feito”. Confira a configuração do quadro na tabela a seguir! Quadro Kanban Para fazer Fazendo Feito Tabela: Exemplo de quadro Kanban para controlar pendência. Eduardo Montes. Esse quadro Kanban pode ser: Físico Empregam-se cartões post-its (para representar cada item) que vão se movimentando em cada lista conforme o seu progresso no fluxo. Virtual Seu uso ocorre por intermédio de inúmeros softwares disponíveis no mercado. O quadro Kanban é ideal para dar a transparência ao Scrum team, um dos pilares do Scrum. A visualização do fluxo de trabalho apresenta, de forma clara e fácil, como anda o progresso dos itens de trabalho dos artefatos do Scrum nas seguintes etapas: Criação no product backlog. Desenvolvimento no sprint backlog. Finalização como um incremento. Analise agora um exemplo de quadro Kanban usado no desenvolvimento desoftware com o Scrum! Quadro Kanban Product backlog FaSprint backlog [5] Incremento • • • Quadro Kanban Desenvolvimento [5] Teste [5] Deploy P/ fazer Fazendo P/ fazer Fazendo P/ fazer Fazendo Tabela: Exemplo de quadro Kanban para desenvolvimento de software com Scrum. Eduardo Montes. Como implementar o Kanban no Scrum De acordo com Vacanti e Yeret (2018), cada Scrum team deve criar sua definição de fluxo de trabalho contendo os seguintes elementos: Definição de como considerar o trabalho iniciado e finalizado. Definição das unidades individuais de valor do cliente que estão fluindo por meio do sistema (provavelmente, itens do product backlog). Definição do fluxo de trabalho das unidades individuais com cada estágio do início ao fim do fluxo. Políticas sobre como o trabalho flui por meio de cada estágio, como a definição de pronto e políticas de transferência entre estágios. Definição de como o trabalho em progresso (WIP - work in progress) será limitado. Expectativa de nível de serviço (SLE - service level expectation) definida que comunica uma previsão de quanto tempo deve levar para concluir os itens de trabalho. Práticas do Kanban aplicadas ao Scrum Algumas práticas do Kanban podem ser integradas ao Scrum para tornar o processo mais eficaz. Veja! Visualização do fluxo de trabalho Aqui estão algumas dicas do que você deve observar: Definir o fluxo acima com seus elementos. É necessário definir como e onde ele será apresentado e gerenciado. Pode ser em um quadro físico, com o uso de post-its, ou um virtual, implementado em algum software de gestão. • • • • • • • • • Limitação do trabalho em progresso Toda a construção de conteúdo deve ser clara e limitada. Para isso, observe os seguintes pontos: Trabalho em progresso é tudo que foi iniciado e ainda não foi concluído. O Kanban trabalha com limitações do trabalho em progresso, concentrando-se nos itens de trabalho em cada um dos estágios do fluxo. Os limites de trabalho em progresso podem ser por estágio ou por agrupamento dos estágios. Usando o quadro Kanban de exemplo para o desenvolvimento de software apresentado acima, se o limite do estágio desenvolvimento for igual a 5, nunca haverá mais de 5 itens de desenvolvimento em progresso. As limitações do trabalho em progresso contribuem para o Scrum teams manter o foco e o comprometimento, além de aumentar a colaboração. Gestão ativa de itens de trabalho em andamento Tal gestão ocorre ao se: Remover agilmente os impedimentos dos itens de trabalho. Garantir que os itens de trabalho serão concluídos conforme o nível de serviço esperado. Desobstruir itens de trabalho acumulados em um estágio do fluxo. Inspeção e adaptação da definição do fluxo de trabalho Acha que acabou? Claro que não! A recuperação e a revisão são fundamentais. A sprint retrospective é uma grande oportunidade para que o fluxo de trabalho e seus elementos sejam revisados. Pequenas mudanças podem fazer uma grande diferença no desempenho do Scrum team. As mudanças devem ser sempre avaliadas e adaptadas conforme seus resultados. Métricas do Kanban Todas as métricas dispostas a seguir são calculadas tendo como base as definições do fluxo de trabalho e seus elementos detalhados no tópico Como implementar o Kanban no Scrum. • • • • • • • • • • Trabalho em progresso WIP Número de itens de trabalho iniciados, mas não concluídos. Tempo de ciclo Cycle time Tempo decorrido do início do item de trabalho até sua conclusão. Idade do item de trabalho Work item age Tempo decorrido do início do item de trabalho até a hora atual. Taxa de entrega Throughput Número de itens de trabalho concluídos por unidade de tempo. Para calcular tempo de ciclo, é necessário que o Scrum team registre a data e a hora em que se iniciou o item de trabalho e quando ele terminou. Vamos organizar esse fluxo! Agora é a sua vez de montar seu próprio quadro Kanban e visualizar o caminho das tarefas até a entrega! Essa atividade é para você experimentar, na prática, como o Kanban ajuda a deixar tudo mais claro, focado e fluindo de forma mais leve. Dá para ver onde está travando, o que já foi feito e o que ainda está por vir. É como um GPS do seu projeto! Então, separe seus post-its (virtuais ou não) e construa seu quadro! Estudo de caso: na rotatória, vire à quarta direita: cuidado para não voltar ao mesmo lugar! Agora que você já definiu as histórias de usuário, quebrou em tarefas e estimou o esforço com o baralho de planejamento ágil, é hora de organizar tudo visualmente utilizando o Kanban. Você irá montar seu próprio quadro Kanban, simulando o andamento da sprint, com colunas que representam o fluxo de trabalho e cartões representando as tarefas. Para essa atividade, vamos utilizar uma ferramenta nova, o Jira. Confira o passo a passo inicial! Acesse o site do Jira. Crie uma conta ou utilize a sua conta Google ou Microsoft para acessar a ferramenta. Crie um nome para o seu ambiente de trabalho (site). Escolha um template, que, no caso, será o Kanban, e aguarde a finalização da construção do quadro. 1. 2. 3. 4. https://www.atlassian.com/br/software/jira Forneça um nome para o seu projeto (Kanban). Passo a passo da atividade Confira com atenção o passo a passo e faça a atividade! Monte seu quadro Kanban com 4 colunas Você pode nomeá-las assim: Backlog da sprint (tarefas selecionadas, ainda não iniciadas). A fazer (tarefas prontas para começar). Em andamento (tarefas iniciadas – aqui aplicaremos o limite de WIP). Concluído (tarefas finalizadas). Organize suas tarefas Pegue as tarefas do seu sprint backlog estimado na atividade anterior. Crie um cartão para cada tarefa e inclua: Título da tarefa. História de usuário relacionada. Pontuação estimada (carta do baralho). Pessoa responsável. Simule o andamento das tarefas Movimente os cartões pelas colunas, simulando o desenvolvimento de uma sprint (como se fosse um dia a dia de trabalho). Você deve indicar: Quais tarefas estão em andamento. Quais já foram concluídas. Quais ainda não foram iniciadas. 5. • • • • • • • • • • • Aplique um limite de WIP (Work in progress) Defina um limite de 3 tarefas na coluna Em andamento. Se houver mais que isso, registre qual tarefa precisaria esperar e o porquê. Exemplo: A tarefa X só pode começar quando uma das tarefas atuais for concluída. Capture uma imagem ou exporte seu quadro No Jira, tire um print ou exporte o link do quadro. Confira, a seguir, um exemplo de um quadro Kanban feito no Jira, adicionando o campo pontuação. Conteúdo interativo Acesse a versão digital para ver mais detalhes da imagem abaixo. Exemplo de quadro Kanban feito no Jira. Agora, veja a continuação para a criação do campo pontuação. Conteúdo interativo Acesse a versão digital para ver mais detalhes da imagem abaixo. • • • Exemplo da adição do campo pontuação. Conteúdo interativo Acesse a versão digital para ver mais detalhes da imagem abaixo. Finalização do exemplo. Transforme sua prática em vitrine! Agora que você montou seu próprio quadro Kanban, que tal dar um passo além e incluir esse resultado no seu portfólio? Além de mostrar que você está colocando a teoria em prática, isso ajuda a destacar suas habilidades de organização, planejamento e pensamento visual – competências supervalorizadas em qualquer área! É uma forma de mostrar, com exemplos reais, como você aplica métodos ágeis no seu dia a dia de estudos. Então, publique! Seu portfólio é sua melhor vitrine! O que você deverá publicar: Seu quadro Kanban completo, com pelo menos 6 tarefas organizadas nas colunas. A indicação do limite de WIP na coluna Em andamento. • • Um pequeno parágrafo (5 linhas) explicando: Por que é importante limitar o WIP; Como você fez sua simulação. Técnicas para facilitar eventos Sprint planning O evento que inicia a sprint tem como objetivo definir o sprint backlog. Para queo sprint backlog seja produtivo, será necessário que, antes do evento, o product owner atualize o product backlog, incluindo a priorização e o detalhamento dos itens potenciais na seleção para a próxima sprint. Já no sprint planning, é importante observar os seguintes pontos: O Scrum master deve atuar como facilitador do evento. Toda a equipe Scrum deve participar ativamente. O product owner inicia a reunião apresentando os itens priorizados do backlog e esclarecendo dúvidas dos developers. Com base nessas explicações, os developers detalham os itens selecionados em tarefas, incluindo suas estimativas. Quando os developers considerarem que já têm trabalho suficiente para a sprint, o sprint backlog é finalizado e o evento é encerrado. Relembrando As métricas do Kanban funcionam como parâmetros para selecionar quantos itens do product backlog farão parte da sprint. Por exemplo, se o time tem uma taxa de entrega de 10 itens de product backlog por cada sprint, você já sabe que deverá escolher até 10 itens. Nesse caso, também é recomendado incluir um limite de trabalho em progresso de 10 itens para a sprint. A técnica do Scrum poker pode ser usada pelos developers para o detalhamento dos itens do product backlog. Daily Scrum Veja agora algumas das melhores práticas em relação à daily Scrum: A reunião deve ocorrer sempre no mesmo horário e local, que deve ser de frente para o quadro Kanban. Todos ficam de pé durante toda a duração do evento. Todos têm de falar e responder às seguintes questões: Todo trabalho planejado na última daily Scrum foi realizado? Existe algum impedimento para a realização do trabalho? Qual trabalho será feito nas próximas 24 horas? Você pode utilizar um baralho de apenas 3 cartas, que será utilizado por cada uma das pessoas da equipe, para facilitar a visualização e comunicação de todas as pessoas durante a reunião. • • • • • • • • • • Confira na imagem a seguir o baralho de 3 cartas que pode ser utilizado para Daily Scrum! O que estou fazendo? O cartão da tarefa deve estar atualizado no quadro Kanban. Quais os impedimentos? Internos e/ou externos. O que vou fazer? Você deve adicionar um cartão no quadro Kanban. Sprint review A sprint review ocorre no último dia da sprint para inspecionar o resultado dela, determinando, assim, as adaptações futuras. Para que ela seja produtiva, será necessário que, antes do evento, sejam feitas algumas avaliações por parte dos envolvidos: Person Product owner Deve avaliar quais clientes podem ajudar na review e deverá convidá-los. Groups Developers Devem avaliar a melhor forma de apresentar o resultado da sprint. Já na sprint review, é importante que: Ela seja facilitada pelo Scrum master. O incremento do produto seja apresentado para apreciação e feedback do product owner e dos clientes presentes. Trabalho planejado versus o que foi realizado seja avaliado (itens do sprint backlog concluídos e os não concluídos). As métricas sejam revisadas. Sprint retrospective É realizada logo após a sprint review e tem como principal objetivo analisar e refletir sobre os processos da equipe, para melhorá-los para a próxima sprint, principalmente para encontrar potenciais soluções para os problemas enfrentados e impedimentos ocorridos. Durante a sprint retrospective, é importante considerar os seguintes pontos, confira! 1 Facilitação pelo Scrum Master O Scrum master deve conduzir a reunião como facilitador. 2 Participação de todo o time Todo o Scrum team deve participar, garantindo espaço para que todos se expressem. 3 Discussão de impedimentos Devem ser discutidos os principais impedimentos enfrentados pelos developers, buscando formas de evitá-los nas próximas sprints. 4 Inspeção do fluxo de trabalho Os processos e o fluxo de trabalho devem ser inspecionados e adaptados com base nas métricas disponíveis. • • • • 5 Registro de melhorias Mudanças que contribuam para a melhoria do fluxo devem ser registradas ou convertidas em um plano de ação. 6 Adoção de ao menos uma melhoria Pelo menos uma dessas melhorias deve ser escolhida para ser aplicada na sprint seguinte. Pode-se usar um quadro com três semáforos (verde, amarelo e vermelho) e solicitar que cada membro da equipe escreva em um post-it o que considera relevante para as próximas sprints. Dessa forma, confira. Verde Significa que foi bem e deve ser repetido. Amarelo Significa que não foi tão bem, mas não é algo crítico. Vermelho Significa que certos itens não foram bem e precisam ser melhorados o mais breve possível. O Scrum master deve conduzir essa sprint para discutir mais os itens marcados como vermelho, gerando ações de melhoria de responsabilidade do próprio Scrum team com a seleção de alguns dos itens para execução na próxima sprint. Técnicas complementares ao Scrum Neste vídeo, falaremos sobre a importância de usar técnicas para complementar o Scrum e apresentaremos algumas técnicas, como MoSCoW, Scrum Poker e o método Kanban. Vamos lá! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Verificando o aprendizado Questão 1 MoSCoW é uma técnica usada para priorizar os itens do product backlog. Qual das opções a seguir constitui uma de suas categorias? A Must have B Nice to have C Shouldn’t have D Couldn’t have E Will have A alternativa A está correta. MoSCoW é um acrônimo das suas categorias (must have, should have, could have e won't have). Portanto, a única categoria do MoSCoW listada é a must have. Questão 2 Qual das afirmações abaixo sobre Kanban está correta? A Kanban foi criado por Peter Drucker em 1975 na Toyota. B Kanban é um termo de origem japonesa que significa lista. C Kanban é um método de gestão visual do fluxo de trabalho para definir, gerenciar e aperfeiçoar serviços. D Kanban é simples de usar. Ele facilita a visualização do fluxo de trabalho, melhora a comunicação entre os envolvidos e, por isso, deve estar sempre no formato físico. E Kanban e Scrum são métodos ágeis, mas funcionam de forma distinta e não se complementam. A alternativa C está correta. O Scrum é um framework que necessita de técnicas complementares para ser implementado. O Kanban tem várias métricas e práticas que complementam muito bem o Scrum. Foi até criado um método ágil chamado ScrumBan, que usa o Scrum e o Kanban de forma complementar. 4. Boas práticas Fases para a implementação Neste vídeo, explicaremos como iniciar um projeto-piloto, suas características e seu impacto para o projeto como um todo. Vamos lá! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Para haver sucesso na implementação do Scrum, é importante atender às seguintes condições. Confira! Patrocínio da alta direção É necessário convencer pessoas estratégicas na sua organização para implementar qualquer método ou processo novo. Resultados consistentes no curto prazo Quanto mais rápido forem obtidos bons resultados, maior será a credibilidade e menor a resistência das pessoas. Implantação por fases A implantação deve evoluir de forma gradual e com visão de longo prazo para criar uma cultura na organização baseada nos valores e nos princípios do Manifesto Ágil. Fases para implementação do Scrum Neste vídeo, apresentaremos as fases de implementação de um projeto Scrum, também definiremos o que são essas fases e exemplificaremos a aplicação no projeto Scrum. Vamos lá! Conteúdo interativo Acesse a versão digital para assistir ao vídeo. Abordagem: montar um Scrum team para um projeto-piloto Scrum team Montar um Scrum team a fim de trabalhar em um projeto-piloto para avaliar o Scrum normalmente envolve baixo investimento e menor esforço; por isso, ele é mais fácil de ser aprovado. Além disso, o piloto é uma forma rápida de evidenciar os benefícios do Scrum. A desvantagem de se iniciar por um piloto é que ele não explora todas as possibilidades de uma implementação Scrum. Relembrando Para montar um Scrum team, você precisa de um Scrum master, um product
Mais conteúdos dessa disciplina
QUESTIONÁRIO 07 ADMINISTRAÇÃO FINANCEIRA E ORÇAMENTÁRIA- Mapa Mental - PLDFT Brasil
- Avaliação II - Individual
- Segurança da Informação proteção de dados, criptografia, ciberataques
- Texto Opinativo e Interpretação
- eCAC - Centro Virtual de Atendimento
- PROJETO CLICK SAUDE
- TRAB4_GQS docx
- MAPA - ENGENHARIA DO PRODUTO - 51_2026
- MAPA - ENGENHARIA DO PRODUTO - 51_2026
- Qual é uma das práticas essenciais para alcançar uma visualização de dados eficaz em Business Intelligence (BI)? Questão 15Escolha uma opção: a. Inclu
- Questão 10/10 - Segurança da Informação (E) Ler em voz alta A norma ABNT NBR ISO/IEC 27002:2013 define informação como sendo um ativo – isto é, bem, p
- As câmeras corporais também contribuem para: a. Reduzir a responsabilização dos gestores. b. Tornar opacas as ações institucionais. c. Ocultar provas
- Os riscos inerentes às transferências internacionais de dados pessoais são mínimos, pois as legislações nacionais, como a LGPD, garantem fiscalizaç...
- Segundo a LGPD, uma transferência internacional de dados pode ocorrer mediante o consentimento do titular, desde que respeitadas outras bases legai...
- A manufatura aditiva vem ganhando destaque na indústria por permitir a produção de peças com geometrias complexas e personalizadas. Qual das alternati
- O que é essencial para o sucesso da Gestão de Recursos Humanos no meio rural? Questão 20Escolha uma opção: a. Aumento da carga horária de trabalh...
- A medida de segurança representa: a) Objetivo de alto nível declarando o que se espera alcançar com a aplicação da medida. d) Ações de segurança que p
- Como o conceito de “Infraestrutura como Código” (IaC) se relaciona com o DevOps e quais são os benefícios de implementar a IaC em ambientes de nuve...
- Como o conceito de “Infraestrutura como Código” (IaC) se relaciona com o DevOps e quais são os benefícios de implementar a IaC em ambientes de nuvem?
- o gerenciamento dos riscos possui uma normatização dada por meio da organização internacional organization for Standardization,mais conhecida como...
- No contexto da proteção de dados de crianças e adolescentes, a LGPD estabelece que o tratamento de dados deve: Opções da pergunta 2: a) Não se apl
- Qual é um potencial benefício de usar uma ferramenta de gerenciamento de serviço de TI para suportar a prática de “gerenciamento de incidente”? Respos
- Avaliação On Line 2 (AOL 2) Mat Constr Civil.
- Fluxograma Harrington exemplo
