Uma visão do SCRUM

Um ponto de vista sobre o SCRUM aplicado no gerenciamento de projetos.

A verdade máxima do gerenciamento de projetos é que não há uma forma única de gerenciar projetos que funcione para todos os tipos de projeto. Um dos mais interessantes trabalhos do Escritório de Projetos, inclusive, é o de descobrir os fluxos de gerenciamento de projetos mais adequados para cada tipo de projeto realizado pela instituição.

Uma das premissas que o SCRUM possui, e que vende otimismo para muitas organizações e profissionais, é de que não devemos documentar todo o projeto no seu início. Isso permite, segundo seus entusiastas, uma maior flexibilidade na mudança de prioridades do projeto durante seu ciclo de vida e menos tempo de planejamento no início do projeto. Assim, funcionalidades que agregam valor ao negócio possuem prioridade, serão entregues primeiro e a primeira entrega será em até 1 mês de trabalho, já que o SCRUM prega entregas parciais priorizadas por valor de negócio.

A ideia é boa, mas será que serve para todos os tipos de projeto?

Vou citar como objeto um projeto de médio porte com escopo fechado. Se utilizarmos o SCRUM sem customizações, o projeto possuirá um planejamento fraco, com documentação que registra apenas uma visão macro do negócio e detalhes e atividades apenas da primeira parte do produto que será entregue. Se não temos o escopo claramente definido, como vamos planejar o tempo de trabalho com menor chance de erro?

Alguns entusiastas do SCRUM garantem que as estimativas baseadas no conhecimento da produtividade do time de trabalho apresentam resultados satisfatórios. Mas se não temos como enxergar todo o escopo do projeto, a nível de atividades, como prever o prazo sabendo que nenhum projeto é igual a outro? E se estamos implantando o SCRUM hoje na empresa, como saber a velocidade do time de trabalho?

Com essas características, o SCRUM se apresenta eficaz para projetos com escopo aberto, onde o mesmo será construído ao longo do projeto com o prazo negociável. Área em que metodologias mais tradicionais iriam despender esforços que aqui seriam desnecessários.

Outra característica que apresenta alguns efeitos negativos neste objeto, está na falta de definição de papéis no projeto. Os papéis são apenas 4: Product Owner (tradicional Patrocinador ou Cliente), Scrum Master (Gerente do Projeto) e Team (Equipe – sem definição de papéis, todos fazem de tudo). Essa definição de time propõe uma maior flexibilidade na distribuição de tarefas. Na realidade das organizações maiores, é preciso restringir algumas distribuições à papéis que devem ser exclusivos à um grupo de profissionais (como os testes, por exemplo).

Com essa característica vemos que o SCRUM é ideal para gerenciar times de desenvolvimento, mas não todos os envolvidos em um projeto de uma organização de porte maior.

As limitações do SCRUM não o tornam uma ferramenta descartável para projetos de escopo fechado. Ao contrário, suas limitações são um convite para combinarmos o SCRUM com as boas práticas de gerenciamento de projetos de metodologias mais tradicionais, como o PMBOK, por exemplo.

Uma organização, de médio a grande porte, precisa ter maior controle de seu portfólio e uma maior flexibilidade na gestão de escopo de seus projetos para responder, com mais agilidade, às mudanças dos ambientes de negócio. O PMBOK, por exemplo, por não ser uma framework como o SCRUM e sim um guia de boas práticas, deve ser customizado para a realidade da organização, logo pode ser combinada com outras ferramentas para potencializar os seus resultados.

É Importante lembrar que a partir do momento em que customizamos o SCRUM, este perde as características da framework original, logo já não podemos chamar o resultado da customização de SCRUM. Uma framework não pode ser customizada e manter seu nome de origem – o nome “SCRUM Modificado” pode ser uma sugestão de nome a ser usado.

0 comentários

Envie seu comentário