Visão Ágil e Visão estruturada-Parte 6-Desafios

Desafios

Os projetos e as empresa que aderiram ao uso de ambos os paradigmas, percebem que existem valores reais nos dois lados.No nível de projetos, os modelos estruturados focam mais no "o quê" fazer enquanto os métodos ágeis focam no "como" os projetos desenvolvem seus produtos. Isso define que ambos tem uma boa faixa de convivência. Hoje muitas organizações certificadas em CMMI/MPS.BR usam equipes "ágeis" de desenvolvimento. Da mesma forma, uma empresa ágil, pode usar MPS.BR/CMMI para projetos iterativos, time-boxed, o que é perfeitamente compatível com os seus preceitos de hoje. Os métodos ágeis podem prover o "como" em projetos CMMI, especialmente em projetos de menor porte com equipe co-alocada. As abordagens CMMMI/MPS.BR, por seu lado oferecem as práticas de engenharia de software para projetos de maior porte.
O grande desafio dos modelos ágeis está na aplicação de grandes projetos, onde diversas e pequenas equipes devem ser mantidas alinhadas e coordenadas durante a sua execução, mantendo as premissas ágeis aplicáveis. A manutenção do alinhamento em projetos distribuídos requer um papel ou mecanismo para a preservação da coerência, lógica e unicidade de:
a)Arquitetura do sistema;
b)Escopo,qualidade, cronograma, custo e risco;
c)Funcionalidades gerais do sistema a serem desenvolvidas, incluindo requisitos não técnicos.
Algumas técnicas que evoluem bem em ambientes ágeis controlados, como a refatoração, não escalam bem quando se tem múltiplas equipes cooperando no mesmo produto.
O modelo ágil pode escalar bem para grandes projetos desde que adote os conceitos regulares de Release Planning,Sprint Planning,Test Planning, Integração contínua e defina equipes para desenvolvimento no estilo FDD(orientado a features) ao invés do desenvolvimento orientado a componentes.
Do ponto de vista de engenharia de software, as atividades abaixo são desafiadoras para projetos grandes,complexos,distribuídos e em várias equipes e se potencializam quando em modelos ágeis:
a)Estabelecer os objetivos gerais do produto e ter uma visão do projeto;
b)Gerenciar a alocação de requisitos para as equipes;
c)Definir e manter as interfaces e restrições entre equipes, tanto para o produto quanto para o processo;
d)Manter integração efetiva dos produtos, com verificação e validação;
e)Coordenar a gerência de riscos por todo o projeto.
Esses processos necessários para a condução de grandes projetos estão presentes nos níveis D e C do MPS.BR(N3 do CMMI).
Algumas abordagens Scrum estão evoluindo de forma a permitir a efetiva gerência de grandes projetos. O "Scrum of Scrum" é uma delas, que seria uma espécie de gerente sênior alinhavando vários projetos. O MPS.BR possui processos e resultados que orientam na gerência integrada(GPR-II e GPP-Portfólio) e o CMMI tem um processo(IPM) voltado para isso.
Os métodos ágeis também deverão buscar melhorias dentro do escopo organizacional que suportem definição de processo, medições,treinamento, reutilização, etc, e formem um arco gerencial mais amplo do que os limites do "scrum team", principalmente para projetos com tais características. Nas empresas de MG, que estão envolvidas com MPS.BR e Scrum, percebe-se alguns sintomas semelhantes. A Powerlogic, que fará sua apresentação, uma empresa, cuja UO(Unidade organizacional) avaliada é focada em produtos, tem nível C(CMMI-N3), e adota Scrum com extrema capacidade, sendo inclusive referência no Brasil.Uma empresa pequena, focada em projetos, localizada no interior, prestes a tirar nível G, em junho/julho adota Scrum/Ágil com bastante eficiência e muito provavelmente logrará êxito na sua avaliação. Uma empresa maior, também com ênfase em projetos, localizada em BH, nível F e indo para C, divide o seu universo de projetos, deixando aqueles que demandam maiores controles para o método mais estruturado, no qual se certificaram F(2 do CMMI) e para os projetos menores, incentiva a aplicação do Scrum. Mas é importante observar que isso tudo pode ser relativo: depende da empresa, do seu amadurecimento em métodos ágeis, do seu tipo de contrato com clientes, etc. Ou seja, cada empresa pode ter a sua verdade momentânea.

