Mapeamento entre MPS.BR e Scrum-Parte-V-Adendos e extensões

Adendos e Extensões:atualizado em 26/09/2010-10:45h

Nesta parte, colocaremos as possíveis extensões conceituais desenvolvidas, fruto de novas observações e discussões recebidas.
Uma das primeiras extensões que faço é a análise do livro: Agile Data Warehousing, de Ralph Hughes, 2008, Ceregenics Inc, especialista em projetos de BI com Scrum(dai o meu interesse direto, pois toca nas minhas duas áreas de atuação). Nesse livro, nas páginas 232 a 250, o autor estabelece uma análise, semelhante à que fizemos nos itens anteriores, sobre a aderência do CMMI ao ADW(Agile Data Warehousing, método Scrum/XP para o desenvolvimento de aplicações em BI). Fiz a tradução literal das suas colocações sobre o CMMI e inclui as minhas observações sobre o MPS.BR.

1)GPR e PP- CMMI:PP-Project Planning  e MPS.BR: GPR-Gerência de Projetos

a)CMMI: SG1: Estimates of project planning parameters are established and maintained.
MPS.BR: Equivale aproximadamente à  
GPR2- As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados e
GPR4: (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 colocadas pelo autor: Não há necessidade de ajustes. Num nível abrangente de planejamento, o ADW(SCRUM), usa conceitos de números de estórias,pontos de estórias,velocidade de equipe e gráfico de Release Burndown. Num nível de planejamento mais elaborado, a equipe, dentro das iterações(sprints), aplica conceitos de número de tarefas(tasks),Total original labor estimates-OLE(estimativa total de esforço inicial) e gráfico de burndown de iterações .

Idéias sobre evidências, colocadas por mim: Isso tudo é absolutamente verdadeiro, desde que se tenha os devidos cuidados de se manter registros evidenciando os produtos  e critérios aplicados.

b)CMMI: SG2: A project plan is established and maintained as the basis for managing the project

SP2.2- Identify and analyse risks

SP 2.3-Plan for the management of project data

Equivale aproximadamente aos resultados da  GPR5 a GPR10 do MPS.BR

Idéias sobre evidências colocadas pelo autor: Há necessidade de pequenos ajustes. O ADW(Scrum) necessita que o P.O(Product Owner) e o SM(Scrum Master) discutam os riscos durante as sessões do Sprint Planning 1(que ele chama de Conferência de estórias)  e Sprint Planning 2(que ele chama de task planning). A equipe deverá estimar a severidade desses riscos(P x I) identificados antes do Desenvolvimento e rever essas definições nas avaliações no Retrospective Meeting. O PO, SMaster e o PCA(Project Comunnication Assistant(*) devem colaborar para manter o repositório de documentos do projeto.

(*)-PCA-Project Communication Assistant: novo papel colocado , necessário em grandes organizações, segundo o autor, para liberar o P.O e/ou o SM das tarefas obrigatórias de manter informadas as camadas gerenciais acima do projeto, como IT Manager e outros, sem o que   um projeto Scrum de maior envergadura poderá apresentar problemas. Seria uma espécie de porta-voz do projeto, responsável pela condução do Plano de Comunicação do Projeto.

Idéias sobre evidências, colocadas por mim: Concordo, desde que se tenha os devidos registros efetuados e preservados.Na definição de P x I, basta se fazer uma análise qualitativa dos riscos para se ter idéia de suas probabilidades(alta, média, baixa) e de seus impactos(alto, médio, baixo). Com o aparecimento desse novo papel(PCA) e a necessidade de se manter a comunicação agora menos "tete a tete" e um pouco mais formal, alcança-se um equilíbrio desejável.

2)GPR e PMC- CMMI:PMC-Project Monitoring and Control  e MPS.BR: GPR-Gerência de Projetos

c)CMMI: SG1: Actual  performance and progress of the project are monitored against the project plan;

SG2- Corrective actions are managed to closure of the project  when project´s performance or results deviate significantly from the plan; 

SP 1.1-Monitor the actual values of the project planning parameters against the project plan 

Equivale aproximadamente aos resultados da  GPR13 a GPR17 do MPS.BR

