Ser líder de uma equipe e ter comprometimento no gerenciamento de projetos é uma tarefa que exige muito esforço para enfrentar os constantes desafios. Otávio Ottoni tem várias certificações no ramo de gerenciamento de projetos e já trabalhou como analista em quatro empresas diferentes. Atualmente Otávio trabalho no Banco Central do Brasil, utilizando metodologias ágeis para manter o Sistema de Câmbio Interbancário. Em resposta ao contato, Otávio explicou um pouco do funcionamento do Scrum e as restrições que surgiram durante a adaptação.
Aqui no Banco Central do Brasil, nós utilizamos o Scrum aplicado ao ambiente de tecnologia e de desenvolvimento que vivemos. Scrum é um framework Ágil de gestão de projetos usado para entregar aos clientes, de forma iterativa, incrementos de produto de alto valor. Scrum depende de equipes hábeis e auto-organizadas para entregar os incrementos do produto. Também depende de um cliente, ou Dono do Produto, que indique uma equipe com uma lista de funcionalidades desejadas, e que use o valor de negocio como mecanismo de priorização.
Scrum é ideal para projetos cujos requisitos mudam rapidamente ou são altamente emergentes. O trabalho a ser feito em um projeto Scrum é registrado nas Pendências do Produto (Product Backlog), que é uma lista de todos os desejos de mudança no produto. No inicio de cada incremento é feita uma Reunião de Planejamento de Incremento (Sprint Planning Meeting) na qual o Dono do Produto (Product Owner) prioriza as Pendências do Produto (Product Backlog), e a Equipe Scrum (Scrum Team) seleciona as tarefas que ela pode completar durante o próximo Incremento. Essas tarefas são então movidas das Pendências do Produto para as Pendências do Incremento.
Durante um incremento, são conduzidas curtas reuniões diárias chamadas de Scrum Diário (Daily Scrum), que ajudam a equipe a manter-se no rumo. Ao final de cada incremento a equipe demonstra a funcionalidade concluída, na Reunião de Revisão do Incremento (Sprint Review Meeting).
Sobre as vantagens em relação ao RUP e o Desenvolvimento em Cascata vou descrever algo mais prático em que vivi.
Sou terceirizado pela empresa Cast e no contrato antigo ficávamos misturados aos servidores em diversas equipes. O desempenho da equipe trabalhando em pares e principalmente a qualidade do processo e do código fonte, artefatos resultantes eram impressionante. Entretanto, o TCU forçou a mudança de pagamento de serviço terceirizado, de homem/hora para ordens de serviço contadas em pontos de função. Em uma equipe de 10 pessoas, eu e mais uma pessoa éramos da Cast e fomos para um ambiente separado da equipe. Nós continuamos com a mentalidade ágil e posso afirmar que no início foi difícil, muito por causa da distância e pelas coisas não parecerem mais tão ágeis como eram. Isso foi devido a uma documentação pesada e um processo amarrado (abertura de OS, contagem de pontos de função da cast, contagem do banco, aprovação de ambas as partes, abertura de uma nova OS para desenvolvimento, entre outras) que tínhamos que nos enquadrar. Muitas vezes uma “história” era transformada em Ordem de serviço.
Ágil possui inúmeras vantagens. Se hoje fosse iniciar uma equipe e escolher o processo, esse processo seria ágil, porém posso falar que as demandas decorrentes de um processo ágil são extremamente difíceis de mensurar, porque a contagem de pontos de função é limitada em muitos aspectos. Em todas as tarefas são realizados testes automatizados unitários e de aceitação. O sistema fica robusto e seguro, porém, consome um bom tempo para realizá-los (cerca de 65% do esforço é para fazer teste), e o ponto de função não conta esse esforço. Teste não é contado como funcionalidade, e é ignorado.
Aqui no Banco Central nós usamos Desenvolvimento Ágil há cinco anos, e o processo está em um nível de maturidade exemplar, onde muitos sistemas de uma complexidade absurda são sucessos de qualidade e desempenho.
Otávio Ottoni
Gerente de Projetos – Banco Central do Brasil