Visão Ágil e Visão estruturada-Parte 5-Analisando o Manifesto Ágil

A interpretação do Manifesto Ágil, por vezes pode trazer impropriedades à sua aplicação e os erros de sua interpretação podem ser danosos até para os agilistas.
O Manifesto diz algo assim:
---------
1)Estamos apresentando melhores formas de desenvolvimento de software, fazendo e ajudando os outros a fazerem. Através desse trabalho, estamos valorizando(come to value) :
1)Indivíduos e interações com relação(over) a processos e ferramentas;
2)Software funcionando com relação(over) a documentação abrangente(aqui um erro de interpretação de inglês que alguns cometem, quando traduzem a palavra -comprehensive- como compreensiva);
3)Colaborações com o cliente com relação a negociações contratuais;
4)Resposta a mudanças com relação a acompanhamento(following) de um plano.
---------

Os pontos fundamentais na análise do manifesto são dois:
a)Entendimento do verbo valorizar(to value) e
b)Os conceitos colocados à direita das premissas do manifesto, após a palavra com relação ou (sobre)(over).
Justamente esses dois pontos tem contribuído para a adoção equivocada de alguns preceitos dentro dos métodos ágeis. O conceito de "to value"(valorizar) está dizendo que o Manifesto dará maior valor, considerará mais os itens à esquerda da frase do que os à direita. Isso, entretanto não significa que os da direita devem ser banidos definitivamente, o que foi assumido por interpretações equivocadas de que os modelos ágeis não devem ter processos, ferramentas, documentação,negociação contratual e planos. O que o Manifesto explicita é que os itens à esquerda devem ser mais valorizados. De novo, as fragilidades na interpretação levam as duas bandas(agilistas e estruturados) a terem posicionamentos incorretos sobre o significado real do manifesto.Tanto para o lado dos agilistas, que justificam a ausência desses artefatos como uma imposição pétrea do manifesto, como pelo lado dos estruturados que criticam um ambiente caracterizado como indisciplinado e anárquico.A interpretação equilibrada do Manifesto ajuda tanto na adoção exata e ajustada do modelo, quanto na diminuição de críticas originadas pelos erros de sua interpretação.

Visão Ágil e Visão estruturada-Parte 4-Entendendo o conceito de modelo

Entendendo o conceito de modelo:
Uma dos pontos mais importantes para se diminuir as lacunas conceituais entre os dois modelos é perceber que o CMMI e o MPS.BR são " modelos" e não "padrões". A distinção, vai muito além da semântica e nos remete a observação de algo simples como o capim. Um "modelo" define o "quê" e não o "como". Isso faz muita diferença quando pensamos em implementar um modelo e analisarmos os riscos da sua interpretação, inclusive para a preparação da avaliação. Quando você trabalha com o balizamento pelo "o quê" a implementação torna-se mais liberta de procedimentos, templates rigorosos e de processos pré-cozidos. Até porque a empresa, dentro da sua visão, cultura e estilo é que irá definir certamente isso. O modelo será o guia, a orientação e o apontamento de caminhos. O cuidado que se deve ter sempre é garantir que aquilo que você definiu produza os resultados esperados que o modelo exige. Já o "padrão" é muito mais rigoroso e impõe formas específicas de se fazer algo. No modelo ágil, por exemplo, se a empresa apresenta o Release Plan, identifica o P.O(Product Owner), que representa os fornecedores de requisitos da área do Produto e na reunião de Sprint Planning 1 seleciona os itens do Product Backlog, estaria caracterizando o resultado GRE1-Os requisitos são entendidos, avaliados e aceitos, junto aos fornecedores de requisitos,utilizando critérios objetivos  e o SP1.1-Obtain an understanding of requirements, do processo RM(requirements management) do CMMI. Isso, por si só, mostra que modelos como MPS.BR e CMMI incentivam as empresas a buscar alternativas de solução, através de práticas, frameworks, e de outros conceitos correlatos, sem estabelecer amarras rígidas a pontos pré-definidos. É claro, entretanto, que algumas evidências são necessárias em uma avaliação, para que se possa perceber o alcance da implementação. O exemplo, que sempre cito, a respeito de um agilista entusiasmado que conheci e que dizia ser ele(em carne e osso) a própria documentação do Plano de Projeto, implicará reprovação naquele resultado específico. É importante entender que MPS.BR e CMMI são coleções de idéias e de boas práticas registradas ao longo de décadas e que devem ser usadas como guias para implementação na empresa, sempre de acordo com a cultura dela. Aqui cabe a diferenciação entre "aplicar" e "implementar". "Aplicar" MPS.BR ou CMMI, sugere muito mais um decalque justaposto sobre os processos existentes da empresa a fim de produzir os produtos que o modelo espera. "Implementar" MPS.BR /CMMI, por sua vez, sugere você usar o modelo como uma ferramenta de aprendizado, de comunicação e de organização de idéias, claro, dentro de um universo delimitado. Também significa parar para analisar o que se faz, da forma com que a empresa e sua cultura adotam a prática, e "ajustar" de maneira a melhorar, se e onde cabível. Onde não for pertinente, deveremos olhar para verificar se o que é feito e como está feito atende às exigências do modelo, podendo até permanecer como tal. Essa caracterização do MPS.BR/CMMI, como um "modelo" guia de melhorias de processo, por vezes não é observada nem pelos seus implementadores e as vezes não entendida nem por seus avaliadores, ajudando a criar, dessa forma, mitos de dificuldade, que na realidade não deveriam existir, caso os conceitos de "modelo" e de "implementação" fossem plenamente entendidos.

