Mapeamento do Scrum para o nível G do MPS.BR

O nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos aumenta a cada dia (MOREIRA, 2009). E para acompanhar a exigência do mercado, as empresas têm buscado cada vez mais a maturidade nos seus processos de software para atingir padronizações de qualidade e produtividade nacionais e internacionais, que são essenciais para a sobrevivência no mercado de TI (Tecnologia da Informação).

Por outro lado a evolução dos processos de desenvolvimento de software impactou na exigência do mercado, cada vez mais querem softwares melhores e mais baratos, prazos mais curtos e orçamentos mais reduzidos, requerendo equipes menores e mais produtivas. As empresas cada vez mais estão investindo em processos que permitam ganhar produtividade e qualidade, pois nosso dia a dia está cada vez mais dependente de softwares que funcionem de forma segura e precisa (BARTIE, 2006).


Neste contexto, esse artigo propõem mapear as práticas do Scrum aos resultados esperados do nível G do MPS.BR (Melhoria de Processo do Software Brasileiro) para que as empresas tenham a possibilidade de definirem processos que produzam software com alto padrão de qualidade e sejam certificados e reconhecidos nacionalmente, tendo ainda, uma produção de software ágil e eficiente.


Para cada resultado esperados dos processos exigidos pelo nível de maturidade G serão diagnosticados como:

- Satisfeita: quando em Scrum possuir práticas explícitas que sirva como evidência na avaliação do MPS.BR e que cubra completamente o resultado esperado em questão.

- Parcialmente satisfeita: quando em Scrum possuir práticas explícitas que sirva como evidência na avaliação do MPS.BR e que cubra pelo menos parte do que o resultado esperado define.

- Não satisfeita: quando em Scrum não houver nenhuma prática explícita que seja evidência na avaliação do MPS.BR.




Processo: Gerencia de Projetos – GPR
- GPR 1. O escopo do trabalho para o projeto é definido.

- Análise: Em Scrum, o Product Backlog e o documento de visão, criados durante a fase de planejamento, provêem a definição do escopo do projeto. Com esse escopo inicial, é possível estimar a quantidade de iterações e o tempo de desenvolvimento necessário para o desenvolvimento do produto.

- Diagnóstico: Satisfeita.

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

- Análise: As tarefas e produtos de trabalho são estimados em cada Sprint. As estimativas são feitas utilizando métodos que envolve toda a equipe desde do Scrum Master até o desenvolvedor, e cada Sprint a equipe se torna mais apta a estimar corretamente. Portanto, os métodos para estimar as tarefas e produtos são apropriados.

- Diagnóstico: Satisfeita.

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

- Análise: Em Scrum, o projeto tem um ciclo de vida iterativo/incremental e que pode ser definido em quatro fases: Planejamento, Preparação e escalonamento, Desenvolvimento e Entrega.

- Diagnóstico: Satisfeita.

- 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.

- Análise: Em Scrum as tarefas e produtos de trabalho são estimados a cada sprint. Estas estimativas são baseados em dados históricos, isto é, na experiência que a equipe teve em outros projetos e no projeto em questão a medida que avança o seu desenvolvimento. Contudo, Scrum não define que as estimativas devem ser documentadas.

- Diagnóstico: Parcialmente satisfeita.

- GPR 5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos.

- Análise: Com as estimativas de esforço do Product Backlog e uma idéia da produtividade da equipe, estabelece-se um primeiro cronograma do projeto através da divisão em Sprints de trinta dias. esse cronograma é automaticamente atualizado à medida que o projeto se desenvolve e as funcionalidades são re-priorizadas. O orçamento do projeto, no entanto, não está contemplado nas atividades do Scrum e nem sempre pode ser calculado diretamente do cronograma. Os marcos são feitos ao final de cada Sprint, o progresso do projeto e o cumprimento dos compromissos é revisado na reunião de Sprint Review.

- Diagnóstico: Parcialmente satisfeita.

- GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados.

- Análise: No Scrum não há identificação e monitoramento explícito e sistemático dos riscos do projeto, com seu respectivo impacto e probabilidade de ocorrência, como sugere o nível G do MPS.BR. No entanto, riscos são possíveis impedimentos, e, portanto, podem ser levantados durante a Daily Meeting, e anotados na Impediments List, gerando um levantamento iterativo dos riscos.


- Diagnóstico: Parcialmente satisfeita.

- GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo.

- Análise: No começo do projeto é realizada a alocação do time e da infra-estrutura necessária para todo o desenvolvimento. O Scrum Master e o Product Owner são responsáveis por garantir os recursos e a continuação do projeto, através das reuniões ao início de cada iteração e da remoção de impedimentos levantados pelo time. O time, que é um grupo multifuncional e auto-gerenciado, deve, na medida do possível, ser criado contendo os conhecimentos e as habilidades (técnicas e de negócio) necessárias para desenvolver o Product Backlog.

- Diagnóstico: Satisfeita.

- GPR 8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados.

- Análise: As tarefas, os recursos e o ambiente de trabalho são planejados na elaboração do Product Backlog e no documento de Visão que são previstos no Scrum.

- Diagnóstico: Satisfeita.

- GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança.

