Implementando o MPS.BR com SCRUM – Nível G (Parte 1 – Gerência de Projetos)

Este é o primeiro da série de posts que tratarão o tema da implementação do MPS.BR com o framework do SCRUM. Serão apresentados os resultados esperados e RAPS presentes no guia de implementação do MR-MPS-SW, e como estes podem ser traduzidos para o contexto da agilidade.

É importante frisar que estes posts tratarão de idéias e dicas e não como a implementação é feita integralmente.

Uma breve introdução sobre o MR-MPS-SW

O MR-MPS-SW, ou Modelo de Referência do Software Brasileiro, é um programa mantido pela SOFTEX que tem por objetivo arquitetar uma indústria brasileira de software competitiva nos cenários nacional e internacional. Isto é, utilizar as práticas de Engenharia de Software para aperfeiçoar seus processos organizacionais no intuito de desenvolver produtos com padrões de qualidade aceitos internacionalmente.

O modelo de referência define níveis de maturidade para as organizações que vão do G ao A e estão descritos nos Guias de Implementação, que podem ser encontrados no site da SOFTEX. Cada nível possui processos específicos a serem implementados, sendo estes descritos por meio de resultados esperados.

Nível G

No nível G, Parcialmente Gerenciado, são dados os primeiros passos no sentido da mudança da cultura organizacional no que se refere ao aperfeiçoamento dos seus processos. Neste nível é dada importância na definição de alguns padrões dos projetos da organização.

O nível G trata dos processos de Gerência de Projetos e Gerência de Requisitos, que serão tratados a seguir e no próximo post, colocando-os frente a frente com o SCRUM.

Gerência de Projetos

Resultados Esperados do nível G:

GPR 1. O escopo do trabalho para o projeto é definido.

GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.

O GPR 1 trata de definir o que há de ser feito no projeto, suas restrições e limites, já o GPR 2 trata da complexidade do que há de ser feito. Trazendo estes para o mundo SCRUM, podemos implementá-los através do Product Backlog. Se no início do projeto forem inseridas as histórias a serem realizadas, mesmo que sejam macro-histórias, há uma definição de escopo, e ao realizar estimativas, utilizando, por exemplo, o planning poker, a complexidade individual destas está sendo definida.

GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos.

Aqui está sendo definido, de fato, que será utilizado o SCRUM com suas cerimonias etc.

GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas.

Mantendo-se registros dos Product Backlogs e Sprint Backlogs antigos é possível estimar com algum nível de precisão o HH necessário para a realização do novo projeto. É uma boa prática guardar informações de contexto sobre estes, por exemplo: datas de início e fim, quantos desenvolvedores seniors, juniors participaram, quais suas cargas horárias, horas extras, quantos pontos foram planejados, aceitos e reprovados. Isto ajuda o seu especialista analisar o que ocorreu para evitar que possíveis problemas venham a acontecer.

Este foi o primeiro post da série da união do MPS.BR com o SCRUM. No próximo post darei seguimento ao processo de Gerência de Projetos – GPR.