Gerenciando Projetos Ágeis por Sprints

Gerenciando Projetos Ágeis por Sprints Gestão de Times Métodos Ágeis Diretor Executivo DAVID LIRA STEPHEN BARROS Gerente Editorial ALESSANDRA VANESSA FERREIRA DOS SANTOS Projeto Gráfico TIAGO DA ROCHA Autoria LUIZ GUSTAVO REZENDE MOTTA AUTORIA Luiz Gustavo Rezende Motta Olá Sou graduado em Ciência da Computação e tenho experiência técnicoprofissional de mais de 10 anos na área de Gestão de Projetos Passei por empresas como Unimed Benner e Postal Saúde Sou apaixonado pelo que faço e adoro transmitir minha experiência de vida àqueles que estão iniciando em suas profissões por isso fui convidado pela Editora Telesapiens a integrar seu elenco de autores independentes Estou muito feliz em poder ajudar você nesta fase de muito estudo e trabalho Conte comigo ICONOGRÁFICOS Olá Esses ícones irão aparecer em sua trilha de aprendizagem toda vez que OBJETIVO para o início do desenvolvimento de uma nova competência DEFINIÇÃO houver necessidade de apresentar um novo conceito NOTA quando necessárias observações ou complementações para o seu conhecimento IMPORTANTE as observações escritas tiveram que ser priorizadas para você EXPLICANDO MELHOR algo precisa ser melhor explicado ou detalhado VOCÊ SABIA curiosidades e indagações lúdicas sobre o tema em estudo se forem necessárias SAIBA MAIS textos referências bibliográficas e links para aprofundamento do seu conhecimento REFLITA se houver a necessidade de chamar a atenção sobre algo a ser refletido ou discutido ACESSE se for preciso acessar um ou mais sites para fazer download assistir vídeos ler textos ouvir podcast RESUMINDO quando for preciso fazer um resumo acumulativo das últimas abordagens ATIVIDADES quando alguma atividade de autoaprendizagem for aplicada TESTANDO quando uma competência for concluída e questões forem explicadas SUMÁRIO A Sprint e seu Planejamento 12 Sprint Planning Meeting 15 Como Fazer a Sprint Planning Meeting 15 O que Será Desenvolvido na Sprint 16 Como Será Desenvolvido 18 Alinhamento 20 Duração 21 Trabalho 21 Técnicas de Reunião no Método SCRUM 23 Qual a Importância do Daily SCRUM 24 Regras Básicas do Daily SCRUM 25 Duração Máxima de 15 Minutos 25 Mesmo Local e Horário Todos os Dias 25 O SCRUM Master Organiza Mas o Time SCRUM é que Conduz a Reunião Diária 26 O que é Preciso para o Daily SCRUM 26 Roteiro Passo a Passo 27 Sprint Review 29 Reunião de Revisão da Sprint 30 Objetivos 30 Quem Deve Participar da Reunião 32 Ao Final da Reunião O que se Espera 32 Importância do Review 33 Sprint Retrospective 36 Efetividade da Sprint Retrospective 38 Excelente SCRUM Master Excelente Retrospectiva 38 Faça o Sprint Retrospective em um Momento Auspicioso 38 O Corpo Fala 39 Presença Obrigatória do Product Owner 39 Não Buscar Culpados 40 Checar e Atuar 41 Faça a Sprint Retrospective 42 Todos têm Algo Importante a Dizer 42 Música dá o Tom no Ambiente 42 Fluxo de Facilitação na Sprint Retrospective 43 Foco nas Três Perguntas 43 O SCRUM Master é uma Pessoa 43 9 UNIDADE 03 Gestão de Times Métodos Ágeis 10 INTRODUÇÃO O objetivo dos eventos no SCRUM é proporcionar maior controle sobre o processo adquirir uma rotina de trabalho e aumentar a transparência no decorrer do desenvolvimento Os eventos SCRUM são timeboxed ou seja têm uma duração máxima definida Não se pode garantir o sucesso de um projeto com o uso do SCRUM deixando de incluir qualquer um dos seus eventos que são sprint sprint planning meeting a daily SCRUM meeting a sprint review e a sprint retrospective Eventos prescritos são usados no SCRUM para criar uma rotina e minimizar a necessidade de encontros não definidos Os eventos timeboxed garantem uma quantidade apropriada de tempo gasto em planejamento sem permitir perdas no processo Além da própria sprint que é um container para outros eventos cada evento no SCRUM é uma oportunidade para inspecionar e adaptar algo Esses eventos são projetados especificamente para permitir transparência e inspeção Ao longo desta unidade letiva veremos estes conceitos Gestão de Times Métodos Ágeis 11 OBJETIVOS Olá Seja muito bemvindo à Unidade 3 Gerenciando projetos ágeis por sprints Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos 1 Definir cada sprint atividade de um projeto SCRUM bem como a forma de planejamento de cada um 2 Conduzir uma reunião de time SCRUM de forma produtiva 3 Aplicar técnicas de revisão nas sprints de um projeto SCRUM 4 Desenvolver a retrospectiva das sprints em um projeto SCRUM Gestão de Times Métodos Ágeis 12 A Sprint e seu Planejamento OBJETIVO Ao término deste capítulo você será capaz de definir o conceito e a forma de planejamento de cada sprint atividade de um projeto SCRUM Isto será fundamental para o exercício de sua profissão Motivado para desenvolver esta competência Então vamos lá Avante A sprint é o principal evento do SCRUM Significa em tradução literal corrida de velocidade ou arrancada Tratase de um ciclo de desenvolvimento iteração que tem um tempo determinado com dia para começar e acabar Esse tempo pode variar de duas a quatro semanas mas nunca exceder 30 dias Uma sprint começa ao final da sprint anterior sem intervalos O objetivo desse evento é transformar os itens do backlog do produto funcionalidades descritas em um software ou parte dele totalmente funcional e pronto para uso Figura 1 Imagem alusiva à organização de sprint Fonte Pixabay Gestão de Times Métodos Ágeis 13 O tempo da sprint sempre será definido em dias corridos considerar finais de semana e feriados Deve ter duração de duas semanas 14 dias corridos a quatro semanas 30 dias corridos Uma duração menor do que 14 dias ainda que possível não é recomendável pois esse prazo pode ser insuficiente para a entrega do software Em contrapartida uma duração superior a 30 dias pode aumentar consideravelmente o risco pois nesse período requisitos e prioridades poderão ser alterados o tempo para obter um feedback do cliente é muito longo e consequentemente a chance de erros inconsistências e inaderências com o cliente são maiores Recomendase também que a duração seja constante do início ao fim do projeto Manter a duração da sprint definida no início do projeto até a finalização de todo o backlog facilitará o processo de calcular a velocidade do time e o tempo das liberações para produção Outra recomendação envolve a adoção de sprints maiores para times mais novos no SCRUM por exemplo 30 dias pois assim o time terá mais tempo para se adequar às regras do SCRUM e um tempo maior para entregar o que foi selecionado para a sprint Conforme o time ganha maturidade esse tempo pode ser reduzido para três semanas em seguida para duas semanas tornando as entregas mais constantes Um produto completo poderá ter inúmeras sprints quantas forem necessárias até que o backlog do produto seja finalizado Ao final de cada sprint é liberado um software ou parte dele pronto para o uso Isso não quer dizer porém a liberação de uma versão final que irá para a produção Isso pode soar estranho pois se já está pronto por qual razão não poderá ir para a produção Em empresas menores normalmente startups a tendência é que ao final de cada sprint seja realizado um deploy em produção Contudo em empresas maiores ou com arquitetura mais robusta isso não é possível pois existem períodos de atualização que não podem ocorrer a qualquer momento É normal então que nos casos de atualizações periódicas as sprints sejam programadas de forma a atender a esse calendário de atualização Note que isso não impede a entrega de parte da solução pronta e funcional em um ambiente de testes ou de treinamento Gestão de Times Métodos Ágeis 14 Exemplificando melhor supondo que estamos desenvolvendo uma solução para um cliente na qual a versão dos sistemas é atualizada somente a cada três meses o desenvolvimento completo da solução irá levar pela estimativa inicial seis meses Nessa situação podemos ter o seguinte planejamento SPRINTS DE 30 DIAS CADA 6 MESES PARA ENTREGA DA SOLUÇÃO PLANEJAR AS LIBERAÇÕES PARA PRODUÇÃO RELEASES A CADA 3 SprintS 3 MESES A cada 30 dias parte do software incremento é liberada em um ambiente de testes para que o cliente possa ter contato com o sistema e avaliar sua conformidade Além disso a cada 30 dias o cliente poderá redefinir a prioridade dos itens do backlog do produto que deseja ter na primeira release liberação que irá para produção Por alguns acreditarem que a cada final de sprint o produto deve ir para produção é que fica a dúvida o SCRUM serve para grandes projetos em grandes corporações A resposta é positiva Realizar entregas de forma incremental e iterativa entregando parte da solução rapidamente para avaliar a conformidade a aderência e afastar mudanças no caminho é uma prática positiva DEFINIÇÃO Deploy significa colocar em posição O termo é utilizado quando queremos disponibilizar um sistema para uso Gestão de Times Métodos Ágeis 15 Sprint Planning Meeting Sprint planning meeting é a reunião de planejamento que ocorre antes do início de uma sprint como resultado de um trabalho colaborativo do SCRUM team Ela deve ter um timebox de oito horas de duração para sprints de quatro semanas Ao fim de uma sprint planning meeting o time de desenvolvimento deve saber responder ao SCRUM Master e ao Product Owner o que será entregue como resultado do próximo incremento e como o trabalho será desenvolvido para chegar ao resultado esperado O Product Owner apresenta ao SCRUM Team o product backlog que consiste em uma lista ordenada de tudo que é necessário para o produto final para que o development team escolha quantos itens serão desenvolvidos na próxima sprint Essa é uma decisão que deve ser tomada apenas pelo development team pois é ele que vai desenvolver o produto que representará o resultado da sprint O Product Owner tem a responsabilidade de definir a prioridade dos itens do product backlog mas quem sabe quantos itens serão desenvolvidos é o time Após a criação da sprint backlog que representa a seleção dos itens do product backlog a serem desenvolvidos na sprint o SCRUM team define o objetivo da sprint Esse objetivo será a meta a ser trabalhada pela equipe até o término da sprint Como já mencionado o SCRUM team tem como característica ser auto organizável e multifuncional Seguindo esse pensamento o development team deve ser capaz de decidir a melhor forma de alcançar os objetivos da sprint usando seu conhecimento para transformar a sprint backlog em um produto utilizável O SCRUM não prescreve práticas da engenharia de software a serem usadas dentro do desenvolvimento do sistema Essa é uma decisão do development team Como Fazer a Sprint Planning Meeting Na sprint planning meeting estão presentes o SCRUM Master o SCRUM team e o Product Owner com a proposta de definir como será realizada a sprintnO Product Owner apresenta as funcionalidades do Gestão de Times Métodos Ágeis 16 product backlog que serão executadas naquela sprint por meio de uma definição de prioridades A partir dessa etapa é desenvolvida a sprint backlog a lista que marca as práticas apenas daquele ciclo específico É bom lembrar que o processo é uma elaboração conjunta O cliente apresenta as prioridades do product backlog e o time faz uma avaliação do tempo necessário para que as tarefas sejam concluídas Ao final daquela sprint definese quais serão as práticas realizadas Na reunião também será possível esclarecer dúvidas para evitar falhas ao longo da realização das atividades e para que os processos sejam otimizados Também é a sprint planning meeting que define a meta para aquela sprint servindo de referência para avaliação após a realização de todo o trabalho daquele ciclo Serão adiados para a próxima sprint os itens do product backlog que ficarem pendentes O cliente e o grupo de trabalho definem em conjunto quais serão as demandas cumpridas naquela sprint e o SCRUM Master realiza o papel de orientar e gerenciar todo o processo Assim o time tem um plano de ação e pode desempenhar as tarefas gradualmente até que todas as demandas do product backlog sejam efetivadas Cumprindo bem essa etapa garantese que cada sprint seja realizada com mais qualidade e efetividade O que Será Desenvolvido na Sprint Na primeira etapa o time de desenvolvimento avalia as funcionalidades que poderão entrar na sprint conforme a prioridade dos itens definida pelo Product Owner Dessa forma o Product Owner poderá detalhar os itens de forma que o time de desenvolvimento possa compreendêlos avaliar a complexidade dos itens e saber quantos caberão na sprint As entradas desta parte da reunião são Os itens de backlog do produto devidamente priorizados e detalhados no maior nível possível para que sejam facilmente compreendidos pelo time de desenvolvimento O último incremento do software em desenvolvimento Gestão de Times Métodos Ágeis 17 A capacidade projetada do time de desenvolvimento sua produtividade em pontos e a performance da última sprint O detalhamento dos itens normalmente é feito em formato de histórias de usuários mas poderão ser casos de uso especificação de requisitos ou simplesmente textos descritivos Cabe aqui o cliente ou o time SCRUM definir a melhor forma de descrever as necessidades do software Realizado o alinhamento entre o dono do produto e o time de desenvolvimento seguese para as estimativas de complexidade para cada item selecionado Essa complexidade normalmente medida em pontos é dada pelo time de desenvolvimento A técnica utilizada normalmente é o Planning Poker Após as estimativas o time de desenvolvimento seleciona os itens que acredita ser possível entregar na sprint sempre respeitando a prioridade definida pelo dono do produto e sempre tomando cuidado para não selecionar itens além da capacidade de entrega do time na sprint Por exemplo se em uma sprint de 30 dias é possível entregar 20 pontos a equipe não poderá exceder esse número Se já tiver selecionado 18 pontos e o próximo item tem 4 pontos é melhor não trabalhar nesse item deixandoo para a próxima sprint Vale aqui a regra ao invés de exceder a capacidade da equipe e não conseguir entregar o item de forma satisfatória ou sacrificar algumas etapas para entregálo é melhor postergar seu desenvolvimento IMPORTANTE Acrescentar itens durante a sprint é preferível em vez de tirálos após o início dela Após definidos os itens e suas estimativas de complexidade define se a meta da sprint que é um balizador uma frase curta que indica o que será entregue por exemplo converter o sistema para rodar no banco de dados SQLServer ou permitir ao usuário realizar pedidos de venda Gestão de Times Métodos Ágeis 18 O importante dessa fase da reunião é definir o que fazer e não como fazer Nessa reunião cabe ao time de desenvolvimento orientar o Product Owner e dividir itens do backlog em partes menores caso notem que eles são muito grandes para serem desenvolvidos em uma única sprint ou são de difícil compreensão em geral itens menores são mais facilmente compreendidos Cabe aqui um ponto de atenção o objetivo da reunião não é o de reordenar os itens do backlog do produto Essa atividade deverá ser executada previamente Caso contrário a reunião de planejamento se tornará improdutiva e não será ágil As saídas desta primeira parte serão Itens do backlog do produto selecionados para a sprint Estimativas dos itens selecionados para a sprint Meta da sprint estabelecida e acordada pelo time SCRUM Como Será Desenvolvido Terminada a primeira parte iniciase a segunda etapa da reunião com a pergunta como isso será desenvolvido Nesta etapa a presença do dono do produto não é obrigatória mas encorajada pois é possível que o time de desenvolvimento precise esclarecer alguma dúvida sobre a expectativa do produto ou serviço Ainda nesta etapa o time de desenvolvimento deverá decidir como fará para desenvolver a funcionalidade dentro da definição de pronto ou seja quais tarefas são necessárias para construir os itens do backlog do produto dentro dos critérios de aceitação do projeto que satisfaçam às necessidades ou aos requisitos descritos nas histórias de usuário Neste momento são discutidas todas as tarefas tais como análise criação de tabelas design layout de tela ou relatório desenvolvimento testes tecnologia necessária bibliotecas que poderão ser utilizadas entre outras Cada item do backlog do produto será desmembrado em pequenas tarefas que precisarão ser realizadas pelo time de desenvolvimento e não poderão ser terceirizadas Gestão de Times Métodos Ágeis 19 Nesta reunião não é necessário detalhar todas as atividades necessárias para toda a sprint O ponto que demanda atenção é o detalhamento das tarefas dos primeiros dias de trabalho e diariamente os demais itens Esse desmembramento dos itens de backlog de produto em tarefas menores gera o chamado backlog da sprint As tarefas devem ser estimadas em horas e não deve exceder oito horas trabalho de um dia caso contrário será mais difícil medir a evolução do time na busca da meta da sprint já que para a medição consideramse as tarefas que foram completadas não havendo percentual concluído de tarefas Também é possível neste momento acionar especialistas ou consultores para ajudar no processo de entendimento sobre como executar os itens Por exemplo acionar um DBA data base adminsitrator ou administrador do banco de dados da empresa para ajudar a definir o banco de dados um consultor de negócio para esclarecer um cálculo de imposto algum técnico para falar sobre determinada biblioteca etc Fique atento pois tratamse apenas de pessoas que ajudam nas definições O time de desenvolvimento é que deverá ser capaz de construir a solução por completo sem delegar ou repassar tarefas para esses profissionais que estão fora da equipe Após as estimativas das tarefas em horas o time de desenvolvimento conseguirá avaliar melhor o tempo necessário para desenvolver os itens do backlog do produto selecionados e verificar se realmente conseguirá entregar tudo na sprint O mais importante é o comprometimento do time de desenvolvimento com os itens selecionados para entregar todas as tarefas necessárias prontas para uso Ao final da reunião o time de desenvolvimento deverá ser capaz de apresentar ao dono do produto como o item do backlog foi convertido em incremento de software pronto para uso Terminada a reunião o time de desenvolvimento poderá dar início às atividades da sprint Essa reunião apesar de ser timeboxed poderá terminar antes das oito horas desde que seu objetivo seja alcançado Superar as oito horas entretanto não é indicado Gestão de Times Métodos Ágeis 20 Alinhamento Os profissionais deverão alinhar com o Product Owner quais funções serão implementadas bem como as tarefas a serem executadas Essa etapa é chamada de sprint planning Tratase do primeiro evento realizado na sprint e deve responder a duas perguntas primordiais o que será feito e como será feito A sprint planning é dividida em duas partes cada uma com tempo sugerido de quatro horas A primeira definirá os itens do product backlog que serão desenvolvidos na sprint Já a segunda parte definirá como esses itens serão abordados durante o trabalho ou seja quais serão as tarefas executadas para que os elementos selecionados sejam entregues ao final dessa etapa O resultado é um novo backlog que se caracteriza por ser uma parte do product backlog porém com maior detalhamento das tarefas e funções para cada item selecionado Esse novo artefato gerado a partir da reunião inicial da sprint é chamado de sprint backlog Normalmente a atribuição de prioridades nos backlogs é feita por pontuação Tarefas mais importantes para o Product Owner mais difíceis de executar mais demoradas ou que têm alguma incerteza ou risco técnico recebem maior pontuação Cada SCRUM team tem uma pontuação limite aferida com base na produtividade da equipe Com isso o grupo fica limitado a pegar um conjunto de tarefas que não exceda o limite Esse parâmetro é criado para diminuir o número de tarefas não entregues em decorrência de uma sobrecarga de trabalho Assim que o Product Owner define os itens do backlog a serem desenvolvidos fica a cargo do SCRUM team orientar o que é possível ser entregue dentro do prazo final da sprint Nesse ponto é necessário que o time aceite apenas uma quantidade de tarefas que não exceda a pontuação máxima determinada Em alguns casos pode ser mais interessante dar prioridade para as atividades que envolvam maior risco técnico ou de segurança Em outros Gestão de Times Métodos Ágeis 21 casos os gestores podem optar por priorizar os trabalhos que agregam mais valor ao produto Nesse momento a opinião do Product Owner deve ser levada em consideração Duração No SCRUM todo evento ou processo é timeboxed ou seja tudo que será realizado no método tem uma duração um prazo predefinido determinado com base em uma análise anterior ou a um padrão já conhecido de trabalho Assim cada sprint deverá ter sua duração de acordo com a capacidade de trabalho do SCRUM team responsável pelo desenvolvimento da arquitetura do produto Normalmente em equipes que estão no início da implantação do método é adotado um período de 30 dias para a execução da carga de tarefas padrão Se a sprint contar com muitas tarefas será necessário reduzir a quantidade de atividades do product backlog que a equipe tentará executar Caso o número de trabalhos seja baixo mais itens do product backlog podem ser adicionados à sprint Trabalho Uma vez finalizada a sprint backlog as atividades são efetivamente iniciadas Nesse momento o Product Owner deverá se afastar um pouco do time de desenvolvimento que subdividirá as tarefas de modo a conseguir maior controle sobre os trabalhos a serem realizados O SCRUM procura criar um ambiente de trabalho que facilite a solução de problemas por meio da cooperação coletiva Para isso é sugerido que o SCRUM team seja composto de pessoas de diferentes áreas técnicas a fim de criar um grupo multidisciplinar para estimular novas ideias e soluções Além disso a comunicação interpessoal e o acompanhamento de resultados devem ser constantemente motivados dentro da sprint para que não haja atrasos ou tarefas não realizadas Gestão de Times Métodos Ágeis 22 RESUMINDO E então gostou do que estudamos neste capítulo Agora vamos recordar um pouco do que foi visto Você deve ter compreendido que a sprint é o principal evento do SCRUM Significa em tradução literal corrida de velocidade ou arrancada e seu tempo sempre será definido em dias corridos sendo recomendado que a duração seja constante do início ao fim do projeto Estudamos também sobre o sprint planning meeting que é a reunião de planejamento que ocorre antes do início de uma sprint como resultado de um trabalho colaborativo do SCRUM team Vimos também que ao fim de uma sprint planning meeting o development team deve saber responder ao SCRUM Master e ao Product Owner o que será entregue como resultado do próximo incremento e como o trabalho será desenvolvido para chegar ao resultado esperado O Product Owner apresenta ao SCRUM team o product backlog que consiste em uma lista ordenada de tudo que é necessário para o produto final para que o development team escolha quantos itens eles serão capazes de desenvolver na próxima sprint Em seguida estudamos como fazer a sprint planning meeting na qual estão presentes o SCRUM Master o SCRUM team e o Product Owner com a proposta de definir como será realizada a sprint além de desvendar o que será desenvolvido na sprint seu alinhamento e trabalho Gestão de Times Métodos Ágeis 23 Técnicas de Reunião no Método SCRUM OBJETIVO Este capítulo tem como principal objetivo elencar as técnicas para a realização de reunião no método SCRUM visando garantir a eficiência da produção Vamos lá A daily SCRUM meeting é uma reunião diária timeboxed geralmente de 15 minutos Seu objetivo principal é fazer o development team refletir a respeito das seguintes questões O que foi completado desde a última reunião O que será feito até a próxima reunião e quais obstáculos estão no caminho Essa reunião assegura que o development team está seguindo a direção correta em relação ao objetivo da sprint Como regra do SCRUM somente os integrantes do development team devem participar da daily SCRUM meeting Figura 2 Development team Fonte Freepik Gestão de Times Métodos Ágeis 24 A reunião diária melhora a comunicação identifica e remove impedimentos para o desenvolvimento do trabalho e melhora o nível de conhecimento da equipe de desenvolvimento SCHWABER SUTHERLAND 2017 Qual a Importância do Daily SCRUM São muitas as vantagens de realizar o daily SCRUM Além de melhorar a comunicação e o engajamento da equipe serve como oportunidade para correção de rota mitiga os riscos e ainda proporciona a prática dos três pilares do SCRUM inspeção do progresso adaptação ajustes e impedimentos diária e transparência todos sabem o que está acontecendo Reuniões diárias melhoram as comunicações eliminam reuniões desnecessárias identificam e removem impedimentos para o desenvolvimento destacam e promovem rápidas tomadas de decisão e melhoram o nível de conhecimento do time de desenvolvimento Quadro 1 O que cada letra da palavra Gifts significa G GOOD START I IMPROVEMENT F FOCUS T TEAM S STATUS Fonte Eaborado pela autora 2021 Good start ajuda a começar bem o dia Improvement promove melhoria contínua Focus reforça o foco no que realmente importa Team reforça o senso de equipe Status comunica o que está acontecendo O daily SCRUM funciona como um mini PDCA Plan Do Act Check diário promovido pela equipe do projeto Gestão de Times Métodos Ágeis 25 Regras Básicas do Daily SCRUM Para que o daily SCRUM possa funcionar de forma efetiva existem algumas regras que devem ser estabelecidas e mantidas pelo SCRUM Master Duração Máxima de 15 Minutos Assim como os demais eventos do SCRUM estas reuniões são timeboxed ou seja têm um tempo fixo Reuniões longas e monótonas são formas erradas de começar o dia acabando com a energia dos participantes Como regra geral após 15 minutos as pessoas começam a se distrair e perder o foco principal o que torna a reunião pouco produtiva Evitase isso no SCRUM fixando duração máxima para cada evento Mesmo Local e Horário Todos os Dias O principal motivo desta regra é fazer com que as pessoas se acostumem e passem a sentir que as reuniões fazem parte de sua rotina diária assim como escovar os dentes tomar café etc Figura 3 Mesmo horário e local Fonte Freepik Gestão de Times Métodos Ágeis 26 Para que esta regra funcione é essencial que a reunião nunca deixe de iniciar porque algum membro da equipe ainda não chegou ou porque alguém terá que faltar Tratase de um processo ritualístico Há casos de projetos em que as equipes definem algum tipo de punição mas sempre na medida correta por vezes até lúdica para quem se atrasa ou deixa de comparecer à daily SCRUM O SCRUM Master Organiza Mas o Time SCRUM é que Conduz a Reunião Diária O SCRUM Master assegura que o time de desenvolvimento realize a reunião diária mas o time é responsável por conduzila O SCRUM Master reforça a norma de que somente os integrantes do time de desenvolvimento participam da reunião Terceiros podem participar apenas como ouvintes O que é Preciso para o Daily SCRUM É necessário compreender o que é preciso para o daily SCRUM sendo seus elementos Integrantes do time SCRUM condutores SCRUM Master organizador Burndown Chart Registro de impedimentos Recomendase que a reunião seja feita diante de um quadro de Kanban Gestão de Times Métodos Ágeis 27 Figura 4 Quadro Kanban Fonte Elaborada pelo autor 2022 DEFINIÇÃO Kanban é uma palavra de origem japonesa que significa cartão ou sinalização Este é um conceito relacionado com a utilização de cartões postit e outros nos quais são colocadas indicações sobre determinada tarefa por exemplo para executar em andamento ou finalizado Roteiro Passo a Passo Passo 1 O SCRUM Master organiza a reunião e avisa a todos os envolvidos local horário pauta e modus operandi Passo 2 O SCRUM Master explica as regras do daily SCRUM e o time de desenvolvimento continua a reunião Passo 3 É comum um impasse para saber quem vai começar a falar Uma forma simples de resolver isso é usar a regra do quem chega por último fala primeiro Entram aqui as três perguntas básicas o que eu fiz ontem que ajudou o time de desenvolvimento a atender à meta da sprint O que eu farei hoje para ajudar o time de desenvolvimento aa tender à meta da sprint Vejo Gestão de Times Métodos Ágeis 28 algum obstáculo que impeça a mim ou ao time de desenvolvimento de atender a meta da sprint Passo 4 O próximo em ordem de chegada fala sua parte até que todos falem É importante definir uma regra como a do quem chega por último para que o próprio time saiba a ordem da fala sem precisar intervenção do facilitador Isso contribui para que a reunião não ultrapasse os 15 minutos Passo 5 O SCRUM Master termina a reunião atualiza o quadro de Kanban e o Burndown Chart Além disso atualiza os registros de impedimentos que foram levantados para tentar resolvêlos assim que a reunião se encerra O time de desenvolvimento ou os membros da equipe frequentemente se encontram imediatamente após a reunião diária para discussões detalhadas para adaptar ou replanejar o restante do trabalho da sprint Isso é feito de forma isolada e não faz parte do daily SCRUM RESUMINDO E então gostou do que estudamos neste capítulo Esperamos que sim Agora vamos recordar um pouco do que foi visto Você deve ter compreendido sobre as técnicas de reunião no método SCRUM sabendo inicialmente que a daily SCRUM meeting é uma reunião diária timebox geralmente de 15 minutos onde a reunião assegura que o development team está seguindo a direção correta em relação ao objetivo da sprint Vimos em seguida que a importância do daily SCRUM está em melhorar a comunicação e o engajamento da equipe pois serve como oportunidade para correção de rota mitiga os riscos e ainda proporciona a prática dos três pilares do SCRUM inspeção adaptação e transparência Você compreendeu as regras básicas do daily SCRUM que são duração máxima de 15 minutos mesmo local e horários todos os dias SCRUM Master organiza mas o time SCRUM é que conduz a reunião diária Após compreender isso vimos o que é preciso para o daily SCRUM como os condutores o organizador e o registro Por fim vimos os passos para o andamento dessas técnicas Gestão de Times Métodos Ágeis 29 Sprint Review OBJETIVO Você já ouviu falar em sprint review Sabe para que serve Se ainda não é sobre ele que trataremos neste capítulo se você já ouviu falar irá aprofundar o seu conhecimento sabendo da importância disso Pronto para conhecer um pouco mais Vamos lá Começamos nosso capítulo enumerando que Um backlog do produto nunca está completo Os primeiros desenvolvimentos estabelecem os requisitos inicialmente conhecidos e melhor entendidos O backlog do produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem O backlog do produto é dinâmico mudando constantemente para identificar o que o produto necessita para ser mais apropriado competitivo e útil Se um produto existe seu backlog do produto também existe SCHWABER SUTHERLAND 2017 p 14 Sabendo disso devemos salientar que a sprint review ocorre no final da sprint Mas o que é a sprint review Figura 5 Sprint review Gestão de Times Métodos Ágeis 30 Fonte Freepik A sprint review acontece ao final de cada sprint e tem como objetivo avaliar o que foi produzido pelo development team É uma reunião time boxed com duração de quatro horas para sprints de um mês Na sprint review o Product Owner se encarrega de verificar se o incremento desenvolvido realmente atende à expectativa de pronto Nesse momento o Product Owner se encarrega de atualizar o product backlog e por meio disso tornase capaz de projetar possíveis conclusões A sprint review fornece informações importantes que serão usadas na sprint planning meeting da próxima sprint Reunião de Revisão da Sprint Assim como as reuniões diárias o review também é timeboxed deve ter um tempo limitado e um objetivo bem definido Geralmente os reviews têm no máximo quatro horas de duração A reunião de review é também conhecida como apresentação da sprint É uma parte importante do SCRUM mas muitos não a valorizam o que é um erro pois pode fazer grande diferença na aplicação e melhoria contínua do SCRUM Um membro do time pode realizar a demonstração dos itens de backlog prontos ao Product Owner que pode navegar no sistema e fazer por si só a avaliação dos itens entregues Objetivos Podemos elencar como objetivos Apresentar o produto desenvolvido para o dono do produto e os stakeholders Receber o feedback do dono do produto e dos stakeholders Receber o aceite do dono do produto e dos stakeholders Gestão de Times Métodos Ágeis 31 Nesta reunião são apresentados os itens que estão prontos e os que não estão prontos no backlog do produto O time de desenvolvimento apresenta os itens que foram concluídos e as dificuldades encontradas É importante neste momento que o time apresente o sistema mesmo que no computador do desenvolvedor e não uma apresentação em PowerPoint ou algo semelhante Figura 6 Apresentação dos itens pelo time Fonte Freepik É importante que antes da reunião o time de desenvolvimento reserve cerca de uma hora para fazer um deploy da aplicação em um ambiente de testes ou treinamento atribuindo mais credibilidade ao time Depois da apresentação o dono do produto precisa dar o feedback apontar o que ficou bom ou não se o quesito pronto definido para a sprint foi atendido e se a meta da sprint foi alcançada Caso algum item seja rejeitado deve voltar para o backlog do produto e ter nova prioridade definida Durante a apresentação é normal surgirem sugestões novas necessidades pedidos de mudanças entre outros pois essa reunião serve também para adicionar solicitações ao backlog do produto que será priorizado conforme a necessidade e importância para o negócio O Gestão de Times Métodos Ágeis 32 backlog do produto é um artefato vivo e muda constantemente A reunião de revisão da sprint é um dos momentos em que esse artefato sofre mudanças A reunião de revisão é o momento formal do SCRUM para comunicação e interação entre dono do produto e dos stakeholders com o time de desenvolvimento É uma reunião que promove Transparência pois todo o trabalho desenvolvido até então é apresentado Não se espera o final do projeto para mostrar o que foi feito Inspeção por meio da qual é possível acompanhar a evolução dos trabalhos avaliar o que já foi feito e o que ainda falta ser concluído Adaptação em que é possível fazer ajustes nos itens que faltam mudar a prioridade e solicitar melhorias em relação ao pedido inicial Quem Deve Participar da Reunião Todo o time de desenvolvimento deve participar da demonstração do sistema Por questões práticas e operacionais uma pessoa pode ser selecionada para a apresentação mas é importante considerar um revezamento por exemplo SCRUM Master dono do produto interessados no projeto stakeholders convidados pelo dono do produto Podem ser usuárioschaves diretoria donos de processo entre outros Ao Final da Reunião O que se Espera É necessário considerar os seguintes pontos quando a reunião é finalizada Um conjunto de funcionalidades prontas para uso e aprovadas pelo dono do produto Um backlog do produto atualizado e revisado Gestão de Times Métodos Ágeis 33 Prioridades do backlog do produto revisado observando a relevância de cada item para atingir o maior valor possível Uma lista de itens que poderão ser inclusos no backlog do produto Cronograma do projeto orçamento e capacidade do time revisados Itens do backlog do produto que provavelmente entrarão na próxima sprint IMPORTANTE O review não é um momento para testar os itens entregues mas sim de apresentação conferência e avaliação dos itens de acordo com a indicação de pronto de cada um deles Importância do Review Mesmo com todas as explicações desenvolvidas até aqui muitos podem ainda estar se perguntando para que gastarmos tempo com uma revisão ou apresentação A primeira ideia que devemos ter em mente é que ao seguir as regras do SCRUM não gastamos tempo Pelo contrário investimos tempo Vamos entender o porquê Uma coisa muito comum em desenvolvimento de sistemas é o acúmulo de tarefas quase prontas e o empilhamento de funcionalidades com 99 de conclusão Geralmente não há nada 100 pronto mas tudo está no quase Quando temos uma apresentação com o objetivo de demonstrar e revisar as conclusões todo o time se empenha em realmente ter as tarefas prontas porque o próprio time do Product Owner e os outros envolvidos com o projeto vão participar da Apresentação da sprint e esperam ver um sistema funcionando O que geralmente se vê em times novos no SCRUM é a negligência e a pouca importância atribuída aos primeiros reviews Com isso acabam incorrendo no erro do praticamente pronto Notase então o Gestão de Times Métodos Ágeis 34 aparecimento de muitas falhas o que gera até mesmo impossibilidade de apresentações Isso causa desconforto e frustração no próprio time que certamente vai procurar melhorar sua apresentação para a próxima revisão de sprint e naturalmente tentará terminar 100 menos itens em vez de ter mais itens quase prontos Desta forma será mais precisa a avaliação de velocidade do time e do que está sendo de fato entregue Figura 7 Review e a melhoria continua Fonte Freepik Quando o time começa a melhorar a qualidade de suas entregas nos reviews tornase cada vez mais motivado Isso faz com que sua melhoria seja contínua Ao final do review novos itens não planejados para a próxima sprint podem surgir gerando entradas importantes para as futuras reuniões de planejamento Gestão de Times Métodos Ágeis 35 RESUMINDO E então gostou do que estudamos neste capítulo Esperamos que sim Agora vamos recordar um pouco do que foi visto Você deve ter compreendido que o sprint review ocorre no final da sprint e tem como objetivo avaliar o que foi produzido pelo development team É uma reunião timeboxed com duração de quatro horas para sprints de um mês A reunião de review é também conhecida como apresentação da sprint Vimos os objetivos estando entre elas apresentar o produto desenvolvido para o dono do produto e os stakeholders e receber o feedback deles Depois da apresentação o dono do produto precisa dar o feedback apontar o que ficou bom ou não se o quesito pronto definido para a sprint foi atendido e se a meta da sprint foi alcançada Caso algum item seja rejeitado deve voltar para o backlog do produto e ter nova prioridade definida O que geralmente se vê em times novos no SCRUM é a negligência e a pouca importância atribuída aos primeiros reviews Com isso acabam incorrendo no erro do praticamente pronto Vimos então a importância desses reviews Gestão de Times Métodos Ágeis 36 Sprint Retrospective OBJETIVO O sprint conta com a revisão para a sua efetivação assim este capítulo será dedicado ao estudo do que chamamos de sprint retrospective sempre importante para a avaliação de desempenho Vamos conhecer O sprint retrospective é uma reunião timeboxed com duração de três horas para uma sprint de um mês Tem como objetivo avaliar o desempenho do development team criando melhorias para a próxima sprint Deve ocorrer ao final da sprint review e serve como forma de inspeção e adaptação pois o SCRUM team enxerga melhores formas de trabalhar para otimizar seu desempenho A retrospectiva da sprint ocorre após a revisão e antes do próximo planejamento da sprint Para sprints mais curtas os eventos também são mais curtos O SCRUM Master garante que o evento ocorra e que os participantes entendam seu propósito Esta é a oportunidade para o time SCRUM melhorar e todos os membros devem estar presentes Durante a retrospectiva da sprint a equipe discute O que correu bem na sprint O que poderia ser melhorado O que pode melhorar na próxima sprint Gestão de Times Métodos Ágeis 37 Figura 8 Análise de dados Fonte Pixabay O SCRUM Master encoraja o time SCRUM a melhorar seu processo de desenvolvimento e suas práticas para tornálo mais eficaz e agradável para a próxima sprint Durante cada retrospectiva da sprint o time SCRUM planeja maneiras de aumentar a qualidade do produto melhorar os processos de trabalho ou adaptar a definição de pronto apropriarse dos padrões do produto ou da organização e não entrar em conflito com eles No final da retrospectiva da sprint o time SCRUM deve ter identificado melhorias que serão implementadas na próxima sprint A implementação dessas melhorias é a adaptação à inspeção do próprio time SCRUM Embora as melhorias possam ser implementadas a qualquer momento a retrospectiva da sprint oferece uma oportunidade formal para se concentrar na inspeção e adaptação Gestão de Times Métodos Ágeis 38 Efetividade da Sprint Retrospective Excelente SCRUM Master Excelente Retrospectiva Tudo o que você precisa é de um excelente SCRUM Master Existem milhares de técnicas de retrospectiva publicadas em livros e em blogs que quando bem aplicadas alcançam resultados maravilhosos A questão principal é saber como e quando aplicar uma técnica ou um fluxo Dizem que musculatura de retrospectiva só se ganha com o tempo com a prática e com a vontade de melhorar a facilitação Assim os SCRUM Masters se tornarão melhores facilitadores e seus sprint retrospectives melhoram cada vez mais bem como seus SCRUM teams Faça o Sprint Retrospective em um Momento Auspicioso Uma sprint não precisa necessariamente começar na segunda e terminar na sextafeira Mas qual seria o problema disso Seu development team pode estar cansado de uma semana intensa de trabalho e participar apenas fisicamente da reunião Você terá problemas para manter a presença mental do time Dependendo do horário da sprint review e da sprint retrospective alguns times ficam compelidos a fazer trabalhos complexos como implementação e testes exploratórios Imagine se for encontrado um bug e o resultado da sprint não for como o esperado Sprint retrospectives na sextafeira podem funcionar em muitos SCRUM teams mas isso pode não ser o caso de sua equipe Veja que utilizamos o exemplo da sprint retrospective ocorrendo na sextafeira para exemplificar como alguns fatores psicológicos podem afetar o desempenho da equipe Esse conceito contudo pode ser transportado para quaisquer outros referentes a datas eventos entre outros O ponto chave aqui é seja habilidoso em gerenciar as expectativas e os momentos psicológicos da equipe Gestão de Times Métodos Ágeis 39 O Corpo Fala Escute as palavras e veja o real significado delas Infelizmente ainda não é possível saber o que outra pessoa está pensando dessa forma podemos ter um melhor entendimento das reais intenções das pessoas por meio de suas expressões corporais Por exemplo braços cruzados podem significar desde uma postura defensiva ou de insegurança até uma postura de hostilidade Uma posição relaxada com braços e pernas ligeiramente abertos demonstra autoconfiança e segurança Já uma postura recolhida significa tédio Movimentos de cabeça de um lado para o outro significam negação movimentos de cabeça para cima e para baixo consentimento Mãos na cintura podem significar desafio e agressividade Alguns sinais corporais podem trazer impressões incorretas e desconsiderar essas informações valiosas em uma facilitação pode levar a resultados desastrosos Presença Obrigatória do Product Owner A participação do Product Owner é essencial e obrigatória na sprint retrospective Veja o que diz a primeira frase do SCRUM Guide 2017 sobre isso IMPORTANTE A sprint retrospective é uma oportunidade para o SCRUM team inspecionar a si próprio e criar um plano de melhorias para ser aplicado na próxima sprint A questão principal é que existe a responsabilidade do SCRUM Master em garantir a segurança psicológica de todos os envolvidos durante a sprint retrospective Por exemplo com frequência o development team não se sente à vontade em frente ao Product Owner por questões de arrogância hierarquia desconfiança entre outras Nestes casos o Product Gestão de Times Métodos Ágeis 40 Owner não participe das sprint retrospectives e o SCRUM Master trabalhe em paralelo essas questões a fim de manter a segurança psicológica da reunião Vale lembrar que o SCRUM demanda muito trabalho do Product Owner que precisa ser capaz de colaborar com a melhoria contínua dos processos dentro do SCRUM Como exemplo de processos em que o Product Owner é essencial temos a priorização e a preparação dos itens do product backlog e o relacionamento com os stakeholders Não Buscar Culpados Um dos maiores receios ao entrar em uma sprint retrospective é de que a reunião se torne uma sessão de caça às bruxas em que a única coisa que importa é buscar culpados Claramente tal atitude não contribuirá para a evolução do time ou para um melhor desempenho coletivo Com esse raciocínio KERZNER 2002 define a primeira diretiva de uma boa sprint retrospective independentemente do que descobrirmos nós entendemos e realmente acreditamos que todos fizeram o melhor que podiam dado o que eles sabiam no momento as suas competências e capacidades os recursos disponíveis bem como a situação na mão Dessa forma a chave para uma sprint retrospective bemsucedida e construtiva é garantir que todos os participantes estejam de acordo com essa diretiva Teremos assim um evento de aprendizagem coletiva que trará bons resultados a longo prazo Figura 9 Busca por culpados Fonte Pixabay Gestão de Times Métodos Ágeis 41 Checar e Atuar Sempre há algo a melhorar no processo O mais importante de uma sprint retrospective é o comprometimento dos envolvidos com as melhorias do processo de desenvolvimento de software No SCRUM temos diversos ciclos de PDCA PlanDoCheckAct sendo executados com diferentes objetivos Na sprint retrospective é feita a checagem do processo e a criação de um plano de ação para melhorias Existem estratégias como um backlog de melhorias para expor o plano de ação em local visível e no qual todos os envolvidos podem escrever um plano para auxiliar na implementação das melhorias O SCRUM Master deve guiar a melhoria dos processos todavia deve haver o comprometimento de todos os membros do SCRUM team com a melhoria contínua de processos Figura 10 Checagem Fonte Pixabay Gestão de Times Métodos Ágeis 42 Faça a Sprint Retrospective Não fazer a sprint retrospective é o mesmo que não usar SCRUM Ela é o coração do SCRUM a ponto de muitos praticantes experientes dizerem que é a reunião mais importante Não fazer a sprint retrospective é a pior falha possível em relação a este evento A sprint retrospective é o momento em que os membros da equipe têm a oportunidade de inspecionar e adaptar seu processo e os membros do SCRUM team conversam sobre o que deu certo o que poderia ter sido melhor e o que pode ser feito de melhor para a próxima sprint O objetivo é ao menos melhorar o processo e iniciar a implementação de imediato O processo da melhoria contínua é considerado tão importante dentro do SCRUM que é peça central do raciocínio para o aumento de produtividade de um SCRUM team É considerado por Jeff Sutherland um dos principais artifícios para aumentar a produtividade do SCRUM team ou um dos itens fundamentais para fazer o dobro do trabalho na metade do tempo Todos têm Algo Importante a Dizer Um SCRUM Master pode de forma inconsciente filtrar ou desconsiderar o que uma das pessoas diz e isso pode destruir a sprint retrospective Existe um teste muito interessante para fazer a autoavaliação da imparcialidade de um líder que deveria ser feito por todos os SCRUM Masters que acreditam em sua imparcialidade Nele você é levado a se perguntar sobre sua relação com seu colega não favorito e se você realmente consegue ser imparcial em sua relação com ele dentro do local de trabalho Música dá o Tom no Ambiente Música ajuda a relaxar e pode ajudar a dar o tom na sua sprint retrospective Pessoas de diferentes épocas e culturas experimentam uma gama universal de reações emocionais a intervalos musicais específicos como se houvesse uma espécie de gramática universal tonal Para ajudar Gestão de Times Métodos Ágeis 43 estudos mostram que ouvir a música preferida melhora o desempenho dos profissionais Fluxo de Facilitação na Sprint Retrospective É necessário utilizar um fluxo para chegar a algum lugar Se não houver planejamento da sprint retrospective e um fluxo não for seguido as consequências podem ser desastrosas principalmente em início de projeto ou quando a meta da sprint não foi alcançada Também é necessário enfatizar a importância da primeira diretiva do Norman Keath uma dinâmica de warmup aquecimento um momento específico para falar o que foi bem e um momento para que todos se comprometam com a melhoria Isso pode ser a diferença entre o sucesso e o fracasso do projeto Foco nas Três Perguntas Empresas de marcadores autoadesivos não são patrocinadoras do SCRUM Existe um lado lúdico e romantizado ao se utilizar flipchart e marcadores adesivos nesta reunião Para muitos a sprint retrospective se resume ao SCRUM Master facilitar uma reunião mediada por uma técnica Postits não fazem parte do core do SCRUM da mesma maneira que o Planning Poker a User Story e o quadro de Kanban não fazem parte do framework O foco em uma sprint retrospective é sempre fazer com que as seguintes perguntas sejam respondidas O que foi bom O que melhorar Como melhorar O SCRUM Master é uma Pessoa Existe SCRUM Master isento Muito se fala e lê sobre o SCRUM Master se manter isento durante esta reunião A maior dificuldade está Gestão de Times Métodos Ágeis 44 relacionada ao fato de que em sua essência o SCRUM Master é uma pessoa e por isso tem vieses cognitivos Um exemplo uma pessoa que busca evidências que confirmem uma hipótese inicial de problema ou solução e não se permite enxergar outras possibilidades pode parecer teimosa O SCRUM Master pode enxergar com clareza um problema que não existe e mesmo assim tentar solucionálo Um exemplo claro disso é um observador externo ao time enxergar anarquia em um time auto organizado Para um observador externo a anarquia é imensa mas na realidade não existe um padrão facilmente detectável de organização O problema fica gigantesco quando o observador tem a tendência de propor soluções centralizadoras para uma característica do sistema auto organizado Estudos mostram que as escolhas das massas influenciam diretamente como uma pessoa faz escolhas mesmo que vá contra o próprio juízo dela Esse é o famoso viés da conformidade O extremo do viés da conformidade nos leva ao pensamento de manada que é um fenômeno no qual o desejo pela harmonia do grupo faz com que as opiniões das pessoas sejam suprimidas pois pensamentos contrários se tornam tóxicos e fica mais difícil ainda alterar o status quo Um SCRUM Master não consciente desses vieses pode se deixar levar pela opinião do grupo e suprimir ideias e opiniões importantes Já o efeito de ancoragem é um viés cognitivo que diz respeito a se ancorar em uma característica ou parte da informação recebida Em outras palavras é difícil se afastar da primeira impressão Dessa forma um SCRUM Master que tem a impressão de que a culpa de um insucesso é um determinado processo irá se ancorar e terá dificuldade em ver o que está realmente ocorrendo Gestão de Times Métodos Ágeis 45 RESUMINDO E então gostou do que estudamos neste capítulo Esperamos que sim Agora vamos recordar um pouco do que foi visto Você deve ter compreendido que o sprint retrospective é uma reunião timeboxed de duração de três horas para uma sprint de um mês Tem como objetivo avaliar o desempenho do development team criando melhorias para a próxima sprint Vimos que ele deve ocorrer ao final da sprint review e serve como forma de inspeção e adaptação pois o SCRUM team enxerga melhores formas de trabalhar para otimizar seu desempenho O SCRUM Master encoraja o time SCRUM a melhorar seu processo de desenvolvimento e suas práticas para tornálo mais eficaz e agradável para a próxima sprint além de compreender que no final da retrospectiva da sprint o time SCRUM deve ter identificado melhorias que serão implementadas na próxima sprint A implementação dessas melhorias é a adaptação à inspeção do próprio time SCRUM Estudamos também os pontos de efetividade da sprint retrospective Gestão de Times Métodos Ágeis 46 REFERÊNCIAS FIGUEIREDO A M Gerenciamento de Projetos Ágeis São Paulo Golden Cross 2007 KERZNER H Project management a system approach to planning scheduling and controlling Hoboken John Wiley Sons 2002 SCHWABER K SUTHERLAND J Guia do Scrum SCRUM Guides 2017 Disponível em httpsscrumguidesorgdocsscrumguide v20172017ScrumGuidePortugueseBrazilianpdf Acesso em 03 maio 2022 LESSA L O papel do PMO nas estruturas organizacionais Belo Horizonte PMI Chapter MG 2006 PERBIRA P et al Entendendo SCRUM para gerenciar projetos de forma ágil Curitiba Revista Mundo PM 2007 Gestão de Times Métodos Ágeis