Mapeamento entre MPS.BR e Scrum-Parte-II-Nível G

Processo GRE-Gerência de Requisitos-Atualizado em 07/10/2010

Pontos de atenção: Existem diferenças de terminologia na Gerência de Requisitos  entre os modelos MPS.BR e Scrum. Os conceitos de requisitos de negócios e  requisitos de clientes são mapeados para conceitos de  Temas e Épicos. Os casos de uso ou cenários de casos de usos são mapeados para estórias.É somente uma questão de mapeamento e ajuste fino de conceitos.Os pontos críticos que poderão aparecer na aplicação de GRE nas empresas ágeis se estendem à filosofia de “fazer” e não necessariamente de “documentar”, ou de que os próprios “stakeholders”, como P.O  são a própria  materialização dos requisitos, descaracterizando uma necessidade e documentação mais formal. Os registros de reuniões, via atas, mesmo que simplificadas, ou o registro de “issues” deverão ser pontos de atenção dos implementadores.

Resultados esperados do MPS.BR

GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos;

Idéias sobre evidências: Os Product Owners são os fornecedores naturais de requisitos , dentro do modelo Scrum. Podem ser um cliente interno(da própria empresa), ou externo(da contratante).O Release Plan identifica os P.O(Product Owners), que são os grandes fornecedores de requisitos da área do Produto ou do Sistema. O Relatório de Product Backlog inclui o fornecedor de cada requisito. O Relatório de Temas/Épicos, representando grandes requisitos definidos pela área de Produtos/Sistemas, mantém equivalência com Lista de Requisitos de Negócios e Requisitos de Clientes. A reunião de Sprint Planning 1 (SP 1) selecionando os itens do Product Backlog e criando os requisitos da Sprint está no cerne da Gerência de Requisitos. A utilização de check-list na reunião de Sprint Planning 1, visando aplicar sobre os itens do Product Backlog, caracteriza uma avaliação dos requisitos.

GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido;

Idéias sobre evidências: No Release Planning e no Sprint Planning(SP1 e SP2) há atividades de revisão e refinamento de requisitos, que de certa forma sugerem a busca de entendimento e do comprometimento com a equipe . No SP1, a aplicação de check-list  visando analisar os itens do Product Backlog, promovem o entendimento e por conseguinte, o comprometimento da equipe com os requisitos.O Scrum Team(STeam), durante o Daily Scrum também cria comprometimentos implícitos, analisando, embora de forma expedita, os impedimentos e as ações planejadas. Isso  seria uma forma de também evidenciar esse resultado.

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

Idéias sobre  evidências: A empresa deve oferecer mecanismos de rastreabilidade, via as ferramentas existentes. Os níveis de rastreabilidade mínimos e bidirecionais  devem contemplar: Temas/Épicos para Requisitos;Casos de Testes para Requisitos;Casos de Uso para Diagramas de Classes; Diagramas de Telas/GUI  para  Requisitos, Código com Requisito, via tags de ferramentas de controle de fontes, etc.  O uso de ferramentas Case, como EA(Enterprise Architect), por exemplo, pode ajudar na rastreabilidade ligando requisitos a elementos de engenharia como componentes, classes, pacotes, etc. O mapeamento entre Itens de Backlog e Requisitos é direto.

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;

Idéias sobre evidências: As atas das reuniões de Sprint Review, com requisitos avaliados e validados; um relatório produzido mostrando os itens daquela Sprint, com a informação sobre a realização de validação  sobre eles são fontes de evidências. A análise dos impactos de alterações de requisitos sobre os artefatos usados no Scrum(Release Plan, Sprint Plan,  Agile radiator contendo os detalhamentos de estórias,etc) servem também como evidência desse resultado. Em níveis mais maduros, as ações de GQA são também fontes de evidências para esse resultado. 

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

Idéias sobre evidências: Solicitações de mudanças e análise de impacto sobre os itens. Os registros formais de SM(Solicitação de mudanças) e o racional de impacto, elaborado,via rastreabilidade, são evidências desse resultado. Aqui entram os mecanismos de “issue tracker”, como Mantis, BugZilla, Scarab,etc, como elemento importante no registros das alterações. O número da “issue” associada ao código fonte define , por exemplo, a rastreabilidade entre o Item de backlog alterado e o código afetado.

Processo GPR-Gerência de Projetos

Pontos de atenção: A Gerência de Projetos, dentro do MPS.BR tem sabor semelhante ao  do PMBOK. Nesse mapeamento para Scrum, deve prevalecer a premissa  de que alterações deverão ser acolhidas nos processo Scrum, a fim de criar aderência com resultados esperados do MPS.BR. Aqui o ponto forte de atenção deverá ser o conceito de projeto(o release, por exemplo, no gráfico apresentado), composto de diversas iterações(sprints). Além disso, a necessidade de se criar artefatos que “documentem” o conceito de projeto, como Release Plan. A parte de acompanhamento de projetos também deverá ser observada com atenção em função dos aspectos mais "libertários" dos modelos ágeis. 

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