Visão Ágil e Visão estruturada-Parte 3-Métodos Ágeis

Métodos Ágeis:

O surgimento dos métodos ágeis se deu, para surpresa de muitos, bem antes da Internet e dos processos colaborativos. A pedra fundamental dos métodos ágeis foi o desenvolvimento de projeto com estilo iterativo e incremental, aplicado à engenharia desde a metade dos anos 30. IIDD, como era chamado "Interative and Incremental Design and Development", já era muito usada em projetos de engenharia de hardware(não software). O grande precursosr dos métodos iterativos e incrementais foi Dr Edward Deming, um estatístico, professor que promoveu o conceito de PDCA(originalmente PDSA), com o -S- de Study ao invés de -C- de Check. A Nasa,a Força Aérea Americana e a indústria japonesa usaram intensivamente o método de Deming em projetos "time box", iterativos e com ciclo de desenvolvimento incremental de produtos. Na metade dos anos 50, diversos projetos de software usaram o método de IIDD, empregando muitos dos conceitos hoje aplicados nas metodologias ágeis. Entretanto num mundo dominado pelo Cobol, com demandas por projetos complexos, grandes arquivos, abordagem top-down estruturada, isso acabou não sendo percebido como um possível padrão emergente. Em 1976, Tom Guilby apontou no seu livro "Software Metrics", que um método superior para desenvolvimento de software existia e lançou a idéia de algo mais leve, mais ágil, mais adaptativo, com ciclos e iterações que mostravam mais rapidamente os produtos ao cliente. Essas idéias foram gradativamente amadurecidas e em 1985, Barry Boehm lançou o seu método Espiral, no seu "The Spiral Model of Software Deevelopment and Enhancement". Durante os anos 90, aumentou a aceitação dessa nova abordagem e o IIDD ganhou variantes como RAD(Rapid Application Development) e RUP(Rational Unified Process). Embora soando estranho, algumas técnicas inovadoras de métodos ágeis surgiram em grandes empresas: XP(eXtreme Programming) surgiu na Chrysler Corp em 1996, num projeto pilotado pelos ainda não gurus Ron Jeffries e Kent Beck. Já no final da década, ficou claro que um método que privilegiava a forte interação entre equipes, usava a comunicação "tête-à-tête",aplicava uma rigorosa interação com o cliente, empregando times pequenos e rápidos,e com as entregas frequentes de software, se tornaria uma forte abordagem para se fazer software de forma superior àquela vigente. Vários métodos foram derivados dessas idéia originais como Scrum, Crystal, FDD, etc. Com a proliferação de métodos se deu um fenômeno parecido com o que aconteceu quando do surgimento da UML. Havia a necessidade de se definir algo em comum e os grandes gurus de cada linha se uniram para escrever o famoso "Manifesto Ágil", nascido nas montanhas geladas do estado de Utah. Os líderes foram: Kent Beck,Ron Jeffries,Alistair Cockburn, Jim Highsmith,Bob Martin,Mike Beedle,Ken Schwaber e Jeff Sutherland. Um subconjunto desses autores se juntou à Mary Poppendick para formar a Agile Alliance, organização não lucrativa voltada para encorajar o uso de métodos ágeis. Enquanto o primeiro manifesto foi focado para programação, 2 gurus originais(Cockburn e Highsmith) se juntaram com outros luminares como David Anderson, Mike Cohn, Todd Little, etc para definir os seis princípios de gerenciamento, conhecido pelo estranho nome de "Project Management Declaration of Interdependence(DoI)". Os 15 autores do DoI formaram o Agile Project Leadership Network(APLN), de novo, um organismo sem fins lucrativos que encorajava a prática de métodos ágeis, agora em domínios de liderança e gerenciamento. Esses manifestos, somados ao crescimento de desenvolvimento de software para a internet alavancou o método, sendo que o mais conhecido (Scrum) continua a crescer além do software, alcançando domínios que objetivam os mesmos ganhos definidos por Deming e equipe, com o seu IIDD. Assim surgiu um método caracterizado por premissas frontalmente opostas àquelas existentes :
1)Equipe pequena,coesa e trabalhando com forte interação;
2)Forte participação do cliente;
3)Entregas pequenas e em maior frequência;
4)Comunicação "tête-à-tête", com experiência fortemente focada em projetos menores, sem os rigores do custo fixo, com aceitação de riscos, que segundo o método, serão mitigados pelas suas próprias características de fluidez,rapidez e de entregas menores.
Da mesma maneira, o modelo ágil proposto deverá ser observado, segundo seus valores e princípios de uma forma aberta, atentando para o fato de que o Manifesto ágil define preferências e não alternativas excludentes e encoraja o foco sobre certas áreas mas não elimina outras.

