Total de visualizações de página

sexta-feira, 26 de novembro de 2010

Lágrimas classificadas

Quando minha mãe morreu em 1975, eu chorei lágrimas de saudade. Fluentes e um pouco constrangidas nos meus 26 anos, elas chegaram na noite de 22/05, quando trilhei sozinho o caminho de São José dos Campos à Cruzeiro. Na alta madrugada, inverno rigoroso, elas lubrificaram as lembranças das suas músicas preferidas que eu sempre dedilhara toscamente ao violão, ainda que ela me considerasse o cantor dos seus hits preferidos. Mãe, é mãe, todos sabemos....
Quando meu pai morreu em 09/96, chorei lágrimas de amizade. Em menor quantidade, mas suficientes para embaçar os olhos. Foram brotando, gota a gota nos caminhos das Vertentes, Mantiqueira até chegar em Cruzeiro novamente. Nessa trilha, tive o afago discreto dos filhos, que montaram sentinela evitando que a tristeza se aproximasse, mas as lágrimas, vocês sabem, essas não pedem permissão para chegar;
Quando você, minha amiga, se foi hoje, dia 25/11/10, eu chorei lágrimas de sinceridade. Elas começaram na Montes Claros, a caminho da Clivet e da decisão mais difícil da minha vida. Elas vieram em profusão, maior do que o razoável, principalmente para um sexagenário que deveria, por dever da idade, ser contido pelas laqueaduras de sentimentos por que passamos nesses mais de 22.000 dias vividos. Além disso, por estar chorando por um "ser" menor , numa hipotética escala de valores de sentimentos, como se essas coisas pudessem ser quantificadas com a métrica dos racionais. Foi aí que eu percebi que as lágrimas são diferentes nas suas proposições. Podem apostar. Quem inventou esse "engine" emocional, fundamental para a irrigação da alma, sabia das coisas.  As lágrimas de saudade tem a cor dos riachos transparentes que se projetam na volta dos nossos tempos.Embaçam os "replays" que insistimos em reproduzir, confundem a trilha  do fundo musical, correm em torrentes volumosas e terminam na curva do rio, drenadas pelas fendas das nossas emoções.
Já as lágrimas da amizade são também verdadeiras, porém mais contidas.Nos remetem aos sorrisos marotos, brincadeiras sem graça, aos grandes amigos, às  imitações da vida e podem até passar certas tonalidades cênicas,  mas nunca cínicas.
As lágrimas da sinceridade são diferentes, pois se postam como espelhos a mostrar como aquele que se foi, nos amava pelo que somos. É como se nos enviassem "streams" de lá para cá, desenhando rabiscos para mostrar que gostou da gente de forma incondicional. Você, companheira felina, testemunhou todos os meus mal-escritos, e tantos foram. Aqui  nesse mesmo teclado, hoje até meio úmido, onde eu batucava as minhas  linhas e você, sentinela do meu silêncio, assentia com a sua discrição companheira. Você,que lambia os meus cabelos brancos ou tocava o seus olhos azuis na minha face, quando definia que era hora de parar. Era assim que você me dizia as coisas, na eloquência de seus pequenos gestos silenciosos, aliás, como fazem os felinos, diferentemente dos ferinos.
Pois hoje, no meu colo, você miou diferente, no caminho da Montes Claros. Em 10 anos, nunca ouvira algo tão triste e as lágrimas da sinceridade me avisaram que tinha chegado a hora de partir.E você partiu, silenciosa e sem dor e até o mouse sem fio, seu companheiro de lutas aqui na minha mesa, perdeu a sua energia  e parou. Trocou a luta pelo luto.  E agorinha, quando me preparava  para tentar escrever algo sobre você, observei que no seu lugar de sempre, ao lado do teclado, restava um tufo de seus pelos. Ato contínuo, resolvi colocá-lo no quadro de avisos,onde "penduro" os fragmentos da minha vida, defronte à minha mesa. Por uma interessante  coincidência, o magneto que usei para afixar o seu pelo ao quadro, tinha a forma de uma estrela, e a feliz combinação dos dois elementos formou um cometa. Ali ele ficará para sempre. A estrela, que era você, seus pelos desfiados e os meus apelos descabidos  para que voltes.....

