APLICAÇÃO DA METODOLOGIA ÁGIL NA GESTÃO DE UM PROJETO DE RESERVATÓRIO DA METALÚRGICA CARBOQUÍMICA DA AMAZÔNIA LTDA Lucienne Keily da Silva Rodrigues (IDAAM) lucienne_keily@hotmail.com Marcio de Menezes Rodrigues (IDAAM) marciodemenezes@yahoo.com.br Jose Carlos Reston Filho (IDAAM) jcreston@gmail.com Este trabalho discute a aplicação de um método de gestão ágil em um projeto de reservatório de uma empresa metalúrgica do polo industrial de Manaus utilizando as práticas do Scrum. Além disso, pretende-se analisar a implantação do método ágil Scrum nos projetos de novos produtos da empresa. Os resultados alcançados e apresentados no gráfico de Burndown foram satisfatórios e mostraram que o método melhorou a comunicação e a motivação dos membros do time, e, a diminuição do tempo, custo e risco do projeto. Palavras-chave: Scrum, Metodologia ágil de produtos, Gestão de projetos.
1. Introdução A metodologia de gerenciamento ágil vem se destacando principalmente pelo enfoque no escopo do projeto: o produto. Descrever um produto de forma concisa é uma das tarefas que podemos encontrar em vários métodos e aplicações. Conforme Lei et al (2015), o movimento ágil foi introduzido em resposta aos problemas da metodologia de software waterfall, onde explana um método linear e sequencial. Os métodos ágeis surgiram em meados dos anos 90, com técnicas para desenvolvimento de software, para evitar os riscos que chegam a afetar o desenvolvimento do produto (Serrador & Pinto, 2015). Criado por Jeff Sutherland e Ken Schwaber em 1993, o Scrum tem a finalidade de ser um método mais rápido, eficaz e confiável de se desenvolver softwares para o ramo tecnológico. Dentre os métodos ágeis, o Scrum se sobressai pelo fato de dar maior destaque na gestão de projetos que agrega atividades de monitoramento e acompanhamentos diários. No Amazonas, as indústrias metalúrgicas acabam tendo desperdícios em sua produção pela falta de um gerenciamento que facilite o acompanhamento diário de fabricação do produto. O trabalho atual propõe-se uma metodologia para gerenciamento da fabricação de um reservatório, produzido pela Industria Metalúrgica Carboquímica da Amazônia Ltda. Pretende-se com essa metodologia ágil utilizando as práticas do Scrum, realizar o acompanhamento da fabricação do produto durante o período de 30 dias. Com esse objetivo serão obtidos resultados diários do processo com reuniões com o time para assegurar a efetividade do Scrum. Os resultados serão apresentados no gráfico de Burndown como descreveremos adiante. A metodologia aqui apresentada, com algumas adaptações no escopo, poderá ser aplicada para outros produtos da empresa onde foi realizada a pesquisa. 2. Revisão da Literatura 2.1 A metodologia ágil de gestão de projetos Os métodos ágeis foram fortemente influenciados pela filosofia japonesa. Segundo Dingsoyr et al (2012), as práticas relacionadas a planejamento, controle e agilização do fluxo são ações fortemente relacionadas com técnicas e princípios da produção Lean. Segundo Campanelli & Parreiras (2014), os principais métodos ágeis são: Programação Extrema (XP), Scrum, Kanban, Lean, Desenvolvimento dirigido por funções (FDD), Método 2
de desenvolvimento de sistemas dinâmicos (DSDM), Desenvolvimento adaptativo de software (ASD), Crystal e Processo unificado da rational (RUP). Dentre estes, destaca-se o Scrum como um dos métodos mais utilizados. Serrador & Pinto (2015) afirmam que, os métodos ágeis foram elaborados para que se utilizassem o mínimo de documentações, ajudando na flexibilidade e capacidade de respostas às mudanças, ou seja, nesta metodologia a flexibilidade e capacidade de adaptação é muito mais importante que o planejamento, ao contrário da metodologia tradicional. Tais métodos ágeis surgiram na década de 90, mas foi a partir do manifesto ágil em 2001, que eles foram apresentados como um conjunto de princípios para a evolução da gestão de projetos. 2.2 Scrum O Scrum foi criado por Jeff Sutherland juntamente com Ken Schwaber em 1993, a partir do trabalho de Nonaka e Takeuchi no início de 1990, para ser um meio mais rápido, eficaz e confiável de se desenvolver softwares para o ramo tecnológico. Segundo Sutherland (2014), até 2005 a maior parte de desenvolvimento de software era feito através do método tradicional chamado de Cascata. Tal método tratava-se de um processo vagaroso que demoravam meses e até mesmo anos de atrasos, e que por muitas vezes resultavam num produto não almejado pelo cliente. O Scrum se sobressai diante dos demais métodos ágeis pelo fato de dar maior destaque na gestão de projetos, agregando atividades de monitoramento, feedback s através de reuniões rápidas e diárias com toda a equipe, objetivando a identificação e correção de quaisquer falhas ou impedimentos, que possam surgir durante o processo de desenvolvimento. 2.3 Papéis do Scrum A equipe Scrum é composta por três papéis fundamentais: Product Owner, Scrum Master e os membros do time. Todas as responsabilidades de gerenciamento em um projeto são divididas entre eles. Cada um desses papéis possui objetivos específicos que são essenciais para o sucesso do Scrum. O Product Owner, caracterizado como o dono do produto, é o responsável pela gestão dos requisitos do projeto definidos no Product Backlog, assim como a configuração da equipe. Dentro das diversas atividades desempenhadas, a principal que se destaca é a de garantir que 3
os itens do Backlog do produto sejam visíveis e transparentes para todos os membros da equipe. O Scrum Master é responsável pelo funcionamento do Scrum, sua implementação e maximização dos benefícios. Responsável por treinar a metodologia ao time, uma de suas principais atividades é a remoção de impedimentos ou obstáculos apontados na reunião diária, que possam comprometer o trabalho da equipe ao longo do projeto. De acordo com Klemme (2016), o Scrum Master é responsável pela aceleração da taxa de inovação de um projeto, seguindo quatro objetivos: Mantendo os ciclos de atividades de inovação ou sprints curtos, sendo o mais comum de duas semanas, criando entregas aceleradas evitando problemas em projetos; Focando na criação de valor e na interação frequente do cliente no processo de desenvolvimento; Eliminando os obstáculos durante o desenvolvimento do projeto; Protegendo os desenvolvedores de procedimentos de gerentes externos. Segundo Lei et al (2015), os membros do time é uma equipe multifuncional e autoorganizada, ou seja, eles têm o controle do projeto e sabem realizar as tarefas sem depender de interferências externas. São os grandes responsáveis por realizar a implementação do produto. O tamanho desta equipe pode ser de até 7 membros, com uma variação de mais ou menos 2, afirma Sutherland (2014). 2.4 Cerimónias do Scrum 2.4.1 Planeamento da sprint Todo o trabalho no Scrum é executado através de ciclos denominados Sprints. Lei et al (2015), afirmam que o Sprint é o coração do processo Scrum. Os Sprints são iterações definidas para ter certa duração. Esta duração é estabelecida pela equipe, podendo ser adotado entre 2 a 4 semanas. A figura 1 mostra a dinâmica do funcionamento do fluxo do Scrum. 4
Figura 1 - Fluxo Scrum Fonte: Adaptado de https://slidemodel.com/templates/software-diagrams-powerpoint/ De acordo com Cervone (2010), o Planejamento do Sprint consiste em duas partes: Na primeira parte o Product Owner define o Backlog do produto, que é uma lista dos requisitos do produto. Na segunda parte, o foco da reunião está em criar o sprint backlog, ou seja, as tarefas priorizadas elegidas a partir do Product Backlog, e que a equipe se compromete em desenvolver em um sprint. Para este mesmo autor, definido o planejamento do sprint, as atividades poderão ser iniciadas e, durante a realização deste, nenhuma ação externa deve intervir com a equipe Scrum, uma vez que os requisitos de um projeto não podem ser alterados no decorrer de um sprint. 2.4.2 Daily Scrum São reuniões diárias de curtíssima duração também chamadas de Daily meeting ou Stand up. De acordo com a visão de Sutherland (2014), essas reuniões têm duração máxima de 15 minutos. Nesta são admitidos todos os membros e interessados, para tal, seguem as regras: A reunião deve ser diária; Duração máxima de 15 minutos; Mesmo local e horário; Scrum Master, Equipe e Product Owner participam; Interessados (participarão apenas como ouvintes). Nesta reunião três perguntas são realizadas: O que foi feito no projeto desde a última reunião?; O que será feito até a próxima reunião?; Existe algum impedimento?. 5
Como mediador da reunião o Scrum Master é o responsável em declarar o término, deixando a equipe livre para discutir problemas ou assuntos técnicos que possam surgir durante a reunião e pudessem prolongar o tempo, para um outro momento. 2.4.3 Sprint review Esta reunião é realizada no último dia da sprint. Aberta a todos os membros, objetiva expor o trabalho concluído durante o sprint. O Product Owner, a partir do feedback do cliente, faz a reorganização do Product Backlog para o próximo Sprint, adicionando novos itens ou priorizando outros. 2.4.4 Sprint retrospective A retrospectiva de sprint consiste numa reunião realizada entre o Scrum Master e os membros do time, com objeto de discutir o que deu certo ou errado durante a realização da Sprint do ponto de vista dos membros do time. Esta reunião possibilita a interação e o surgimento de ideias que possam vir ajudar os demais membros em relação ao projeto, tornando-os cada vez mais uma equipe auto-organizavél. 2.5 Artefatos do Scrum 2.5.1 Product Backlog É uma lista de todas as funcionalidades desejadas num produto, definida pelo cliente e priorizadas pelo Product Owner. Não é possível descrever todos os requisitos quando iniciado o projeto. Normalmente, escrevem-se primeiro os mais importantes, que são suficientes para compor o primeiro sprint. O Product Backlog é mutável, podendo ser alterado na medida em que vai se conhecendo mais sobre o produto, negócio e o cliente. Os requisitos de maior prioridade são os mais detalhados, e mantido de forma visível para os demais membros da equipe scrum. De forma geral, qualquer pessoa pode contribuir para a construção do Product Backlog, no entanto, sua priorização sempre será realizada pelo Product Owner. 2.5.2 Flipboard Conhecido como quadro Kanban, permite a visualização do fluxo do trabalho através de utilização de cartões em um quadro onde contém colunas representando os estágios de um 6
fluxo, as funcionalidades ou estórias. Através desta gestão visual, é possível identificarmos o responsável por cada estória, as prioridades e os impedimentos, ou seja, todo o desenvolvimento do trabalho será explicito neste quadro, como mostra a figura 2. Figura 2 - Flipboard ou Quadro Kanban Fonte: Adaptado de https://slidemodel.com/templates/3d-agile-scrum-powerpoint-diagram/ 2.5.3 Burndown Chart É um gráfico que monitora o progresso e velocidade do projeto, também é uma outra forma de tornar o trabalho visível. Este gráfico é estruturado por um eixo com o número de pontos definidos pela equipe para o sprint, e outro eixo com o número de dias. Para montar o Burndown Chart é utilizado o Planning Poker. De acordo com a afirmação de Sutherland (2014), é um método de estimativa incrivelmente simples, com cartas baseadas na sequência de Fibonacci 1, 3, 5, e assim por diante, como mostra a figura 3. A escolha da carta pelos membros da equipe está diretamente ligada ao grau de complexidade de cada tarefa do Sprint Backlog. Figura 3 - Cartas Planning Poker Após a reunião diária, o Scrum Master soma o número de pontos concluídos e atualiza o gráfico. Para efeito positivo, é ideal que este gráfico apresente uma linha descendo 7
constantemente, como observado na figura 4, até que se chegue no último dia do sprint, concluindo o objetivo deste. Figura 4 - Burndown Chart 3. Metodologia A metodologia Scrum foi aplicada de acordo com o apresentado nas próximas seções. 3.1 Planejamento do projeto 3.1.1 Escolha dos papéis e responsabilidades A equipe Scrum é dividida em três papeis: Product Owner, Scrum Master e membros do time. O Product Owner, está representado pelo Diretor Executivo da empresa, que é o responsável pelo contato direto com o cliente, na negociação e fechamento de contrato. O Scrum Master, responsável em coordenar o time, como facilitador garantirá que a metodologia seja aplicada de forma correta, removendo os impedimentos e participando de todas as reuniões afim de assegurar a eficácia do Scrum, está representado pela pesquisadora deste estudo. Já os membros do time, como limitado pelo Scrum, é composto por 6 pessoas, dentre elas temos comprador, engenheiro de projetos, engenheiro de produção e líderes dos processos de corte, montagem/ soldagem e jateamento/pintura/expedição. Todos responsáveis pelo cumprimento das atividades definidas em cada sprint. Através da figura 5 podemos observar o fluxograma da equipe Scrum. 8
Figura 5 - Equipe Scrum Para melhor entendimento das práticas da Metodologia Scrum, toda a equipe supracitada, participou de um treinamento realizado pelo Scrum Master, onde este teve duração de uma hora e trinta minutos. 3.1.2 Elaboração da lista dos requisitos Product Backlog Após a escolha dos papéis, foram definidos a lista de tarefas do produto, conhecido por Product Backlog, para desenvolvimento do sprint. Para este levantamento foi realizada uma reunião com duração de uma hora, onde foi decidido pelo Product Owner, a sequência dos itens para fabricação de um reservatório como apresenta a tabela 1, com as seguintes dimensões: Capacidade: 164m³; Diâmetro: 3,0m; Altura do fundo falso: 15,71m e Altura total: 27,30m. Tabela 1 Product Backlog - Reservatório SEQUÊNCIA ITENS 1 PROJETOS 2 COMPRAS 3 CORTE 4 JATEAMENTO 5 CALANDRAGEM 9
6 MONTAGEM 7 SOLDAGEM 8 PINTURA 9 EXPEDIÇÃO 3.1.3 Planejamento do sprint Definido a lista de atividades, foi realizado a primeira reunião da equipe Scrum, para planejamento do sprint. Para o produto Reservatório, foi estimado um Sprint de 30 dias e, detalhadas a partir do Product Backlog, as tarefas a serem executadas durante a iteração. Este planejamento foi realizado dentro de um tempo de aproximadamente duas horas. Decidido o Sprint Backlog, a equipe estimou através do método Planning Poker baseado na sequência de Fibonacci, o número de pontos para cada item considerando-os de acordo com a complexidade de cada tarefa. Essa pontuação foi utilizada para que fosse visualizado a velocidade em que a equipe realizaria cada tarefa. A tabela 2 mostra o processo detalhado da fabricação do Product Backlog. Tabela 2 - Sprint Backlog - Reservatório PROJETOS COMPRAS CORTE PLASMA CORTE GUILHOTINA ITENS PONTOS Projeto do Gabarito 21 Projeto do Reservatório 8 Projeto das Escadas e Plataformas 13 Projeto dos Bocais 144 Chapas 55 Cantoneiras 34 Conexões 34 Barras 21 Tinta 55 Corte do Gabarito 13 Corte do Costado 13 Corte do Teto 13 Corte do Fundo e Plataforma 13 Corte da Bocas de Visitas 13 Chumbadores 8 Guarda-Corpo das Escadas e Teto 8 Escadas Interna e Externa 8 10
3.1.4 O quadro Scrum Jateamento das Chapas do Costado 8 Jateamento das Chapas do Fundo 3 JATEAMENTO Jateamento das Bocas de Visita 3 Jateamento das Escadas 1 1 Jateamento dos Guarda-corpos e Plataforma 3 CALANDRAGEM Calandragem das Chapas do Costado 55 Montagem do Gabarito 8 Montagem do Costado 144 Montagem do teto 21 Montagem do fundo 34 Montagem dos Guarda-Corpos 2 MONTAGEM Montagem das Bocas de Visita 13 Montagem das Escadas e Plataforma 8 Locação dos Bocais 5 Locação das Bocas de Visita 13 Locação das Escadas e Plataforma 8 Locação do Guarda-Corpo do teto 5 Soldagem do Gabarito 1 Soldagem do Costado 144 Soldagem do Teto 3 SOLDAGEM Soldagem do Fundo 21 Soldagem dos Guarda-Corpos 8 Soldagem das Bocas de Visita 13 Soldagem das Escadas 8 Pintura do Reservatório (Interno/ Externo) 89 PINTURA Pintura das Escadas 3 Pintura dos Guarda-Corpos 3 EXPEDIÇÃO Expedição do Gabarito 1 Expedição do Reservatório 1 Total de Pontos 1.104 O quadro Scrum foi criado para tornar visível o progresso da equipe. Composto de quatro colunas: A Fazer, Em Progresso, Concluído e Pendências conforme a ilustração na figura 6. As atividades foram representadas através dos post-its, que eram movidos um a um de acordo com sua evolução. 11
Figura 6 - Quadro Kanban 3.1.5 Gráfico de Burndown O Burndown foi uma outra forma de visualizarmos o progresso da equipe. Representado pelo gráfico onde o eixo X referia-se ao número de dias do sprint, enquanto o eixo Y referia-se a soma da pontuação de cada atividade definida pela equipe no Planejamento, como mostrado na figura 7. Diariamente, o Scrum Master atualizava o gráfico, demostrando o número de pontos concluídos entre um stand up e outro. Figura 7 - Gráfico de Burndown 12
3.2 Execução do projeto 3.2.1 Daily Scrum As reuniões com todos os membros aconteciam todos os dias, no mesmo local e horário, nunca ultrapassando o tempo de 15 minutos. Mediada pelo Scrum Master, estas reuniões promoviam o relato dos integrantes sobre o progresso das atividades em direção a meta do sprint, através de três questões: O que você fez ontem para ajudar a equipe a concluir o sprint?; O que você vai fazer hoje para ajudar a equipe a concluir o sprint?; Existe algum obstáculo impedindo você ou a equipe de alcançar o objetivo do sprint?. 3.2.2 Revisão do sprint A Sprint Review trata-se da reunião onde foi mostrado ao Product Owner e interessados, o que foi concluído durante o sprint, ou seja, os post-its movidos para a coluna concluído. Sua duração foi de 1 hora, monitorada pelo Scrum Master. 3.2.3 Retrospectiva do sprint Na Sprint Retrospective, a equipe motivada pelo Scrum Master relatou os pontos de melhoria dentro das práticas do Scrum, objetivando tornar o processo mais eficaz para o próximo produto, uma vez que para este reservatório foi planejado com apenas um sprint. 4. Resultados Para a utilização da metodologia, a escolha de um reservatório como piloto se deu para que houvesse um melhor entendimento e aplicação das práticas. Para tal produto, foi realizado um planejamento de um sprint de 30 dias. A partir deste, foram criados o quadro Kanban e Gráfico de Burndonw. A figura 8 Quadro Kanban, expõe todas as estórias e as atividades que as compunham, para acompanhamento do fluxo do processo. Na figura 9 Gráfico de Burndonw, é representado pelos números de pontos estimados na reunião de planejamento no eixo X, enquanto o eixo Y representa o número de dias levantado para sprint (4 semanas). 13
Figura 8 - Quadro Kanban em estagio inicial de processo Figura 9 - Gráfico de Burndonw em estagio inicial de processo No vigésimo terceiro dia do mês de março de 2017, foi startado o projeto e as reuniões Daily Scrum, a partir desta data passaram a ocorrer diariamente, no mesmo local e horário. Durante este evento, cada membro do time atualizava o quadro com as atividades que entrariam em processo ou que estavam concluídas, além de relatar os osbstáculos que os impediam de concluir certa tarefa. A figura 10 representa a evolução das atividades na semana 1. Das 47 atividades da coluna A fazer, 34 entraram em processo resultando em 17 atividades concluídas. Através da figura 11, podemos acompanhar essa mesma evolução graficamente. 14
Partindo da pontuação total 1.104 pontos, ao final da semana 1 foram concluídos 376 pontos. Figura 10 - Quadro Kanban - Semana 1 Figura 11 - Gráfico de Burndonw - Semana 1 Para verificação do resultado final, foi avaliado o progresso das atividades semanalmente. A figura 12 mostra os resultados obtidos. Na semana 1, as atividades concluídas superaram as pontuações diárias estimadas, tendo uma quebra no final de semana devido não ter expediente na empresa nestes dias. Na semana 2, em decorrência de alguns impedimentos como falta de energia, remanejamento de colaboradores para finalização de outro produto, problema em programa da rede, fizeram com que poucas atividades tivessem resultados positivos, obtendo 169 pontos concluídos, 55% a menos da semana anterior. Na semana 3, iniciamos ainda com 15
alguns dos impedimentos da semana 2, como pode ser visto no Gráfico de Burndonw Resultado final, no entanto, ao concluirmos duas atividades de pontuações elevadas, este volta a se comportar de forma eficiente, finalizando a semana com mais 433 pontos. Na semana 4, caracterizada como a última, alguns impedimentos como priorização de outro cliente, falta de energia, feriado, atraso do retorno do cliente para localização dos bocais, impossibilitam o adiantamento da conclusão da Sprint, ocorrido somente em sua data limite, zerando a pontuação. Figura 12 - Gráfico de Burndonw - Resultado Final 5. Conclusão A partir dos resultados mostrados na Gráfico Burndonw Resultado final (figura 12), observa-se que os melhores desfechos ocorreram na semana 1, onde muitas atividades foram concluídas e na semana 3, quando duas atividades de maiores pontuações baseadas em seu grau de complexidade foram finalizadas. No entanto, o prazo estimado para o sprint foi concluído conforme planejado. Os membros do time da pesquisa observaram alguns benefícios com a aplicação do Scrum, tais como: melhoria na comunicação com maior interação entre os envolvidos, motivação da equipe de desenvolvimento, entrega do projeto dentro do prazo com a diminuição do tempo, e a diminuição do risco do projeto. A metodologia de gestão ágil de projetos Scrum, foi concordante com a realidade da empresa pesquisada, mostrando um processo focado em resultados e comunicação entre os membros do time. 6. Agradecimentos 16
Os autores gostariam de agradecer o apoio dado para o desenvolvimento da presente pesquisa pela empresa Carboquímica da Amazônia Ltda, onde foi aplicada a metodologia apresentada neste artigo. 7. Referências Campanelli, A. S. & Parreiras, F. S. (2015). Agile Methods Tailoring A systematic Literature Review. The Jounal of Sistems and Software, pp. 85-100. Cervone, H. F. (2011). Understanding Agile Project Management Methods Using Scrum. Systems & Services: International Digital Library Perspectives, pp. 18-22. Dingsoyr, N. B. (2012). A Decade of Agile Methodologies: Towards Explaining Agile Software Development. Jounal of Sistems and Software, pp. 1.213-1.221. Klemme, A. D. (2016). Why a CEO Should Think Like a Scrum. Strategy & Leadership, pp. 36-40. Lei, H., Ganjeizadeh, F., Jayachandran, P. K., & Ozcan, P. (2015). A statistical analysis of the effects of Scrum and Kanban on software development projects. Roboticsand Computer - Integrated Manufacturing, 59-67. Serrador, P. &. Pinto, J. K. (2015). Does Agile work? A Quantitative Analysis of Agile. International Journal of Project Management, pp. 1.040-1.051. Suthertland, J. (2014). A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. São Paulo - SP: Leya. 17