Visão Ágil e Visão estruturada-Parte-2-CMMI

CMMI:

Um dos pontos mais importantes para se entender as diferenças e ajustar os encaixes, quando falamos de CMMI(MPS.BR) e métodos ágeis, é compreender a origem de cada abordagem.
O CMMI surgiu para se desenvolver projetos grandes, de gerência altamente complexa, torneados com escopo imutável e custo definido, além de altíssima aversão a riscos. Os primeiros projetos CMM surgiram para a fabricação de softwares que visavam controlar naves espaciais, satélites inovadores e armamentos de tecnologia inédita. O modelo foi publicado em 1989, por Watts Humphrey, no seu livro "Managing the Software Process". O Departamento de Defesa(DoD), responsável por esses projetos estratégicos não tinha outra saída, naquele momento, senão sugerir métodos altamente estruturados, com forte gerência de requisitos e um estrito controle das partes envolvidas.Um ambiente onde o escopo era(ou tinha que ser) definido rigorosamente, pois o software era tido como um componente de algo maior, cuja infalibilidade era a premissa primeira, até porque naves espaciais, satélites,equipamentos médicos,etc, implicavam aspectos de segurança de vida. Os usuários não eram stakeholders colaborativos, como agora percebemos, entrando no circuito do processo somente para os testes e com pouca intervenção durante o trajeto. Esse conceito era chamado de "low trust". O sistema era desenvolvido por processos cuidadosamente definidos centrados no menor risco, na fortíssima padronização e em relacionamentos amplamente costurados por contratos entre clientes e desenvolvedores. Isso acabou moldando a personalidade do modelo CMMI para ambientes que os americanos chamavam de " high ceremony" e "low trust" , ou seja com alto nível de controle de risco e aplicação de gerência e com baixa interveniência dos usuários. As entregas, por sua vez, também obedeciam a uma receita da época: os "deliveries" eram monolíticos e infrequentes. Porquê? Por que a parada de um caça de guerra para troca de possível componente(software incluído), ou a suspensão da funcionalidade de um aparelho médico podia custar muitas horas de logística. Na época, claro,não se baixava um software pela internet. Além disso, entregar o componente funcionando na sua plenitude, no primeiro "delivery" era premissa de primeira ordem. Tudo isso, num projeto gigantesco, com envolvimento de múltiplas empresas com inúmeras equipes e entrelaçados por contratos governamentais exigentes em termos de baixo risco. Com o tempo, o CMM ganhou variantes para outros projetos(não somente de software) e não demorou o pleito para que todas essas fossem empacotadas num único modelo, quando nasceu o CMMI, em 1998. O CMMI foi evoluindo e hoje forma o framework com um conjunto melhorado de padrões, práticas e idéias.Mas a sua gênese trouxe marcas que definiram o método e que se observa no seu genoma:
1)Aplicado para projetos grandes e de alta complexidade;
2)Aplicado em projetos com múltiplas equipes, oriundas de empresas diferentes e até competidoras entre si, onde a competitividade influia e o alto protocolo definido substituia a confiança(trust) e a coesão das equipes, definindo um ambiente com traços de "low trust". Ou seja, a confiança entre os times não se dava por coesão, integração e interação constante das equipes(valor do relacionamento do capital humano), mas pelo nivel de cerimônia, rigor e protocolo que o processo impunha;
3)Projetos onde os "deliveries" eram monolíticos e infrequentes, pois a logística de parada dos seus receptores de software (aviões,satélites e devices médicos) implicava sérios riscos. A idéia era entregar o " todo" com "quase tudo" funcionando na primeira vez( a velha e volumosa cascata);
4)Os projetos tinham que ter baixos riscos(aversão intensa a riscos) devido às suas características técnicas especiais e ao alto investimento de recursos públicos, dada as características dos projetos.
Assim nasceu um modelo CMMI, fortemente estruturado, revestido pelo rigor das regras e com baixa interação do capital humano(entre equipes),porém aplicado para projetos gigantes e de alta complexidade operacional e gerencial.Isso, entretanto, não significa que o Modelo, tal como definido hoje, não pode ou não deve ser aplicado em projetos que possuem estilo e ciclos de vidas diferentes. Um modelo, qualquer que seja, deve ser visto como um guia e não como uma regra ortodoxa calcada sobre preceitos imutáveis, conforme veremos na parte 4.

