Metodologias Ágeis: da empatia à entrega de valor com Design Thinking e Scrum

25-317628.0 CDD-658.4063 Dados Internacionais de Catalogação na Publicação (CIP) (Câmara Brasileira do Livro, SP, Brasil) Metodologias ágeis [livro eletrônico] : da empatia à entrega de valor com design thinking e scrum / Wenndisson da Silva Souza ... [et al.] ; prefácio por Nivaldo Rodrigues e Silva ; revisão Alyson de Jesus dos Santos. -- 2. ed. -- Manaus, AM : Ed. dos Autores, 2025. PDF Outros autores: Alexandre Lopes Martiniano, Eduardo Palhares Júnior, Lucélia Cunha da Rocha Santos, Nivaldo Rodrigues e Silva Bibliografia ISBN 978-65-01-80808-6 1. Administração de empresa - Metodologia 2. Criatividade nos negócios 3. Design thinking 4. Scrum (Desenvolvimento de software) I. Souza, Wenndisson da Silva. II. Martiniano, Alexandre Lopes. III. Palhares Júnior, Eduardo. IV. Santos, Lucélia Cunha da Rocha. V. Silva, Nivaldo Rodrigues e. VI. Santos, Alyson de Jesus dos. VII. Título. Índices para catálogo sistemático: 1. Design thinking : Criatividade nos negócios : Administração 658.4063 Maria Alice Ferreira - Bibliotecária - CRB-8/7964 DOI: 10.5281/zenodo.17674820 Expediente do IFAM MINISTÉRIO DA EDUCAÇÃO SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO AMAZONAS Reitor Jaime Cavalcante Alves Pró-Reitor de Administração Fábio Teixeira Lima Pró-Reitor de Gestão de Pessoas Leandro Amorim Damasceno Pró-Reitora de Ensino Rosângela Santos da Silva Pró-Reitora de Extensão Maria Francisca Morais de Lima Pró-Reitor de Pesquisa, Pós-Graduação e Inovação Paulo Henrique Rocha Aride Diretor Geral do Campus Manaus Distrito Industrial Nivaldo Rodrigues e Silva Expediente do Projeto CITHA MINISTÉRIO DA EDUCAÇÃO SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO AMAZONAS Gestores Nivaldo Rodrigues e Silva Samirames da Silva Fleury Alyson de Jesus dos Santos Maria Cassiana Andrade Braga Adanilton Rabelo de Andrade Coordenadores Tiago Francisco Andrade Diocesano Jaidson Brandão da Costa Elcivan dos Santos Silva Martinho Correia Barros Adelino Maia Galvão Filho Expediente de Produção Autores Wenndisson da Silva Souza Alexandre Lopes Martiniano Eduardo Palhares Júnior Lucélia Cunha da Rocha Santos Nivaldo Rodrigues e Silva Avaliação Pedagógica Samirames da Silva Fleury Diagramadores Eduardo Palhares Jr. Wenndisson da Silva Souza Fabio Serra Ribeiro Couto Revisores de Texto Alyson de Jesus dos Santos Metodologias Ágeis: da empatia à entrega de valor com Design Thinking e Scrum Autores Wenndisson da Silva Souza Alexandre Lopes Martiniano Eduardo Palhares Júnior Lucélia Cunha da Rocha Santos Nivaldo Rodrigues e Silva Prefácio por Nivaldo Rodrigues e Silva Revisão Alyson de Jesus dos Santos 2ª Edição Manaus - AM 2025 Prefácio Este e-book é um guia completo sobre metodologias ágeis, com destaque especial para as práticas de Design Thinking e Scrum. Estas ferramentas são apresentadas como instrumentos indispensáveis para solucionar desafios complexos, especialmente em contextos como o da Amazônia, onde sustentabilidade e eficiência são prioridades. A abordagem prática e dinâmica deste material o torna essencial para aqueles que buscam aplicar metodologias modernas em cenários reais e transformadores. Estruturado de forma clara e interativa, o e-book convida o leitor a explorar, experimentar e implementar essas metodologias em projetos diversos. O módulo 4, em especial, exemplifica essa proposta ao detalhar a proposta de gestão sustentável de uma fazenda na Amazônia. A integração entre tecnologia, colaboração e inovação destaca o potencial das metodologias ágeis em fomentar soluções criativas para problemas relacionados à gestão de recursos naturais e sustentabilidade. O projeto vai além de uma proposta acadêmica, ilustrando como práticas ágeis podem ser catalisadoras de mudanças reais e significativas. Desde a aplicação de sensores para monitoramento ambiental até sistemas de manejo integrado, o experimento prático evidencia como o Design Thinking e o Scrum podem transformar ideias em resultados concretos, sempre com foco nas necessidades locais e no impacto ambiental positivo. Ao longo das páginas, os leitores serão incentivados a refletir sobre as implicações de cada metodologia e a explorar novas formas de resolver problemas. Este e-book não apenas ensina, mas inspira a adoção de uma mentalidade ágil e colaborativa, essencial para enfrentar os desafios do século XXI. Que este material seja um ponto de partida para a inovação e a transformação sustentável. Projeto de Capacitação e Interiorização em Tecnologias Habilitadoras na Amazônia - CITHA O projeto CITHA surge com o objetivo de fortalecer a economia da Amazônia por meio do incentivo ao empreendedorismo local e do desenvolvimento sustentável. Sua proposta é capacitar profissionais e impulsionar a criação de startups voltadas para a bioeconomia, além de apoiar cooperativas locais na melhoria de seus processos produtivos. A implementação de tecnologias inovadoras é uma das estratégias centrais do projeto, visando oferecer soluções eficientes que atendam às necessidades regionais, como a otimização dos recursos naturais e a melhoria da infraestrutura local. Ao longo de sua execução, o projeto se compromete a integrar os diversos stakeholders, como governos, empresas, ONGs e comunidades, por meio da capacitação da mão de obra local. O objetivo é formar um capital intelectual qualificado, capaz de apoiar uma governança eficiente, promover a inovação e assegurar a sustentabilidade. O CITHA dedica-se à criação de processos internos que incentivem o desenvolvimento de novos métodos e tecnologias, adaptáveis às particularidades do território amazônico. Em síntese, o projeto CITHA visa criar um ciclo de desenvolvimento que não só incentive o empreendedorismo, mas também promova a modernização das estruturas locais, elevando a qualidade de vida das populações da Amazônia. Focado em áreas como bioeconomia, inovação e transferência de tecnologia, o projeto busca estabelecer um ecossistema mais forte e autossustentável, capaz de responder eficientemente às demandas do mercado e da sociedade. Lista de Expressões para Enriquecimento de Conteúdo Este material foi cuidadosamente estruturado para apoiar sua jornada de aprendizado. Ao longo dos capítulos, você encontrará diversas chamadas sinalizadas por ícones especiais, que ajudarão a destacar pontos-chave e enriquecer sua compreensão. Durante a diagramação, esses ícones serão inseridos conforme as indicações dos autores, guiando você para diferentes tipos de conteúdo e atividades que potencializam seu estudo. Fique Alerta! Destaque para conceitos, expressões e trechos fundamentais que merecem sua atenção especial para a compreensão do conteúdo. Iniciando o diálogo... Espaço para reflexão crítica. Aqui você será convidado(a) a problematizar os temas abordados, relacionando-os com sua experiência e buscando conexões relevantes para aprofundar seu aprendizado. Conhecendo um pouco mais! Indicação de fontes complementares, como livros, entrevistas, vídeos, aplicativos, links e outros recursos para ampliar seu conhecimento sobre o tema. Caso Prático Aplicação direta do conteúdo em exemplos concretos, para facilitar a fixação e demonstrar a utilidade do que foi aprendido. Copie e Teste! Trechos de código prontos para serem copiados e executados, para que você possa experimentar, validar e explorar na prática os conceitos estudados. ◎Objetivos do Capítulo Apresenta de forma clara as competências e habilidades que você irá desenvolver. Funciona como um ’contrato de aprendizado’, mostrando exatamente o que você será capaz de fazer ou explicar após a conclusão do capítulo. CAPÍTULO 1. FUNDAMENTOS DO DESIGN THINKING Como Usar a Ferramenta dos 5 Porquês? 1. Defina o Problema de forma clara. Escreva uma frase curta sobre o problema que você identificou. 2. Pergunte ”Por quê?” em relação à situação do problema. A resposta vai ajudá-lo a identificar a causa mais imediata. 3. Pergunte novamente ”Por quê?” para a resposta anterior. Continue perguntando ”Por quê?”até chegar à causa raiz do problema. Repita o processo até cinco vezes ou até que as respostas não revelem mais causas subjacentes. 4. Analise a causa raiz encontrada na última resposta. Esse é o motivo mais profundo do problema e, provavelmente, o ponto ideal para começar a pensar em soluções. 5. O que podemos concluir? A causa raiz pode ser a falta de organização e comunicação no início do trabalho em grupo. Com isso, você pode propor soluções focadas na organização inicial e na divisão de tarefas. Passo 2: DEFINIÇÃO DO PROBLEMA Na fase de Definição, você organiza tudo o que aprendeu na fase de Empatia. Aqui, é importante deixar o problema bem claro e específico. Quando o problema é bem definido, é mais fácil criar uma solução realmente útil. Atividade: Depois de coletar informações na fase de Empatia, organize-as para identificar o problema central. Por exemplo: • Você pode descobrir que a falta de sensoriamento e automação na estrutura da fazenda reduz a produtividade. • Ou que os sistemas de captação e monitoramento de água são insuficientes, causando desperdícios ou dificuldades no manejo. Uma definição clara do problema pode ser: “A fazenda enfrenta dificuldades em monitorar o consumo de água e energia, afetando a eficiência das atividades agrícolas e de criação de animais.” Fique Alerta! Utilize a ferramenta de Design Thinking, o Diagrama de Afinidades, para organizar as informações e definir com precisão o problema central. Como Usar o Diagrama de Afinidades? 1. Revise todas as informações coletadas durante a fase de empatia. Escreva cada insight, observação ou comentário em um cartão, uma folha pequena recortada ou post-it. 2. Organize os cartões em grupos de ideias semelhantes. Por exemplo, se você tem várias observações sobre o desconforto físico dos alunos, agrupe essas respostas. 15 CAPÍTULO 1. FUNDAMENTOS DO DESIGN THINKING 3. Identifique padrões e temas principais entre os grupos. Dê um nome a cada grupo, como “Infraestrutura”, ”Água”, “Agricultura” ou ”Manejo”, dependendo das questões mais mencionadas. 4. Priorize os temas para ajudar a identificar o problema mais importante a ser resolvido. Figura 1.6: Diagrama de afinidades Fonte: Elaborada pelos autores Passo 3: IDEAÇÃO Agora que o problema está claro, é hora de ser criativo! Na fase de Ideação, você vai gerar o maior número possível de ideias para resolver o problema. Não se preocupe se algumas ideias parecerem malucas – quanto mais criativo, melhor! Atividade: Para resolver problemas identificados, pense em ideias criativas e viáveis. Por exemplo: •Estrutura Física: Projetar um sistema de energia renovável com painéis solares para alimentar dispositivos de automação. •Captação de Água: Criar reservatórios inteligentes com sensores que monitoram o nível e a qualidade da água. •Agricultura e Criação Integradas: Implementar um sistema de aquaponia onde a água dos tanques de peixes seja reutilizada como fertilizante natural para os vegetais. Reúna colegas e faça uma sessão de Brainstorming (tempestade de ideias). Peça a cada um que sugira soluções para o problema que você definiu. Anote todas as ideias, mesmo as mais simples ou ousadas. Em seguida, utilize a Matriz SWOT para avaliar e organizar as melhores ideias, identificando as forças, fraquezas, oportunidades e ameaças associadas a cada solução proposta 16 CAPÍTULO 1. FUNDAMENTOS DO DESIGN THINKING Figura 1.7: Exemplo de Brainstorm Fonte: Yasminkalume, 2017 Como conduzir o Brainstorming? 1. Defina o problema claramente para o grupo. Certifique-se de que todos entendam a questão central que desejam resolver. 2. Estabeleça um ambiente aberto e sem julgamentos. Deixe claro que qualquer ideia é válida, incentivando o grupo a pensar de forma criativa e sem restrições. 3. Registre todas as ideias em post-its, papéis recortados ou em um quadro visível para todos. Isso facilita a visualização e organização das propostas. 4. Priorize as ideias que mais se destacam com base na viabilidade e no impacto que podem ter para resolver o problema. Como usar a matriz SWOT para avaliar as ideias? 1. Desenhe a matriz SWOT com quatro quadrantes: Forças (Strengths), Fraquezas (Weaknesses), Oportunidades (Opportunities) e Ameaças (Threats). 2. Analise cada ideia prioritária com a Matriz SWOT, preenchendo os quadrantes: •Forças: Quais são os pontos fortes dessa ideia? •Fraquezas: Quais são as limitações ou pontos fracos? •Oportunidades: Que oportunidades essa ideia cria? •Ameaças: Que obstáculos ou riscos podem surgir? 3. Compare as ideias com a Matriz SWOT para decidir qual delas apresenta o melhor equilíbrio entre pontos fortes, oportunidades e menor quantidade de ameaças e fraquezas. 4. Escolha as soluções com o melhor perfil SWOT para implementar ou para o próximo estágio de desenvolvimento. 17 CAPÍTULO 1. FUNDAMENTOS DO DESIGN THINKING Figura 1.8: Representação gráfica da Matriz SWOT e seus quatro quadrantes Fonte: Elaborada pelos autores Passo 4: PROTOTIPAÇÃO (CRIANDO MODELOS) A fase de Prototipação é onde você escolhe as melhores ideias e começa a transformálas em algo concreto. Aqui, você vai criar uma versão simples da solução para que as pessoas possam experimentá-la. Atividade: Para testar uma das ideias, você pode criar um protótipo simples, por exemplo: • Monte uma maquete da fazenda com tanques para aquaponia e um sistema básico de irrigação conectados a sensores. • Desenhe esquemas para o posicionamento de painéis solares e dispositivos automáticos que melhorem a gestão de energia. • Simule o funcionamento de um aplicativo que monitore os reservatórios de água e os cultivos em tempo real. Selecione uma das ideias desenvolvidas na fase de Ideação e construa um protótipo inicial. Utilize materiais simples como papel, canetas, objetos recicláveis ou qualquer item acessível para criar uma versão preliminar da sua solução. Lembre-se: o protótipo não precisa ser perfeito nem finalizado. O objetivo é produzir uma representação funcional da ideia, algo que possa ser testado, ajustado e melhorado com base no feedback dos usuários. Concentre-se em mostrar como a solução funcionaria na prática e esteja aberto a modificá-la conforme as sugestões recebidas. 18 CAPÍTULO 1. FUNDAMENTOS DO DESIGN THINKING Passo 5: TESTES (COLHENDO FEEDBACK) Na fase de Testes, você vai apresentar seu protótipo para as pessoas que enfrentarão o problema e pedir para que elas o experimentem. Com base no feedback delas, você poderá fazer ajustes e melhorias na solução. Atividade: Implemente o protótipo em pequena escala e colete feedback: •Estrutura Física: Teste o impacto do uso de sensores automáticos no desempenho dos trabalhadores. •Aquaponia: Observe como o sistema integrado de peixes e vegetais atende às necessidades de subsistência e comercialização. •Captação de Água: Avalie se o monitoramento digital reduz o desperdício e melhora a distribuição para os cultivos e animais. Fique Alerta! O Design Thinking, não é uma fórmula mágica. Seu sucesso depende de um verdadeiro engajamento com as necessidades e realidades dos usuários. Isso significa que as empresas e equipes que utilizam essa metodologia precisam estar dispostas a escutar ativamente, observar comportamentos eadaptar suas ideias conforme novos aprendizados surgem. Não basta seguir as etapas do Design Thinking de forma mecânica – é essencial que a equipe tenha empatia, abertura para mudanças e disposição para experimentar novas soluções constantemente. Por exemplo, gigantes da tecnologia usaram o Design Thinking não apenas para criar produtos inovadores, mas também para refinar suas ofertas continuamente. Eles estão sempre atentos ao feedback dos usuários, fazendo ajustes e melhorias com base no uso real e nas necessidades que surgem com o tempo. A chave do sucesso dessas empresas é que elas nunca param de aprender com seus usuários. Elas sabem que um produto nunca está ”pronto”– ele pode sempre ser melhorado, e isso só acontece quando o foco permanece em quem vai utilizá-lo. Ao entender o que os usuários precisam e quais são suas dores, essas empresas desenvolvem soluções que não só resolvem problemas, mas também melhoram a experiência do dia a dia. Seja um celular fácil de usar, uma plataforma que ajuda pessoas a encontrar lugares ou uma ferramenta de ensino inovadora, o Design Thinking está por trás de muitas das inovações que vemos hoje. 1.3 Aplicando seus conhecimentos 1. Escreva um texto refletindo sobre como o Design Thinking pode transformar a maneira como você lida com desafios cotidianos. (a) Pense em problemas que enfrenta no dia a dia, seja em casa, na escola ou na comunidade, e considere como as etapas dessa metodologia como empatia, definição do problema e prototipagem podem ajudá-lo a compreender melhor as necessidades das pessoas envolvidas, gerar ideias criativas e testar soluções práticas. (b) Avalie também como essa abordagem colaborativa pode incentivar novas formas de resolver problemas, promovendo inovação e impacto positivo em sua rotina 19 CAPÍTULO 1. FUNDAMENTOS DO DESIGN THINKING 1.4 Considerações do módulo O Design Thinking nos ensina a colocar as pessoas no centro de qualquer solução, focando em entender suas necessidades e criar algo que faça diferença em suas vidas. Ao seguir as cinco fases – Empatia,Definição,Ideação,Prototipação eTestes – você é capaz de gerar ideias inovadoras e aplicáveis, ajustando as soluções conforme recebe feedback. Esse processo é colaborativo e criativo, permitindo que equipes de diferentes áreas trabalhem juntas para resolver problemas complexos de forma eficaz. No próximo módulo, vamos explorar como o Scrum, uma metodologia ágil, ajuda a organizar o trabalho em equipe para que essas soluções possam ser desenvolvidas de maneira eficiente e entregues rapidamente. Conhecendo um pouco mais! Produto Técnico e Tecnológico GUIA DIDÁTICO DO DESIGN THINKING https://educapes.capes.gov.br/handle/capes/5 72344 ou aponte a câmera do seu smartphone para o Qr Code ao lado 20 Capítulo 2 Introdução às Metodologias Ágeis Iniciando o diálogo... Bem-vindo(a) estudante, neste módulo, você vai aprender o que são metodologias ágeis, por que elas são importantes e como elas diferem dos métodos tradicionais, como são aplicadas em projetos, possibilitando a entrega de resultados de forma mais rápida e eficiente. Figura 2.1: Arquitetura do modelo tradicional vs o modelo ágil Fonte: XPEducação, 2022 ◎Objetivos do Capítulo Ao final desta leitura, você será capaz de: • Diferenciar o conceito de agilidade (capacidade de adaptação) de simplesmente velocidade. • Compreender os quatro valores fundamentais e os doze princípios do Manifesto Ágil, a base filosófica do movimento. • Analisar as principais diferenças práticas entre as metodologias ágeis e as abordagens tradicionais de gerenciamento de projetos. • Identificar os contextos em que cada abordagem é mais adequada. 21 CAPÍTULO 2. INTRODUÇÃO ÀS METODOLOGIAS ÁGEIS 2.1 Fundamentos do Pensamento Ágil Antes de mergulhar nas práticas e cerimônias de uma metodologia específica, é fundamental compreender a filosofia que a sustenta. O termo ”Ágil”(do inglês, Agile) no contexto de desenvolvimento de projetos refere-se não a uma única metodologia, mas a uma mentalidade, um conjunto de valores e princípios focados na adaptação, colaboração e entrega de valor de forma contínua. O Que é Agilidade? (Além da Velocidade) É um erro comum associar agilidade exclusivamente com velocidade. Embora equipes ágeis frequentemente entreguem resultados de forma mais rápida, o cerne do conceito é a capacidade de responder a mudanças de forma eficaz. Uma analogia útil é comparar o gerenciamento de projetos a uma viagem de carro: • Uma abordagem tradicional é como planejar a viagem inteira usando um mapa de papel impresso. O caminho é definido do início ao fim. Se houver um bloqueio na estrada, o plano se torna obsoleto e o custo para mudar a rota é alto. • Uma abordagem ágil é como usar um aplicativo de GPS. Você sabe o destino, mas o caminho é recalculado em tempo real com base nas condições do trânsito, permitindo desvios e otimizações para chegar ao destino da forma mais eficiente possível. Portanto, a agilidade está na flexibilidade e na adaptação, e não apenas na rapidez da execução. O Guarda-Chuva Ágil e o Manifesto O pensamento ágil não nasceu em um vácuo. No final dos anos 90, diversas metodologias ”leves”(em oposição aos processos pesados e burocráticos da época) ganhavam força, como o Extreme Programming (XP), focado na excelência técnica e na colaboração [2], e o Scrum, um framework para gerenciar trabalhos complexos de forma iterativa [8]. Em 2001, dezessete praticantes desses métodos se reuniram e consolidaram os valores comuns que guiavam seus trabalhos, redigindo o Manifesto para o Desenvolvimento Ágil de Software [1]. Este documento estabeleceu uma mentalidade baseada em valores fundamentais que abriga diversas metodologias e frameworks, conforme ilustrado na figura 2.2, Figura 2.2: O ”Guarda-Chuva Ágil”e suas diversas metodologias e frameworks. Fonte: Cy Mastrodomenico, 2020 22 CAPÍTULO 2. INTRODUÇÃO ÀS METODOLOGIAS ÁGEIS Os quatro valores do manifesto priorizam: •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. Isso não significa que os itens à direita não tenham valor, mas que os itens à esquerda são mais valorizados. Fique Alerta! A equipe deve estar preparada para mudanças no escopo, tempo, custo, tecnologia, arquitetura, entre outros. Iterações curtas de desenvolvimento permitem que mudanças possam ser rapidamente inseridas no projeto, de forma que atendam às novas necessidades. Os Doze Princípios de Suporte Para dar suporte prático aos quatro valores, o Manifesto é acompanhado por doze princípios. Em vez de uma simples lista, podemos compreendê-los melhor ao agrupá-los por afinidade temática: Foco no Cliente e no Valor Estes princípios garantem que o trabalho realizado esteja sempre alinhado às necessidades do cliente, entregando o máximo de valor possível. •1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. A ênfase está na entrega contínua de valor, e não em uma única entrega massiva no final do projeto. Isso permite que o cliente comece a ter retorno sobre seu investimento mais cedo. •2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se aproveitam de mudanças, para a vantagem competitiva do cliente. A mudança não é vista como um problema, mas como uma oportunidade. O objetivo é construir o produto certo, e o ágil permite que a definição de ”certo”evolua conforme o aprendizado do mercado. Processo, Ritmo e Entrega Estes princípios governam como o trabalho flui, como o progresso é medido e como a sustentabilidade da equipe é mantida. •3. Entregar frequentemente software funcionando, de duas em duas semanas a dois em dois meses, com preferência à menor escala de tempo. Ciclos curtos de entrega (iterações) reduzem o risco, aumentam a previsibilidade e criam ciclos de feedback rápidos com o cliente. 23 CAPÍTULO 2. INTRODUÇÃO ÀS METODOLOGIAS ÁGEIS •7. Software funcionando é a medida primária de progresso. O progresso não é medido por documentos aprovados ou fases concluídas, mas sim por incrementos de produto real, testado e funcional. É a medida mais honesta de avanço. •8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Este princípio é contra a cultura de ”heróis”e de longas horas de trabalho (”crunch time”). Uma equipe ágil deve encontrar um ritmo de trabalho que possa ser mantido a longo prazo sem esgotamento. •10. Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial. Não se trata de fazer menos, mas de evitar o desperdício. O foco é em construir apenas o que é estritamente necessário para atender às necessidades atuais, evitando a superengenharia e funcionalidades que ”talvez um dia sejam úteis”. Colaboração e Excelência da Equipe O sucesso do Ágil depende fundamentalmente das pessoas e da forma como elas interagem. •4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Este princípio busca quebrar os silos de comunicação. A colaboração diária garante que a equipe de desenvolvimento esteja sempre alinhada com os objetivos de negócio. •5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário, e confie neles para fazer o trabalho. É um princípio de empoderamento. Equipes motivadas e com autonomia têm maior probabilidade de encontrar as melhores soluções. •6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é a conversa face a face. Embora a tecnologia tenha evoluído, o princípio da comunicação de alta fidelidade permanece. A comunicação direta (seja presencial ou por vídeo) é muito mais rica e menos suscetível a mal-entendidos do que longas trocas de e-mails ou documentos. •11. As melhores arquiteturas, requisitos e designs emergem de equipes que são auto-organizáveis. A inteligência coletiva da equipe, que está mais próxima do trabalho, tende a gerar soluções mais eficazes e elegantes do que aquelas ditadas de cima para baixo. Qualidade Técnica e Melhoria Contínua Agilidade não é uma desculpa para o caos ou para a falta de qualidade técnica. •9. Contínua atenção à excelência técnica e bom design aumenta a agilidade. Um código limpo e bem projetado é mais fácil de manter e modificar. Investir em qualidade técnica não atrasa a equipe; pelo contrário, permite que ela continue a se mover rapidamente no futuro, reduzindo o ”débito técnico”. 24 Capítulo 3 Introdução ao Scrum Iniciando o diálogo... Neste capítulo, vamos mergulhar no framework ágil mais utilizado no mundo: o Scrum. Longe de ser uma metodologia prescritiva, o Scrum é um framework simples e leve que ajuda pessoas, equipes e organizações a gerar valor através de soluções adaptativas para problemas complexos. Figura 3.1: Os Três Pilares do Empirismo: a base do Scrum. Fonte: Thiago Anastácio, 2020 ◎Objetivos do Capítulo Ao final deste capítulo, você será capaz de: • Compreender o Scrum como um framework fundamentado no empirismo. • Identificar e descrever as responsabilidades dos três papéis do Time Scrum: Product Owner,Scrum Master eDesenvolvedores. • Detalhar o propósito e a dinâmica dos cinco eventos do Scrum: a Sprint, o Planejamento, a Reunião Diária, a Revisão e a Retrospectiva. • Descrever os três artefatos do Scrum: o Product Backlog, o Sprint Backlog e o Incremento. 31 CAPÍTULO 3. INTRODUÇÃO AO SCRUM 3.1 O que é SCRUM? Para entender o Scrum, imagine que ele não é um manual de instruções detalhado, mas sim uma caixa de LEGOs com algumas regras simples. Ele não diz o que construir, mas oferece as peças (papéis, eventos, artefatos) e as regras de encaixe (o framework) para que uma equipe possa construir, inspecionar e adaptar qualquer produto complexo de forma eficaz. Oficialmente, segundo seus criadores, Ken Schwaber e Jeff Sutherland, o Scrum é um ”framework leve que ajuda pessoas, equipes e organizações a gerar valor através de soluções adaptativas para problemas complexos”. A palavra framework é fundamental aqui, pois ele é intencionalmente incompleto, servindo como um contêiner onde diversas outras técnicas e práticas podem ser aplicadas. As raízes do Scrum são mais antigas do que o Manifesto Ágil e remontam a um influente artigo de 1986 da Harvard Business Review, intitulado ”The New New Product Development Game”, de Hirotaka Takeuchi e Ikujiro Nonaka [11]. No artigo, eles descreveram uma abordagem de desenvolvimento de produtos mais holística, rápida e flexível, comparando as equipes de alta performance a um time unido e coeso de Rugby – daí a origem do termo ”Scrum”. Essa abordagem surgiu como uma resposta direta às falhas dos modelos sequenciais e rígidos, como o Waterfall, que se mostravam ineficazes para lidar com a incerteza e a complexidade dos projetos modernos. A base filosófica do Scrum é o empirismo, a teoria de que o conhecimento provém da experiência e da tomada de decisões com base no que é observado. Para que o empirismo funcione na prática, ele se apoia em três pilares fundamentais: Transparência, Inspeção e Adaptação. Figura 3.2: Scrum como um Framework Contêiner Fonte: Gerada por Google Gemini 2.5 Pro, 2025 32 CAPÍTULO 3. INTRODUÇÃO AO SCRUM 1. Transparência: O estado real do trabalho, os desafios e o progresso devem ser visíveis e compreendidos por todos os envolvidos – tanto a equipe que realiza o trabalho quanto as pessoas que o recebem. A transparência vai além de um quadro de tarefas; ela exige uma linguagem comum e padrões claros. No projeto da fazenda, a transparência seria garantida se toda a equipe, do agrônomo ao desenvolvedor do aplicativo, compartilhasse o mesmo Product Backlog priorizado e entendesse que a tarefa ”implementar sensor de umidade”só está ”Pronta”quando o sensor está instalado, coletando dados e exibindo-os de forma funcional no aplicativo, conforme um critério predefinido. Fique Alerta! A Definição de Pronto (Definition of Done - DoD) Um dos conceitos mais críticos para garantir a transparência é a ”Definição de Pronto”. Trata-se de um acordo formal e compartilhado por todo o Time Scrum, que descreve todos os critérios de qualidade e trabalho que uma funcionalidade deve atender para ser considerada ”concluída”e parte do Incremento. Sem um DoD claro, a equipe corre o risco de gerar mal-entendidos e entregar um trabalho que não possui a qualidade necessária, comprometendo o valor do produto. 2. Inspeção: Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados frequentemente e diligentemente para detectar variações ou problemas indesejados. A inspeção não deve ser vista como microgerenciamento, mas como uma ferramenta para a equipe avaliar sua própria trajetória. Essa inspeção ocorre em eventos específicos do Scrum. Por exemplo, a equipe da fazenda inspeciona seu progresso em direção à meta da Sprint todos os dias durante a Daily Scrum, e o produto em si é inspecionado junto aos stakeholders durante a Sprint Review. 3. Adaptação: Se a inspeção revelar que um ou mais aspectos do processo ou do produto se desviaram dos limites aceitáveis, um ajuste deve ser feito o mais rápido possível para minimizar desvios futuros. A adaptação é a ação corretiva. Se, durante a Sprint Review, o agricultor (stakeholder) percebe que o protótipo do sistema de irrigação não é prático, a equipe adapta o plano para a próxima Sprint, ajustando os itens e as prioridades do Product Backlog com base nesse valioso feedback. O ciclo de Transparência, Inspeção e Adaptação é o motor que impulsiona a melhoria contínua e a agilidade no Scrum. Figura 3.3: O Ciclo do Empirismo no Scrum. Fonte: Adaptado de Felipe Guimaraes e Equipe Aela, 2022 33 CAPÍTULO 3. INTRODUÇÃO AO SCRUM 3.2 Ciclo de desenvolvimento Agora que entendemos a filosofia por trás do Scrum, vamos conhecer os elementos que compõem seu framework. Estes elementos são projetados para dar vida ao ciclo de transparência, inspeção e adaptação. O Time Scrum Product Owner : (”dono”do produto): representa o cliente e é responsável por garantir que a equipe SCRUM agregue valor ao negócio. Portanto, desempenha o papel de moderador entre os interesses do cliente e do Team, tendo como responsabilidade manter a equipe funcional e produtiva. O Product Owner é responsável por: • Definir a visão e as funcionalidades do produto; • Definir as prioridades; • Elaborar e manter o Product Backlog; • Definir as prioridades e o ROI (Return of Investment); • Decidir sobre as datas de lançamento do produto; • Representar o cliente (quando este não está presente); • Aceitar ou rejeitar os resultados dos trabalhos. SCRUM Master: (mestre SCRUM): representante do cliente no projeto e desempenha um papel importante de facilitador, responsável pela remoção de impedimentos (problemas técnicos, administração de conflitos, itens não planejados) que eventualmente surjam durante o desenrolar do desenvolvimento. Atua na definição de funcionalidades de acordo com seu valor para o cliente, planejando e elaborando em conjunto com o Product Owner uma lista de prioridades. Portanto, o SCRUM Master desempenha um papel de responsabilidade técnica na condução do projeto, mantendo a equipe focada nas suas tarefas. O SCRUM Master é responsável por: • Desempenhar o papel de líder, representando a gerência do projeto; • Remover impedimentos; • Proteger a equipe SCRUM; • Ajudar o Product Owner com o Product Backlog; • Ser o facilitador da equipe SCRUM, garantindo sua plena produtividade; • Garantir a colaboração entre os diversos papéis e funções; • Atuar como escudo para interferências externas; • Aplicar os valores e as práticas SCRUM. 34 CAPÍTULO 3. INTRODUÇÃO AO SCRUM Desenvolvedores: São as pessoas do Time Scrum que se comprometem a criar qualquer aspecto de um Incremento utilizável a cada Sprint. As habilidades específicas dos Desenvolvedores são frequentemente amplas e variam com o domínio do trabalho. No entanto, todos os Desenvolvedores são responsáveis por: • Criar um plano para a Sprint, o Sprint Backlog; • Injetar qualidade ao aderir a uma Definição de Pronto; • Adaptar seu plano a cada dia em direção à Meta da Sprint; e, • Manterem-se mutuamente como profissionais responsáveis. No caso da fazenda, a equipe de Desenvolvedores seria multifuncional, incluindo engenheiros de software, especialistas em hardware para os sensores e talvez um designer de UX para o aplicativo. Os Eventos do Scrum Sprints: corresponde às iterações. O objetivo é gerar um produto ”entregável”de valor para o cliente, que foi previamente combinado com ele. Cada sprint deve ocorrer em um período de duas a quatro semanas. O produto é projetado, codificado e testado durante a sprint. As tarefas escolhidas para fazerem parte de uma sprint devem ser retiradas de outro documento, denominado Product Backlog, que contém um conjunto de requisitos que representam o trabalho que deve ser feito. No final de cada sprint, outra reunião deve ser realizada, para revisar o que foi feito, avaliar o progresso e identificar lições aprendidas para serem usadas na próxima sprint. Planejamento da sprint ou Sprint Planning Meeting: é a primeira reunião do projeto e todos precisam participar; deve ter uma duração de no máximo oito horas. Durante o planejamento da sprint podemos utilizar uma técnica que estima o tamanho do trabalho a ser realizado. Esta é a reunião em que o Product Owner planeja e elabora a lista de prioridades que devem ser cumpridas pelo projeto, dividindo a reunião em duas partes: Figura 3.4: Etapas do planejamento da sprint Fonte: Elaborada pelos autores Reunião diária ou Daily SCRUM: é uma reunião que cada membro do time deve responder sobre o que já fez, sobre o que pretende fazer e se há algum impedimento para a conclusão da(s) tarefa(s) sob sua responsabilidade. A reunião diária deve ter uma duração muito rápida, preferencialmente de no máximo quinze minutos, tendo como participantes apenas o time e o SCRUM Master. Cada membro do time deve responder a três perguntas: 35 CAPÍTULO 3. INTRODUÇÃO AO SCRUM 1. O que eu fiz desde a última reunião? 2. O que vou fazer até a próxima? 3. Tive ou estou tendo algum impedimento? Quais? Revisão da sprint ou Sprint Review: é uma reunião de balanço sobre tudo o que foi feito durante uma sprint. Nessa reunião o time deve mostrar os resultados da sprint para o Product Owner e seus convidados. Observe que devem ser apresentados somente os itens que estiverem 100% prontos, ou seja, se faltou uma única atividade, o item não deve ser apresentado. Essa reunião deve ter uma duração estimada de quatro horas e precisa contar com os seguintes participantes: Product Owner, SCRUM Master , Equipe SCRUM e outros convidados. Deve-se marcar essa reunião sempre no final da sprint. Os objetivos esperados após a reunião: • Apresentar o que a equipe fez durante a sprint; • Entregar o produto (software funcionando) ao Product Owner (geralmente uma demo da parte implementada). Após a apresentação, o Product Owner conversa com seus convidados e tem o direito de aceitar ou rejeitar a sprint com base no que foi apresentado. Qualquer necessidade de mudança ou inserção de novas features (funcionalidades) será incorporada ao Product Backlog em um momento oportuno, além de priorizada novamente. Retrospectiva da sprint ou Sprint Retrospective: o objetivo dessa reunião é verificar o que houve de bom e o que pode ser melhorado em uma sprint. São avaliados aspectos relacionados ao trabalho em equipe, pontos positivos e negativos, e feitas reflexões sobre estratégias de melhoria que podem ser adotadas. Devem participar da reunião, obrigatoriamente, o time e o SCRUM Master. O Product Owner também pode participar, sempre que convidado. Todos os membros do time devem responder basicamente a duas perguntas: o que foi bom durante a sprint e o que se pode fazer para melhorar a próxima. O SCRUM Master deve tomar nota de tudo e o time deve priorizar os itens apontados em uma ordem ideal de mudança. A retrospectiva é uma excelente forma de garantir a melhoria contínua do processo. Essa reunião deve acontecer logo após a revisão da sprint, com duração aproximada de três horas. Os Artefatos do Scrum Product Backlog: é um documento que representa a visão do produto de forma modular, contendo todos os itens que devem ser desenvolvidos durante o projeto. Basicamente é uma lista de prioridades feitas logo no início do projeto, com o objetivo de esclarecer e elencar o que deve ser entregue para o cliente. Esses itens devem ser escritos de forma clara e simples, de fácil entendimento tanto para o time de desenvolvimento quanto para o cliente. O Product Backlog deve ser criado e mantido pelo Product Owner, que tem a liberdade de alterar esse documento quando quiser, desde que os itens alterados não estejam na sprint que estiver sendo desenvolvida no momento. Os itens do Product Backlog devem ser priorizados em função do ROI (Return of Investment), ou seja, os que apresentarem maior valor para o negócio devem ser desenvolvidos primeiro. O tamanho de cada item deve ser estimado pelo time de desenvolvimento. O Product Owner deve manter e priorizar o Product Backlog constantemente. 36 CAPÍTULO 3. INTRODUÇÃO AO SCRUM Até este ponto, apresentamos todas as ’peças de LEGO’ que compõem o Scrum: o Time (quem executa), os Eventos (quando o trabalho acontece) e os Artefatos (o que guia e o que é produzido). Agora que conhecemos cada componente individualmente, podemos finalmente montar o quebra-cabeça. O texto e a figura a seguir ilustram como todos esses elementos se conectam e interagem para formar o ciclo de desenvolvimento completo, transformando as necessidades do cliente em um Incremento de valor a cada Sprint. Tabela 3.1: Exemplo de um Product Backlog priorizado. Prioridade (ROI) Ator Req. Func. Descrição do Item Tamanho Release Sprint Status Essencial Usuário RF001 Cadastro de usuário To Do Essencial Usuário RF002 Cadastro de curriculum To Do Essencial Usuário RF003 Cadastro de interesse To Do Essencial Usuário RF004 Busca de oportunidades de emprego To Do Essencial Empresas RF005 Cadastro de empresas To Do Essencial Empresas RF006 Busca de candidato a emprego To Do Uma prática essencial para manter o Product Backlog organizado e eficiente, também conhecido como ”refinamento do backlog”. Essa atividade ocorre regularmente e tem como objetivo revisar, ajustar e priorizar os itens do backlog, garantindo que estejam claros e prontos para serem desenvolvidos nos próximos sprints, alguns pontos a serem considerados. •Dividir tarefas grandes: Quebrar itens complexos em partes menores e mais gerenciáveis; •Estimar esforço: Avaliar o tamanho ou esforço necessário para concluir cada item; •Ajustar prioridades: Reordenar os itens do backlog com base no feedback do cliente ou em mudanças no projeto. Essa prática é conduzida de forma colaborativa, envolvendo o Product Owner, o Scrum Master e a equipe de desenvolvimento, e ajuda a alinhar todos os membros sobre o trabalho que será realizado. Embora não seja uma cerimônia formal do Scrum, o Backlog Refinement é fundamental para preparar a equipe para os sprints, aumentando a produtividade e a clareza sobre os próximos passos. Sprint Backlog: é um artefato oriundo da Sprint Planning Meeting e representa todas as tarefas que devem ser desenvolvidas durante uma sprint ou iteração. Cada item deve ser detalhado em tarefas e cada uma dessas tarefas deve ter uma estimativa de esforço, neste caso, em horas. 37 CAPÍTULO 3. INTRODUÇÃO AO SCRUM Tabela 3.2: Exemplo de Sprint Backlog com detalhamento de tarefas e horas. Item Tarefa 1 2 3 4 5 6 7 8 9 10 Total ES006 Criar Base de Dados 4 0 0 0 0 0 0 0 0 0 4 Desenvolver Modelo 8 8 0 0 0 0 0 0 0 0 16 Desenvolver Controle 0 0 4 4 0 0 0 0 0 0 8 Desenvolver View 0 0 0 4 4 0 0 0 0 0 8 Teste de Unidade 0 0 0 0 4 2 2 0 0 0 8 Teste Funcional 0 0 0 0 0 4 4 2 0 0 10 Documentação Técnica 0 0 0 0 0 0 4 4 2 2 12 Task Board é um quadro utilizado para o acompanhamento das sprints, durante as reuniões diárias. Por meio das informações contidas neste registro, aliadas ao seu posicionamento no task board, torna-se possível a qualquer um observar o andamento do projeto, de maneira clara e intuitiva. Tabela 3.3: Estrutura de um Quadro de Tarefas (Task Board). Product Backlog To Do Doing Done Sprint Backlog Unplanned Items Impediments To Discuss Incremento: O Incremento é um passo concreto em direção à Meta do Produto. Cada Incremento é aditivo a todos os Incrementos anteriores e verificado, garantindo que todos funcionem juntos. Para fornecer valor, o Incremento deve ser utilizável. Múltiplos Incrementos podem ser criados dentro de uma Sprint. A soma dos Incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um Incremento pode ser entregue aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um portão para liberar valor. O momento em que o trabalho se torna um Incremento é quando ele atende à Definição de Pronto (DoD). Resumo do ciclo de desenvolvimento SCRUM Até este ponto, apresentamos todas as ’peças de LEGO’ que compõem o Scrum: o Time (quem executa), os Eventos (quando o trabalho acontece) e os Artefatos (o que guia e o que é produzido). Agora que conhecemos cada componente individualmente, podemos finalmente montar o quebra-cabeça. O texto e a figura a seguir ilustram como todos esses elementos se conectam e interagem para formar o ciclo de desenvolvimento completo, transformando as necessidades do cliente em um Incremento de valor a cada Sprint. 38 CAPÍTULO 3. INTRODUÇÃO AO SCRUM Figura 3.5: Ciclo de desenvolvimento da metodologia Scrum Fonte: Cohn, 2005 O ciclo de desenvolvimento da metodologia SCRUM pode ser observado na figura 3.5, e ilustra o fato de que no início de cada projeto, clientes e desenvolvedores se reúnem com o objetivo de definir o Backlog do produto (que representa a lista de requisitos). Nesse momento também são estimados os custos do projeto e é feita uma análise dos riscos, bem como as ferramentas de trabalho e os integrantes da equipe são escolhidos e são definidas as datas para entrega de resultados a partir de priorizações sinalizadas pelo cliente. Esse período também é utilizado para escolher o SCRUM Master, eleito entre a equipe alocada para o projeto. Depois que o Product Backlog é definido, a equipe deve se dedicar à definição da Sprint Backlog, que contém uma lista de atividades que serão realizadas na próxima sprint, momento em que também são definidas as responsabilidades de cada membro do time. Após os desenvolvedores discutirem quais padrões serão adotados, as atividades de análise, codificação e testes devem se iniciar. Ao final de cada sprint um incremento do produto deve ser apresentado ao cliente para que o time obtenha uma retroalimentação. Caso algum defeito seja encontrado, deve ser adicionado ao backlog do produto. Na medida em que o ciclo de desenvolvimento ocorre, são aplicados diversos mecanismos de controle do SCRUM, como, por exemplo, ações sobre as funcionalidades não entregues, a necessidade de mudanças para correção de defeitos, problemas técnicos encontrados, bem como os riscos e as estratégias para evitá-los. 3.3 Aplicando seus conhecimentos 1. Qual é o principal objetivo do Scrum? (a) Criar documentação extensa (b) Entregar produtos de forma rápida e incremental (c) Estabelecer um cronograma rígido de trabalho (d) Aumentar o número de reuniões 2. Quais são os três papéis principais na metodologia Scrum? (a) Gerente de Projetos, Analista de Negócios, Desenvolvedor 39 CAPÍTULO 3. INTRODUÇÃO AO SCRUM (b) Product Owner, Scrum Master, Equipe de Desenvolvimento (c) Cliente, Fornecedor, Consultor (d) Coordenador, Supervisor, Executor 3. Qual é a duração típica de uma Sprint no Scrum? (a) 1 semana (b) 2 a 4 semanas (c) 1 mês (d) 3 meses 4. O que é o Product Backlog? (a) Um documento que lista as funcionalidades do produto em ordem de prioridade (b) Um cronograma de entregas (c) Um registro de problemas encontrados durante o projeto (d) Um relatório de desempenho da equipe 5. Qual das seguintes cerimônias do Scrum ocorre no início de cada Sprint? (a) Sprint Review (b) Daily Scrum (c) Sprint Retrospective (d) Sprint Planning Meeting 6. Descreva as principais responsabilidades do Product Owner e do Scrum Master. 7. Explique a importância das reuniões diárias (Daily Scrum) e como elas contribuem para a eficiência da equipe. 8. Quais são os principais benefícios de utilizar a metodologia Scrum em projetos de desenvolvimento? 9. Como o feedback dos clientes é incorporado no processo Scrum? 10. Agora você faz parte de uma equipe ágil, novamente fica como sugestão o projeto da gestão de uma fazenda. Divida-se em grupos e atribua papéis específicos para cada integrante: Product Owner, Scrum Master e Desenvolvedores. (i) Durante uma simulação de reunião de planejamento, o Product Owner deverá apresentar o problema e definir as prioridades do projeto; (ii) O Scrum Master será responsável por garantir que o processo seja seguido corretamente e por remover quaisquer impedimentos que surjam; (iii) Já os Desenvolvedores deverão discutir as possíveis soluções e planejar as tarefas necessárias para alcançar os objetivos definidos. (iv) Após a simulação, cada grupo deve compartilhar suas experiências, destacando os desafios enfrentados ao desempenhar cada papel e como as funções colaboraram para o sucesso do projeto. 40 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA tanques é utilizada na irrigação do plantio hidropônico de verduras e hortaliças da fazenda, após o tratamento, a água tratada é reutilizada, para os próprios tanques dos peixes. A fazenda solicita o desenvolvimento de um sistema, de forma que as atividades da fazenda, sejam realizadas de forma automatizadas como: verificação de horas-graus no processo de reprodução de peixe, comportamento do peixe após atingir o valor hora-grau, verificação da oxigenação da água, medição do nível da água no tanque, a irrigação e adubação do plantio. Segue as informações da aferição de hora-grau = soma do número de horas e temperatura da água: • 1ª aferição: Hora 1 = 30 graus →1 + 30 = 31 horas/graus • 2ª aferição: Hora 2 = 31 graus →2 + 31 = 33 horas/graus • Nª aferição: Hora M = K graus →M + K = Z horas/graus • Total = 1ª aferição + 2ª aferição + ... + Nª aferição. 5.2 Etapa 1: Design Thinking Com o cenário compreendido, iniciamos a aplicação do Design Thinking (como visto no Capítulo 1) para explorar o problema sob a perspectiva humana, identificar as reais necessidades e gerar ideias de soluções. Nessa etapa do projeto, é importante estar sensível à necessidade das pessoas, focar nas ideias que possibilitam uma solução e que haja boas transformações, ainda que sejam pequenas. A equipe não pode ter medo ou vergonha em apresentar as ideias, ainda que possam parecer “malucas”, não devem sentir “medo de errar”, o foco é apresentar as ideias de forma criativa, ou seja, o foco nessa etapa é apresentar a “Tempestade de ideias”, os filtros e os ajustes deverão ser feitos em um segundo momento. É muito importante que todos os membros da equipe tenham um espírito colaborativo, todos deverão ter uma visão colaborativa entre as ideias individuais e não desmerecer a ideia alheia, o absurdo para um pode ser a solução para o outro. Não há ideias absolutas, mas há ideias que poderão ser recebidas e posteriormente serem otimizadas. Fique Alerta! Buscar soluções que sejam desejáveis (atendem a uma necessidade humana), praticáveis (tecnicamente viáveis) e viáveis (economicamente sustentáveis). A tabela a seguir resume a aplicação das cinco fases do Design Thinking ao cenário da fazenda, mostrando as ferramentas utilizadas e os resultados obtidos em cada etapa. Tabela 5.1: Apresentação do Design Thinking do Projeto do Sistema. Etapa Ferramenta/Conceito Aplicação no Cenário Stakeholders Partes interessadas Proprietário da fazenda; Piscicultores; Técnicos Agrícola; Funcionários da Fazenda. Continua na próxima página... 47 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA Tabela 5.1: (Continuação) Etapa Ferramenta/Conceito Aplicação no Cenário Empatia Mapa da Empatia: o que pensam e sentem, o que ouvem, o que veem, o que falam e fazem. Dores identificadas: Aferição manual da hora e temperatura; Cálculo manual das horas-temperaturas; Inspeção visual do comportamento dos peixes; Verificação da oxigenação da água; Medir o nível da água; Irrigação manual do plantio. Definição Diagrama de afinidades: Revisar, organizar, identificar padrões e priorizar temas . Problemas definidos: Necessidade de automatizar as aferições de horas-graus; Automatizar a observação dos comportamentos dos peixes; Automatizar a coleta das informações do nível, temperatura e oxigenação da água; Automatizar a irrigação e o uso de resíduos. Ideação Brainstorming (tempestade de ideias) e Matriz SWOT. Ideias geradas: Sistematizar as atividades das aferições de horas-graus, medição de temperatura, nível e oxigenação e comportamento dos peixes de forma automatizada; Sistematizar a irrigação e adubação do plantio; Criar um Aplicativo do sistema automatizado. Prototipação Criação de Modelos (ex: maquetes, wireframes). Protótipo proposto: Sistema de Automação de Aferições, comportamento e Irrigação. Teste Colhendo Feedback dos stakeholders. Validação: Testar o funcionamento do protótipo do sistema no cenário apresentado e validar as funcionalidades com os usuários. Fique Alerta! As ideias e soluções apresentadas são um ponto de partida. O processo de ideação no Design Thinking incentiva a geração de múltiplas alternativas. 5.3 Etapa 2: Scrum Após a fase de Design Thinking, onde exploramos o problema e idealizamos uma solução (um sistema automatizado), passamos a usar o framework Scrum (detalhado no Capítulo 3) para gerenciar o desenvolvimento dessa solução de forma ágil e iterativa. Na metodologia SCRUM, as tarefas são adaptáveis, interativas, rápidas, flexíveis e eficientes, com o intuito de fornecer resultados ágeis em todas as etapas do projeto, de forma transparente, responsivo e contínuo progresso. Visando as características do SCRUM, iremos empregá-las na próxima fase do projeto. 48 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA Fique Alerta! A equipe SCRUM deverá estar focada e comprometida com o projeto em sua totalidade, ou seja, desde a concepção, desenvolvimento, testes, entrega e feedback pós-entrega. Lembrar sempre: O Time SCRUM é colaborativo e não apenas participativo, esse entendimento fará toda a diferença no desenvolvimento, progresso e resultados. 5.3.1 Grupo de Trabalho O primeiro passo no Scrum é definir o Time Scrum. A tabela a seguir mostra uma possível composição, separando os stakeholders (grupo ”Central”) dos papéis que compõem o Time Scrum (grupo ”Não-Central”), embora lembremos que o Product Owner atua como ponte entre eles e é parte do Time Scrum. Tabela 5.2: Apresentação do Grupo de Trabalho. Central (Stakeholders) Não – Central (Time SCRUM) • Proprietário da fazenda; • Piscicultores; • Técnicos Agrícola; • Funcionários da fazenda. Product Owner Scrum Master Scrum Desenvolvedores A figura abaixo ilustra o fluxo de trabalho no Scrum, desde a priorização do Backlog pelo Product Owner até a entrega de incrementos (Entregáveis) pelo Time Scrum e a validação na Sprint Review. Figura 5.1: Diagrama do fluxo de incremento do projeto Fonte: Scrumstudy. 49 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA 5.3.2 Visão A ”Visão”do produto define o objetivo geral e o propósito do que será construído. Ela serve como guia para o Product Owner e o Time Scrum. Tabela 5.3: Apresentação da Visão do Projeto do Sistema. Conceito Descrição Visão (apresentação da demanda) ”A fazenda solicita o desenvolvimento de um sistema, de forma que essas atividades de verificação de horas-graus no processo de reprodução de peixe, comportamento do peixe após atingir o valor hora-grau, verificação da oxigenação da água, medição do nível da água no tanque, a irrigação e adubação do plantio, sejam realizados de forma automatizadas.” Fique Alerta! Após o recebimento das demandas (Visão), o Product Owner deverá se reunir com as partes envolvidas (stakeholders) para coletar o levantamento das necessidades específicas, que serão traduzidas em Histórias de Usuário. 5.3.3 Histórias do Usuário As Histórias de Usuário descrevem funcionalidades sob a perspectiva de quem as utilizará (”Como um [ator], eu quero [ação] para que [benefício]”). Elas formam a base do Product Backlog. Veja exemplos coletados para o sistema da fazenda: Tabela 5.4: Apresentação das Histórias da Visão do Projeto do Sistema. ID-H Descrição da História do Usuário 1 Como proprietário da fazenda, eu gostaria de ter um sistema que automatizasse as atividades de piscicultura e plantio da fazenda. 2 Como proprietário, eu gostaria que cada funcionário criasse seu próprio cadastro no sistema, seja piscicultor, técnico agrônomo ou funcionário da fazenda e que haja classificação de acesso. 3 Como proprietário, eu gostaria que o sistema gerasse relatório com gráficos das atividades da piscicultura e plantio da fazenda. 4 Como piscicultor eu preciso acompanhar as informações aferidas da temperatura e oxigenação da água dos tanques dos peixes. 5 Como piscicultor eu preciso de um sistema que realize a medição da hora e temperatura no período da reprodução dos peixes e que gere o cálculo hora-grau. 6 Como piscicultor, desejo que o sistema permita o cadastro de hora-grau para cada espécie de peixe. Continua na próxima página... 50 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA Tabela 5.4: (Continuação) ID-H Descrição da História do Usuário 7 Como piscicultor eu quero realizar consultas das informações coletadas dos tanques dos peixes. 8 Como piscicultor eu quero que o sistema realize relatórios com gráficos com as informações hora-grau do período da reprodução dos peixes. 9 Como piscicultor eu quero que o sistema realize relatórios com gráficos do período das temperaturas e oxigenação da água, por dia, semana, mês e ano para analisar a influência das estações climáticas. 10 Como piscicultor, quero um sistema que realize amostras visuais do comportamento dos peixes no período da reprodução e que gere um relatório. 11 Como piscicultor, quero um sistema que realize amostras visuais do comportamento dos peixes em cada estação climática e que gere um relatório. 12 Como técnico agrícola, quero que o sistema de irrigação do plantio seja automatizado. 13 Como técnico agrícola, quero que o aproveitamento dos resíduos dos peixes, utilizados para adubar o plantio, seja realizado de forma automatizada. 14 Como piscicultor, desejo que o sistema emita um sinal de alerta quando a hora-grau tiver próxima da hora-grau apropriada para a reprodução por cada espécie de peixe. 15 Como técnico agrícola, quero que o sistema emita um sinal de alerta, caso o sistema automatizado de irrigação não esteja operando de forma correta. 16 Como técnico agrícola, quero que o sistema emita um sinal de alerta, caso o sistema automatizado de adubação não esteja operando de forma correta. Note que nem toda História de Usuário precisa seguir rigidamente o formato ”Como um..., eu quero..., para que...”. O importante é capturar a necessidade do usuário. Fique Alerta! Esta lista inicial pode (e deve) evoluir. Novas histórias podem ser adicionadas e as existentes podem ser refinadas ao longo do projeto. Fique Alerta! “Os Épicos são escritos nas fases iniciais do projeto, quando a maioria das Histórias de Usuário são funcionalidades de alto nível ou quando as descrições de produtos e requisitos são amplamente definidas...” (ScrumStudy). Muitas das histórias acima podem ser consideradas Épicos iniciais. 51 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA 5.3.4 Classificação das Histórias Após coletar as histórias, o próximo passo é agrupá-las por funcionalidades ou temas comuns. Isso ajuda a organizar o trabalho e a identificar os principais requisitos do sistema. Fique Alerta! Este processo de agrupar e refinar histórias faz parte do Backlog Refinement (Refinamento do Backlog), uma atividade contínua no Scrum. Tabela 5.5: Apresentação da classificação das Histórias do Projeto do Sistema. ID-Func. Funcionalidade Agrupada Histórias de Usuário (ID-H) Relacionadas R001 Cadastrar Funcionário 2 R002 Gerar e Emitir Relatórios 3, 8, 9, 10, 11, 12 R003 Consultar aferições 4, 5, 7 R004 Consultar cálculo hora-grau 5 R005 Cadastrar hora-grau 6 R006 Emissão de sinal de alerta 5, 6, 14, 15, 16 5.3.5 Backlog Priorizado do Produto Com as funcionalidades identificadas, o Product Owner cria o Product Backlog Priorizado. Esta é a lista ordenada de tudo que é desejado no produto, com os itens de maior valor para o negócio no topo. Fique Alerta! “O Dono do Produto desenvolve um Backlog Priorizado do Produto, que contém uma lista de prioridades de negócios e de requisitos dos projetos, escritos na forma de Épico(s), que são as Histórias de Usuário de alto nível.” (ScrumStudy). Tabela 5.6: Apresentação do Product Backlog Priorizado do Projeto do Sistema. ID Funcionalidade (Item do Backlog) Prioridade R001 Cadastrar Funcionário Alta R004 Consultar cálculo hora-grau Alta R005 Cadastrar hora-grau Alta R006 Emissão de sinal de alerta Alta R002 Gerar e Emitir Relatórios Média R003 Consultar aferições Média 52 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA Note que a ordem na tabela acima foi ajustada para refletir a priorização (Alta antes de Média). A priorização é dinâmica e pode mudar ao longo do projeto. 5.3.6 Backlog do Produto (com Épicos Detalhados) Itens de maior prioridade no Product Backlog (especialmente os Épicos) são detalhados em Histórias de Usuário menores e mais gerenciáveis, prontas para serem consideradas em uma Sprint. Abaixo, vemos o detalhamento do item R001 (”Cadastrar Usuário”). Tabela 5.7: Apresentação do Detalhamento de Épico (R001) no Backlog do Produto. ID-Fun. Épico ID-E História de Usuário Detalhada Prior. R001 Cadastrar Usuário E001 Como usuário, quero poder fazer login usando meu usuário/CPF e senha para acessar o sistema. Alta E002 Como administrador, quero poder gerenciar (criar, editar, desativar) contas de usuários. Alta E003 Como administrador, quero poder definir perfis de acesso (piscicultor, técnico, etc.). Alta E004 Como novo funcionário, quero poder realizar um auto-cadastro inicial no sistema. Alta E005 Como usuário logado, quero poder visualizar e editar meus dados cadastrais. Alta E006 Como usuário logado, quero ver um menu principal (Dashboard) com as opções disponíveis para meu perfil. Alta R002 Gerar e Emitir Relatórios ... (Detalhar futuramente) ... R003 Consultar aferições ... (Detalhar futuramente) ... R004 Consultar cálculo hora-grau ... (Detalhar futuramente) ... R005 Cadastrar hora-grau ... (Detalhar futuramente) ... R006 Emissão de sinal de alerta ... (Detalhar futuramente) ... Fique Alerta! O detalhamento dos Épicos R002 a R006 seria feito em sessões de Refinamento do Backlog quando sua prioridade os trouxer para o topo da lista. 5.3.7 Backlog da Sprint Durante a Sprint Planning (Planejamento da Sprint), o Time Scrum seleciona os itens de maior prioridade do Product Backlog que acredita poder concluir dentro da Sprint. Esses itens formam o Sprint Backlog. 53 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA Fique Alerta! Sprint Backlog: é a lista de trabalho (itens do Product Backlog e tarefas para alcançá-los) que o Time Scrum se compromete a realizar durante a Sprint. A tabela abaixo mostra um exemplo de planejamento de Sprints para entregar as funcionalidades de Cadastro de Usuário (R001), divididas em grupos menores (Épicos E001 a E006) ao longo de três Sprints. A Release 1 agrupa a entrega dessas funcionalidades. Tabela 5.8: Apresentação do Backlog da Sprint do Projeto do Sistema. ID da Sprint ID-E Itens do Product Backlog Selecionados Complex. Início Fim Sprint 1 E001 Cadastrar Usuário – Área de Login Média 06/01/2025 20/01/2025 E004 Cadastrar Usuário – Área de Login – Auto Cadastro Média E005 Cadastrar Usuário – Meus Dados Média Sprint 2 E002 Cadastrar Usuário – Administrador Baixa 21/01/2025 27/01/2025 E003 Cadastrar Usuário – Gerenciar Perfil Baixa Sprint 3 E006 DashBoard Menu Média 28/01/2025 11/02/2025 Entregar Release 1: 12/02/2025 5.3.8 Sprint Planning A reunião de Sprint Planning é onde o Time Scrum detalha o *como* o trabalho selecionado para o Sprint Backlog será realizado. Define-se a Meta da Sprint e criam-se as tarefas necessárias para transformar os itens do backlog em um Incremento ”Pronto”. Abaixo, um exemplo do planejamento detalhado para a Sprint 1. Após a definição de cada Sprint, cada Sprint deverá ser documentada de acordo com as especificações técnicas e abordagens de desenvolvimento. Utilizando as informações da tabela anterior, a documentação de cada Sprint é a próxima atividade a ser realizada, atividade conhecida como Sprint Planning. Fique Alerta! O planejamento da Sprint é muito importante, pois são documentados os procedimentos fundamentais para a execução das atividades, as ações, o tempo de execução e tempo de entrega e quais as tarefas de cada pessoa do Time Scrum. Todos os membros do Time Scrum deverão participar do planejamento da Sprint. 54 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA Tabela 5.9: Apresentação da Sprint 1 - Modulo 1 do Projeto do Sistema. Sprint Planning Data 06/01/2025 Sprint 1 Participantes Membro 1, Membro 2, Membro 3, ..., Membro N Meta da Sprint (Exemplo) Disponibilizar as funcionalidades básicas de login (usuário/senha, recuperação) e auto-cadastro para os usuários da fazenda. Objetivos da Sprint A Sprint 1 tem como objetivo o desenvolvimento da tela de Login para o Módulo #1 do sistema. O usuário terá a opção de realizar o login utilizando o nome do usuário, CPF ou a sua conta do Google, por meio de uma API integrada. Time-box 2 semanas Itens do Sprint Backlog Itens do Product Backlog: E001, E004, E005 (Funcionalidade não listada no Backlog, mas mencionada nos objetivos: Recuperar Senha) Tarefas Planejadas: (Exemplo) - Criar modelo de dados do usuário - Desenvolver API de autenticação - Desenvolver API de recuperação de senha - Desenvolver tela de login (UI) - Desenvolver tela de auto-cadastro (UI) - Desenvolver tela de ”Meus Dados”(UI) - Integrar UI com APIs - Escrever testes unitários/integração - Configurar pipeline de CI/CD Detalhes das Funcionalidades e Testes Funcionalidade 1: Autenticação com Login e Senha (E001) Descrição A funcionalidade permite que os usuários façam login no sistema utilizando nome de usuário ou CPF e senha, cadastrado anteriormente no sistema. Testes (Critérios de Aceite) Cenário 1 (Sucesso): Login com credenciais válidas. Dado que o usuário está na tela de login Quando ele insere nome de usuário/CPF e senha corretos Eclica em ”Entrar” Então ele é redirecionado para a página principal do sistema. Cenário 2 (Falha): Usuário/CPF inválido. Dado que o usuário está na tela de login Quando ele insere nome de usuário ou CPF inexistente Eclica em ”Entrar” Então o sistema exibe a mensagem de erro: ”O nome de usuário ou CPF está incorreto. Tente novamente.”. 55 CAPÍTULO 5. ESTUDO DE CASO APLICADO: GESTÃO DE UMA FAZENDA DE PISCICULTURA Tabela 5.9: (Continuação) Sprint Planning Cenário 3 (Falha): Senha inválida. Dado que o usuário está na tela de login Quando ele insere usuário/CPF válido e senha incorreta Eclica em ”Entrar” Então o sistema exibe a mensagem de erro: ”A senha está incorreta. Tente novamente.”. Cenário 4 (Falha): Conta bloqueada/desativada. Dado que o usuário está na tela de login Quando ele tenta logar com uma conta bloqueada/desativada Eclica em ”Entrar” Então o sistema exibe a mensagem de erro: ”Sua conta está bloqueada ou desativada. Entre em contato com o suporte.”. Funcionalidade 2: Recuperar Senha Descrição A funcionalidade permite a recuperação da senha através do e-mail caso o usuário esqueça sua senha. Testes (Critérios de Aceite) Cenário 1 (Sucesso): Recuperação bem-sucedida. Dado que o usuário está na tela de login Quando ele clica em ”Recuperar senha” Einsere seu e-mail cadastrado Eclica no link recebido por e-mail Edefine e confirma uma nova senha Então o sistema exibe a mensagem ”Senha alterada com sucesso” Eele consegue logar com a nova senha. Cenário 2 (Falha): E-mail não cadastrado. Dado que o usuário está na tela de recuperação de senha Quando ele insere um e-mail não cadastrado Então o sistema exibe uma mensagem informativa (sem confirmar se o e-mail existe ou não por segurança). UI/UX - Sprint 1 Tela de Login: Necessidades da Sprint Essencial. 56