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

Unidade 1 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 Conhecendo o universo dos métodos ágeis 12 O manifesto ágil possui a seguinte base 12 O desenvolvimento ágil é incremental 13 Desenvolvimento ágil necessita de práticas ágeis 14 Equipes 16 Entendendo a definição e o uso do framework scrum 18 Definição do scrum 18 O time scrum 19 O product owner 20 O time de desenvolvimento 21 Tamanho do time de desenvolvimento 21 O scrum master 22 Backlog do produto 23 Eventos scrum 25 Sprint 25 Revisão da sprint 26 Retrospectiva da sprint 28 Reunião diária 28 Compreendendo a teoria por trás do framework scrum 30 Áreas de conhecimento do gerenciamento de projetos aplicáveis 30 A dinâmica do scrum 32 O gerente de projeto no apoio 32 Adaptabilidade 33 Transparência 33 Feedback contínuo 34 Melhoria contínua 34 Entrega contínua de valor 35 Eficiência 36 Motivação 37 Alta velocidade 38 Ambiente inovador 39 Entender os valores do método scrum 41 Papel e os princípios do scrum 41 Transparência 42 Inspeção 42 Adaptação 43 Pontos para inspeção e adaptação em scrum 44 Valores que sustentam os pilares do scrum 45 Gestão de Times Métodos Ágeis 9 UNIDADE 01 INTRODUÇÃO AOS MÉTODOS ÁGEIS E O SCRUM Gestão de Times Métodos Ágeis 10 Projetos ágeis fazem parte da cadeia de processos de uma empresa Os Métodos Ágeis surgiram como alternativa para os problemas pontuais que apresentam durante a elaboração de um software usando os métodos de desenvolvimento orientado a planos O Scrum é um framework para gerenciamento de projetos ágeis e que apesar de muito utilizado na área de desenvolvimento de software pode ser utilizado para o planejamento gerenciamento e desenvolvimento de qualquer produto principalmente por ser um framework iterativo repetitivos e incremental A ideia principal aqui é controlar processos empíricos mantendo o foco na entrega de valor de um negócio no menor tempo possível Os projetos são divididos em ciclos repetitivos iterativos e curtos para que possam ser modificados e adaptados para corrigir os desvios incrementais Estes ciclos podem durar de duas a quatro semanas e são chamados de Sprints O framework Scrum é simples de entender Para ajudar eu separei abaixo alguns tópicos que resumem o Scrum sua teoria sua história e seus componentes Ao longo desta unidade letiva você vai mergulhar neste universo INTRODUÇÃO Gestão de Times Métodos Ágeis 11 Olá Seja muito bemvindo à Unidade 01 Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos 1 Conhecer o universo dos métodos ágeis 2 Entender a definição e os usos do framework scrum 3 Compreender a teoria por trás do framework scrum 4 Entender os valores do método scrum OBJETIVOS Gestão de Times Métodos Ágeis 12 Conhecendo o universo dos métodos ágeis INTRODUÇÃO Metodologias ágeis existem há anos desde a década de 80 mas algumas informações passaram por distorções fato que dificultou no início a utilização das metodologias Por conseguinte desenvolvedores passaram a entender a metodologia ágil como algo que tudo pode ou seja podemos desenvolver sem documentação sem padrão e sem cuidado Isto não é verdade as metodologias ágeis podem trazer sucesso ao projeto e são utilizadas inclusive na indústria Apesar das metodologias existirem foi em 2001 que um grupo de renomados desenvolvedores assinaram o MANIFESTO PARA O DESENVOLVIMENTO ÁGIL DE SOFTWARE e o grupo foi batizado de aliança dos ágeis O manifesto ágil possui a seguinte base Figura 1 imagem que faz alusão ao manifesto ágil Fonte Editorial Os indivíduos e as interações são mais importantes do que os processos e as ferramentas O software funcionando é mais importante do que uma documentação completa A colaboração dos clientes acima de apenas negociações de contratos e Gestão de Times Métodos Ágeis 13 Respostas à mudanças acima de seguir um plano A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento A filosofia defende a satisfação do cliente e a entrega de incremental prévio equipes de projetos pequenas e altamente motivadas métodos informais artefatos de engenharia de software mínimos e acima de tudo simplicidade no desenvolvimento geral Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto embora essas atividades não sejam desencorajadas também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes Pressman 2011 IMPORTANTE Isso não quer dizer que documentação não seja importante e que os processos e as ferramentas sejam inúteis significa que os itens à esquerda são mais valorizados apenas isso ACESSE httpagilemanifestoorg Acesso em 21082018 Um projeto envolve pessoas e mudanças principalmente quando falamos de entregas constantes Desta forma as metodologias ágeis trabalham com equipes altamente motivadas e suporte à mudanças durante o processo de desenvolvimento O desenvolvimento ágil é incremental Um plano completo com tudo que devemos fazer para depois iniciar o desenvolvimento Você não deve desenvolver o produto sem antes fazer contato com o cliente ao invés disso desenvolver incrementalmente ou seja o produto é feito aos poucos e entregue constantemente desta forma toda mudança é bemvinda pois o projeto está em desenvolvimento e não foi concluído por completo Gestão de Times Métodos Ágeis 14 Os incrementos iniciais do sistema podem fornecer uma funciona lidade de alta prioridade de forma que os clientes logo poderão obter valor do sistema durante seu desenvolvimento Os clientes podem assim ver os requisitos na prática e especificar mudanças para serem incorporadas nos releases liberações ou lançamentos posteriores do sistema O contato constante com o cliente também gera conhecimento pois a equipe vai entendendo o negócio para ao desenvolver fazêlo com maior velocidade e precisão e em caso de erros a equipe não terá perdido um ano de desenvolvimento e sim terá perdido apenas o tempo de desenvolvimento do incremento podendo corrigir rapidamente DEFINIÇÃO Incremental relativo a incremento ato ou efeito de desenvolver ou aumentar alguma coisa Que visa aprimorar gradualmente em etapas mudança incremental atualiza ção incremental Falamos da importância de saber escolher o que será feito ou seja funcionalidades que tenham alta prioridade desta forma o cliente já pode usufruir de recursos do sistema O que antes demoraria meses agora em semanas ele poderá ter acesso para verificar erros e especificar novas mudanças ou melhorias não necessitando chegar ao final do desenvolvimento para ver os problemas Desenvolvimento ágil necessita de práticas ágeis Podemos citar Utilização de TDD é a técnica que permite fazer testes contínuos e não apenas na conclusão do sistema melhorando assim a qualidade técnica do produto Planejamento incremental ao invés de planejar o software como um topo podemos planejar de forma sistêmica ou seja definir o todo mas planejar em etapas realizando um Gestão de Times Métodos Ágeis 15 planejamento por incremento Os requisitos do incremento podem ser registrados em cartões que algumas metodologias denominam de histórias do usuário aqui determinamos a prioridade que o cliente define e também o tempo que os desenvolvedores precisam para o desenvolvimento Incrementos desenvolvidos em tempo reduzido releases liberações ou lançamentos pequenos entregando funcionalidades em meses ou semanas ao invés de anos Utilização de refatoração melhorando o código e tornandoo mais fácil de manter constantemente Integração continua quando o incremento está pronto ele é integrado ao sistema como um todo ou seja isto é feito diariamente Figura 2 imagem alusiva a desenvolvimento agil Fonte Editorial Os métodos ágeis são eficientes para alguns tipos de sistemas como em desenvolvimento de produtos para venda em pequeno e médio porte ou também em desenvolvimento de sistemas que o cliente estará envolvido no processo de desenvolvimento em que não haverá muitas regras que afetam o software Gestão de Times Métodos Ágeis 16 Equipes Os pontos acima são base para quase todas as metodologias ágeis mas o principal ponto nestas metodologias além dos citados acima é a possibilidade de a equipe ser auto gerenciável ou seja não há necessidade de um gerente e sim um líder que tem o papel de facilitador A equipe e a comunicação entre os membros da equipe e o cliente é crucial para o sucesso das metodologias ágeis e para isso as equipes pequenas tornam se fatores de sucesso Figura 3 imagem alusiva a equipe Fonte pixabay As equipes pequenas reduzem problemas de conflitos comunicação entre outros Mike Cohn um dos colaboradores da invenção da metodologia de desenvolvimento de software Scrum afirma que equipes pequenas possuem menos ociosidade social melhoram a interação construtiva menor tempo na coordenação ninguém fica para trás pois todos apreendem em conjunto há maior satisfação entre os membros do grupo e é menos provável que ocorra excesso de especialização pois todos devem conhecer o projeto Gestão de Times Métodos Ágeis 17 Outro ponto que foi notado por Cohn é que o tamanho não indica realmente maior produtividade pois equipes grandes não são necessariamente mais produtivas pois há menos comunicação e maior número de conflitos Ainda segundo Cohn não é de se surpreender que equipes menores concluem os projetos com um esforço total menor equipes maiores demandam mais esforços e custos Equipes entre 5 a 8 integrantes têm maior chance de sucesso pois é mais fácil a comunicação mais fácil criar uma integração do que equipes com 20 a 30 integrantes Equipes muito pequenas podem sofrer problemas de falta de pessoal O Scrum e outras metodologias ágeis indicam que equipes pequenas tem maior chance de concluir o projeto do que equipes grandes Caso isso ocorra nas equipes pequenas o líder nota as deficiências e pode atacá las com maior facilidade utilizando capacitação integração etc Figura 4 imagem alusiva a equipe Fonte Flaticon Como a equipe é pequena a perda de um integrante pode prejudicar o grupo como um todo para isso não há grande especialização na equipe ou seja todos devem ser responsáveis pelo projeto e não por apenas uma tarefa o que torna a equipe elástica caso algum integrante saia do projeto Gestão de Times Métodos Ágeis 18 Entendendo a definição e o uso do framework scrum Definição do scrum Figura 5 imagem alusiva a equipe realizando SCRUM Fonte pixabay Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos enquanto produtiva e criativamente entregam produtos com o mais alto valor possível Scrum é Leve Simples de entender Extremamente difícil de dominar Scrum é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de 1990 Ele não é um processo ou uma técnica para construir produtos em vez disso é um framework dentro do qual você pode empregar vários processos ou técnicas O Scrum deixa claro a eficácia relativa à práticas de gerenciamento e desenvolvimento de produtos de modo que você possa melhorálas O framework Scrum consiste nos times do Scrum associadas a papéis eventos artefatos e regras Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e seus sucesso Gestão de Times Métodos Ágeis 19 As regras do Scrum integram os eventos papéis e artefatos administrando as relações e interações entre eles As suas regras serão descritas ao longo deste documento IMPORTANTE Scrum não é metodologia O time scrum O Time Scrum é composto pelo Product Owner o Time de Desenvolvimento e o Scrum Master Times Scrum são autoorganizáveis e multifuncionais eles escolhem qual a melhor forma para completarem seu trabalho em vez de serem dirigidos por outros de fora do Time Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade criatividade e produtividade Times Scrum entregam produtos de forma iterativa e incremental maximizando as oportunidades de realimentação Entregas incrementais do produto Pronto garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível Figura 6 imagem alusiva a equipe Fonte Flaticon Gestão de Times Métodos Ágeis 20 O product owner O Product Owner ou dono do produto é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento Como isso é feito pode variar amplamente através das organizações times Scrum e indivíduos O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto O gerenciamento do Backlog do Produto inclui Expressar claramente os itens do Backlog do Produto Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões Garantir o valor do trabalho realizado pelo Time de Desenvolvimento Garantir que o Backlog do Produto seja visível transparente claro para todos e mostrar o que o time Scrum vai trabalhar a seguir e Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário O Product Owner pode fazer o trabalho acima ou delegar para o Time de Desenvolvimento fazêlo No entanto ele continua sendo o responsável pelos trabalhos O Product Owner é uma pessoa e não um comitê pode representar o desejo de um comitê no Backlog do Produto mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner ACESSE httpwwwscrumorg Acesso em 22082018 Gestão de Times Métodos Ágeis 21 O time de desenvolvimento O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto Pronto ao final de cada Sprint Somente integrantes do Time de Desenvolvimento criam incrementos Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo Os Times de Desenvolvimento têm as seguintes características Eles são autoorganizados Ninguém nem mesmo o Scrum Master diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis Times de Desenvolvimento são multifuncionais possuindo todas as habilidades necessárias enquanto equipe para criar o incremento do Produto O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o desenvolvedor independentemente do trabalho que está sendo realizado pela pessoa não há exceções para esta regra Individualmente os integrantes do Time de Desenvolvi mento podem ter habilidades especializadas e área de especialização mas a responsabilidade pertence ao Time de Desenvolvimento como um todo e Times de Desenvolvimento não contém subtimes dedicados a domínios específicos de conhecimento tais como teste ou análise de negócios Tamanho do time de desenvolvimento O tamanho ideal do time de desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint Gestão de Times Métodos Ágeis 22 Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade Times de Desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável Havendo mais de nove integrantes é exigida muita coordenação Times de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem a menos que eles também executem o trabalho do Backlog da Sprint Figura 7 Exemplo de equipe Fonte PIXABAY Fonte Pixabay O scrum master O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado O Scrum Master faz isso para garantir que o Time Scrum adere à teoria práticas e regras do Scrum O Scrum Master é um servolíder para o Time Scrum O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com eles e quais são úteis e quais não são O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum Gestão de Times Métodos Ágeis 23 O Scrum Master serve o Product Owner de várias maneiras incluindo Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto Claramente comunicar a visão objetivo e itens do Backlog do Produto para o Time de Desenvolvimento Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa Compreender a longo prazo o planejamento do Produto no ambiente empírico Compreender e praticar a agilidade e Facilitar os eventos Scrum conforme exigidos ou necessários Backlog do produto 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 no produto O Product Owner é responsável pelo Backlog do Produto incluindo seu conteúdo disponibilidade e ordenação Um Backlog do Produto nunca está completo Os primeiros desen volvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos Ele evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem é dinâmico mudando constantemente para identificar o que o produto necessita para ser mais apropriado competitivo e útil que existirá enquanto o produto também existir O Backlog do Produto lista todas as características funções requisitos melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões seus itens possuem os atributos de descrição ordem estimativa e valor Enquanto um produto é usado ganha valor e o mercado oferece retorno o Backlog do Produto tornase uma lista maior e mais completa Requisitos nunca param de mudar então ele é um artefato vivo por isso mudanças nos requisitos de negócio condições de mercado ou tecnologia podem causar mudanças nele Gestão de Times Métodos Ágeis 24 Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto Um Backlog do Produto é usado para descrever o trabalho previsto para o produto assim um atributo seu que agrupe itens pode ser então aplicado O refinamento é a ação de adicionar detalhes estimativas e ordem aos itens no Backlog do Produto Este é um processo contínuo em que o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto Durante o seu refinamento os itens são analisados e revisados O Time de Desenvolvimento decide como e quando o refinamento está Pronto Este refinamento usualmente não consome mais de 10 da capacidade do Time de Desenvolvimento Contudo os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do dele 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 baseadas em maior clareza e maior detalhamento quanto menor a ordem na lista menos detalhes Os itens irão ocupar o desenvolvimento na próxima Sprint são mais refinados de modo que todos os itens possam ser Prontos dentro do timebox da Sprint esses itens são considerados como Preparados para seleção no Planejamento da Sprint e geralmente adquirem este grau de transparência através das atividades de refinamento descritas acima O Time de Desenvolvimento é responsável por todas as estimativas O Product Owner deve influenciar o Time ajudando no entendimento e nas decisões conflituosas de troca mas as pessoas que irão realizar o trabalham fazem a estimativa final SAIBA MAIS Timebox na tradução literal significa caixa de tempo Ou seja o tempo para fazer um trabalho é limitado executandoo da melhor forma que puder nessa janela de tempo É uma técnica simples usada no desenvolvimento de software para rastrear o progresso e para ter o trabalho feito Gestão de Times Métodos Ágeis 25 Eventos scrum Eventos prescritos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas anteriormente Todos os eventos são eventos timebox de tal modo que todo evento tem uma duração máxima Uma vez que a Sprint começa sua duração é fixada e não pode ser reduzida ou aumentada Os eventos restantes podem terminar sempre que o propósito do evento é alcançado garantindo que uma quantidade adequada de tempo seja gasta sem permitir perdas no processo Figura 8 Exemplo de planejamento de Scrum Fonte Pixabay Além da Sprint que é um container para outros eventos cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa Estes eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar Sprint O coração do Scrum é a Sprint um timebox de um mês ou menos durante o qual um Pronto versão incremental potencialmente utilizável do produto é criado Sprints tem durações coerentes em todo o esforço de desenvolvimento Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior As Sprints são compostas por uma reunião de planejamento da Sprint reuniões diárias o trabalho de desenvolvimento uma revisão da Sprint e a retrospectiva da Sprint Gestão de Times Métodos Ágeis 26 Durante a Sprint Não são feitas mudanças que possam colocar em perigo o objetivo da Sprint As metas de qualidade não diminuem e O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês Como os projetos as Sprints são utilizadas para realizar algo Cada Sprint tem a definição do que é para ser construído um plano projetado e flexível que irá guiar a construção o trabalho e o resultado do produto IMPORTANTE Uma Sprint pode ser cancelada antes do timebox da Sprint terminar Somente o Product Owner tem a autoridade para cancelar a Sprint embora ele ou ela possa fazer isso sob influência das partes interessadas do Time de Desenvolvimento ou do Scrum Master Revisão da sprint A Revisão da Sprint é executada no final para inspecionar o incremento e adaptar o Backlog do Produto se necessário Durante a reunião Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint e as sobre próximas coisas que podem ser feitas para otimizar valor Esta é uma reunião informal não uma reunião de status e a apresentação do incremento destinase a motivar e obter comentários e promover a colaboração Esta é uma reunião timebox de 4 horas de duração para uma Sprint de um mês Para Sprints menores este evento é usualmente menor O Scrum Master garante que o evento ocorra e que os participantes entendam o seu objetivo O Scrum Master ensina a todos a manter a reunião dentro dos limites do timebox Gestão de Times Métodos Ágeis 27 A Reunião de Revisão inclui os seguintes elementos Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner SAIBA MAIS Stakeholders Em inglês stake significa interesse partici pação risco Holder significa aquele que possui De modo geral descreve uma pessoa ou grupo que tem interesse em uma empresa negócio ou indústria podendo ou não ter feito um investimento neles O Product Owner esclarece quais itens do Backlog do Produto foram Prontos e quais ainda não foram O Time de Desenvolvimento discute o que foi bem durante a Sprint quais problemas ocorreram dentro da Sprint e como estes problemas foram resolvidos O Time de Desenvolvimento demonstra o trabalho que está Pronto e responde as questões sobre o incremento O Product Owner discute o Backlog do Produto tal como está Ele ou ela projeta as prováveis datas de conclusão baseado no progresso até a data se necessário O grupo todo colabora sobre o que fazer a seguir e é assim que a Reunião de Revisão da Sprint fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint Análise de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer a seguir e Análise da linha do tempo orçamento potenciais capaci dades e mercado para a próxima versão esperada do produto O resultado da Reunião de Revisão da Sprint é um Backlog do Produto revisado que define o provável Backlog do Produto para a próxima Sprint O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades Gestão de Times Métodos Ágeis 28 Retrospectiva da sprint A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint Esta é uma reunião timebox de três horas para uma Sprint de um mês Para Sprint menores este evento é usualmente menor O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito O Scrum Master ensina todos a mantêlo dentro do timebox O Scrum Master participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo processo Scrum O propósito da Retrospectiva da Sprint é Inspecionar como a última Sprint foi em relação às pessoas aos relacionamentos aos processos e às ferramentas Identificar e ordenar os principais itens que foram bem e as potenciais melhorias e Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho Em qualquer ponto do tempo na Sprint o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado O Time de Desenvolvimento monitora o total do trabalho restante pelo menos a cada Reunião Diária O Time de Desenvolvimento acompanha estes resumos diários e projeta a probabilidade de alcançar o objetivo da Sprint Com o rastreamento do trabalho restante em toda a Sprint o Time de Desenvolvimento pode gerenciar o seu progresso Reunião diária A Reunião Diária do Scrum é um evento timeboxed de 15 minutos para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária e prever o trabalho que deverá ser feito antes da próxima Reunião Diária Gestão de Times Métodos Ágeis 29 A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade Durante a reunião os membros do Time de Desenvolvimento esclarecem 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 O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende para completar o trabalho do Backlog da Sprint A Reunião Diária aumenta a probabilidade do Time de Desenvolvimento atingir o objetivo da Sprint Todos os dias o Time de Desenvolvimento deve entender como o mesmo pretende trabalhar em conjunto como um time auto organizado para completar o objetivo da Sprint e criar um incremento esperado até o final da Sprint 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 O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária e ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do timebox de 15 minutos Ele reforça a regra de que somente os integrantes do Time de Desenvolvimento participem RESUMINDO 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 Esta é uma reunião chave para inspeção e adaptação Gestão de Times Métodos Ágeis 30 Compreendendo a teoria por trás do framework scrum Áreas de conhecimento do gerenciamento de projetos aplicáveis A possibilidade de mudança do gerenciamento de projetos tradicional para o gerenciamento de projetos ágil requer uma atenção especial em cinco áreas de conhecimento definidas Gerenciamento de Recursos Humanos Gerenciamento da Qualidade Gerenciamento da Integração Gerenciamento do Escopo Gerenciamento do Tempo Tanto a abordagem ágil quanto a abordagem tradicional identificam as três restrições de um projeto como sendo custo tempo agenda e escopo Para a abordagem tradicional no entanto o escopo do projeto deve ser fixado para que tempo e custo possam ser estimados Figura 9 Exemplo de gerenciamento de tempo e integração Fonte pixabay Já as abordagens ágeis se manifestam acreditando que o escopo estará em constante mudança então tempo e custo devem ser fixados Em abordagens ágeis a estratégia de comandocontrole deve ser substituída por facilitação colaboração e suporte Gestão de Times Métodos Ágeis 31 Figura 10 Capa do livro Guia PMBOK Fonte google Uma abordagem segundo o PMBOK Project Management Body of Knowledge e do PMI 2004 Project Management Institute nos leva a perceber que a preocupação está na definição do escopo em um alto nível que permita o entendimento do trabalho inclusive com a participação do cliente para a priorização das funcionalidades o cronograma é orientado ao produto que será produzido em iterações repetições curtas que contribuem para uma redução dos conflitos pela cumplicidade no processo as alterações são incorporadas dentro da iteração mais apropriada e de comum acordo com o cliente podendo elevar o custo final os padrões a serem seguidos devem ser estabelecidos no início do projeto e estarem concentrados na programação em pares a monitoração e o controle dos riscos ocorrem durante todo o processo de desenvolvimento a comunicação é colaborativa e direta entre todos os membros da equipe o que exige certo grau de maturidade por parte da organização do cliente e da equipe todos os participantes do projeto executam suas tarefas planejam e tomam decisões em conjunto compartilhando suas experiências o processo de aquisição deve ser evitado em função da volatilidade dos requisitos a atuação colaborativa da equipe com o cliente favorece um major grau de informalidade e o conhecimento implícito é privilegiado o papel do gerente de projetos é voltado para o papel de facilitador ou coordenador das atividades Gestão de Times Métodos Ágeis 32 A dinâmica do scrum Existem papéis e responsabilidades bem definidos assim como diversas etapas que devem ser cumpridas que visam produzir de forma rápida ao mesmo tempo em que atende às necessidades do cliente O dono do produto ou Product Owner representa os stakeholders e o negócio os membros da equipe ou Team é formada por cerca de 7 pessoas Equipes com poucos envolvidos e multidisciplinares são uma das características marcantes da metodologia Para gerenciar o projeto surge a figura do Scrum Master que funciona como o gerente de projeto dirigindo a equipe para que os objetivos e metas sejam atingidos Ele garante que o processo está sendo seguido Participando das reuniões diárias revisão da Sprint e planejamento O gerente de projeto no apoio Um dos papéis mais polemizados quando o assunto é Scrum é o tradicional gerente de projetos Primeiro porque este papel específico não aparece nas suas definições de papéis e segundo porque ele defende que o time deve ser autogerencial o que resumidamente é interpretado como não havendo a necessidade de ter um gerente de projetos na equipe Figura 11 O gerenciador de Scrum Fonte pixabay Gestão de Times Métodos Ágeis 33 Adaptabilidade O controle de processos empíricos e a entrega iterativa fazem com que os projetos sejam adaptáveis e abertos à incorporação de mudanças Enquanto os métodos tradicionais de desenvolvimento em especial o cascata valorizam análise extensa e definições rígidas de requisitos visando segurança ou a falsa sensação dela o Scrum abraça a imprevisi bilidade que um projeto longo possui ao inserir mais resiliência neles Transparência Na administração tradicional a Gestão à Vista não é algo novo e comprovadamente vantajoso para as organizações Isso porque permite que todos vejam o que está acontecendo e consigam tomar atitudes em relação a isso Figura 12 Exemplo de gráfico que denota transparência Fonte pixabay Scrum fala de adaptação mas não há como se adaptar ao que não se consegue ver e por isso que o primeiro pilar da metodologia é a transparência Sem transparência não há Inspeção adequada Adaptação Engajamento Confiança Evolução do time Sucesso no projeto Gestão de Times Métodos Ágeis 34 Gerentes temem expor informações que possam gerar medos e conflitos no Time Ao fazerem isso impedem que o time amadureça e realmente abrace a causa Feedback contínuo O feedback contínuo é fornecido através de processos denominados como a Reunião Diária e a Sprint Review O Scrum fornece diversos mecanismos de feedback o que garante o segundo pilar do framework inspeção que leva à adaptação em um ciclo virtuoso que gera a melhoria contínua Figura 13 Exemplo de Feedback contínuo Fonte pixabay Feedback contínuo não é dar tapinhas nas costas na reunião de final de ano da empresa Feedback contínuo tem a ver com transparência pois o time precisa saber se suas ações estão gerando resultado Você precisa saber se está no caminho certo O seu colega precisa saber como pode lhe ajudar e você precisa saber se ele precisa de ajuda também Melhoria contínua As entregas melhoram progressivamente Sprint por Sprint através do processo de refinamento do Backlog do Produto e do processo em si Na metodologia de inovação em startups denominada Lean Startup existe um ciclo chamado construirmediraprender buildmeasurelearn no original que trabalha da seguinte maneira Gestão de Times Métodos Ágeis 35 1 Você constrói um incremento de produto 2 Você mede o desempenho dele 3 Você aprende com os erros e refinao 4 Volte ao passo 1 E assim o é também no Scrum O framework é enxuto apenas 19 páginas Talvez não cubra nem sequer 10 da ciência da gestão de projetos Mas os seus princípios fundamentais te ajudam a pensar de uma maneira diferente com o mindset correto Ele próprio te ensina que a inspeção vai te levar inerentemente ao aprendizado adaptação e com isso à melhoria contínua dos processos e produtos Esqueça aquela ideia que alguns métodos pregam que você deve apenas confiar cegamente em um livro e seus problemas estarão resolvidos DEFINIÇÃO Lean startup Esse conceito no universo da administração envolve um trabalho de enxugar identificação eliminar desperdícios nos processos e está muito ligado ao ambiente de startups de tecnologia Mindset traduzindo ao pé da letra seria mente configurada ou configuração da mente O conceito significa o conjunto de atitudes mentais que influencia diretamente nos nossos comportamentos e pensamentos Entrega contínua de valor Os processos iterativos permitem a entrega contínua de valor tão frequente quanto o exigido pelo cliente Tenha em mente que ninguém compra software Ninguém Só quem gosta de software é programador Cliente gosta de solução que entrega valor Se o seu time demora demais eou não entrega valor ele não vai ir muito longe A chave aqui é entregar valor continuamente em pequenas porções mas frequentes deixando sempre o cliente satisfeito e com um gostinho Gestão de Times Métodos Ágeis 36 de quero mais A cada iteração do Scrum sprint um incremento de produto é entregue ao cliente um que gera valor ao mesmo É assim que tem que ser em todos os projetos Você nunca terá como entregar tudo o que o cliente quer no prazo que ele quer e dentro do orçamento dele Isso não existe Mas o processo de criar e priorizar um Backlog de Produto garante que as exigências de maior valor ao cliente sejam atendidas primeiramente e que o valor que ele tanto busca não confunda valor com custo seja entregue em partes à cada iteração Uma abordagem colaborativa com stakeholders como a do Scrum e a ênfase no valor de negócio garantem uma estrutura orientada para o cliente E não orientada ao software Seus clientes não querem seus softwares Eles querem o valor gerado pelos mesmos Eles querem ser melhores do que eram antes de comprar seu software Eficiência O Timeboxing e a minimização de trabalho nãoessencial conduzem a níveis mais altos de eficiência As coisas mais excêntricas existentes no Scrum são em prol da eficiência e por isso que seguir o Scrum à risca é tão importante principalmente em equipes imaturas do ponto de vista de agilidade Pense nas timeboxes restrições pétreas quanto à duração de eventos no ciclo de desenvolvimento Sprints de x semanas Reuniões de x horas E por aí vai Isso não é algo negociável Esse tipo de restrição estimula os desenvolvedores do time a pensar no que é mais importante ser desenvolvido hoje rumo ao objetivo de amanhã Não há tempo a perder com coisas que não gerem valor à meta da sprint Estimula o Product Owner a manter o backlog priorizado com o que realmente deve entrar no produto na próxima sprint deixando para um futuro incerto o que não é essencial à aplicação Gestão de Times Métodos Ágeis 37 Figura 14 Exemplo de eficiência Fonte pixabay Todos sabemos ou deveríamos saber que a falácia da próxima feature e a overengineering são alguns dos piores maus que podem arruinar um projeto de software e até mesmo uma empresa As restrições de tempo do Scrum e as demais também te ajudam a não cair nessas tentações como essa outra de reescrever todo o código da sua aplicação para que fique melhor por exemplo DEFINIÇÃO Feature é uma funcionalidade ou uma característica É algo que tem uma função Overengineering quando se constrói um código mais sofisticado do que ele precisa ser Motivação Os processos de conduzir a reunião diária e de retrospectiva da Sprint conduzem a níveis mais altos de motivação entre os colaboradores É necessário um ambiente de alta confiança para que o time se sinta motivado a seguir em frente em prol dos objetivos gerais da Sprint Processos do Scrum como a Reunião Diária e a Retrospectiva da Sprint promovem a transparência pilar 1 lembra e a colaboração resultando em um ambiente de trabalho de alta confiança e garantindo baixo atrito entre os colaboradores além de uma alta motivação uma vez que o time tem o suporte e aval necessários para que consiga avançar sem impedimentos Gestão de Times Métodos Ágeis 38 Figura 15 Exemplo de motivação Fonte Flaticon Quando os Times confiam sem si mesmos e seus líderes confiam no time a motivação se torna algo inabalável gerando a responsabilidade coletiva e o comprometimento que é o que todo gerente quer da sua equipe e toda empresa quer ver nos seus funcionários O processo de aprovar estimar e comprometerse às tarefas ou histórias de usuário casos de uso etc permite que os membros do time se sintam responsáveis pelo projeto e por seu trabalho resultando em uma qualidade muito maior Não importa se você vai usar planning poker ou não mas se não houver confiança no time para tomar essas decisões não haverá motivação para executar as tarefas Tudo começa na confiança Alta velocidade Uma estrutura de colaboração permite que os times multifuncionais atinjam o seu pleno potencial e alta velocidade Se o seu time vem vencendo nos demais quesitos como motivação entrega contínua de valor transparência adaptação entre outros você terá o que todo gerente de software almeja alta velocidade DEFINIÇÃO Planning poker é uma técnica do Scrum que permite ao time do projeto gerar estimativas rapidamente Gestão de Times Métodos Ágeis 39 Não agilidade não é entregar software pura e simplesmente mais rápido É sobre entregar valor mais cedo Mas quando você entrega valor mais cedo a percepção que todos têm interna e externamente é que o time está avançando mais rápido O que vale mais um professor sedentário correndo em linha reta por 100m ou o Usain Bolt correndo em ziguezague para chegar no mesmo destino que está 100m à frente É o mesmo para software Se você não está trabalhando com um backlog priorizado não está entregando software com foco no cliente ou seja entregando valor pra ele você está andando em zigue zague rumo ao mesmo objetivo que poderia estar perseguindo em linha reta A alta velocidade obtida com o Scrum não está na quantidade de linhas de código que seu time vai escrever por Sprint mas sim nas linhas certas que serão escolhidas para serem escritas Aquelas que trarão os maiores resultados para o cliente em menos tempo Isso é velocidade de maneira inteligente Ambiente inovador Os processos de Retrospectiva da Sprint e de Review da Sprint criam um ambiente de introspecção aprendizagem e adaptabilidade que levam a um ambiente de trabalho inovador e criativo Não custa repetir transparência inspeção e adaptação Os três pilares do Scrum Esse ciclo virtuoso é a chave para a inovação A inspeção e adaptação frequentes do Scrum levam o seu produto sempre aonde ele deve estar agora neste momento E não conforme foi planejado um ano atrás com a diretoria Embora seja extremamente válido e aconselhável definir as estratégias a médio e longo prazo é a execução em curto prazo aliado aos pilares do Scrum que vão garantir a existência do projeto para talvez chegar no destino desejado Se ele ainda fizer sentido um ano depois de traçado Gestão de Times Métodos Ágeis 40 Figura 16 Exemplo de inovação Fonte Flaticon A chance de revisitar o processo e ajustálo a cada Sprint é única e dá uma vantagem muito grande ao time frente às metodologias tradicionais a vantagem de poder errar Mas errar rápido e aprendendo com esse erro para acertar Ninguém tem as respostas sobre como os softwares precisam ser desenvolvidos em todos os casos nem o Scrum mas a inspeção e adaptação às mudanças devem ser o cerne dos projetos Gestão de Times Métodos Ágeis 41 Entender os valores do método scrum Como sabemos o Scrum é uma metodologia ágil para gestão e planejamento de projetos Nele os projetos são divididos em ciclos com atividades que devem ser executadas dentro de um cronograma As metodologias ágeis de desenvolvimento de software são iterativas ou seja o trabalho é dividido em iterações As funcionalidades a serem implementadas no projeto são mantidas em uma lista para criála ou definir as atividades prioritárias são feitas pequenas reuniões de planejamento As reuniões também servem para disseminar conhecimento sobre o que foi feito no dia anterior identificar impedimentos e priorizar o trabalho do dia que se inicia Figura 17 Exemplo de valores do método Fonte pixabay Papel e os princípios do scrum Mostrar a eficácia das suas práticas de desenvolvimento para que você possa melhorá las enquanto provê um framework dentro dos quais produtos complexos podem ser desenvolvidos O Scrum é fundamentado nas teorias empíricas de controle de processo e tem como base para sua implementação três pilares transparência inspeção e adaptação A metodologia emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos Gestão de Times Métodos Ágeis 42 Transparência Os aspectos do processo que afetam o resultado devem ser visíveis àqueles que gerenciam no Esses aspectos não apenas devem ser transparentes mas também o que está sendo visto deve ser conhecido O que isso quer dizer Quando alguém que inspeciona um processo acredita que algo está pronto isso deve ser equivalente à sua definição de pronto A transparência se dá através da comunicação verbal ou escrita e ocorre em diversos momentos por exemplo Quando o cliente Product Owner descreve as funcio nalidades esperadas para o produto Quando o cliente informa as prioridades das entregas Quando o Scrum Master apresenta o planejamento e o andamento das sprints Quando a equipe comunica diariamente o andamento do trabalho Quando a equipe atualiza um kanban deixando claro o andamento do desenvolvimento do produto Quando a entrega parcial é realizada e o cliente tem a oportunidade de dar um feedback antes do final do projeto Inspeção Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho Gestão de Times Métodos Ágeis 43 Figura 18 Exemplo de inspeção Fonte Flaticon A inspeção é um princípio tão forte que o Scrum considera que o processo de testes está dentro da própria Sprint Isso nos remete aos conceitos de integração contínua test driven development e pair programming que são formas de garantir a qualidade enquanto o produto está sendo produzido ao invés de controlar a qualidade só no final A inspeção se dá por exemplo através dos seguintes itens No conceito de ready definition of ready No conceito de done definition of done Na reunião de grooming Quando se estima os story points de uma história de usuário Reunião de revisão review meeting com o cliente product owner Diariamente quando alguém termina uma história e um membro do grupo faz a verificação do DoD Na verificação de bugs e sua respectiva correção Adaptação O inspetor determinará a partir da inspeção que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável ele deverá ajustar o processo ou o material que está sendo processado Esse ajuste deve ser feito o mais rápido Gestão de Times Métodos Ágeis 44 possível para minimizar desvios posteriores A adaptação é a grande vedete dos projetos Scrum pois ele pode começar com um conjunto de histórias e terminar relativamente diferente O PO pode constituir modificar e excluir estórias ao término de cada Sprint A adaptação se dá por exemplo através dos seguintes itens No planejamento do projeto quando o PO prioriza as histórias No review de uma Sprint quando o PO reprioriza as histórias itens do backlog No conceito de meta da Sprint quando o time tem a liberdade de realizar mais ou menos histórias do que estava planejado No conceito de velocidade que difere de progresso quando após algumas Sprints se tem a velocidade real do time e se pode calcular o tempo necessário para terminar o projeto Pontos para inspeção e adaptação em scrum Daily Scrum reunião utilizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho Reuniões de Revisão da Sprint e de Planejamento da Sprint utilizadas para inspecionar o progresso em direção à Meta da Release e para fazer as adaptações que otimizem o valor da próxima Sprint Retrospectiva da Sprint utilizada para revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva recompensadora e gratificante Gestão de Times Métodos Ágeis 45 Valores que sustentam os pilares do scrum Figura 19 Exemplo de valores Fonte Flaticon Comprometimento cada pessoa deve estar comprometida com os objetivos do time e com a meta do Sprint Foco o time mantém o foco constante na meta da Sprint e nos objetivos do time Coragem trabalha com coragem para fazer a coisa certa e encarar os problemas difíceis dentro dos limites do framework Respeito os membros do time respeitam uns aos outros como pessoas capazes e independentes Abertura o Time Scrum e Stakeholders concordam em estarem abertos a respeito do trabalho a ser feito e dos desafios com a sua execução Scrum não descreve o que fazer em cada situação Ele é usado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer Ele é mais que isso representa um conjunto de valores princípios e práticas que fornecem a base para que a sua organização adicione suas práticas particulares de planejamento e que sejam relevantes para a sua realidade com uma versão de Scrum exclusivamente sua No livro Scrum A arte de fazer o dobro do trabalho na metade no tempo em que Jeff Sutherland autor e idealizador do Scrum exemplifica que se exige prática e atenção para se chegar a um novo estado no qual as coisas apenas fluem para que o resto aconteça Gestão de Times Métodos Ágeis 46 BIBLIOGRAFIA COHN Mike Gilleanes T A Uma Introdução ao Scrum 2012 FIGUEIREDO A M Gerenciamento de Projetos Ágeis Golden Cross 2007 KERZNER H Project Management A system approach to planning scheduling and controlling John Wiley Sons 2002 LEITAO Rogério S Escritório de Projetos Definindo uma estratégia para projetos de TI 2006 LESSA L O Papel do PMO nas Estruturas Organizacionais Belo Horizonte PMI Chapter MG 2006 Disponível em httpsbitly3dg7Sal Acesso em 14 fev 2015 PROJECT MANAGEMENT INSTITUTE A Guide to the Project Management Body Of Knowledge PMBOK Guide 3 ed Pennsylvania 2004 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