segunda-feira, 4 de outubro de 2010

Mapeamento entre MPS.BR e Scrum-Introdução

Atualizado em 07/10/2010:

Podcast com ImproveIT:
Há algum tempo tenho escrito por aqui algumas coisas sobre os métodos estruturados e modelos ágeis. Isso tudo começou quando fui entrevistado pelo Vinicius Manhães Teles, da ImproveIT, que proporcionou uma conversa que, embora técnica, se configurou extremamente agradável(para mim, claro), pois me deparei com alguém que, embora agilista cromossômico, não apresentou, por "default" preconceitos viscerais  com relação aos métodos estruturados. Tinha ele o objetivo claro e profissional de rastrear afinidades e enfatizar as diferenças entre as duas abordagens. Ele que tão bem conhece os métodos ágeis, buscando entender o emergente MPS.BR. Esse foi o "viés" da nossa conversa . Embora só nos  conheçamos via Skype, fiquei com excelente impressão dele. Essa discussão entre o novo e o já existente(eufemismo para velho) é muito proveitosa. Isso acontece muito com os sambistas talentosos de hoje, que vira e mexe, vão jogar conversa fora com os antigos compositores da velha guarda da Portela. Essa visões mais novas e as experiências mais tradicionais não precisam ser conflituosas. Conforme falei em vários posts anteriores, metodologia e tecnologia não comportam paixões e antagonismos. Deixa isso para futebol e política.
O Podcast que fizemos é longo pois passamos uma tarde de sábado de 14:00 às 18:00 conversando, como dois amigos que nunca se viram e que se encontraram neste botequim virtual da internet para falar de assuntos de que gostam.
Você pode acessar essa entrevista(podcast), no endereço
http://improveit.com.br/podcast/improvecast-8-entrevista-carlos-barbieri-mpsbr

Maré de Agilidade:
Depois desse evento, por ocasião do evento Maré de Agilidade, escrevi diversos artigos, aqui postados respectivamente em Abril, Maio e Agosto quando coloquei uma série de idéias sobre a possibilidade de convivência pacífica entre os métodos estruturados e os métodos ágeis . O (evento) Maré da Agilidade, onde fizemos uma apresentação(eu e Isabela Fonseca, da Powerlogic) também se mostrou uma excelente oportunidade para discussões sobre as duas abordagens.O movimento ágil cresce no Brasil. assim como o MPS.BR. Quem sabe não se cruzam, ali depois da curva da estrada, onde tem um pé de araçá, como diz Renato Teixeira. Para o evento, preparei alguns escritos que desejo retirar da poeira e faço para eles, os links abaixo:
Parte 1-Visão Ágil e Visão estruturada-Introdução
Parte 2-Visão Ágil e Visão estruturada-CMMI
Parte 3-Visão Ágil e Visão estruturada-Métodos Ágeis
Parte 4-Visão Ágil e Visão estruturada-Entendendo o conceito de modelo
Parte 5-Visão Ágil e Visão estruturada-Analisando o manifesto ágil
Parte 6-Visão Ágil e Visão estruturada-Desafios
Parte 7-Visão Ágil e Visão estruturada-Conclusão
Parte 8-Visão Ágil e Visão estruturada-Adendos e extensões

Artigo na Revista BHTI:
Artigo publicado, após a Maré de Agilidade, na revista mineira de Informática, BHTI. Na realidade é um condensado do que falamos na palestra da Maré de Agilidade.