Idéias sobre evidências colocadas pelo autor: Há necessidade de pequenos ajustes. O ADW(SCRUM) desenvolve um Release Plan e cria o Sprint backlog, que servem como planos estratégicos e táticos. Essa combinação deve ser traduzida para "parâmetros de planejamento" para se criar a aderência aos resultados demandados. Essa lista pode ser gerada a partir de conceitos de conhecimento da equipe, como número de estórias,fontes, targets e módulos principais.

Idéias sobre evidências, colocadas por mim: Concordo, que há necessidade de ajustes, mas não entendi que o último parágrafo tenha ido ao ponto.O que é importante aqui no acompanhamento das atividades é: As reuniões de Sprint review, Retrospective Meeting e o Daily Scrum, com certo grau de formalidade nos registros de acompanhamentos e pendências. 

3)GCO e CM- CMMI:CM-Configuration Managenent  e MPS.BR: GCO-Gerência de Configuração

c)CMMI: SG1: Baselines of identified work products are established;

SP 1.1-Identify the configuration itens that will be placed under configuration management 

Equivale aproximadamente aos resultados da  GCO2 e GCO3. 

Idéias sobre evidências colocadas pelo autor: Sem ajustes necessários.É raro uma área de TI hoje que não pratique gerência de configuração usando uma ferramenta de terceiros. No ASW(SCRUM), o build diário enviado para a área/sessões de testes é obtido da ferramenta de change management, verificando se a baseline de cada dia está completa 

Idéias sobre evidências, colocadas por mim: Concordo, atentando para o fato de que deverão ser controlados os IC(versionados ou sob BL) e também as solicitações de alterações sobre eles, com os devidos impactos. Na passagem da Baseline há que se ter auditoria física e funcional para se garantir a integridade dos seus elementos. 

4)GQA e PPQA- CMMI:PPQA-Process and Product Quality Assurance  e MPS.BR: GQA-Garantia da Qualidade

c)CMMI: SG1: Adherence of the performed process and associated work products and services to process descriptions, standards and procedures is objectively evaluated

SG2-Noncompliance issues are objectively tracked and communicated, and resolution is ensured 

Equivale aproximadamente aos resultados do processo  GQA(GQA1 a GQA4) 

Idéias sobre evidências colocadas pelo autor: Sem ajustes necessários.O ADW(SCRUM) garante a qualidade através de vários mecanismos: Apresentações para usuários finais(end user visible quality issues); desenvolvimento conduzido pelo teste(test led development), com a verificação da precisão do código e os aspectos de tolerância a falha; testes de integração contínua e automatizada, observando os aspectos de integração dos módulos) e as ações de verificação, com observação da codificação e padrões externos de integração de sistema.  Há que se ter para as validações anteriores, um conjunto padrão de critérios de aceitação, definido pelo P.O, para serem aplicados durante as sessões de demonstração. Com essa pequena adição, o ADW(SCRUM) não necessita de ajustes outros para obter aderência aos resultados do CMMI.

Idéias sobre evidências, colocadas por mim: Aqui o nosso preclaro especialista fez uma ligeira confusão, normalmente encontrada na esfera da qualidade. Ele focou mais em VER e VAL do que nos aspectos de PPQA(GQA). Esse ponto deverá ser analisado com cuidado pelos implementadores, pois o GQA e PPQA definem a necessidade de uma avaliação neutra dos processos e dos produtos, com maior foco na forma e procedimentos e menos no conteúdo(esse sim, objetivo da esfera do VER e VAL). 

5)MED e MA- CMMI:MA-Measurements and Analysis e MPS.BR: MED-Medições

c)CMMI: SG1: Measurement objectives and activities are aligned with identified information needs and objectives;

SG2-Measurement results , which address identified information needs and objectives, are provided .

Equivale aproximadamente aos resultados do processo  MED(MED1 a MED7) .

