Gestão de Times e Métodos Ágeis - Livro Didático Digital

Unidade 3 Livro Didático Digital Luiz Gustavo Rezende Motta Gestão de Times Métodos Ágeis Diretor Executivo DAVID LIRA STEPHEN BARROS Diretora Editorial ANDRÉA CÉSAR PEDROSA Projeto Gráfico MANUELA CÉSAR ARRUDA Autoras JOANA ÁUREA CORDEIRO BARBOSA E ALINE PEDRO FEZA Desenvolvedor CAIO BENTO GOMES DOS SANTOS Luiz Gustavo Rezende Motta Olá Meu nome é Luiz Gustavo Rezende Motta Sou formado em Ciência da Computação com experiência técnicoprofissional na área de Gestão de Projetos de mais de 10 anos Passei por empresas com a 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 convidada 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 O AUTOR Olá Meu nome é Manuela César de Arruda Sou a responsável pelo projeto gráfico de seu material Esses ícones irão aparecer em sua trilha de aprendizagem toda vez que ICONOGRÁFICOS INTRODUÇÃO para o início do desenvolvimento de uma nova com petência DEFINIÇÃO houver necessidade de se apresentar um novo conceito NOTA quando forem necessários obser vações ou comple mentaçõ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 aprofundamen to do seu conheci mento REFLITA se houver a neces sidade de chamar a atenção sobre algo a ser refletido ou discutido sobre ACESSE se for preciso aces sar um ou mais sites para fazer download assistir vídeos ler textos ouvir podcast RESUMINDO quando for preciso se fazer um resumo acumulativo das últimas abordagens ATIVIDADES quando alguma atividade de au toaprendizagem for aplicada TESTANDO quando o desen volvimento de uma competência for concluído e questões forem explicadas SUMÁRIO A sprint e seu planejamento 12 Sprint planning meeting 14 Como fazer o sprinta planning meeting 15 O que será desenvolvido na sprint 16 Como será desenvolvido 18 Alinhamento 20 Duração 21 Trabalho 22 Técnicas de reunião no método scrum 24 Qual a importância do daily scrum 24 Regras básicas da daily scrum 25 Duração máxima de 15 minutos 25 Mesmo local e horários todos os dias 25 Scrum master organiza mas o time scrum é quem conduz 26 O que é preciso para o daily scrum 26 Roteiro passo a passo 27 Sprint review 28 Reunião de revisão da sprint review 28 Objetivos 28 Quem deve participar da reunião 29 Ao final da reunião esperase 30 Importância da review 30 Sprint retrospective 32 Efetividade da sprint retrospective 33 Excelente scrum master excelente retrospectiva 33 Faça a sprint retrospective em um momento auspicioso 33 O corpo fala 34 Presença obrigatória do product owner 35 Não buscar culpados 35 Checar e atuar 36 Faça a sprint retrospective 36 Todos têm algo importante a falar 37 Música dá o tom no ambiente 37 Fluxo de facilitação na sprint retrospective 37 Foco nas três perguntas 38 O scrum master é uma pessoa 38 Gestão de Times Métodos Ágeis 9 UNIDADE 03 EVENTOS SCRUM Gestão de Times Métodos Ágeis 10 O objetivo dos eventos no Scrum é proporcionar um maior controle sobre o processo adquirindo uma rotina de trabalho e aumentando a transparência ao decorrer do desenvolvimento Os eventos Scrum são timeboxed ou seja possuem 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 a Sprint a 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 para minimizar a necessidade de encontros não definidos O Scrum usa eventos timeboxed em que cada evento tem uma duração máxima Isso garante uma quantidade apropriada de tempo gasto em planejamento sem permitir perdas no processo de planejamento Além do próprio Sprint que é um container para outros eventos cada evento no Scrum é uma oportunidade para inspecionar e adaptar algo Estes eventos são projetados especificamente para permitir a transparência e inspeção Ao longo desta unidade letiva veremos estes conceitos INTRODUÇÃO Gestão de Times Métodos Ágeis 11 Olá Seja muito bemvindo à Unidade 03 Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos 1 Compreender o conceito e a forma de planejamento de cada sprint atividade de um projeto scrum 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 Aplicar técnicas para desenvolver a retrospectiva das sprints em um projeto scrum OBJETIVOS Gestão de Times Métodos Ágeis 12 A sprint e seu planejamento INTRODUÇÃO A Sprint é o principal evento do Scrum que significa em tradução literal como corrida de velocidade arrancada Esse evento tratase de um ciclo de desenvolvimento iteração que tem um tempo determinado com dia para começar e dia para acabar Esse tempo pode variar de 2 a 4 semanas mas nunca exceder 30 dias Uma Sprint começa ao final da Sprint anterior sem intervalos O objetivo deste evento é transformar os itensdo Backlogdo Produtofuncionalidades descritas em um software ou parte dele totalmente funcional e pronto para uso dentro do período definido para a Sprint Figura 1 Imagem alusiva a organização de Sprint Fonte pixabay O tempo da Sprint sempre será definido em dias corridos sem descontar finais de semana e feriados Deve ter uma duração de 2 semanas 14 dias corridos a 4 semanas 30 dias corridos Duração menor do que 14 dias pode ser insuficiente para construir um software ou parte dele totalmente funcional e pronto para uso por isso não é recomendável porém é possível Duração maior do que 30 dias pode aumentar consideravelmente o risco pois mais do que 30 dias alguns requisitos e prioridades poderão ser alteradas e o tempo para se obter um feedback do cliente é muito longo e a chance de descobrir o que estava errado é grande Gestão de Times Métodos Ágeis 13 Recomendase também que a duração seja constante do início ao fim do projeto ou seja uma vez definida a duração da Sprint que esse seja o mesmo até que todo o backlog do produto seja finalizado assim ficará mais fácil calcular a velocidade do time e o tempo das liberações para produção Outra recomendação é que times mais novos no Scrum façam Sprints maiores de 30 dias no início pois terão mais tempo para se adequar as 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 3 semanas e depois para 2 tornando assim as entregas mais constantes Um produto completo poderá ter inúmeras Sprints quantas forem necessárias até que o backlog do produto seja finalizado se é que ele for finalizado algum dia Ao final de cada Sprint é liberado um software ou parte dele pronto para o uso porém isso não quer dizer que será liberada uma versão final que vai para produção Parece estranho pois se já está pronto por qual razão não posso ir para produção direto Em empresas menores normalmente Startups a tendência é que no 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 elas 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 esse calendário de atualização porém não impede que parte da solução seja entregue pronta e funcional em um ambiente de testes ou de treinamento Vou exemplificar melhor supomos que estamos desenvolvendo uma solução para um cliente no qual só atualiza a versão dos sistemas a cada 3 meses O desenvolvimento completo da solução irá levar pela estimativa inicial 6 meses Nesta situação poderemos planejada da seguinte forma Gestão de Times Métodos Ágeis 14 Desta forma a cada 30 dias parte do software incremento é liberado em um ambiente de testes para que o cliente possa ter contato com o sistema avaliar se o mesmo está ficando da forma desejada Além disso a cada 30 dias ele poderá redefinir a prioridade dos itens do backlog do produto que ele 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 se o Scrum serve para grandes projetos em grandes corporações A resposta é sim é muito melhor fazer desta forma incremental e iterativa entregando parte da solução rapidamente até para avaliar se está certo e se não haverá mudanças no caminho DEFINIÇÃO Deploy Em termos gerais deploy significa colocar em posição Na prática normalmente esse termo é utilizado quando queremos disponibilizar um sistema para uso Sprint planning meeting O 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 Deve ter um timebox de oito horas de duração para Sprints de quatro semanas Ao fim de uma Sprint Planning Meeting o Development Team deve saber responder ao ScrumMaster 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 PO apresenta para o 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á capaz de desenvolver na próxima Sprint Essa é uma decisão que deve ser tomada apenas pelo o Development Team pois é este quem vai desenvolver o produto que representará o resultado da Sprint Como dito anteriormente o Scrum Team tem como caracte rística ser autoorganizável e multifuncional Gestão de Times Métodos Ágeis 15 O PO tem a responsabilidade de definir a prioridade dos itens do Product Backlog mas quem sabe quantos itens serão desenvolvidos é o DT Após a criação do Sprint Backlog que representa a seleção dos itens do Product Backlog que serão desenvolvidos na Sprint o Scrum Team definese o objetivo da Sprint que será a meta com a qual todos devem trabalhar até o término da Sprint Como dito anteriormente o Scrum Team tem como característica ser autoorganizá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 de seu conhecimento para transformar o Sprint Backlog em um produto utilizável O Scrum não prescreve praticas da engenharia de software a serem usadas dentro do desenvolvimento do sistema Essa é uma decisão do Development Team Como fazer o sprint planning meeting No Sprint Planning Meeting estão presentes o Scrum Master que é o líder o Scrum Team que é toda a equipe que desenvolverá as atividades o Product Owner que é o cliente e os stakeholders A proposta é definir como será realizado o Sprint O Product Owner apresenta quais as funcionalidades do Product Backlog serão executadas naquele Sprint através de uma definição de prioridades A partir dessa etapa é desenvolvido o 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 daquele 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 para que os processos sejam otimizados Também é o Sprint Planning Meeting que define a meta para aquele Sprint que será a referência para a avaliação após a realização de todo o trabalho daquele ciclo Serão adiados para a Sprints os itens do Product Backlog que ficam pendentes Gestão de Times Métodos Ágeis 16 Figura 3 Imagem alusiva ao Product Owner Fonte pixabay O Sprint Planning Meeting é uma etapa básica do Scrum uma metodologia de gestão de projetos que segue os princípios do Manifesto Ágil Nessa reunião a equipe define quais as atividades do Product Backlog vão ser cumpridas naquele Sprint Entre os participantes do Sprint Planning Meeting estão o ScrumMaster o Product Owner os stakeholders e o Scrum Team O cliente e o grupo de trabalho definem em conjunto quais vão ser as demandas cumpridas naquele Sprint e o ScrumMaster 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 você garante que cada Sprint seja realizado com mais qualidade e efetividade O que será desenvolvido na sprint Na primeira etapa o Time de Desenvolvimento avalia as funciona lidades que poderão entrar na Sprint conforme a prioridade dos itens definida pelo Dono do Produto Então o dono do produto poderá detalhar os itens de forma que o time de desenvolvimento possa compreendêlos e avaliar a complexidade e quantos itens caberão na Sprint As entradas para desta parte da reunião são Os itens de backlog do produto devidamente priorizados e detalhados no nível maior possível para que sejam facilmente compreendidos pelo time de desenvolvimento Gestão de Times Métodos Ágeis 17 O último incremento do software em desenvolvimento 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 a empresa 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 é então definida 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 não vou detalhar aqui como funciona fica para um outro artigo 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 o cuidado para não selecionar itens além da capacidade de entrega do time na Sprint Por exemplo se uma Sprint de 30 dias é possível entregar 20 pontos a equipe não poderá exceder esse número Se já estiver selecionado 18 pontos e o próximo item tem 4 pontos é melhor não pegar esse item deixandoo para a próxima Sprint do que pegar 22 pontos e não conseguir entregar esse item ou deixálo pela metade ou até mesmo sacrificar algumas etapas do desenvolvimento para entregálo Durante a Sprint se a equipe entender que poderia ter pego o item pois daria tempo ela pode negociar com o Dono do Produto a adição deste item para a Sprint IMPORTANTE Pense que acrescentar itens durante a Sprint é melhor do que ter que tirar itens depois de iniciar a Sprint Gestão de Times Métodos Ágeis 18 Após definido os itens suas estimativas de complexidade é então definida a meta da Sprint A meta da Sprint é um balizador uma frase curta que indica o que será entregue na Sprint Por exemplo Converter o sistema para rodar no banco de dados SQLServer ou permitir ao usuário realizar pedidos de venda O importante desta fase da reunião é definir o que fazer e não como fazer Cabe também nesta reunião ao time de desenvolvimento orientar o dono do produto em quebrar itens do backlog em itens menores caso eles sejam muito grandes para serem desenvolvidos em uma única Sprint ou que estejam difíceis de entender itens menores facilitam a compreensão Porém atenção esta reunião não é para ficar reordenando os itens do backlog do produto esse é um trabalho que deve ser feito previamente caso contrário a reunião de planejamento não será ágil e nem produtiva 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 logo em seguida começa a segunda parte da reunião nesta etapa a pergunta Como será desenvolvido será respondida Figura 4 Imagem alusiva a planejamento Fonte pixabay Gestão de Times Métodos Ágeis 19 Nesta etapa a presença do dono do produto não é obrigatória mas caso o time de desenvolvimento necessite tirar alguma dúvida o mesmo deverá atender de prontidão por isso é normal e recomendado que ele permaneça na segunda parte Nesta etapa o time de desenvolvimento deverá decidir como fará para desenvolver a funcionalidade dentro da definição de Pronto ou seja quais as tarefas necessárias para construir os itens do backlog do produto dentro dos critérios de pronto do projeto que satisfaça as necessidades ou requisitos descritos nas histórias de usuário Neste momento são discutidas todas as tarefas necessárias como análise criação de tabelas design layout de tela ou relatório desenvolvi mento testes tecnologia necessária bibliotecas que poderão ser utilizadas etc Cada item do backlog do produto serão desmembrados em pequenas tarefas que precisarão ser realizadas pelo time de desenvolvimento e não poderão ser terceirizadas Nesta reunião não é necessário detalhar todas as atividades necessárias para a Sprint inteira pois durante a Sprint os itens a serem desenvolvidos poderão ser melhor detalhados O importante é detalhar pelo menos as 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 Essas tarefas devem ser estimadas em horas e não deve exceder 8 horas trabalho de 1 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 são consideradas 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 de como fazer os itens Por exemplo acionar um DBA 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 uma determinada biblioteca Mas fique atento são apenas pessoas que ajudam nas definições o time é que deverá ser capaz de construir a solução por completo sem delegar ou repassar tarefas para esses profissionais que estão fora do time de desenvolvimento em questão Gestão de Times Métodos Ágeis 20 Após as estimativas em horas das tarefas 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 Caso o time entenda que não conseguirá entregar tudo este deverá acionar o dono do produto e negociar itens que poderão ser retirados da Sprint O inverso também é possível caso o time entenda que a complexidade é menor e que poderão ser acrescentados mais itens na Sprint O importante é que o time de desenvolvimento se comprometa com os itens selecionados e que realize todas as tarefas necessárias para que sejam considerados prontos para o uso Ao final da reunião o time dedesenvolvimento deverá ser capaz de apresentar ao dono do produto como será para converter o item do backlog do produto em incremento de software pronto Terminada a reunião o time de desenvolvimento poderá dar início às atividades da Sprint tão logo a reunião termine Essa reunião apesar de ser time boxed ela pode terminar antes das 8 horas desde que o objetivo da mesma seja alcançado O que não poderá ocorrer é ultrapassar as 8 horas Alinhamento Compartilhando informações os profissionais deverão alinhar com o Project Owner quais funções serão implementadas assim como as tarefas a serem executadas Essa parte é chamada de Sprint Planning Ele é o primeiro evento realizado no Sprint e deve responder duas perguntas primordiais ao decorrer do método Scrum o que será feito Como será feito Gestão de Times Métodos Ágeis 21 Logo o Sprint Planning é dividido em duas partes cada uma com tempo sugerido de quatro horas A primeira definirá quais os itens do Product Backlog serão desenvolvidos no Sprint Enquanto 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 de tarefas e funções para cada item selecionado Esse novo artefato gerado a partir da reunião inicial do Sprint é chamado de Sprint Backlog Normalmente a atribuição de prioridades nos Backlog é feita por pontuação Tarefas mais importantes para o Product Owner mais difíceis de executar mais demoradas ou que possuem 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 devido a equipe estar sobrecarregada Assim que o Product Owner define os itens do Backlog a serem desenvolvidos fica a cargo do Scrum Team dizer o que é possível de ser entregue dentro do prazo final do Sprint Nesse ponto é necessário que o time aceite apenas uma quantidade de tarefas que não exceda a pontuação máxima que a equipe é capaz de desenvolver Em alguns casos pode ser mais interessante dar prioridade para as atividades que envolvem um maior risco técnico ou de segurança Em outros 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 método Scrum todo evento ou processo é timeboxed ou seja tudo que será realizado no método tem uma duração um prazo pré definido determinado com base em uma análise anterior ou a um padrão já conhecido de trabalho Gestão de Times Métodos Ágeis 22 Assim cada Sprint deverá ter sua duração de acordo com a capacidade de trabalho do Scrum Team responsável pelo desenvolvi mento 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 Assim que ela passar a dominar o método esse período pode ser reduzido para 21 dias e em seguida para 14 dias É importante que a duração do Sprint seja dada em semanas exatas o que facilita a organização da equipe Da mesma forma as tarefas a serem feitas devem ter no máximo 8 horas ou seja um dia de trabalho Se o 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 ao sprint Trabalho Uma vez finalizado o 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 um maior controle sobre os trabalhos a serem realizados Figura 6 Fonte pixabay Gestão de Times Métodos Ágeis 23 O método 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 por pessoas de diferentes áreas técnicas a fim de criar um grupo multidisciplinar o que estimula novas ideias e soluções Além disso a comunicação interpessoal e acompanhamento de resultados devem ser bastante motivados dentro do Sprint para que não haja atrasos ou tarefas não realizadas Gestão de Times Métodos Ágeis 24 Técnicas de reunião no méto do scrum A Daily Scrum Meeting é uma reunião diária time box geralmente de 15 minutos O 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 os obstáculos que estão no caminho Scrum 2011 Essa reunião assegura que o DT 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 A reunião diária melhora a comunicação identifica e remove impedimentos para o desenvolvimento e melhora o nível de conhecimento da Equipe de Desenvolvimento Scrum 2011 Qual a importância do daily scrum São muitas as vantagens de se realizar as Daily Scrums todos os dias Além de melhorar a comunicação e o engajamento da equipe corrige os rumos mitiga os riscos e ainda proporciona o uso dos 3 pilares do Scrum que é a inspeção do progresso e adaptação ajustes e impedimentos diariamente e transparência todos sabem o que está acontecendo Reuniões Diárias melhoram as comunicações eliminam outras reuniões 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 Good Start Ajudam a começar bem o dia Improvement Promove a melhoria contínua Gestão de Times Métodos Ágeis 25 Focus Reforça o foco no que realmente importa Team Para reforçar o senso de equipe Status Para comunicar o que está acontecendo O Daily Scrum funciona como um mini PDCA diário promovido pela equipe do projeto Regras básicas da daily scrum Para que a Daily Scrum possa funcionar de forma efetiva existem algumas regras que devem ser estabelecidas e mantidas pelo ScrumMaster Duração máxima de 15 minutos Assim como os demais eventos do Scrum estas reuniões são time boxed ou seja possuem um tempo fixo Reuniões longas e monótonas são formas erradas de começar mal o dia acabando com a energia dos seus participantes Como regra geral após 15 minutos as pessoas começam a se distrair e perder o foco principal deixando a reunião pouco produtiva Evitamos isso no Scrum fixando durações máximas para os eventos Por isso mantenha as Daily Scrums com quinze minutos ou menos Mesmo local e horários todos os dias O principal motivo desta regra é fazer com que as pessoas se acostumem e passem a sentir que estas reuniões fazem parte de sua rotina diária assim como escovar os dentes tomar café etc Figura 8 Imagem Fonte Flaticon 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 Existem projetos que as equipes definem algum tipo de punição para quem se alusiva a horarios atrasa ou deixa de comparecer à Daily Scrum Scrum master organiza mas o time scrum é quem conduz O Scrum Master assegura que o Time de Desenvolvimento realize a reunião mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária Ele reforça a norma de que somente os integrantes do Time de Desenvolvimento participem da Reunião Diária Terceiros podem participar mas somente como ouvintes O que é preciso para o daily scrum Os integrantes do Time Scrum são eles que conduzem O Scrum Master ele quem organiza O Burn Down Chart O Registro de Impedimentos É recomendado que a reunião seja feita em frente a um quadro de Kanban Figura 9 Quadro Kanban Fonte Editorial 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 neles são colocadas indicações sobre uma determinada tarefa por exemplo para executar em andamento ou finalizado Gestão de Times Métodos Ágeis 27 Roteiro passo a passo PASSO 1 Scrum Master organiza a reunião e avisa todos os envolvidos sobre o local horário pauta e modus operandi PASSO 2 Scrum Master explica as regras do Daily Scrum e passa o bastão para o Time de Desenvolvimento PASSO 3 É comum um empasse no início para saber quem vai começar Uma forma simples de resolver isso é usar a regra do Quem chega por último fala primeiro Aqui entram as 3 perguntas básicas que devem ser respondidas O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint PASSO 4 O próximo em ordem de chegada fala a sua parte até que todos falem É importante definir uma regra como a do quem chega por último para que o próprio time saiba quem é o próximo da vez sem precisar da intervenção do facilitador Isso contribui para que a reunião não ultrapasse os 15 min PASSO 5 O Scrum Master termina a reunião atualiza o quadro de Kanban e o Burn Down Chart Além disso também o atualiza os registros de impedimentos que foram levantados para que ele possa partir para tentar resolvêlos assim que a reunião acaba O Time de Desenvolvimento ou membros da equipe frequentemente se encontram imediatamente após a Reunião Diária para discussões detalhadas ou para adaptar ou replanejar o restante do trabalho da Sprint mas isso é feito de forma isolada e não faz parte da Daily Scrum Gestão de Times Métodos Ágeis 28 Sprint review 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 box com duração de 4 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 PO se encarrega de atualizar o Product Backlog e através disso tornase capaz projetar possíveis conclusões A Sprint Review chega a fornecer informações importantes que serão usadas na Sprint Planning Meeting da próxima Sprint Reunião de revisão da sprint review Assim como as reuniões diárias a Review também é uma timebox e deve ter um tempo limitado e um objetivo bem definido Geralmente as Reviews têm no máximo 4 horas de duração A reunião de Review é também conhecida como Apresentação da Sprint Esta apresentação é uma parte importante do Scrum que muitos normalmente não dão muita importância o que é um erro porque a Review pode fazer uma 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 Apresentar o produto desenvolvido para o dono do produto e stakeholders Receber o feedback do dono do produto e stakeholders Receber o aceite do dono do produto e stakeholders Nesta reunião são apresentados os itens que estão prontos e os que não estão prontos do Backlog do Produto O time de desenvolvi mento então apresenta os itens que foram concluídos e quais foram as dificuldades encontradas É importante neste momento que o time Gestão de Times Métodos Ágeis 29 apresente o sistema mesmo que no computador do desenvolvedor e não uma apresentação em Power Point ou coisa semelhante É importante que antes da reunião o time de desenvolvimento reserve cerca de 1 hora para fazer um deploy da aplicação em um ambiente de testes ou treinamento dando assim mais credibilidade ao time Depois da apresentação o dono do produto precisa dar o feedback apontando o que ficou bom ou não se atendeu o quesito pronto definido para a Sprint se a meta da Sprint foi alcançada Caso algum item for rejeitado ele deve voltar para o Backlog do produto e definir a nova prioridade Durante a apresentação é normal que aparecem sugestões novas necessidades pedidos de mudanças entre outros Esta reunião também serve para adicionar essas solicitações ao Backlog do produto que será priorizado conforme a necessidade e importância para o negócio Veja o 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 comuni cação e interação entre Dono do Produto e Stakeholders com o time de desenvolvimento É uma reunião que promove A transparência pois todo o trabalho desenvolvido até então é apresentado Não esperase o final do projeto para mostrar o que foi feito A inspeção é possível acompanhar a evolução dos trabalhos pois é possível avaliar o que já foi feito e o que ainda falta fazer A adaptação é possível fazer ajustes nos itens que faltam mudar sua prioridade e solicitar melhorias no que já foi pedido Quem deve participar da reunião Time de Desenvolvimento todo ele não somente um representante Obviamente pode ser eleito uma pessoa para demonstrar o sistema mas é importante o revezamento Gestão de Times Métodos Ágeis 30 Scrum Master Dono do Produto Interessados no projeto stakeholders seja quem for convidados pelo dono do produto Aqui podem ser usuárioschave diretoria donos de processo entre outros Ao final da reunião esperase Um conjunto de funcionalidades prontas para uso e aprovadas pelo dono do produto Um Backlog do produto atualizado e revisado 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 revisado Itens do backlog do produto que provavelmente entrarão na próxima Sprint A 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 dos itens Importância da 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 Bom a primeira ideia que devemos ter em mente é que ao seguir as regras do Scrum não gastamos tempo e sim investimos tempo neste tipo de cerimônia Vamos entender o porquê Gestão de Times Métodos Ágeis 31 Uma coisa muito comum em desenvolvimento de sistemas é o acumulo de tarefas quase prontas e o empilhamento de funcionalidades com 99 de conclusão Quem nunca ouviu a frase Tá praticamente pronto Geralmente não há nada pronto em 100 mas tudo no quase No entanto quando se tem 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 até outros envolvidos com o projeto vão participar da Apresentação da Sprint e esperam ver um sistema funcionando Não gaste tempo montando uma apresentação do sistema ou das funcionalidades prontas utilize o próprio sistema para apresentar os itens concluídos mesmo que em um ambiente de desenvolvimento O que geralmente se vê em times novos no Scrum é a negligência e a pouca importância atribuída às primeiras Reviews Com isso acabam caindo no erro do praticamente pronto então o que notase é o aparecimento de muitas falhas até mesmo gerando a impossibilidade de apresentações devido a esses erros Isso vai gerar desconforto e frustração para o próprio time e então a mudança começa acontecer O time vai preferir melhorar a sua apresentação na próxima Revisão de Sprint e naturalmente vai preferir terminar em 100 menos itens do que ter mais itens quase prontos Desta forma será mais precisa a avaliação de velocidade do time e do que está sendo entregue realmente Quando o time começa a melhorar a qualidade de suas entregues nas Reviews a autoestima melhora a confiança do time em si mesmo aumenta e a positividade começa a tomar conta do time fazendo com que a sua melhoria tornese cada vez mais contínua Ao final da Review podese ter novos itens não planejados para a próxima Sprint gerando com isso entradas muito importantes para as futuras reuniões de planejamento de Sprint Gestão de Times Métodos Ágeis 32 Sprint retrospective Esta é uma reunião timebox de duração de três horas para uma Sprint de um mês E tem como objetivo avaliar o desempenho do Development Team criando melhorias a esse respeito para a próxima Sprint Deve ocorrer ao final da Sprint Review e serve como uma forma de inspeção e adaptação em que o Scrum Team enxerga melhores formas de trabalhar a fim de otimizar o seu desempenho na Sprint posterior Figura 11 Análise de dados Fonte pixabay A Retrospectiva da Sprint ocorre após a Revisão da Sprint e antes do próximo Planejamento da Sprint Isso é no máximo uma reunião de três horas para Sprints de um mês Para sprints mais curtos o evento geralmente é mais curto O Scrum Master garante que o evento ocorra e que os participantes entendam o 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 Scrum Master encoraja o Time Scrum a melhorar seu processo de desenvolvimento e práticas para tornálo mais eficaz e agradável para o próximo Sprint Durante cada Retrospectiva da Sprint o Time Scrum planeja Gestão de Times Métodos Ágeis 33 maneiras de aumentar a qualidade do produto melhorando os processos de trabalho ou adaptando a definição de Concluído se apropriado e não entrar em conflito com os padrões do produto ou da organização No final da retrospectiva da Sprint o Time Scrum deve ter identificado melhorias que serão implementadas no próximo Sprint A implementação dessas melhorias no próximo Sprint é 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 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 determinada técnica ou fluxo ao invés de outra Dizem que musculatura de retrospectiva só se ganha com o tempo com a prática e com a vontade de melhorar a facilitação E assim se tornarão melhores facilitadores e suas Sprint Retrospectives cada vez melhores assim como os seus Scrum Teams E finalmente o Certified Scrum Trainer Alan Cyment vai além ao dizer que tudo que o Scrum precisa é de um excelente Scrum Master para começar a fazer Sprint Retrospectives Faça a sprint retrospective em um momento auspicioso Uma Sprint não precisa começar sempre na segundafeira e terminar na sextafeira todavia isto pode não funcionar Mas qual o problema disso O seu Development Team pode estar cansado de uma semana intensa de trabalho e participar apenas fisicamente da reunião e terá problemas para manter a presença mental na reunião Gestão de Times Métodos Ágeis 34 Dependendo do horário da Sprint Review e da Sprint Retrospective alguns times ficam compelidos a fazer trabalhos complexos como implantação e testes exploratórios em um dia em que o foco pode estar no final de semana Isso se não for encontrado um bug e o resultado da Sprint não for como o esperado E dependendo do que é falado na Sprint Retrospective muitos finais de semanas podem ser estragados e algumas situações podem ficar ainda piores E finalmente Estudos mostram que a sextafeira tem uma ligação forte com os conceitos de Liberdade e Partir De certa forma sexta feira é o dia que tipicamente as pessoas estão mais focadas em no fim de semana do que em qualquer outro tema Basta lembrar quantas vezes na sextafeira o assunto do seu Scrum Team é o final se semana Sprint Retrospectives na SextaFeira funciona em muitos Scrum Teams todavia isso pode não ocorrer no seu ambiente de trabalho O corpo fala Escute as palavras e veja o real significado Infelizmente ainda não é possível saber o que outra pessoa está pensando Dessa forma entender as reais intenções de uma pessoa é algo que beira o impossível Podemos ter um melhor entendimento das reais intenções das pessoas por meio das 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 abertas 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 já movimentos de cabeça para cima e para baixo consentimento Uma postura erguida demonstra segurança valor e importância no que você está fazendo E mãos na cintura significam desafio agressividade Alguns sinais corporais podem trazer impressões incorretas todavia desconsiderar essas informações valiosas em uma facilitação pode levar a resultados desastrosos Gestão de Times Métodos Ágeis 35 Presença obrigatória do product owner A participação do Product Owner é essencial na Sprint Retrospective O Product Owner é obrigado a participar da Sprint Retrospective E acredite isso está escrito no Scrum Guide A primeira frase do Scrum Guide sobre a Sprint Retrospective é a seguinte A Sprint Retrospective é uma oportunidade para que o Scrum Team inspecionar a si próprio e criar um plano de melhorias para ser aplicado na próxima Sprint Tendo em vista que o Scrum Team é compreendido pelos três papeis do Scrum incluindo o próprio Product Owner A presença do Product Owner é obrigatória seu Scrum Team gostando ou não 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 que vão desde arrogância hierarquia desconfiança dentre outras Nestes casos Peter Hundermark recomenda que temporariamente o Product Owner não participe das Sprint Retrospectives e o Scrum Master trabalhe em paralelo estas questões objetivando a segurança psicológica da reunião Vale lembrar que o Scrum demanda muito trabalho do Product Owner e estes precisam ser capazes de colaborar com a melhoria continua dos processos dentro do Scrum Como exemplo de processos em que o Product Owner é essencial temse 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 se entrar em uma Sprint Retrospective é o de que a reunião se torne uma sessão de caça às bruxas onde a única coisa que importa é buscar culpados Diga não à caça às bruxas Claramente tal atitude não contribuirá para a evolução do time ou para um melhor desempenho coletivo Com esse raciocínio Norman Keath define a primeira diretiva de uma boa Sprint Retrospective Gestão de Times Métodos Ágeis 36 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 E assim teremos um tão sonhado evento de aprendizagem coletiva que irá dar bons resultados no longo prazo 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 PlanDo CheckAct sendo executados com diferentes objetivos Na Sprint Retrospective é feito a checagem do processo e a criação de um plano de ação para melhorias Existem estratégias como um backlog de melhorias expor o plano de ação em local visível e pedir para todos os envolvidos escrever o plano de ação auxiliam 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 continua de processos 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 Jean Tabaka afirma que 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 o seu processo E é nela que os membros do Scrum Team conversam sobre o que deu certo o que poderia ter sido melhor e o que pode ser feito melhor para a próxima Gestão de Times Métodos Ágeis 37 Sprint O objetivo é o foco de ao menos uma melhoria no processo ou Kaizen e iniciar a implementação de imediato O processo da melhoria continua é considerado tão importante dentro do Scrum que é peça central do raciocínio do aumento de produtividade de um Scrum Team Sendo 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 falar Um Scrum Master pode de forma inconsciente filtrar ou descon siderar o que uma das pessoas está dizendo e isto pode destruir a Sprint Retrospective Existe um teste muito interessante para fazer uma 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 Estudos mostram que 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 estudos mostram que nos esportes ouvir sua música preferida melhora o desempenho dos profissionais Fluxo de facilitação na sprint retrospective É necessário utilizar um fluxo para chegar em algum lugar Se não houver planejamento da Sprint Retrospective e não seguir um fluxo poderá ter consequências desastrosas em uma Sprint Retrospective principalmente em início de projeto ou quando a Meta da Sprint não foi alcançada Gestão de Times Métodos Ágeis 38 Também é necessário enfatizar a importância da primeira diretiva do Norman Keath uma dinâmica de warmup 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 patrocinadores 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 Primeiramente Postit não faz 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 três perguntas fossem respondidas O scrum master é uma pessoa O Scrum Master isento existe Muito se fala e lê sobre o Scrum Master se manter isento durante esta reunião A maior dificuldade está relacionada ao fato que em sua essência o Scrum Master é uma pessoa e por isso tem vieses cognitivos por exemplo uma pessoa que busque evidencias que confirmem uma hipótese inicial de problema ou solução e não se permita enxergar outras possibilidades isso pode parecer teimosia mas para a psicologia pode ser visto como viés da confirmação 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 autoorganizado 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 a propor soluções centralizadoras para uma característica do sistema autoorganizado Gestão de Times Métodos Ágeis 39 Estudos mostram que as escolhas das massas influenciam diretamente como uma pessoa faz escolhas mesmo que vá contra o próprio juízo da pessoa Esse é o famoso viés da conformidade O extremo do viés da conformidade nos leva ao pensamento de manada que é um fenômeno em que 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 descreve em se ancorar em uma característica ou parte da informação recebida Em outras palavras a dificuldade de se afastar da primeira impressão Dessa forma um Scrum Master que tenha a impressão que a culpa de um insucesso seja um determinado processo irá se ancorar e terá dificuldade em ver o que está realmente ocorrendo O Scrum Master não é uma máquina de facilitação mas sim uma pessoa Que deve sempre focar em processos de facilitação para se isentar o máximo possível Gestão de Times Métodos Ágeis 40 BIBLIOGRAFIA FIGUETREDO AM Gerenciamento de Projetos Ágeis Golden Cross 2007 KERZNER H Project Management A system approach to planning scheduling and controlling John Wiley Sons 2002 LESSA L O Papel do PMO nas Estruturas Organizacionais Belo Horizonte PMI Chapter MG 2006 Disponível em httpwwwpmimgorg brGeralvisualizador Conteudoaspxcodareaconteudo423 Acesso em 14 fev 2015 PERBIRA P et al Entendendo Scrum para Gerenciar Projetos de Forma Ágil Curitiba Revista Mundo PM 2007 Luiz Gustavo Rezende Motta Gestão de Times Métodos Ágeis