Mapeamento MPSxSCRUM: 
Hoje, estou iniciando a publicação do que chamo um Mapeamento entre o MPS.BR e o SCRUM. De início, devo dizer que estou longe de ser um especialista em movimentos ágeis. Com 61 anos, vocês entendem que nada mais é ágil na criatura humana..... O que coloco aqui hoje, é uma tentativa de mapear os resultados do MPS.BR(aquilo que se busca implementar nas empresas) com algumas idéias sobre Scrum que aprendi na Powerlogic(*) , quando eu e Flávio Harasaki ajudamos a implementar o nível C do MPS.BR, naquela empresa, que se tornou a primeira MPS nível C do Brasil,  com adoção de Scrum. Paulo Alvim, Isabela Fonseca, Rogério Baldini, Fernanda Alves e Márcia Alves entravam com o espesso conhecimento sobre SCRUM e eu e Hara  encaixávamos o MPS.BR, nessa mistura que acredito, seja viável.
As percepções que trago não são necessariamente válidas para todos os matizes de metodologias ágeis e estão longe de representarem as únicas ou as melhores  . Estão centradas naquela implementação e na discussão com outros consultores que , de uma forma ou de outra, já vivenciaram implementações e avaliações ágeis.
Algumas premissas devem ser observadas nesse mapeamento, antes de se partir para a sua leitura:
1)Não há a menor possibilidade de se implementar modelos como MPS.BR/CMMI em empresas que não aceitarem certo grau de flexibilização nas suas receitas  de desenvolvimento de sistemas. Aquelas que mantiverem posições ortodoxas e leituras inflexíveis  sobre o manifesto e os princípios da agilidade não lograrão êxito numa implementação MPS.BR ou CMMI;
2)Todas as propostas aqui colocadas estão centradas no fato de que uma empresa ágil  a ser avaliada no modelo MPS.BR e/ou CMMI  deverá produzir evidências. Somente as evidências permitem instrumentalizar a equipe de avaliação, de forma a garantir a aderência aos respectivos modelos e concluírem(ou não) pela certificação . Por esse motivo, o detalhamento de cada REP-Resultado esperado do processo, foca no mapeamento do processo Scrum e em possíveis idéias sobre interpretação de suas evidências;
3)As propostas aqui colocadas estão centradas em uma das muitas formas de se implementar Scrum. Logo, alguns agilistas poderão estranhar certas colocações e o motivo deve ser  a especificidade adotada nesse caso;
Nesses posts vou me ater aos níveis de G a E do MPS.BR, onde essa convergência apresenta pontos mais interessantes. Como sempre, vou dividir essas idéias em 3 posts, a fim de facilitar a fuga dos que se arvorarem a ler essas linhas e desejarem saltar fora. Para maiores detalhes sobre o MPS.BR, acesse
http://www.softex.br/mpsbr/_guias/default.asp  Lá você encontrará todo o detalhamento sobre o modelo.

A parte I- Traz um gráfico sobre Scrum, que serve para posicionar conceitos.Os conceitos discutidos estão fortemente atrelados  a essa figura;

A parte II-trata do mapeamento dos processo de  nível G, contemplando Gerência de Requisitos e Gerência de Projetos. Nesse nível, por se tratar de processos fundamentais,  aparecem mapeamentos interessantes e com muitas equivalências.

A parte III-trata do mapeamento dos processos de nível F, contemplando Gerência de Configurações,Medições,Garantia da Qualidade e Gerência de Portfólio. Nessa parte, por se tratar de processos de apoio, as coisas ficam mais dependentes de como o Scrum foi implementado na empresa;

A parte IV- trata das RAPS-Resultados de atributos de processos, comuns a todos;

A parte V - trata de Adendos e extensões sobre esse assunto;

A parte VI - trata dos processos do Nível E.


(*)Powerlogic, uma das grandes empresas do Brasil praticantes de Scrum, famosa antes mesmo do “ agilismo” se tornar moda. Lá aprendi muito com Paulo Alvim,Isabela Fonseca, Márcia Alves, Fernanda Alves e Rogério Baldini a respeito de Scrum, enquanto(eu e Harasaki) “encaixávamos” o modelo MPS.BR naquele mundo novo de P.O,Scrum master,Scrum Team, daily scrum, gráficos de burndown, ideal-day, etc. Assim vai aqui o meu agradecimento a essa brilhante equipe da Powerlogic e ao amigo Flávio Harasaki, pela oportunidade do trabalho e as discussões valiosas sobre SCRUM.  


Importante: Serão extremamente bem recebidas as opiniões, pontos discordantes, sugestões, melhorias, etc, sempre em nome do viés de profissionalismo e do crescimento  dos movimentos de qualidade de software no Brasil.

