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

Unidade 4 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 Backlog do produto 12 Característicaschave 12 Priorização 13 Requisitos não funcionais 15 Critérios 16 User story 17 Priorização 19 Backlog do sprint 23 Característica de um backlog do sprint 24 Como criar um backlog de sprint 25 Por que o backlog do sprint é importante 26 Criando um bom backlog do sprint 26 Melhores práticas para planejar o sprint backlog 27 Stakeholders do sprint backlog 27 Dicas para planejar o sprint backlog 27 Reunião de planejamento do sprint 28 Considerações para execução do sprint planejado 28 Medindo o progresso de projetos scrum com burndown chart 29 Como criar um burndown chart 30 Atualizando o burndown chart no daily meeting 31 Incremento 33 Incrementos entregáveis 34 Definição de preparado 34 Como é a definição de preparado 35 Transparência do artefato 37 Definição de pronto 37 O que é a definição de pronto 38 Como é a definição de pronto 39 Gestão de Times Métodos Ágeis 9 UNIDADE 04 ARTEFATOS DO SCRUM Gestão de Times Métodos Ágeis 10 Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos Podem ser representados pelo Backlog do Produto Backlog do Sprint e interaçãoincremento O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto e é uma origem única dos requisitos para qualquer mudança a ser feita Os itens do Backlog do Produto de ordem mais alta topo da lista devem ser mais claros e mais detalhados que os itens de ordem mais baixa Estimativas mais precisas são feitas com base em maior clareza e maior detalhamento quanto menor for a ordem na lista menos detalhes existem O Backlog do Sprint é um conjunto de itens do Backlog do Produto selecionados para o Sprint juntamente com o plano para entregar o incremento do produto e atingir o objetivo do Sprint O Backlog do Sprint é a previsão do time de desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento O incremento é a soma de todos os itens do Backlog do Produto completados durante o Sprint e o valor dos incrementos de todos os Sprints anteriores Ao final do Sprint um novo incremento deve estar concluído o que significa que deve estar em condição utilizável e atender à definição do time Scrum Entendeu Ao longo desta unidade letiva veremos esses conceitos INTRODUÇÃO Gestão de Times Métodos Ágeis 11 Olá Seja muito bemvindo à Unidade 04 Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos 1 Gerenciar requisitos de escopo para o produto em desen volvimento por meio de backlogs 2 Gerenciar a lista de afazeres de uma atividade por meio de sprint backlogs 3 Gerenciar incrementos no produto de forma iterativa 4 Entender a definição de pronto para gerar transparência no artefato OBJETIVOS Gestão de Times Métodos Ágeis 12 Backlog do produto INTRODUÇÃO O Backlog do Produto Product Backlog é uma lista de funcionalidades desejadas de um produto ou seja os requisitos que um cliente espera receber ao final do projeto descrito com sua própria linguagem O ponto central do Scrum é a criação do Product Backlog é nele que o projeto começa Diferente do modelo tradicional de gestão de projetos em que precisamos fechar o escopo para poder começar a executar no Scrum acreditase que o início do projeto não é o melhor momento para isso Afinal nesse ponto ainda não conhecemos suficiente o projeto e precisamos avançar um pouco mais em algumas hipóteses antes de ter certeza Quando um projeto é iniciado não há nenhum esforço abrangente que demande muito tempo para escrever todas as tarefas ou requisitos previsíveis Normalmente tudo o que é óbvio consta do projeto o que quase sempre é mais que suficiente para o primeiro Sprint A partir daí o Product Backlog deverá crescer e mudar na medida em que se conhece o produto e os clientes Característicaschave Para o planejamento eficaz da nossa primeira entrega precisamos desdobrar as características chave do produto programadas para o primeiro release em requisitos ou histórias Na sequência do processo esses requisitos são priorizados e estimados assim como são definidos os perfis e a quantidade dos integrantes do time de projeto Dessa forma é possível ao final do processo de planejamento obter prazos e estimativas de custo para o projeto Durante a reunião de planejamento Sprint Planning o dono do produto Product Owner prioriza os itens do Product Backlog e os descreve ao time de desenvolvimento que por sua vez determina quais itens ele conseguirá concluir no próximo Sprint e os passa do Product Backlog para o Sprint Backlog Gestão de Times Métodos Ágeis 13 Figura 1 Chave Fonte pixabay Ao fazêlo o time desdobra cada item em uma ou várias tarefas de Sprint Backlog para que seja possível o compartilhamento de atividades mais efetivo Conceitualmente o time inicia do topo da lista priorizada de Product Backlog e desenha uma linha logo abaixo do item que o time considerar ser o último possível de se concluir durante o Sprint Na prática não é incomum ver um time selecionar por exemplo os cinco itens mais importantes e dois itens que estão abaixo na lista mas associados aos cinco iniciais As estimativas são realizadas pelos desenvolvedores mas é notório que são muito imprecisas e somente são utilizadas para uma grosseira alocação de tarefas nos vários Sprints Priorização De forma mais ampla a equipe Scrum e o Product Owner precisam considerar todo o backlog ao ordenar seus itens a fim de otimizar o valor ou o retorno sobre o investimento ROI A maioria das pessoas normalmente acha que o ROI tem prioridade entretanto você deve pensar o ROI como o resultado de longo prazo decorrente da ordenação correta de todo o backlog ao invés da simples soma do ROI dos itens individuais Isso é verdade de certa forma porque o ROI de um item isolado depende de sua posição no backlog Gestão de Times Métodos Ágeis 14 REQUISITOS A criação do Backlog do Produto é realizada a partir do desdobra mento das característicaschave estabelecidas na visão do produto em De maneira geral os requisitos funcionais são as funções do produto que podem ser descritas priorizadas e estimadas Requisitos também são conhecidos no mundo ágil como histórias Uma história descreve uma necessidade ou situação futura a qual o cliente pretende alcançar por meio da utilização do produto a ser desenvolvido Normalmente a descrição de uma história ou um requisito utiliza a seguinte estrutura quem precisa o que precisa por que precisa como cliente eu posso reservar filmes pela internet para poder retirálos no drivethru da loja como atendente eu posso obter a posição atualizada de um filme para informar o cliente sobre sua disponibilidade como gestor de loja eu posso consultar informações sobre o historico dos clientes para criar e oferecer promoções mais atraenters IMPORTANTE Priorizar uma lista significa ordenar seus itens pela importância de cada um em relação aos outros As prioridades guiam a comparação dois a dois dos itens na lista Pense na aplicação do algoritmo de ordenação por bolhas bubble sort para priorizar o Backlog do Produto compare os dois itens do topo e troqueos de posição se estiverem na ordem errada Gestão de Times Métodos Ágeis 15 Com base nesses exemplos conseguimos visualizar necessidades ou situações futuras a partir de três pontos de vista diferentes A primeira coluna quem referese ao cliente atendente e gestor da loja Na segunda coluna o quê é informada a necessidade ou a situação futura desejada na terceira para quê sua finalidade Uma história para ser considerada completa precisa ser formada por essas três partes quem o quê e por quê Entretanto não é uma receita de bolo Podemos descrever requisitos de outras formas como mostrado no exemplo a seguir RESERVA DE FILMES PELA INTERNET Com retiradas através do drivethru da loja CONSULTA A POSIÇÃO ATUALIZADA DO ACERVO DE FILMES Atendidemento presencial ou via telefone CONSULTA A INFORMAÇÃO SOBRE HISTÓRICO DE TRANSAÇÕES DO CLIENTE Criação e oferta de promoções Requisitos não funcionais Requisitos não funcionais são aspectos subjetivos relacionados à história Vamos considerar o seguinte requisito consulta à posição atualizada do acervo de filmes com tempo de resposta satisfatório A dúvida usual nesse tipo de requisito é o que é tempo de resposta satisfatório Tratase de uma condição que pode gerar várias interpretações Para mim tempo de resposta satisfatório pode ser algo entre dois a três segundos entretanto dependendo do perfil do usuário podem existir tolerâncias maiores ou menores Por esse motivo a única forma de resolver esse problema é transformar um requisito não funcional ou a parte não funcional do requisito em algo funcional objetivo Para tanto precisamos definir o que é tempo de resposta satisfatório Gestão de Times Métodos Ágeis 16 Se nossos clientesusuários estabelecem uma tolerância máxima de 2 segundos como tempo de resposta satisfatório é possível garantir essa condição como servidores links de acesso arquitetura do site etc Priorização e ordenação andam de mãos dadas Todas as comparações são locais ou seja são restritas a uma otimização local Critérios Para um requisito fazer parte do Backlog do Produto deve respeitar os seguintes critérios Ser independente o requisito deve possuir capacidade para atender à necessidade ou situação futura informada pelo cliente sem depender de outro requisito Essa condição é fundamental para garantir flexibilidade durante o ciclo de desenvolvimento do produto Ser negociável enquanto não for convertido em produto o requisito deve permitir alterações como mudança de prioridade aumentoredução de sua abrangência e desdobramento em outros requisitos Podese inclusive ser reescrito ou mesmo descartado desde que mantido o valor esperado pelo cliente final na entrega do produto Ser priorizado valuable o requisito deve obrigatoriamente assegurar a entrega de valor para o cliente caso contrário seu desenvolvimento poderá representar desperdício de esforço para o time de Projeto Por esse motivo o requisito é priorizado pelo dono do produto de acordo com o valor agregado ao negóciocliente final Ser estimado o requisito deve apresentar condições para que seu prazo de desenvolvimentoentrega possa ser estimado Caso o requisito não ofereça essas condições em virtude por exemplo de seu tamanho deverá ser desdobrado em requisitos menores até que possa ser adequadamente estimado Gestão de Times Métodos Ágeis 17 Ser pequeno small esse critério está diretamente relacionado ao anterior O requisito deve estar descrito de forma que permita sua estimativa com certo nível de certeza quanto menor melhor Outro aspecto a ser observado é que a duração prevista do requisito não deve ultrapassar o prazo de execução dos ciclos de trabalho estabelecidos para o projeto Sprints Ser inspecionado testable o requisito propriamente dito ou sua descrição deve prover as informações necessárias para que possa ser inspecionadotestado pelo cliente final Requisitos que não podem ser validados elevam os níveis de risco do projeto e podem ocasionar problemas graves em etapas mais avançadas do projeto Conforme mostrado até aqui fica evidente que a elaboração de requisitos não é uma tarefa simples principalmente para quem não está habituado a planejar projetos dessa forma Por esse motivo acredito que seja melhor explorar um pouco mais o tema para assegurar o correto entendimento dos conceitos e práticas relacionadas à elaboração e gestão do Backlog do Produto ACESSE httpscrumexcombrblogp1091 User story Para estruturar adequadamente o Backlog do Produto utilizase o conceito de User Stories que contém a descrição detalhada dos requisitos de cada solicitação a ser implementada Ou seja deve conter as necessidades dos usuários ou dos clientes e não as funcionalidades do sistema User Story é uma breve descrição de uma funcionalidade dita a partir da perspectiva da pessoa que deseja a nova capacidade geralmente um usuário ou cliente do sistema Gestão de Times Métodos Ágeis 18 Tratase de uma mudança de paradigma quando comparado ao modelo criado pelo Project Management Institute PMI para gestão de projetos Esse é um dos papéis do Product Owner traduzir as necessidades do cliente por meio do Backlog do Produto em uma linguagem não técnica compreensível a todas as pessoas envolvidas no projeto Exemplo Cada User Storie pode ser composta por ID uma identificação única apenas um número com autoincremento Seu objetivo é evitar que ao mudarmos seu nome percamos o controle sobre as histórias Nome um nome curto e descritivo para a história como Layout do Relatório O nome tem que ser explicativo o bastante para que os membros do time e o Product Owner entendam minimamente o que estamos falando e específico o suficiente para distinguila das demais histórias Normalmente usase entre 2 e 10 palavras Figura 3 Análise de informações Fonte pixabay Importância definir qual é importância dessa história na perspectiva do Product Owner em relação ao cliente Por exemplo 10 ou 150 Quanto mais pontos mais importante Estimativa inicial estimativas preliminares que o time dá sobre quanto tempo será necessário para concluir determinada história se comparada às demais Cada empresa trabalha sua estimativa de uma maneira mas normalmente dáse uma pontuação que está diretamente Gestão de Times Métodos Ágeis 19 relacionada à complexidade da tarefa e que servirá como base para se calcular quantos diashoraspessoas serão necessárias para entregar Se a pontuação estiver muito alta uma dica interessante é quebrar a tarefa em duas atividades assim ficará mais fácil acertar na estimativa A unidade está ligada a pontos por história e geralmente corresponde mais ou menos a relação homemdias ideal Faça a seguinte pergunta em x dias nós apresentaremos uma implementação pronta demonstrável e testada Se a resposta for com 3 pessoas trancadas em uma sala levará aproximadamente 4 dias então a estimativa inicial é de 12 pontos por história Demonstração em alto nível criamos uma descrição de como a história será demonstrada na apresentação do Sprint É apenas uma especificação de teste Faça assim então faça aquilo e então isso deverá acontecer Quaisquer outras informações esclarecimentos referências a outras fontes de informação etc Priorização MANTENHA O PRODUCT BACKLOG ATUALIZADO Histórias que não estejam mais alinhadas à visão do produto devem ser descartadas do Backlog do Produto Quanto menor for o conjunto de histórias que devem ser priorizadas mais simples será a tarefa Por mais que seja difícil desapegar de uma história pensada e até certo ponto especificada é importante que isso seja feito pois ela estando no Backlog do Produto mesmo que com uma prioridade baixa pode influenciar na priorização das demais histórias e alterar o rumo do produto DÊ IMPORTÂNCIA À DEFINIÇÃO DE PRONTO A definição de história preparada é outro fator que pode auxiliar bastante na priorização Sem ela a equipe de desenvolvimento pode não saber estimar corretamente uma história passando uma falsa noção de Gestão de Times Métodos Ágeis 20 tamanho da história para o Product Owner que tomará decisões sobre priorização com base em uma informação pouco confiável Figura 4 Questionamentos Fonte pixabay CONHECIMENTO INCERTEZA E RISCO DE HISTÓRIAS Como esses fatores influenciam diretamente o sucesso do produto histórias com baixo grau de conhecimento e alto grau de incerteza e risco devem ter uma prioridade alta Isso porque quanto antes forem desenvolvidas antes podese perceber o melhor caminho a se seguir caso contrário pode não haver o tempo necessário para desenvolver a história e colher os frutos do aprendizado do desenvolvimento da mesma QUAL É A INFLUÊNCIA DA HISTÓRIA NO PRÓXIMO RELEASE Histórias que permitam um lançamento mais rápido do produto também devem estar no topo do Product Backlog Por exemplo em um software de geração de nota fiscal a geração da nota em si é muito mais importante que o cadastro dos produtos logo ela deve possuir maior prioridade ATENÇÃO AO TAMANHO DAS HISTÓRIAS Lembrese que a história deve ser pequena suficiente s de small do INVEST para ser independente e agregar valor para o software e para o cliente Dessa forma busque uma uniformidade no tamanho das histórias de modo que o Product Backlog principalmente em seu topo Gestão de Times Métodos Ágeis 21 possua apenas histórias na menor unidade possível e à medida que avançamos podemos encontrar histórias maiores Assim evitamos que a equipe estime histórias muito grandes que possuem maior risco de apresentar surpresas em seu desenvolvimento e com estimativas mais suscetíveis a erros ATENÇÃO À DEPENDÊNCIA ENTRE AS HISTÓRIAS Apesar da definição de que as histórias devem ser independentes i de independent do INVEST muitas vezes não conseguimos evitar a dependência entre as histórias Nesse caso a melhor opção é deixar essa dependência visível com uma anotação uma cor diferente ou qualquer coisa que chame a atenção para isso Se a história A depende da história B não agrega valor para o negócio fazer a A antes da B e isso deve estar visível para todos os envolvidos no projeto OUÇA TODOS OS INTERESSADOS NO PROJETO A decisão sobre a prioridade do Product Backlog é única e exclusiva do Product Owner entretanto ele deve ouvir todos os interessados stakeholders no projeto para auxiliar seu processo de tomada de decisão Isso é importante pois o produto sendo desenvolvido não deve agradar somente ao Product Owner mas a todos os envolvidos no projeto principalmente interessados e clientes UTILIZE TÉCNICAS DE PRIORIZAÇÃO Novamente apesar de a decisão sobre as prioridades definidas ser única e exclusiva do Product Owner a utilização de técnicas como a técnica de KANO pode ser bastante útil quando existe dúvida na prioridade de um pequeno conjunto de histórias Utilize as técnicas de priorização como sua aliada para ajudar a resolver esses pequenos conflitos CONSIDERE A PRIORIZAÇÃO POR TEMAS A dependência entre histórias muitas vezes é inevitável Dessa forma agrupar as histórias dependentes em um uma e priorizar o tema Gestão de Times Métodos Ágeis 22 também pode ajudálo Assim a priorização pode ser dividida em dois passos primeiramente priorizamse os temas e depois as histórias dentro de cada tema evitando que histórias de um mesmo tema fiquem espalhadas por todo o Backlog do Produto Tão importante quando entender os conceitos existentes por trás de um Backlog do Produto é saber trabalhar de forma correta na criação e manutenção do mesmo A definição das estimativas das histórias éresponsabilidade do time de desenvolvimento com apoio do Scrum Master e do Product Owner trabalhando juntos na busca dos objetivos estabelecidos e produtividade esperada de coerência e produtividade Gestão de Times Métodos Ágeis 23 Backlog do sprint A responsabilidade de construir esse artefato é do time de desenvolvimento que listará o que é necessário para criar o produto pronto Devese listar todas as tarefas pertinentes para desenvolver o item desde a modelagem de dados construção da interface desenvolvimento das regras de negócio testes específicos etc Somente o time de desenvolvimento poderá adicionar ou remover tarefas do Sprint Backlog e poderá fazêlo a qualquer momento Figura 5 Ideia Fonte pixabay O Sprint Backlog é um artefato vivo durante o Sprint Na reunião de planejamento ele não precisa estar completo é preciso conter apenas as atividades necessárias para os primeiros dias do Sprint Durante o Sprint o time de desenvolvimento poderá ir complementando essa lista sempre que identificar novas tarefas a serem feitas ou ajustar as já definidas mas ainda não realizadas Esse artefato assim como o Product Backlog deverá ser visível para todo o time Scrum fortalecendo assim a transparência É comum a utilização de quadro Kanban ou quadro do Scrum para demonstrar essas atividades e como elas estão As atividades do Sprint Backlog são medidas em horas e não devem ultrapassar 8 horas pois assim a atividade durará no máximo 1 dia Se uma Gestão de Times Métodos Ágeis 24 tarefa durar mais do que 8 horas o ideal é dividila em tarefas menores O motivo dessa duração máxima é tornar seu acompanhamento muito mais fácil já que no Scrum não se controla percentuais de uma tarefa realizada e sim a tarefa concluída em andamento e aberta Tarefas que não foram concluídas não são consideradas no avanço do Sprint Por isso é importante quebrar as tarefas para que tenham uma duração de até 8 horas assim ao final do dia é bem provável que a tarefa seja concluída e no dia seguinte na reunião diária todos possam acompanhar a evolução do Sprint Esse talvez seja um dos pontos mais complicados para quem está acostumado ao modelo tradicional pois normalmente as tarefas ou atividades são definidas em uma semana Por exemplo a modelagem de dados pode demorar mais do que 8 horas a prototipação de uma tela complexa como uma frente de caixa PDV também pode ser grande demais para se fazer em 1 dia contudo é necessário dividir a atividade A modelagem por exemplo pode ser quebrada em partes menores como modelagem dos cadastros e modelagem das tabelas de movimentação o protótipo pode ser dividido em tela de venda tela de fechamento da venda tela de busca de produtos etc Com a prática você verá que é muito mais simples fazer dessa forma do que nos moldes tradicionais Em resumo o Sprint Backlog é uma lista de atividades a serem realizadas no Sprint para desenvolver os itens do Backlog do Produto selecionados para um Sprint Os itens são identificados e definidos pelo time de desenvolvimento sendo sua estimativa definida em horas não excedendo o limite de 8 horas Essas tarefas devem ser visíveis ao time Scrum acompanhado diariamente e podem ser incluídas e sofrer alterações em qualquer momento durante o Sprint Característica de um backlog do sprint O Backlog do Sprint é dinâmico por natureza A cada Sprint o cenário anterior é repetido A boa prática é manter o Sprint Backlog ou Sprint Goal o mais estático possível durante um Sprint Gestão de Times Métodos Ágeis 25 Durante cada sessão de planejamento de Sprint a equipe retorna ao Backlog do Produto para escolher histórias de usuários recentemente priorizadas para o Sprint O Backlog do Sprint é um subconjunto do Backlog do Produto O Backlog do Sprint é uma saída de uma reunião de plane jamento do Sprint No Backlog do Sprint a equipe Scrum trabalha em como as histórias do usuário seriam implementadas em um Sprint dividindoa em tarefas e estimandoa Supondo que o Product Backlog tenha histórias 1 2 3 4 5 e 6 A equipe decide fazer as reportagens 1 2 e 4 Como durante a equipe de planejamento do Sprint percebeu que ainda há alguma dúvida que não é bem respondida pelo Product Owner eles decidiram não incluir a história do usuário 3 e pular para a história do usuário 4 que foi bem definida O Backlog do Sprint é propriedade da equipe de desenvol vimento e contém o que e como ele é entregue Por último na equipe de Backlog do Sprint implementando convertendo os itens de Backlog de Produto mais priorizados em software de trabalho Para cada iteração Sprint a equipe cria um plano com base no que está no topo do Backlog do Produto ao iniciar o Sprint Como criar um backlog de sprint O Backlog do Sprint é criado durante a reunião de planejamento do Sprint A equipe apresenta a quantidade de trabalho que deseja fazer do Backlog do Produto para o Backlog do Sprint e decompõe ainda mais os PBIs nas tarefas do Sprint A equipe decide como e expressa isso nas tarefas A melhor maneira de representar o Sprint Backlog é um quadro de tarefas físico usando PostIt Notes ou cartões de índice bem como ser mantido eletronicamente por exemplo em planilha de Excel ou quadro de tarefas digital Gestão de Times Métodos Ágeis 26 O último tem algumas vantagens como transparência e facilidade de acesso mas adiciona complexidade se o time Scrum for distribuído em vários sites A figura a seguir mostra um exemplo de como esse quadro de tarefas pode ser organizado A estrutura deve ser adaptada para refletir as necessidades do projeto Por que o backlog do sprint é importante É prática comum no Scrum que o Backlog do Sprint seja representado em uma placa Scrum ou em um quadro de tarefas que fornece uma representação constantemente visível do status das histórias de usuário no backlog Também estão incluídos no Sprint Backlog os riscos associados às várias tarefas Quaisquer atividades de mitigação para tratar os riscos identificados também serão incluídas como tarefas no Backlog do Sprint Uma vez que o Backlog do Sprint é finalizado e comprometido pelo time Scrum novas histórias de usuário não devem ser adicionadas No entanto tarefas que podem ter sido perdidas ou negligenciadas das histórias de usuários comprometidas podem precisar ser adicionadas Se surgirem novos requisitos durante um Sprint eles serão adicionados ao Backlog Priorizado do Produto geral e incluídos em um Sprint futuro Criando um bom backlog do sprint Envolva todos os membros da equipe no processo Discuta como cada item deve ser implementado Tenha uma definição de feito Identifique todos os tipos de tarefas Não calcule tarefas em tudo Não atribua tarefas antecipadamente Revise o compro misso do Sprint Não use muito tempo Evolua o Sprint Backlog durante o Sprint Gestão de Times Métodos Ágeis 27 Melhores práticas para planejar o sprint backlog O Sprint Backlog é uma lista ordenada de User Stories que a equipe acredita que possa ser completada durante o próximo Sprint Essa lista é um subconjunto do Product Backlog na qual estão priorizadas todas as User Stories do projeto Esses itens são puxados a partir do topo do Product Backlog durante a reunião de planejamento da Sprint Essas User Stories estão no topo do Product Backlog porque o Product Owner as priorizou junto ao cliente com base no critério de geração de valor e no ROI Cada história do Sprint deve ter uma pontuação atribuída a ela com base no esforço relativo necessário para completar a história A equipe determina a melhor forma de trabalhar com o Sprint Backlog No entanto quando possível eles devem trabalhar sobre os itens de maior valor em primeiro lugar Stakeholders do sprint backlog PRODUCT OWNER Faz o mapeamento e a priorização do backlog assim como analisa a geração de valor e o ROI junto ao cliente SCRUM MASTER Remove os impedimentos da equipe TIME SCRUM Equipe multidisciplinar e autoorganizada formada de 5 a 9 pessoas Consiste em programadores analista designer tester etc Todos no projeto trabalham colaborativamente para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint Dicas para planejar o sprint backlog 1 Envolva toda a equipe no processo 2 Discuta como cada item da User Story será implementada e sua complexidade Gestão de Times Métodos Ágeis 28 3 Identifique todas as tarefas de natureza técnica ou não 4 Reveja as tarefas do Sprint e se elas cabem dentro do mesmo ou seja o escopo cabe dentro da Sprint Reunião de planejamento do sprint O Sprint Planning Meeting é uma reunião na qual estão presentes o todos os stakeholders do projeto assim como qualquer pessoa interessada que esteja representando a gerência ou o cliente Nessa atividade do Scrum o Product Owner apresenta as User Stories de maior prioridade para o time A equipe interage de forma que ocorra o compartilhamento do conhecimento e todos possam compreender o escopo do Sprint Assim a equipe técnica tem conhecimento da complexidade do Sprint e consegue estimar o esforço para a realização das tarefas Considerações para execução do sprint planejado Assim que o time prevê o número de histórias que podem ser realizadas no Sprint Backlog o escopo deve ser blindado até o final do Sprint No entanto se durante o Sprint o Product Owner decidir há uma característica de maior valor de negócio que precisa entrar no Sprint deve ocorrer uma interrupção no mesmo Figura 6 Ideia Fonte Pixabay Se houver uma interrupção que mude drasticamente as prioridades do Sprint o Product Owner pode abortar o Sprint Nesse caso a equipe realiza uma nova Sprint Meeting Planning e um novo Sprint é iniciado Gestão de Times Métodos Ágeis 29 Como tudo no Scrum vale ressaltar que o planejamento do Sprint é uma atividade TimeBox Medindo o progresso de projetos scrum com burndown chart Os métodos e as práticas ágeis são extremamente efetivos e eficazes Produzem resultados de qualidade em curto espaço de tempo comparado ao modelo em cascata e outras abordagens tradicionais de desenvolvimento de software Esses resultados são sempre orientados à geração de valor para o cliente ao final de cada Sprint do projeto ou seja a expectativa é software funcionando e agregando valor na organização cliente Para alcançar esses resultados é primordial medir e controlar o progresso do Sprint Além da questão do gerenciamento existe uma complexidade inerente que é a introdução de novos requisitos frequente mente a cada Sprint na Engenharia Civil ninguém pede para mover o prédio 1 cm para o lado após a construção da fundação entretanto quando se fala sobre software a evolução é contínua Assim surge um problema para atender ao custo ao prazo e à qualidade associados ao Sprint IMPORTANTE Como monitorar e controlar o progresso dos Sprints de projetos ágeis com a metodologia Scrum de forma transparente Na engenharia de software clássica cada projeto é composto de milestones ou marcos Esses marcos servem para mensurar o progresso do projeto fazendo um comparativo entre o que foi planejado e o que foi realizado em termos de desenvolvimento Uma métrica para estimar o esforço são os Use case points lembrando que o esforço é uma métrica dada pela capacidade homem hora um pouco taylorista O problema é que para usar essa métrica Gestão de Times Métodos Ágeis 30 é necessário ter todos os casos de uso do sistema documentados e detalhados para se analisar a complexidade No Scrum todas as User Stories são descritas em uma única sentença simples Nesse contexto como monitorar e controlar os Sprints Bom aqui reforçaremos a importância dos daily meetings para que você entenda a dinâmica É no encontro diário que a equipe aponta as tarefas que foram realizadas no dia anterior Assim cada membro dá seu depoimento compartilhando com o time o seu progresso Nesse momento o membro seleciona a tarefa em que tem maior aptidão para realizar durante o dia Com essas informações o Scrum Master atualiza o Burndown Chart diariamente Abrindo um paralelo nenhum projeto atrasa 1 mês de uma vez O atraso é decorrente da somatória de vários dias de atraso No Scrum se durante a reunião diária for apontado algum impedimento isso será avaliado assim como o seu risco de forma que o Sprint seja realizado dentro do prazo Se for um problema impactante a equipe se reúne e discute as medidas a serem tomadas em conjuntos para dirimir o problema Como criar um burndown chart O primeiro passo é fazer o planejamento e a divisão das tarefas do Sprint Isso é realizado na reunião de planejamento do Sprint e utiliza uma técnica chamada de planning poker Cada tarefa deve ter horas associadas O tempo de uma tarefa é sempre analisado usando uma sequência Fibonnaci 01 1 2 3 5 8 13 21 34 ou seja uma tarefa deve ter entre 3 horas no mínimo e 6 horas no máximo de modo que possa ser realizada em um dia Se a tarefa tem mais de 6 horas deve ser analisada e subdividida Caso a tarefa tenha menos de 2 horas esta deve ser vinculada à outra tarefa associada EsSe processo é realizado pelo time junto com o Scrum Master de forma a compartilhar e gerar colaboração em torno do Sprint Uma vez que a divisão de tarefas foi realizada o gráfico burndown ideal é traçado O ideal reflete o progresso assumindo que todas as tarefas serão concluídas dentro do Sprint a uma taxa uniforme Gestão de Times Métodos Ágeis 31 Para saber quantos pontos e a capacidade produtiva de um time para determinado Sprint devese levar em consideração as seguintes variáreis SPRINT duração de 2 semanas 10 dias úteis EQUIPE 7 membros HORASDIA 6 CAPACIDADE TOTAL 420 horas Figura 5 Exemplo de gráfico burndown Fonte O Autor Ou seja para uma equipe de 7 membros trabalhando 6 horas por dia no projeto cada durante 10 dias podemos executar um total de 420 horas de desenvolvimento Portanto na reunião de planejamento do Sprint esse parâmetro deve ser levado em consideração Atualizando o burndown chart no daily meeting O progresso realizado pela equipe de desenvolvimento deverá sempre estar próximo do progresso planejado Essa linha se inicia no mesmo ponto de origem do progresso ideal mas o seu progresso é dado a partir da queima dos Story Points A reta será traçada a partir do produto do esforço realizado tempo gasto Assim diariamente após a equipe mover as tarefas da coluna de doing para done o Scrum Master calcula o total de pontos realizados e atualiza o Burndown Chart conforme mostra a Figura 6 Gestão de Times Métodos Ágeis 32 Figura 6 Burndown chart atualizado após reunião diária Fonte O Autor Gestão de Times Métodos Ágeis 33 Incremento Em cada Sprint do projeto o time de desenvolvimento trabalha nos itens selecionados do alto do Product Backlog para o Sprint Backlog do mais importante para o menos importante visando realizar a meta do Sprint O Incremento do Produto é o resultado desse trabalho ou seja é a soma de todos os itens completos em um Sprint Portanto é um incremento de funcionalidades do produto prontas de acordo com a definição de pronto produzido em cada Sprint do projeto O Incremento do Produto é composto por novas funcionalidades e por melhorias no que foi produzido anteriormente oriundas de itens do Product Backlog A natureza incremental desse trabalho faz com que um item já considerado pronto jamais volte para o desenvolvimento Quando há necessidade de mudanças um novo item relativo a esse trabalho é criado no Product Backlog No entanto itens não prontos ao final do Sprint não fazem parte do Incremento do Produto e devem voltar ao Product Backlog a critério e escolha do Product Owner Esperase que o Incremento do Produto seja entregável ou potencialmente entregável de forma que o Product Owner possa decidir por fazer uma entrega para os clientes do projeto ao final do Sprint No entanto embora devase fazer entregas frequentes o Product Owner pode optar por acumular alguns Incrementos do Produto para só então fazer uma entrega release Ou seja entregável é diferente de entregue Entre as razões para tal um Incremento nem sempre representa valor suficiente para ser utilizado por seus usuários Assim pode não haver sentido entregálo ao final do Sprint em que foi produzido E mesmo que represente valor suficiente os clientes podem não conseguir absorver mudanças tão frequentemente ou pode haver questões políticas burocráticas ou técnicas que impeçam o Product Owner de realizar a entrega ao final de cada Sprint O time de desenvolvimento e o Product Owner demonstram o Incremento do Produto para os clientes do projeto e pessoas relevantes ao final de cada Sprint na reunião de Sprint Review O principal objetivo dessa reunião é obter feedback dessas pessoas sobre o trabalho Gestão de Times Métodos Ágeis 34 realizado e dar a elas um senso do progresso do projeto Para tornar esse feedback possível o Incremento do Produto deve representar valor visível para os presentes ou seja deve conter funcionalidades que possam ser experimentadas e usadas Incrementos entregáveis Em cada Sprint é gerado pelo time de desenvolvimento um Incremento do Produto pronto de acordo com a Definição de Pronto Idealmente esse Incremento está sempre apto a ser entregue para os clientes ou seja é entregável ou potencialmente entregável No entanto a entrega em si somente é feita quando o Product Owner julga que há valor suficiente para que seja utilizado Isso em muitos casos ocorre apenas ao somarsemais de um Incremento do Produto ou seja a partir dos resultados de mais de um Sprint Há casos no entanto em que é necessário algum trabalho adicional antes que um conjunto de Incrementos do Produto possa de fato ser entregue Isso aumenta os riscos do projeto ao se postergar a detecção de problemas Definição de preparado A Definição de Preparado é um artefato utilizado para garantir que os itens a serem considerados na reunião de Sprint Planning estejam preparados segundo um critério bemdefinido É um acordo formal entre Product Owner e time de desenvolvimento sobre o estado em que um item do Product Backlog deve estar para ser considerado preparado para entrar no Sprint Backlog Mesmo que o item no momento da reunião de Sprint Planning seja de alta prioridade ele poderá ser rejeitado pelo time de desenvolvimento se não estiver preparado de acordo com a Definição de Preparado Essa Definição não é um artefato oficial do Scrum e portanto é opção do time de Scrum usála ou não É comum times de Scrum realizarem esse trabalho de preparação apenas durante a reunião de Sprint Planning Diversos times optam no Gestão de Times Métodos Ágeis 35 entanto por antecipálo realizandoo ao longo do Sprint anterior em sessões de refinamento do Product Backlog Essas sessões realizadas pelo Product Owner e membros do time de desenvolvimento são importantes para diminuir os riscos de um Sprint mal planejado já que de outra forma detalhes demais são deixados para serem discutidos apenas na reunião de Sprint Planning Esse trabalho excessivo torna a reunião longa cansativa e ineficiente originando um Sprint Backlog mal formulado e colocando em risco todo o trabalho do Sprint O principal resultado esperado das sessões de refinamento do Product Backlog é que um número suficiente de itens a serem considerados na reunião de Sprint Planning seguinte esteja preparado para ser desenvolvido Nesses casos a Definição de Preparado funciona como um critério de entrada para o Sprint Caso o item do Product Backlog esteja preparado de acordo com a Definição de Preparado ele pode ser aceito para discussão na reunião de Sprint Planning e consequentemente pode fazer parte do Sprint Backlog Se o item estiver pronto de acordo com a Definição de Pronto ao final do Sprint ele é aceito na reunião de Sprint Review e sai do Sprint como parte do Incremento do Produto gerado no Sprint Como é a definição de preparado A Definição de Preparado assim como a Definição de Pronto é criada antes do início do desenvolvimento do produto geralmente antes mesmo do primeiro Sprint Entretanto ela pode ser modificada e evoluir de forma a acomodar novas necessidades identificadas ao longo do projeto A Definição de Preparado geralmente tem o formato de uma lista de critérios condições ou ainda passos de um processo É comum a Definição de Preparado para itens do Product Backlog conter os seguintes tópicos Deve ter havido um alinhamento sobre o item de forma a gerar uma compreensão compartilhada sobre o que o item representa Gestão de Times Métodos Ágeis 36 O item deve possuir Critérios de Aceitação discutidos compreendidos e acordados entre Product Owner e time de desenvolvimento O item deve ter sido estimado pelo time de desenvol vimento O item deve ser pequeno o suficiente de acordo com algum critério estabelecido pelo time de desenvolvimento um valor máximo para sua estimativa por exemplo Assim como a Definição de Pronto a Definição de Preparado é criada compreendida e compartilhada por todos os membros do time de Scrum Assim deve se manter visível para todos eles Gestão de Times Métodos Ágeis 37 Transparência do artefato Scrum invoca transparência Decisões para otimizar o valor e o controle de riscos são feitos com base na percepção existente do estado dos artefatos Na medida em que a transparência é plena essas decisões têm uma base sólida Mas se os artefatos não são completamente transparentes essas decisões podem ser falhas os valores podem diminuir e os riscos podem aumentar O Scrum Master deve trabalhar com Product Owner time de desenvolvimento e outras partes envolvidas para entender se os artefatos estão plenamente transparentes Há práticas para lidar com transparência incompleta o Scrum Master deve ajudar todos a aplicar a prática mais apropriada na ausência de transparência plena O Scrum Master pode detectar transparência incompleta pela inspeção dos artefatos percebendo padrões ouvindo atentamente o que está sendo dito e detectando diferenças entre o esperado e o resultado real O trabalho do Scrum Master é atuar com o time Scrum e organizar o aumento da transparência dos artefatos Esse trabalho geralmente envolve aprendizagem convencimento e mudança Transparência não ocorre de um dia para o outro mas é um caminho ACESSE No link httpsbitly2YmBn5W você pode obter mais informações sobre as regras do jogo do Scrum Definição de pronto Quando o item do Backlog do Produto ou um incremento é descrito como pronto todos devem entender o que isso significa Embora isso varie significativamente para cada time Scrum os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo assegurando a transparência Essa é a Definição de Pronto para o time Scrum e é usado para assegurar quando o trabalho está completado no incremento do produto Gestão de Times Métodos Ágeis 38 A mesma definição orienta o time de desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante a Reunião de Planejamento do Sprint O propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente utilizáveis que aderem à definição atual de pronto do time Scrum O time de desenvolvimento entrega um incremento de funcio nalidade do produto a cada Sprint Esse Incremento é utilizável assim o Product Owner pode escolher por liberálo imediatamente Se a definição de pronto para um Incremento é parte das convenções padrões ou diretrizes de desenvolvimento da organização todos os times Scrum devem seguila como um requisito mínimo Se para um Incremento pronto não é uma convenção de desenvolvimento da organização o time de desenvolvimento do Scrum deve definir uma Definição de Pronto apropriada para o produto Se há múltiplos times Scrum trabalhando no lançamento do sistema ou produto os times de desenvolvimento de todos os times Scrum devem mutuamente estabelecer a Definição de Pronto Cada Incremento é adicionado a todos os Incrementos anteriores e completamente testados garantindo que funcionem juntos Com um time Scrum maduro é esperado que a sua Definição de Pronto seja expandida para incluir critérios mais rigorosos de alta qualidade O que é a definição de pronto A Definição de Pronto é um acordo formal entre Product Owner e time de desenvolvimento sobre o que é necessário para se considerar que um trabalho realizado no Sprint está pronto É um conjunto de critérios compartilhados para que quando o time de desenvolvimento ou um de seus membros afirme que um item ou o Incremento do Produto está pronto todos compreendam o que isso significa A mesma Definição de Pronto se aplica a cada item do Sprint Backlog e ao Incremento do Produto como um todo que é o conjunto dos itens desenvolvidos no Sprint Ela ajuda o time de desenvolvimento no momento de planejar o trabalho a ser realizado no Sprint e guia o time de desenvolvimento durante a realização desse trabalho Gestão de Times Métodos Ágeis 39 Uma Definição de Pronto ideal estabelece que o resultado do trabalho de um time de desenvolvimento em um Sprint seja entregável Dessa forma nenhum desenvolvimento teste integração ou quaisquer tarefas adicionais devem ser necessários para que o Incremento do Produto produzido no Sprint possa ser entregue aos clientes do projeto Entregar ou não ao final do Sprint no entanto é uma decisão que cabe ao Product Owner Mesmo que já seja possível ele pode decidir por acumular alguns Incrementos do Produto para só então fazer uma entrega Diferentemente dos Critérios e Testes de Aceitação a Definição de Pronto não é específica para um item ou para um grupo de itens Ela é a mesma para todos os itens desenvolvidos Uma boa Definição de Pronto exige preferencialmente de forma explícita que cada item passe nos Testes de Aceitação e portanto nos Critérios de Aceitação acordados especificamente para o item Uma boa Definição também garante que o Incremento do Produto tenha o nível de qualidade exigido para ser entregue Como é a definição de pronto A Definição de Pronto é criada antes do início do desenvolvimento do produto Em geral antes mesmo do primeiro Sprint Entretanto ela pode ser modificada e evoluir de modo a acomodar novas necessidades identificadas ao longo do projeto para o desenvolvimento do produto Para a construção de uma Definição de Pronto efetiva é importante que se considerem as restrições organizacionais que afetam o trabalho do time de Scrum sejam restrições de negócio de processo tecnológicas ou culturais Devido a essas restrições muitos times de Scrum iniciam o projeto com uma Definição de Pronto distante da ideal algum trabalho adicional ainda será necessário para tornar o resultado do Sprint o Incremento do Produto entregável Exemplos dessas atividades adicionais incluem diversos tipos de testes realizados por uma equipe externa como exploratórios de integração de estabilidade e de segurança e outras validações como auditorias externas integrações com outros produtos em desenvolvimento homologações por parte do cliente e alguns tipos de documentação A necessidade dessas atividades não permite que o Incremento do Produto pronto seja entregável Gestão de Times Métodos Ágeis 40 A existência de um trabalho adicional ao pronto em cada Sprint é uma disfunção e traz riscos consideráveis ao projeto Esse trabalho ao ser realizado em Sprints seguintes desorganiza e adia a entrega de valor Uma alternativa comum é realizálo em um Sprint adicional imediatamente anterior à entrega chamado Sprint de Estabilização Nessa abordagem diversos problemas serão descobertos tardiamente e cada entrega poderá acumular problemas comuns a projetos em cascata Na medida do possível o time de Scrum trabalha ao longo do projeto para reduzir a disfunção transferindo progressivamente esse trabalho para dentro dos Sprints e assim tornando sua Definição de Pronto cada vez mais estrita à medida que se consegue aproximar de fato o pronto do entregável Em casos muito particulares por exemplo de projetos de alto risco em que são necessários testes adicionais e auditorias externas o trabalho adicional antes da entrega será sempre necessário e existirá durante todo o projeto A Definição de Pronto varia de time para time de projeto para projeto O time de desenvolvimento possui entre seus membros todas as habilidades e todos os conhecimentos necessários para entregar ao final do Sprint um Incremento do Produto pronto de acordo com a Definição de Pronto Assim é fácil entender como a Definição de Pronto e a formação do time de desenvolvimento são intrinsecamente relacionadas A Definição de Pronto geralmente se parece com uma lista de atividades ou um processo pelo qual passamos itens de trabalho no Sprint Essa lista é definida de acordo com as necessidades do produto das quais qualidades sempre faz parte e em conformidade com as convenções e os padrões organizacionais Essas atividades incluem tudo o que deve ser realizado para se construir o produto como diferentes tipos de testes que se considerem necessários documentação que faça parte do produto quaisquer integrações que devam ser realizadas etc Gestão de Times Métodos Ágeis 41 As atividades da Definição de Pronto portanto são utilizadas como referência quando o time de desenvolvimento indica quanto trabalho prevê que conseguirá produzir no Sprint Servem da mesma forma para quando o time de desenvolvimento estabelece o plano para o Sprint quebrando os itens do Sprint Backlog em tarefas por exemplo A Definição de Pronto é criada compreendida e compartilhada por todos os membros do time de Scrum Dessa forma é essencial mantêla visível para eles Gestão de Times Métodos Ágeis 42 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 New York John Wiley Sons 2002 LESSA L O papel do PMO nas estruturas organizacionais Belo Horizonte PMI Chapter MG 2006 Disponível em wwwpmimgorgbr Geralvisualizador Conteudo aspxcodareaconteudo423 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