Visão Ágil e Visão estruturada-Parte-1-Introdução

Quando um dinossauro como eu, cheio de movimentos letárgicos e pré-reumáticos, é convidado a falar sobre MPS.BR num evento chamado -Maré de Agilidade- , há que se preparar. Como sou um "sem-prancha", e da praia só gosto da paisagem, detesto a areia e me incomodo com o sol, senti a necessidade de buscar um pouco da história para preencher o vazio que tal combinação insólita proporcionaria(um dinossauro sem prancha, numa praia cheia de jovens surfistas, brilhantes e ágeis). Fui estudar um pouco acerca dos dois pólos aparentemente antagônicos e distantes dentro do campo da Engenharia de Software: O métodos ágeis e os métodos , que chamei de estruturados, envolvendo CMMI e MPS.BR. Esse artigo, claro, não objetiva nem evangelizar os seus pouquíssimos leitores de forma a cooptá-los a uma genuflexão definitiva diante do altar de uma das alternativas, nem acender uma tocha provocativa, buscando detonar uma linha e colorir de méritos a remanescente. Muito pelo contrário, a missão é de paz.
Se pudesse definir um objetivo sintético para essas reflexões, diria que, como já falei por cerca de 4 horas e pouco no podcast do Vinicius Manhães Teles, estamos falando de métodos convergentes e não de extremos que nunca se tocarão.
Esse trabalho foi centrado no melhor "paper" que detalhou os dois métodos. Publicado pelo SEI, em Novembro de 2008, sob o título de CMMI or Agile: Why not embrace both, esse artigo, escrito por pessoas ligadas profundamente à engenharia de software, mostra com equilíbrio e vislumbre as trilhas de convergências entre as duas propostas. Dentre seus autores (Hillel Glazer, da Entinex,Inc; Jeff Dalton, da Broadsword Solutions Corp;Mike Konrad do SEI; e Sandy Shrum do SEI), também se encontra David Anderson, da David Anderson Associates, um dos signatários do Manifesto Ágil, em uma das suas vertentes. Ele foi escrito em várias partes, para que um leitor incauto possa desistir dele, sem grandes perdas de oxigênio e comprometimentos de suas sinapses. A estrutura, segue uma estrutura próxima do artigo original:
1)Essa introdução
2)Visão do CMMI e métodos estruturados(MPS.BR)
3)Visão dos métodos ágeis
4)Entendendo o conceito de modelo
5)Analisando o Manifesto Ágil
6)Desafios
7)Conclusão
8)Adendos-extensões sobre o assunto