Mapeamento entre MPS.BR e Scrum-Parte-VI-Nível E

Mapeamento MPSxSCRUM-Nível E-Parte VI-atualizado em 04/10/2010-16:00h

Considerações  sobre os processos do nível E:
O nível E do MPS.BR  é um nível bastante conceitual e distancia um pouco dos aspectos diretos de desenvolvimento, principalmente daqueles que  tem o “ agilismo” correndo nas veias. Explico melhor: O nível E é o nível onde se define um ou mais processos que a empresa deverá empregar na sua culinária de sistemas. Até então, a empresa podia ter, por projetos, receitas específicas, desde que cada uma  delas contemplasse os processos fundamentais(GRE,GPR), os processos de apoio(GCO,GQA,MED e GPP), além das RAP´s exigidas para aqueles níveis. Agora não. As coisas ganham um pouco mais de formalismo e exige-se que a empresa ofereça  um ou mais processos padrão(variando com estilos de negócios praticados) e que esses ou esse(caso seja somente um processo padrão), tenha regras claras e objetivas de aplicação e adaptação, dependentes do tipo de sistema que se deseja desenvolver. Por exemplo, se a empresa for uma Fábrica de Software, poderá ter um processo que abrirá mão da fase inicial de DRE/GRE para se concentrar na construção e entrega. Se a empresa, ao contrário, for uma fábrica de Requisitos, o seu processo se concentrará nas fases iniciais do ciclo de vida. A esse processo adaptado, chamamos de processo definido e ao(s) processo(s)-mãe,chamamos de processo padrão. Essa espiral conceitual é algo que deverá ser bem trabalhada no mundo  ágil, onde os praticantes não são muito afeito a essas elaborações semânticas e normalmente são ávidos por “ mão-na massa”, “olho no olho”, etc.
O nível E contempla dois processos seminais(AMP e DFP), que são a receita para se escrever os processos de que precisamos para a empresa. Os dois são muito conceituais e abstratos, pois resvalam nas fronteiras do meta-processo(processo para se escrever processo), mas poderão ser evidenciados pela mimetização dos conceitos ágeis, conforme veremos adiante.
Além desses, temos o GRH(Gerência de Recursos Humanos).Esse é relativamente invariante com relação ao mundo ágil, se considerarmos aquela premissa de que a empresa ágil deseja alcançá-lo. O GRH toca em pontos óbvios e necessários que qualquer empresa, seja agilista ou estruturada, deverá ter para moldar aquele que é o principal recurso de qualquer processo, independente da sua gênese: as pessoas. No GRH são elaboradas ações de recrutamento e seleção, treinamento e uma área nova, que toca na gerência de conhecimentos. As duas anteriores (recrutamento e seleção) são típicas de qualquer empresa e normalmente conduzidas por uma área paralela(RH). A parte de conhecimentos tem algumas interseções com o mundo ágil, na medida em que o conhecimento produzido pela equipe(PO,Scrum Master e Scrum Team,etc) deverá ser registrado, catalogado, pesquisado e disseminado. Uma rede de especialistas deverá ser definida e controlada. O mundo ágil, tem como premissa, repito,  um certo grau de informalidade e refração à definição de protocolos e aqui deveremos ter ações preventivas para mitigar esses pontos. Deveremos trabalhar visando o aculturamento desses conceitos de “gerência” de  conhecimento, via processos e ferramentas um pouco mais formais do que um “daily scrum”  "despojado".
O outro processo do nível E trata de um assunto muito próximo dos agilistas: A reutilização. A Gerência de reutilização, trazida como novidade no bojo do MPS.BR, é algo novo, ainda imaturo, mesmo como processo MPS  e será escrito em conjunto pelos agilistas e pelos implementadores MPS.BR nas empresas.O conceito de reutilização, nesse nível, começa com o conceito de ativos reutilizáveis, que significa,”qualquer coisa” que se deseje reutilizar, desde que traga retornos claros para a empresa. Pode ser “template”, códigos, procedimentos,etc. De novo, a reutilização, exige certas formalidades, que vão da definição do ativo e  de uma base de armazenamento; de sua pertinência ou validade de ser compartilhado através de aplicação de critérios; de sua integridade(se está funcionando OK); se está pronto(intelegível e documentado) para ser reutilizado, além dos controles de seu ciclo de vida e  de quem e quando  faz(fez) a reutilização, ou do porquê e quando desiste de fazê-lo.  E isso, como se depreende, não pode ser definido “ no bigode”, para se usar um termo do interior, quando se estabelece direitos e deveres de partes interessadas e envolvidas num compromisso.   Há que se ter aqui algum formalismo definido.
Dessa forma, nestas linhas faremos um mapeamento  direto do processo DFP, AMP e Extensão do GPR,  com possíveis idéias sobre evidências em SCRUM.   
DFP-Definição do Processo Organizacional
O processo de DFP, como explícito no nome, busca orientar no sentido do que é um Processo, seus componentes  e como podemos defini-los.
DFP1 - Um conjunto definido de processos padrão é estabelecido e mantido, juntamente com a indicação da aplicabilidade de cada processo.