Idéias sobre evidências colocadas pelo autor: Sem ajustes necessários.O ADW(SCRUM) obtém pontos de estórias(story points) e estimativas OLE-Total original labor estimates-OLE(estimativa total de esforço inicial), velocidade da equipe(pontos por iteração) e gráficos de burndown. Nós adicionamos outras métricas, através do processo QPM(Quantitative Project Management), como percentagem de estórias, pontos de estórias e OLE(Total original labor estimates-estimativa total de esforço inicial) completados.Também o esforço estimado e real por tarefa(tasks), etc. Essas métricas deverão ser analisadas criticamente e melhoradas nas sessões de Retrospective Meeting, a fim de oferecer as informações necessárias.

Idéias sobre evidências, colocadas por mim: Concordo com a exposição acima, na medida em que aparenta cobrir os resultados de MED. 

Mapeamento entre MPS.BR e Scrum-Parte-I

Nessa parte, começarei pelo gráfico que montei para entender os ingredientes do Scrum. Nele aparecem os principais conceitos de Scrum, como os ciclos de vida de um release, que mapeio aqui para projeto, buscando uma coerência com os preceitos do MPS.BR. As fases são PréGame, Development e PostGame. O development é onde se concentram as sprints(iterações). Cada iteração  tem sessões de planejamento(sprint planning), no caso duas. Tem as sessões diárias de acompanhamento da equipe(daily scrum) e ao final de cada sprint, o sprint review, onde se avalia o objetivo contra o alcance daquela sprint. A seguir temos uma reunião de retrospectiva(retrospective meeeting), onde se levantam as lições aprendidas daquela iteração e os pontos a se considerar para melhorar as próximas.O PostGame encerra o projeto(release), com os testes finais, a produção de documentação de usuário, os treinamentos planejados, a preparação de material de divulgação, etc.As durações estimadas de cada atividade, colocadas no gráfico, podem variar de acordo com o "sabor" Scrum adotado.

Figura 01-Visão geral Scrum

Mapeamento entre MPS.BR e Scrum-Parte-III-Nível F

Considerações sobre o nível F: 

No nível F, aparecem os processos considerados de apoio:GQA(Garantia da Qualidade), GCO(Gerência de Configuração), MED(Medições), GPP(Gerência de Portfólio) e opcionalmente AQU(Aquisições). Alguns desses processos, como GCO certamente tem uma parte significativa praticada nas empresas ágeis, se encontrando nelas, no mínimo, os aspectos relativos à manutenção e controle do código fonte. Outros resultados, como a formalização de itens de configuração, auditoria de baselines, etc poderão não ser observados, a menos em empresas ágeis com certificação F ou maior. Outros processos como GQA  também provavelmente não serão encontrados nas empresas ágeis como preconizado pelo modelo. Aqui poderemos ter alguns ajustes de conceitos, devido aos aspectos vigentes de auto-gestão da equipe e a introdução de auditoria de alguém de fora do círculo, não envolvida no STeam. A parte de Medições(MED) poderá ter alguma aderência com o Scrum, principalmente na elaboração de estimativas, mas lacunas poderão acontecer na sistematização da coleta, análise, divulgação e tomada de decisão a respeito das métricas. A Gerência de Portfólio(GPP), deverá apresentar lacunas grandes, por ser um processo novo, até para as empresas mais estruturadas. O Processo de AQU(Aquisições) deverá ter o mesmo comportamento do GPP devido à sua opcionalidade.   

Processo GQA-Garantia de Qualidade

Pontos de Atenção: Como existe ampla possibilidade desse processo ser uma novidade integral numa empresa ágil sem MPS.BR, o processo de GQA deverá ser implementado como definido pelo modelo. Assim, não deve existir diferença significativa no processo de Garantia da Qualidade (GQA) entre o Modelo MPS.BR e um a ser adotado no Scrum. Claro que estamos falando de um procedimento de aferição formal de qualidade e não uma idéia de qualidade natural, embutida nos processos ágeis, através de seus preceitos de que todos farão com correção pela força da coesão da equipe, de que as iterações , por serem curtas, implicarão menor risco de perda de qualidade, etc. Isso implicará a criação de um Plano de Qualidade a ser aplicado no release, observado nas diferentes sprints.

GQA 1. A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues e em marcos predefinidos ao longo do ciclo de vida do projeto;

