Gerenciamento de projeto - Unidade I

Prévia do material em texto

<p>Autor: Prof. Tarcísio de Souza Peres</p><p>Colaboradores: Prof. Angel Antonio Gonzalez Martinez</p><p>Profa. Larissa Rodrigues Damiani</p><p>Gerenciamento de</p><p>Projetos de Software</p><p>Professor conteudista: Tarcísio de Souza Peres</p><p>É formado em Engenharia da Computação e mestre pela Unicamp. Atuou como pesquisador no Human Cancer</p><p>Genome Project, no qual utilizou algoritmos e programação orientada a objetos. Tem MBA em Gestão de TI pela Fiap,</p><p>possui formação em Gestão de Projetos pela FIA/USP e cursou Gestão Estratégica e Competitividade pela Fundação</p><p>Dom Cabral. Com perfil multidisciplinar, tem experiência nas áreas de tecnologia, saúde, governança, novos negócios</p><p>e inovação. Além disso, é certificado pelo PMI, Cobit e autor de livro sobre Mercado Financeiro. Trabalhou também em</p><p>multinacionais e órgãos públicos. Atua como empreendedor (startups de inovação em tecnologia), professor na UNIP,</p><p>cFGV e no Centro Paula Souza.</p><p>© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou</p><p>quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem</p><p>permissão escrita da Universidade Paulista.</p><p>Dados Internacionais de Catalogação na Publicação (CIP)</p><p>P437g Peres, Tarcísio de Souza.</p><p>Gerenciamento de Projetos de Software / Tarcísio de Souza</p><p>Peres. – São Paulo: Editora Sol, 2024.</p><p>208 p., il.</p><p>Nota: este volume está publicado nos Cadernos de Estudos e</p><p>Pesquisas da UNIP, Série Didática, ISSN 1517-9230.</p><p>1. Equipe ágil. 2. Desenvolvimento ágil. 3. Gestão ágil. I. Título.</p><p>CDU 681.3.02</p><p>U520.32 – 24</p><p>Profa. Sandra Miessa</p><p>Reitora</p><p>Profa. Dra. Marilia Ancona Lopez</p><p>Vice-Reitora de Graduação</p><p>Profa. Dra. Marina Ancona Lopez Soligo</p><p>Vice-Reitora de Pós-Graduação e Pesquisa</p><p>Profa. Dra. Claudia Meucci Andreatini</p><p>Vice-Reitora de Administração e Finanças</p><p>Prof. Dr. Paschoal Laercio Armonia</p><p>Vice-Reitor de Extensão</p><p>Prof. Fábio Romeu de Carvalho</p><p>Vice-Reitor de Planejamento</p><p>Profa. Melânia Dalla Torre</p><p>Vice-Reitora das Unidades Universitárias</p><p>Profa. Silvia Gomes Miessa</p><p>Vice-Reitora de Recursos Humanos e de Pessoal</p><p>Profa. Laura Ancona Lee</p><p>Vice-Reitora de Relações Internacionais</p><p>Prof. Marcus Vinícius Mathias</p><p>Vice-Reitor de Assuntos da Comunidade Universitária</p><p>UNIP EaD</p><p>Profa. Elisabete Brihy</p><p>Profa. M. Isabel Cristina Satie Yoshida Tonetto</p><p>Prof. M. Ivan Daliberto Frugoli</p><p>Prof. Dr. Luiz Felipe Scabar</p><p>Material Didático</p><p>Comissão editorial:</p><p>Profa. Dra. Christiane Mazur Doi</p><p>Profa. Dra. Ronilda Ribeiro</p><p>Apoio:</p><p>Profa. Cláudia Regina Baptista</p><p>Profa. M. Deise Alcantara Carreiro</p><p>Profa. Ana Paula Tôrres de Novaes Menezes</p><p>Projeto gráfico: Revisão:</p><p>Prof. Alexandre Ponzetto Maitê Donato</p><p>Vitor Andrade</p><p>Gerenciamento de Projetos de Software</p><p>APRESENTAÇÃO ......................................................................................................................................................7</p><p>INTRODUÇÃO ...........................................................................................................................................................9</p><p>Unidade I</p><p>1 INTRODUÇÃO À AGILIDADE E FUNDAMENTOS DOS FRAMEWORKS ÁGEIS ............................ 13</p><p>1.1 Breve histórico sobre o PMI e a abordagem tradicional de gestão</p><p>de projetos, incluindo uma introdução ao PMBOK........................................................................ 14</p><p>1.2 História e princípios do Manifesto Ágil ....................................................................................... 17</p><p>1.3 A mudança do paradigma de gestão de projetos em TI ....................................................... 20</p><p>1.4 Visão geral dos frameworks ágeis: Scrum, Kanban e XP (Extreme Programming) .... 24</p><p>1.5 Comparação entre os frameworks ágeis ..................................................................................... 27</p><p>2 CONFIGURANDO E GERENCIANDO EQUIPES ÁGEIS ......................................................................... 30</p><p>2.1 Estruturação de squads: papéis e responsabilidades ............................................................. 32</p><p>2.2 Ambientes de desenvolvimento ágil: espaços físicos e virtuais ........................................ 36</p><p>2.3 Cultura ágil: valores e comportamentos para o sucesso do time .................................... 42</p><p>2.4 Planejamento iterativo e incremental, técnicas de estimativa ágil</p><p>(Planning Poker etc.) ................................................................................................................................. 45</p><p>Unidade II</p><p>3 PLANEJAMENTO, EXECUÇÃO E GESTÃO ÁGIL....................................................................................... 60</p><p>3.1 Priorização de backlog e roadmaps ágeis .................................................................................. 61</p><p>3.2 Ciclos de desenvolvimento iterativos: sprints .......................................................................... 64</p><p>3.3 Daily Stand-ups e sincronização de equipe .............................................................................. 67</p><p>3.4 Gestão de backlogs e iterações ....................................................................................................... 71</p><p>4 QUALIDADE, TESTES E PRÁTICAS DE ENTREGA CONTÍNUA (CD) .................................................. 81</p><p>4.1 A importância da qualidade e testes nas abordagens tradicionais do PMI</p><p>e como a agilidade incorpora e expande esses conceitos ........................................................... 82</p><p>4.2 Integração contínua (CI) e entrega contínua (CD) ................................................................. 86</p><p>4.3 Testes automatizados e TDD (Test Driven Development) ..................................................... 91</p><p>4.4 Deployment e monitoramento em ambientes ágeis ............................................................. 97</p><p>Sumário</p><p>Unidade III</p><p>5 ESCALANDO O ÁGIL E FERRAMENTAS DE SUPORTE .......................................................................107</p><p>5.1 Métodos para escalar ágil em grandes organizações (SAFe, LeSS, Nexus) .................108</p><p>5.2 Ferramentas digitais para colaboração e gestão de projetos (Jira, Trello, Asana) ....117</p><p>5.3 Automação e ferramentas para CI/CD (Jenkins, GitLab CI) ...............................................125</p><p>5.4 Seleção e adaptação de ferramentas para equipes ..............................................................131</p><p>6 TENDÊNCIAS FUTURAS EM TECNOLOGIA E GESTÃO DE PROJETOS ..........................................140</p><p>6.1 DevOps e NoOps .................................................................................................................................141</p><p>6.2 Inteligência artificial e machine learning na gestão de projetos ...................................146</p><p>6.3 Trabalho remoto e gestão de equipes distribuídas ...............................................................148</p><p>Unidade IV</p><p>7 DESENVOLVIMENTO PROFISSIONAL E LIDERANÇA EM GESTÃO ÁGIL .....................................158</p><p>7.1 Certificações ágeis (Scrum Master, Product Owner, Agile Coach, PMI-ACP) ...........159</p><p>7.2 Desenvolvimento de habilidades de liderança e colaboração .........................................166</p><p>7.3 Networking, comunidades ágeis e aprendizado contínuo ................................................168</p><p>8 ESTUDOS DE CASO E APLICAÇÕES PRÁTICAS ....................................................................................171</p><p>8.1 Case studies de implementação de metodologia ágil em larga escala ........................172</p><p>8.2 Desafios e estratégias de implementação ................................................................................180</p><p>8.3 Exemplos práticos e exercícios de aplicação dos conceitos ágeis ..................................181</p><p>8.4 Glossário de termos ágeis ...............................................................................................................191</p><p>7</p><p>APRESENTAÇÃO</p><p>Projetos ágeis têm transformado significativamente a maneira como as empresas</p><p>de</p><p>integração frequente entre equipes</p><p>Ambientes nos quais a colaboração</p><p>entre equipes é essencial</p><p>Desenvolvimento de</p><p>software em grandes</p><p>empresas, projetos</p><p>complexos de TI</p><p>DA (Disciplined</p><p>Agile)</p><p>Framework híbrido e flexível</p><p>Integração de várias práticas ágeis e Lean</p><p>Foco em agilidade empresarial e</p><p>flexibilidade organizacional</p><p>Organizações que buscam uma</p><p>abordagem ágil personalizada</p><p>Ambientes que necessitam de</p><p>flexibilidade em práticas ágeis</p><p>Grandes empresas que desejam</p><p>integrar várias metodologias ágeis</p><p>Grandes empresas</p><p>de TI, consultorias,</p><p>organizações</p><p>que necessitam</p><p>de flexibilidade</p><p>metodológica</p><p>2 CONFIGURANDO E GERENCIANDO EQUIPES ÁGEIS</p><p>Configurar e gerenciar equipes ágeis é uma tarefa multifacetada que exige uma compreensão</p><p>profunda dos princípios do desenvolvimento ágil, assim como a aplicação prática de técnicas</p><p>e ferramentas específicas para garantir a eficiência e a colaboração. Desse modo, neste tópico,</p><p>abordaremos diversos aspectos essenciais, começando pela estruturação dos squads, passando pelo</p><p>ambiente de desenvolvimento, a cultura ágil, o planejamento iterativo e incremental, até as técnicas de</p><p>estimativa ágil.</p><p>A estruturação de squads é fundamental para o sucesso das equipes ágeis. Squads são pequenos</p><p>grupos multifuncionais, geralmente compostos por 5 a 9 membros, cada um trazendo habilidades e</p><p>conhecimentos específicos que, juntos, permitem a entrega de um produto ou funcionalidade de forma</p><p>autônoma. Dentro de um squad, há diferentes papéis e responsabilidades.</p><p>O Product Owner (PO) é responsável por maximizar o valor do produto e gerenciar o backlog,</p><p>priorizando tarefas conforme a necessidade do negócio e feedback dos usuários. O Scrum Master, por</p><p>sua vez, facilita o processo ágil, removendo impedimentos e garantindo que a equipe siga os princípios</p><p>e as práticas ágeis. Os desenvolvedores, designers, testadores e outros especialistas colaboram para</p><p>transformar requisitos em incrementos funcionais do produto. A clareza de papéis e responsabilidades</p><p>é crucial para evitar sobreposições e lacunas no trabalho, promovendo uma sinergia eficiente</p><p>dentro da equipe.</p><p>O ambiente de desenvolvimento ágil, tanto físico quanto virtual, também desempenha um papel</p><p>significativo na produtividade e moral da equipe. Em um espaço físico, o layout deve promover</p><p>a colaboração e a comunicação aberta. Áreas de trabalho abertas, salas de reuniões equipadas com</p><p>ferramentas de videoconferência e quadros brancos para brainstorming são componentes essenciais.</p><p>No entanto, com o aumento do trabalho remoto, a criação de ambientes virtuais eficazes tornou-se</p><p>igualmente importante.</p><p>31</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Plataformas de comunicação como Slack, ferramentas de gestão de projetos como Jira ou Trello, e</p><p>sistemas de versionamento de código como GitHub são indispensáveis para manter a equipe conectada</p><p>e  sincronizada. As reuniões diárias (Daily Stand-ups) ajudam a manter todos informados sobre o</p><p>progresso e desafios, independentemente de onde os membros da equipe estejam fisicamente.</p><p>A cultura ágil é outro pilar para o sucesso das equipes ágeis. Baseia-se em valores e comportamentos</p><p>que promovem a colaboração, adaptabilidade e foco na entrega contínua de valor. Transparência,</p><p>comunicação aberta e confiança são valores fundamentais. A equipe deve ser encorajada a experimentar,</p><p>aprender com os erros e iterar rapidamente. A mentalidade de melhoria contínua, na qual o feedback</p><p>frequente é usado para ajustar processos e melhorar a qualidade do produto, é vital. Além disso, é</p><p>importante celebrar as conquistas e reconhecer o esforço de cada membro, fortalecendo o espírito de</p><p>equipe e a motivação.</p><p>O planejamento iterativo e incremental é a espinha dorsal do desenvolvimento ágil. Em vez de um</p><p>plano detalhado de longo prazo, que pode se tornar rapidamente obsoleto, as equipes ágeis planejam</p><p>em pequenos ciclos (iterações ou sprints). Cada iteração dura geralmente de uma a quatro semanas, ao</p><p>final das quais a equipe deve entregar um incremento funcional do produto.</p><p>Esse ciclo permite uma rápida adaptação às mudanças nas necessidades do negócio ou feedback dos</p><p>usuários. No início de cada sprint, a equipe realiza uma reunião de planejamento para definir as metas</p><p>e as tarefas que serão trabalhadas. Ao final, uma revisão do sprint permite avaliar o que foi alcançado e</p><p>identificar áreas de melhoria.</p><p>As técnicas de estimativa ágil, como o Planning Poker, são ferramentas eficazes para prever o esforço</p><p>necessário para completar tarefas. Ele envolve toda a equipe na estimativa, promovendo discussões e</p><p>compartilhamento de conhecimentos. Cada membro usa cartas numeradas para indicar sua estimativa</p><p>de esforço para uma determinada tarefa.</p><p>Se houver discrepâncias significativas nas estimativas, a equipe discute os motivos por trás de suas</p><p>escolhas até chegar a um consenso. Outras técnicas incluem a estimativa por Pontos de História, em que</p><p>tarefas são comparadas a outras já concluídas para determinar sua complexidade relativa. Além disso,</p><p>temos a técnica do T-shirt sizing, que categoriza tarefas em tamanhos (P, M, G, GG) de acordo com seu</p><p>esforço estimado.</p><p>Isso significa que configurar e gerenciar equipes ágeis exige uma abordagem holística, que abrange</p><p>a estruturação clara de squads, a criação de ambientes de desenvolvimento propícios, a promoção</p><p>de uma cultura ágil robusta, a implementação de planejamento iterativo e incremental e o uso de</p><p>técnicas eficazes de estimativa ágil. Ao seguir esses princípios e práticas, as equipes podem alcançar alta</p><p>produtividade, adaptação rápida às mudanças e, sobretudo, a entrega contínua de valor aos usuários</p><p>e ao negócio.</p><p>32</p><p>Unidade I</p><p>2.1 Estruturação de squads: papéis e responsabilidades</p><p>A estruturação de squads, ou equipes ágeis, é uma abordagem amplamente adotada no</p><p>desenvolvimento de software, e em outras áreas que exigem alta colaboração e rapidez na entrega de</p><p>valor (Narayan, 2015). Essa metodologia baseia-se em formar equipes multidisciplinares e autônomas</p><p>que possuem todas as habilidades necessárias para completar um projeto de modo eficiente.</p><p>Cada squad é responsável por um conjunto específico de tarefas ou uma área de produto,</p><p>permitindo uma grande flexibilidade e agilidade na execução das atividades. A definição clara de</p><p>papéis e responsabilidades dentro de um squad é crucial para o seu sucesso, garantindo que todos os</p><p>membros saibam exatamente suas funções e como contribuir para os objetivos da equipe. Um squad</p><p>típico é composto por um conjunto de papéis fundamentais, incluindo Product Owner, Scrum Master,</p><p>desenvolvedores, designers e testadores. Cada um desses papéis desempenha funções específicas que,</p><p>quando bem executadas, contribuem para a eficácia do squad.</p><p>O Product Owner (PO), por exemplo, é o responsável por maximizar o valor do produto e</p><p>gerenciar o backlog do produto. Ele atua como a ponte entre a equipe de desenvolvimento e as partes</p><p>interessadas externas, como clientes e outras áreas da empresa. O PO é responsável por definir e</p><p>priorizar as funcionalidades e requisitos do produto, garantindo que a equipe esteja sempre focada nas</p><p>tarefas mais importantes. Sua principal responsabilidade é compreender as necessidades dos clientes</p><p>e do negócio, transformando-as em histórias de usuário e critérios de aceitação claros para a equipe</p><p>de desenvolvimento.</p><p>O Scrum Master, por sua vez, é o guardião do processo e das práticas ágeis. Ele tem a responsabilidade</p><p>de garantir que o time siga os princípios e valores do Scrum, facilitando as cerimônias como as reuniões</p><p>diárias (Daily Stand-ups), planning, reviews e retrospectives. O Scrum Master também trabalha para</p><p>remover impedimentos que possam estar bloqueando o progresso do time e ajuda a equipe a melhorar,</p><p>continuamente, seus processos e práticas. Ele age como um coach para o time, promovendo um ambiente</p><p>de colaboração e autogerenciamento.</p><p>Os desenvolvedores são os membros que escrevem o código e constroem o produto. Eles são</p><p>responsáveis por transformar os requisitos definidos pelo PO em funcionalidades reais. Os desenvolvedores</p><p>trabalham em conjunto para garantir a qualidade do código e a CD de incrementos de produto. Eles</p><p>também participam das cerimônias ágeis e colaboram com o PO e o Scrum Master para ajustar o</p><p>planejamento conforme necessário.</p><p>Os designers desempenham um papel crucial na criação da experiência do usuário (UX) e na</p><p>interface do usuário (UI). Eles trabalham próximos ao PO para entender os requisitos do usuário e traduzir</p><p>esses requisitos em protótipos e designs visuais. Eles também colaboram com os desenvolvedores para</p><p>garantir que os designs sejam implementados conforme especificado, mantendo a consistência visual e</p><p>funcionalidade intuitiva do produto.</p><p>Por fim, temos os testadores, ou QA (Quality Assurance), que são responsáveis por garantir que o</p><p>produto esteja livre de defeitos e atenda aos critérios de qualidade definidos. Eles escrevem e executam</p><p>33</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>casos de teste, identificam bugs e trabalham com os desenvolvedores para resolvê-los. Os testadores</p><p>também ajudam a definir estratégias de automação de testes e mantêm um processo contínuo de</p><p>melhoria na qualidade do produto.</p><p>Além desses papéis principais, outros especialistas, como analistas de negócios, arquitetos de</p><p>software e engenheiros de DevOps, podem ser incorporados ao squad conforme necessário. A inclusão</p><p>desses papéis adicionais depende da natureza do projeto e das necessidades específicas da equipe.</p><p>Observação</p><p>Engenheiros de DevOps são profissionais que desempenham um papel</p><p>crucial na integração e otimização dos processos de desenvolvimento</p><p>de software e operações de TI. DevOps, uma combinação das palavras</p><p>Development (Desenvolvimento) e Operations (Operações), é uma</p><p>abordagem que visa unificar e automatizar processos, facilitando a</p><p>colaboração entre equipes de desenvolvimento e operações para melhorar</p><p>a eficiência e a qualidade do software produzido.</p><p>A função principal de um engenheiro de DevOps é construir, e manter, a infraestrutura e as ferramentas</p><p>que suportam a CD de software. Isso envolve várias responsabilidades, incluindo a automação de tarefas</p><p>repetitivas, a implementação de práticas de CI e CD, e a garantia de que o ambiente de produção seja</p><p>estável e seguro.</p><p>Esses profissionais utilizam uma variedade de ferramentas e tecnologias para automatizar a</p><p>construção, teste e implantação do software. Tais ferramentas ajudam a criar pipelines automatizados</p><p>que podem compilar o código, executar testes e implantar o software em ambientes de produção de</p><p>modo rápido e confiável.</p><p>Além das habilidades técnicas, engenheiros de DevOps precisam ter uma forte compreensão</p><p>das práticas ágeis e das metodologias de desenvolvimento de software. Eles trabalham em estreita</p><p>colaboração com desenvolvedores para garantir que o código seja facilmente integrável e implantável,</p><p>e com equipes de operações para garantir que a infraestrutura suporte as necessidades do software em</p><p>produção. Essa colaboração é essencial para identificar e resolver rapidamente problemas que possam</p><p>surgir durante o desenvolvimento ou após o programa ser lançado.</p><p>A comunicação e a colaboração são elementos-chave para o sucesso de um squad. Reuniões</p><p>regulares, ferramentas de colaboração e uma cultura de feedback constante são essenciais para garantir</p><p>que todos os membros da equipe estejam alinhados e trabalhando em direção aos mesmos objetivos.</p><p>A autonomia do squad permite que ele tome decisões rápidas e se adapte rapidamente às mudanças,</p><p>sem depender de aprovações externas ou processos burocráticos.</p><p>A estruturação de squads bem-sucedida requer uma mentalidade de crescimento e uma disposição</p><p>para experimentar e ajustar as práticas conforme necessário. É importante que as organizações apoiem</p><p>34</p><p>Unidade I</p><p>seus squads, fornecendo os recursos e a formação necessários para que possam operar de maneira</p><p>eficaz e eficiente. Desta forma, a estruturação de squads com papéis e responsabilidades bem definidos</p><p>é fundamental para o sucesso em ambientes ágeis.</p><p>A colaboração, a comunicação e a autonomia são pilares dessa abordagem, permitindo que as equipes</p><p>entreguem valor contínuo e se adaptem rapidamente às necessidades dos clientes e do mercado. A clara</p><p>definição dos papéis de Product Owner, Scrum Master, desenvolvedores, designers e testadores, entre</p><p>outros, garante que todos os membros da equipe saibam exatamente suas funções e como contribuir</p><p>para os objetivos da equipe, criando um ambiente de trabalho produtivo e harmonioso.</p><p>Esse modelo de squads foi popularizado pela empresa Spotify e se assemelha a práticas de</p><p>desenvolvimento ágil pré-existentes, como o Scrum. Nele, já encontramos pequenas equipes</p><p>(Scrum Teams) que são multidisciplinares e autônomas, compostas por um Product Owner, um Scrum</p><p>Master e desenvolvedores, focadas em ciclos de desenvolvimento curtos chamados sprints. O modelo</p><p>Spotify, desenvolvido no início dos anos 2010, foi pioneiro na nomenclatura e na estrutura específica,</p><p>que inclui squads, tribos e guildas, tornando-se um caso de sucesso de como as organizações podem</p><p>escalar práticas ágeis.</p><p>Saiba mais</p><p>A empresa Spotify desenvolveu este modelo para atender às suas</p><p>necessidades específicas de inovação e crescimento rápido, lidando com</p><p>desafios que surgiram com o aumento da escala em uma organização ágil.</p><p>Para conhecer mais sobre como a Spotify implementou essa prática, leia o</p><p>seguinte livro.</p><p>LUNDBERG, A. Sucesso com a estrutura ágil do Spotify. Esquadrões, tribos</p><p>e capítulos – o próximo passo depois do Scrum e Kanban? [S.l.]: Books on</p><p>demand, 2021.</p><p>A partir da divisão e definições adotadas, analisemos os elementos desse modelo de squads. As tribos</p><p>são agrupamentos de squads que trabalham em áreas relacionadas, ou em projetos, que compartilham</p><p>objetivos estratégicos semelhantes. O propósito de uma tribo é proporcionar alinhamento entre squads</p><p>que têm missões que se sobrepõem ou que dependem uns dos outros para a entrega de produtos</p><p>ou serviços.</p><p>Uma tribo geralmente é liderada por um Tribe Lead, cuja função é assegurar que todos os squads</p><p>dentro da tribo estejam progredindo em direção aos objetivos comuns e resolver problemas de maior</p><p>escala que possam afetar várias equipes. Isso ajuda a manter a coesão e a sinergia entre os squads,</p><p>enquanto ainda lhes permite operar com um alto grau de autonomia.</p><p>35</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Guildas, por outro lado, são redes mais informais que se estendem por toda a organização e são</p><p>compostas por indivíduos com interesses ou habilidades compartilhadas. Por exemplo, pode haver</p><p>uma guilda para desenvolvedores de JavaScript, especialistas em UX, ou profissionais de QA. O principal</p><p>propósito de uma guilda é promover o compartilhamento de conhecimentos e melhores práticas entre</p><p>seus membros, que podem estar dispersos por diversos squads e tribos.</p><p>As guildas são geralmente auto-organizadas e lideradas por membros que são reconhecidos como</p><p>especialistas em suas áreas específicas. A figura a seguir sumariza os conceitos de squads, tribos e guildas.</p><p>Squads: no modelo</p><p>Spotify, um squad</p><p>é semelhante a um</p><p>Scrum Team. Cada</p><p>squad é responsável por</p><p>uma parte específica</p><p>do produto e opera</p><p>de maneira bastante</p><p>autônoma, decidindo</p><p>suas próprias prioridades</p><p>e métodos de trabalho,</p><p>com um escopo claro e</p><p>objetivos alinhados às</p><p>necessidades do negócio</p><p>Tribos: para</p><p>organizações maiores,</p><p>como a Spotify, nas</p><p>quais há muitos squads,</p><p>houve a necessidade</p><p>de uma camada extra</p><p>de agrupamento</p><p>para manter squads</p><p>que trabalham em</p><p>áreas de produto</p><p>relacionadas, alinhados</p><p>e eficientes. As tribos</p><p>são essencialmente</p><p>agrupamentos de</p><p>squads que facilitam</p><p>a comunicação e a</p><p>coordenação em uma</p><p>escala maior, sem</p><p>sacrificar a agilidade</p><p>Guildas: essas são</p><p>comunidades de</p><p>interesses que cortam</p><p>transversalmente</p><p>as tribos e squads,</p><p>permitindo que pessoas</p><p>com habilidades</p><p>similares ou interesses</p><p>comuns</p><p>(como</p><p>desenvolvimento</p><p>de back-end, design de</p><p>UX ou segurança</p><p>da informação)</p><p>compartilhem</p><p>conhecimentos, práticas</p><p>e inovações. As guildas</p><p>ajudam a promover</p><p>a aprendizagem</p><p>contínua e a melhoria</p><p>de habilidades em toda</p><p>a organização</p><p>Figura 4 – Resumo dos conceitos de squads, tribos e guildas</p><p>A inclusão de tribos e guildas no modelo de squads ajuda a organização a manter um equilíbrio</p><p>entre a autonomia do squad e a necessidade de alinhamento e padrões em toda a empresa. Tribos</p><p>garantem que esforços alinhados estejam sincronizados e que as interdependências sejam gerenciadas</p><p>eficazmente. Guildas, por sua vez, apoiam a melhoria contínua e o desenvolvimento profissional ao</p><p>facilitar o fluxo de informações e a inovação cruzada entre os especialistas.</p><p>Esses elementos contribuem significativamente para o dinamismo e a resiliência organizacional, pois</p><p>permitem uma adaptação rápida às mudanças do mercado e às necessidades dos clientes, ao mesmo</p><p>tempo que fortalecem a base de conhecimento e as competências dentro da organização.</p><p>36</p><p>Unidade I</p><p>Em relação à adoção de tribos e guildas por outras empresas, há uma variação significativa de</p><p>acordo com a cultura organizacional, necessidades e tamanho da empresa. Algumas empresas</p><p>adotam integralmente o modelo Spotify, incluindo squads, tribos e guildas, porque reconhecem valor</p><p>em promover não apenas a agilidade operacional, mas também uma forte cultura de aprendizado e</p><p>compartilhamento através das guildas, e um alinhamento estratégico eficaz através das tribos.</p><p>No entanto, outras empresas podem escolher adaptar o modelo para melhor se adequarem às suas</p><p>circunstâncias específicas. Por exemplo, algumas podem implementar squads sem necessariamente</p><p>formar tribos ou guildas, sobretudo se forem menores ou se as equipes já estiverem naturalmente</p><p>alinhadas sem a necessidade de uma estrutura adicional de tribos.</p><p>Do mesmo modo, algumas empresas podem achar alternativas às guildas para o compartilhamento</p><p>de conhecimento, como através de workshops regulares, sessões de treinamento ou outras formas de</p><p>compartilhamento de práticas. Portanto, enquanto o modelo Spotify oferece um framework robusto</p><p>para organizações que buscam escalar suas operações mantendo princípios ágeis, essa não é uma</p><p>fórmula única que se aplica igualmente bem a todos os contextos.</p><p>Empresas bem-sucedidas frequentemente adaptam modelos para atender às suas próprias</p><p>necessidades e cultura, adotando os elementos que fazem sentido para eles e modificando outros para</p><p>melhor alinhamento estratégico e operacional. A escolha de implementar squads com ou sem tribos</p><p>e guildas depende de muitos fatores, incluindo o tamanho da empresa, a complexidade dos produtos e o</p><p>grau de colaboração interdisciplinar necessário.</p><p>2.2 Ambientes de desenvolvimento ágil: espaços físicos e virtuais</p><p>Os ambientes de desenvolvimento ágil são projetados para facilitar a colaboração, a comunicação</p><p>e a eficiência entre os membros de uma equipe. Esses ambientes podem ser físicos, como escritórios</p><p>projetados especificamente para suportar metodologias ágeis, ou virtuais, utilizando ferramentas</p><p>digitais para conectar equipes. A estrutura e o design desses ambientes desempenham um papel crucial</p><p>no sucesso das práticas ágeis, promovendo a interação contínua e a adaptação rápida às mudanças.</p><p>No contexto dos espaços físicos, os ambientes de desenvolvimento ágil geralmente são projetados</p><p>para serem abertos e flexíveis, como o exemplo mostrado na figura 5. Escritórios com layout aberto</p><p>promovem a comunicação espontânea e a colaboração entre os membros da equipe. A ausência de</p><p>barreiras físicas, como cubículos ou salas fechadas, facilita a troca de ideias e a resolução rápida</p><p>de problemas.</p><p>37</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Figura 5 – Exemplo de espaço físico de trabalho de equipes ágeis. Imagem produzida</p><p>pelo próprio autor com tecnologia DALL-E, uma ferramenta de IA desenvolvida pela OpenAI</p><p>Além disso, a flexibilidade no mobiliário, como mesas móveis e cadeiras ajustáveis, permite que</p><p>os times reorganizem o espaço conforme necessário para atender às demandas específicas de cada</p><p>sprint ou projeto.</p><p>Outro elemento crucial dos espaços físicos ágeis é a presença de áreas dedicadas para diferentes</p><p>atividades. Salas de reunião pequenas, ou huddle rooms, são ideais para discussões rápidas e reuniões</p><p>stand-up. Salas maiores podem ser utilizadas para planejamentos de sprint, reviews e retrospectives.</p><p>Áreas de descanso e espaços informais, como lounges e cozinhas, incentivam interações sociais que</p><p>podem levar a insights valiosos e fortalecer os laços entre os membros da equipe.</p><p>A visualização do trabalho é um princípio fundamental nos ambientes ágeis. Quadros Kanban,</p><p>painéis Scrum e outras ferramentas visuais são frequentemente utilizados para rastrear o progresso</p><p>das tarefas e manter todos os membros da equipe informados sobre o estado atual do projeto. Esses</p><p>quadros geralmente são colocados em locais de fácil acesso e visibilidade, como indica a figura a seguir,</p><p>permitindo que a equipe rapidamente veja o que está sendo feito, o que precisa ser feito e quaisquer</p><p>impedimentos que possam estar bloqueando o progresso.</p><p>Figura 6 – Quadros para visualização do trabalho. Imagem produzida pelo próprio autor</p><p>com tecnologia DALL-E, uma ferramenta de IA desenvolvida pela OpenAI</p><p>38</p><p>Unidade I</p><p>Nos ambientes virtuais, a tecnologia desempenha um papel essencial na facilitação da colaboração</p><p>e comunicação. Ferramentas como Slack, Microsoft Teams e Zoom permitem que as equipes se</p><p>comuniquem em tempo real, independentemente de sua localização geográfica. Essas plataformas</p><p>oferecem funcionalidades como chat em grupo, videochamadas, compartilhamento de arquivos e</p><p>integração com outras ferramentas de gestão de projetos, como Jira e Trello, tornando a colaboração</p><p>mais eficiente e organizada.</p><p>Figura 7 – Equipe de trabalho interagindo de forma síncrona. Imagem produzida</p><p>pelo próprio autor com tecnologia DALL-E, uma ferramenta de IA desenvolvida pela OpenAI</p><p>As ferramentas de gestão de projetos são vitais para manter um fluxo de trabalho ágil em ambientes</p><p>virtuais. Aplicativos como Jira, Trello e Asana ajudam a rastrear tarefas, gerenciar backlog e priorizar</p><p>atividades. Eles permitem que todos os membros da equipe vejam o progresso do projeto em tempo</p><p>real e contribuam com atualizações e feedback continuamente. Essas ferramentas também facilitam</p><p>a documentação e a rastreabilidade, garantindo que todos os requisitos e critérios de aceitação sejam</p><p>claros e facilmente acessíveis.</p><p>A comunicação assíncrona é outro aspecto importante dos ambientes de desenvolvimento ágil</p><p>virtuais. E-mails, fóruns de discussão e wikis corporativos permitem que os membros de uma equipe</p><p>compartilhem e colaborem com informações, mesmo quando não estão trabalhando simultaneamente.</p><p>Isso é particularmente útil para equipes distribuídas em diferentes fusos horários, permitindo que o</p><p>trabalho continue de maneira ininterrupta.</p><p>Além disso, ambientes híbridos de desenvolvimento ágil combinam elementos de espaços físicos e</p><p>virtuais, permitindo que equipes distribuídas geograficamente colaborem de modo eficaz e eficiente.</p><p>Esta abordagem tem se tornado cada vez mais comum, especialmente com o aumento do trabalho</p><p>remoto e a necessidade de flexibilizar as formas de trabalho para se adaptar às circunstâncias diversas.</p><p>Em um ambiente híbrido, a integração de ferramentas tecnológicas e práticas colaborativas é essencial</p><p>para manter a coesão da equipe e garantir a entrega contínua de valor.</p><p>39</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Uma das características fundamentais de um ambiente híbrido é a flexibilidade. Os membros da</p><p>equipe podem trabalhar tanto no escritório quanto remotamente, dependendo de suas necessidades</p><p>pessoais e das exigências do projeto. Esta flexibilidade permite que as empresas atraiam e retenham</p><p>talentos de diferentes locais, sem as limitações geográficas tradicionais. Portanto, para que um ambiente</p><p>híbrido funcione bem, a comunicação eficaz é essencial.</p><p>Lembrete</p><p>Ferramentas de comunicação em tempo real, como Slack, Microsoft</p><p>Teams e Zoom, são amplamente utilizadas para garantir que todos os</p><p>membros da equipe possam interagir facilmente, independentemente de sua</p><p>localização. Essas plataformas permitem chat em grupo, videochamadas,</p><p>compartilhamento de arquivos e integração com outras ferramentas</p><p>de  gestão de projetos, facilitando a colaboração e a coordenação das</p><p>atividades. Além das ferramentas de comunicação, a gestão de projetos</p><p>desempenha um papel crucial nos ambientes híbridos.</p><p>Aplicativos como Jira, Trello e Asana permitem que a equipe rastreie tarefas, gerencie o backlog</p><p>e visualize o progresso do projeto em tempo real. Essas ferramentas ajudam a manter a transparência e a</p><p>garantir que todos os membros da equipe estejam cientes das prioridades e dos prazos, independentemente</p><p>de onde estejam trabalhando, conforme exemplo da figura a seguir.</p><p>Figura 8 – Utilização de ferramentas para acompanhamento de tarefas. Imagem produzida</p><p>pelo próprio autor com tecnologia DALL-E, uma ferramenta de IA desenvolvida pela OpenAI</p><p>A tecnologia de videoconferência é outro componente essencial dos ambientes híbridos. As reuniões</p><p>diárias, planning, reviews e retrospectives podem ser realizadas através de videochamadas, permitindo</p><p>que todos os membros da equipe participem ativamente. O uso de câmeras e microfones de alta</p><p>qualidade melhora a experiência de comunicação, tornando as interações mais pessoais e envolventes.</p><p>40</p><p>Unidade I</p><p>Nos ambientes físicos, o design do escritório deve ser adaptado para suportar a colaboração híbrida.</p><p>Espaços abertos e flexíveis continuam a ser importantes, mas também é necessário incluir salas de</p><p>videoconferência bem equipadas, onde os membros da equipe possam se conectar facilmente com</p><p>colegas remotos. Áreas dedicadas para reuniões virtuais, com tecnologia adequada e uma conexão</p><p>estável à internet, são fundamentais para garantir a eficácia das interações híbridas.</p><p>A gestão do tempo e das atividades também é um desafio nos ambientes híbridos. É importante</p><p>estabelecer rotinas e práticas que ajudem a sincronizar o trabalho da equipe. Isso pode incluir a definição</p><p>de horários fixos para reuniões, períodos dedicados ao trabalho focado e pausas regulares para evitar</p><p>a fadiga. O uso de calendários compartilhados e a clareza nas expectativas ajudam a coordenar as</p><p>atividades e a manter o ritmo de trabalho consistente.</p><p>É importante destacarmos também que a segurança da informação é uma consideração essencial</p><p>nos ambientes híbridos. As empresas devem implementar medidas adequadas para proteger dados</p><p>sensíveis, garantindo que tanto os funcionários remotos quanto os presenciais sigam as melhores</p><p>práticas de segurança. Isso pode incluir o uso de VPNs, autenticação multifatorial e políticas de</p><p>acesso rigorosas.</p><p>Observação</p><p>A pandemia de covid-19, que começou no início de 2020, teve um impacto</p><p>profundo e duradouro nas formas de trabalho em todo o mundo. Em um</p><p>esforço para conter a propagação do vírus, muitas empresas foram obrigadas</p><p>a adotar rapidamente o trabalho remoto, mudando radicalmente a maneira</p><p>como operavam. Esta transição repentina e abrangente para o trabalho</p><p>remoto trouxe desafios e oportunidades, acelerando a transformação digital</p><p>e mudando as expectativas sobre o local de trabalho. Antes da pandemia, o</p><p>trabalho remoto era uma prática relativamente limitada e vista por muitos</p><p>empregadores com certo ceticismo. Entretanto, as circunstâncias forçaram</p><p>as organizações a adotarem tecnologias e práticas que permitissem a</p><p>continuidade dos negócios, enquanto os funcionários trabalhavam de casa.</p><p>Com o tempo, as empresas começaram a perceber os benefícios do trabalho remoto. A flexibilidade</p><p>proporcionada por esse modelo levou a um aumento na satisfação dos funcionários, muitos dos quais</p><p>apreciaram a economia de tempo e custos associados à ausência de deslocamentos diários. Além disso, a</p><p>possibilidade de trabalhar de qualquer lugar abriu novas oportunidades para atrair talentos de diferentes</p><p>regiões, eliminando a necessidade de mudanças.</p><p>No entanto, a transição abrupta também revelou desafios significativos. Problemas de comunicação,</p><p>isolamento social e a dificuldade de separar a vida profissional da pessoal foram algumas das principais</p><p>questões enfrentadas pelos trabalhadores remotos. As empresas precisaram investir em tecnologia e</p><p>adaptar suas culturas organizacionais para apoiar adequadamente os funcionários, proporcionando</p><p>suporte emocional e garantindo que todos tivessem acesso às ferramentas necessárias para realizar</p><p>suas tarefas com eficácia.</p><p>41</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>À medida que as restrições de saúde pública começaram a ser relaxadas, muitas empresas começaram a</p><p>explorar modelos híbridos de trabalho, combinando elementos do trabalho remoto com a presença no</p><p>escritório. Este movimento para um ambiente de trabalho híbrido foi motivado pelo desejo de manter</p><p>a flexibilidade conquistada durante a pandemia, ao mesmo tempo que se aproveitam os benefícios da</p><p>interação presencial, como a colaboração espontânea e o fortalecimento dos laços de equipe.</p><p>O modelo híbrido oferece uma solução equilibrada, permitindo que os funcionários escolham</p><p>quando e onde trabalhar com base nas necessidades das suas tarefas e preferências pessoais. Em</p><p>um ambiente híbrido, os funcionários podem optar por trabalhar remotamente em atividades que</p><p>requerem concentração e foco individual, enquanto aproveitam os dias no escritório para reuniões</p><p>presenciais, sessões de brainstorming e outras atividades colaborativas. Considerando tal contexto, é</p><p>importante termos claro que implementar um modelo híbrido de forma eficaz exige planejamento</p><p>e adaptação por parte das empresas.</p><p>As organizações precisam estabelecer políticas claras que definam expectativas e diretrizes para o</p><p>trabalho híbrido, garantindo que todos os funcionários tenham acesso igualitário às oportunidades de</p><p>desenvolvimento e participação. Além disso, é importante criar um ambiente de trabalho que suporte</p><p>a colaboração tanto virtual quanto presencial, com investimentos em tecnologia adequada e a criação</p><p>de espaços físicos flexíveis e bem equipados.</p><p>A cultura organizacional também é um fator determinante na eficácia dos ambientes ágeis, tanto</p><p>físicos quanto virtuais. Uma cultura que valoriza a transparência, a confiança e o aprendizado contínuo</p><p>cria um ambiente no qual os membros da equipe se sentem seguros para compartilhar ideias, assumir</p><p>riscos calculados e aprender com os erros.</p><p>Líderes e gestores desempenham um papel crucial na promoção dessa cultura, oferecendo suporte,</p><p>incentivando a experimentação e celebrando as conquistas da equipe. A adoção de práticas ágeis em</p><p>ambientes de desenvolvimento requer um compromisso com a melhoria contínua e a disposição para</p><p>ajustar processos e ferramentas conforme necessário. Feedback regular, retrospectives e métricas de</p><p>desempenho ajudam a identificar áreas de melhoria e a implementar mudanças que aumentam a</p><p>eficiência e a qualidade do trabalho.</p><p>Cultura é um conceito amplo que abrange os valores, crenças, comportamentos, normas, costumes</p><p>e artefatos que caracterizam um grupo ou uma sociedade. A cultura influencia a maneira como os</p><p>indivíduos interagem entre si e com o mundo ao seu redor, moldando suas percepções, atitudes e ações.</p><p>Ela se manifesta em diversos aspectos da vida, incluindo linguagem, religião, arte, vestimenta, práticas</p><p>sociais, instituições e estruturas de poder.</p><p>No contexto organizacional, a cultura refere-se ao conjunto de valores, crenças e comportamentos</p><p>que definem o ambiente de trabalho e guiam as interações entre os membros da empresa. A cultura</p><p>organizacional é formada e perpetuada tanto por fatores explícitos, como políticas e regras, quanto</p><p>por fatores implícitos, como normas sociais e hábitos de trabalho. Ela desempenha um papel crucial na</p><p>determinação de como os colaboradores</p><p>percebem seu trabalho, como se comunicam e colaboram, e</p><p>como enfrentam desafios e oportunidades.</p><p>42</p><p>Unidade I</p><p>A cultura é transmitida e reforçada através de processos de socialização, nos quais novos membros do</p><p>grupo aprendem e internalizam os valores e comportamentos esperados. Isso pode ocorrer formalmente,</p><p>através de treinamento e orientação, ou informalmente, através de observação e interação com</p><p>colegas. Líderes e figuras de autoridade dentro do grupo ou organização têm um papel significativo na</p><p>modelagem e promoção da cultura, pois suas ações e decisões servem como exemplos para os demais.</p><p>A cultura também é dinâmica e pode evoluir ao longo do tempo. Mudanças na liderança, na composição</p><p>do grupo, nas condições externas e nas expectativas dos membros podem influenciar a cultura. Essa</p><p>adaptabilidade permite que a cultura responda a novos desafios e oportunidades, mantendo a relevância</p><p>e a coesão do grupo.</p><p>Um dos aspectos fundamentais da cultura é a criação de um senso de identidade e pertencimento.</p><p>Ela ajuda os membros do grupo a se identificarem com algo maior do que eles mesmos, gerando um</p><p>sentido de propósito e coesão. Esse senso de pertencimento é crucial para a motivação, o engajamento</p><p>e a lealdade dos indivíduos ao grupo ou organização.</p><p>A cultura também pode ser uma fonte de diferenciação competitiva. Em um ambiente de negócios,</p><p>uma cultura organizacional forte e positiva pode atrair e reter talentos, fomentar a inovação e a</p><p>colaboração, e melhorar a satisfação e o desempenho dos funcionários. Empresas com culturas bem</p><p>definidas e alinhadas com seus objetivos estratégicos tendem a ser mais resilientes e adaptáveis às</p><p>mudanças do mercado.</p><p>Assim, os ambientes de desenvolvimento ágil, sejam eles físicos ou virtuais, são projetados para</p><p>maximizar a colaboração, a comunicação e a adaptabilidade. Espaços físicos abertos e flexíveis,</p><p>combinados com áreas dedicadas para diferentes atividades, promovem a interação contínua e  a</p><p>rápida resolução de problemas. Ferramentas virtuais avançadas facilitam a comunicação e a gestão de</p><p>projetos em equipes distribuídas, enquanto uma cultura organizacional que valoriza a transparência</p><p>e o aprendizado contínuo sustenta as práticas ágeis. Portanto, a criação de um ambiente que suporte</p><p>efetivamente o desenvolvimento ágil é essencial para o sucesso de qualquer equipe que adote essa</p><p>metodologia.</p><p>2.3 Cultura ágil: valores e comportamentos para o sucesso do time</p><p>Na cultura ágil, a valorização das pessoas e das interações humanas são primordiais. A comunicação</p><p>aberta e honesta é incentivada, criando um ambiente no qual a colaboração entre os membros da equipe</p><p>é a chave para resolver problemas e criar soluções inovadoras. Essa ênfase nas interações humanas</p><p>reconhece que são as pessoas que fazem a diferença, não apenas os processos ou ferramentas utilizadas.</p><p>Portanto, promover um ambiente onde os membros da equipe se sintam seguros para compartilhar</p><p>ideias, discutir problemas e sugerir melhorias é fundamental.</p><p>A entrega de um software funcional é uma prioridade. Em vez de se concentrar excessivamente em</p><p>documentação abrangente, a cultura ágil valoriza a CD de incrementos de valor tangíveis e utilizáveis</p><p>para os clientes. Isso significa que o desenvolvimento é iterativo, com ciclos curtos de trabalho que</p><p>permitem a rápida adaptação às mudanças e ao feedback dos usuários. A cada iteração, a equipe busca</p><p>fornecer um produto que esteja em evolução constante, sempre atendendo às necessidades reais</p><p>dos usuários.</p><p>43</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>A interação contínua com o cliente é outro aspecto vital da cultura ágil. Em vez de se basear em</p><p>contratos rígidos e negociações formais, a cultura ágil promove uma colaboração estreita e contínua</p><p>com os clientes. O feedback dos usuários é integrado diretamente no processo de desenvolvimento,</p><p>permitindo ajustes rápidos e garantindo que o produto final atenda às expectativas e necessidades dos</p><p>clientes. Essa colaboração melhora a qualidade do produto e também fortalece a relação entre a equipe</p><p>de desenvolvimento e os stakeholders.</p><p>A adaptabilidade é um valor central na cultura ágil. As equipes são encorajadas a ser flexíveis e a</p><p>responder rapidamente às mudanças. Isso implica uma disposição para experimentar, aprender com os</p><p>erros e ajustar as abordagens conforme necessário. A melhoria contínua é uma prática constante, com a</p><p>equipe realizando retrospectivas regulares para identificar áreas de melhoria e implementar mudanças</p><p>que aumentem a eficiência e a qualidade do trabalho.</p><p>A transparência e a confiança são pilares da cultura ágil. A transparência envolve manter todos</p><p>os membros da equipe informados sobre o estado do projeto, os desafios enfrentados e as decisões</p><p>tomadas. Isso cria um ambiente de confiança, onde os membros da equipe sentem-se valorizados e</p><p>engajados. A confiança também se estende à autonomia das equipes, permitindo que elas tomem</p><p>decisões informadas e rápidas, sem depender de aprovações hierárquicas demoradas.</p><p>O respeito e a empatia são igualmente importantes na cultura ágil. Cada membro da equipe é</p><p>tratado com respeito, reconhecendo suas contribuições e habilidades. A empatia permite entender as</p><p>perspectivas dos outros, promovendo uma colaboração mais harmoniosa e eficaz. Esses valores criam</p><p>um ambiente onde os conflitos podem ser resolvidos de maneira construtiva e onde todos se sentem</p><p>parte de um objetivo comum.</p><p>O quadro a seguir apresenta uma síntese dos comportamentos e valores a serem desenvolvidos e</p><p>observados em ambientes de desenvolvimento de software usando frameworks ágeis.</p><p>Quadro 2 – Resumo dos comportamentos e valores importantes no sucesso do time ágil</p><p>Item cultural Tipo Impacto para o sucesso do time Como aplicar e promover</p><p>Comunicação</p><p>aberta e honesta Valor Promove a confiança e a</p><p>resolução rápida de problemas</p><p>Realizar reuniões regulares e incentivar a</p><p>comunicação aberta entre todos os membros</p><p>da equipe</p><p>Colaboração</p><p>entre membros</p><p>da equipe</p><p>Comportamento Facilita a criação de soluções</p><p>inovadoras e eficazes</p><p>Promover atividades colaborativas e projetos</p><p>em grupo, incentivando a troca de ideias</p><p>e habilidades</p><p>Entrega contínua</p><p>de valor Valor Garante que o produto atenda às</p><p>necessidades reais dos usuários</p><p>Adotar ciclos de desenvolvimento curtos e</p><p>iterativos, focando na entrega de incrementos</p><p>de valor constantes</p><p>Adaptabilidade</p><p>e flexibilidade Comportamento Permite ajustes rápidos e</p><p>eficientes às mudanças</p><p>Incentivar a flexibilidade nos processos e a</p><p>capacidade de adaptação rápida a mudanças</p><p>Transparência Valor Mantém todos os membros da</p><p>equipe informados e alinhados</p><p>Manter uma comunicação clara e acessível</p><p>sobre o estado dos projetos e decisões tomadas</p><p>Feedback</p><p>constante</p><p>dos clientes</p><p>Comportamento</p><p>Assegura que o produto final</p><p>esteja em consonância com as</p><p>expectativas dos clientes</p><p>Envolver os clientes em reuniões regulares</p><p>para coletar feedback e ajustá-lo</p><p>ao desenvolvimento</p><p>44</p><p>Unidade I</p><p>Item cultural Tipo Impacto para o sucesso do time Como aplicar e promover</p><p>Autonomia</p><p>da equipe Valor Aumenta a motivação e o</p><p>compromisso com o trabalho</p><p>Delegar responsabilidades e permitir que</p><p>a equipe tome decisões informadas de</p><p>forma autônoma</p><p>Melhoria contínua Comportamento Melhora processos e práticas,</p><p>aumentando a eficiência</p><p>Realizar retrospectivas periódicas</p><p>para identificar áreas de melhoria e</p><p>implementar mudanças</p><p>Respeito e empatia Valor Cria um ambiente harmonioso</p><p>e produtivo</p><p>Promover um ambiente de respeito mútuo e</p><p>reconhecimento das contribuições individuais</p><p>Mentalidade</p><p>de crescimento Comportamento Encoraja a aprendizagem</p><p>contínua e a adaptação</p><p>Incentivar a busca contínua por novos</p><p>conhecimentos e habilidades através de</p><p>treinamentos e workshops</p><p>Ambiente</p><p>seguro para</p><p>experimentação</p><p>Comportamento Fomenta a inovação e a</p><p>descoberta de novas abordagens</p><p>Criar um ambiente seguro, no qual os membros</p><p>possam experimentar novas ideias sem medo</p><p>de falhar</p><p>Valorização</p><p>da diversidade</p><p>Valor</p><p>Enriquece o processo de</p><p>tomada de decisão com</p><p>diferentes perspectivas</p><p>Fomentar a inclusão e a valorização de</p><p>diferentes perspectivas e experiências dentro</p><p>da equipe</p><p>Lembrete</p><p>A cultura ágil é essencial para o sucesso de equipes que adotam</p><p>metodologias ágeis, que promovem a colaboração, a adaptabilidade</p><p>e a  entrega contínua de valor. A criação e manutenção de uma cultura</p><p>ágil eficaz garantem que os princípios e práticas ágeis sejam mais do que</p><p>apenas processos, mas sim uma forma intrínseca de operar que permeia</p><p>toda a organização.</p><p>O sucesso de um time ágil pode ser definido por uma combinação de fatores qualitativos e</p><p>quantitativos que refletem a eficácia, a eficiência e a satisfação da equipe e dos stakeholders.</p><p>A entrega contínua de valor é um dos principais indicadores de sucesso. A capacidade da equipe</p><p>de lançar incrementos de produto regularmente e que atendam às necessidades e expectativas dos</p><p>usuários demonstra que o time está focado em fornecer soluções relevantes e úteis.</p><p>A satisfação do cliente é outro critério crucial, uma vez que times ágeis buscam feedback constante</p><p>e trabalham para incorporá-lo nas próximas iterações. Alta satisfação do cliente indica que a equipe está</p><p>atendendo ou superando as expectativas em termos de funcionalidade, qualidade e usabilidade do produto.</p><p>A qualidade do produto entregue também desempenha um papel significativo na definição de</p><p>sucesso. Não se trata apenas de minimizar bugs e defeitos, mas também de garantir robustez, usabilidade</p><p>e capacidade de atender às necessidades do usuário final. Práticas como testes contínuos, CI e automação</p><p>de testes são métodos utilizados para manter a qualidade em altos padrões.</p><p>A velocidade e eficiência da equipe, medidas pela capacidade de concluir sprints e atingir metas</p><p>dentro do prazo estabelecido, são igualmente importantes. Métricas como a velocidade do sprint ajudam</p><p>45</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>a avaliar a eficiência e a consistência da equipe na entrega de valor. Times ágeis devem ser flexíveis e</p><p>prontos para ajustar suas prioridades e estratégias com base em novos insights e feedback, garantindo</p><p>que possam responder rapidamente às novas demandas.</p><p>O nível de engajamento e satisfação dos membros da equipe é outro indicativo importante do</p><p>sucesso. Uma equipe motivada, que se sente valorizada e desafiada, tende a ser mais produtiva e</p><p>criativa. Manter um bom equilíbrio entre vida pessoal e profissional, proporcionar oportunidades de</p><p>desenvolvimento e reconhecer as conquistas da equipe são maneiras de sustentar altos níveis de moral.</p><p>Embora a flexibilidade seja uma característica dos times ágeis, cumprir prazos e orçamentos é essencial</p><p>para manter a confiança dos stakeholders e garantir a viabilidade do projeto.</p><p>A capacidade de planejar e estimar com precisão, além de gerenciar recursos de maneira eficaz,</p><p>é crucial para o sucesso. Finalmente, o sucesso de um time ágil é medido pela sua capacidade de</p><p>alinhar suas atividades com os objetivos estratégicos da organização. A entrega de valor deve estar em</p><p>consonância com as metas de negócio, garantindo que o trabalho da equipe contribua diretamente para</p><p>o sucesso geral da empresa.</p><p>Em linhas gerais, a cultura ágil se fundamenta em valores e comportamentos que promovem  a</p><p>colaboração, a entrega contínua de valor, a adaptabilidade, a transparência, a confiança, o respeito e</p><p>a empatia. Esses elementos são essenciais para criar um ambiente onde as equipes possam prosperar</p><p>e  entregar produtos de alta qualidade que atendam às necessidades dos clientes. A cultura ágil é,</p><p>portanto, um fator crítico para o sucesso de qualquer organização que adote metodologias ágeis.</p><p>2.4 Planejamento iterativo e incremental, técnicas de estimativa ágil</p><p>(Planning Poker etc.)</p><p>O planejamento iterativo e incremental é uma abordagem central nas metodologias ágeis,</p><p>especialmente em frameworks como Scrum e Kanban. Esta abordagem difere significativamente</p><p>dos métodos tradicionais de desenvolvimento de software, que frequentemente dependem de um</p><p>planejamento extensivo e detalhado no início do projeto. Em vez disso, tal abordagem foca em ciclos</p><p>curtos de planejamento e desenvolvimento, permitindo a adaptação constante e a melhoria contínua</p><p>com base em feedback regular.</p><p>No planejamento iterativo, o desenvolvimento do produto ocorre em ciclos repetidos, conhecidos</p><p>como iterações ou sprints. Cada iteração geralmente dura de uma a quatro semanas e culmina na</p><p>entrega de um incremento de produto potencialmente utilizável. Esse incremento é uma versão funcional</p><p>do produto que inclui novas funcionalidades ou melhorias significativas. O objetivo de cada iteração</p><p>é produzir um incremento que possa ser testado, revisado e, se possível, lançado aos usuários finais.</p><p>Uma das principais vantagens do planejamento iterativo é a capacidade de responder rapidamente</p><p>às mudanças. Em vez de tentar prever todas as necessidades e problemas no início do projeto, a equipe</p><p>ágil pode ajustar seu planejamento com base no feedback obtido durante as iterações anteriores. Isso</p><p>torna o processo de desenvolvimento muito mais flexível e adaptável, permitindo que a equipe reaja a</p><p>novas informações, mudanças no mercado ou feedback dos clientes de maneira ágil e eficiente.</p><p>46</p><p>Unidade I</p><p>O planejamento incremental, por outro lado, complementa o processo iterativo ao dividir o trabalho</p><p>em pequenos incrementos de funcionalidade que são entregues ao longo do tempo. Cada incremento</p><p>adiciona valor ao produto, construídos gradualmente sobre os incrementos anteriores. Isso permite</p><p>que os stakeholders vejam progresso contínuo e tangível, mantendo o engajamento e a satisfação</p><p>ao longo do ciclo de desenvolvimento. Além disso, a entrega incremental reduz o risco associado ao</p><p>desenvolvimento de grandes sistemas, pois cada incremento é uma oportunidade de validar as hipóteses</p><p>e corrigir o curso se necessário.</p><p>Juntas, as abordagens iterativa e incremental criam um ciclo de desenvolvimento altamente eficaz.</p><p>No início de cada iteração, a equipe realiza uma sessão de planejamento em que define os objetivos e</p><p>as tarefas para o próximo ciclo. Esse planejamento é baseado na priorização do backlog do produto</p><p>e garante que as tarefas mais importantes e de maior valor sejam abordadas primeiro. Assim, ao final</p><p>de cada iteração, a equipe realiza uma revisão para demonstrar o trabalho concluído e coletar feedback.</p><p>Essa revisão é seguida por uma retrospectiva, em que a equipe avalia o que funcionou bem e o que pode</p><p>ser melhorado, ajustando suas práticas para a próxima iteração.</p><p>Os planejamentos iterativo e incremental também promovem uma cultura de melhoria contínua.</p><p>Ao refletir regularmente sobre o processo e os resultados, a equipe identifica oportunidades para otimizar</p><p>suas práticas e aumentar a eficiência. Isso pode incluir melhorias técnicas, como a automação de testes</p><p>ou a CI, bem como melhorias de processo, como a comunicação e a colaboração dentro da equipe.</p><p>Além disso, essa abordagem facilita a gestão de riscos. Ao dividir o trabalho em pequenos incrementos</p><p>e realizar testes frequentes, a equipe pode identificar e resolver problemas rapidamente, antes que se</p><p>tornem grandes obstáculos. Isso reduz a incerteza e aumenta a previsibilidade do projeto, proporcionando</p><p>maior confiança tanto para a equipe quanto para os stakeholders.</p><p>Os planejamentos iterativo e incremental são, portanto, estratégias fundamentais nas metodologias</p><p>ágeis, permitindo a entrega contínua de valor, a adaptação rápida às mudanças e a melhoria contínua.</p><p>Tais abordagens promovem a flexibilidade, a colaboração e a transparência, garantindo que o produto</p><p>final atenda às necessidades dos usuários e aos objetivos do negócio de maneira eficiente e eficaz. Ao</p><p>adotar essa abordagem, as equipes podem responder mais agilmente às dinâmicas do mercado, melhorar</p><p>a qualidade do produto e manter um alto nível de satisfação entre os clientes e os stakeholders.</p><p>Também podemos destacar as técnicas</p><p>de estimativa ágil, que são essenciais para ajudar as equipes</p><p>a prever o esforço necessário para completar tarefas e funcionalidades durante o desenvolvimento</p><p>de um produto. Essas técnicas permitem uma avaliação mais precisa e colaborativa do trabalho a ser</p><p>realizado, facilitando o planejamento e a priorização do backlog. Entre as técnicas mais populares estão</p><p>o Planning Poker, a técnica de T-shirt Sizes, a de Pontos de História (Story Points) e a técnica de Delphi.</p><p>O Planning Poker, por exemplo, é uma das técnicas de estimativa mais amplamente utilizadas</p><p>em ambientes ágeis. Ele envolve toda a equipe de desenvolvimento e é baseado em um jogo de</p><p>cartas que representa diferentes valores de estimativa, geralmente em uma sequência de Fibonacci</p><p>modificada  (1,  2,  3, 5, 8, 13, 21 etc.). Cada membro da equipe recebe um conjunto de cartas e, ao</p><p>discutir uma história de usuário ou tarefa, todos os membros escolhem uma carta que representa sua</p><p>47</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>estimativa de esforço. As cartas são reveladas simultaneamente, e se houver grande discrepância nas</p><p>estimativas, os membros discutem suas razões até chegar a um consenso. O Planning Poker promove</p><p>a participação ativa de todos os membros da equipe e aproveita o conhecimento coletivo para obter</p><p>estimativas mais precisas.</p><p>Já a técnica de T-shirt Sizes é uma abordagem mais simples e rápida, usada frequentemente para</p><p>estimativas iniciais de alto nível. As tarefas ou histórias de usuário são classificadas em categorias de</p><p>tamanhos de camisetas (XS, S, M, L, XL) com base na percepção do esforço necessário. Essa técnica é</p><p>útil para obter uma visão geral e rápida da complexidade relativa das tarefas. É particularmente útil em</p><p>estágios iniciais do projeto, nos quais muitas incertezas ainda existem.</p><p>Os Pontos de História, por sua vez, são técnicas de estimativa que se concentram na medição do esforço</p><p>relativo necessário para completar uma história de usuário. Em vez de estimar o tempo exato, a equipe</p><p>avalia o esforço comparando-o com outras histórias já conhecidas. A escala utilizada pode variar, mas</p><p>frequentemente com a sequência de Fibonacci modificada. Essa técnica permite uma avaliação mais flexível</p><p>e adaptável, considerando fatores como complexidade, quantidade de trabalho e incertezas. Ao longo do</p><p>tempo, as equipes desenvolvem um senso de consistência em suas estimativas, tornando-as mais confiáveis.</p><p>Saiba mais</p><p>Histórias de usuário são técnicas utilizadas em metodologias ágeis para</p><p>capturar requisitos do ponto de vista do usuário final. Elas descrevem de</p><p>maneira simples e clara o que o usuário deseja alcançar com uma determinada</p><p>funcionalidade ou recurso do produto.</p><p>Elas são escritas em linguagem não técnica, facilitando a comunicação</p><p>entre desenvolvedores, stakeholders e usuários. A estrutura típica de uma</p><p>história de usuário inclui um breve enunciado que segue o formato: “Como</p><p>[tipo de usuário], eu quero [ação] para que [benefício/valor]”. Elas também</p><p>possuem critérios de aceitação.</p><p>Essa forma de descrição ajuda a garantir que todos os envolvidos no</p><p>projeto compreendam os objetivos e as necessidades dos usuários. Além</p><p>disso, histórias de usuário são curtas e concisas, promovendo a discussão e a</p><p>colaboração dentro da equipe para esclarecer e detalhar os requisitos. Assim,</p><p>para mais detalhes sobre esse assunto, sugerimos a leitura do seguinte livro.</p><p>PATTON, J. et al. User story mapping: discover the whole story, build the</p><p>right product. Massachusetts: O’Reilly Media, 2014.</p><p>A técnica Delphi é um método mais formal e estruturado, geralmente utilizado quando se busca um</p><p>consenso entre especialistas. Envolve várias rodadas de estimativas anônimas, as quais os especialistas</p><p>48</p><p>Unidade I</p><p>fornecem suas estimativas independentemente. Após cada rodada, as estimativas são compartilhadas</p><p>com o grupo, permitindo que os membros ajustem suas previsões com base no feedback coletivo.</p><p>O processo continua até que um consenso seja alcançado. A técnica Delphi é útil para estimativas</p><p>complexas e para reduzir a influência de vieses individuais.</p><p>Considerando as informações apresentadas, a seguir analisaremos o passo a passo de como aplicar</p><p>cada uma dessas técnicas, bem como apresentar exemplos ilustrativos. Comecemos pelo Planning Poker,</p><p>que, com vimos, é uma técnica de estimativa colaborativa usada por equipes ágeis para avaliar o esforço</p><p>necessário para completar histórias de usuário ou tarefas em um projeto. A seguir podemos observar</p><p>o passo a passo necessário. A técnica combina a sabedoria coletiva da equipe com um processo de</p><p>consenso para obter estimativas mais precisas e compartilhadas.</p><p>•	 Preparação: antes de começar a sessão de Planning Poker, o Product Owner prepara uma lista</p><p>de histórias de usuário que precisam ser estimadas. Cada história deve estar bem definida, com</p><p>critérios de aceitação claros e discutidos previamente com a equipe.</p><p>•	 Distribuição das cartas: cada membro da equipe recebe um conjunto de cartas de Planning Poker.</p><p>Cada carta tem um número que representa uma estimativa de esforço. Os números geralmente</p><p>seguem a sequência de Fibonacci modificada (1, 2, 3, 5, 8, 13, 21 etc.), pois essa progressão reflete</p><p>melhor o aumento relativo do esforço para tarefas mais complexas.</p><p>•	 Apresentação da história: o Product Owner destaca a primeira história de usuário à equipe.</p><p>Ele descreve os detalhes da história, explica os critérios de aceitação e responde a quaisquer</p><p>perguntas que a equipe possa ter para clarificar os requisitos.</p><p>•	 Discussão e análise: os membros da equipe discutem a história de usuário, compartilhando suas</p><p>percepções sobre a complexidade, as dependências e os possíveis desafios. Esta discussão inicial</p><p>ajuda a alinhar a compreensão de todos sobre o trabalho envolvido.</p><p>•	 Escolha das cartas: após a discussão, cada membro da equipe escolhe uma carta de seu conjunto</p><p>que representa sua estimativa de esforço para completar a história de usuário. Todos mantêm</p><p>suas cartas viradas para baixo para garantir que as estimativas sejam independentes.</p><p>•	 Revelação das cartas: todos os membros da equipe revelam suas cartas simultaneamente. As</p><p>diferenças nas estimativas são discutidas, com foco em entender por que alguém estimou um valor</p><p>muito diferente dos outros. Por exemplo, se as cartas reveladas forem 3, 5 e 13, a equipe precisa</p><p>discutir por que alguém considerou a história muito mais complexa (13) ou mais simples (3) do</p><p>que os outros.</p><p>•	 Nova rodada de estimativas: após a discussão, a equipe pode optar por fazer outra rodada de</p><p>estimativas. Cada membro escolhe novamente uma carta com base na nova compreensão obtida</p><p>durante a discussão. Esse processo de estimar, discutir e reestimar continua até que a equipe</p><p>alcance um consenso ou uma convergência de estimativas.</p><p>•	 Registro da estimativa: uma vez que a equipe concorda em uma estimativa, essa estimativa</p><p>é registrada no backlog do produto ao lado da história de usuário. A equipe então passa para a</p><p>próxima história de usuário e repete o processo.</p><p>49</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Note que o Planning Poker usa a sequência de Fibonacci modificada (geralmente 1, 2, 3, 5, 8, 13, 21 etc.)</p><p>em vez de uma sequência linear (1, 2, 3, 4, 5, 6 etc.). A principal razão é que a sequência de Fibonacci</p><p>reflete melhor a incerteza e a complexidade crescentes associadas a tarefas maiores. Em projetos de</p><p>desenvolvimento de software, a diferença entre uma tarefa que leva um dia e uma que leva dois dias</p><p>é relativamente pequena e fácil de estimar. No entanto, conforme as tarefas se tornam maiores e mais</p><p>complexas, a incerteza sobre o tempo necessário para completá-las também aumenta. A sequência de</p><p>Fibonacci captura essa incerteza de maneira mais natural, pois os números aumentam de modo não</p><p>linear, refletindo a dificuldade de fazer estimativas precisas para tarefas maiores.</p><p>Usar uma sequência linear, como 1, 2, 3, 4, 5, 6 etc., pode dar uma falsa sensação de precisão. Em</p><p>contextos nos quais a complexidade</p><p>aumenta de maneira imprevisível, uma escala linear pode levar a</p><p>subestimações ou superestimações significativas. Assim, a sequência de Fibonacci ajuda a evitar esse</p><p>problema ao fornecer uma escala que aumenta rapidamente, incentivando os estimadores a considerar</p><p>cuidadosamente a incerteza e a complexidade.</p><p>Outra vantagem da sequência de Fibonacci é que ela promove discussões mais significativas durante</p><p>as sessões de estimativa. Quando tais diferenças são maiores, isso geralmente indica que há uma falta</p><p>de entendimento comum sobre a tarefa ou que existem aspectos da tarefa que alguns membros da</p><p>equipe perceberam, mas outros não. Essa discrepância leva a discussões que ajudam a esclarecer e</p><p>alinhar o entendimento da equipe sobre o trabalho a ser feito, resultando em estimativas mais precisas</p><p>e em uma melhor preparação para enfrentar os desafios da tarefa. Por exemplo, se uma equipe está</p><p>usando Planning Poker para estimar uma história de usuário e os membros escolhem 3, 5 e 13 pontos,</p><p>a grande diferença entre essas estimativas indicará a necessidade de uma discussão aprofundada. Isso</p><p>ajuda a identificar quaisquer suposições erradas ou áreas de incerteza que precisam ser abordadas antes</p><p>de iniciar o trabalho.</p><p>O uso de Fibonacci também ajuda a evitar o bikeshedding, isto é, gastar tempo excessivo discutindo</p><p>detalhes triviais. Como os valores da sequência são mais espaçados à medida que aumentam, é mais</p><p>fácil para a equipe se concentrar nas diferenças significativas e evitar debates longos sobre diferenças</p><p>mínimas. Isso mantém o processo de estimativa eficiente e focado nas questões que realmente importam.</p><p>Convém observarmos também que a sequência de Fibonacci é uma série de números na qual cada</p><p>número é a soma dos dois anteriores: 0, 1, 1, 2, 3, 5, 8, 13, 21 e assim por diante. Essa sequência reflete</p><p>um crescimento natural, no qual a proporção entre números consecutivos se aproxima da razão</p><p>áurea (aproximadamente 1,618).</p><p>Desse modo, no contexto de estimativas ágeis, a sequência de Fibonacci utilizada é modificada,</p><p>pois omite alguns números da sequência original e pode começar com 1 em vez de 0. A versão mais</p><p>comum para estimativas de Planning Poker é: 1, 2, 3, 5, 8, 13, 21, 40, 100. Essa modificação é feita</p><p>por várias razões práticas que ajudam a facilitar o processo de estimativa. Uma delas é simplificar o</p><p>conjunto de opções disponíveis para a equipe durante a estimativa. A modificação reduz o número</p><p>de escolhas possíveis, o que ajuda a evitar que os membros da equipe fiquem presos em detalhes</p><p>minuciosos e aumente a eficiência do processo de estimativa. Ao ter menos opções, a equipe pode focar</p><p>mais rapidamente nas diferenças significativas entre as estimativas.</p><p>50</p><p>Unidade I</p><p>Além disso, a sequência de Fibonacci modificada inclui números que refletem o aumento exponencial</p><p>da incerteza e complexidade à medida que as tarefas se tornam maiores. Por exemplo, a inclusão de</p><p>21, 40 e 100 permite estimar tarefas que são significativamente maiores e mais complexas do que</p><p>aquelas cobertas pelos números menores, mas sem precisar de números consecutivos, que possam dar</p><p>uma falsa sensação de precisão.</p><p>A escolha de não usar a sequência de Fibonacci original (com todos os seus números) é principalmente</p><p>para evitar a inclusão de números que são muito próximos entre si, como 1 e 1, ou 2 e 3. Esses números</p><p>próximos podem levar a discussões longas e improdutivas sobre pequenas diferenças que não impactam</p><p>significativamente o planejamento. A sequência modificada ajuda a equipe a se concentrar nas diferenças</p><p>mais substanciais, tornando o processo de estimativa mais prático e útil.</p><p>Outra modificação comum é a inclusão de cartas especiais como ? para indicar incerteza ou café</p><p>para sugerir uma pausa, ajudando a abordar a necessidade de mais informações ou um intervalo no</p><p>caso de discussões prolongadas.</p><p>Para o exemplo ilustrativo do Planning Poker, a seguir, vamos considerar uma equipe que está</p><p>desenvolvendo um aplicativo de gerenciamento de tarefas. O Product Owner apresenta a seguinte</p><p>história de usuário: “como usuário, eu quero poder adicionar uma nova tarefa com uma data de</p><p>vencimento para que eu possa acompanhar meus prazos”.</p><p>•	 Apresentação da história: o Product Owner explica os detalhes da história e responde a</p><p>perguntas sobre como a interface deve funcionar e quais validações são necessárias para a data</p><p>de vencimento.</p><p>•	 Discussão e análise: a equipe discute os requisitos, a complexidade de implementar a interface</p><p>de usuário, a lógica de back-end necessária e os testes associados.</p><p>•	 Escolha das cartas: após a discussão inicial, cada membro da equipe escolhe uma carta de</p><p>Planning Poker. As cartas são reveladas e os números são 3, 5 e 8.</p><p>•	 Revelação das cartas: a equipe discute as diferenças. Um desenvolvedor que escolheu 8 pode</p><p>explicar que considera a validação de datas complexa e sujeita a erros, enquanto outro que</p><p>escolheu 3 pode achar que a tarefa é simples e já fez algo semelhante antes.</p><p>•	 Registro da estimativa: a equipe reestima, após a discussão, e desta vez escolhe 5 como um</p><p>consenso, refletindo um acordo sobre a complexidade moderada da tarefa.</p><p>Assim, após o registro da estimativa, o Planning Poker continua para todas as histórias de usuário</p><p>na lista, proporcionando uma maneira estruturada e colaborativa de estimar o esforço necessário para</p><p>completar o trabalho. Esta técnica resulta em estimativas mais precisas e promove a compreensão</p><p>comum e a comunicação aberta dentro da equipe.</p><p>51</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Como introduzimos anteriormente, também temos a técnica de T-shirt Sizes, que é uma abordagem</p><p>simples e eficaz para estimar o esforço necessário para completar tarefas ou histórias de usuário em</p><p>projetos ágeis. Ela utiliza tamanhos de camisetas (XS, S, M, L, XL) para categorizar o esforço relativo</p><p>das tarefas, facilitando a compreensão e a comunicação dentro da equipe. Considerando tais aspectos,</p><p>analisemos um exemplo ilustrativo com um passo a passo detalhado de como o T-shirt Sizes é realizado.</p><p>•	 Preparação: antes de iniciar a sessão de estimativa, o Product Owner prepara uma lista de histórias</p><p>de usuário ou tarefas que precisam ser estimadas. Cada item deve ter uma descrição clara e</p><p>critérios de aceitação bem definidos para que a equipe possa compreender o trabalho envolvido.</p><p>•	 Explicação da técnica: a facilitador (geralmente o Scrum Master ou o Product Owner) explica</p><p>a técnica de T-shirt Sizes à equipe, se necessário. Ele esclarece que os tamanhos de camiseta são</p><p>usados como metáforas para o esforço relativo necessário para completar cada item. Os tamanhos</p><p>típicos são Extra Pequeno (XS), Pequeno (S), Médio (M), Grande (L) e Extra Grande (XL).</p><p>•	 Apresentação da história: o Product Owner destaca a primeira história de usuário ou tarefa à</p><p>equipe. Ele fornece detalhes suficientes para que todos compreendam o que precisa ser feito e os</p><p>critérios de aceitação associados.</p><p>•	 Discussão e análise: a equipe discute a história de usuário, considerando fatores como</p><p>complexidade, dependências, riscos e o tempo necessário para a conclusão. Essa discussão inicial</p><p>ajuda a alinhar a compreensão da equipe sobre o trabalho envolvido.</p><p>•	 Estimativa de tamanho de camiseta: com base na discussão, cada membro da equipe propõe</p><p>um tamanho de camiseta para a história de usuário. Eles podem indicar verbalmente ou utilizar</p><p>ferramentas colaborativas para registrar suas estimativas. A equipe discute as diferenças de</p><p>opinião até chegar a um consenso sobre o tamanho de camiseta apropriado.</p><p>•	 Registro da estimativa: uma vez que a equipe concorda em um tamanho de camiseta, essa</p><p>estimativa é registrada no backlog do produto ao lado da história de usuário. A equipe então</p><p>passa para a próxima história de usuário e repete o processo.</p><p>Para o exemplo ilustrativo a seguir, vamos considerar uma equipe que está desenvolvendo um</p><p>aplicativo de e-commerce. O Product Owner apresenta a seguinte história de usuário: “como usuário,</p><p>eu</p><p>quero poder adicionar produtos ao carrinho de compras para que eu possa comprá-los posteriormente”.</p><p>•	 Apresentação da história: o Product Owner explica os detalhes da história, como a interface</p><p>de usuário, a lógica de back-end necessária para adicionar produtos ao carrinho e os critérios de</p><p>aceitação, incluindo validações e testes.</p><p>•	 Discussão e análise: a equipe discute os requisitos, abordando aspectos como a complexidade da</p><p>interface de usuário, a integração com o banco de dados e a implementação das funcionalidades</p><p>de adicionar e remover produtos do carrinho.</p><p>•	 Estimativa de tamanho de camiseta: após a discussão inicial, cada membro da equipe propõe</p><p>um tamanho de camiseta para a história de usuário. As propostas são XS, S e M.</p><p>52</p><p>Unidade I</p><p>•	 A equipe discute as diferenças: um desenvolvedor que escolheu M explica que considera a</p><p>integração com o banco de dados complexa e sujeita a erros, enquanto outro, que escolheu XS,</p><p>pode achar que a tarefa é simples devido à experiência anterior com funcionalidades semelhantes.</p><p>•	 Registro da estimativa: a equipe discute e reavalia as propostas até chegar a um consenso.</p><p>Neste caso, a equipe concorda que o tamanho S é uma estimativa apropriada, refletindo um</p><p>esforço moderado, mas não trivial.</p><p>A técnica de T-shirt Sizes continua assim para todas as histórias de usuário na lista, proporcionando</p><p>uma maneira estruturada e colaborativa de estimar o esforço necessário para completar o trabalho. Essa</p><p>técnica é especialmente útil nas fases iniciais do projeto, quando ainda há muitas incertezas e a equipe</p><p>precisa de uma visão geral rápida da complexidade das tarefas. A simplicidade e a natureza visual das</p><p>estimativas de T-shirt Sizes facilitam a comunicação e a compreensão comum, permitindo que a equipe</p><p>se alinhe rapidamente e avance no planejamento e na execução do projeto.</p><p>Além das técnicas e exemplos apresentados, analisemos aspectos sobre a técnica Pontos de História,</p><p>que é amplamente utilizada em metodologias ágeis para medir o esforço relativo necessário para</p><p>completar histórias de usuário. Em vez de estimar o tempo exato, os Pontos de História permitem que a</p><p>equipe avalie a complexidade, o esforço e a incerteza associada a uma tarefa. Esta técnica ajuda a criar</p><p>uma compreensão compartilhada do trabalho a ser feito e facilita o planejamento e a priorização das</p><p>tarefas. A seguir, analisaremos um passo a passo detalhado de como utilizar os Pontos de História.</p><p>•	 Preparação: antes de iniciar a sessão de estimativa, o Product Owner prepara uma lista de</p><p>histórias, de usuário que precisam ser estimadas. Cada história deve ter uma descrição clara e</p><p>critérios de aceitação bem definidos para que a equipe possa compreender o trabalho envolvido.</p><p>•	 Explicação da técnica: o facilitador (geralmente o Scrum Master ou o Product Owner) explica a</p><p>técnica dos Pontos de História à equipe, se necessário. Ele esclarece que os Pontos de História são</p><p>usados para representar a complexidade, o esforço e a incerteza de cada história de usuário, com uma</p><p>escala numérica geralmente baseada na sequência de Fibonacci modificada (1, 2, 3, 5, 8, 13, 21 etc.).</p><p>•	 Apresentação da história: o Product Owner destaca a primeira história de usuário à equipe. Ele</p><p>fornece detalhes suficientes para que todos compreendam o que precisa ser feito e os critérios de</p><p>aceitação associados.</p><p>•	 Discussão e análise: a equipe discute a história de usuário, considerando fatores como</p><p>complexidade, dependências, riscos e o tempo necessário para a conclusão. Esta discussão inicial</p><p>ajuda a alinhar a compreensão da equipe sobre o trabalho envolvido.</p><p>•	 Estimativa inicial: cada membro da equipe atribui um valor de Pontos de História à história de</p><p>usuário com base na sua percepção da complexidade e do esforço necessário. Normalmente, isso</p><p>é feito individualmente, depois as estimativas são comparadas. Se há grandes discrepâncias entre</p><p>elas, a equipe discute as razões por trás dessas diferenças.</p><p>53</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>•	 Ajuste das estimativas: após a discussão, os membros da equipe podem ajustar suas estimativas.</p><p>O processo de estimar, discutir e reestimar continua até que a equipe alcance um consenso ou</p><p>uma convergência de estimativas.</p><p>•	 Registro da estimativa: uma vez que a equipe concorda na quantidade de Pontos de História</p><p>para uma determinada história, essa estimativa é registrada no backlog do produto ao lado da</p><p>história de usuário. A equipe então passa para a próxima história de usuário e repete o processo.</p><p>A partir disso, consideremos uma equipe que está desenvolvendo um aplicativo de gestão de</p><p>projetos. O Product Owner apresenta uma história de usuário: “como usuário, eu quero poder criar um</p><p>novo projeto com um nome e uma descrição para que eu possa organizar meu trabalho”. Analisemos o</p><p>exemplo a seguir.</p><p>•	 Apresentação da história: o Product Owner explica os detalhes da história, incluindo a interface</p><p>do usuário necessária, a lógica de back-end para armazenar os dados do projeto e os critérios de</p><p>aceitação, como validações e testes.</p><p>•	 Discussão e análise: a equipe discute os requisitos, abordando aspectos como a complexidade da</p><p>interface do usuário, a integração com o banco de dados e a implementação das funcionalidades</p><p>de criação de projeto.</p><p>•	 Estimativa inicial: após a discussão inicial, cada membro da equipe atribui um valor de Pontos</p><p>de História à história de usuário. As estimativas variam de 3 a 8 pontos. A equipe discute as</p><p>diferenças: um desenvolvedor que estimou 8 pontos explica que considera a validação dos dados</p><p>e a interface do usuário mais complexa do que parece, enquanto outro, que estimou 3 pontos,</p><p>acha que a tarefa é simples e rotineira.</p><p>•	 Ajuste das estimativas: após a discussão, a equipe decide ajustar suas estimativas. Desta vez, a</p><p>maioria concorda que 5 pontos de história é uma estimativa apropriada, refletindo a complexidade</p><p>moderada da tarefa.</p><p>•	 Registro da estimativa: a estimativa de 5 pontos de história é registrada no backlog ao lado da</p><p>história de usuário.</p><p>Repetindo esse processo para todas as histórias de usuário, a equipe pode criar uma visão clara do</p><p>esforço relativo necessário para completar o backlog. Os Pontos de História ajudam a equipe a planejar</p><p>seus sprints de maneira mais eficaz, permitindo uma melhor alocação de recursos e gestão de expectativas</p><p>com os stakeholders. Além disso, ao longo do tempo, a equipe pode utilizar a velocidade (a soma dos</p><p>Pontos de História concluídos em um sprint) para prever com maior precisão o tempo necessário para</p><p>completar futuras iterações e o projeto como um todo.</p><p>Para finalizar os exemplos temos a técnica Delphi, que é um método estruturado de estimativa que</p><p>busca obter um consenso entre especialistas sobre o esforço necessário para completar uma tarefa ou</p><p>projeto. É particularmente útil para estimativas complexas e em situações nas quais há grande incerteza</p><p>ou falta de dados históricos.</p><p>54</p><p>Unidade I</p><p>A técnica Delphi envolve várias rodadas de estimativas anônimas e feedback, permitindo que os</p><p>participantes ajustem suas respostas com base no retorno coletivo até que um consenso seja alcançado.</p><p>A seguir, analisemos o passo a passo detalhado de como a técnica Delphi é realizada.</p><p>•	 Seleção dos especialistas: o facilitador (geralmente o Scrum Master ou o Product Owner)</p><p>seleciona um grupo de especialistas que têm conhecimento relevante sobre o projeto ou as</p><p>tarefas a serem estimadas. Esses especialistas podem ser membros da equipe de desenvolvimento,</p><p>stakeholders ou outros profissionais com experiência relevante.</p><p>•	 Preparação do questionário: o facilitador prepara um questionário que inclui uma lista de</p><p>tarefas ou histórias de usuário que precisam ser estimadas. Cada tarefa deve ter uma descrição</p><p>clara e critérios de aceitação bem definidos para garantir que todos os especialistas compreendam</p><p>o trabalho envolvido.</p><p>•	 Primeira rodada de estimativas: os especialistas recebem o questionário e fornecem suas</p><p>estimativas</p><p>de modo independente e anônimo. Eles podem utilizar uma escala numérica (por</p><p>exemplo, horas de trabalho, pontos de história) para estimar o esforço necessário para completar</p><p>cada tarefa. As respostas são enviadas de volta ao facilitador.</p><p>•	 Coleta e análises das estimativas: o facilitador coleta as estimativas de todos os especialistas</p><p>e calcula a média ou mediana das respostas para cada tarefa. Além disso, o facilitador analisa a</p><p>distribuição das estimativas, identificando qualquer divergência significativa.</p><p>•	 Feedback e justificativas: o facilitador dá feedback aos especialistas, compartilhando a média</p><p>ou mediana das estimativas e destacando quaisquer discrepâncias significativas. Os especialistas</p><p>também recebem as justificativas anônimas de seus colegas sobre por que forneceram certas</p><p>estimativas. Esse feedback ajuda os especialistas a entender diferentes perspectivas e reconsiderar</p><p>suas próprias estimativas.</p><p>•	 Segunda rodada de estimativas: com base no feedback recebido, os especialistas revisam</p><p>e ajustam suas estimativas, se necessário. Eles enviam novamente suas respostas de forma</p><p>independente e anônima. O facilitador coleta e analisa essas novas estimativas da mesma maneira</p><p>que na primeira rodada.</p><p>•	 Rodadas adicionais (se necessário): o processo de feedback e reestimativa pode ser repetido</p><p>por várias rodadas, até que as estimativas convirjam para um consenso. Normalmente, duas ou</p><p>três rodadas são suficientes para alcançar um acordo razoável.</p><p>•	 Registro das estimativas finais: uma vez que o consenso é alcançado, as estimativas finais são</p><p>registradas no backlog do produto ao lado das tarefas ou histórias de usuário. A equipe pode</p><p>então usar essas estimativas para planejar sprints e alocar recursos de maneira eficaz.</p><p>55</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Para o exemplo ilustrativo, vamos considerar uma equipe que está desenvolvendo um sistema de</p><p>reservas de hotel. O Product Owner apresenta a seguinte história de usuário: “como usuário, eu quero</p><p>poder reservar um quarto de hotel on-line para que eu possa garantir minha estadia”.</p><p>•	 Seleção dos especialistas: o facilitador seleciona cinco especialistas da equipe, incluindo</p><p>desenvolvedores, testadores e analistas de negócios.</p><p>•	 Preparação do questionário: o facilitador prepara um questionário detalhado com a descrição da</p><p>história de usuário e os critérios de aceitação, como a interface de usuário necessária, integração</p><p>com o sistema de pagamento e validações de dados.</p><p>•	 Primeira rodada de estimativas: os especialistas fornecem suas estimativas de modo anônimo.</p><p>As estimativas variam de 20 a 80 horas de trabalho.</p><p>•	 Coleta e análise das estimativas: o facilitador calcula a média (50 horas) e a mediana (45 horas)</p><p>das estimativas. Há uma grande discrepância, então o facilitador coleta as justificativas anônimas</p><p>de cada especialista.</p><p>•	 Feedback e justificativas: o facilitador compartilha o feedback com os especialistas, destacando</p><p>a média e a mediana das estimativas e fornecendo as justificativas anônimas.</p><p>•	 Segunda rodada de estimativas: com base no feedback, os especialistas ajustam suas estimativas.</p><p>Desta vez, as estimativas convergem para um intervalo menor, variando de 40 a 60 horas.</p><p>•	 Rodadas adicionais (se necessário): o facilitador pode optar por realizar uma terceira rodada</p><p>se ainda houver grandes discrepâncias. Normalmente, duas rodadas são suficientes para alcançar</p><p>um consenso razoável.</p><p>•	 Registro das estimativas finais: as estimativas finais são registradas no backlog do produto</p><p>como 50 horas de trabalho.</p><p>No exemplo apresentado, a técnica Delphi, com suas rodadas de feedback anônimo e reestimativa,</p><p>ajuda a minimizar o viés e a influência de indivíduos dominantes, promovendo uma avaliação mais</p><p>equilibrada e informada. Ela é particularmente útil para estimar tarefas complexas e incertas, em que o</p><p>consenso de especialistas pode fornecer uma estimativa mais confiável e precisa.</p><p>Além dessas técnicas específicas, a abordagem ágil incentiva a reavaliação constante e a adaptação</p><p>das estimativas ao longo do desenvolvimento. À medida que a equipe ganha mais informações e</p><p>experiência com o projeto, as estimativas podem ser ajustadas para refletir melhor a realidade. Isso é</p><p>facilitado através de reuniões regulares de refinamento do backlog, em que as histórias de usuário são</p><p>revisadas e as estimativas atualizadas conforme necessário.</p><p>56</p><p>Unidade I</p><p>Em um ambiente ágil, é importante termos claro que as estimativas são apenas previsões, e não</p><p>compromissos firmados. A incerteza e a variabilidade são partes naturais do processo de desenvolvimento,</p><p>e a flexibilidade, para ajustar o planejamento conforme novas informações que surgem, é crucial para o</p><p>sucesso. O foco deve estar em manter a transparência, a comunicação aberta e a colaboração contínua</p><p>entre todos os membros da equipe.</p><p>Podemos concluir que as técnicas de estimativa ágil, como Planning Poker, T-shirt Sizes, Pontos</p><p>de História e a técnica Delphi, são ferramentas valiosas para ajudar as equipes a avaliar o esforço</p><p>necessário para completar tarefas e funcionalidades. Elas promovem a participação ativa, o consenso</p><p>e a flexibilidade, permitindo uma gestão de projetos mais adaptável e eficaz. A reavaliação constante e</p><p>a adaptação das estimativas, ao longo do desenvolvimento, garantem que a equipe possa responder</p><p>rapidamente às mudanças e entregar valor contínuo aos stakeholders.</p><p>57</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Resumo</p><p>Nesta unidade, exploramos, de maneira abrangente, a gestão ágil</p><p>de projetos de TI, enfatizando a implementação de frameworks ágeis</p><p>e a comparação dessas metodologias com abordagens tradicionais de</p><p>gestão de projetos, especificamente aquelas alinhadas com o PMI e o</p><p>PMBOK. Na primeira parte, esclarecemos os princípios fundamentais que</p><p>sustentam a agilidade, destacando sua capacidade de resposta rápida e</p><p>eficiente a mudanças, uma necessidade crítica em projetos de tecnologia</p><p>da informação. Esses princípios foram ilustrados através do Manifesto Ágil,</p><p>que prioriza colaboração, adaptabilidade e resultados funcionais.</p><p>A discussão progrediu para uma análise detalhada dos principais</p><p>frameworks ágeis, como Scrum, Kanban e XP (Extreme Programming),</p><p>cada um com suas práticas e abordagens distintas para otimizar o fluxo</p><p>de trabalho e a eficiência. Compreendemos que o Scrum, por exemplo,</p><p>organiza o trabalho em sprints e enfatiza a importância de papéis e</p><p>cerimônias definidas, enquanto o Kanban concentra-se na visualização do</p><p>fluxo de trabalho e na eficiência operacional. O XP é destacado por suas</p><p>técnicas rigorosas, que incluem programação em pares e TDD.</p><p>Exploramos, de modo amplo, o desenvolvimento ágil, focando</p><p>especificamente na configuração e gestão de equipes ágeis. Destacamos a</p><p>importância de configurar corretamente os squads ágeis, que são grupos</p><p>pequenos, multifuncionais e essenciais para o sucesso em projetos dinâmicos</p><p>e multifacetados. O ambiente de desenvolvimento, tanto físico quanto</p><p>virtual, foi outro fator crítico discutido. Entendemos que no espaço físico a</p><p>promoção de um layout que favoreça a comunicação e a interação é crucial,</p><p>enquanto em um cenário de aumento de trabalho remoto, ferramentas</p><p>como Slack, Jira e GitHub se tornam indispensáveis para manter a equipe</p><p>conectada. As práticas diárias como stand-ups são essenciais para manter</p><p>todos a par dos desenvolvimentos, independentemente da sua localização.</p><p>Por fim, analisamos as técnicas de estimativa ágil, como o Planning</p><p>Poker e os Pontos de História, que são descritas como fundamentais para</p><p>estimar o esforço e gerenciar as expectativas de maneira eficaz. Fizemos</p><p>exemplos práticos e fornecemos um passo a passo para a aplicação. Estas</p><p>técnicas facilitam a discussão e o entendimento coletivo, ajudando a alinhar</p><p>todos os membros da equipe e a promover uma abordagem de consenso.</p><p>58</p><p>Unidade I</p><p>Exercícios</p><p>Questão 1. (Cesgranrio/2024, adaptada) Consideremos uma organização que contratará uma equipe</p><p>para</p><p>gerenciam o</p><p>desenvolvimento de produtos e serviços, especialmente no contexto da tecnologia da informação (TI).</p><p>A aplicação dessas metodologias ágeis não se restringe apenas ao setor de TI, mas se expande para</p><p>diversas áreas de negócios que buscam mais eficiência e resposta rápida às mudanças do mercado.</p><p>Esta disciplina proporciona uma abrangente introdução e imersão nas práticas de gerenciamento ágil</p><p>de projetos. O curso tem como objetivo fundamental introduzir os alunos aos conceitos do Manifesto</p><p>Ágil e às metodologias tradicionais apoiadas pelo Project Management Institute (PMI), destacando-se</p><p>pela capacidade de fundir teoria e prática em um contexto dinâmico e moderno.</p><p>Os projetos ágeis são baseados em valores e princípios delineados no Manifesto Ágil, que enfatiza</p><p>a colaboração, a flexibilidade, a entrega contínua de valor e a capacidade de responder rapidamente a</p><p>mudanças. Essa abordagem contrasta com os métodos tradicionais de gerenciamento de projetos, que</p><p>são muitas vezes mais rígidos e sequenciais, focados em planejamento extenso e execução linear.</p><p>A partir disso, abordaremos aqui desde a história e os fundamentos da agilidade até as técnicas mais</p><p>avançadas de gerenciamento de projetos em TI. Exploraremos os principais frameworks ágeis, como</p><p>Scrum, Kanban e XP (Extreme Programming), e discutiremos sobre suas aplicações práticas, através de</p><p>estudos de caso e configurações reais de trabalho em equipe. A transição das metodologias tradicionais</p><p>para abordagens mais flexíveis e adaptativas serão analisadas, visando preparar os alunos para enfrentar</p><p>os desafios e mudanças no cenário de desenvolvimento de software.</p><p>Nos aprofundaremos no planejamento iterativo, técnicas de estimativa ágil e gestão de backlogs,</p><p>além de focarmos na execução de projetos utilizando sprints e práticas de integração e entrega</p><p>contínuas. Assim, notaremos que uma característica central dos projetos ágeis é a formação de equipes</p><p>multidisciplinares e auto-organizáveis, conhecidas como squads ou scrum teams, que são responsáveis</p><p>por todo o ciclo de vida do projeto, desde o planejamento até a entrega e o feedback do cliente.</p><p>Incentivaremos também a análise e o desenvolvimento de habilidades em liderança e gerenciamento</p><p>de equipes ágeis, com ênfase especial na configuração e dinâmica dessas equipes. Isso inclui o uso de</p><p>ferramentas digitais para suportar os processos ágeis e estratégias para escalar métodos ágeis em</p><p>grandes organizações.</p><p>Empresas de todos os tamanhos têm adotado práticas ágeis para aproveitar seus benefícios. Por</p><p>exemplo, em grandes corporações, métodos ágeis têm sido usados para escalar operações sem perder</p><p>agilidade, através de abordagens como o SAFe (Scaled Agile Framework) ou o LeSS (Large Scale Scrum),</p><p>que trataremos nesta disciplina.</p><p>Notaremos que as práticas ágeis também estão sendo cada vez mais integradas com as últimas</p><p>inovações tecnológicas, como inteligência artificial e automação, para facilitar a gestão de projetos</p><p>e a tomada de decisões baseada em dados. Isso é visível na crescente adoção de ferramentas</p><p>de  CI/CD  (Continuous Integration/Continuous Delivery), que automatizam partes do processo de</p><p>desenvolvimento para garantir entregas mais rápidas e de maior qualidade.</p><p>8</p><p>Além das competências técnicas, enfatizaremos nossas discussões no desenvolvimento profissional</p><p>e na preparação para certificações ágeis, que são cruciais para o fortalecimento do perfil profissional</p><p>dos alunos no mercado de trabalho. As tendências futuras na gestão de projetos de TI, como DevOps,</p><p>NoOps, inteligência artificial (IA) e gestão de equipes distribuídas também serão exploradas, oferecendo</p><p>uma visão ampla e atualizada dos caminhos que a indústria de tecnologia está seguindo.</p><p>Por fim, trataremos sobre a transição para o trabalho remoto, que foi acelerada por circunstâncias</p><p>globais como a pandemia de covid-19, destacando a versatilidade dos métodos ágeis. Assim, não</p><p>buscamos apenas equipar os alunos com conhecimentos e habilidades essenciais para sua carreira</p><p>profissional, mas também prepará-los para serem líderes adaptativos e inovadores na gestão de projetos</p><p>de software.</p><p>9</p><p>INTRODUÇÃO</p><p>Começaremos nossos estudos com uma introdução ampla à agilidade, explorando as bases históricas</p><p>e teóricas dos frameworks ágeis. Na primeira parte, apresentaremos uma visão detalhada sobre o</p><p>PMI (Project Management Institute) e sua metodologia tradicional de gestão de projetos, incluindo uma</p><p>introdução ao PMBOK, um guia reconhecido globalmente para a gestão de projetos. Isso estabelecerá</p><p>uma base sólida para contrastar com as abordagens ágeis que serão discutidas em seguida.</p><p>Ao nos aprofundarmos nos conceitos de agilidade, discutiremos a origem e os princípios do</p><p>Manifesto Ágil. Isso será crucial para entendermos o que são práticas ágeis e também por que elas foram</p><p>desenvolvidas, enfatizando a necessidade de flexibilidade e resposta rápida às mudanças, características</p><p>essenciais em ambientes dinâmicos de TI. A transição para abordagens ágeis será explorada, ilustrando</p><p>como as metodologias tradicionais estão evoluindo para modelos mais adaptativos e colaborativos,</p><p>marcando uma mudança significativa no paradigma de gestão de projetos em TI.</p><p>Em seguida, apresentaremos as discussões sobre frameworks ágeis, como Scrum, Kanban e</p><p>XP (Extreme Programming), oferecendo ao leitor uma visão geral de cada método e suas peculiaridades.</p><p>Esta parte do livro destina-se a fornecer um entendimento claro de como esses frameworks funcionam</p><p>na prática e como eles se diferenciam entre si e em relação às práticas tradicionais. A comparação</p><p>entre tais modelos ágeis será enriquecida com exemplos práticos e discussões sobre suas aplicações em</p><p>diferentes contextos de projetos de TI.</p><p>Na segunda unidade, nosso foco se deslocará para a configuração e o gerenciamento de equipes ágeis.</p><p>Nesse momento, discutiremos sobre a formação de squads, que são pequenos times multifuncionais</p><p>focados em tarefas específicas. Detalharemos os papéis e as responsabilidades dentro de um squad, bem</p><p>como as melhores práticas para criar um ambiente que suporte a cultura ágil, que é essencial para o</p><p>sucesso do time, incorporando valores e comportamentos que promovem colaboração, flexibilidade e</p><p>melhoria contínua.</p><p>Abordaremos também o ambiente de desenvolvimento ágil, que pode ser tanto físico quanto virtual,</p><p>destacando a importância de espaços que promovam a interação constante e o compartilhamento de</p><p>ideias entre os membros da equipe. Isso se complementa com técnicas de planejamento iterativo e</p><p>incremental, como o Planning Poker, que são essenciais para estimar o trabalho de modo eficaz e manter</p><p>o projeto ágil em curso. Estas técnicas ajudam na organização e previsibilidade dos projetos, garantindo</p><p>que a equipe possa adaptar-se rapidamente às mudanças, que é um dos pilares das práticas ágeis.</p><p>A unidade III, por sua vez, será dedicada ao planejamento, execução e gestão ágil, começando pela</p><p>priorização de backlog e elaboração de roadmaps ágeis. Com isso, discutiremos sobre a organização e</p><p>a prioridade das demandas de projetos, para que se maximizem o valor entregue ao cliente, usando</p><p>técnicas ágeis para adaptar-se rapidamente às mudanças nas necessidades do projeto ou do mercado.</p><p>Avançaremos nossos estudos, explorando os ciclos de desenvolvimento iterativos, conhecidos</p><p>como sprints, que são períodos fixos durante os quais um conjunto predefinido de atividades deve</p><p>ser completado e preparado para revisão. Este método promove uma cadência de entrega e permite</p><p>10</p><p>avaliações regulares do progresso, facilitando ajustes rápidos que podem ser necessários para alinhar</p><p>o projeto com as expectativas do cliente e os objetivos comerciais. Os Daily Stand-ups, reuniões</p><p>breves e diárias, nas quais a equipe sincroniza suas atividades e destaca obstáculos, também serão</p><p>abordados como uma ferramenta vital para manter todos os membros da equipe alinhados e focados</p><p>nos objetivos da sprint.</p><p>Além disso, os alunos</p><p>executar um projeto de Tecnologia da Informação (TI). Segundo os critérios de licitação exigidos,</p><p>essa equipe deverá seguir as normas do PMBOK. As especificações do projeto estabelecem o uso de um</p><p>tipo de ciclo de vida que determina o escopo, o prazo e o custo do projeto nas fases iniciais do ciclo de</p><p>vida e que quaisquer alterações no escopo serão gerenciadas de modo acurado, funcionando como um</p><p>ciclo em cascata.</p><p>Considerando as especificações do projeto e as conformidades com o PMBOK, qual é o tipo de ciclo</p><p>de vida que deverá ser escolhido pela equipe contratada?</p><p>A) Ágil.</p><p>B) Iterativo.</p><p>C) Preditivo.</p><p>D) Adaptativo.</p><p>E) Incremental.</p><p>Resposta correta: alternativa C.</p><p>Análise da questão</p><p>Em um ciclo de vida preditivo, o escopo, o prazo e o custo são determinados nas fases iniciais do</p><p>projeto e quaisquer alterações no escopo são cuidadosamente gerenciadas. O ciclo de vida preditivo</p><p>também é chamado de ciclo de vida em cascata.</p><p>Projetos com requisitos bem definidos e estáveis podem beneficiar-se da previsibilidade e do</p><p>controle oferecidos pelo modelo em cascata. No entanto, projetos desenvolvidos em ambientes incertos</p><p>e voláteis, que ocorrem comumente na área de TI, podem obter mais vantagens com a flexibilidade e a</p><p>capacidade de adaptação proporcionadas pelas práticas ágeis.</p><p>59</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Questão 2. (Ufscar/2023, adaptada) O Manifesto Ágil foi criado em 2001 e é base para diferentes</p><p>metodologias. Sobre o manifesto em questão, avalie as afirmativas a seguir.</p><p>I – O Kanban deve ser utilizado como ferramenta principal.</p><p>II – É orientado por quatro valores principais.</p><p>III – ITIL é um exemplo de framework que segue o Manifesto Ágil.</p><p>É correto o que se afirma em:</p><p>A) I, apenas.</p><p>B) II, apenas.</p><p>C) I e II, apenas.</p><p>D) II e III, apenas.</p><p>E) I, II e III.</p><p>Resposta correta: alternativa B.</p><p>Análise das afirmativas</p><p>I – Afirmativa incorreta.</p><p>Justificativa: o Manifesto Ágil não prevê a utilização do Kanban como ferramenta principal. O Kanban</p><p>é uma metodologia de gestão visual que é comumente usada em contextos ágeis, mas não é parte</p><p>integrante do Manifesto Ágil.</p><p>II – Afirmativa correta.</p><p>Justificativa: o Manifesto Ágil estabeleceu quatro valores fundamentais. São eles:</p><p>•	 Indivíduos e interações são mais valiosos que processos e ferramentas.</p><p>•	 Software em funcionamento é mais significativo que documentação abrangente.</p><p>•	 Colaboração com o cliente é mais importante do que negociação de contratos.</p><p>•	 Responder a mudanças é mais valioso do que seguir um plano.</p><p>III – Afirmativa incorreta.</p><p>Justificativa: o ITIL (Information Technology Infrastructure Library) é um conjunto de boas práticas</p><p>para o gerenciamento de serviços de TI. Ele foca em eficiência e qualidade de serviço, mas não segue</p><p>necessariamente os princípios do Manifesto Ágil.</p><p>serão introduzidos à gestão eficaz de backlogs e iterações, aprendendo a</p><p>manter o backlog organizado e atualizado, o que é essencial para garantir que o trabalho seja claramente</p><p>definido e prontamente acessível. Essas sessões enfatizam a importância de uma boa comunicação</p><p>e colaboração dentro da equipe para uma gestão ágil eficiente.</p><p>Na sequência, trataremos sobre a qualidade, testes e práticas de entrega contínua, iniciando com</p><p>uma discussão sobre como a qualidade e os testes são tratados nas metodologias tradicionais do PMI e</p><p>como os métodos ágeis incorporam e expandem esses conceitos. Este segmento sublinha a necessidade</p><p>de integrar práticas de qualidade desde o início do desenvolvimento do projeto, em vez de vê-las como</p><p>uma etapa final. A integração contínua (CI) e a entrega contínua (CD) serão examinadas em detalhe,</p><p>mostrando como essas práticas permitem que as equipes de desenvolvimento automatizem os testes e a</p><p>liberação de atualizações de software, reduzindo o tempo de ciclo e aumentando a eficiência.</p><p>Também conheceremos os testes automatizados e o desenvolvimento orientado por testes</p><p>(TDD – Test-Driven Development), que são métodos essenciais para garantir que o código novo atenda</p><p>aos requisitos antes mesmo que ele seja integrado ao código principal, contribuindo significativamente</p><p>para a qualidade do software. Neste ponto, também discutiremos o deployment (que se refere ao processo</p><p>de distribuir e instalar uma aplicação ou uma atualização de software em um ambiente de produção,</p><p>no qual ela pode ser acessada por usuários finais) e o monitoramento em ambientes ágeis, destacando</p><p>como a rápida iteração e feedback contínuo são essenciais para o sucesso no desenvolvimento de</p><p>software ágil. Por meio desta abordagem, o aluno estará equipado com conhecimentos e habilidades</p><p>práticas para aplicar técnicas ágeis em projetos reais; além de estar preparado para enfrentar desafios</p><p>em ambientes dinâmicos e complexos com confiança.</p><p>Também é salutar falarmos sobre como escalar métodos ágeis em grandes organizações, uma</p><p>área crítica para empresas que buscam adotar a agilidade em níveis departamentais ou corporativos.</p><p>A capacidade de ampliar as práticas ágeis além de pequenas equipes para envolver múltiplas equipes</p><p>interconectadas será explorada por meio de metodologias como SAFe (Scaled Agile Framework), LeSS</p><p>(Large Scale Scrum) e Nexus, que oferecem estruturas para implementar agilidade em grande escala</p><p>com eficácia.</p><p>Neste contexto, também daremos atenção às ferramentas digitais que suportam a colaboração e a</p><p>gestão de projetos em ambientes ágeis. Plataformas como Jira, Trello e Asana são essenciais para o</p><p>gerenciamento de tarefas, permitindo que as equipes mantenham o controle sobre os sprints, backlogs e</p><p>progresso dos projetos em tempo real. Compreenderemos, então, que essas ferramentas facilitam</p><p>a comunicação e a organização dentro das equipes e também oferecem visibilidade para stakeholders e</p><p>gerentes, sendo fundamentais para o sucesso da gestão de projetos em ambientes ágeis.</p><p>11</p><p>Adicionalmente, compreenderemos que a automação desempenha um papel crucial na sustentação</p><p>dos processos ágeis, especialmente por meio da CI e da CD. Assim, ferramentas como Jenkins e GitLab CI</p><p>serão examinadas, destacando como elas automatizam a compilação, o teste e a implantação de</p><p>software, e permitem que as equipes aumentem a frequência de entregas sem sacrificar a qualidade.</p><p>A escolha e adaptação dessas ferramentas, conforme as necessidades específicas das equipes, também</p><p>serão abordadas, enfatizando a importância de personalizar as soluções tecnológicas para maximizar</p><p>sua eficácia em diferentes contextos organizacionais.</p><p>Seguiremos com foco nas tendências futuras em tecnologia e gestão de projetos, nas quais conceitos</p><p>como DevOps e NoOps serão discutidos. Estas práticas representam uma evolução na maneira como as</p><p>operações de desenvolvimento e infraestrutura são geridas, visando à automatização extensiva e à</p><p>melhoria contínua dos processos.</p><p>O impacto da IA e do aprendizado de máquina na gestão de projetos também será um tema abordado,</p><p>explorando como essas tecnologias estão começando a transformar as práticas de gerenciamento de</p><p>projetos. Por exemplo, a IA pode ajudar na análise de riscos, na previsão de resultados de projetos</p><p>e na otimização de recursos, oferecendo insights que podem melhorar significativamente a tomada</p><p>de decisão. Além disso, a gestão de equipes distribuídas, particularmente em contextos de trabalho</p><p>remoto, será analisada.</p><p>A última unidade deste livro-texto concentra-se no desenvolvimento profissional e liderança em gestão</p><p>ágil, complementando a formação técnica com habilidades essenciais para o avanço na carreira e eficácia</p><p>organizacional. Considerando isso, nesse momento, abordaremos certificações ágeis reconhecidas, como</p><p>Scrum Master, Product Owner, Agile Coach e PMI Agile Certified Practitioner (PMI-ACP), destacando sua</p><p>importância como indicadores de conhecimento e competência no campo ágil.</p><p>Além das certificações, discutiremos o desenvolvimento de habilidades interpessoais, como liderança</p><p>e colaboração, que são cruciais para a gestão eficaz de equipes ágeis e para a promoção de um ambiente</p><p>de trabalho que valorize a transparência, a adaptabilidade e o engajamento contínuo dos membros da</p><p>equipe. Este livro-texto também incentiva o networking ativo e a participação em comunidades ágeis,</p><p>reconhecendo que o aprendizado contínuo e a troca de experiências são vitais para a adaptação às</p><p>rápidas mudanças na indústria de TI.</p><p>Na sequência, apresentaremos estudos de caso e aplicações práticas que demonstram a implementação</p><p>de práticas ágeis em larga escala. Esses estudos nos oferecerão uma perspectiva realista de desafios e</p><p>estratégias envolvidas na adoção de métodos ágeis em diferentes tipos de organizações. Ao analisá-los,</p><p>o aluno poderá visualizar como os conceitos aprendidos são aplicados no mundo real, enfrentando e</p><p>superando obstáculos comuns que surgem durante a transformação ágil das empresas.</p><p>Por fim, contaremos com um glossário de termos ágeis que é fornecido para assegurar que todos</p><p>os alunos, independentemente de seu nível de familiaridade prévio com a gestão ágil, tenham uma</p><p>compreensão clara da terminologia específica usada no campo. Este recurso se torna um valioso ponto</p><p>de referência para o leitor, auxiliando na consolidação de seu conhecimento e na sua capacidade de</p><p>comunicar eficientemente conceitos e práticas ágeis dentro de suas organizações.</p><p>13</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Unidade I</p><p>1 INTRODUÇÃO À AGILIDADE E FUNDAMENTOS DOS FRAMEWORKS ÁGEIS</p><p>A introdução à agilidade e aos fundamentos dos frameworks ágeis constitui a base sobre a qual</p><p>se assenta a gestão ágil de projetos de TI. Desse modo, a esta parte inicial do livro-texto é dedicada a</p><p>estabelecer um entendimento sólido dos princípios e valores que definem a agilidade, uma abordagem</p><p>que se destaca principalmente pela sua capacidade de adaptação e resposta rápida às mudanças,</p><p>o que é essencial em ambientes de desenvolvimento de software e projetos de TI. Neste momento,</p><p>portanto, trataremos sobre a história do Manifesto Ágil, um documento que foi redigido em 2001 por</p><p>um grupo de desenvolvedores de softwares que propunham uma nova maneira de pensar e executar o</p><p>desenvolvimento de projetos.</p><p>O Manifesto Ágil sublinha valores como a colaboração com o cliente acima da negociação</p><p>de contratos, a resposta às mudanças mais do que o seguimento de um plano fixo, a importância de</p><p>entregar um software funcional com frequência, entre outros aspectos. A discussão desses valores</p><p>permite ao leitor compreender não apenas as práticas ágeis, mas também a filosofia subjacente que</p><p>busca maximizar o valor para o cliente e melhorar a eficiência do processo de desenvolvimento.</p><p>Observação</p><p>Um framework ou arcabouço é um conjunto estruturado de práticas,</p><p>técnicas e regras que fornecem uma base para organizar, planejar e</p><p>executar projetos de maneira eficaz.</p><p>Os frameworks são projetados</p><p>para serem adaptáveis a diversas situações de projeto, oferecendo uma</p><p>estrutura que pode ser seguida para alcançar resultados de maneira</p><p>consistente, eficiente e previsível. Frameworks são particularmente úteis</p><p>em ambientes que seguem métodos ágeis de desenvolvimento de software,</p><p>pois fornecem as diretrizes necessárias para facilitar a colaboração, a rápida</p><p>iteração e a adaptabilidade — características essenciais das abordagens</p><p>ágeis. Eles ajudam as equipes a manterem o foco em entregar valor ao</p><p>cliente, enquanto gerenciam complexidades e mantêm a flexibilidade para</p><p>responder a mudanças. Além disso, um framework pode incluir papéis</p><p>definidos para os membros da equipe, eventos regulares para inspeção</p><p>e adaptação do trabalho, e artefatos que auxiliam na visualização do</p><p>progresso e na priorização do trabalho.</p><p>Além disso, neste tópico analisaremos detalhadamente os principais frameworks ágeis, como Scrum,</p><p>Kanban e XP (Extreme Programming). Cada um deles será examinado em termos de suas regras, práticas</p><p>14</p><p>Unidade I</p><p>e estruturas típicas. Por exemplo, Scrum é apresentado como um framework que organiza o trabalho</p><p>em ciclos chamados sprints e enfatiza papéis claros (como Scrum Master e Product Owner), cerimônias</p><p>específicas (como Sprints Planning, Daily Scrums, Sprint Reviews e Retrospectives) e artefatos (como</p><p>o Product Backlog, Sprint Backlog e o incremento do produto). Já o Kanban é discutido como uma</p><p>abordagem que foca na visualização e na gestão do fluxo de trabalho para otimizar a eficiência, enquanto</p><p>o XP enfatiza práticas e técnicas rigorosas como programação em pares e TDD.</p><p>Analisaremos também uma comparação crítica entre os métodos ágeis e as abordagens tradicionais</p><p>de gestão de projetos, como as orientadas pelo PMI (Project Management Institute), através do</p><p>PMBOK (Project Management Body of Knowledge). Desse modo, buscaremos entender como a agilidade</p><p>difere em termos de estrutura, cultura e eficácia em diferentes tipos de projetos, especialmente aqueles</p><p>caracterizados por requisitos incertos e rapidamente mutáveis.</p><p>1.1 Breve histórico sobre o PMI e a abordagem tradicional de gestão de</p><p>projetos, incluindo uma introdução ao PMBOK</p><p>O PMI foi criado em 1969 na Filadélfia, Pensilvânia, por cinco voluntários: James Snyder, Eric Jenett,</p><p>Gordon Davis, A. E. “Ned” Engman e Susan Gallagher. Esses fundadores, oriundos de diferentes setores</p><p>industriais, tinham como objetivo criar uma organização dedicada ao desenvolvimento e à promoção</p><p>das práticas de gestão de projetos.</p><p>Desde sua criação, o PMI tem sido uma força motriz no estabelecimento de padrões profissionais</p><p>para a gestão de projetos, oferecendo uma plataforma para troca de conhecimento e avanço da</p><p>profissão. Em 1984, o PMI lançou sua primeira certificação, o Project Management Professional (PMP),</p><p>que rapidamente tornou-se uma das certificações mais reconhecidas e respeitadas na área de gestão de</p><p>projetos em todo o mundo.</p><p>Saiba mais</p><p>Atualmente, o PMI conta com um site, em que é possível conhecer mais</p><p>sobre sua história e explorar diversos aspectos da ferramenta.</p><p>Disponível em: https://www.pmi.org/. Acesso em: 30 jul. 2024.</p><p>Um dos marcos mais significativos na história do PMI foi a publicação do primeiro guia do PMBOK,</p><p>em 1987. Este guia consolidou uma vasta gama de conhecimentos, práticas e processos considerados</p><p>essenciais para a gestão eficaz de projetos. A partir disso, ele evoluiu ao longo dos anos, passando por</p><p>várias edições, refletindo as mudanças e avanços na área de gestão de projetos (PMI, 2021). Ao longo</p><p>das décadas, o PMI também expandiu significativamente sua influência e presença global. Atualmente,</p><p>possui centenas de milhares de membros em mais de 200 países e territórios, e oferece uma ampla</p><p>gama de certificações além do PMP, incluindo o PMI-ACP (Agile Certified Practitioner), que aborda</p><p>metodologias ágeis.</p><p>15</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>O PMI continua a desempenhar um papel crucial no avanço da profissão de gestão de projetos,</p><p>promovendo educação, pesquisa e advocacy. Sua missão é capacitar profissionais e organizações a</p><p>atingirem a excelência na execução de projetos, programas e portfólios, contribuindo, assim, para o</p><p>sucesso sustentável e a criação de valor.</p><p>Observação</p><p>Advocacy é um termo que se refere ao ato de defender, promover</p><p>ou apoiar uma causa, política, ideia ou grupo de pessoas. O objetivo do</p><p>advocacy é influenciar a opinião pública, políticas governamentais e</p><p>decisões institucionais para provocar mudanças sociais, políticas ou</p><p>econômicas. As atividades de advocacy podem incluir campanhas de</p><p>conscientização pública, educação e capacitação, parcerias e coalizões,</p><p>além de litigação estratégica.</p><p>Como um dos seus principais projetos, o PMI tem a publicação do PMBOK, que é um guia amplamente</p><p>reconhecido e utilizado na área de gestão de projetos. Ele compila um conjunto abrangente de processos,</p><p>melhores práticas, terminologias e diretrizes aceitas como padrão para a gestão eficaz de projetos. É</p><p>estruturado em torno de cinco grupos de processos principais: iniciação, planejamento, execução,</p><p>monitoramento e controle, e encerramento. Cada um desses grupos de processos é detalhado com</p><p>subprocessos específicos que abrangem desde a definição do escopo e o desenvolvimento do cronograma</p><p>até a gestão de riscos e a comunicação com as partes interessadas.</p><p>Além dos grupos de processos, o PMBOK organiza as práticas de gestão de projetos em dez áreas de</p><p>conhecimento: integração, escopo, tempo, custo, qualidade, recursos, comunicação, riscos, aquisições e</p><p>partes interessadas. Essas áreas de conhecimento fornecem uma estrutura lógica e coerente para abordar</p><p>todos os aspectos de um projeto. O guia é amplamente utilizado como uma referência fundamental para</p><p>profissionais de gestão de projetos e é a base para muitas certificações oferecidas pelo PMI, incluindo a</p><p>PMP. Sua relevância e aplicação abrangem diversos setores, tornando-o um recurso indispensável para</p><p>aqueles que buscam aprimorar suas habilidades e garantir o sucesso de seus projetos.</p><p>Uma das influências do PMBOK está no tipo de abordagem utilizada na gestão de projeto.</p><p>A abordagem tradicional de gestão de projetos, por exemplo, é enfatizada pelo PMI e pelo PMBOK.</p><p>Ela é, muitas vezes, caracterizada por sua natureza sequencial e estruturada, conhecida como cascata</p><p>ou waterfall. Esta metodologia destaca a necessidade de uma definição clara do escopo do projeto, um</p><p>planejamento detalhado e uma execução rigorosa.</p><p>O modelo cascata é projetado para controle e previsibilidade, com cada fase do projeto fluindo</p><p>logicamente para a próxima, e mudanças no escopo ou nos requisitos geralmente são vistas como</p><p>custosas e evitadas sempre que possível. Contudo, embora essa abordagem possa ser eficaz para projetos</p><p>com requisitos claros e estáveis, ela muitas vezes se mostra menos adaptável a mudanças e inovações</p><p>frequentes, características comuns em muitos projetos de TI.</p><p>16</p><p>Unidade I</p><p>Assim, surge a necessidade de abordagens mais flexíveis e dinâmicas, como as práticas ágeis, que</p><p>permitem às equipes responder mais rapidamente às mudanças no ambiente de projeto, mantendo a</p><p>entrega contínua de valor para os clientes. Essa compreensão histórica e estrutural da gestão de projetos</p><p>oferecida pelo PMI e pelo PMBOK é fundamental para compreendermos as diferenças e escolhermos</p><p>efetivamente entre as metodologias tradicionais e ágeis, conforme a necessidade, aplicando a abordagem</p><p>mais adequada às características específicas de seus projetos.</p><p>No contexto da evolução das metodologias de gestão de projetos, é essencial compreendermos</p><p>como o PMI e o PMBOK se adaptaram às transformações e exigências do mercado ao longo do tempo.</p><p>Desde sua criação, o PMI tem desempenhado um papel crucial na padronização das práticas de gestão</p><p>de projetos e na capacitação de profissionais por meio de certificações como PMP. Essas certificações</p><p>são reconhecidas globalmente e atestam a competência</p><p>dos profissionais em aplicar os conhecimentos</p><p>e as habilidades necessários para gerenciar projetos de maneira eficaz e eficiente.</p><p>A abordagem tradicional de gestão de projetos, conforme delineada pelo PMBOK, é robusta e</p><p>detalhada, fornecendo um framework claro para o gerenciamento de projetos em diversas indústrias.</p><p>No entanto, com o avanço tecnológico e a rápida mudança dos requisitos do mercado, a rigidez da</p><p>metodologia em cascata começou a apresentar limitações, principalmente em ambientes que exigem</p><p>rápida adaptação e inovação constante. Em resposta a essas limitações, a comunidade de gestão de</p><p>projetos começou a explorar e adotar metodologias mais flexíveis, como as metodologias ágeis.</p><p>As metodologias ágeis, em contraste com a abordagem tradicional, priorizam a adaptabilidade e</p><p>a resposta rápida a mudanças. Elas promovem ciclos curtos de desenvolvimento, conhecidos como</p><p>sprints, e uma interação constante com os stakeholders, assegurando que o produto final atenda às</p><p>expectativas e às necessidades dos clientes. A transição para práticas ágeis não representa uma rejeição</p><p>dos princípios tradicionais de gestão de projetos, mas sim uma evolução que reconhece a necessidade</p><p>de flexibilidade em ambientes dinâmicos. O PMI, ciente dessas mudanças, incorporou elementos das</p><p>metodologias ágeis em suas diretrizes e certificações, como a PMI-ACP, refletindo a convergência e a</p><p>complementaridade das abordagens tradicionais e ágeis.</p><p>Para os gestores de projetos, a escolha entre uma abordagem tradicional ou ágil deve ser decidida</p><p>pelas características específicas do projeto e pelo contexto em que ele está inserido. Projetos com</p><p>requisitos bem definidos e estáveis podem se beneficiar da previsibilidade e do controle oferecidos</p><p>pela metodologia em cascata. Por outro lado, projetos em ambientes incertos e voláteis, especialmente</p><p>no setor de TI, podem obter maiores vantagens com a flexibilidade e a capacidade de adaptação</p><p>proporcionadas pelas práticas ágeis.</p><p>Ao entender tanto as metodologias tradicionais quanto as ágeis, os profissionais de gestão de projetos</p><p>estão melhor equipados para selecionar e aplicar a abordagem que melhor se alinha às necessidades de</p><p>seus projetos, garantindo a entrega de valor contínua e o sucesso das iniciativas. A integração dessas</p><p>metodologias, conforme promovida pelo PMI, demonstra um reconhecimento da complexidade e</p><p>diversidade dos desafios enfrentados pelos gestores de projetos na atualidade, promovendo uma prática</p><p>de gestão mais holística e adaptável.</p><p>17</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>1.2 História e princípios do Manifesto Ágil</p><p>A história do Manifesto Ágil (Bennekum et al., 2001) começa no início dos anos 2000, em um</p><p>momento em que a indústria de desenvolvimento de software enfrentava desafios significativos com as</p><p>abordagens tradicionais de gestão de projetos, como o modelo em cascata (waterfall). Essas metodologias</p><p>frequentemente resultavam em projetos atrasados, acima do orçamento e que não atendiam plenamente</p><p>às necessidades dos clientes devido à sua rigidez e falta de adaptabilidade.</p><p>Em fevereiro de 2001, um grupo de 17 desenvolvedores de software e profissionais de metodologias</p><p>alternativas se reuniu em Snowbird, Utah, para discutir formas mais eficientes e humanas de desenvolver</p><p>software. Entre os participantes do encontro que resultou no Manifesto Ágil estavam nomes influentes,</p><p>como Kent Beck, Martin Fowler, Robert C. Martin e Jeff Sutherland, que já eram conhecidos por suas</p><p>contribuições significativas ao campo do desenvolvimento de software.</p><p>Kent Beck, por exemplo, era amplamente reconhecido por seu trabalho pioneiro no Extreme</p><p>Programming (XP), uma metodologia que enfatiza a simplicidade, comunicação constante e feedback</p><p>rápido. O autor promoveu práticas como Test-Driven Development (TDD) e programação em pares, que</p><p>se tornaram pilares em ambientes de desenvolvimento ágil (Beck, 2021).</p><p>Martin Fowler, outro participante notável, é um renomado autor e pensador na área de engenharia de</p><p>software. Suas publicações, como Refactoring: improving the design of existing code (Fowler, 2018) e</p><p>Patterns of enterprise application architecture (Fowler, 2002), forneceram uma base teórica sólida para</p><p>muitas das práticas ágeis adotadas posteriormente. Fowler é conhecido por seu enfoque na melhoria</p><p>contínua do código e na arquitetura sustentável, aspectos que são cruciais para o sucesso a longo prazo</p><p>de projetos ágeis.</p><p>Robert C. Martin, também conhecido como uncle Bob, é um dos defensores mais veementes da</p><p>qualidade no desenvolvimento de software. Ele desempenhou um papel vital na formulação dos princípios</p><p>SOLID, que são diretrizes para a construção de softwares robustos e flexíveis. Martin também é autor de</p><p>livros influentes como Clean code (Martin; Feathers; Ottinger, 2008) e The clean coder (Martin, 2011),</p><p>que se tornaram leituras essenciais para desenvolvedores comprometidos com a excelência técnica e</p><p>práticas ágeis.</p><p>Por fim, temos Jeff Sutherland, cocriador do Scrum (Sutherland; Sutherland, 2014), que trouxe</p><p>para o encontro uma metodologia que transformou a maneira com a qual as equipes de software</p><p>trabalhavam. Scrum, com suas iterações curtas e foco na entrega incremental de valor, se tornou uma</p><p>das abordagens ágeis mais populares no mundo. A experiência de Sutherland na aplicação de Scrum em</p><p>projetos complexos demonstrou a eficácia da agilidade em ambientes empresariais dinâmicos e voláteis.</p><p>O resultado desse encontro foi a criação do Manifesto para desenvolvimento ágil de software,</p><p>também conhecido como Manifesto Ágil, que estabeleceu quatro valores fundamentais, como indica a</p><p>figura 1, doze princípios que visavam promover uma abordagem mais flexível, colaborativa e centrada</p><p>no cliente para o desenvolvimento de software.</p><p>18</p><p>Unidade I</p><p>Indivíduos e interações mais que processos e ferramentas</p><p>Valorizar a colaboração e comunicação direta entre pessoas sobre a aderência estrita</p><p>a processos e ferramentas</p><p>Software em funcionamento mais que documentação abrangente</p><p>Priorizar a entrega de software funcional como a principal medida de progresso</p><p>Colaboração com o cliente mais que negociação de contratos</p><p>Focar na colaboração contínua com o cliente para garantir que o produto final atenda</p><p>às suas necessidades</p><p>Responder a mudanças mais que seguir um plano</p><p>Ser flexível e adaptável às mudanças, ao invés de seguir rigidamente um plano predeterminado</p><p>Figura 1 – Os quatro valores fundamentais do Manifesto Ágil</p><p>A partir das novas diretrizes apresentadas pelo Manifesto Ágil, no mundo da gestão de projetos</p><p>e desenvolvimento de software, houve uma mudança substancial na maneira como as equipes</p><p>valorizavam  e priorizavam suas práticas e objetivos. Essa mudança enfatizou a importância das</p><p>interações humanas e a adaptação flexível aos requisitos mutáveis dos clientes em contraposição às</p><p>práticas tradicionais mais rígidas e focadas em planejamento extensivo.</p><p>Primeiramente, é inegável que a proximidade e a comunicação contínua entre colegas de equipe</p><p>são essenciais para o sucesso de qualquer projeto. A priorização dessas interações leva a uma melhor</p><p>resolução de problemas e a um ambiente de trabalho mais dinâmico e adaptável. Equipes que mantêm</p><p>comunicação constante são mais capazes de responder a desafios inesperados e de integrar novas</p><p>ideias, o que amplia a inovação e melhora a entrega de resultados.</p><p>Além disso, enquanto os requisitos documentados sempre desempenharão um papel vital na</p><p>definição de expectativas e objetivos, o foco em responder à evolução das necessidades dos clientes</p><p>mostra uma abordagem mais personalizada e orientada ao usuário final. A adaptabilidade a essas</p><p>mudanças, mesmo em estágios tardios do desenvolvimento, pode resultar em produtos que melhor</p><p>atendam às necessidades do mercado e proporcionam mais satisfação ao cliente.</p><p>Por outro lado, é preciso termos claro que a sobrevalorização de ferramentas e procedimentos</p><p>rígidos podem levar à inflexibilidade e atrasos desnecessários.</p><p>Portanto, enfatizar a funcionalidade e a</p><p>eficácia do que é entregue em detrimento de métodos burocráticos ou excessivamente tecnicistas revela</p><p>um reconhecimento de que o verdadeiro valor não está nas ferramentas utilizadas, mas nos resultados</p><p>alcançados. Essa perspectiva favorece a inovação e a eficiência ao longo do processo de desenvolvimento.</p><p>19</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Por fim, a cooperação sobre a negociação de contratos formais realça a importância de construir</p><p>parcerias de confiança entre as partes envolvidas. Priorizar uma colaboração transparente e baseada</p><p>na confiança mútua, ao invés de depender estritamente dos termos contratuais, pode conduzir</p><p>a relacionamentos mais flexíveis e a projetos mais bem-sucedidos. Tal abordagem, portanto,</p><p>promove um ambiente onde as partes se sentem mais comprometidas e envolvidas no sucesso</p><p>compartilhado do projeto.</p><p>Notamos, então, que essa reorientação de valores reflete uma adaptação às realidades do mundo</p><p>moderno, em que a velocidade da inovação e a necessidade de flexibilidade dominam o mercado. Ela</p><p>reconhece que as abordagens ágeis facilitam a gestão de projetos e fortalecem as relações humanas</p><p>e a qualidade dos produtos desenvolvidos. Além dos valores, os doze princípios do Manifesto Ágil,</p><p>dispostos a seguir, detalham práticas como entregas frequentes de softwares funcionais, aceitação</p><p>de mudanças nos requisitos, colaboração contínua com stakeholders e a construção de equipes</p><p>motivadas e auto-organizadas.</p><p>Observação</p><p>Os stakeholders, em gestão de projetos de software, são indivíduos,</p><p>grupos ou organizações que têm interesse, ou são afetados, pelas</p><p>atividades e resultados do projeto. Esses interesses podem ser diversos e</p><p>variam de acordo com o papel de cada stakeholder no projeto. Em um</p><p>projeto de software, stakeholders típicos incluem os clientes ou usuários</p><p>finais, isto é, aqueles que utilizarão o produto ou serviço desenvolvido; os</p><p>patrocinadores, que fornecem os recursos financeiros necessários para a</p><p>execução do projeto; os membros da equipe de desenvolvimento, que são</p><p>responsáveis por projetar, implementar e testar o software; e os gestores</p><p>de projeto, que coordenam as atividades e garantem que o projeto esteja</p><p>alinhado com os objetivos e prazos estabelecidos.</p><p>Além do exposto, outros stakeholders podem incluir fornecedores, que oferecem produtos ou serviços</p><p>que suportam o desenvolvimento do software; reguladores, que asseguram que o projeto esteja em</p><p>conformidade com leis e normas aplicáveis; e qualquer outro grupo ou indivíduo cuja rotina de trabalho</p><p>seja impactada direta ou indiretamente pelo software desenvolvido. Cada um desses stakeholders tem</p><p>expectativas e requisitos específicos que precisam ser considerados para o sucesso do projeto.</p><p>Por esse motivo, a identificação e a gestão adequada deles são cruciais para o andamento eficaz</p><p>de um projeto de software. Uma comunicação clara e contínua com esses agentes garante que seus</p><p>interesses sejam compreendidos e atendidos, o que, por sua vez, minimiza riscos de conflitos e facilita a</p><p>tomada de decisões informadas ao longo do ciclo de vida do projeto.</p><p>20</p><p>Unidade I</p><p>Princípios do Manifesto Ágil</p><p>•	 Tem como prioridade satisfazer o cliente através da CD e adiantada de software com valor agregado.</p><p>•	 Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.</p><p>•	 Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.</p><p>•	 Entregar frequentemente o software funcionando, de poucas semanas a poucos meses, com</p><p>preferência à menor escala de tempo.</p><p>•	 Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.</p><p>•	 Construir projetos em torno de indivíduos motivados.</p><p>• Promover o ambiente e o suporte necessário para a boa execução do trabalho.</p><p>•	 O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de</p><p>desenvolvimento é através de conversa face a face.</p><p>•	 Software funcionando é a medida primária de progresso.</p><p>•	 Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores</p><p>e usuários devem ser capazes de manter um ritmo constante indefinidamente.</p><p>•	 Contínua atenção à excelência técnica e bom design aumentam a agilidade.</p><p>•	 Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.</p><p>É importante destacarmos também que o Manifesto Ágil teve um impacto profundo na indústria.</p><p>Ele deu origem a uma família de metodologias ágeis, como Scrum, Kanban, Lean Software Development</p><p>e outras, que foram amplamente adotadas não apenas no desenvolvimento de software, mas também em</p><p>outras áreas de gestão de projetos e desenvolvimento de produtos. A abordagem ágil continua a evoluir</p><p>e influenciar práticas de gestão e desenvolvimento em diversas indústrias, promovendo um ambiente de</p><p>trabalho mais adaptável, colaborativo e centrado no cliente.</p><p>21</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>1.3 A mudança do paradigma de gestão de projetos em TI</p><p>A mudança do paradigma de gestão de projetos em TI representa uma evolução notável de métodos</p><p>tradicionais, como o cascata, para abordagens ágeis que incluem Scrum, Kanban e Lean. Essa transição</p><p>não é meramente uma mudança de técnicas, mas uma profunda reformulação nas atitudes e na cultura</p><p>das organizações.</p><p>Como vimos, inicialmente, a gestão de projetos de TI era dominada por metodologias preditivas</p><p>que enfatizavam uma sequência estrita de etapas de desenvolvimento, planejamento detalhado e</p><p>documentação extensa. Essa abordagem linear, embora oferecesse uma estrutura clara, resultava muitas</p><p>vezes em rigidez, tornando difícil adaptar-se às mudanças rápidas, comuns em projetos de tecnologia.</p><p>Em resposta às limitações desses métodos tradicionais, os métodos ágeis surgiram como soluções</p><p>flexíveis que enfatizam a entrega contínua de valor para o cliente, adaptabilidade e colaboração.</p><p>Diferentemente do planejamento extenso no início do projeto, os métodos ágeis incentivam ciclos</p><p>iterativos e incrementais de desenvolvimento, conhecidos como sprints, que permitem frequentes</p><p>ajustes de curso para melhor atender às mudanças nas necessidades dos clientes e do mercado.</p><p>A implementação dos métodos ágeis também implica uma transformação cultural dentro das</p><p>empresas. Contrariamente ao modelo cascata, que concentra a tomada de decisão no topo da hierarquia,</p><p>os métodos ágeis promovem equipes autogerenciáveis e multidisciplinares. Isso melhora a comunicação</p><p>interna, aumentando o engajamento e a responsabilidade de todos os envolvidos. Entretanto, ele pode</p><p>enfrentar desafios, especialmente em organizações grandes e estabelecidas, que podem encontrar</p><p>dificuldades para se desvincular de práticas profundamente enraizadas.</p><p>Porém, a necessidade de maior adaptabilidade e a capacidade de responder prontamente às</p><p>mudanças têm impulsionado a adoção de métodos ágeis, que têm mostrado aumentar a eficiência e a</p><p>satisfação do cliente, além de aprimorar a qualidade e a relevância dos produtos desenvolvidos em um</p><p>ambiente de tecnologia em constante evolução. Empresas como Spotify, Amazon e Google ilustram essa</p><p>transição com sucesso.</p><p>O Spotify, por exemplo, desenvolveu o Modelo Spotify, que organiza as equipes em esquadrões</p><p>(squads) que operam de forma autônoma dentro de tribos, promovendo alinhamento estratégico,</p><p>enquanto guildas e capítulos facilitam a disseminação de conhecimento técnico e melhores práticas.</p><p>A Amazon, por sua vez, adota o princípio dos Two Pizza Teams, que suporta equipes pequenas e</p><p>ágeis, e a Google fomenta uma cultura de inovação e colaboração, permitindo às equipes adaptar</p><p>seus métodos de trabalho conforme necessário, o que potencializa a produtividade e a criatividade.</p><p>O conceito de Two Pizza Teams é uma estratégia de gestão e organização de equipes introduzida por</p><p>Jeff Bezos, CEO da Amazon. A ideia por trás dessa abordagem é que cada equipe deve ser pequena o</p><p>suficiente para ser alimentada por duas pizzas.</p><p>O princípio</p><p>subjacente é que equipes menores fomentam mais eficiência, comunicação mais efetiva e</p><p>tomada de decisão mais ágil. A lógica de manter as equipes pequenas é que isso limita a complexidade de</p><p>22</p><p>Unidade I</p><p>gestão. Equipes menores tendem a ter menos burocracia e menor número de linhas de comunicação, o que</p><p>significa que cada membro da equipe pode ter um papel mais significativo e participativo. Isso também</p><p>aumenta a agilidade da equipe em desenvolver e implementar soluções e a satisfação e motivação dos</p><p>membros, uma vez que eles se sentem mais diretamente envolvidos nos resultados e sucesso do grupo.</p><p>Além disso, é interessante observarmos que o modelo Two Pizza Teams facilita uma cultura  de</p><p>autonomia e inovação. Por serem pequenas, essas equipes têm mais liberdade para experimentar e</p><p>adaptar métodos de trabalho que melhor atendam às suas necessidades específicas, sem esperar por</p><p>aprovações de múltiplas camadas de gestão. Essa estrutura de equipe é vista como uma resposta direta</p><p>aos desafios de gerenciar grandes organizações, particularmente aquelas que operam em setores</p><p>de rápida evolução, como a tecnologia e a internet.</p><p>É praticamente impossível estimar o número de projetos ágeis atualmente em andamento nas</p><p>empresas, mas podemos fazer um exercício hipotético para ilustrar, de modo didático, a transição do</p><p>modelo de projetos tradicional para o ágil. As informações da figura a seguir são estimativas baseadas</p><p>em tendências observadas na indústria de TI.</p><p>100</p><p>90</p><p>80</p><p>70</p><p>60</p><p>50</p><p>40</p><p>30</p><p>20</p><p>10</p><p>0</p><p>1980-1989 1990-1999 2000-2009 2010-2019 2020-atual</p><p>Figura 2 – Mudança de paradigma em gestão de projetos</p><p>Considerando a figura apresentada, temos, no eixo vertical, o percentual de projetos e no eixo</p><p>horizontal as décadas de 1980 a 2020. As barras em vermelho representam os projetos tradicionais</p><p>e as barras em azul representam os projetos ágeis. Notemos que os percentuais de projetos ágeis têm</p><p>aumentado ao longo das décadas.</p><p>A distribuição entre métodos ágeis e tradicionais pode variar de acordo com o setor, a cultura</p><p>empresarial e a natureza específica dos projetos de TI, mas a tendência geral é clara: uma crescente</p><p>preferência por abordagens ágeis. Analisemos, então, os aspectos históricos a seguir. Eles foram</p><p>considerados para a elaboração da figura apresentada anteriormente.</p><p>23</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>1980-1989</p><p>Durante a década de 1980, a maioria dos projetos de TI seguia modelos</p><p>de desenvolvimento tradicionais, como o modelo em cascata. Métodos</p><p>ágeis eram praticamente desconhecidos ou raramente adotados</p><p>2000-2009</p><p>O Manifesto Ágil, publicado em 2001, teve um grande impacto nesta</p><p>década, promovendo uma substancial adoção de práticas ágeis, como</p><p>Scrum, Extreme Programming (XP) e Lean. Os métodos tradicionais</p><p>ainda eram dominantes, mas cada vez mais dividiam espaço com</p><p>abordagens ágeis</p><p>2010-2019</p><p>Esta década viu uma ampla aceitação dos métodos ágeis nas empresas,</p><p>especialmente nas indústrias de tecnologia e software. O desenvolvimento</p><p>ágil tornou-se uma prática dominante em muitos setores, principalmente</p><p>devido à sua flexibilidade e eficiência em responder a mudanças</p><p>2020-atual</p><p>Atualmente, os métodos ágeis são a norma em grande parte dos projetos</p><p>de desenvolvimento de software. As organizações continuam a adotar</p><p>essas práticas para se beneficiar de ciclos de desenvolvimento mais</p><p>rápidos e de maior colaboração e adaptabilidade</p><p>1990-1999</p><p>A divulgação do Manifesto Ágil em 2001 está fora desta faixa de</p><p>tempo, mas preparativos e discussões sobre métodos ágeis, bem como</p><p>o aumento do uso de prototipagem rápida, marcaram o crescimento do</p><p>interesse pelos métodos ágeis no final dos anos 1990</p><p>Figura 3 – Contexto considerado nas estimativas da transição</p><p>A preferência crescente pelas metodologias ágeis sobre as tradicionais em projetos de TI está</p><p>enraizada nas características dinâmicas do setor tecnológico. Na medida em que o ambiente de</p><p>tecnologia passou a evoluir de maneira acelerada, as empresas encontraram nos métodos ágeis uma</p><p>forma eficaz de lidar com a necessidade constante de ajustes rápidos e eficientes. Esta abordagem</p><p>permite uma adaptação contínua às mudanças, favorecendo a inovação e a competitividade.</p><p>Por sua natureza, os métodos ágeis focam na colaboração intensiva, na iteração regular e na CD</p><p>de partes funcionais do projeto, o que oferece várias oportunidades para ajustar o produto final às</p><p>expectativas e necessidades do cliente. Essa flexibilidade é menos presente nos métodos tradicionais,</p><p>que geralmente seguem um caminho linear e predefinido, com menos espaço para mudanças depois que</p><p>o projeto já está em desenvolvimento.</p><p>24</p><p>Unidade I</p><p>Outra razão importante para a ascensão dos métodos ágeis é a mudança nas expectativas dos</p><p>consumidores. Hoje, os clientes esperam soluções mais rápidas, personalizadas e que evoluam de</p><p>acordo  com suas demandas. Os métodos ágeis, com seu ciclo de feedback constante e colaboração</p><p>próxima com o cliente, estão melhor equipados para atender a essas expectativas. Sem contar que a</p><p>cultura de trabalho também desempenha um papel importante. Os métodos ágeis muitas vezes promovem</p><p>um ambiente de trabalho mais aberto e flexível, que pode aumentar a satisfação e a produtividade</p><p>dos colaboradores. Essa cultura colaborativa e adaptável atrai e retém talentos, especialmente em um</p><p>mercado de trabalho que cada vez mais valoriza a flexibilidade e o desenvolvimento contínuo.</p><p>Compreendemos, assim, que tais mudanças no ambiente de negócios e tecnologia convergiram para</p><p>fazer dos métodos ágeis a escolha predominante para muitas organizações que buscam não apenas</p><p>sobreviver, mas prosperar em um mercado em constante transformação.</p><p>1.4 Visão geral dos frameworks ágeis: Scrum, Kanban e XP (Extreme</p><p>Programming)</p><p>Frameworks ágeis são metodologias, ou abordagens, estruturadas para a gestão de projetos, focadas</p><p>em flexibilidade, colaboração, entrega contínua de valor e capacidade de adaptação rápida às mudanças.</p><p>Eles fornecem uma série de práticas, princípios e processos que ajudam as equipes a trabalhar de modo</p><p>mais eficiente e eficaz, especialmente em ambientes de desenvolvimento de software. Esses frameworks</p><p>são baseados nos princípios do Manifesto Ágil, que enfatizam a importância de interações humanas,</p><p>software funcional, colaboração com o cliente e resposta a mudanças.</p><p>O framework Scrum é uma metodologia ágil projetada para otimizar o desenvolvimento de</p><p>produtos, particularmente o de softwares. Este framework foi concebido para ser altamente flexível</p><p>e adaptável, possibilitando às equipes lidar com a complexidade e as mudanças inerentes ao</p><p>desenvolvimento de produtos. Ideal para projetos em que os requisitos são incertos, ou sujeitos a</p><p>alterações frequentes, o Scrum facilita uma colaboração eficaz, enquanto entrega produtos de alto</p><p>valor de maneira iterativa e incremental.</p><p>Scrum é construído em torno de sprints, que são ciclos de desenvolvimento de curta duração e,</p><p>geralmente, duram de duas a quatro semanas. Durante um sprint, a equipe trabalha para completar</p><p>um conjunto de funcionalidades definidas e concordadas anteriormente. Essas funcionalidades são</p><p>escolhidas de uma lista maior chamada Product Backlog, que é uma compilação de todos os trabalhos</p><p>ou funcionalidades desejadas no produto final.</p><p>O processo começa com o Sprint Planning Meeting, uma sessão de planejamento na qual a equipe</p><p>de Scrum, incluindo o Product Owner, o Scrum Master e o Development Team, discutem e selecionam as</p><p>tarefas do Product Backlog que serão realizadas no sprint. O Product Owner é responsável por definir</p><p>as prioridades do Product Backlog, garantindo que a equipe esteja trabalhando nas funcionalidades que</p><p>oferecem o maior valor ao negócio. Já o Scrum Master atua como um facilitador e guardião dos princípios</p><p>Scrum, ajudando a equipe a resolver impedimentos e a seguir as práticas Scrum adequadamente.</p><p>25</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Após a reunião de planejamento, inicia-se o sprint. Durante</p><p>esse período, a equipe realiza Daily</p><p>Scrums, ou Stand-up Meetings, que são reuniões diárias e curtas, em que cada membro da equipe</p><p>relata o que fez desde o último encontro, o que planeja fazer a seguir e quaisquer obstáculos que</p><p>estejam impedindo seu progresso. Essas reuniões são essenciais para manter todos na equipe alinhados</p><p>e focados nos objetivos do sprint.</p><p>Ao final de cada sprint, a equipe realiza duas sessões importantes: a Sprint Review e a Sprint</p><p>Retrospective. Na Sprint Review, a equipe demonstra o que foi desenvolvido durante o sprint para o</p><p>Product Owner e outras partes interessadas. Esta é uma oportunidade para receber feedback e fazer</p><p>ajustes necessários ao produto. Na Sprint Retrospective, a equipe reflete sobre o sprint que terminou,</p><p>discutindo o que funcionou bem, o que poderia ser melhorado e como podem melhorar ainda mais os</p><p>processos no próximo sprint.</p><p>O Scrum enfatiza a importância de entregas frequentes de partes do produto que são totalmente</p><p>funcionais e prontas para o mercado, conhecidas como Increments. Isso permite que as organizações se</p><p>adaptem rapidamente às mudanças no mercado e às necessidades dos clientes, além de proporcionar</p><p>uma sensação de realização contínua à equipe, ao ver seu trabalho contribuir de modo significativo para</p><p>o sucesso do produto. Em essência, Scrum é mais do que apenas um método para gerenciar projetos, é</p><p>uma maneira de pensar e colaborar. Ele promove uma cultura de transparência, inspeção e adaptação,</p><p>em que as equipes trabalham juntas para atingir metas comuns de maneira eficiente e eficaz, mesmo</p><p>em ambientes altamente variáveis e desafiadores.</p><p>O Kanban, por sua vez, é uma metodologia de gestão de projetos que se originou no sistema de</p><p>produção Just-In-Time da Toyota. Ela foi desenvolvida para aumentar a eficiência, ao limitar o trabalho</p><p>em progresso, e focar na CD. Embora comumente associado ao desenvolvimento de software, o Kanban</p><p>pode ser utilizado em qualquer processo que exija gestão de fluxo de trabalho, sendo uma ferramenta</p><p>versátil e eficaz para diversas áreas.</p><p>A essência do Kanban está em seu quadro visual, conhecido como Kanban Board, que representa os</p><p>diferentes estágios do processo de trabalho. Este quadro é tipicamente dividido em várias colunas, cada</p><p>uma simbolizando um passo específico do fluxo de trabalho. Os itens de trabalho são representados</p><p>por cartões que são movidos de uma coluna para outra, oferecendo uma visão clara do progresso de</p><p>cada tarefa.</p><p>Essa visualização não só aumenta a transparência sobre o status do trabalho para toda a equipe, como</p><p>destaca gargalos e problemas no fluxo de trabalho, permitindo abordagens imediatas para resolução e</p><p>melhoria. O Kanban enfatiza a importância de visualizar todo o trabalho em curso para que todos na</p><p>equipe possam compreender claramente o andamento do projeto. Ao mesmo tempo, a metodologia</p><p>preconiza a limitação do trabalho em progresso, estabelecendo restrições sobre quantas tarefas podem</p><p>estar em cada estágio do processo simultaneamente. Esta prática ajuda a evitar sobrecargas em qualquer</p><p>parte do processo e garante que a equipe concentre seus esforços em finalizar tarefas existentes antes</p><p>de assumir novas, resultando em um fluxo de trabalho mais coerente e eficiente.</p><p>26</p><p>Unidade I</p><p>Outro aspecto fundamental do Kanban é a gestão do fluxo, que envolve monitorar e ajustar</p><p>continuamente o fluxo de trabalho para assegurar que as tarefas se movam de maneira eficaz através</p><p>do quadro Kanban. Isso envolve identificar e resolver paradas e gargalos, utilizando a análise do</p><p>fluxo  de trabalho para realizar adaptações contínuas que visam aprimorar a eficiência. A melhoria</p><p>contínua é um princípio central no Kanban, exigindo que as equipes estejam sempre em busca de</p><p>maneiras de aperfeiçoar o processo de trabalho. Regularmente, revisões do desempenho do fluxo e das</p><p>práticas são conduzidas para descobrir oportunidades de refinamento. Essas revisões fomentam uma</p><p>cultura de inovação e aprimoramento, na qual o feedback constante e a capacidade de adaptar-se a</p><p>novas informações são valorizados.</p><p>Diferentemente do Scrum, que se organiza em ciclos fixos chamados sprints, Kanban oferece</p><p>mais flexibilidade, permitindo que as tarefas sejam priorizadas e realocadas com facilidade conforme</p><p>as necessidades evoluem. Isso torna o Kanban particularmente adequado para ambientes nos quais</p><p>os requisitos podem mudar rapidamente ou nos quais é desafiador estimar o volume de trabalho de</p><p>maneira precisa.</p><p>O Kanban também promove a colaboração contínua entre os membros da equipe, com reuniões</p><p>regulares que servem para discutir o progresso, identificar obstáculos e reavaliar prioridades. Essas</p><p>interações mantêm todos os membros alinhados e engajados, criando um ambiente de trabalho coeso e</p><p>produtivo. Em resumo, o Kanban é mais do que uma ferramenta para gerenciar fluxos de trabalho, é uma</p><p>filosofia que encoraja a transparência, a colaboração e a eficiência, ajudando as equipes a adaptar-se a</p><p>mudanças e a maximizar sua produtividade de maneira organizada e efetiva.</p><p>Por fim, temos o Extreme Programming (XP), que é uma metodologia de desenvolvimento de software</p><p>que enfatiza a excelência técnica e a alta capacidade de resposta às mudanças nas demandas do cliente.</p><p>A XP foi uma das primeiras metodologias ágeis a serem desenvolvidas e é caracterizada por seu foco nas</p><p>práticas de engenharia de software, trabalho em equipe e eficiência. Ela é ideal para projetos em constante</p><p>mudança, devido à sua adaptabilidade e abordagem proativa no tratamento de requisitos de clientes e de</p><p>qualidade de software. Em seu núcleo está a crença de que as mudanças nos requisitos de negócios são</p><p>naturais e inevitáveis, portanto, sua metodologia é projetada para facilitar essas mudanças, mesmo nos</p><p>estágios tardios do desenvolvimento.</p><p>O XP propõe a melhoria contínua de software e de práticas de desenvolvimento através de ciclos</p><p>curtos de lançamentos, o que incrementa a eficácia e a produtividade. A comunicação frequente e</p><p>clara entre todos os membros da equipe e entre a equipe e o cliente é outro ponto importante do</p><p>XP. A comunicação aberta ajuda a equipe a entender profundamente as necessidades do cliente e a</p><p>responder rapidamente a qualquer mudança. Em XP, espera-se que os desenvolvedores trabalhem em</p><p>proximidade, ou até mesmo em pares, revisando e discutindo constantemente o código uns dos outros</p><p>para detectar erros precocemente e compartilhar conhecimento sobre o código e sobre as práticas</p><p>de desenvolvimento.</p><p>27</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Uma prática distintiva do XP é justamente a programação em par, na qual dois programadores</p><p>trabalham juntos em um único computador, um escrevendo o código e o outro revisando cada linha</p><p>de código conforme é escrita. Essa técnica melhora a qualidade do software ao permitir que erros</p><p>sejam identificados e corrigidos rapidamente, além de promover a partilha de conhecimento entre os</p><p>membros da equipe. A programação em par é complementada por TDD, os quais são escritos antes do</p><p>código que deverá passar pelos testes. Esta abordagem assegura que o código desenvolvido seja robusto</p><p>e confiável desde o início.</p><p>Além disso, o XP promove a entrega frequente de valor ao cliente, com lançamentos de softwares</p><p>funcionais e revisados em ciclos curtos. Isso maximiza a satisfação do cliente ao demonstrar progresso</p><p>tangível e também permite que a equipe receba feedback regularmente, que pode ser imediatamente</p><p>incorporado no ciclo de desenvolvimento. O feedback contínuo é crucial para orientar o desenvolvimento</p><p>e assegurar que o produto final atenda às expectativas e necessidades do cliente. O XP também</p><p>enfatiza a simplicidade na codificação, incentivando soluções simples e elegantes que fazem apenas</p><p>o que é necessário e nada mais. Este foco na simplicidade ajuda a reduzir a complexidade do software,</p><p>facilita a manutenção e a expansão futuras, além de promover a eficiência no desenvolvimento.</p><p>Compreendemos, então, que o XP reconhece</p><p>a importância do bem-estar da equipe, promovendo</p><p>um ritmo sustentável de trabalho. Ao evitar horas extras de trabalho e enfatizar a relevância de uma</p><p>vida profissional equilibrada, o XP busca manter a equipe motivada, produtiva e focada em entregar</p><p>alta qualidade no trabalho. Assim, o Extreme Programming é uma metodologia poderosa que molda</p><p>o produto de software e o ambiente de trabalho, criando uma dinâmica de equipe que é ao mesmo</p><p>tempo eficaz e sustentável. Ele continua a ser um dos modelos ágeis mais respeitados e implementados,</p><p>oferecendo estruturas robustas para enfrentar os desafios de um ambiente de desenvolvimento de</p><p>software dinâmico.</p><p>1.5 Comparação entre os frameworks ágeis</p><p>Existem diversos frameworks ágeis, cada um com características e objetivos específicos. Destacamos,</p><p>então, brevemente os principais deles, que são reconhecidos e amplamente utilizados na indústria.</p><p>•	 Scrum: é um framework amplamente usado que organiza o trabalho em sprints, ciclos</p><p>de 2-4  semanas, e define papéis claros como Scrum Master, Product Owner e a equipe</p><p>de desenvolvimento.</p><p>•	 Kanban: foca na visualização do trabalho e na limitação de trabalho em progresso (work in</p><p>progress – WIP), ajudando as equipes a melhorarem continuamente o fluxo de trabalho.</p><p>•	 Lean: é originário da manufatura, busca eliminar desperdícios, otimizar processos e entregar valor</p><p>continuamente ao cliente.</p><p>•	 Extreme Programming (XP): enfatiza práticas como desenvolvimento orientado a testes (TDD),</p><p>programação em pares e feedback contínuo do cliente para melhorar a qualidade do software.</p><p>28</p><p>Unidade I</p><p>•	 Dynamic Systems Development Method (DSDM): prioriza entregas rápidas e frequentes,</p><p>com foco no alinhamento constante com os objetivos de negócios e na flexibilidade para</p><p>mudanças de escopo.</p><p>•	 Feature-Driven Development (FDD): divide o projeto em funcionalidades, com desenvolvimento</p><p>iterativo e incremental, focando em entregas baseadas em features.</p><p>•	 Crystal: é adaptável e centrado em pessoas, variando conforme o tamanho da equipe e criticidade</p><p>do projeto, com foco em comunicação e feedback contínuo.</p><p>•	 Scaled Agile Framework (SAFe): é escalável para grandes organizações, integrando princípios</p><p>Lean e Agile, com uma estrutura organizacional clara e cerimônias definidas.</p><p>•	 Large-Scale Scrum (LeSS): é uma extensão do Scrum para grandes projetos, mantendo a</p><p>simplicidade e evitando a complexidade excessiva.</p><p>•	 Nexus: é uma extensão do Scrum para escalar em grandes projetos, com o Nexus Integration</p><p>Team para coordenar múltiplas equipes.</p><p>•	 Disciplined Agile (DA): é um framework híbrido e flexível que integra várias práticas ágeis e Lean,</p><p>focando em agilidade empresarial e flexibilidade organizacional.</p><p>Além dos frameworks ágeis, que são estruturas organizadas e detalhadas, existem métodos ágeis</p><p>que são abordagens e práticas utilizadas para implementar os princípios ágeis em projetos. Dentre os</p><p>principais, estão: Agile Unified Process (AUP), Rapid Application Development (RAD) e Adaptive Software</p><p>Development (ASD).</p><p>Os frameworks ágeis oferecem diferentes abordagens para a gestão de projetos e a escolha do</p><p>mais adequado depende das necessidades específicas do projeto, da equipe e da organização. Scrum</p><p>e Kanban são amplamente utilizados devido à sua simplicidade e flexibilidade, enquanto frameworks</p><p>como SAFe e LeSS são escolhidos para escalar práticas ágeis em grandes organizações. XP e DSDM são</p><p>apropriados para ambientes que valorizam a qualidade e a entrega rápida de valor, respectivamente.</p><p>Por fim, Crystal, DA e Nexus oferecem abordagens adaptativas e escaláveis, atendendo a diversas</p><p>necessidades organizacionais.</p><p>O quadro a seguir organiza e compara os diferentes frameworks. É importante conhecê-los tendo</p><p>em mente que a maioria dos projetos utiliza basicamente os três principais, já citados anteriormente.</p><p>Analisemos o quadro 1.</p><p>29</p><p>GERENCIAMENTO DE PROJETOS DE SOFTWARE</p><p>Quadro 1 – Comparativo de frameworks ágeis</p><p>Framework Características Quando usar Exemplos de aplicação</p><p>Scrum</p><p>Framework estruturado e dividido em</p><p>sprints de 2-4 semanas</p><p>Papéis definidos (Scrum Master, Product</p><p>Owner, Team)</p><p>Reuniões diárias (Daily Stand-ups)</p><p>Revisões e retrospectivas ao final de</p><p>cada Sprint</p><p>Projetos complexos e dinâmicos</p><p>Quando há necessidade de</p><p>entregas frequentes</p><p>Equipes pequenas e</p><p>multifuncionais+</p><p>Desenvolvimento de</p><p>software, projetos de TI,</p><p>marketing digital</p><p>Kanban</p><p>Visualização do trabalho em um</p><p>quadro Kanban</p><p>Limite de trabalho em progresso (WIP)</p><p>Foco em melhorar continuamente o fluxo</p><p>de trabalho</p><p>Flexibilidade para adicionar ou</p><p>remover tarefas</p><p>Projetos com fluxos de</p><p>trabalho contínuos</p><p>Quando há necessidade</p><p>de flexibilidade+</p><p>Equipes que precisam gerenciar</p><p>o fluxo de trabalho e melhorar</p><p>a eficiência</p><p>Suporte técnico,</p><p>manutenção de</p><p>sistemas, operações</p><p>Lean</p><p>Foco na eliminação de desperdícios</p><p>Melhoria contínua (Kaizen)</p><p>Entrega rápida de valor</p><p>Uso eficiente de recursos</p><p>Processos de produção e</p><p>manufatura</p><p>Empresas buscando aumentar a</p><p>eficiência e reduzir custos</p><p>Projetos que necessitam de</p><p>entregas rápidas e frequentes</p><p>Indústria automotiva,</p><p>manufatura,</p><p>desenvolvimento</p><p>de produtos</p><p>XP (Extreme</p><p>Programming)</p><p>Entregas frequentes de pequenas releases</p><p>Desenvolvimento orientado a testes (TDD)</p><p>Programação em pares</p><p>Revisões de código constantes</p><p>Feedback contínuo do cliente</p><p>Projetos que demandam alta</p><p>qualidade de código</p><p>Ambientes nos quais mudanças</p><p>são frequentes</p><p>Equipes que valorizam a</p><p>colaboração e a melhoria contínua</p><p>Desenvolvimento de</p><p>software, startups de</p><p>tecnologia, projetos com</p><p>requisitos instáveis</p><p>DSDM</p><p>(Dynamic</p><p>Systems</p><p>Development</p><p>Method)</p><p>Foco em entregas rápidas e frequentes</p><p>Priorização baseada em valor de negócio</p><p>Flexibilidade para mudanças de escopo</p><p>Envolvimento ativo dos stakeholders</p><p>Projetos que requerem</p><p>entregas rápidas</p><p>Necessidade de alinhamento</p><p>constante com o negócio</p><p>Ambientes onde a entrega de valor</p><p>constante é essencial</p><p>Desenvolvimento de</p><p>sistemas de negócios,</p><p>projetos de TI em</p><p>grandes empresas,</p><p>desenvolvimento de</p><p>aplicativos</p><p>FDD</p><p>(Feature-Driven</p><p>Development)</p><p>Divisão do projeto em funcionalidades</p><p>Desenvolvimento iterativo e incremental</p><p>Entregas baseadas em features</p><p>Modelagem inicial extensa</p><p>Projetos grandes e complexos</p><p>Equipes grandes</p><p>Quando há necessidade de</p><p>entregas contínuas e incrementais</p><p>Desenvolvimento de</p><p>sistemas empresariais,</p><p>grandes projetos de</p><p>software, projetos com</p><p>muitos stakeholders</p><p>Crystal</p><p>Adaptável e centrado em pessoas</p><p>Variações baseadas no tamanho da equipe</p><p>e criticidade do projeto (Crystal Clear,</p><p>Crystal Red, Crystal Orange etc.)</p><p>Foco em comunicação e feedback contínuo</p><p>Projetos que variam em tamanho</p><p>e complexidade</p><p>Quando a comunicação é chave</p><p>para o sucesso</p><p>Equipes que necessitam de</p><p>flexibilidade em práticas</p><p>e processos</p><p>Desenvolvimento de</p><p>software, projetos</p><p>de consultoria,</p><p>ambientes variados</p><p>SAFe (Scaled</p><p>Agile</p><p>Framework)</p><p>Framework escalável para</p><p>grandes organizações</p><p>Integração de princípios Lean e Agile</p><p>Estrutura organizacional clara (equipes,</p><p>programas, portfólios)</p><p>Cerimônias e eventos definidos</p><p>Grandes empresas e</p><p>projetos complexos</p><p>Necessidade de coordenação entre</p><p>múltiplas equipes ágeis</p><p>Ambientes que requerem</p><p>alinhamento estratégico</p><p>e operacional</p><p>Indústrias de TI, grandes</p><p>empresas de manufatura,</p><p>projetos governamentais</p><p>30</p><p>Unidade I</p><p>Framework Características Quando usar Exemplos de aplicação</p><p>LeSS</p><p>(Large-Scale</p><p>Scrum)</p><p>Extensão do Scrum para grandes projetos</p><p>Múltiplas equipes Scrum</p><p>trabalhando juntas</p><p>Foco em manter a simplicidade e evitar a</p><p>complexidade excessiva</p><p>Grandes projetos Scrum</p><p>Quando há necessidade de</p><p>coordenação entre várias equipes</p><p>Organizações que já utilizam</p><p>Scrum com sucesso</p><p>Desenvolvimento de</p><p>software em grandes</p><p>organizações, projetos de</p><p>TI amplos</p><p>Nexus</p><p>Extensão do Scrum para escalar em</p><p>grandes projetos</p><p>Nexus Integration Team para coordenar</p><p>múltiplas equipes</p><p>Framework leve e focado na integração</p><p>Projetos que utilizam Scrum e</p><p>precisam escalar</p><p>Quando há necessidade</p>