Idéias sobre  evidências: O conceito de Temas, evidencia os grandes requisitos que formam o escopo do projeto. Os Temas se dividem ou mapeiam em épicos. Os Épicos são decompostos em Requisitos, que são os chamados itens de backlog. É uma espécie de hierarquia entre Temas  para  Épicos  e de Épicos para Requisitos. No Release Planning, na fase de Pré-Game, ficam registrados os temas(ou seus épicos) daquele Release, que deverão estar documentados no Release Plan. Esse conjunto de elementos evidencia o escopo do trabalho dentro da visão Scrum.

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

Idéias sobre evidências: A estimativa inicial é feita no SP1(Sprint Planning 1), onde os backlogs são selecionados para entrar no Sprint(formando o Selected Backlog). No SP2(Sprint Planning 2), quando cada item(requisito) é decomposto em atividades, é feita a estimativa de tamanho , via Poker Planning, por exemplo, com a participação da equipe, dando o maior valor, menor valor e o mais provável. Algumas empresas ágeis definem que cada atividade deve caber em 1 dia. Caso necessário, pode ocorrer uma reestimativa, a ser feita numa reunião (por demanda), denominada reestimate meeting.Essas reuniões deverão ser evidenciadas com atas, mesmo que numa forma simples e objetiva.

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

Idéias sobre evidências: O ciclo de vida mostrado na figura 01 evidencia o estilo clássico dos modelo ágeis: Pregame, Development e Postgame. Mostrar um gráfico com os ciclos de vida, destacando os marcos evidencia o ciclo de vida do projeto.Os diversos tipos(modelos) de processos(já adaptados pelos diferentes business da empresa) também evidenciam diferentes ciclos de vida, no caso de empresas em nível maior que F . Para empresas menores que nível E, a descrição do ciclo de vida adotado naquele projeto, com a definição dos marcos é suficiente para resolver essa evidência.

GPR 4. (Até o nível F) 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;

Idéias sobre evidências: No caso de níveis até F, deverá haver um racional definido que evidencie o mecanismo de estimativa. A aplicação de “ideal days” para definição de tamanho  de onde derivam o esforço e custo, usual em Scrum, é plenamente adequada, desde que esse racional seja registrado/explicitado formalmente.

GPR 4. (A partir do nível E) O planejamento e as estimativas das atividades do projeto são feitos baseados no repositório de estimativas e no conjunto de ativos de processo organizacional;

Idéias sobre evidências: Um repositório deverá conter medidas e estimativas derivadas das sprints anteriores, que devem servir de base(exigência de nível maior que F) para as estimativas daquele projeto. 

GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos;

Idéias sobre evidências: O cronograma deve existir para empresas ágeis, mas isso pode ser questionado pelos valores e princípios adotados na visão mais estrita. O cronograma, existindo, mostrará as fases de Pregame, Development e Postgame. Dentro do Pregame, existem as atividades de planejamento, como o Release Planning. Dentro da fase de Development, existem as sprints(interações). Cada Sprint pode ter atividades de Presprint, Sprint e Postsprint, que podem rodar em paralelo, (entre sprints)  otimizando  o processo com paralelização de atividades, executadas por equipes disjuntas.Enquanto uma sprint x está na fase de postsprint(teste), por exemplo, a sprint x-1, está desenvolvendo e a sprint x-2, está em planejamento, com sprint planning. Algumas empresas não tem o plano de custo definido por projeto. Muitas vezes, em empresas ágeis, o controle é feito pela gerência global. Algumas empresas, com foco em Produto também consideram o custo do projeto como investimento.Caso verdadeiro, essas asserções deverão estar na Política de Gerência de Projetos, o que reforçará  a evidência.

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;

Idéias sobre evidências: No Release Plann deve existir uma seção de riscos do projeto(release). Nas reuniões de Daily Scrum existem as anotações de impedimentos, associados aos riscos(presentes no Agile Radiator). Aqui aparecerão discussões: Os modelos ágeis, por personalidade, assumem riscos. Esses poderão ser mitigados pelas próprias características de ciclos curtos, presença forte de cliente e coesão de equipe. Até nível F, uma abordagem inicial de riscos por projetos deve ser estabelecida e os modelos ágeis deverão absorver isso no Release Plan. Para níveis maiores que F, deve existir um plano de gerenciamento global de riscos, que atenderá ao processo GRI, caso esteja sendo implantado esse processo(nível C) .Uma empresa com modelos ágeis deverá pensar nessa concessão/flexibilização, caso deseje a certificação, visto a abordagem ágil ser naturalmente afeita a riscos e dotada de personalidade  própria para mitigá-los.

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

Idéias sobre  evidências: O Release Plan(equivalente ao Plano do Projeto) deverá conter as habilidades requeridas para o projeto. Em uma empresa mais estruturada deverá haver uma descrição das habilidades requeridas por papel. Também nessas empresas deverá haver um mapeamento de competências por pessoa, contendo a classificação do conhecimento em certa escala. Como as empresas ágeis centram fortemente no aspecto "tête-à-tête" das equipes, poderá haver mecanismos de Auto-avaliação em conjunto(todos olhando e ouvindo a auto-avaliação), além das avaliações tradicionalmente praticadas. As empresas ágeis deverão oferecer algum racional que evidencie que os recursos devidos foram alocados nos respectivos papéis e isso pode estar no Release Plan.