Idéias sobre evidências: Relatórios de auditorias de GQA executadas, segundo plano de GQA em pontos do ciclo de vida do projeto. Por exemplo, auditoria de GQA no final do Pregame, durante os sprints do Development(presprint, sprint e postsprint) e durante o postgame . Os relatórios conterão resultados das auditorias de produtos de trabalho, realizados através de check-lists.

GQA 2. A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente;

Idéias sobre  evidências: Relatórios de auditoria de GQA executado, segundo plano de GQA em pontos do ciclo de vida do projeto. Por exemplo, auditoria de GQA no final do Pregame, durante os sprints do Development(presprint, sprint e postsprint) e durante o postgame. Os relatórios conterão resultados de auditoria de processos, realizados através de check-lists. A mesma instância de auditoria avaliará tanto produto quanto processo.

GQA 3. Os problemas e as não-conformidades são identificados, registrados e comunicados;

Idéias sobre evidências: Os problemas detectados durante a auditoria(NC-Não conformidades), serão registrados numa ferramenta de issue-tracker, por exemplo, que deverá permitir o  acompanhamento até a sua resolução. Um dos pontos que poderá ser adotado no Scrum, o que potencializará a conscientização sobre erros e, principalmente, como evitá-los, será a discussão dessas NC dentro das reuniões da equipe(daily scrum ou sprint review), por exemplo.

GQA 4. Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, o escalamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução;

Idéias sobre evidências: O foco aqui é o acompanhamento da NC até a sua conclusão e a possibilidade de escalonamento, em caso de impasses na resolução. Esse ponto tem uma componente  cultural  relativo ao fato dos colaboradores serem " observados" por alguém de fora do “team” e auditado nos seus erros. A filosofia dos métodos ágeis, por conterem traços de comportamento  mais libertos e  de auto-gestão, talvez até facilite esse aspecto.

Processo GCO-Gerência de Configuração

Introdução: Não existe diferença significativa na Gerência de Configuração (GCO) entre os Modelos MPS.BR e Scrum, podendo ser adotados os mesmos conceitos da GCO tradicional. Provavelmente uma empresa ágil já terá familiaridade com ferramentas de controle de fontes, porém se atendo a operações regulares de tratamento de fontes como check-in, check-out, etc, sem maiores extensões em gerência de configuração.

GCO 1. Um Sistema de Gerência de Configuração é estabelecido e mantido;

Idéias sobre evidências: Um plano geral de Configuração, ou plano de configuração por projeto, contendo especificidades, deverá ser elaborado, contendo os principais elementos de um sistema de Gerência de Configuração: 1)Um repositório de códigos fonte, um repositório de códigos executáveis e  uma ferramenta de Issue-tracker para controlar as eventuais mudanças. Além disso, outros elementos de software poderão integrar esse conjunto, como Maven, por exemplo, que ajudará na gerência do projeto, no sentido de facilitar o controle dos builds,da documentação e  das dependências entre objetos.

GCO 2. Os itens de configuração são identificados com base em critérios estabelecidos;

Idéias sobre evidências: Definição de itens de configuração, colocados sob os tipos de controles: registro, versionamento e linha de base. A filosofia na escolha dos IC´s deve ser a mesma que baliza os métodos estruturados, com priorização dos elementos essenciais associados ao cliente/produto.

GCO 3. Os itens de configuração sujeitos a um controle formal são colocados sob baseline;

Idéias sobre evidências: Definição das Baselines criadas, com os seus respetivos itens de configuração. As Baselines deverão ser definidas para serem passadas em pontos(marcos) do ciclo de vida Scrum, podendo ser ao final da fase de Pré-game, ao final de cada sprint e ao final do  pós-game. Eventualmente baselines tiradas em momentos de atualizações intensas e críticas poderão ser adotadas. As baselines deverão estar definidas no Release Plan, para se garantir a compatibilidade nos momentos de auditoria de GCO.

GCO 4. A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada;

Idéias sobre evidências: Processo aliado à ferramenta que permite a análise das baselines, seus itens de configuração, com as respectivas versões. Deverá permitir um -diff- entre as baselines . Isso , por vezes, é resolvido diretamente pela própria ferramenta de GCO adotada(software de controle de versão).

