Scrum e o gerenciamento de projetos

Projeto é todo trabalho que possui uma ou mais atividades bem definidas, que precisam ser completadas em um período determinado por uma data inicial e uma data final. Para que os projetos sejam bem entendidos, executados e entregues com qualidade é necessário que haja no mínimo um planejamento prévio, uma alocação de profissionais qualificados, uma direção e um controle eficiente, além de uma experiência para antecipar possíveis problemas com o intuito de evitá-los. Isso tudo junto e aplicado a um projeto, chama-se gerenciamento de projetos.

As principais abordagens de gerenciamento de projetos utilizadas em grande escala atualmente são a tradicional e a ágil. A primeira é identificada por determinar uma sequência de passos a serem completados formando processos, e a segunda é mais vista como um conjunto de pequenas tarefas, ao invés de um processo completo. No Brasil, a mais divulgada nos dias de hoje dentre as tradicionais é a contida no Guia PMBOK® (Project Management Body Of Knowledgment), do PMI (Project Management Institute), e entre as ágeis temos o Scrum.

O Scrum é um framework para gerenciamento ágil de projetos, onde o seu conteúdo é relativamente simples, porém a sua aplicação é complexa. O framework do Scrum é um conjunto composto por pequenas equipes, que executam eventos com duração fixa e ciclos iterativos, sempre apoiados por artefatos e regras que servem para unir todos estes componentes.

Neste contexto, este é o primeiro artigo de uma série que irá abordar a aplicação do framework do Scrum apoiado por abordagens tradicionais, em projetos reais de desenvolvimento de sistemas. Os principais assuntos aqui apresentados serão os papéis e responsabilidades do Scrum, aliado e complementado por papéis e responsabilidades existentes no gerenciamento de projetos tradicional, além de algumas maneiras de solucionar problemas de conflitos entre eles.

Scrum

Scrum é um framework para gerenciamento de projetos ágeis muito utilizado na área de desenvolvimento de software. Uma das principais características do Scrum é permitir o desenvolvimento de produtos complexos de uma forma incremental e iterativa, contribuindo para decompor um grande produto complexo, em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem desenvolvidos e entregues. No Scrum estas iterações são chamadas de Sprints, e uma característica marcante de sua estrutura e aplicação é o controle sobre os trabalhos realizados, e a possibilidade de correção e adaptação rápida, permitindo que a equipe altere sua forma de agir ou de pensar o mais breve possível, evitando que problemas ou erros causem danos maiores ao projeto.

O Scrum possui vários eventos definidos para acontecer em determinados momentos da execução do projeto, e o mais importante deles é a Sprint, que é também a principal responsável pelo sucesso da aplicação deste framework, concentrando alguns dos pontos mais positivos e de maior destaque do Scrum.

O conceito da Sprint permite a divisão de um grande projeto que possui uma data de início e uma data de entrega final, em vários outros pequenos projetos, com várias datas de início e fim bem definidas. Esta divisão possibilita que as tarefas de controle sejam realizadas em cima de partes menores, mais claras e mais visíveis, além do término total de pequenas partes do sistema ao final de cada um destes pequenos “projetos”.

Em resumo, a Sprint é uma caixa fechada que possui uma data determinada para iniciar e terminar, possuindo atividades bem definidas para serem cumpridas neste tempo limitado, sendo justamente esta caixa fechada a maior qualidade da aplicação do Scrum.

O conceito de “caixa” permite o controle total do que está contido dentro dela, possibilitando a percepção de erros ou desvios mais rapidamente pelos envolvidos, e consequentemente a reação a estes desvios é mais rápida, evitando que os problemas causem estragos grandes e mitigando a possibilidade de danos irreparáveis. Porém, muitos questionamentos ainda são feitos quanto à eficiência e eficácia do Scrum em grandes projetos, ou como ele aborda e trata as documentações de apoio ao desenvolvimento, e principalmente como o gerente de projeto, ou o gerenciamento de projetos tradicional se encaixa no meio destes conceitos ágeis que o Scrum prega.