Eu na Livraria Cultura, hoje pela manhã. "Causos" de Minas

Não sei se todos conhecem a Livraria Cultura, na Paulista com Augusta. É um dos lugares mais espetaculares para quem gosta de olhar livros, respirar um oxigênio mais elevado, comprar eventualmente alguns lançamentos mundiais, circular por entre as prateleiras gigantescas e até se deitar num -puff- generoso que te abraça enquanto você você lê um livro gratuitamente por quanto tempo desejar. Sem que ninguém venha lhe perguntar, algo do tipo: Posso ajudá-lo?.Coisa de primeiro mundo. Sempre que venho a SP, vou lá, pois é a minha Disneylândia na terra da garôa. Acabei de chegar de lá, junto com Beth e Maria Alice, minha nora. Flávio, meu filho está num evento da Microsoft e somente nos encontrará à noite, com Ana Luiza e Roberto.
Beth procura por um livro americano, que fala sobre a arte de escolher(The Art of choosing), escrito por uma consultora cega,especialista em tomadas de decisão. Parto para um ponto de atendimento da mega-loja e inicio a conversa com o vendedor(nome Marco Antônio Canela).No final da história, voces entenderão o porquê de ter gravado o seu nome.
__Gostaria de encomendar um livro americano, chamado The art of choosing, disse eu.
__ OK, Deixa-me ver se temos, disse ele,enquanto olhava no sistema. Não encontra no estoque, mas somente no catálogo e me pergunta se quero encomendar. Digo que sim e ele me pergunta o nome.
__Carlos Barbieri, respondo.
__O Sr é aquele famoso professor?
Eu, com sorriso meia boca, tolhido pela mineiridade desenvolvida, pronto para dizer qualquer coisa que a minha vaidade interior, em ebulição, me permitisse. Não deu nem tempo..
__Professor José Carlos Barbieri, da USP. Que prazer, disse ele.
Com sorriso amarelo, respondo:
__Não, não sou eu não. Sou somente Carlos Barbieri.
No nome, brinco com ele, sou 2/3 desse gigante Uspiano, ele tem José a mais do que eu, mas certamente sou bem menos, falei. Sou de BH, da terra das montanhas, onde o trabalhamos em silêncio , trololó..e continuo a falar para disfarçar o -yellow smiling-. Com o jeitinho que aprendi em Minas,encho o peito de coragem e falo que também tinha 2 livros publicados, mas que vc sabe, livro técnico, vende pouco, só a família, alguns amigos e alunos desesperados compram, ninguém conhece muito, etc,etc,etc...
__Seria um livro de BI?, pergunta ele.
__Pois é , é esse mesmo, respondo eu, com sorriso de boneco de ventríloquo.
__Puxa, eu já li esse seu livro, disse ele, enquanto buscava no sistema a capa em tons vermelho amarronzado, que conheço de cor e salteado.
__Sabe, eu sou da área técnica e trabalho aqui na Cultura e hoje, excepcionalmente, estou nesta seção de importados, mas na realidade trabalho na outra e gosto e estudo TI, etc, etc, disse ele, enquanto eu já não ouvia mais nada, com o ego inflado tal qual uma bexiga de aniversário.
__Mas o seu livro de BI está esgotado, não é mesmo?
Conto pra ele, que sim, mas não por méritos do livro, mas por demérito do editor. Falo sobre o site -inimigos da Axcel-, da editora AxcelBooks, cujo dono está foragido e que escreveu um livro sobre Capoeira nos EUA, sob o pseudônimo de Mestre Ricardo Cachorro. Ele acessa no sistema o livro -Unknown Capoeira-, de Mestre Ricardo Cachorro, o próprio. Ele diz algo como ..putz , que coisa..
__Olha, seu livro de BI é bastante procurado por aqui, mas não temos mais,está esgotado, complementa ele. Falei , então, do movimento de doações ao Hospital do Câncer Infantil e que ele poderia -rotear- os possíveis interessados para este blog, que entrega o livro na forma de pdf, para quem fizer uma doação de R$30,00 diretamente à AURA, entidade que apoia crianças com câncer, etc.
__Você não vai reeditar o livro, me pergunta ele. Disse que sim, que farei o BI2, em fase de escrita, etc e que nunca mais me alio a qualquer editora carioca, de quem tomei rasteiras nos dois livros que escrevi. Ai , ele me dá o seu cartão e fala: __Quando você estiver com o livro (BI2) pronto, me procure aqui na Cultura, que farei os contatos com todas as grandes editoras de SP visando a publicação de seu livro.
Eu, como se diz em Cruzeiro, minha terra, boquiabri e não boquifechei.
Havia ganhado o dia, o sorriso amarelo foi embora e senti que não perdí de goleada para o gigante da USP.

