Scrum, uma geração à frente no modo de se fazer a gestão de uma obra.

RESUMO.

Foi no final da década de 1990 que os microcomputadores começaram a se tornar usuais nos canteiros de obra. Para se “tocar uma obra” nessa época, os mais sofisticados equipamentos disponíveis eram, uma calculadora programável, um aparelho de fax quando se conseguia uma linha telefônica, uma lapiseira, papel e uma parede bem grande na sala de projetos onde se colavam um Cronograma PERT/CPM (figura 1), ao lado de um Quadro Kanban (figura 2) que era uma novidade vinda do Japão, desenvolvido nas linhas de produção da Toyota. O Quadro era um painel com diversas colunas, com postites das tarefas em andamento, das tarefas próximas de iniciar, das tarefas concluídas, dos contratos que faltavam ser fechados, das compras e das entregas de materiais, dos projetos pendentes e de tudo o mais que era necessário providenciar para que a obra não perdesse seu prazo, alimentado pela agenda do cronograma. Tudo ficava muito exposto, tudo muito claro e todo mundo que entrava na sala dava uns “pitacos”, cliente, diretoria, projetistas, fornecedores, mas era a melhor forma de fazer a gestão para o bom andamento e cumprimento dos prazos

Figura 1Figura 2

Nos tempos atuais, a agilidade se impôs como um quesito indispensável na gestão de uma obra e este trabalho tem a intenção de repetir exatamente o conceito acima, com a utilização de ferramentas atuais. A gestão é feita no conceito Scrum, o cronograma é um MS Project adaptado para rodar neste conceito, que monta a agenda das tarefas e das decisões que devem ser tomadas e que vão para o Quadro Kanban, que não fica mais na parede, mas sim no aplicativo Trello, na nuvem, onde através de notebooks e smartfones, clientes, diretores, projetistas e para quem mais se liberar o acesso, conseguem dar os seus “pitacos” sem sair de casa ou do escritório, ajudar a obra a cumprir seu cronograma, com muito mais clareza, velocidade e precisão, do que com os métodos de planejamento tradicionais.

PALAVRAS-CHAVE: Métodos ágeis, Planejamento de obras, Scrum.

I – INTRODUÇÃO:

A Metodologia Scrum

Criado na década de 90 para desenvolvimento de softwares, por Jeff Sutherland, um veterano da guerra do Vietnã e de acordo com ele e sua experiência enquanto piloto, o grande desafio de pousar um avião consiste no fato de não haver fórmula fixa para se fazer isto, então a todo segundo o piloto precisa fazer ajustes para adequar sua aeronave à rota de pouso.

Isso também vale para os grandes projetos da construção civil, onde cada um é único e envolve a gestão de uma enorme complexidade de atividades, máquinas, equipamentos e pessoas, sendo que não existe produtividade precisa para as tarefas, então é necessário, a todo momento a conferência de suas performances, para ajustes na agenda dos serviços.

II – PAPÉIS CENTRAIS DO SCRUM

Os papéis centrais de uma equipe Scrum da construção civil (figura 3), tem a seguinte estrutura:

Scrum Owner: É quem representa o cliente dentro do contrato. Não é necessariamente um líder técnico, mas é o líder máximo de todo o empreendimento.

Scrum Master: É um líder técnico, possui alto conhecimento de todos os serviços a serem executados, métodos, sequência executivas, produtividades e logística a serem empregadas. É o responsável pelo funcionamento do Sistema Scrum.

Time de Desenvolvimento: São as pessoas ligadas à produção; engenheiros de produção, mestres de obra, encarregados e oficiais.

Figura 3

III – AS CERIMÔNIAS QUE COMPÕE O CICLO SCRUM 

A Metodologia Scrum, possui cerimônias, que são procedimentos de rotina que necessitam ser realizados para efetivação do método.

Reunião de planejamento: é uma reunião preparatória para a execução do cronograma, com todos os envolvidos no projeto, onde no Scrum Board, inserem-se postites com as tarefas que devem se dar mais atenção, quem e quando precisa ser contratado, o que precisa ser comprado com prazo de entrega demorado, pendências de projetos, pendências legais e tudo o mais que possa ser um impedimento para o desenvolvimento do empreendimento como um todo. 

Sprint: é a duração de uma tarefa, é o coração do Scrum. Deve ter duração entre 1 e 30 dias no máximo, pois durações longas significam que não se entendeu bem a tarefa a ser executada. 

Dailly Scrum Meeting: são reuniões diárias que se fazem em pé, no local dos serviços em andamento, de no máximo 15 minutos, pelo Time de Desenvolvimento, para verificar o que foi feito no dia anterior, determinar o que será feito no presente dia, verificar se a data de término da tarefa será cumprida ou se há algum impedimento para que isso ocorra.

Sprint Review Meeting: são reuniões semanais, feita pelo Scrum Master e pelo Time de Desenvolvimento, quando é feito uma Data de Corte no cronograma. Avaliam-se as realizações da semana, ajustam-se se necessário datas de início e término das tarefas, analisam-se metas e ações para manter o cronograma em dia. Não há medição de quantidade de serviços em nenhum momento do processo, só aferição de datas de início e término das tarefas. 