Idéias sobre evidências: Processo(s) padrão, definido(s) na forma ágil, com todos os ingredientes  dos modelos ágeis utilizados: SCRUM,XP, etc, inclusive considerando os aspectos de Scrum distribuído.Uma empresa que pretende estabelecer projetos envolvendo diversas equipes Scrum, distribuídas por componente ou por funcionalidade, deverá definir processos para esse tipo de projeto, ou pensar em adaptações de processos que contemplem esses cenários;

DFP2 - Uma biblioteca de ativos de processo organizacional é estabelecida e mantida .

Idéias sobre evidências: Bibliotecas de ativos do(s)  processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes  dos modelos ágeis utilizados(SCRUM,XP, etc);

DFP3 - Tarefas, atividades, papéis e produtos de trabalho associados aos processos padrão são identificados e detalhados, juntamente com o desempenho esperado do processo .

Idéias sobre evidências: Detalhamento do(s)  processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes  modelos ágeis utilizados(SCRUM,XP, etc);

DFP4 - As descrições dos modelos de ciclo de vida a serem utilizados nos projetos da organização são estabelecidas e mantidas

Idéias sobre evidências: Detalhamento dos diferentes ciclos de vida  do(s)  processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes dos  modelos ágeis utilizados( SCRUM,XP, etc);

DFP5 - Uma estratégia para adaptação do processo padrão é desenvolvida considerando as necessidades dos projetos

Idéias sobre evidências: Documento de adaptação para o(s)  processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes  modelos ágeis utilizados(SCRUM,XP, etc), visando a criação de processo(s) definido(s);

DFP6 - O repositório de medidas da organização é estabelecido e mantido
Idéias sobre evidências: Definição de um repositório de medidas, como evolução do processo MED(nível F) aplicado dentro do(s)  processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes  dos modelos ágeis utilizados( SCRUM,XP,etc);

DFP7 - Os ambientes padrão de trabalho da organização são estabelecidos e mantidos

Idéias sobre evidências: Definição de ambiente de trabalho padrão da organização, elencando softwares, hardwares, por papel desempenhado dentro do(s)  processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes  dos modelos ágeis utilizados (SCRUM,XP,etc).

Para os processos restantes do nível E,(GRH,GRU)  há uma forte invariância, pelo o que permanecem somente os conceitos elaborados anteriormente. Não detalharemos, por ora, os resultados esperados desses processos.
GPR-Estendido:
O processo GPR estendido, ajusta o processo GPR(nível G) aos aspectos do processo padrão e do processo definido:
GPR4 - (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: O planejamento e estimativa das estórias, atividades originadas delas, ajustes de velocidades de sprints, pontos de estórias, burndown, etc, deverão ser baseado em  um repositório de medidas, como evolução do processo MED(nível F) aplicado dentro do(s)  processo(s) padrão), definido(s) na forma ágil, com todos os ingredientes  dos modelos ágeis utilizados (SCRUM,XP,etc);

GPR18 - (A partir do Nível E) Um processo definido para o projeto é estabelecido de acordo com a estratégia para adaptação do processo da organização .

