Estruturando um Projeto SCRUM: Gestão de Times e Métodos Ágeis

Estruturando um Projeto SCRUM Gestão de Times Métodos Ágeis Diretor Executivo DAVID LIRA STEPHEN BARROS Gerente Editorial ALESSANDRA VANESSA FERREIRA DOS SANTOS Projeto Gráfico TIAGO DA ROCHA Autoria LUIZ GUSTAVO REZENDE MOTTA AUTORIA Luiz Gustavo Rezende Motta Olá Sou graduado em Ciência da Computação e tenho experiência técnicoprofissional de mais de 10 anos na área de Gestão de Projetos Passei por empresas como Unimed Benner e Postal Saúde Sou apaixonado pelo que faço e adoro transmitir minha experiência de vida àqueles que estão iniciando em suas profissões por isso fui convidado pela Editora Telesapiens a integrar seu elenco de autores independentes Estou muito feliz em poder ajudar você nesta fase de muito estudo e trabalho Conte comigo ICONOGRÁFICOS Olá Esses ícones irão aparecer em sua trilha de aprendizagem toda vez que OBJETIVO para o início do desenvolvimento de uma nova competência DEFINIÇÃO houver necessidade de apresentar um novo conceito NOTA quando necessárias observações ou complementações para o seu conhecimento IMPORTANTE as observações escritas tiveram que ser priorizadas para você EXPLICANDO MELHOR algo precisa ser melhor explicado ou detalhado VOCÊ SABIA curiosidades e indagações lúdicas sobre o tema em estudo se forem necessárias SAIBA MAIS textos referências bibliográficas e links para aprofundamento do seu conhecimento REFLITA se houver a necessidade de chamar a atenção sobre algo a ser refletido ou discutido ACESSE se for preciso acessar um ou mais sites para fazer download assistir vídeos ler textos ouvir podcast RESUMINDO quando for preciso fazer um resumo acumulativo das últimas abordagens ATIVIDADES quando alguma atividade de autoaprendizagem for aplicada TESTANDO quando uma competência for concluída e questões forem explicadas SUMÁRIO Time SCRUM 12 Características Essenciais de um Time SCRUM 14 AutoOrganização 14 Fortalecimento 15 Colaboração 15 Objetivo Comum 16 Tamanho perfeito 16 Múltiplas Habilidades 18 Cultura 18 Product Owner 20 Principais Responsabilidades 20 Participação no Planejamento 20 Grooming do Product Blacklog 21 Definição dos Critérios de Aceitação e Verificação de sua Aprovação 21 Colaboração com a Equipe de Desenvolvimento 22 Colaboração com o Restante da Empresa 23 Características e Habilidades 23 Dia a dia do Product Owner 24 Time de Desenvolvimento 27 Times com Funções Específicas29 Principais Responsabilidades 30 Execução da Sprint 30 Inspeção e Adaptação 30 Grooming do Product Blacklog 30 Planejamento da Sprint 31 Times de Alta Performance 32 Custo x Adequação 32 Pilares Escopo x Custo x Prazo 33 Desenvolvimento Contínuo 34 SCRUM Master 37 Principais Responsabilidades 37 Coach 37 Líder Servidor 38 Autoridade no Processo 38 Escudo Contra Interferências 38 Removedor de Impedimentos 38 Agente de Mudança 39 Perfil do SCRUM Master 39 Conhecimento 39 Questionamento 39 Paciência 40 Colaboração 40 Proteção 40 Transparência 40 O Dia a Dia do SCRUM Master 41 SCRUM Master X Product Owner 41 SCRUM Master fraco Product Owner fraco fracasso lento 41 SCRUM Master bom Product Owner fraco fracasso rápido 41 SCRUM Master fraco Product Owner bom ganhos rápidos mas insustentáveis 41 SCRUM Master bom Product Owner bom sucesso permanente 42 9 UNIDADE 02 Gestão de Times Métodos Ágeis 10 INTRODUÇÃO 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 ele 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 pois 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 que tenham interesses sejam 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 Ao longo desta unidade letiva vamos esclarecer estes conceitos Gestão de Times Métodos Ágeis 11 OBJETIVOS Olá Seja muito bemvindo à Unidade 2 Estruturando um projeto SCRUM Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos 1 Discernir sobre o perfil típico dos membros de um time de projetos de software aplicáveis ao método SCRUM 2 Identificar quem é e qual o papel do Product Owner 3 Organizar membros de um time de desenvolvimento administrar conflitos e controlar os principais indicadores do projeto relacionados aos recursos humanos 4 Praticar o papel do facilitador e líder de um projeto SCRUM Master Gestão de Times Métodos Ágeis 12 Time SCRUM OBJETIVO Ao término deste capítulo você será capaz de conhecer o perfil típico dos membros de um time de projetos de software aplicáveis ao método SCRUM O time SCRUM tem papel fundamental no desenvolvimento do projeto afinal é o time que transforma requisitos em funcionalidades É o time que entrega e desenvolve todo o produto Figura 1 Time SCRUM Fonte Freepik O SCRUM team é multifuncional tem três a nove membros sem contar o SCRUM Master e o Product Owner seleciona o objetivo da sprint sprint goal especifica os produtos de trabalho necessários tem a liberdade de fazer qualquer coisa dentro das diretrizes do projeto para alcançar o objetivo da sprint é autoorganizável planeja suas atividades e apresenta os produtos de trabalho ao Product Owner Gestão de Times Métodos Ágeis 13 Membros do SCRUM team não assumem 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 coletivamente se comprometeram a realizar durante uma sprint SCRUM teams desenvolvem um profundo espírito de coletividade Um SCRUM team típico possui de 5 a 9 pessoas mas é possível escalar utilizando um SCRUM de SCRUMS Antes de estudarmos de forma detalhada as características é necessário considerar esses pontos principais Planejar é útil Seguir cegamente os planos é burrice É simplesmente tentador demais ficar desenhando diagramas sem fim Todo o trabalho que precisa ser feito em um projeto de grande porte deve ser definido para todos verem mas quando os planos detalhados se deparam com a realidade eles viram ruínas Inclua no seu método de trabalho a possibilidade de mudança descoberta e inovação Inspeção e Adaptação De tempos em tempos pare de fazer o que está fazendo revise o que já fez e verifique se isso ainda é o que você deveria estar fazendo e se existe uma maneira de fazer melhor Mudar ou morrer Ficar preso ao modo antigo de fazer as coisas de mandar ou controlar e manter uma previsibilidade rígida resultará apenas no fracasso Nesse meio tempo a concorrência que estiver disposta a mudar deixará você comendo poeira Fracasse rápido para que possa corrigir o problema o quanto antes A cultura corporativa costuma dar mais valor a formulários procedimentos e reuniões do que à criação de valor palpável que pode ser verificado a curtos possibilita de tempo pelos usuários O trabalho que não resulta em valor real é loucura Trabalhar em um produto em ciclos curtos possibilita um feedback inicial do usuário permitindo que você possa eliminar imediatamente tudo aquilo que obviamente constitui um desperdício de esforço SUTHERLAND 2014 p 43 Mas 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 disso a partir de agora Gestão de Times Métodos Ágeis 14 Características Essenciais de um Time SCRUM O time SCRUM garante que o desenvolvimento aconteça 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 os membros da equipe são responsáveis pela entrega do produto ou serviço desejado e não o SCRUM em si São pessoas acima de processos e ferramentas Por isso devemos ter cuidado na formação das equipes SCRUM pois elas serão responsáveis pelo sucesso do projeto e garantirão que aquilo que precisa acontecer realmente acontecerá 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 pode ser chamado de equipe de desenvolvimento uma vez que é responsável pelo desenvolvimento do produto serviço ou outros resultados É constituído por um grupo de indivíduos que utilizam as histórias de usuário na sprint backlog para criar as entregas para o projeto SCRUMSTUDY 2013 AutoOrganização Figura 2 Organização Fonte Pixabay Gestão de Times Métodos Ágeis 15 Os membros da equipe SCRUM são indivíduos motivados que não esperam seus superiores para entender quais tarefas precisam fazer Assumem a responsabilidade compartilham o risco tomam as decisões e trabalham em conjunto para um objetivo comum IMPORTANTE A sinergia resultante dessa autoorganização faz com que haja um melhoramento da eficiência do time de forma geral Assim ninguém nem mesmo o líder diz ao time como ou quando deve haver uma transformação em incrementos de funcionalidades entregáveis Cada uma das pessoas que forma esse time aplica sua especialidade a todos os problemas Fortalecimento A equipe SCRUM ou 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 sem mudar as pessoas A equipe interage mas 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 Gestão de Times Métodos Ágeis 16 Figura 3 Colaboração Fonte Freepik Sabemos que é por meio da colaboração que o processo se encaminha de forma mais rápida e sistêmica Deste modo 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 Como já sabemos quando falamos em time SCRUM estamos nos referindo a uma unidade com objetivos em comum Assim dentro da equipe os indivíduos devem trabalhar em conjunto O objetivo da equipe deve se sobrepor aos objetivos individuais 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 reunir as habilidades necessárias para desenvolver o produto ou serviço Em contrapartida Gestão de Times Métodos Ágeis 17 uma equipe grande pode comprometer a caraterística de dinamismo e colaboração contínuos dentro da equipe Figura 4 Tamanho perfeito da equipe SCRUM Fonte Freepik Conforme definido no SBOK o tamanho ideal da equipe SCRUM deve ser de seis a dez pessoas garantindo que seja grande o suficiente para ter todas as habilidades necessárias para o projeto e ao mesmo tempo pequena o suficiente para colaborar mutuamente durante o projeto Quando um time SCRUM é formado por menos de seis pessoas há uma menor interação resultando em um menor ganho de produtividade Mais do que uma perda na produtividade com menos pessoas o time poderá encontrar limitações de conhecimento durante partes da sprint e devido a isso não ser capaz de entregar uma parte do produto pronta E quando o time é muito grande o que pode acontecer Se a equipe for grande haverá a necessidade de muita coordenação porque os times maiores ocasionam uma maior complexidade para que um processo possa ser gerenciado Gestão de Times Métodos Ágeis 18 Múltiplas Habilidades Durante a formação da equipe SCRUM os membros devem ser selecionados tendo em mente as habilidades necessárias para gerar valor nas entregas esperadas do projeto Figura 5 Múltiplas habilidades Fonte Freepik Assim quando falamos em múltiplas habilidades não focamos em profissionais que saibam desempenhar múltiplas funções mas sim em uma equipe com profissionais que desempenham funções diferentes e desse modo um possa completar o outro visando a maximização dos resultados do time Cultura Aconselhase formar uma equipe SCRUM com os membros instalados presencialmente na organização Isso garante colaboração e coordenação entre os membros e alinhamento com os preceitos do framework SCRUM Nas abordagens tradicionais de desenvolvimento de software é comum encontrarmos maior segregação de funções por exemplo arquiteto programador testador administrador de banco de dados prototipador etc O SCRUM define o papel da equipe de desenvolvimento Gestão de Times Métodos Ágeis 19 que é uma coleção dessas pessoas Os membros da equipe de desenvolvimento em conjunto devem ter as habilidades necessárias para entregar o que foi solicitado pelo Product Owner O time SCRUM é comumente chamado de equipe de desenvolvimento Figura 6 Time SCRUM Fonte Elaborada pelo autor 2021 RESUMINDO E então Gostou do que lhe mostramos Aprendeu mesmo tudinho Agora só para termos certeza de que você realmente entendeu o tema de estudo deste capítulo vamos resumir tudo o que vimos Você deve ter aprendido que o SCRUM team é multifuncional com três a nove membros sem contar o SCRUM Master e o Product Owner seleciona o objetivo da 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 da sprint é autoorganizável e planeja as atividades e apresenta os produtos de trabalho ao Product Owner Você também entendeu que o time SCRUM garante que o desenvolvimento aconteça da forma que o framework prevê Por fim você compreendeu que o SCRUM define o papel da equipe de desenvolvimento que é uma coleção dessas pessoas Os membros da equipe de desenvolvimento em conjunto devem ter as habilidades necessárias para entregar o que foi solicitado pelo Product Owner Gestão de Times Métodos Ágeis 20 Product Owner OBJETIVO Ao término deste capítulo você saberá identificar quem é o Product Owner e qual o papel dele O Product Owner é o ponto central do projeto ágil e exerce liderança sobre o produto que está sendo desenvolvido Ele diz o que precisa e o que não precisa ser feito em relação ao produto que está sendo desenvolvido e constitui um dos três papéischave que constituem uma equipe SCRUM clássica os outros são o SCRUM Master e a equipe de desenvolvimento O Product Owner é responsável por fazer a ponte entre a área de negócios e a equipe SCRUM ACESSE Para saber mais sobre o assunto acesse o artigo Desmistificando o Product Owner clicando aqui Principais Responsabilidades Este é claramente um papel para uma pessoa em tempo integral com responsabilidades significativas e de fato veremos que o grau de responsabilidade do Product Owner parecerá excessivo para uma pessoa só Na maioria das vezes é uma única pessoa mas em algumas circunstâncias pode ser demandado um time de Product Owners Participação no Planejamento O Product Owner é um participantechave nas atividades de planejamento de produto releases e sprints Durante o planejamento do produto trabalha com todas as partes interessadas da empresa diretoria demais departamentos etc para conseguir visualizar o produto ideal Gestão de Times Métodos Ágeis 21 Durante o planejamento de release trabalha com as partes interessadas e a equipe SCRUM para definir o conteúdo do próximo lançamento Durante o planejamento da sprint trabalha com a equipe de desenvolvimento para definir o seu objetivo Grooming do Product Blacklog O Product Owner supervisiona toda a preparação e refinamento também chamado grooming do product backlog que inclui as responsabilidades de criar atualizar estimar e priorizar os itens IMPORTANTE O Product Owner não é o único responsável pelo trabalho de grooming tampouco estima os itens responsabilidade da equipe de desenvolvimento Contudo o Product Owner deve estar disponível para perguntas e esclarecimentos durante tal 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 Definição dos Critérios de Aceitação e Verificação de sua Aprovação O Product Owner é responsável por definir os critérios de aceitação para cada item do product backlog com o auxílio do SCRUM Master IMPORTANTE O Product Owner deve assegurar que os critérios de aceitação e testes de aceitação com frequência específica foram criados antes que o item seja considerado na reunião de planejamento de sprint Sem tais critérios a equipe teria uma compreensão incompleta do item e não estaria pronta para incluílo em uma sprint O Product Owner é responsável por confirmar se os critérios foram satisfatoriamente atendidos O Product Owner pode optar por executar os testes de aceitação por conta própria ou pode pedir a ajuda de usuários experientes Contudo a decisão sobre o atendimento de todas as expectativas é dele Gestão de Times Métodos Ágeis 22 É importante que o Product Owner verifique os critérios de aceitação durante a execução da sprint ao invés de esperar até a revisão Ao fazer isso o Product Owner pode identificar erros e malentendidos que podem ser corrigidos pela equipe antes da revisão da sprint Colaboração com a Equipe de Desenvolvimento O Product Owner deve colaborar frequentemente com a equipe de desenvolvimento de forma direta e estreita exigindo comprometimento diário Muitas organizações que recémadotam SCRUM falham neste ponto e não promovem 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 no qual o envolvimento do usuário é muito maior no início do projeto concepção levantamento de requisitos cai durante o desenvolvimento 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 Esta é exatamente a desvantagem da abordagem tradicional para projetos como dinamismo maior geralmente o usuário descobre a falta de aderência ou compatibilidade do desenvolvimento em uma etapa tardia em que as mudanças se tornam caras ou até inviáveis Veja um exemplo Cliente se vocês tivessem lido minhas especificações com mais cuidado teriam construído o que eu realmente queria Equipe de desenvolvimento se você tivesse escrito seu documento de forma mais clara teríamos construído algo diferente Construímos o que você pediu Usando o SCRUM construímos uma funcionalidade de cada vez e não uma fase de cada vez Isso significa que realizamos todas as atividades para criar determinada funcionalidade design codificação testes durante uma sprint evitando situações como no exemplo apresentado Nesse sentido destacase também um alto nível de engajamento do Product Owner Gestão de Times Métodos Ágeis 23 Colaboração com o Restante da Empresa O Product Owner é o portavoz de toda a comunidade de partes interessadas da empresa internas e externas 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 para recolher necessidades e sintetizar uma visão coerente para orientar o desenvolvimento do produto Características e Habilidades Existem inúmeras características que podemos destacar em um bom Product Owner as quais podem ser agrupadas em quatro grandes categorias Conhecimento do negócio Habilidade com 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 o intermediário do cliente o que requer um bom relacionamento com ele É normal que as pessoas tenham necessidades conflitantes e portanto o Product Owner deve ser um bom negociador e sempre buscar consenso Ele é o eixo entre a comunidade de interessados no projeto e o resto da equipe SCRUM Essa Gestão de Times Métodos Ágeis 24 posição exige boa comunicação para transmitir as informações da forma mais apropriada Autoridade O Product Owner deve ter autoridade necessária na organização para tomar decisões Este item é crucial para o sucesso do projeto SCRUM e merece destaque especial Um problema frequente em empresas que recémadotam SCRUM envolve justamente a falta de poder do Product Owner indicado para tomar todas as decisões importantes do projeto O Product Owner também deve estar preparado para tomar as decisões mais duras como mudanças de escopo data e orçamento Essas 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 possui sua parcela de responsabilidade o ponto aqui é enfatizar que o Product Owner é responsável pela certificação de que os recursos estão sendo usados da melhor forma para atingir os resultados de negócio esperados O Product Owner é um membro da equipe SCRUM e portanto deve entender que os bons resultados econômicos são inviáveis sem os esforços colaborativos da equipe SCRUM Dessa forma o Product Owner deve trabalhar junto com a equipe de desenvolvimento e com o SCRUM Master para que a parceria traga resultados satisfatórios Dia a dia do Product Owner Durante as duas primeiras semanas o Product Owner se mantém envolvido no planejamento do produto ou no portfólio de produtos Após a conclusão do planejamento do produto ele poderá ser submetido a alguma aprovação interna da empresa para avaliação econômica estratégica etc Gestão de Times Métodos Ágeis 25 Na semana três o Product Owner já pode planejar o início do primeiro release Isso geralmente é feito por meio 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 essa 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 essa reunião é mais focada na priorização e na escolha de quais itens serão entregues no release Para a maioria dos projetos essa 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 a primeira sprint No início da sprint o Product Owner supervisiona a atividade de planejamento de sprint Durante a execução da 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 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 a 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 da sprint o Product Owner participa das duas atividades de inspeção e adaptação a revisão e a retrospectiva da 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 Gestão de Times Métodos Ágeis 26 Figura 7 Planejamento de transição Fonte Elaborada pelo autor 2021 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 maior prioridade de forma que todos saibam em que irão 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á de convencer o Product Owner RESUMINDO E então Gostou do que lhe mostramos Aprendeu mesmo tudinho Agora só para termos certeza de que você realmente entendeu o tema de estudo deste capítulo vamos resumir tudo o que vimos Você deve ter aprendido que o Product Owner é um participantechave nas atividades de planejamento de produto release e sprints Assim ele deve ter conhecimento do negócio habilidade com pessoas autoridade e responsabilidade Você também deve ter compreendido que o Product Owner é responsável por maximizar o valor do trabalho que o time de SCRUM faz sendo a única pessoa responsável pelo gerenciamento do product backlog e por garantir o valor do trabalho realizado pelo time Por fim você deve ter visto que o Product Owner mantém product backlog e garante que ele está visível para todos Gestão de Times Métodos Ágeis 27 Time de Desenvolvimento OBJETIVO Ao término deste capítulo você será capaz de organizar os membros de um time de desenvolvimento administrando conflitos e controlando os principais indicadores do projeto relacionados aos recursos humanos 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 É importante frisar que o time de desenvolvimento não é composto apenas por programadores há a necessidade de compor a equipe com todas as competências necessárias para que o produto seja construído pelo time sem dependência de qualquer outra pessoa externa a ele EXEMPLO Se o produto é um software para web desenvolvido em Java com banco de dados Oracle você precisará compor o time com analistas de sistemas programadores Java Web Designers 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 por exemplo o Web Designer que está em outra equipe fazer o frontend para que o time de desenvolvimento faça o backend e teste a solução O conceito é o produto pronto do início ao fim da criação das tabelas frontend back end 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 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 Gestão de Times Métodos Ágeis 28 e assim por diante É o time de desenvolvimento que define essas atividades e o tempo estimado para concluílas Para que isso funcione os membros do time precisam ser autodisciplinados e autoorganizados Em resumo um time de desenvolvimento precisa ter pessoas com habilidades específicas e generalistas ao mesmo tempo Um time de três pessoas em que apenas uma faz a análise apenas um programa e uma faz o teste não irá performar no SCRUM Dentro do conceito de interdisciplinaridade e perfil multitarefa o time ideal contaria com analistas que podem ajudar no desenvolvimento e testar programadores que podem auxiliar nas definições de análise e testar e testadores que têm as habilidades técnicas para análise e montagem de manuais de usuários 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 ao mesmo tempo pequeno o suficiente para ser ágil Recomendase que o time tenha de 3 a 9 integrantes sem contar o SCRUM Master e o Product Owner nota tratase de uma recomendação ou referência Estes últimos só poderão ser considerados se contribuírem diretamente para as entregas do backlog da sprint desenvolver analisar programar ou testar por exemplo Ter um time menor do que três integrantes pode incorrer em não entregar o trabalho por completo e um time que excede nove pessoas poderá se tornar menos rápido às respostas e difícil de coordenar Levantase então a seguinte pergunta e se tivermos 20 pessoas na empresa Nesse caso podem ser montados pelo menos três times de desenvolvimento que poderão ser alocados em produtos diferentes com backlogs diferentes ou no mesmo produto compartilhando o mesmo backlog O time de desenvolvimento precisa ter Gestão de Times Métodos Ágeis 29 Figura 8 Time de desenvolvimento CONHECIMENTO SOBRE O SCRUM SEUS PAPÉIS ARTEFATOS CERIMÔNIAS REGRAS Fonte Elaborada pelo autor 2021 Colaboração trabalho em equipe é essencial Atuação com transparência Busca do máximo valor ao negócio Melhoria contínua Apoio ao dono do produto em relação ao product backlog Autoorganização Comprometimento Qualidade Times com Funções Específicas Em muitas empresas observamos uma divisão intencional de papéis de trabalho diferentes em equipes especializadas por exemplo equipe de design equipe de desenvolvimento equipe de testadores etc Nessas equipes os trabalhos são entregues de forma independente e autônoma cada um com sua responsabilidade Contudo em uma equipe de desenvolvimento todo esse escopo pode ser realizado para produzir uma ou mais funcionalidades do produto em cada sprint Por exemplo a atuação da equipe de desenvolvimento pode incluir concepção desenvolvimento integração e testes de uma funcionalidade reforçando a necessidade de uma equipe que seja hábil em todas as tarefas Gestão de Times Métodos Ágeis 30 Principais Responsabilidades Execução da Sprint Durante a execução da sprint os membros da equipe de desenvolvimento 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 Esperase que todos os membros da equipe de desenvolvimento participem de cada reunião diária daily SCRUM na qual os membros da equipe inspecionam coletivamente o progresso do trabalho em direção à meta da sprint e adaptam o plano de trabalho para tal Se algum membro da equipe não participar a equipe pode perder detalhes importantes do trabalho como impedimentos ou restrições o que pode impactar o objetivo da sprint Grooming do Product Blacklog 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 Gestão de Times Métodos Ágeis 31 Planejamento da Sprint Figura 9 Planejamento Fonte Flaticon 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 a próxima sprint A equipe então determina quais dos subconjuntos de itens do product backlog devem ser priorizados para alcançar esse objetivo Ao invés de focar em um extenso e excessivamente detalhado plano a equipe realiza uma série de planos menores antes do início de cada sprint Um projeto envolve pessoas e mudanças principalmente quando falamos sobre entregas constantes Dessa forma as metodologias ágeis trabalham com equipes altamente motivadas e com suporte a mudanças durante o processo de desenvolvimento Mas como promover uma equipe motivada e um ambiente apto a mudanças constantes Gestão de Times Métodos Ágeis 32 Times de Alta Performance A performance no contexto de células ou times de desenvolvimento está intimamente relacionada com a maturidade do time Maturidade por sua vez pode ser compreendida como 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 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 High Performance Teams HPT traduzido para o português no livro The Wisdom of Teams como Times de Alta Performance é trabalhada no contexto do desenvolvimento organizacional Trata se do conceito de desenvolvimento de times organizações ou grupos virtuais que são altamente focados em suas metas e que podem alcançar resultados superiores se comparados aos seus pares dentro da mesma organização Por fim vale mencionar que alta performance não significa atendimento ou entrega de tudo o que o cliente demanda guiado por emoções e sem base em resultados Custo x Adequação Figura 10 Custo Fonte Pixabay Gestão de Times Métodos Ágeis 33 Existem diversas combinações possíveis para montagem de times de desenvolvimento Fatores como distribuição experiência técnica e maturidade dos profissionais devem ser levados em conta antes de garantir que um time atenda às necessidades do negócio O SCRUM prega que a multidisciplinariedade de um time poderá ser positiva 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 Em qualquer equipe há profissionais com mais ou menos facilidade para uma atividade mas deve haver incentivo à multidisciplinaridade e ao trabalho conjunto sempre que possível Isso contribuirá para um time menos sujeito às situações imprevisíveis Qualquer empresa gostaria de ter em seus times apenas profissionais com muitos anos de experiência comprovada Nem sempre isso é possível seja por falta de profissionais no mercado seja pelo alto custo Salvo situações em que o cenário exija e possibilite um time somente de profissionais experientes o aconselhável é montar um time balanceado com desenvolvedores menos experientes obtendo o apoio técnico de um desenvolvedor mais experiente assim como um testador júnior que 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 O sucesso de um projeto pode em grande parte das vezes apresentar uma relação direta entre equilíbrio de qualidade custo e prazo Pilares Escopo x Custo x Prazo As três primeiras áreas a serem estudadas pelo Project Management Institute PMI escopo custo e prazo ajudaram a formar um diagrama chamado de Trinômio Sagrado do Gerenciamento de Projetos ou Triângulo de Ferro Este diagrama mostra resultados das variações sobre escopo custo e prazo do projeto e seu impacto na qualidade do produto 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 Gestão de Times Métodos Ágeis 34 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 ser negociado Qualquer problema com qualidade gera impacto direto em custo prazo eou escopo Não existem motivos para diminuir a qualidade mesmo que a falta de cuidado com a qualidade seja atraente para diminuir os custos como nos casos em que há diminuição no time de testes ou no escopo de testes 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 prova quando defeitos em desenvolvimento homologação ou produção começarem a impactar negativamente o prazo eou o custo um risco que não valeria 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 a 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 Tal 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 Essa contudo 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 esse motivo é importante entender que times diferentes compostos de pessoas com níveis técnicos e de maturidade diversificados terão projetos com resultados diferentes Por isso quando não existe garantia Gestão de Times Métodos Ágeis 35 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 Desse modo as fases que compõem uma iteração ou um 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 Com foco na melhoria contínua considerando o aproveitamento máximo e o feedback das iterações alguns pontos de atenção devem ser levados em consideração os quais serão analisados a seguir Figura 11 Equipe de desenvolvimento Fonte Elaborada pelo autor 2021 Gestão de Times Métodos Ágeis 36 RESUMINDO E então Gostou do que lhe mostramos Aprendeu mesmo tudinho Agora só para termos certeza de que você realmente entendeu o tema de estudo deste capítulo vamos resumir tudo o que vimos Você deve ter aprendido que o time de desenvolvimento é responsável pela definição das tarefas necessárias para que um item do backlog do produto seja considerado pronto Você também compreendeu que High Performance Teams HPT é o desenvolvimento de times organizações ou grupos virtuais focados em suas metas e que podem alcançar resultados superiores se comparados aos seus pares dentro da mesma organização Por fim você compreendeu que 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 Gestão de Times Métodos Ágeis 37 SCRUM Master OBJETIVO Ao término deste capítulo você conseguirá exercer o papel do facilitador e líder de um projeto 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 o SCRUM Master é o personagem 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 para o Product Owner Quando surge qualquer problema que a equipe pode e deve ser capaz de resolver a atitude do SCRUM Master como a de qualquer bom treinador é Não estou aqui para resolver seus problemas por você em vez disso estou aqui para ajudálo a resolver seus próprios problemas Porém se o problema é um impedimento que a equipe não pode resolver sozinha o SCRUM Master deve tomar para si a responsabilidade Ele também desempenha o papel de coach para novos Product Owners ajudandoos a entender e cumprir as responsabilidades do papel 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 por meio do SCRUM Gestão de Times Métodos Ágeis 38 Líder Servidor O SCRUM Master é também um líder servidor que nunca perguntaria a um membro da equipe o que você vai fazer por mim hoje Ao invés disso um líder servidor perguntaria o que posso fazer hoje para ajudar você e sermos mais eficazes Autoridade no Processo O SCRUM Master é autoridade no processo e deve dominar o processo do SCRUM como ninguém mas a autoridade neste contexto não é a mesma que um gerente funcional ou gerente de projeto teria O SCRUM Master não contrata nem demite ninguém e também não dita para a equipe quais tarefas devem ser feitas ou como fazêlas O SCRUM Master ajuda a equipe a definir e aderir ao próprio processo para ter certeza de que o trabalho será feito da melhor forma possível O SCRUM Master tem o dever de garantir que todos da equipe SCRUM conheçam os valores os princípios e as práticas juntamente com as abordagens específicas da equipe SCRUM O SCRUM Master continuamente ajuda a equipe SCRUM a melhorar o processo para maximizar o valor do negócio entregue Escudo Contra Interferências O SCRUM Master protege a equipe do 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 uma sprint até de problemas provenientes de outras equipes Não importa 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 39 Agente de Mudança Para muitas empresas adotar o SCRUM representa uma mudança muito grande na cultura de trabalho O SCRUM Master ajuda então as pessoas a entenderem essas mudanças bem como os impactos e benefícios que podem ser obtidos com a adoção do SCRUM 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 também os benefícios a longo prazo Perfil do SCRUM Master Conhecimento Para ser um bom coach o SCRUM Master deve dominar os processos do SCRUM 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 Questionamento O SCRUM Master precisa saber fazer as perguntas certas que façam 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 ajudam as pessoas a perceber que têm o conhecimento necessário para encontrar as próprias respostas não as respondem diretamente Gestão de Times Métodos Ágeis 40 Paciência Como SCRUM Masters preferem não dar respostas precisam ter muita paciência até que a própria equipe consiga chegar à resposta Isso ajuda no aprendizado da equipe com relação ao projeto e além disso ajuda a amadurecer o processo e elevar o nível de maturidade da equipe Colaboração 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 coach do processo o SCRUM Master sempre deve procurar oportunidades para ajudar os membros da equipe a alcançar um nível maior de colaboração o que é fundamental para o sucesso do projeto SCRUM Proteção 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 pois sempre que as coisas se tornam difíceis é comum algum membro da equipe se desviar do processo ágil e cair na tentação de fazer as coisas do jeito que acha mais familiar da forma tradicional Transparência Finalmente o SCRUM Master é transparente em todas as formas de comunicação ele não esconde nada de ninguém não devem existir agendas ou informações ocultas dos demais As pessoas não esperam nada além disso de um líder servidor Gestão de Times Métodos Ágeis 41 O Dia a Dia do SCRUM Master No início e no final da sprint a maior carga é com as atividades do SCRUM planejamento execução e retrospectivas de sprint e reuniões diárias Durante o desenvolvimento das 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 SCRUM Master X Product Owner SCRUM Master fraco Product Owner fraco fracasso lento Nenhum projeto ou valor é entregue SCRUM Master bom 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 SCRUM Master fraco Product Owner bom ganhos rápidos mas insustentáveis O produto entregue tem defeitos ou capacidade limitada de execução Dependendo da qualidade da entrega abrese um novo projeto só para corrigir falhas do projeto original Gestão de Times Métodos Ágeis 42 SCRUM Master bom 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 acontecer é o time ficar estagnado nas situações 1 2 e 3 Quatro situações que podem ocorrer Figura 12 Situações GANHOS RÁPIDOS MAS INSUSTENTÁVEIS SUCESSO PERMANENTE FRACASSO LENTO FRACASSO RÁPIDO COISA ERRADA COISA CERTA MODO ERRADO MODO CERTO RESUMINDO E então Gostou do que lhe mostramos Aprendeu mesmo tudinho Agora só para termos certeza de que você realmente entendeu o tema de estudo deste capítulo vamos resumir tudo o que vimos Você deve ter aprendido que valores envolvem comprometimento foco coragem respeito e abertura e que princípios envolvem transparência inspeção e adaptação para prover a abordagem iterativa e incremental Gestão de Times Métodos Ágeis 43 REFERÊNCIAS FIGUEIREDO A M Gerenciamento de projetos ágeis Porto Alegre Golden Cross 2007 KERZNER H Project management a system approach to planning scheduling and controlling Hoboken John Wiley Sons 2002 LESSA L O papel do PMO nas estruturas organizacionais Belo Horizonte PMI Chapter MG 2006 PERBIRA P et al Entendendo SCRUM para gerenciar projetos de forma ágil Curitiba Revista Mundo PM 2007 SUTHERLAND Jeff A arte de fazer o dobro do trabalho na metade do tempo São Paulo Editores LTDA 2014 Gestão de Times Métodos Ágeis