Reunião de Retrospectiva do Projeto: é uma reunião de Lições Aprendidas, que não necessariamente precisa ser feita ao final da obra, onde se avalia o que deu certo e o que não deu na execução dos serviços e quais soluções para se obter uma melhoria contínua dos processos.

IV – MONTANDO UM CRONOGRAMA SCRUM

Figura 4

Após a reunião de planejamento dá-se início ao Cronograma Scrum que tem o esquema da ilustração acima (figura 4). Precisam já estarem definidas as sequências executivas das tarefas, suas durações (Sprints) e as quantidades de homens-hora necessárias para completar cada tarefa (figura 5).

Para dar início ao acompanhamento da obra, não é necessário ter o cronograma todo completo, pois no Scrum não se trabalha com pesos de tarefas que se alterariam à medida que se acrescentasse mais tarefas. O trabalho agregado em homens-hora nas tarefas é importante para montarmos um histograma (Gráfico de Burndown) e analisarmos se estamos executando mais ou menos obra do que o previsto, mostrar se o grau de dificuldade irá aumentar ou diminuir em função do que estamos realizando, se teremos um pico de obra maior ou menor do que o previsto.

Figura 5

O grande desafio de montar um cronograma numa obra onde as tarefas de uma sequência de executiva se repetem em vários andares, é determinar as durações e latências (prazo para início) entre tarefas similares, de modo que não haja descontinuidade entre os trabalhos, ocasionando tempos de parada e espera e com a melhor distribuição de homens-hora possível.

Exemplificando, na sequência executiva Alvenaria / Reboco, de um prédio de 21 andares, onde a Alvenaria tem uma Sprint de 10 dias e o Reboco de 5 dias, quanto tempo eu devo esperar para iniciar o Reboco no 1º andar, que tem velocidade maior do que a da Alvenaria, para que este não pare por falta de frente de serviço e tenha o seu início no 21º andar, imediatamente após a conclusão da Alvenaria deste mesmo andar?

E na sequência Reboco / Azulejo, onde Reboco tem uma Sprint de 5 dias e Azulejo de 10 dias (mais lento), em que data e em qual andar eu tenho que iniciar uma segunda frente de serviço Azulejo, para que as duas frentes iniciem e terminem juntas em seus últimos andares, sem haver descontinuidade de trabalho? 

O Project Scrum faz esse equilíbrio em toda a rede de tarefas com suas Sprints conforme ilustração da figura 6, usando o conceito do Método do Caminho Crítico e Fluxo Ininterrupto de Produção, controlado pelas colunas Margens entre tarefas. Mas para isso é necessário que todas as ligações do cronograma sejam do tipo Término-Início (TI), que é quando a tarefa predecessora manda no início da sua tarefa sucessora ou do tipo Início Término (IT) que é quando a tarefa sucessora manda no início da sua predecessora. Só esses dois tipos de ligações produzem uma rede fechada que habilitam os cálculos das colunas Margem de Atraso Total e Margem de Atraso Permitida, possibilitando trabalhar com as folgas existentes, fazer cálculos e recálculos para manter a rede de serviços sempre equilibrada, quando uma Sprint de uma tarefa não consegue manter a sua duração de projeto e começa a empurrar sua sequência executiva e a data final da obra.

Figura 6

Observação: Ligação Início-Início não produz interdependência entre tarefas. Nestas, quando se atualiza o Project, a duração da predecessora pode aumentar infinitamente que a sucessora não tem a sua data de início alterada. E ligação Término / Término faz com que uma tarefa adiantada se atrase para acompanhar o atraso da outra, uma coisa completamente sem sentido numa obra. 

O conceito PERT, usa como prazo das tarefas a média ponderada de três tempos possíveis, otimista, provável e pessimista, ou seja, é um prazo probabilístico, o conceito CPM usa um prazo fixo, ou seja, é determinístico e o Scrum usa Sprints, prazos que aprendem e se ajustam com o que está ocorrendo, ou seja, é realístico. 

Não confundir o conceito Equilíbrio de Sprints feito no Project com de Linhas de Balanço feitas em Excel. Linhas de Balanço são linhas de um gráfico e não há interdependência entre elas, um atraso em uma linha não causa atraso automático em outra linha. Equilíbrio de Sprint trabalha com uma rede tipo PERT/CPM fechada em um Project, onde o atraso de uma tarefa empurra a sua seguinte, causando uma variação de término em toda uma sequência produtiva, podendo ou não deslocar a data de término da obra, dependendo de folgas existente pelo caminho. 

V – FAZENDO A GESTÃO NO PROJECT SCRUM 

Os Projects Scrum que ilustram as descrições deste trabalho, referem-se ao exemplo abaixo, exceto, o da figura 8.

Cronograma físico – Agenda da obra.