GCO 5. Modificações em itens de configuração são controladas;

Idéias sobre evidências: Sistema de controle de alterações, com a identificação das alterações, análise de impacto, análise sob a ótica de  IC e aprovação. Os registros de Commit do SVN, por exemplo, contendo associação com os itens de backlog(Id do requisito) que estão sendo resolvidos naquela alteração são evidências. O Mantis ou equivalente como elemento de controle de alterações, descrevendo-a serve como evidência indireta. O número da “issue” registrada para a alteração deverá estar no label do SVN, CVS, etc, para definir a rastreabilidade entre a alteração efetuada no código fonte e o seu registro como issue, no ambiente de “issue-tracker”.

GCO 6. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados;

Idéias sobre evidências: Controle de registro de Baseline no software de controle de versão, de acordo com as definições de linhas de base do projeto(release).Liberaçãodos IC´s sob baseline para atualização e passagem de nova baseline. Os elementos derivados dessas ações são fonte de evidências.

GCO 7. Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes;

Idéias sobre evidências: As auditorias de configuração feitas por uma auditor de configuração em cima das Base Lines passadas, com apontamento de NC que deverão ser corrigidas antes do fechamento da baseline. As auditorias deverão ter o cunho físico e funcional. A auditoria física cuida da estrutura dos diretórios, os IC corretos dentro daquela Baseline,os padrões corretos aplicados aos elementos envolvidos, etc. A auditoria funcional verifica cada IC, compara a versão correta, se o IC foi alterado, verifica o seu conteúdo abrindo o arquivo, analisando se o elemento passou pelos controles que deveria, etc.É uma espécie de garantia da garantia de qualidade.

Processo MED-Medições

Introdução: Existe alguma diferença no processo de Medições(MED), quando comparamos modelos estruturados e ágeis. Alguns tipos de indicadores são diferentes dos adotados nos processos convencionais. Por exemplo,  “story point”  é usado como indicador de tamanho de estórias(funcionalidades semelhante ao conceito de CSU, ou cenário de CSU). O gráfico de “burndown” , usado para acompanhamento diário da  sprint é também algo bem próprio do Scrum. Os métodos para a definição de tamanho também passam por aspectos diferenciados como “poker planning”, processo mais lúdico onde a equipe estima o tamanho/esforço daquela funcionalidade através de colocações de estimativas relativas.

MED1 - Objetivos de medição são estabelecidos e mantidos a partir dos objetivos de negócio da organização e das necessidades de informação de processos técnicos e gerenciais

Idéias sobre evidências: Um plano geral de Medição, ou plano de medições por projeto, contendo especificidades, deverá ser elaborado. As medições deverão estar associadas à estratégia da empresa e contendo métricas(uma para cada processo, podendo haver métricas globalizantes, como as que ajuntam aspectos de reutilização-GRU e de engenharia-PCP). Um plano estratégico ou uma diretriz estratégica da empresa deverá ser apresentado coerente com as medições definidas.

MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado;

Idéias sobre evidências: As métricas deverão ser definidas de acordo com o Scrum, podendo haver algumas medições diferentes das comumente encontradas em modelos estruturados. A diferença centra nas estimativas de tamanho, esforço e prazo, que poderão ser de outra natureza como: ideal-day, story-point, e burndown(percentagem de alcance da sprint). As medidas de processos de apoio como GQA,GCO,MED e de outros níveis como PCP,ITP,DRE,VER,VAL provavelmente serão semelhantes aos dos modelos tradicionais. As medições poderão ser feitas nas sprints, ou por projeto(release). Para cada métrica definida deverão ser mostrados: os procedimentos de coleta e armazenamento e os procedimentos de análise e de divulgação.

MED3 - Os procedimentos para a coleta e o armazenamento de medidas são especificados;

Idéias sobre evidências: Procedimentos de coleta e armazenamento, dependentes das métricas definidas, executados nos pontos definidos no Plano de Medição do projeto.

MED4 - Os procedimentos para a análise das medidas são especificados;

Idéias sobre evidências: Procedimentos de análise  dependentes das métricas definidas.

MED5 - Os dados requeridos são coletados e analisados;