Neste contexto, o objetivo deste artigo será justamente entender um pouco mais sobre estes questionamentos, sugerir como respondê-los durante um ciclo de desenvolvimento de sistemas, e mostrar que o gerenciamento de projetos tradicional pode complementar e fortalecer o Scrum, assim como o Scrum pode complementar e fortalecer o gerenciamento de projetos tradicional. Eles não precisam ser excludentes, e nem tão pouco concorrentes.

Existem várias abordagens difundidas e bem aceitas atualmente no mercado de gerenciamento de projetos tradicional, tais como o Guia PMBOK®, PRINCE2, IPMA entre outras. No entanto, não iremos comparar o Scrum a nenhuma destas abordagens específicas neste momento. O objetivo aqui será tratar o gerenciamento de projetos como uma área de conhecimento geral, relacionando algumas das práticas e papéis comuns à maioria das abordagens tradicionais, com as práticas e papéis descritos pelo framework do Scrum.

Papéis e responsabilidades no Scrum

Em qualquer tipo de projeto, e seja qual for a abordagem de gerenciamento, o primeiro ponto a ser tratado e um dos mais importantes e influenciadores para o sucesso de um projeto, é a identificação correta dos papéis e responsabilidades necessárias para a condução do projeto. Como complementação, é de fundamental importância a divulgação clara destas definições para toda a equipe envolvida, levando em consideração os times da empresa executante e da empresa contratada.

O Time Scrum é definido a partir de três papéis bem claros, o Scrum Master, o Product Owner e o Time, onde suas principais responsabilidades são:

• Scrum Master: É o responsável por garantir que o Time siga as regras do Scrum, e por remover os impedimentos existentes para que o Time não tenha problemas em atingir a sua meta;
• Product Owner: É o responsável por gerenciar o escopo do projeto, e por garantir o valor do trabalho gerado pelo Time;
• Time: É o responsável por executar o desenvolvimento, e transformar o escopo definido para o projeto em um sistema pronto e disponível para entrega ao cliente. As equipes que utilizam o Scrum gostam de intitular este trabalho de “mão na massa”, porque é efetivamente composto pelas tarefas de construção do sistema, e envolve todos os trabalhos técnicos de desenvolvimento.

O termo descontraído “mão na massa” evidencia que o Scrum é bem direcionado e voltado para a etapa de desenvolvimento. Os papéis do Scrum parecem atender muito bem a necessidade de construir um incremento do sistema, onde de maneira resumida o Product Owner define o que é preciso ser construído, e qual a ordem de construção. O Time entra no processo entendendo as necessidades trazidas pelo Product Owner e definindo como realizará os trabalhos necessários para atingir a meta do projeto, além de também ser o responsável por determinar a sua própria capacidade e velocidade de trabalho. Por fim, o Scrum Master assume a responsabilidade de contribuir e garantir que o Time siga as regras do Scrum durante os trabalhos de desenvolvimento, além de ser a pessoa mais indicada para remover obstáculos, orientar a resolução de problemas que atrapalhem a evolução dos trabalhos do Time e fazer com que o trabalho flua sem interrupções e com a produtividade mais alta possível dentro dos padrões estabelecidos pelo próprio Time.

Apesar de parecer bastante simples, é aqui que começam alguns dos problemas ou questionamentos referentes a papéis e responsabilidades.

Quando se pensa nos trabalhos específicos de desenvolvimento com o objetivo de entregar uma parte do sistema, os papéis do Scrum parecem atender muito bem a esta necessidade, porém, é preciso refletir e pensar sobre a existência de outros trabalhos que precisam ser realizados.

É comum que antes, durante e após a etapa de desenvolvimento, diversas outras tarefas sejam concluídas em paralelo contribuindo para que um projeto seja bem sucedido, e influenciando para que o ambiente externo ao Time Scrum não afete os seus trabalhos, e nem tão pouco os trabalhos do Time afete o ambiente externo. Sendo este o primeiro ponto que o gerenciamento tradicional pode complementar o Scrum e dividir a responsabilidade de algumas tarefas, e onde os papéis no Scrum começam a ser relacionados a outros existentes na abordagem tradicional.