Fazer um cronograma para uma obra, significa gerar uma agenda com todas as datas de início e término de tudo o que precisa ser feito e providenciado e quem monta e gerencia esta agenda é o Project Scrum (figura 7). Como já foi dito as datas de início e término das tarefas podem sofrer variações durante o decorrer da obra, conforme as variações das Sprints, mas a data final não poderá ser alterada. E como não existe cronograma perfeito, a cada alteração de término de tarefa, durações e interpendências deverão ser revistas pela equipe de planejamento para que a agenda de tarefas sofra o mínimo de alteração e a data final não seja modificada.Figura 7

Data de Corte – Atualização do cronograma.

Data de Corte é a data em que se faz a Sprint Review Meeting, avaliação semanal de tudo o que está sendo executado em uma Data de Status; o andamento das tarefas, o dia em que estas começaram e a previsão para terminarem. Faz-se uma Atualização Automática no Project e este coloca à esquerda da Data de Status, tudo o que já foi executado e à direita todo o restante a ser executado, com suas datas de início e término reajustadas aos deslocamentos ocorridos. Estes deslocamentos é que mostram se a obra está atrasada ou adiantada (figura 8).

Figura 8.

Sinalizadores

O Project Scrum tem um sinalizador em sua primeira coluna à esquerda, um Farol em emoji que altera as suas “carinhas” conforme a variação de término das tarefas (figura 8). No início da obra, todos os emojis estão amarelos, a obra está totalmente em dia. As carinhas dos emojis mudam quando a data de término de uma tarefa se desloca de cima de sua Linha de Base, para verde quando a Data de Término adianta e para vermelho quando a Data de Término atrasa. 

Seguir as carinhas vermelhas no Project, nos permite descobrir qual sequência executiva está levando a obra a atrasar e estudar quais tarefas desta sequência, que ainda nem começaram, podem ter suas durações encurtadas ou seus inícios antecipados, modificando a estrutura da rede de produção.

Trabalho em homens-hora.

Todas as quantidades de trabalho das tarefas, metro quadrado, metro cúbico, etc, são transformados em homens-hora e essa é a unidade que se mede o quanto se tem feito de obra. Um comparativo trabalho previsto versus trabalho concluído, indica o quanto deveria estar pronto e quanto realmente está, para uma Data de Corte. O Project (figura 9) faz o 

cálculo com base nas porcentagens concluídas das durações das tarefas e os homens-hora agregados a elas e com estes dados gera um gráfico, Gráfico de Burndown, um histograma com o número de homens hora previsto e o número de homens-hora restante em função das tarefas ainda não concluídas. Analisar esse gráfico possibilita saber se o grau de dificuldade para concluir a obra está ficando maior ou menor com base na curva da Linha de Base, se teremos um pico de mão de obra maior ou menor do que o estudado inicialmente, se o número de pessoas é compatível com o canteiro existente.Figura 9

Como já foi explicado anteriormente trabalho previsto versus trabalho realizado, não indica se a obra está adiantada ou atrasada. Poderemos ter uma situação em que realizamos mais homem-hora do que o previsto, porém uma tarefa, com pouco ou nenhum homem-hora, uma Data Marco por exemplo, quando não concluída é deslocada para a frente, empurrando uma sequência de tarefas para fora de sua linha de base (figura 8).

VI – QUADRO KANBAN (SCRUM BOARD) – ONDE AS INFORMAÇÕES SÃO FIXADAS

Quadro Kanban ou Scrum Board (figura 10) como na nomenclatura do Scrum, é um quadro com colunas, que mostram as situações em que as tarefas se encontram, evoluindo da 

Como já foi explicado anteriormente trabalho previsto versus trabalho realizado, não indica se a obra está adiantada ou atrasada. Poderemos ter uma situação em que realizamos mais homem-hora do que o previsto, porém uma tarefa, com pouco ou nenhum homem-hora, uma Data Marco por exemplo, quando não concluída é deslocada para a frente, empurrando uma sequência de tarefas para fora de sua linha de base (figura 8).

VI – QUADRO KANBAN (SCRUM

BOARD) – ONDE AS INFORMAÇÕES SÃO FIXADAS

Quadro Kanban ou Scrum Board (figura 10) como na nomenclatura do Scrum, é um quadro com colunas, que mostram as situações em que as tarefas se encontram

Paulo Eduardo Ramalho Jr.

• Engenheiro civil formado pela Faculdade de Engenharia de São José dos Campos – SP em 1977.
• Certificado Scrum Master Professional pela CertiProf Professional Knowledge (2019) e pela International Scrum Master Fundation, associada à Agile Alliance – USA (2019).
• Scrum Fundamentals Certified pela Scrum Study – USA (2019).
• Autor de um capítulo no livro “Métodos Ágeis – Sprints de Experiências Práticas” sobre obras em contrato “Fast Track” – Editora Saramago (2021).
• Pós-graduação e especialização em diversos cursos na área de planejamento e controle de obras pela Escola Politécnica da Universidade de São Paulo.
• Formado há 44 anos trabalhou sempre em empresas de médio e grande porte como gerente de planejamento e de produção.

www.lindedin.com.br/in/paulo-eduardo-ramalho-jr-45460456

peramalhojr@gmail.com