- Análise: Em Scrum não há orientações para verificar se existe um plano para gerência de dados listando todos os documentos gerados no projeto, distribuição dos mesmos e mídia para armazenamento, proteção (segurança e sigilo) e recuperação desses dados.

- Diagnóstico: Não satisfeita.

- GPR 10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto.

- Análise: Em Scrum, o documento de Visão e o Product Backlog representam o plano em alto-nível do projeto, com os requisitos funcionais e não-funcionais e o porquê do desenvolvimento do projeto. O Time, Scrum Master e Product Owner revisam os planos e compromissos no início e no final de cada Sprint, durante a reuniões de planejamento (Sprint Planning) e revisão (Sprint Review).

- Diagnóstico: Satisfeita.

- GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados.

- Análise: Em Scrum, a viabilidade é definida pelo time em cada Sprint, já que nas reuniões de planejamento de cada Sprint (Planning Meeting) o time define quais das funcionalidades é viável para eles finalizar durante o período do Sprint. Os ajustes são feitos nas reuniões de retrospectiva (Retrospective Meeting) no qual se tem maior conhecimento do time da produtividade e da complexidade do projeto.

- Diagnóstico: Satisfeita.

- GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido.

- Análise: O compromisso com o plano é obtido continuamente no início de cada Sprint quando as atividades a serem desenvolvidas são negociadas com o Product Owner e o time.

- Diagnóstico: Satisfeita.

- GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados.

- Análise: Em Scrum, o Product Burndown e as reuniões diárias (Daily Meeting) provêem a visibilidade necessária para monitorar o andamento do projeto e conferir desvios no plano. O Sprint Burndown também contribui para isso, mostrando diariamente a velocidade do time e se as funcionalidades que vão ser entregues ao final do período.

- Diagnóstico: Satisfeita.

- GPR 14. O envolvimento das partes interessadas no projeto é gerenciado.

- Análise: Em Scrum o envolvimento dos interessados é garantido pelo Product Owner (que os representa na definição do escopo e das prioridades) e pelo Scrum Master (que deve garantir o cumprimento das regras do Scrum). Evidências indiretas desta participação, como atualizações no Product Backlog, mostram que os stakeholders estão envolvidos no projeto.

- Diagnóstico: Satisfeita.


- GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento.

- Análise: Ao final de cada Sprint, o progresso do projeto e o cumprimento dos compromissos é revisado na reunião de Sprint Review.

- Diagnóstico: Satisfeita.

- GPR 16. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas

- Análise: Durante as reuniões diárias, o time reporta e analisa os problemas encontrados, registrando-os em um quadro branco, cartões de papel ou na Impediments Backlog. Além disso, é responsabilidade do Scrum Master identificar e resolver impedimentos o mais breve possível.

- Diagnóstico: Satisfeita.

- GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão.

- Análise: O Scrum Master é responsável por resolver os impedimentos assim que eles são identificados. No entanto, não há registro ou evidências do planejamento e monitoramento dos impedimentos, impedindo um acompanhamento dessas ações de correção.

- Diagnóstico: Parcialmente satisfeita.

Observamos portanto, que 70,59% dos resultados esperados são satisfeitos nas práticas do Scrum, sendo que 17,65% são parcialmente satisfeitos e apenas 11,76% não são satisfeitos.



3.2. Processo: Gerência de Requisitos – GRE

- GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos.

- Análise: Considerando o envolvimento dos stakeholders, percebe-se que as práticas de Scrum contribuem para garantir e manter uma boa comunicação e colaboração entre o time e os fornecedores de requisitos. Portanto os requisitos são obtidos com a intensa participação dos fornecedores de requisitos.

- Diagnóstico: Satisfeita.

- GRE 2. Os requisitos de software são aprovados utilizando critérios objetivos.

- Análise: Em Scrum são aprovados os requisitos com os fornecedores de requisitos porem não utilizando critérios objetivos.

- Diagnóstico: Não satisfeita.

- GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida.

- Análise: Em Scrum não há nenhuma prática que prevê isto.

- Diagnóstico: Não satisfeita.


- GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos.

- Análise: Em Scrum revisões freqüentes são realizadas a cada iteração (Sprint Review) e diariamente (Daily Meeting), inclusive com ajuda de gráficos (Product Burndown e Sprint Burndown).

- Diagnóstico: Satisfeita.

- GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

- Análise: No Scrum sugere que os requisitos prioritários para fazer parte do Sprint não sejam alterados depois que o Sprint começou, porem se ver a necessidade de mudança o Sprint é interrompido e é feito uma nova reunião de Planning Meeting, a fim de modificar conforme a necessidade. Esta modificação é registra na nova versão do Product Backlog e do Sprint Backlog.

- Diagnóstico: Satisfeita.

Observamos portanto, que 60% dos resultados esperados são satisfeitos nas práticas do Scrum e apenas 40% não são satisfeitos.



Em conclusão tem-se portanto, que o Scrum atende em 68,18% os processos do nível G de MPS.BR. Portanto, nota-se que é possível obter certificação de qualidade do software utilizando-se as boas práticas de uma metodologia ágil, o Scrum, desde de que adapte as poucas práticas que o MPS.BR exige.

Posted in: A Metodologia