Fragmentos do BI2-Modelagem e Qualidade

A era do zettabytes, como chamamos o futuro em que seremos informações codificadas e transformados de “human being”  em “human bits” , pode ser imaginada pelo volume de informação produzido nesses últimos anos. Os pesquisadores Martin Hilbert da Universidade da Califórnia e Priscila López, da  Universidade da Catalunha, fizeram um estudo que estima o acervo de informações existente de 1986 até 2007.Caso fosse armazenado de forma otimizada, o volume de informação existente naquele ano, presente nas diversas formas de suporte, quer sejam analógicos ou digitais, chegaria a um volume de 295 trilhões de megabytes ou 295 exabytes. Exabytes é a unidade que representa 1024 petabytes, que, por sua vez,  vem a ser 1024 terabytes. Se esses dados fossem armazenados em CD com capacidade de 730 megabytes,  com 1,2 milímetros de espessura, teríamos 404 bilhões de CD, que empilhados chegariam além da região orbital da lua. Até o ano 2000, os meios analógicos guardavam cerca de 75% de toda a informação da Humanidade. Em 2007,, segundo o estudo, mais de 94% dessas informações estaria  em meios digitais, invertendo fortemente as posições, com relação ao início desse século. Claro que o crescimento da internet banda larga e da telefonia móvel tem contribuído significativamente para essa produção maciça de informações. Esse aumento teve como contrapartida a suportá-lo, o crescimento da capacidade dos processadores. Segundo a mesma pesquisa, o somatório de todos os processadores em computadores pessoais alcançava, no final da pesquisa,  a capacidade de 6,4 trilhões de MIPS (milhões de instruções por segundo) e mostravam a tendência de dobrar a cada 18 meses, alavancado pela capacidade de processamento embutida, cada vez maior, nos  diferentes “devices” hoje consumidos, como os celulares e os consoles de videogames. Os números mostrados na pesquisa, embora gigantescos, ganham um tom de certo mistério quando comparados com os de outra natureza. Por exemplo, citam os autores que a quantidade de cálculos que todos os computadores do mundo podem fazer está no mesmo nível do número de impulsos nervosos executados pelo cérebro humano por segundo e a informação acumulada no período estudado é ainda menor do que a codificada no DNA de um ser humano, que gravita na ordem de 10 zettabytes. Isso nos dá uma sensação esquisita de que a tecnologia insinuante e espetacular que produzimos, tem servido também ao propósito de nos mostrar o quanto somos menores do que imaginamos.
Se você não percebeu  ainda, você sendo observado e transformado em bits:  De agora em diante, cada vez mais o nosso cotidiano  estará sendo codificado em bits. Câmeras de vigilâncias em aeroportos, metrôs, ruas e boates, estão registrando os nossos bits.Tudo com a velha máxima de saborear as vantagens e  lamentar as desvantagens. Na Califórnia, no início de 2011 foi inaugurado um estacionamento que monitora, via câmera, cada carro em cada vaga. Através disso, as placas são transformadas em informações que vão para um sistema de banco de dados, que facilita a localização do seu carro, além de permitir um “analytics” sobre o movimento do estacionamento. Ao lado do quiosque de pagamento, existe um monitor onde você digita a placa e recebe a localização perfeita da vaga onde você estacionou, evitando a memorização de cores, números, letras, etc. Assim, as táticas furtivas de deixar carros em estacionamento de shopping, com fins inconfessáveis, podem estar com seus dias contados.  O berçário onde meu neto fica, em Santo André, tem câmeras, que me permitem vê-lo nos intervalos das minhas consultorias, acessando o site da escolinha. Pontos para a tecnologia dos “baby bits”.Quando você agora sai de casa, poderá ser flagrado pelas câmeras do Google ou Microsoft, que capturam as imagens das ruas, visando à atualização de seus serviços de mapeamento na internet. No Brasil houve um caso de um cidadão que agora processa  a Google por um flagrante constrangedor que foi parar no Google View,  segundo ele, mostrando a sua indisposição estomacal para  milhões de internautas. Se você dirige e passa por um pedágio, provavelmente será transformado em bits, com a estampa de tempo e a identificação de sua placa indo dormir em algum datamart que poderá ser acessado posteriormente. Há uma previsão  que nos próximos dois anos, o fluxo de informações gerado por capturas de câmeras e outros sensores digitais deverá ultrapassar o número de e-mails e de tweets, ou equivalentes, colocados nas redes sociais. Os sensores tocarão em muitos aspectos das nossas vidas, prevê Stephen Brobst, CTO de Analytics da Teradata, empresa especializada em grandes DWs com grandes volumes de dados, em entrevista ao USA Today de 26 de janeiro de 2011. Para isso, a tecnologia desenvolve aplicativos e “gadgets” capazes de assumirem o papel de interpretadores dessas novas fontes. A empresa Affectiva,  de Waltham, Massachussets, por exemplo, desenvolveu uma pulseira biométrica capaz de detectar imperceptíveis mudanças nas atividades das glândulas sudoríparas, a fim de se capturar  reações emocionais. A pulseira tem sido usada em crianças autistas a fim de melhor entender as suas reações, normalmente não manifestadas pelo “display” emocional desse tipo de pacientes. A área de marketing já planeja o uso do mesmo “device” para capturar aprovações ou frustrações de clientes submetidos a novas propostas ou produtos. Sensores que registram e trabalham a expressão facial de clientes poderão, num futuro bem próximo, rastrear os produtos que mais lhe interessam, quando você olhar para uma vitrine, por exemplo. Algumas bancas americanas de advocacia, especializadas em divórcio, já usam os registros de idas e vindas de  veículos de cônjuges, coletados em pedágios, como elementos de processos.