Idéias sobre evidências: Realização e registro das coletas, seguido das análises. 

MED6 - Os dados e os resultados das análises são armazenados;

Idéias sobre evidências: Dados e resultados armazenados, com o objetivo de se criar base histórica de referência para projetos futuros.

MED7 - Os dados e os resultados das análises são comunicados aos interessados e são utilizados para apoiar decisões;

Idéias sobre evidências: Os dados e os resultados de análise poderão ser comunicados através dos elementos(mecanismos) de controle e acompanhamento do Scrum, como daily scrum(burndown), quadro do agile radiator,sprint review, retrospective meeting  e final de projetos(post-game).

Processo GPP-Gerência de Portfólio

Introdução: Em Gerência de Portfólio não deve haver diferença significativa entre o GPP sugerido para empresas usando Scrum e os métodos mais estruturados. O conceito de Portfólio, quando aplicado em empresas Scrum, se identificará com os diversos  desenvolvimentos de releases de produtos ou projetos em andamento naquele espaço de tempo paralelo. O PO(Product owner) ou os PO´s de cada Produto, nesse contexto, farão as vezes do Gerente de Portfólio, definindo as prioridades e alocação de recursos . Para os projetos de sistemas(empresas de projetos), a sistemática deverá ser a mesma adotada nas abordagens estruturadas, com envolvimento de PMO e GP´s. Uma figura do P.O dos P.O´s poderá surgir aqui com a implantação da Gerência de Portfólio.

GPP1 - As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados

Idéias sobre evidências: Definição dos road-maps de produtos, através dos PO´s envolvidos, coletando as oportunidades via  os demais canais, como Departamento comercial; call center, clientes, departamento de P/D da empresa,etc.

GPP2 - Os recursos e orçamentos para cada projeto são identificados e alocados;

Idéias sobre evidências: Definição macro feita pelos PO´s dentro de cada projeto envolvido na Gerência de Portfólio. Algumas dessas informações são discutidas na fase dePreGame. 

GPP3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas;

Idéias sobre evidências: Definição macro feita pelos PO´s dentro de cada projeto envolvido na Gerência de Portfólio.Algumas dessas informações são discutidas na fase de PreGame.

GPP4 - Os conflitos sobre recursos entre projetos são tratados e resolvidos;

Idéias sobre evidências: Definição feita pelos PO´s envolvidos nos diferentes projetos do portfólio.

GPP5 - Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados;

Idéias sobre evidências: Definição macro feita pelos PO´s dentro de cada projeto envolvido na Gerência de Portfólio.

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.

Mapeamento entre MPS.BR e Scrum-Parte-IV-RAPS-Resultados de Atributos dos processos

RAPS_Resultados de atributos de processos- mapeamento para SCRUM

Considerações: Os resultados esperados de atributos de processos são elementos esperados para todos os processos do nível em implementação. São considerações genéricas, válidas para todos os processos, com algumas variações, dependendo do nível.

Considerações:

RAP 1 - O processo atinge seus resultados definidos
Idéias sobre evidências: Todos os resultados (REPS) anteriormente discutidos evidenciam essa RAP


RAP 2 - Existe uma política organizacional estabelecida e mantida para o processo
Idéias sobre evidências: Todos os processos deverão ter Políticas, que são grandes normas, diretrizes maiores, apontamentos gerais que balizam cada processo da empresa.. Por exemplo: Todo projeto em Scrum, deverá ter um P.O(Product Owner) e um Scrum Team para executá-lo. Isso seria um item de uma política de empresa ágil, para a Gerência de Projetos, por exemplo.


RAP 3 - A execução do processo é planejada
Idéias sobre evidências: O projeto Scrum, tendo um cronograma, contendo as atividades executadas pelas diversas disciplinas/processos. Todos os processos envolvidos deverão ser suas atividades planejadas. Por exemplo, cronograma com a fase de Development, contendo para cada sprint, as suas atividades .No cronograma aparecerão as atividades de sprint planning 1,a sprint review e  por default o cronograma do daily scrum que é diário, etc. Isso seria para GPR. Nessas atividades estão também ações de GRE(Requisitos), GQA,MED,etc. No cronograma da sprint, ao final de cada iteração, aconteceriam as atividades de GQA para auditoria. Se fosse o caso, as atividades de coleta de medições(MED) também deverão estar alocadas/planejadas.

