Scrum x PMI: um choque de culturas

Como é amplamente divulgado, o PMI (Project Management Institute) recomenda planejar e, só então executar o projeto. Executar o projeto, mas, sem deixar de monitorar e controlar cada passo do mesmo. Encerrar o projeto e consolidar as lições aprendidas, para fazer sempre melhor da próxima vez. Essa é a essência da cultura do PMI, retratada no guia de melhores práticas PMBOK guide (http://www.pmisp.org.br/educacao/guia-pmbok). No planejamento deve-se definir muito bem o escopo. Uma vez definido, este deve ser, de certa forma, protegido contra mudanças. Se uma mudança precisa acontecer, por qualquer que seja o motivo, será necessário analisar os impactos gerados por essa mudança do ponto de vista do prazo, dos custos, dos riscos, da qualidade e assim por diante. A mudança precisará ser aprovada primeiro, antes da sua implementação. As mudanças acarretarão, necessariamente, modificações no planejamento original do projeto, devendo este ser revisto e atualizado. Não é por acaso que o PMBOK recomenda estabelecer, desde o início do projeto, um controle integrado de mudanças que, dentre outras atribuições, define que somente mudanças aprovadas serão implementadas. Em outras palavras, a cultura do gerenciamento de projetos do PMI reconhece que mudanças ocorrem num projeto, mas, destaca que tais mudanças devem ser muito bem controladas, pois poderão colocar o projeto em risco, dependendo de sua magnitude. Quanto mais experiência tiver um gerente de projetos e sua equipe em uma determinada área objeto de um projeto, melhor será o planejamento desse projeto e, consequentemente, o número de mudanças deverá ser menor, principalmente mudanças capazes de colocar em risco o sucesso do projeto. Mas o que exatamente a cultura do Scrum difere do PMI? O Scrum (http://www.scrumalliance.org/) é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software. A denominação “ágil” deriva de uma mudança radical na forma de implementar projetos de software, que foi criada à partir do chamado “Manifesto Ágil” (manifestoagil.com.br/). Neste é estabelecida uma nova filosofia de trabalho, bastante diferente daquela preconizada pelo PMI, sustentada nos seguintes fundamentos: • Indivíduos e interação entre eles mais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação de contratos; • Responder a mudanças mais que seguir um plano. A mensagem é clara: - Vamos evitar perder tempo com tudo o que não seja ter o software funcionando, como negociado com o cliente, no menor prazo possível. Na cultura do Scrum, responder as mudanças é mais importante do que controlá-las. O controle integrado de mudanças é visto como burocrático. Como o Scrum funciona? Um projeto de software, geralmente, implementa um conjunto de funcionalidades que atendem determinados requisitos técnicos e operacionais. O trabalho necessário para desenvolver tais funcionalidades é traduzido em tarefas, que são alocadas para os recursos do projeto e gradativamente executadas até a sua conclusão. No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de “sprints”. Cada “sprint” representa um período de tempo dentro do qual um conjunto de tarefas deve ser executado. As funcionalidades que serão implementadas no projeto são mantidas em uma lista que é conhecida como “product backlog”. No início de cada “sprint” (ciclo dentro do qual um conjunto de tarefas é executado), é realizada um reunião de planejamento, chamada “sprint planning meeting”. Nessa reunião, é fornecida para a equipe de projeto a lista de prioridades das funcionalidades que deverão ser implementadas. Por sua vez, a equipe de projeto seleciona as tarefas que serão realizadas dentro desse ciclo (“sprint”) que se inicia. As tarefas alocadas em um “sprint” são transferidas do “product backlog” para o “sprint backlog”. Diariamente, a equipe de projeto faz uma breve reunião, chamada “daily meeting” (geralmente pela manhã), com o objetivo de atualizar-se sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Há controle de mudanças no Scrum? Considerando a cultura do Scrum, o que deve ser feito é “aceitar mudanças de requisitos, mesmo no fim do desenvolvimento”. Se algum tipo de controle de mudanças tiver que ser implementado, este deverá ser o mais leve possível, registrando a mudança no backlog e eliminando tantas aprovações quanto possível. Há algum software de gerenciamento de projetos que suporte o Scrum? A ferramenta de software de gerenciamento de projetos OpenXProcess (http://www.openxprocess.com/) possui um processo baseado no conceito de Scrum que atende às necessidades de equipes de projeto de desenvolvimento de software. Em outras palavras, o OpenXProcess possui uma estrutura padrão para esse tipo de projeto. Quando se abre um novo projeto (“New Scrum Project”) no OpenxProcess é possivel definir o seu perfil, como mostrado na figura 1.

O perfil do projeto conterá os seguintes parâmetros: nome, data de início, duração (“number of 4 week Sprints”) e a chamada “Wiki location” - um endereço de uma página na Internet onde pode ser armazenada informação sobre o projeto. Embora muito conveniente, não é obrigatório preencher o parâmetro “Wiki location”. Tendo criado o projeto e definido seu perfil básico, o próximo passo é alocar os recursos. Há dois papéis básicos (funções dentro da equipe de projeto): o “Scrum Master” e os participantes do projeto (“Participant”). É possível, também, definer as tarefas que serão feitas no Sprint (opção “Sprint task”), alocar recursos para essas tarefas e definir a ordem de prioridade de execução. O Scrum parece fantástico. Será que não falha nunca? Um dos princípios que sustentam o “Manifesto Ágil” afirma que devemos “construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho”. E afirma também que “o método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara”. Ora, esse tipo de coisa, no mundo real, não é tão fácil assim de conseguir e se reflete diretamente no resultado dos projetos, sejam eles desenvolvidos dentro da cultura do PMI ou do Scrum. As pessoas normais têm diferentes tipos de motivações, comportamentos e não estão, geralmente, niveladas do ponto de vista do conhecimento técnico e da experiência. Além disso, como todo mundo, pessoas têm dificuldades de comunicação e uma “conversa cara a cara” pode ser transformar em um bate boca quando diferentes pontos de vista são colocados no foco de uma discussão. Isso sem mencionar como certas empresas dimensionam as áreas de trabalho de seus programadores. Embora não sendo uma regra geral, eu mesmo já vi, em mais de uma empresa, áreas de programação com dezenas de programadores trabalhando em baias apertadas, nas chamadas fábricas de software. Para os outros funcionários que tinham o privilégio de uma baia de tamanho regular, os pobres programadores eram alocados em verdadeiros “poleiros”, de tão reduzido era o espaço físico disponível. Então, como falar em “ambiente e suporte necessário”? Quando pensamos em recursos humanos, podemos considerar, por simplificação, quatro tipos mais comuns de pessoas; a saber: (a) inteligentes e muito dedicadas ao trabalho, (b) inteligentes e menos dedicadas ao trabalho, (c) não inteligentes e muito dedicadas ao trabalho e, finalmente, (d) não inteligentes e menos dedicadas ao trabalho. Na teoria, o Scrum funciona muito bem se todos os membros da equipe do projeto são do tipo (a), entretanto, isso nunca ocorre no mundo real. Por isso é comum que conflitos surjam, ou melhor, conflitos que parecem surgir praticamente do nada, quando os recursos do tipo (a) sentem que estão carregando o projeto nas costas. Finalmente, não podemos deixar de mencionar o enorme desafio em lidar com certos tipos de clientes que estão sempre pedindo mais alguma coisa e, por princípio e estratégia, afirmam que nunca estão satisfeitos. Negociar com esse tipo de cliente é semelhante a enxugar gelo, um trabalho que não tem fim e cujo resultado já sabemos de antemão será um fracasso. As seguintes afirmações também fazem parte do alicerce do “Manifesto Ágil”: - “Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor; - Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas”. Quando se trabalha com pessoas razoáveis e minimamente organizadas é possível ser bem sucedido tanto seguindo o Scrum quanto o PMOBK guide. Mas o mundo não é feito apenas de pessoas razoáveis, que representam empresas que cultivam a idéia de acordos ganha-ganha, onde há soluções mutuamente benéficas. Posso testemunhar ter presenciado muitas situações de empresas, tentando levar vantagem de sua posição de poder e influência, buscaram apenas o que era melhor para si, desconsiderando quase que totalmente que aquela decisão causaria prejuízos para a outra parte. O scrum é, sem dúvida, uma nova forma de trabalhar com projetos, notadamente na área de desenvolvimento de software, mas não é uma solução mágica e perfeita. Pode funcionar em muitos casos e em tantos outros pode fracassar. Embora por razões diferentes, o mesmo vale para um projeto que é implementado segundo a cultura do PMI. A boa notícia é que os projetos são feitos por pessoas e que, independentemente do método escolhido, nós é que teremos que lidar com eles e encontrar as soluções que o levem a um resultado bem sucedido. Para referenciar esse astigo use: SIMOES, H. M. C. "Scrum x PMI: um choque de culturas". Blogger: H12S Serviços Educacionais, setembro, 2012.