GPR 8. Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados;

Idéias sobre evidências: O Release Plan(Plano de projeto) deverá ter uma seção com recursos e infraestrutura requeridos para aquele release. A empresa deverá/poderá ter um Plano Global de Recursos, com infraestrutura por papel, por exemplo, que facilita o "setup" de novos colaboradores. Na fase de Pregame, normalmente existem atividades que analisam os recursos potencialmente demandados pelo Projeto. Essa análise deverá ser realizada confrontando-se esse conjunto de recurso corporativo.

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;

Idéias sobre evidências: As empresas deverão ter um Plano Global de Configuração que regula os artefatos, templates, etc, genericamente chamados de Itens de Configuração e suas respectivas formas de controle(versionamento,baselines, etc). Algumas empresas colocam no Agile Radiator a lista dos recursos mais relevantes daquela sprint, ou do release. Estruturas de pastas, diretórios e repositórios de documentos gerados nos releases/sprints complementam essas evidências.

GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos;

Idéias sobre evidências: O Release Plan, definido no Release Planning é estabelecido integrando os outros planos.No Release Plan, há informações sobre o projeto, além dos outros planos integrados a ele, como o plano de gerência de configuração, plano de integração dos produtos da família, plano de riscos, plano de auditoria de qualidade, etc. No caso de empresas que desenvolvem produtos, poderão existir planos muito semelhantes, pois os projetos são recorrentes. Uma forma de se reduzir essa duplicação é definir políticas que estabeleçam  a necessidade de planos quando houver exceção no projeto, ficando os aspectos genéricos válidos para os que seguirem o comportamento padrão.

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;

Idéias sobre evidências: Existem pontos onde a análise de viabilidade é aplicada: no início do projeto, na elaboração do Release Plan, no início de cada sprint(Sprint Planning 1), e também verificada no daily scrum, através da análise de impedimentos. No Release Planning , existe uma avaliação da viabilidade das diferentes dimensões envolvidas no Release(recursos humanos, tecológicos, etc).

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

Idéias sobre evidências: No Release Planning e no Sprint Planning há atividades de revisão buscando comprometimento com a equipe . O Scrum Team, durante o Daily Scrum também estabelece comprometimentos implícitos. Atas/registros de release planning, sprint planning e daily scrum são fontes de evidências. Nesse último, até a fotografia do agile radiator pode ser aceita como evidência.  Esse resultado pode ser controverso devido aos aspectos naturais dos modelos ágeis, onde colaboração, coesão e integração são princípios subentendidos com prioridade sobre processos( e consequentemente, suas documentações). Deverá haver concessões/flexibilizações nesse ponto.

GPR 13. O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados;

Idéias sobre evidências: O Release Plan e os planos associados são fontes de evidência. Em vários momentos  deve-se ter registros de acompanhamento:Registros no Sprint review, Retrospective meeting(feita após a sprint review, com o que deu certo, o que deu errado); no Agile Radiator, com os impedimentos também documentados. Os impedimentos do daily scrum são rastreados com os Riscos definidos no início e os seus registros poderão ser feitos com certo delay(não imediatamente).

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

Idéias sobre evidências: No Sprint Review, feito após a sprint, com registros/atas. No Release Plan, definido a equipe do projeto(envolvidos). A agenda do Sprint Review e as apropriações de tempo no Sprint review são também evidências desse resultado. Um Plano de comunicação,mostrando  quem envia o que para quem, evidencia também esse resultado. Aqui pode haver controvérsias novamente devido aos princípios e valores do modelo ágil que sustentam que indivíduos e interações tenham prevalência sobre ferramentas e processos .

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

Idéias sobre evidências: O Sprint review pode ser considerado como um -marco- do projeto., quando feito após cada sprint, e com os devidos registros/atas sobre as revisões.Um relatório preparado pelo Scrum Master para a reunião de Sprint Review, mostrando todos os itens do Selected Backlog da Sprint(que foram detalhados em Sprint Backlog) e que será usado na validação da Sprint. Esse relatório pode ser incorporado à ata de reunião do Sprint Review.

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;

Idéias sobre evidências: Os Registros de Retrospective Meeting, reunião que acontece após a Sprint Review e tem como objetivo uma análise mais crítica sobre a Sprint, com o levantamento das questões: WCBI(what can be improved?), WWW(what went well?). O acompanhamento dos impedimentos, no Daily Scrum também são evidências, se forem  registradas.

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;

Idéias sobre evidências: As reuniões de Daily Scrum, com registro de impedimentos, definição de tempo para resolvê-los e cobrança no Daily Scrum subsequente são pontos importantes.Os registros da Retrospective Meeting com acertos de problemas e sugestões de melhoria são fontes de evidências desse resultado.