Gestão de Times: Métodos Ágeis

Unidade 2 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 Entendendo um time scrum 12 As características essenciais para um time scrum 13 Auto organização 13 Fortalecida 14 Colaboração 14 Objetivo comum 14 Tamanho perfeito 14 Múltiplas habilidades 14 Cultura 15 Product owner 16 Principais responsabilidades 16 Participação no planejamento 16 Grooming do paroduct backlog 17 Definir os critérios de aceitação e verificar se foram atendidos 17 Colaborar com a equipe de desenvolvimento 18 Colaborar com o resto da empresa 19 Característicashabilidades pessoais 19 Conhecimento do negócio 19 Habilidade com pessoas 19 Autoridade 20 Responsabilidade 20 Dia a dia do product owner 21 Time de desenvolvimento 24 Times com funções específicas 26 Principais responsabilidades 27 Realizar execução sprint 27 Inspeção e adaptação 27 Grooming do product backlog 27 Planejar a sprint 27 Times de alta performance 28 Custo x adequação 29 Pilares escopo x custo x prazo 30 Desenvolvimento contínuo 31 Scrum master 33 Principais responsabilidades 33 Coach 33 Líder servidor 33 Autoridade no processo 34 Escudo contra interferências 34 Removedor de impedimentos 34 Agente de mudança 35 Perfil scrum master 35 Conhecimento 35 Questionador 35 Paciente 35 Colaborativo 36 Protetor 36 Transparente 36 O dia a dia do scrum master 36 Scrum master x product owner 37 Scrum master fraco x product owner fraco fracasso lento 37 Scrum master bom x product owner fraco fracasso rápido 37 Scrum master ruim x product owner bom ganhos rápidos mas insustentáveis 38 Scrum master bom x product owner bom sucesso permanente 38 Gestão de Times Métodos Ágeis 9 UNIDADE 02 O TIME SCRUM Gestão de Times Métodos Ágeis 10 O Time Scrum é o processo em que além de selecionar as pessoas para fazerem parte de uma equipe o Dono do Produto e o Scrum Master em conjunto de preferência irão criar um plano para o sucesso Mas o que é isso É uma visão para o time de como o time pode ser melhor bem relacionado e feliz Formar o time não é apenas escolher as pessoas que sabem fazer mas as pessoas que sabem fazer e se relacionar Sabem se relacionar Então essa capacidade talvez seja mais importante do que saber fazer Ainda mais importante é ter a capacidade de aprender e compartilhar um time multifuncional como no Scrum depende da capacidade de comunicação das pessoas Também é preciso pensar em mais do que apenas no time mas em todas as partes interessadas que tenham interesses positivos e negativos Formar o Time é criar aquele olho que tudo vê que tudo compreende e fazer com que todos sejam engajados na medida certa para que o projeto seja um sucesso Entendeu Ao longo desta unidade letiva iremos esclarecer esses conceitos INTRODUÇÃO Gestão de Times Métodos Ágeis 11 Olá Seja muito bemvindo à Unidade 02 Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos 1 Perceber e discernir sobre o perfil típico dos membros de um time de projetos de software aplicáveis ao método scrum 2 Entender quem é e qual o papel do product owner 3 Gerenciar membros de um time de desenvolvimento administrando conflitos e controlando os principais indica dores doprojeto relacionados aos recursos humanos 4 Compreender e absorver o papel e as competências do facilitador e líder do projeto scrum master OBJETIVOS Gestão de Times Métodos Ágeis 12 Entendendo um time scrum INTRODUÇÃO O Time Scrum tem um papel fundamental no desenvol vimento do projeto afinal de contas é o time que transforma requisitos em funcionalidades enfim é o time quem entrega e desenvolve todo o produto O Scrum Team É multifuncional com sete mais ou menos dois membros Seleciona o objetivo do Sprint Sprint Goal e especifica os produtos de trabalho necessários Tem a liberdade de fazer qualquer coisa dentro das diretrizes do projeto para alcançar o objetivo do Sprint É autoorganizável e planeja suas atividades Apresenta os produtos de trabalho ao Product Owner Membros do Scrum Team não têm nenhum dos papéis tradicionais da engenharia de software como programador designer testador ou arquiteto Todos no projeto trabalham juntos para finalizar a lista de atividades que eles coletivamente se comprometeram a realizar durante um Sprint Scrum Teams desenvolvem um profundo espírito de camaradagem e o sentimento de estamos juntos nisso Um Scrum Team típico possui de 5 a 9 pessoas mas é possível escalar utilizando um Scrum de Scrums Afinal quem são as pessoas que formam essa equipe Quais são suas funções e responsabilidades no desenvolvimento de um projeto ágil Será que seu time está completo ou você poderia aumentar a produtividade complementando as funções Vamos conferir e tirar quaisquer dúvidas a esse respeito agora mesmo Gestão de Times Métodos Ágeis 13 As características essenciais para um time scrum O time Scrum garante que as coisas possam acontecer da forma que o framework prevê As características de um time Scrum eficiente são muito próprias e únicas para esses projetos Em um projeto Scrum são os membros da equipe Scrum que são responsáveis pela entrega do produto ou serviço desejado e não o Scrum em si Pessoas acima de processos e ferramentas certo Por isso devemos ter cuidado na formação das equipes Scrum Essa equipe será responsável pelo sucesso de seu projeto e irá garantir que aquilo que precisa acontecer realmente aconteça Até mesmo a felicidade delas em trabalhar com seus projetos irá impactar o valor que está sendo extraído do produto ou serviço que está sendo criado O Time Scrum às vezes é chamado somente de equipe de desenvolvimento uma vez que são responsáveis pelo desenvolvimento do produto serviço ou outros resultados É constituída por um grupo de indivíduos que utilizam as histórias de usuário no Sprint Backlog para criar as entregas para o projeto SBOK 2013 Edition Figura 1 imagem alusiva a organização Fonte pixabay Auto organização Os membros da equipe Scrum são indivíduos motivados que não esperam seus superiores para entender quais tarefas eles precisam fazer Eles assumem a responsabilidade compartilham o risco tomam as decisões e trabalham em conjunto para um objetivo comum Gestão de Times Métodos Ágeis 14 Fortalecida A equipe Scrum ou a equipe de desenvolvimento é sempre formada com os recursos necessários para entregar os produtos ou serviços desejados juntamente com a autoridade para tomar as decisões Ela se renova entre si sem mudar as pessoas A equipe interage entre si com responsabilidades individuais e conjuntas Colaboração Gerenciamento de projetos é um processo de criação de valor compartilhado com equipes que trabalham em conjunto para oferecer ganho de performance no projeto A equipe de scrum compartilha conhecimento ideias riscos e responsabilidades além de garantir um trabalho em harmonia com os membros da equipe para entregar os resultados desejados Objetivo comum Dentro da equipe os indivíduos devem trabalhar em conjunto para um objetivo comum O objetivo da equipe como um todo deve sobrepor os seus objetivos individuais e o conjunto acaba sendo mais importante e gera mais valor do que a soma das partes Tamanho perfeito Uma pequena equipe Scrum pode não ter a habilidade necessária para desenvolver o produto ou serviço e uma grande equipe Scrum pode estragar a ideia de dinamismo e colaboração contínua entre a equipe Conforme definido no SBOK o tamanho ideal da equipe de Scrum deve ser de seis a dez pessoas pois isso irá garantir que a equipe Scrum seja grande o suficiente para possuir todas as habilidades necessárias para o projeto e pequena o suficiente para colaborar entre si durante o projeto Múltiplas habilidades A Equipe de Scrum deve possuir coletivamente as habilidades necessárias para garantir todas as entregas do projeto Durante a formação da equipe Scrum os membros da equipe devem ser selecionados tendo Gestão de Times Métodos Ágeis 15 em mente as habilidades necessárias para gerar valor nas entregas que o projeto terá pela frente Cultura Aconselhase a formar uma equipe Scrum com os membros instalados presencialmente na organização Isso garante colaboração e coordenação entre os membros da equipe de forma organizada e aumento do grau de colaboração para seguir o que o framework Scrum busca ACESSE httpsbitly3dl1fDz Acesso em 22 Set 2018 Nas abordagens tradicionais de desenvolvimento de software é comum encontrarmos vários tipos de trabalho bem separados por exemplo arquiteto programador testador administrador de banco de dados prototipador etc O Scrum define o papel da equipe de desenvolvimento que é nada menos do que uma coleção desses tipos de pessoas Os membros da equipe de desenvolvimento em conjunto devem possuir as habilidades necessárias para entregar o que foi solicitado pelo Product Owner O Time Scrum é comumente chamado de Equipe de Desenvol vimento este é o termo mais usado mesmo que nem sempre seja composta somente por desenvolvedores Figura 2 Gestão de Times Métodos Ágeis 16 Product owner O Product Owner é o ponto central do projeto ágil e é quem exerce a liderança sobre o produto que está sendo desenvolvido É ele quem diz o que precisa e o que não precisa ser feito em relação ao produto que está sendo desenvolvido É um dos três papéis que constituem uma Equipe Scrum clássica os outros são o Scrum Master e a Equipe de Desenvolvimento O Product Owner é quem faz a ponte entre a área de negócios e a Equipe Scrum ACESSE httpsbitly2NmioCe Acesso em 22 Set 2018 Principais responsabilidades Este é claramente um papel para uma pessoa em tempo integral com responsabilidades significativas Na verdade você vai ver que a quantidade de coisas que o Product Owner tem que fazer e se preocupar pode até parecer muito para uma única pessoa Na maioria das vezes o Product Owner é uma única pessoa mas em algumas circunstâncias pode se fazer necessário um time de Product Owners Participação no planejamento O Product Owner é um participantechave nas atividades de planejamento de Produto Release e Sprints Durante o planejamento do Produto o Product Owner trabalha com todas as partes interessadas da empresa diretoria demais departamentos etc para conseguir visualizar o produto ideal Durante o planejamento de Release o Product Owner trabalha com as partes interessadas e a Equipe Scrum para definir o conteúdo do próximo lançamento Gestão de Times Métodos Ágeis 17 Durante o planejamento do Sprint o Product Owner trabalha com a Equipe de Desenvolvimento para definir um objetivo para o Sprint Grooming do product backlog É o Product Owner quem supervisiona toda a preparação e refinamento também chamado de Gromming do Product Backlog o que inclui criar atualizar estimar e priorizar os itens IMPORTANTE Não é o Product Owner quem realiza todo o trabalho de Grooming sozinho e ele também não estima os itens é a Equipe de Desenvolvimento quem faz isso mas ele deve estar disponível para perguntas e esclarecimentos durante estimativa Ele é o principal responsável para que a atividade de Grooming seja feita em prol de um fluxo de entregas que gere valor ao projeto Definir os critérios de aceitação e verificar se foram atendidos O Product Owner é responsável por definir os critérios de aceitação para cada item do Product Backlog o Scrum Master é quem o ajuda com isso O Product Owner deve assegurar que os critérios de aceitação e testes de aceitação com frequência específicas foram criados antes que o item seja considerado na reunião de planejamento de Sprint Sem eles a equipe teria uma incompleta compreensão do item e não estaria pronto para incluílo em um Sprint O Product Owner é responsável por confirmar se os critérios foram satisfatoriamente atendidos Ele pode optar por executar os testes de aceitação ele mesmo ou pode pedir a ajuda de usuários experientes mas o Product Owner é quem dá a palavra final se um item atende todas as expectativas É interessante que o Product Owner verifique os critérios de aceitação durante a execução do Sprint ao invés de esperar até a revisão Gestão de Times Métodos Ágeis 18 do Sprint Ao fazer isso o Product Owner pode identificar erros e mal entendidos que a equipe pode corrigir antes da revisão Sprint Colaborar com a equipe de desenvolvimento O Product Owner deve colaborar frequentemente com a Equipe de Desenvolvimento de uma forma muito direta e estreita exigindo comprometimento diário Muitas organizações que recém adotam Scrum falham neste ponto não promovendo o engajamento adequado do Product Owner com a Equipe de Desenvolvimento É mais fácil compreender a importância disso quando comparamos com o método tradicional de desenvolvimento em que o envolvimento do usuário é muito maior no início do projeto concepção levantamento de requisitos cai durante o desenvolvimento em si atividades mais técnicas como design codificação e testes unitários e volta a ter envolvimento novamente quase no final do projeto para testar o que foi desenvolvido O problema do desenvolvimento tradicional é que geralmente o usuário descobre que o que foi desenvolvido não está exatamente como ele esperada e agora é muito tarde ou é muito caro para fazer as mudanças pelo menos nesta versão Vejamos agora um exemplo de uma não rara comunicação em projetos que não usam o Scrum Cliente Se vocês tivessem lido as minhas especificações com mais cuidado vocês teriam construído o que eu realmente queria Equipe de Desenvolvimento Bem se você tivesse escrito o seu documento de forma mais clara teríamos construímos algo diferente Nós construímos o que você pediu Usando Scrum construímos uma funcionalidade de cada vez e não uma fase de cada vez Isto significa que realizamos todas as atividades para criar uma determinada funcionalidade design codificação testes durante um Sprint Portanto um alto nível constante de engajamento do Product Owner é essencial E o melhor disso tudo é que aquele diálogo Gestão de Times Métodos Ágeis 19 de troca de acusações que foi citado raramente acontece em projetos em que o Scrum é adotado de forma correta Colaborar com o resto da empresa O Product Owner é o portavoz de toda a comunidade de partes interessadas internas e externas da empresa Partes interessadas internas podem incluir responsáveis por sistemas internos executivos área de marketing e vendas etc As partes interessadas externas podem incluir clientes usuários parceiros órgãos reguladores entre outros O Product Owner deve trabalhar em estreita colaboração com toda a comunidade de partes interessadas para recolher necessidades e sintetizar uma visão coerente para orientar o desenvolvimento do produto Característicashabilidades pessoais Existem inúmeras características que podemos destacar em um bom Product Owner porém podemos agrupálas em quatro grandes categorias Conhecimento de Negócio Habilidades Pessoas Autoridade Responsabilidade Conhecimento do negócio O Product Owner deve ser um visionário capaz de sintetizar a visão do produto e levar a equipe para alcançar essa visão Para ser eficaz na criação e execução da visão O Product Owner deve ter o conhecimento e domínio do negócio Habilidade com pessoas Um Product Owner também deve ser a voz do cliente o que requer um bom relacionamento com esses É normal que muitas vezes as pessoas tenham necessidades conflitantes portanto o Product Owner Gestão de Times Métodos Ágeis 20 deve ser um bom negociador e sempre buscar um consenso Ele é o eixo entre a comunidade de interessados no projeto e o resto da Equipe Scrum esta posição exige uma boa comunicação para transmitir as informações da forma mais apropriada Autoridade O Product Owner deve ter a autoridade necessária na organização para tomar decisões Este item é tão crucial para o sucesso do projeto Scrum que vou repetir em letras garrafais IMPORTANTE O product owner deve ter a autoridade para tomar decisões Um problema frequente em empresas que recém adotam Scrum é que a pessoa selecionada para ser o Product Owner não tem poderes para tomar todas as decisões importantes do projeto Então tal pessoa não deve ser o Product Owner simples assim O Product Owner também deve estar preparado para tomar as decisões mais duras como mudanças de escopo data e orçamento Estas decisões devem ser tomadas em tempo hábil e não devem ser revertidas sem uma boa razão Responsabilidade O Product Owner é o responsável por entregar bons resultados do ponto de vista de negócios Isso não quer dizer que a Equipe Scrum não tem sua parcela de responsabilidade nisso O ponto aqui é enfatizar que o Product Owner é responsável por se certificar que os recursos estão sendo usados da melhor forma economi camente falando para atingir os resultados de negócio esperados Gestão de Times Métodos Ágeis 21 O Product Owner é um membro da Equipe de Scrum e portanto deve entender que os bons resultados econômicos são impossíveis sem os esforços colaborativos da Equipe Scrum como um todo Desta forma o Product Owner deve trabalhar junto com a Equipe de Desenvolvimento e Scrum Master para que esta parceria resulte em resultados satisfatórios É interessante que tanto o Product Owner quanto o Scrum Master criem um ambiente na equipe como o da história dos 3 mosqueteiros Um por todos e todos por um Dia a dia do product owner Durante as semanas 1 e 2 o Product Owner está envolvido no planejamento do produto ou portfólio de produtos Após a conclusão do planejamento do produto este poderá ser submetido para alguma aprovação interna da empresa para avaliação econômica estratégica etc Na semana 3 o Product Owner já pode planejar o início do primeiro Release Isso geralmente é feito através de uma reunião que inclui todas as partes interessadas internas os membros da Equipe de Desenvolvimento e possivelmente as partes interessadas externas para gerar um Product Backlog de alto nível que pode ser usado durante o planejamento do Release Após o esta reunião o Product Owner participa de um workshop provavelmente uma série de reuniões ao longo de um dia ou dois no qual os membros da Equipe de Desenvolvimento ou uma equipe substituta caso a equipe atual ainda não tenha sido atribuída estimarão o tamanho de um modo mais geral dos itens do Product Backlog Com isso o Product Owner pode promover a reunião de Planejamento do Release Como alguns itens do Product Backlog já foram estimados esta reunião é mais focada Gestão de Times Métodos Ágeis 22 na priorização e escolha de quais itens serão entregues no Release Para a maioria dos projetos esta atividade não deve demorar mais de um ou dois dias para ser concluída Após o planejamento do release a equipe Scrum realiza o primeiro Sprint No início do Sprint o Product Owner supervisiona a atividade de planejamento de Sprint Durante a execução de Sprint o Product Owner pode participar das reuniões diárias Daily Scrums da equipe isso nem sempre é possível mas é uma boa prática O Product Owner também deve estar disponível normalmente todos os dias para responder às questões e para testar funcionalidades conforme elas forem disponibilizadas para testes Se o Product Owner já sabe que ele não poderá estar disponível todos os dias para executar essas responsabilidades ele deve delegálas para uma pessoa apropriada O Product Owner também realiza constantemente o Grooming do product backlog o que inclui escrever novos itens e refinar os itens existentes No final do Sprint o Product Owner participa das duas atividades de Inspeção e Adaptação a Revisão de Sprint Sprint Review e a Retrospectiva do Sprint Após isso o ciclo se repete e o Product Owner participa da próxima atividade de planejamento de Sprint até o final do projeto Figura 3 Fonte O Autor Gestão de Times Métodos Ágeis 23 O Product Owner é responsável por maximizar o valor do trabalho que o Time de Scrum faz é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time Essa pessoa mantém o Product Backlog e garante que ele está visível para todos Todos sabem quais itens têm a maior prioridade de forma que todos saibam em que se irá trabalhar O Product Owner é uma pessoa e não um comitê Podem existir comitês que aconselhem ou influenciem essa pessoa mas quem quiser mudar a prioridade de um item terá que convencer o Product Owner Gestão de Times Métodos Ágeis 24 Time de desenvolvimento O time de desenvolvimento como o próprio nome diz é o responsável por desenvolver o produto Ele é responsável por transformar itens do Backlog do Produto em incremento de software potencialmente utilizável Somente membros do Time de Desenvolvimento entregam incrementos do Software mais ninguém É importante frisar que o Time de Desenvolvimento não é feito só por programadores O time precisa ser composto por todas as competências necessárias para que o produto que se deseja desenvolver seja construído pelo time sem dependência de qualquer outra pessoa externa ao time Exemplo Se o produto é um software para Web desenvolvido em Java com banco de dados Oracle você irá precisar compor o time com analista de sistemas programadores Java web design alguém com conhecimento em Oracle ou até um DBA se for algo muito complexo e testadores Nenhum item de Backlog selecionado por esse time poderá ser terceirizado para outra equipe Não é correto fazer por exemplo com que o web design que está em outra equipe faça o Frontend para que o time de desenvolvimento faça o Backend e teste a solução O conceito é produto pronto do início ao fim da criação das tabela Front end Backend e testes finais da solução O time de desenvolvimento é responsável ainda pela definição das tarefas necessárias para que um item do Backlog do produto seja considerado pronto no exemplo acima as tarefas poderão ser separadas entre design da tela construção da camada de negócio preparação das tabelas do banco de dados testes unitários testes funcionais testes de regressão e por ai vai É o time de desenvolvimento quem define essas atividades e o tempo estimado para conclusão de cada uma delas Para que isso funcione as pessoas deste time precisam ser autodisciplinadas elas não precisam ter um chefe dizendo o que elas precisam fazer pois elas sabem o que deve ser feito e se autoorganizam Em resumo um time de desenvolvimento precisa ter pessoas com habilidades específicas e generalistas ao mesmo tempo Um time de 3 pessoas em que apenas um faz a análise apenas um programa e apenas Gestão de Times Métodos Ágeis 25 um testa não irá funcionar no Scrum Esse time precisa ter um analista que pode ajudar no desenvolvimento e testar um programador que pode auxiliar nas definições de análise e testar e um testador que também faça a análise e monte manual do usuário O time precisa ser multidisciplinar O tamanho do Time de Desenvolvimento segundo o framework Scrum precisa ser grande o suficiente para conseguir entregar incrementos de software por completo e pronto para uso e pequeno o suficiente para não ser ágil Recomendase que o time seja de 6 3 ou seja de 3 a 9 integrantes sem contar o Scrum Master e o Product Owner Os mesmos só poderão ser considerados se eles também fizerem entregas do Backlog da Sprint ou seja se eles também desenvolverem seja analise programação testes etc Ter um time menor do que 3 integrantes pode ser que não seja possível entregar softwares por completo e também reduz demais as relações interpessoais Ter mais do que 9 pessoas o time poderá se tornar lento e difícil de coordenar então tente montar times de 3 a 9 integrantes Então surge a pergunta mas e se eu tiver 20 pessoas na empresa Simples monte pelo menos 3 times de desenvolvimento que poderão trabalhar ou em produtos diferentes com Backlogs diferentes ou no mesmo produto compartilhando o mesmo Backlog do produto O Time de Desenvolvimento precisa ter Colaboração trabalho em equipe é essencial Atuação com transparência Buscar o máximo de valor ao negócio Melhoria contínua Apoiar o dono do produto a manter o Backlog do produto Autoorganização Gestão de Times Métodos Ágeis 26 Comprometimento Trabalho com qualidade Sem dúvida a essência do Time de Desenvolvimento no Scrum é o comprometimento total ao projeto autoorganização e trabalho em equipe sem isso o processo não irá funcionar Se na sua empresa você não tem alguma dessas 3 qualidades no seu time melhor trabalhar esses pontos que faltam e só depois implantar o Scrum caso contrário você irá se frustrar com os resultados Time que não tiver comprometimento mesmo que seja auto organizado não vai funcionar Um time comprometido mas que não sabe se organizar e trabalhar em equipe também não irá funcionar Times com funções específicas Em muitas empresas você verá a divisão intencional de papéis de trabalho diferentes em equipes especializadas específicas tais como Equipe de Design Equipe de Desenvolvimento Equipe de Testadores Etc E estas equipes entregam o resultado dos seus trabalhos para as demais de forma independente e autônoma cada um com sua responsabilidade A Equipe de Desenvolvimento deve fazer todo o trabalho para produzir uma ou mais funcionalidades do produto em cada Sprint Isto inclui a concepção desenvolvimento integração e testes dessa funcionalidade Desta forma precisamos de uma equipe que seja hábil em todas essas tarefas Gestão de Times Métodos Ágeis 27 Principais responsabilidades Realizar execução sprint Durante a execução Sprint os membros da equipe de desenvol vimento realizam o trabalho de concepção construção integração e testes de itens do Product Backlog Devem se autoorganizar e decidir coletivamente como planejar gerenciar executar e comunicar o trabalho Inspeção e adaptação É esperado que todos os membros da equipe de desenvolvimento participem de cada reunião diária Daily Scrum durante os quais os membros da equipe coletivamente inspecionam o progresso em direção à meta do Sprint e adaptam o plano de trabalho para tal Se algum membro da equipe não participar a equipe pode perder algum detalhes importante do contexto geral e isso pode impactar objetivo do Sprint Grooming do product backlog Uma grande parte desse trabalho se concentra no que chamamos de refinamento do Product Backlog estimativa de tamanho e priorização dos itens A equipe de desenvolvimento deve alocar até 10 do seu tempo em cada Sprint para ajudar o Product Owner com essas atividades Planejar a sprint No início de cada sprint a equipe de desenvolvimento deve participar do planejamento Em colaboração com o Product Owner e com a facilitação do Scrum Master a equipe de desenvolvimento ajuda a estabelecer a meta para o próximo Sprint A equipe então determina quais dos subconjuntos de itens do Product Backlog são importantes construir para alcançar esse objetivo Para um Sprint de 2 semanas pode ser gasto meio dia com o planejamento Um Sprint de 4 semanas gastase em média 1 dia inteiro com o planejamento Ao invés de focar em um plano muito grande Gestão de Times Métodos Ágeis 28 incerto e excessivamente detalhada no início a equipe faz uma série de planos menores mais detalhados logo antes do início de cada Sprint Figura 5 imagem alusiva a planejamento Fonte Flaticon 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 a mudanças durante o processo de desenvolvimento Mas como fazer isso Times de alta performance A performance no contexto de células ou times de desenvolvimento está intimamente relacionada com a maturidade do time como um todo Uma definição de maturidade é estado das pessoas ou das coisas que atingiram completo desenvolvimento Para um time de desenvolvimento maturidade pode ser considerada como o conjunto de características que mostram um alto grau de desenvolvimento técnico e comportamental Entretanto ter um time reconhecido como maduro não garante um início com alta performance A definição de HPT ou High Performance Teams segundo o livro The Wisdom of Teams traduzido para o português Times de Alta Performance é um conceito dentro do desenvolvimento das organizações referente a times organizações ou grupos virtuais que são altamente focados nas suas metas e alcançam resultados de negócios superiores superando todos os outros times similares e também as expectativas dadas a sua composição Gestão de Times Métodos Ágeis 29 Para ser um time de alta performance é necessário superar as expectativas entregar cada vez mais e cada vez melhor sobre uma meta possível evitando situações comuns onde o cliente considera alta performance a entrega de tudo o que gostaria de ter simplesmente guiado pelo desejo e gerando uma avaliação baseada em emoção e não em resultados Custo x adequação Para viabilizar um projeto existem diversas combinações possíveis de montar times de desenvolvimento Fatores como distribuição experiência técnica e maturidade das pessoas devem ser levados em conta antes de garantir que determinado conjunto de pessoas atendam às necessidades do negócio O Scrum prega que quanto mais multidisciplinar for um time melhor será para o projeto Se possível o time todo deve ser capaz de planejar executar e testar histórias assim como executar tarefas de Frontend e Backend com praticamente o mesmo esforço Porém sempre haverá pessoas com mais facilidade para um certo tipo de atividade e menos para outra mas deve haver o incentivo à multidisciplinaridade e o trabalho conjunto sempre que possível o que auxilia ter um time menos sujeito a situações imprevisíveis Figura 6 Custo Fonte pixabay Gestão de Times Métodos Ágeis 30 Qualquer empresa gostaria de ter em seus times somente pessoas com muitos anos de experiência comprovada um time inteiro sênior Na maioria das vezes isso não é possível seja por motivo de falta de colaboradores com esse perfil no mercado seja pelo alto custo O que deve ficar claro é que a não ser que o cenário exija e possibilite um time de sêniores o aconselhável é montar um time balanceado Em que desenvolvedores menos experientes tenham apoio técnico de um desenvolvedor mais experiente assim como um testador júnior possa ser responsável por executar os testes enquanto um testador mais experiente possa ser responsabilizado pela criação dos cenários e validação dos requisitos de modo a focar em planejamento e não na execução de testes Na maioria das vezes o sucesso de um projeto tem uma relação direta entre o equilíbrio de qualidade custo e prazo Pilares escopo x custo x prazo As três primeiras áreas a serem estudadas pelo PMI Project Management Institute Escopo Custo e Prazo ajudaram a formar um diagrama chamado de Trinômio Sagrado do Gerenciamento de Projetos Este diagrama mostra resultados das variações sobre o escopo custo e prazo do projeto e seu impacto na qualidade Para o sucesso de um projeto é necessário equilibrar esses três pilares que são relacionados como vértices de um triângulo Se a opção for um custo menor devese aumentar o prazo ou reduzir o escopo Se a busca for pela entrega em menor prazo provavelmente haverá um custo maior ou será necessária a redução do escopo O pilar qualidade fica entre os três vértices o que impossibilita que seja negociado Qualquer problema com qualidade gera impacto direto em custo prazo eou escopo Não existe motivo para diminuir a qualidade mesmo que a falta de cuidado com a qualidade pareça atraente por diminuir o custo como nos casos que há diminuição no time de testes ou no escopo de testes por exemplo O problema é que se não há garantia de qualidade dificilmente haverá como dizer que entregaremos no prazo ou que respeitaremos o custo Então o ganho aparente será posto em Gestão de Times Métodos Ágeis 31 prova quando defeitos em desenvolvimento homologação ou produção começarem a impactar negativamente no prazo e no custo um risco que não vale a pena correr Diante disso existe um cuidado com times de desenvolvimento que não deve ser negligenciado o de produzir com qualidade acima de velocidade ou previsibilidade Desenvolvimento contínuo Para atingir as metas de velocidade sem perder qualidade o ideal seria iniciar o projeto com um time de técnicos especialistas nas tecnologias do projeto com profundo conhecimento no negócio no cliente e comprometido com a entrega do produto Esta realidade é possível para equipes que desenvolvem produtos diretamente para a empresa em que atuam trabalhando em conjunto com a área de negócio e com conhecimento prévio do sistema que será criado ou evoluído Esta não é a realidade das consultorias e fábricas de softwares pelo fato de que tanto na contratação dos profissionais quanto na formação da equipe não existe garantia de que os colaboradores tenham conhecimento técnico necessário Dificilmente os colaboradores conhecerão o negócio do cliente antes de iniciar o projeto e muito menos haverá garantia de que todos estejam comprometidos com a entrega Por este motivo é importante entender que times diferentes compostos por pessoas com nível técnico e de maturidade diversificados terão início de projeto com resultados diferentes Por isso quando não existe garantia de iniciar um projeto com alto rendimento os colaboradores devem ser conduzidos pelo processo de melhoria contínua de forma a serem capazes de alcançar o desenvolvimento técnico e pessoal necessário para atender às necessidades identificadas O Scrum é um framework iterativo baseado em ciclos de PDCA sigla em inglês que significa Planejar Executar Validar e Atuar Plan Do Check Act Deste modo as fases que compõem uma iteração ou ciclo devem ser analisadas para dar aos times insumos para o desenvolvimento aumentando a percepção do próprio time sobre seus pontos fortes e de melhoria Gestão de Times Métodos Ágeis 32 Com o foco na melhoria contínua e considerando o aproveitamento máximo e feedback das iterações alguns pontos de atenção devem ser levados em consideração os quais serão analisados na sequência Figura 7 Equipe de desenvolvimento Fonte Próprio Gestão de Times Métodos Ágeis 33 Scrum master O Scrum Master é um dos três papéis que compõem uma equipe Scrum junto com o Product Owner e o Time de Desenvolvimento Enquanto o Product Owner está focado em construir o produto correto e a equipe de desenvolvimento está focada em produzir corretamente o produto e o Scrum Master é o cara que ajuda todos a compreender os valores princípios e práticas do Scrum Principais responsabilidades Coach O Scrum Master deve agir como um coach algo como um mentor um treinador tanto para a equipe de desenvolvimento Scrum quanto ao Product Owner Quando surge qualquer problema que a equipe pode e deve ser capaz de resolver a atitude do Scrum Master como o de qualquer bom treinador é Eu não estou aqui para resolver seus problemas por você em vez disso eu estou aqui para ajudálo a resolver seus próprios problemas Agora se o problema é um impedimento que a equipe não pode resolver sozinha o Scrum Master deve tomar para si a responsabilidade de resolver O Scrum Master também faz o papel de coach para novos Product Owners ajudandoos a entender e cumprir as suas responsabilidades como Product Owner Exemplo Fazendo uma a analogia com equipes esportivas é como se o Scrum Master fosse o treinador do time e o Product Owner o dono da equipe Logo o Scrum Master é responsável por maximizar os resultados do time através do Scrum Líder servidor O Scrum Master é também um líder servidor e um líder servidor nunca perguntaria a um membro da equipe Então o que você vai fazer por mim hoje Em vez disso um líder servidor deve perguntar Então o que posso fazer hoje para te ajudar e sermos mais eficazes Gestão de Times Métodos Ágeis 34 Autoridade no processo O Scrum Master é autoridade do processo e deve dominar o processo do Scrum como ninguém Autoridade neste contexto não é o mesma que um gerente funcional ou gerente de projeto teria O Scrum Master não contrata e nem demite ninguém e também não é ele quem dita para a equipe quais as tarefas que deve fazer ou como fazêlas Em vez disso o Scrum Master ajuda a equipe a definir e aderir ao seu próprio processo para ter certeza que o trabalho seja feito da melhor forma possível O Scrum Master tem o dever de garantir que todos da equipe Scrum conheçam os valores princípios e práticas juntamente com as abordagens específicas da equipe Scrum O Scrum Master continuamente ajuda a equipe Scrum melhorar o processo para maximizar o valor do negócio entregue Escudo contra interferências O Scrum Master protege a equipe de desenvolvimento de interferências externas para que ela possa manter o foco na entrega de valor a cada Sprint A interferência pode vir de inúmeras de fontes desde gestores que querem mudar os membros da equipe no meio de um Sprint até de problemas provenientes de outras equipes Não importa qual a fonte da interferência o Scrum Master atua como um interceptor para que a equipe possa se concentrar na entrega de valor Removedor de impedimentos O Scrum Master também assume a responsabilidade de remover qualquer obstáculo que possa inibir a produtividade da equipe quando os próprios membros da equipe não podem removêlos Gestão de Times Métodos Ágeis 35 Agente de mudança Para muitas empresas o método de trabalho do Scrum é uma mudança muito grande na cultura de trabalho O Scrum Master ajuda então as pessoas a entenderem essas mudanças os impactos da adoção do Scrum e os benefícios que ele pode ajudálas a atingir O Scrum Master também garante que a mudança efetiva está ocorrendo em todos os níveis da organização permitindo não só o sucesso a curto prazo mas os benefícios a longo prazo com o uso do Scrum Perfil scrum master Conhecimento Para ser um bom coach o Scrum Master deve dominar os processos do Scrum Ele não precisa ser um especialista técnico nem dominar as linguagens de programação que o time de desenvolvimento vai usar mas um mínimo de conhecimento é muito importante para ajudar o time a resolver impedimentos O Scrum Master também não precisa ser um especialista no domínio do negócio o Product Owner é quem deve ser mas novamente o conhecimento do negócio também pode ser muito útil Questionador Scrum Masters tem que saber fazer as perguntas certas Aquele tipo de pergunta que faz as pessoas pararem para pensar Eu nunca tinha pensado desta forma Agora que você me fez essa pergunta me fez pensar que pode haver outra forma de resolver Grandes Scrum Masters quase nunca responderam diretamente às perguntas em vez disso ajudam as pessoas a perceberem que eles têm o conhecimento necessário para encontrar suas próprias respostas Paciente Como Scrum Masters preferem não dar respostas eles precisam ter muita paciência até que a própria equipe consiga chegar na resposta Gestão de Times Métodos Ágeis 36 Isso ajuda no aprendizado da equipe em relação ao projeto e além disso ajuda a amadurecer o processo e elevar o nível de maturidade da equipe Colaborativo O Scrum Master deve ter excelentes habilidades de colaboração para trabalhar com o Product Owner a equipe de desenvolvimento e todos os outros envolvidos Além disso como o coach do processo o Scrum Master está sempre procurando oportunidades para ajudar os membros da equipe à alcançar um nível maior de colaboração A colaboração é fundamental para o sucesso do projeto Scrum Protetor O Scrum Master deve proteger a equipe Ele age como um cão pastor guardando o rebanho dos lobos que podem tentar atacar neste caso lobos são quaisquer impedimentos organizacionais que possam aparecer O Scrum Master também protege o processo Sempre que as coisas se tornam difíceis é comum algum membro da equipe se desviar do processo ágil e cair na tentação fazer as coisas do jeito que acha mais familiar da forma tradicional Transparente Finalmente o Scrum Master é transparente em todas as formas de comunicação Ele é transparente em todas as suas ações não esconde nada de ninguém não deve existir agendas ou informações ocultas dos demais As pessoas não esperam nada além disso de um líder servidor O dia a dia do scrum master No início e no final do Sprint a maior carga é com as atividade do Scrum planejamento execução e retrospectivas de Sprint e reuniões diárias Gestão de Times Métodos Ágeis 37 Durante o desenvolvimento do Sprints surgirão muitos impedimentos e a remoção de impedimentos acaba se tornando a atividade de maior carga no dia a dia do Scrum Master Figura 8 Fonte O Autor Scrum master x product owner Scrum master fraco x product owner fraco fracasso lento É a famosa conversa de louco Muita conversa muita elucubração prazos intermináveis e projeto e valor entregues que é bom nada Scrum master bom x product owner fraco fracasso rápido Neste caso o Product Onwer foca no que não agrega valor ao produto e o objetivo real do projeto fica em segundo plano Tanto o Scrum Master quanto o Time de Desenvolvimento vão sinalizar para o Product Owner que o caminho seguido não é o ideal Se mesmo assim o Product Owner insistir que o Time deve prosseguir no foco errado na entrega da Sprint e na demonstração do produto para os demais stakeholders ficará evidente que a energia do Time não foi gasta para entregar o valor esperado Gestão de Times Métodos Ágeis 38 Scrum master ruim x product owner bom ganhos rápidos mas insustentáveis É o famoso relógio de camelô funciona quando você compra e para de funcionar assim que você dobra a esquina É o chamado débito técnico pois o produto entregue possui defeitos ou capacidade limitada de execução Dependendo da qualidade da entrega abre se um novo projeto só para corrigir as falhas do projeto original O infame termo fase 2 utilizado pelos especialistas em fazejamento Scrum master bom x product owner bom sucesso permanente Neste ponto encontramos um time Scrum maduro seguindo de forma adequada seu planejamento e as regras do framework e o principal de tudo todos focados na entrega de valor É muito difícil chegar neste estágio tropeços serão inevitáveis até lá mas o importante é que a cada Sprint o time entenda em que parte errou e como pode melhorar O que não pode é o time ficar estagnado nas situações 1 2 e 3 Se isso acontece com você repense seriamente se as pessoas certas estão assumindo os papéis certos Quatro situações que podem ocorrer Figura 9 Fonte O Autor Gestão de Times Métodos Ágeis 39 BIBLIOGRAFIA FIGUETREDO AM Gerenciamento de Projetos Ágeis Golden Cross 2007 KERZNER H Project Management A system approach to planning scheduling and controlling John Wiley Sons 2002 LESSA L O Papel do PMO nas Estruturas Organizacionais Belo Horizonte PMI Chapter MG 2006 Disponível em httpwwwpmimgorg brGeralvisualizador Conteudoaspxcodareaconteudo423 Acesso em 14 fev 2015 PERBIRA P et al Entendendo Scrum para Gerenciar Projetos de Forma Ágil Curitiba Revista Mundo PM 2007 Luiz Gustavo Rezende Motta Gestão de Times Métodos Ágeis