Na mesma proporção em que essas novidades são produzidas, considerações sobre privacidade voltam à tona. As áreas envolvidas com a preservação de privacidade já se preocupam com o dia em que as diversas informações coletadas por mecanismos variados, quando confrontadas por métodos analíticos do BI2, poderão levar a uma negativa de emprego, a aspectos de cancelamento de seguros ou à redução de níveis de créditos. Desvantagens do “human bits”. Tudo isso, sem que você saiba de onde vieram as informações, talvez por não ter reparado nessa sua condição de “ser decodificado”. A organização Electronic Frontier Foundation, forte e atenta observadora dos aspectos de privacidade e de direitos fundamentais, independentemente de tecnologia, entende que apesar de todos os esforços, dificilmente, em caso onde envolvimentos e interesses diretos  acontecerem, o governo deixará de mergulhar nesse novo manancial de informações produzido pela sociedade na era do zettabytes. O reconhecimento facial, via fotos, por exemplo, já existe e está bem desenvolvido. A Google (via Picasa) e Facebook (via Photo Albums) incentivam os seus usuários a etiquetar (identificar pessoas, datas e situações) as fotos armazenadas. Com a tecnologia de que dispõem hoje, são plenamente capazes de desenvolver indexações faciais e procurarem por você em outras fotos, através de similaridades de feições, criando uma espécie de impressão “facial”. Uma vez criada essa assinatura, a sua imagem poderá ser procurada nas diversas fontes de armazenamento, inclusive aquelas geradas pelas imagens de câmeras espalhadas pela nuvem. Assim fecha-se o ciclo. Os seus bits faciais, além de serem registrados nas boates, metrôs, estacionamentos, etc, ainda podem ser comparados por técnicas sofisticadas de indexações de feições e permitir a sua identificação. Ou seja, alguém que você não conhece poderá lhe identificar, bastando para isso tirar uma fotografia sua, quebrando alguns preceitos fundamentais do direito ao anonimato. A própria Google introduz com certo cuidado um novo serviço, chamado Goggles, que faz busca na web através de uma fotografia, via smartfone. Ou seja, no lugar de digitar algumas palavras na caixa de pesquisa, você faz um upload de uma foto e obtém as informações relacionadas à ela. Bastaria uma foto sua tirada por alguém interessado em saber quem você é e pronto. Você já não será mais anônimo. Alguns desses smartfones, dotados de GPS, podem facilmente criar as chamadas “geotags”, ou seja, etiquetar as fotos com a sua coordenada geográfica. Isso significa que uma fotografia dessas, mostrando, por exemplo, o novo carro comprado, tirada em frente a sua casa e postada no Twitter, está dizendo onde você mora. Assim, além de saberem sobre você, também poderão saber sobre a sua residência, família, etc. Simples assim. Se você acha que essas linhas estão com um forte sabor de Minority Report, de Tom Cruise, e que demoraremos para alcançar esse patamar que mistura tecnologia com inquietude, tente lembrar dos produtos que eram moda no Natal de 2000. Se você se lembrar deles, o que é difícil, certamente você vai perceber que a instantaneidade da tecnologia já os deixou na poeira da saudade.  

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.