O gerente de projeto no apoio

Um dos papéis mais polemizados quando o assunto é Scrum, é o tradicional gerente de projetos. Primeiro porque este papel específico não aparece nas definições de papéis do Scrum, e segundo por que o Scrum defende que o Time deve ser auto-gerenciável, o que resumidamente é interpretado como não havendo a necessidade de ter um gerente de projetos na equipe.

Considerando o Time Scrum conforme definição, e aplicando esta formação de time em projetos de desenvolvimento de software, temos duas situações que se evidenciam quase que naturalmente:

• Situação A: Um pequeno projeto, com poucos recursos, um prazo curto e pouco dinheiro envolvido tem mais chances de ter sucesso, e funcionar bem, atingindo o objetivo proposto, sem um gerente de projeto envolvido em nenhuma etapa, desde que o Scrum seja bem aplicado;
• Situação B: Um projeto médio ou grande, com dezenas de pessoas, uma duração maior que um ano, com aquisições de máquinas ou equipamentos caros e alguns milhões investidos, tem menos chances de alcançar o sucesso, principalmente por gerar uma grande insegurança e até uma desconfiança no poder de auto-gerenciamento do Time Scrum. Isso geralmente se dá, especialmente, por questões que frequentemente acompanham projetos com as características mencionadas neste item, tais como: “Quem cuidará dos custos do projeto?”, “Quem definirá os recursos necessários e envolvidos com todo o projeto?”, “Quem negociará mudanças no custo e no prazo com o cliente?”, “Quem tratará do gerenciamento das aquisições?”, “Quem gerenciará os riscos?”, “Quem observará a estratégia da organização em relação à estratégia do projeto?”, “Quem desenvolverá os recursos humanos do projeto?” ou “Quem fará o gerenciamento dos stakeholders?”.

Por refletir sobre estas duas situações, e ter dificuldade na resposta destas questões é que vários profissionais da área de sistemas, e até de outros setores, são descrentes quanto ao funcionamento do Scrum em grandes projetos. Realmente olhando apenas para as situações apresentadas acima, e considerando apenas o Time Scrum assumindo todas as responsabilidades descritas, aliada a ausência de um gerente de projeto, fica mesmo fácil ter esta impressão e acreditar que somente pequenos projetos funcionam com Scrum.

Por isso a proposta desta série de artigos é justamente mostrar que o Scrum funciona tanto em projetos pequenos e curtos, como em projetos grandes e longos, levando em consideração equipes, custos, prazos e complexidade. Sendo que para isso basta o suporte de algumas outras abordagens que podem apoiar o Scrum, e principalmente dividir certas responsabilidades entre os papéis do Scrum e os papéis mais tradicionais, que neste caso agirão como complementares uns dos outros.

Ainda observando as duas situações citadas, alguns grupos podem responder rapidamente que o próprio Time Scrum poderá ser responsável por todas as atividades contidas tanto na situação A, quanto na situação B. Porém, caso isso seja realmente feito, surge pelo menos uma nova questão tão importante quanto as outras: “Se o Time Scrum ficará responsável por todas as tarefas de gerenciamento que não se encaixam nas conhecidas como ‘mão na massa’, quem efetivamente desenvolverá e entregará o produto do projeto no prazo estimado?”, ou “É possível que o Time Scrum gerencie todas as áreas que precisam de gestão, inclusive se auto-gerencie durante o desenvolvimento, e consiga ser produtivo, mantendo a qualidade e entregando o sistema proposto?”.

Este último questionamento, em conjunto com os exemplificados na situação B, formam um grupo de perguntas que são difíceis de serem respondidas tendo à disposição apenas os papéis existentes no Scrum. Por isso dá-se início a reflexão sobre a importância e contribuição do tradicional papel do gerente de projetos, complementando e ajudando o Time Scrum.