Governança de Dados-I

Governança de Dados:
O framework acima, mostra os principais componentes de GD-Governança de Dados

1)Estratégia e missão da empresa: entender para onde vai a empresa, quais os caminhos planejados, entender a estratégia( "como" a empresa intenciona chegar lá) , entender "como" os dados bem gerenciados podem influir nisso
2)Organização e Planejamento: Como a empresa está organizada e planejada para alcançar esses caminhos;
3)Definir papéis: Definir a área de governança,na forma de um conselho(board) e criar uma área operacional de governança, espécie de um SEPG, investido da autoridade para as ações operacionais. Seria um DGPG-Data Governance Process Group, grupo que ficaria com a responsabilidade de conduzir as ações nesses domínios. Nesses dois níveis deverão ser envolvidos os responsáveis pelos dados mais sensíveis da empresa, além dos seus produtores e consumidores. O Conselho deverá investir o DGPG da autoridade para conduzir as definições de : Políticas de dados,Regras e Padrões, Responsabilidades e controles. Além disso, a definição de métricas , que deverão indicar a evolução dos aspectos de dados, comparado com o estágio inicial da empresa. Ações de qualidade de dados deverão ser planejadas, visando a identificação de MDM(dados mestres mais sensíveis) e levantamento de aspectos de qualidade(precisão, completeza, segurança,acessabilidade,etc) sobre esses dados deverão ser focos de projetos pilotos. Um trabalho mais orbital , que poderá subsidiar essas ações mais imediatas seria o levantamento da arquitetura atual dos dados mais sensíveis aos negócios da empresa, a identificação de seus metadados e a definição de repositórios para essas meta-informações. Esse levantamento deverá ser sempre cruzado com os processos de negócios que se utilizam, consomem, produzem ou atualizam esses dados e que são os responsáveis, em grande parte,pela introdução de erros e problemas nos domínios dos dados. A melhoria dos processos é fator crítico de sucesso neste domíno dos dados, pois seguindo sempre a premissa do interior de Minas, "de cano sujo não sai água limpa". Isso levará a empresa à construção de uma arquitetura corporativa de informação. As tecnologias que deverão ser usadas:
a)BI-como elemento de estruturação e provimento de informação, originada desses dados, agora sob um manto de maior controle;
b)O uso de estruturas de DW,Dmarts e ferramentas de integração de dados;
c)As ferramentas de MDM e de metadados para os trabalhos sobre os dados sensíveis e a estruturação dos repositórios de metadados;
d)As ferramentas de data cleansing, data profiling, etc, visando os aspectos de qualidade intrínseca dos dados.

De novo sobre BD nas nuvens - NOSQL

Há pouco, escreví aqui algumas linhas sobre uma nova forma de BD, genericamente chamada de NOSQL. É uma abordagem que procura fugir da estruturação rígida dos modelos relacionais, escanteando os conceitos de normalização de dados. Segue uma linha mais libertária de definir dados e metadados em conjunto. Hoje já a aparecem em diversos sistemas em uso pela nuvem.
O Henrique Lobo, meu ex-aluno da Fumec, que me havia pedido opinião sobre o assunto, escreveu algumas linhas, que republico aqui. Veja o link abaixo:

http://www.itexto.net/devkico/?p=682