Idéias sobre evidências: No planejamento do Release(Release Planning), deverá ser estabelecido  o processo definido a ser aplicado naquele momento. Um documento de adaptação deverá mostrar as eventuais alterações e suas justificativas.Aqui também deverão ser considerados os aspectos de Scrum distribuído, quando a empresa previr a possibilidade gerência integrada de várias equipes Scrum, o que deverá ser contemplado no Processo Padrão( ver DFP1).

GPR19 - (A partir do nível E) Produtos de trabalho, medidas e experiências documentadas contribuem para os ativos de processo organizacional

Idéias sobre evidências: No Retrospective Meeting, ao final da iteração, ou ao final do Release(Post-Game), deverão ser  documentadas as experiências, medidas, etc que contribuirão para a melhoria do processo organizacional.

AMP-Avaliação e Melhoria de Processos
Os processos AMP e DFP podem ser vistos, em conjunto, como o processo para se definir e evoluir o processo de desenvolvimento da empresa. Assim, o processo para se desenvolver processo poderá usar os mesmos conceitos ágeis aplicados ao desenvolvimento de software.Ou seja um processo  criador de processos deverá ter  um ou mais releases a serem definidos  com os suas sprints, e em cada sprint, poderão ser definidos a escrita de um ou mais processos. Por exemplo, um release do Processo de definição de processos (PDP) seria a revisão inicial dos processos do nível F e as suas sprints seriam as avaliações e melhorias desses processos. Poderíamos ter um outro release do PDP  com a escrita dos processos de Engenharia, por exemplo e nesse teríamos a escrita de processos de DRE,PCP,ITP,VER,VAL  divididas em sprints diferentes. Um outro release poderia contemplar o desenvolvimento dos processos de nível C, como GRI,GDE e DRU.Assim sucessivamente planejaríamos as escritas dos processos necessários àquele nível . Uma outra sprint poderia ser a implementação desses novos processos, caso a empresa deseje escrever tudo primeiro para implementar depois, numa espécie de cascata. Caso contrário, poderíamos ter em cada sprint de escrita, a sua implementação em estado de beta-teste, por exemplo.A escolha de quais processos serão escritos/implementado vai depender do “gap” entre o último nível certificado e o nível desejado. Muitas empresas, depois de fecharem um certo nível de maturidade, entram num certo “vale” de conforto, diminuindo o oxigênio da equipe de SEPG e provocando certas “flexibilizações” que se manifestarão quando desejarem subir de patamar.
AMP1 - A descrição das necessidades e os objetivos dos processos da organização são estabelecidos e mantidos
Idéias sobre evidências: Aqui entram as posições  estratégicas e negociais da empresa definindo as necessidades de processos na organização. Seriam os insumos para se definir o formato de se escrever o processo da empresa. Poderiam ser os requisitos de alto nível do Release backlog de Processos, formado por Épicos e Temas, por exemplo.
AMP2 - As informações e os dados relacionados ao uso dos processos padrão para projetos específicos existem e são mantidos
Idéias sobre evidências: O Release Plan de cada projeto indica o processo padrão a ser usado e a seção onde aparece a adaptação do processo ao projeto indica as atividades e produtos ajustados ou customizados.Isso forma o conceito de Processo definido. Caso o Scrum esteja sendo desenvolvido em empresas mais vocacionadas para produto, haverá uma tendência de baixa incidência de adaptação, devido à uniformidade do produto e a  consequente invariância do processo.
AMP3 - Avaliações dos processos padrão da organização são realizadas para identificar seus pontos fortes, pontos fracos e oportunidades de melhoria
Idéias sobre evidências: Esse resultado é relativamente invariante com relação à Scrum, pois denota as diversas avaliações pelas quais o processo padrão passou e isso é independente de ser Scrum,RUP, etc. Uma das formas de fazer isso é através de avaliações externas(DPA-Diagnóstico de pré-avaliação), ou  internas(avaliações sobre o andamento da aplicação do processo padrão, nas reuniões de sprint review ou de  retrospective meeting). As auditorias de QA, oriundas do nível F, também avaliam os processos e podem oferecer indicadores de pontos fortes, fracos e oportunidades de melhoria;
AMP4 - Registros das avaliações realizadas são mantidos acessíveis
Idéias sobre evidências: Esse resultado está relacionado ao anterior e valem as mesmas observações. Os diversos mecanismos aplicados na avaliação dos processos produzem diferentes formas de registros que deverão ser mantidos como evidências
AMP5 - Os objetivos de melhoria dos processos são identificados e priorizados
Idéias sobre evidências: Esse resultado pode ser entendido como um maior detalhamento dos requisitos e podem ser respondidos pela pergunta: Quais objetivos intenciono alcançar com o processo, cada melhoria sugerida, etc. O Release backlog, onde os grandes temas e épicos(macro requisitos), agora  detalhados sobre a  implementação do processo, estão registrados, deverão ser avaliados, através de mecanismos de priorização, com o BV(Valor de negócios) daquele processo sendo usado como elemento de priorização, por exemplo.
AMP6 – Um plano de implementação de melhorias nos processos é definido e executado, e os efeitos desta implementação são monitorados e confirmados com base nos objetivos de melhoria
Idéias sobre evidências: O plano de implementação é na essência o projeto de melhoria, aplicando o processo, como ilustrado na figura 03 abaixo. Poderíamos ter um projeto com um release e  algumas sprints, como na figura mostrada. As melhorias cadastradas ou sugeridas ao SEPG ou via outras fontes são os backlogs deste projeto.
AMP7 - Ativos de processo organizacional são implantados na organização
Idéias sobre evidências: Esse resultado está relacionado ao anterior.Para cada processo ou sub-processo implementado, passarão a valer os seus produtos de trabalhos, procedimentos, templates, fórmulas, etc
AMP8 – Os processos padrão da organização são utilizados em projetos a serem iniciados e, se pertinente, em projetos em andamento
Idéias sobre evidências: Os processos padrão definidos para a organização deverão seguir os princípios de agilidade, com os ciclos de vida fortemente iterativos  e incrementais. Como os projetos ágeis primam por ciclos curtos, a utilização de uma nova versão de processo e /ou de um  artefato poderá ser aplicada em iterações do mesmo release, ou, se pertinente, em releases diferentes.
AMP9 - A implementação dos processos padrão da organização e o uso dos ativos de processo organizacional nos projetos são monitorados
Idéias sobre evidências: A monitoração da implementação dos processos padrão são feitas por ações de QA, medidas definidas sobre o uso do processo padrão, etc
AMP10 - Experiências relacionadas aos processos são incorporadas aos ativos de processo organizacional
Idéias sobre evidências: No Retrospective Meeting, normalmente obtem-se as lições aprendidas associadas àquele processo. Isso é feito via as perguntas
WWW-What went well? WCBI-What could be Improved?, com os devidos apontamentos de ações e responsáveis
A figura 02- mostra uma visão geral de implementação de AMP-DFP, ou seja a escrita de processos dentro do nível E. O grupo SEPG define um meta-processo que deverá ser seguido para a construção dos processos. Poderá ser um ciclo parecido com PDCA,IDEAL ou qualquer abordagem iterativo-incremental, como SCRUM, sendo esse o que adotaremos nessas linhas que mapeiam métodos ágeis com MPS. Com esse processo definido o SEPG desenvolve um Plano de Projeto de implementação(Release Plan de Processo). Esse plano conterá os objetivos de se implementar os processos, os principais passos(sprints)  como revisão dos níveis anteriores, planejamento e priorização  dos processos a serem escritos. A partir daí, iniciamos as diversas iterações para a construção de cada um dos conjuntos definidos. Ao final, teremos os processo(s) padrão escritos, que deverão ser usados nos projetos de software. Observem que o processo padrão poderá ser adaptado ao ser aplicado no projeto de software. Da mesma forma, o meta-processo, usado na escrita dos processos padrão da empresa poderá  ser adaptado, conforme mostrado na figura 02.
A figura 03 ilustra o detalhamento dos ciclos de releases, de sprints e de daily scrum, que poderão ser usados na aplicação do método ágil para o desenvolvimento de processos MPS.BR.   


domingo, 26 de setembro de 2010

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. 

quinta-feira, 23 de setembro de 2010

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.