RAP 4 - (Para o nível G) A execução do processo é monitorada e ajustes são realizados
Idéias sobre evidências: Para esse nível seriam as reuniões de Sprint review, Daily Scrum e Retrospective meeting
RAP4 - (A partir do nível F) Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados
Idéias sobre evidências: As métricas adotadas para acompanhamento de cada processo. Medidas de GRE, GPR, GCO,GQA, MED e GPP, etc etc atenderiam a esse resultado.


RAP 5 - (Até o nível F) As informações e os recursos necessários para a execução do processo são identificados e disponibilizados
Idéias sobre evidências: Cada processo(GRE,GPR,MED,GCO,GQA e GPP), tem um conjunto de pastas onde ficam armazenadas suas informações. Por exemplo, onde ficam armazenadas o Product Backlog, Selected Backlog e Sprint Backlog. Tem também os recursos padrões global da empresa (hardware e software) para a sua execução.Alguns releases(projetos) tem infraestrutura específica que também seriam evidências.


RAP 6 - (Até o nível F) As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas
Idéias sobre evidências: Embora a  responsabilidade e a autoridade, no caso do Scrum sejam  diluídas pelo conceito da auto-gestão da equipe, a idéia é que essas responsabilidades sejam documentadas no Reelease Plan ou Sprint Plan.


RAP 7 - (Até o nível F) As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência
Idéias sobre evidências: Comprovar a formação, treinamento de cada envolvido: diplomas, certificados nos respectivos processos.Um quadro geral com as habilidades da equipe, mapa de competências, devidamente comprovadas também formam evidências .


RAP 8 - A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento
Idéias sobre evidências: O Scrum, embora  se baseie em certo informalismo de comunicação, deverá procurar por mais formalidade nesse ponto, mostrando um Plano de Comunicação, por exemplo. O Agile Radiator é uma evidência desse resultado, além dos registros expeditos do daily scrum, por exemplo.


RAP 9 - (Até o nível F) Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização
Idéias sobre evidências: O Retrospective Meeting e o Sprint Review podem compor as evidências desse resultado .

RAP 10 - (Para o nível G) O processo planejado para o projeto é executado
Idéias sobre evidências: Evidenciar os resultados obtidos com as ações planejadas na RAP 3
RAP 10 - (A partir do nível F) A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades
Idéias sobre evidências: Aqui entra o QA de processos. Se a empresa está em F, possui GQA e aquí entra o GQA aplicado aos processos daquele nível, inclusive o QA do QA, ou seja alguém que audita o trabalho do próprio QA.


RAP 11 - Os requisitos dos produtos de trabalho do processo são identificados
Idéias sobre evidências: A Rap 11 , juntamente com a 12 e 13 formam o arcabouço da GCO-Gerência de configuração, no sentido amplo. Nessa(Rap 11), você identifica os atributos que os produtos de trabalho deverão ter. Por exemplo, como deverá ser o Agile Radiator? Como deverá ser o Release Plan? 


RAP 12 - Requisitos para documentação e controle dos produtos de trabalho são estabelecidos
Idéias sobre evidências: Com a  Rap 12, vamos identificar os requisitos para documentação e controle dos PT(Produtos de Trabalho). Por exemplo, onde ficarão os Release Plans, os Sprint Plans, as atas do Sprint Review, do Retrospective Meeting? 


RAP 13 - Os produtos de trabalho são colocados em níveis apropriados de controle
Idéias sobre evidências: Com a Rap 13, decidimos a forma como aquele aqueles PT´s serão controlados(versionados?, sob baseline?, etc).


RAP 14 - Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades
Idéias sobre evidências: Aqui entra o QA de produtos. Se a empresa está em F, possui GQA e aquí entra o GQA aplicado aos produtos daquele nível, inclusive o QA do QA, ou seja alguém que audita o trabalho do próprio QA(aqui audita os Produtos, na Rap 10, audita os Processos).