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.
Aguardo a parte 2
Quero muito a continuidade pois vou defender um TCC na minha MBA sobre Implantaçao de MPS.BR com Scrum.
Assunto interessante. Aguardando a parte 2.
Muito interessante o assunto! Fico no aguardo da parte 2!