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

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.   

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.