O sucesso de um projeto é em grande parte determinado pelo jeito de como ele é conduzido, isto não apenas para SAP mas para qualquer outro ambiente. De modo à melhorar a probabilidade de sucesso nos projetos SAP, a mesma criou um modelo para direcionar projetos neste ambiente, o ASAP – Acceletated SAP. Este modelo endereça diversas práticas de engenharia de software e gestão e é bastante funcional.

Comparando com CMMI, MPS.Br ou PMI, podemos dizer que está bem longe destes modelos, mas recomenda diversas boas práticas consagradas recomendada pelos mesmos.

A metodologia ASAP está baseada em cinco pilares, cinco fases que assim como em outros projetos de engenharia de software vai da definição de escopo, passando por especificação funcional, design, construção, testes até chegar à validação e implantação. Estas cinco fases ajudam a deixar o projeto mais controlável e mais organizado.

É importante lembrar que está não é única abordagem possível para projetos SAP, mas é uma abordagem bastante funcional e prática.

Cada fase tem um conjunto de atividades como abaixo:

1. Project Preparation

Este é o momento onde o escopo é definido, detalhado e estimado. O planejamento do projeto é realizado assim como o kickoff do mesmo para alinhar o entendimento do que é o projeto. Os seguintes temas devem ser tratados:

• Escopo
• Estimativas
• Planejamento inicial do projeto
• Cronograma
• Aspectos técnicos
• Definição de equipe
• Identificação de Riscos e estratégias para os mesmos
• Planejamento de controle de qualidade
• Kickoff

2. Blueprint

Neste momento os analistas funcionais devem levantar e detalhar os requisitos de negócio e processos. Tudo deve ser documentado e consolidado no Business Blueprint. Os seguintes aspectos são endereçados:

• Levantamento dos Processos de negócio
• Gestão do projeto
• Mudanças organizacionais (e estratégia de tratamento)
• Treinamentos (key users e usuários)
• Ambiente para desenvolvimento
• Deginição dos novos processos de negócio
• Controle de qualidade
• Necessidades e mudanças organizacionais

3. Realization

Podemos dizer que neste momento, a análise funcional realizada anteriormente é traduzida para o ambiente SAP. Os processos e requisitos são configurados (ou adaptados) e implementados no sistema através de atividades como:

• Configuração base
• Configuração final
• Desenvolvimento de programas
• Implementação de interfaces
• Testes individuais
• Testes integrados (e suas evidências)
• Documentação de cenários e processos
• Execuçãso dos treinamentos aos key users e usuários
• Controle de qualidade
• Tracking dos bugs

4. Final preparation

Como o próprio nome diz, aqui são realizados os últimos ajustes, testes e verificações. O sistema poderá ir para a Go-Live após as verificações atenderem ao nível de estabilidade esperado. Neste momento são executadas atividades como:

• Testes de volume
• Testes de stress
• Planejamento da implantação
• Estratégia de implantação
• Treinamentos finais
• Controle de qualidade

5. Go Live e suporte

Básicamente neste momento o sistema é colocado em produção e suportado. São executadas atividades como:

• Transferência de pré-produção
• Ajustes em hardware
• Ajustes em software, base de dados, sistema operacional e outros
• Treinamentos
• Suporte aos key-users e usuários
• Encerramento

O ASAP tem se mostrado eficiente e prático ao longo dos anos de sua existência. Vale a pena considerar seu uso em projetos SAP. Além disso, ele é um bom passo para programas de melhoria contínua de processos.

Dias atrás li este artigo no itweb.com e achei muito interessante. Ele explica de uma forma bem fácil o que é governança de TI.

O que é Governança de TI

Esta é uma questão que muitos CIOs estão fazendo. Isto ocorre devido à diversidade de ferramentas e conceitos que são “despejados” no mercado, gerando dúvidas e definições incorretas sobre o tema.

Os grandes equívocos que ocorrem freqüentemente são de definição, onde se conceitua a Governança de TI (GTI) como um painel de indicadores, ou como um processo de gestão de portfólio dos projetos estratégicos.

Existem algumas frentes defensoras do conceito de que com a implementação de alguns processos baseados em apenas uma das melhores práticas (como Balanced Scoredcards (BSC), CobiT, ou ITIL) por si só, garantem a Governança, entretanto este conceito está incorreto.

A premissa mais importante da Governança de TI é o alinhamento entre as diretrizes e objetivos estratégicas da organização com as ações de TI. A definição do ilustre professor da FGV Sr. João R. Peres demonstra este conceito de forma abrangente, atribuindo os papéis e as responsabilidades conforme abaixo:

“Governança de TI é um conjunto de práticas, padrões e relacionamentos estruturados, assumidos por executivos, gestores, técnicos e usuários de TI de uma organização, com a finalidade de garantir controles efetivos, ampliar os processos de segurança, minimizar os riscos, ampliar o desempenho, otimizar a aplicação de recursos, reduzir os custos, suportar as melhores decisões e conseqüentemente alinhar TI aos negócios.”

Está definição deixa clara a importância da Governança de TI em organizações que almejam atender a crescente demanda por aumento de qualidade de produtos e processos, a alta competitividade do mercado globalizado e a busca por menores custos e maiores lucros.

Outra definição que se encaixa em Governança de TI é de considerá-la como “a Gestão da Gestão”, demonstrando seu papel principal que é de auxiliar o CIO (Governante de TI) a avaliar os rumos a serem tomados para o alcance dos objetivos da organização, onde um direcionamento errado pode levar a empresa ao fracasso em pouco tempo.

Casos de sucesso de um programa de Governança aplicados a uma organização não dão a garantia do mesmo sucesso à outra. Estes casos são muito instrutivos e importantes para auxiliar nos caminhos da elaboração de um programa próprio.

A implementação efetiva da Governança de TI só é possível com o desenvolvimento de um framework (modelo) organizacional específico. Para tanto, devem ser utilizadas, em conjunto, as melhores práticas existentes como o BSC, PMBok, CobiT, ITIL, CMMI e ISO 17.799, de onde devem ser extraídos os pontos que atinjam os objetivos do programa de Governança. Além disso, é imprescindível levar em conta os aspectos culturais e estruturais da empresa, devido à mudança dos paradigmas existentes.

O grande desafio do Governante de TI é o de transformar os processos em “engrenagens” que funcionem de forma sincronizada a ponto de demonstrar que a TI não é apenas uma área de suporte ao negócio e sim parte fundamental da estratégia das organizações.

[Carlos Augusto da Costa Carvalho]

Uma verdade absoluta é de que o inglês é a língua universal. A cada vez mais tem-se o inglês em seu dia a dia. É muito comum ter o inglês técnico, mas este tipo de inglês não é mais do que obrigação. Se não puder ler um artigo técnico simples ou compreender um sistema, aplicativo ou serviço que faz parte do seu dia a dia você praticamente estará cometendo suicídio profissional. Este é o inglês técnico, o tipo de inglês que você impreterivelmente deve ter.

Mas, não deve ser este o seu foco. Seu objetivo deve ser falar inglês, mas… que tipo de falar?

Em algumas palestras que fiz este ano para universidades costumo falar que um dos maiores investimentos que o aluno pode fazer é aprender a falar o idioma inglês. Entende-se por falar, poder se comunicar com outra pessoa que pode estar em qualquer parte do mundo. Todos sabem que a globalização andando a passos muito largos. As grandes empresas tem filiais e escritórios em vários países, e qual o idioma que você acha que será utilizado para se comunicar? O português?

Costumo recomendar que se coloque como primeira meta conseguir se comunicar com uma outra pessoa por telefone. Imagine-se no cenário: Você é o especialista na área financeira e tem um conference para defender com um grande banco europeu um projeto estratégico para sua empresa. Os argumentos que você tem são mais que suficientes e o cliente receberá apenas uma pessoa por empresa. O que acontece se você não tiver o inglês falado? Repare que é uma tarefa relativamente simples, e mais simples ainda se você tiver uma boa argumentação. Mas se você não conseguir se comunicar…

Enfim, coloque como meta tanto profissional quanto pessoal aprender a falar inglês. Há várias formar de se conseguir isto em um prazo relativamente rápido. Procure por bons cursos de inglês na sua região, professores particulares de inglês ou até mesmo um bom curso de inglês on-line (conheço um muito bom).

Valerá muito a pena.

Olá pessoal… O pessoal da Salesforce fez um vídeo muito legal explicando o que é Cloud Computing. Você vai entender o que é de um jeito muito fácil e rápido. Vale a pena assistir.

O que é PRINCE2?

O PRINCE2, ou Project In a Controlled Environment, é um método não proprietário para gerenciamento de projetos. É adaptável a qualquer tipo ou tamanho de projeto e cobre seu ge­renciamento, controle e organização. Um projeto PRINCE2 possui as seguintes características:

• Controle e organização do início ao fim;
• Regular revisão de progressos baseada nos planos e no business case;
• Pontos de decisão flexíveis;
• Gerenciamento efetivo de qual­quer desvio do plano;
• Envolvimento da gerência e das partes interessadas em momentos-chave durante toda a execução do projeto;
• Um bom canal de comunicação entre o time do projeto e o res­tante da organização.

O PRINCE2 é de fato um padrão

O PRINCE2 foi lançado como um método para gerenciamento de projetos pelo governo britânico em 1996, tendo sido criado em 1989 a partir do PROMPTII, o qual, por sua vez, surgiu em 1975 e foi adotado em 1979 como padrão para gerenciamento dos projetos de sis­temas de informação do governo.

Hoje, o PRINCE2 vem sendo adotado como padrão para todos os projetos governamentais no Reino Unido e amplamente utilizado pela iniciativa privada não só naquele país, mas também em outros lugares da Europa, África, Oceania e Estados Unidos. Considerado o método de gerenciamento de projetos mais utilizado no mundo, conta com mais de 250 mil profis­sionais certificados, sendo ainda que cerca de 1500 pessoas prestam, mensalmente, os exames de certifi­cação Foudation e Practitioner. Existem mais de 120 centros de treinamento credenciados PRINCE2 pelo mundo, os quais provêem treinamento, em 17 idiomas, de 59 ferramentas de gerenciamento de projetos desenvolvidas com base no Mé­todo. No Brasil, a metodologia PRINCE2 já vem sendo utilizada em algumas organizações, e é crescente a procura por informações a respeito do assunto.

Benefícios

Com a utilização do PRINCE2, a organização tem como benefícios um gerenciamento con­trolado das mudanças em termos de investi­mento e retorno; um ativo envolvimento dos usuários e das partes interessadas durante todo o ciclo de vida do projeto – o que garante que os produtos atinjam os requisitos de negó­cio, funcionais, de ambiente, de serviço e de gerenciamento. A metodologia possui uma abordagem que distingue o gerenciamento do projeto do desenvolvimento dos produtos, de tal forma que pode ser aplicada na elaboração de projetos de qualquer segmento de mercado, desde a construção de um navio até o desenvolvimento de um sistema de informação. Os gerentes de projeto que utilizam o PRINCE2 são capazes de utilizar uma estru­tura para delegação, autoridade e comunica­ção e ter definidos todos os pontos durante o projeto. Desta forma, todos os riscos serão revistos e analisados e haverá uma sistemática natural para o geren­ciamento de riscos.

Um Overview do PRINCE2

O PRINCE2 é baseado em oito processos e 45 sub-processos, os quais definem as atividades que serão executadas ao longo do ciclo de vida do projeto. Juntamente com esses, são descritos oito componentes que são como áreas de conhecimento que devem ser aplicadas de acordo com a necessidade, dentro das atividades de cada processo. A figura 1 mostra uma visão da estrutura do PRINCE2. Apesar de não descrever quais ferramentas e técnicas devem ser aplicadas, o manual do PRINCE2 fornece três técnicas que auxiliam no planejamento e controle dos projetos.

Processos e componentes PRINCE2

Processos

Starting up a Project – Primeiro processo da metodologia, é iniciado a partir da emissão de um documento denominado Project Mandate, que define, em alto nível, as razões para o projeto. O objetivo desse processo é responder à pergunta: “Existe um projeto viável e que traga valor?”.

Directing a project – Processo de responsabilidade do Project Board, constitui um grupo com responsabilidade de dar direcionamento ao projeto, formado por representantes do negócio, usuários e fornecedores. Aqui são tomadas as decisões sobre o andamento do projeto e sobre prováveis exceções ocorridas ao longo do ciclo de vida. Directing a project tem, como princípio, o gerenciamento por exceção, onde o Project Board monitora o projeto via relatórios e controles por intermédio de pontos de decisão pré-determinados.

Initiating a project – Tem como propósito elaborar os planos que formarão a baseline do projeto e que farão parte do Project Initiating Document (PID), que constitui o contrato entre o Project Manager e o Project Board.

Managing Stage Boundaries – PRINCE2 recomenda que o projeto seja dividido em estágios. Este processo é executado ao término de cada estágio e tem como objetivos:

• Garantir ao Project Board que todos os produtos planejados para o estágio foram completados conforme o que foi definido.
• Prover as informações necessárias para avaliar se o projeto continua viável.
• Preparar e aprovar o planejamento para o próximo estágio.
• Listar qualquer lição aprendida no estágio que está terminando.
• Tratar qualquer exceção ou desvio do planejamento aprovado pelo Project Board.

Controlling a Stage – este processo descreve as atividades de controle e monitoramento dos estágios do projeto, constituindo o dia-a-dia do gerente do projeto. Aqui, são autorizados os pacotes de trabalho, avaliados os riscos e as solicitações de mudanças e efetuadas as ações corretivas necessárias.

Managing Product Delivery – O objetivo deste processo é garantir que os produtos planejados serão criados e entregues. PRINCE2 separa o gerenciamento do projeto do desenvolvimento do produto. Este processo constitui a interface com os processos de desenvolvimento dos produtos do projeto existentes na organização como, por exemplo, o RUP (Rational Unified Process) para desenvolvimento de software.

Planning – Este processo desempenha um papel importante nos outros processos. Associado à técnica product-based planning, sua função é auxiliar no desenvolvimento dos planos necessários para o projeto.

Closing a Project – o propósito deste processo é realizar o fechamento controlado do projeto. O fechamento pode ser conduzido ao término do projeto, quando este já desenvolveu e entregou todos os produtos propostos ou se, por algum motivo, tornou-se inviável.

Componentes

Business Case – Justifica a existência do projeto. A filosofia-chave por trás do PRINCE2 é a concepção de que o Business Case deve direcionar o projeto. Ao longo do ciclo de vida do projeto, o ele é revisado e validado para garantir que o projeto se mantenha relevante. Um sólido Business Case irá auxiliar no alinhamento do progresso do projeto aos objetivos do negócio, mantendo-o relevante para a organização. Se não existir um Business Case satisfatório, o projeto não deve ser iniciado. Ele é a ferramenta pela qual o Project Board irá monitorar sua viabilidade.

Organisation – Provê uma estrutura para o projeto com a definição de papéis e responsabilidades e o relacionamento entre os diversos papéis atuantes no projeto. A figura 10 mostra a estrutura de gerenciamento de projetos PRINCE2.

Plans – Disponibiliza um conjunto de planos que podem ser adaptados às características do projeto. O planejamento é vital para o sucesso de um projeto, e o plano deve conter informações detalhadas o suficiente para deixar claros os resultados que se quer alcançar.

Controls – Oferece uma série de controles que ajudam na previsão e nas decisões para a resolução de problemas. Nenhum projeto é conduzido 100% de acordo com o plano, sendo comuns desvios em custo, prazo, ou em algum outro indicador. Aqui é aplicado o conceito de tolerância, onde se definem os níveis de tolerância que o projeto pode aceitar. Isso significa que, se a cada verificação de status o projeto estiver dentro da faixa de tolerância, não será preciso nenhuma ação do Project Board, que será acionado somente se houver alguma previsão de que as referidas faixas serão excedidas. Isso é conhecido como gerenciamento por exceção, uma forte característica dos projetos PRINCE2.

Management of Risk – Define os momentos-chave onde os riscos devem ser avaliados e revisados, além da abordagem a ser aplicada em sua manutenção.

Quality in a Project Environment – Apresenta uma abordagem para o controle de qualidade dos aspectos técnicos e de gerenciamento do projeto durante todo seu ciclo de vida.

Configuration Management – Define as funções essenciais e informações necessárias para a gerência de configuração do projeto, garantindo o correto versionamento dos produtos a serem entregues. Constitui uma proteção para os produtos do projeto.

Change Control – Técnica cujo objetivo é controlar as mudanças do projeto, verificando e validando seus impactos.

Estrutura de gerenciamento de projetos

Técnicas

Product-based Planning – PRINCE2 tem foco de planejamento nos produtos que o projeto deverá desenvolver e não nas atividades desempenhadas na sua produção. Isso altera a forma de planejar e controlar o projeto. O planejamento e definição do escopo são realizados a partir de uma estrutura denominada PBS (Product Breakdown Structure) muito similar à EAP (Estrutura Analítica de Projeto), na qual o produto final do projeto é quebrado em sub-produtos até o menor nível de sub-produtos identificáveis. A estrutura também ajuda na criação de pacotes de trabalho, que facilitam a distribuição e o controle do trabalho para as equipes de desenvolvimento. Esta técnica provê um framework que pode ser aplicado a qualquer tipo de projeto, disponibilizando uma seqüência lógica para o trabalho a ser realizado.

Change Control Technique – Define os passos para o efetivo tratamento das mudanças solicitadas ao longo do projeto. Visa exclusivamente o controle de mudanças nos produtos desenvolvidos pelo projeto (specialist products), e não dos produtos de gerenciamento (management products).

Quality Review Technique – Constitui um processo estruturado para a revisão de qualidade, que visa garantir que cada produto entregue atinja o seu propósito conforme a sua especificação de qualidade.

Implantando o PRINCE2™

A chave do sucesso da utilização do PRINCE2 é a sua escalabilidade/adaptabilidade,. É recomendado que cada processo seja implementado a partir da seguinte questão: “Quão extensivamente este processo deve ser aplicado para este projeto?”. Dessa forma, para um projeto pequeno um processo pode ser menos formal e ser todo desenvolvido em uma reunião, enquanto que para projetos maiores, ou que envolvam maiores impactos para a organização, eles serão extensos e com mais formalidade. Uma boa estratégia é determinar um padrão mínimo (com a definição de uma política) de documentos obrigatórios e opcionais. Na implantação em um ambiente corporativo, devem ser considerados os padrões já existentes, como por exemplo, padrões de qualidade, ferramentas, etc.

O PRINCE2™ e o PMBOK

Existe um alto nível de compatibilidade entre o PRINCE2 e o PMBOK. O segundo constitui uma ampla base de conhecimentos em gerenciamento de projetos, e é fato que toda empresa, desejando gerenciar seus pro­jetos de forma a aumentar suas chances de sucesso, deverá levá-lo em consideração. O PRINCE2 é totalmente aderente às boas práticas contidas no PMBOK, sendo em al­guns aspectos a sua materi­alização.

Agregando valor ao projeto, o PRINCE2:

• Provê um modelo de processos melhor direcionado ao geren­ciamento de um projeto específico.
• Possui um processo de planejamento mais claro, que permite ao gerente de projetos planejar o esforço para fazer os planos necessários ao projeto.
• Possui uma estrutura organizacional com papéis e responsabilidades definidas para o time de projeto, especificando quem faz o que e quando.
• Estabelece a divisão do projeto em está­gios, facilitando o gerenciamento e o pla­nejamento do projeto.
• Estabelece checks points com processos detalhados para captura de informação sobre o progresso do projeto.
• Materializa o controle integrado de mudan­ças (sub-processo 4.6 do PMBOK), pro­vendo uma detalhada abordagem de con­trole de mudanças e gestão de configu­ração ao longo do processo de gerencia­mento do projeto.
• Determina processos claros para definição, verifica­ção e controle do escopo do projeto,
• Provê monitoramento e controle de riscos, fatores intrínsecos aos processos de geren­ciamento do projeto.

[Adalcir da Silva Angelo]

O acrônimo S.M.A.R.T. para a definição de objetivos já é bastante conhecido. O problema é quando se conhece somente a tradução de cada letra não se desenvolve um raciocínio mais amplo do que realmente significa o conceito.

Portanto, o que realmente procuramos na definição de um objetivo (de negócios, profissional ou pessoal) quando dizemos que ele deve ser S.M.A.R.T?

S – Specific (Específico)

Ao definir um objetivo, não se deve deixar espaço a interpretações duvidosas. Quanto mais detalhado for o objetivo, melhor será sua compreensão e maiores suas chances de ser atingido. Você pode fazer as seguintes perguntas para garantir que seu objetivo é específico:
Quem está envolvido?

• O que eu quero atingir exatamente?
• Aonde deve ser atingido este objetivo?
• Qual é o período no qual este objetivo deve ser atingido?
• Quais são meus requerimentos e restrições?
• Quais propósitos ou benefícios existem em atingir este objetivo?

Por exemplo, ao invés de definir “Aumentar as vendas em 10%”, um objetivo melhor seria “Obtenção de 10% no aumento de vendas nacionais nas áreas de negócios A, B e C pela equipe X, durante o próximo ano fiscal, sem redução da margem de lucros e mantendo o nível de satisfação do cliente.”.

Depois de definir o objetivo, avalie se ele está completamente claro para qualquer pessoa com um conhecimento básico do projeto ou da organização.

M – Measurable (Mensurável)

Vale repetir a famosa frase “Você não pode gerenciar o que não pode medir”. Qualquer objetivo que não possa ser transformado claramente em um número permite a manipulação e interpretação para que os interessados o considerem atingido ou não. Talvez sua organização não tenha as ferramentas necessárias para medir um objetivo, e neste caso elas devem ser desenvolvidas antes da definição do objetivo.

Por exemplo, “Melhorar a satisfação dos clientes da loja A em 20% em 3 meses” parece ser um objetivo específico. No entanto, pode acontecer que a loja em questão não tenha um sistema adequado de medição da satisfação do cliente. Desta forma, o gerente da loja poderia usar qualquer variável que tivesse melhorado para considerá-la como determinante da satisfação do cliente, atingindo assim seu objetivo.

Portanto, é importante ter claramente definido o método ou sistema de medição que será usado para monitorar o objetivo.

A – Attainable (Atingível)

Os objetivos sempre devem ser agressivos, mas nunca impossíveis de atingir. É importante lançar um desafio para que a equipe se supere e lute por algo que parece ser difícil, mas isto é muito diferente de definir números que nunca poderão ser obtidos, o que causará frustração e desânimo.

Ao considerar um objetivo como “atingível”, não se deve pensar somente em “possível” ou “impossível”, e sim nos diversos aspectos que o afetam. Por exemplo:

• Nossa equipe e liderança têm as habilidades necessárias para atingir esta meta? Se não, há um plano de treinamento e desenvolvimento?
• Nossos produtos ou serviços possuem a qualidade necessária para tornar a meta realidade?
• Existe um potencial real no mercado que permita a definição deste objetivo?

Na prática, as perguntas para cada objetivo serão diferentes, mas o importante aqui é entender que a meta deve considerar os diversos aspectos do negócio, e não seguir somente o ideal de um chefe que não está observando a realidade.

O A também é algumas vezes chamados de “Agreed Upon” (feito em comum acordo). Isto significa que todos os envolvidos na definição e execução do objetivo o conhecem e estão de acordo com sua viabilidade e benefícios.

R – Realistic (Realista)

Muitas vezes o objetivo é possível, mas não é realista. Ao considerar o realismo, você deve pensar em fatores como:

• A equipe aceitará perseguir o objetivo?
• Este objetivo está alinhado com a missão e visão da organização?
• Algum princípio ético é ferido com este objetivo?

Por exemplo, o objetivo “Reduzir em 30% o gasto com planos de saúde” pode ser atingido simplesmente mudando a categoria dos planos dos funcionários para um nível inferior. No entanto, este não seria um objetivo realista em uma organização que historicamente sempre se preocupou com o bem-estar dos funcionários e não passa por nenhuma dificuldade financeira que justifique estes cortes.

Um líder que define um objetivo pouco realista está fora de sincronia com a empresa e com sua equipe.

T – Timely (Em Tempo)

Esta característica se mistura um pouco com o S (específico). Significa que além do inicio e fim do período de busca do objetivo serem bem definidos, este período não deve ser tão curto que torne o objetivo impossível nem tão longo que cause uma dispersão da iniciativa com o tempo.

O T também pode ser “Tangible” (Tangível). Isto quer dizer que um objetivo que possa ser sentido, observado ou tocado terá maior chance de ser realizado. Tudo o que melhora o dia a dia da equipe será visto com melhores olhos e os incentivará.

MPS.BR é a sigla de Melhoria de Processos do Software Brasileiro, modelo este que foi criado pela Softex e patrocipado pelo MCT. Mas o que é isso afinal de contas?

O MPS.BR é uma adaptação para as empresas brasileiras – em especial micro, pequenas e médias empresas – de um modelo de maturidade de processos de desenvolvimento de software conhecido internacionalmente como CMMI-DEV.

Muito se fala sobre esses modelos. Mas, após pesquisar exaustivamente sobre o assunto, cheguei a uma triste conclusão: Todo o material carece de clareza. Assim como o CMMI, há muito “diz-muito-sem-dizer-nada”. Inclusive, os próprios guias de implementação desses modelos são confusos. Para ajudar, em grande parte de nossas universidades, aprende-se o básico. A maioria delas forma programadores e não analistas ou arquitetos.

Com base neste e outros pontos resolvi tentar desmistificar esse assunto. Como estou no Brasil, nada mais lógico do que começar pelo MPS.BR, mas vale lembrar que o mesmo vale para o CMMI.

Pensei em escrever esse artigo de diversas formas e cheguei à conclusão que a melhor seria por meio de perguntas e respostas. Não que você já se tenha feito essas mesmas perguntas (o material disponível sobre o assunto é confuso e muitos não chegam nem no nível da dúvida). Mas as perguntas nos ajudam a raciocinar e esclarecer o assunto.

Este primeiro artigo é apenas uma breve introdução sobre o MPS.BR de forma geral.

O que é o MPS.BR

É um modelo de maturidade de processos relacionados com o desenvolvimento de software. Esse modelo foi adaptado de um outro modelo conhecido internacionalmente (e de muito sucesso) como CMMI-DEV para a realidade das empresas brasileiras. Isso foi necessário por que o CMMI-DEV prevê o amadurecimento dos processos em apenas cinco níveis. E, com o tempo, percebeu-se que a coisa tinha de funcionar de forma mais gradual aqui no Brasil. Daí quebraram os cinco níveis do CMMI-DEV em sete, que vão do G ao A, e fizeram alguns pequenos ajustes.

O que é um modelo de maturidade de processos?

Toda empresa ou indivíduo que desenvolve software já faz isso por meio de algum processo. Esse processo pode ser caótico, obscuro e até mudar constantemente, mas não deixa de ser um processo. E isso nada mais é do que uma seqüência de atividades. Mesmo que você não se dê conta disto, tudo que você faz no trabalho de desenvolvimento de software segue uma seqüência de atividades. Às vezes essa seqüência não é fixa. Às vezes essa seqüência não segue uma ordem lógica. Às vezes essa seqüência provoca algum retrabalho. Mas perceba que sempre existirá uma seqüência. Às vezes essa seqüência já é eficiente, mas ninguém mais além de você sabe como funciona. Um modelo de maturidade de processos serve para corrigir esses e muitos outros problemas.

O MPS.BR descreve um modelo de amadurecimento gradual dos processos de desenvolvimento de software. Ou seja, você não precisar melhorar tudo de uma vez. Pode fazer isso aos poucos, de forma gradual. É para isso que servem os níveis de maturidade.

Vale ressaltar que o MPS.BR é apenas um modelo. Ninguém é obrigado a segui-lo a risca. Mas… ele é uma coletânea das melhores práticas relacionadas com o desenvolvimento de software. Assim, talvez valha a pena considerá-lo se não no todo, mas em parte. Entretanto, como ele é uma adaptação do CMMI-DEV, essas melhores práticas foram coletadas em outros mercados como EUA e Europa principalmente. E isso pode por em dúvida a aplicabilidade dessas supostas melhores práticas a nós, brasileiros. Essa dúvida, porém, só o tempo poderá dirimir.

O que é um processo maduro?

Ótima pergunta!
Dizer que um processo é, ou não, maduro pode gerar muita polêmica. Um processo é maduro quando ele é previsível, é estável e atinge os resultados esperados – poderiamos adicionar o baixo custo, mas isto normalmente é consequência. Mas a dificuldade é justamente medir os resultados e o custo pois em nossa área não há muito a cultura de se trabalhar com dados e as decisões são tomadas muitas vezes com base em percepções e não em resultados.

Portanto, para saber se um processo é ou não maduro, precisamos primeiro conseguir medi-lo. E é justamente esse a base para o objetivo final do MPS.BR: conseguir medir o desempenho dos processos, predizer seu comportamento futuro e melhorar sempre. Em teoria, uma empresa no Nível A do MPS.BR conhece plenamente o desempenho de seus processos e os fatores que os influenciam. Ao descobrir que um processo qualquer não é maduro, cabe à empresa encontrar formas de amadurecê-lo DE FATO, mas isto acontece fortemente no MPS.Br nível B – até chegar à ele você (vamos dizer) organiza a casa.

Na prática, as empresas já terão subsídios para amadurecer os processos desde o Nível F. Ou seja, não se precisa esperar até o Nível A para tomar alguma ação corretiva, elas podem (e devem) ser tomadas desde os níveis iniciais.

Que ações a empresa precisa tomar? O MPS.BR não diz. Ainda bem!

E para que um processo possa ser medido e corrigido ele precisa ser transparente, medido e gerenciável. Tudo gira em torno disso. Se um processo não é transparente, então não pode ser medido. Se não pode ser medido, então não temos como saber se os seus resultados são os melhores possíveis a um determinado custo. Se um processo não é gerenciável, mesmo que se possa medi-lo, então não se pode corrigi-lo, melhorá-lo. Se não podemos melhorá-lo, não podemos amadurecê-lo. Essa é a lógica da coisa toda.

Maduro para quem?

Maduro para todo mundo, ora bolas!, mas especialmente para as gerências e alta direção. Lembre-se: quando vir a palavra maduro, pense em transparente, medido e gerenciável. Nunca esqueça isso.

Porque meu gerente está especialmente interessado nisso?

Lembra do transparente, medido e gerenciável? Pois é. Se o processo é transparente, o seu gerente sabe exatamente o que você está fazendo ou deve fazer e o que você pode fazer. Sabe se você está enrolando o serviço. Sabe se você precisa de ajuda para cumprir o prazo. Pode até conferir o que você já produziu.

Se o processo é gerenciável, o seu gerente pode aproveitar o que você já produziu e te substituir por outra pessoa para que você toque outra atividade. Pode colocar mais alguém para te ajudar. E pode até pedir para você refazer algo antes que seja tarde demais.

Quando o processo é transparente, ele deixa de ser aquela caixa preta que ninguém além de você sabe como funciona.

Quando o processo é transparente, fica mais fácil saber quais são os bons funcionários e quais não são. Fica mais fácil premiar o bom desempenho. Um processo maduro depende menos dos indivíduos. E também fica mais fácil identificar quem só esta fazendo marketing e não esta trazendo resultados.

Ah, então devo me preocupar com o meu emprego?

Sim e não.

Se você é um mau funcionário, o MPS.BR vai deixar isso mais evidente pois, como já falei, os processos vão ficando cada vez mais transparentes. Mandar-te embora é uma decisão do seu gerente – o MPS.BR não obriga nenhuma empresa a fazer isso!

Acontecerá justamente o contrário se você for um ótimo funcionário. O MPS.BR vai deixar isso mais evidente e, talvez, você seja até promovido. Na pior das hipóteses, você vai continuar se destacando como bom funcionário. Note que o MPS.BR pretende tornar os processos menos dependentes de indivíduos. Repito: indivíduos. Todo processo sempre dependerá de uma boa equipe. E bons gerentes escolhem bons funcionários para as suas equipes. Ou seja, se é bom funcionário, está dentro!

Ok, mas onde entra a documentação nisso tudo?

Sabia que você ia tocar nesse assunto. Após a implementação do MPS.BR, seja qual for o nível, não é raro os desenvolvedores reclamarem da quantidade de documentação que eles precisam produzir. Esse problema, contudo, varia de empresa para empresa.

O MPS.BR não obriga nenhuma empresa a produzir os artefatos A, B ou C. Na verdade, ele não te obriga a ter um único documento. Você precisa sim ter evidências de que realizou determinadas atividades, mas isto pode ser provado de várias formas.

Algumas empresas utilizam formulários de preenchimento manual, outras utilizam ferramentas onde o preenchimento é quase automático e outras como as com modelos SCRUM usam métodos totalmente diferentes. Se você não está contente com a forma como alguns artefatos são produzidos, procure a área responsável e sugira melhorias. O MPS.BR só é viável se todos se comprometerem com o modelo. Se isso não está acontecendo na sua empresa, a alta direção deveria promover isso com incentivos concretos. Só treinamento não basta.

Para que serve essa documentação toda?

Já que você insiste no assunto, vamos lá! Pessoalmente, também não sou muito fã desses artefatos. Mas acredito que sempre há uma forma mais fácil e simples de produzir a documentação implícita no MPS.BR.

Outro problema é que normalmente a gente só sente falta de um determinado documento em uma situação de conflito. Imagine a situação onde você fechou com o cliente que o relatório de vendas vai ser apresentado como uma página web comum. Quando você chega na validação ele comenta que não era nada disso e que o que ele tinha pedido era um relatório com opção para imprimir, com paginação e que permitisse exportar para excel e tivesse um pivot table. Se você não documentou o primeiro pedido imagine de quem será a culpa pelo prejuizo?

Mas em linhas gerais, essa documentação toda serve para tornar o processo mais transparente e segurança para ambos os lados.

Ouvi dizer que tudo precisa ser um projeto; isso é verdade?

Sim e não.

Mas isso não deve ser problema. Você pode aplicar o MPS.Br em Projetos e demandas contínuas como fábrica de código, testes, especificação, etc. Mas mesmo estes trabalhos de demandas contínuas podem ser chamados de projetos. Chego até a dizer que mudando um pouco a terminologia de Software, podemos aplicar o MPS.Br em diversas outras áreas.

Mas… voltando a projeto: O que é um projeto afinal de contas? Projeto é um trabalho com escopo, custo, início e fim determinados e normalmente ele cria algo único. Mas isso é óbvio! E na verdade tudo que é desenvolvido é algo novo. Se não é novo, já existe e, portanto, não precisa ser feito. Logo, o que precisa ser feito é sempre algo novo em menor ou maior escala. Pense sobre isso. Tirando a correção de erros, TUDO é novo no desenvolvimento de software.

Assim, perceba que não faz diferença chamar o seu trabalho de projeto. Concordo que é um erro do MPS.BR exigir uma rotulação para os trabalhos. Mas, já que não faz diferença, o que custa atender?

Ah, mas um projeto é mais burocrático…

Novamente, sim e não. Como já disse, tudo depende da sua empresa. Algumas atividades são necessárias não por simplesmente existir um projeto, mas por que o processo precisa ser transparente e gerenciável. Nunca esqueça disso.

Preciso de alguma ferramenta?

Não. Mas o uso de algumas fica implícito no MPS.BR. Ou seja, não é algo obrigatório, mas muitas vezes é desejável. Lembre-se que as ferramentas existem para agilizar os trabalhos, reduzindo o tempo e consequentemente o custo.

Como exemplo, você pode fazer um controle de configuração através de uma estrutura de diretórios no windows, com (por exemplo) pastas e mudanças nos nomes dos arquivos. Isto vai levar um determinado tempo para fazer e consequentemente um custo. Já se você colocar uma ferramenta para apoio como SVN, Sharepoint ou até mesmo o Source Safe você economizará no mínimo metade do tempo (e consequentemente metade do custo).

O que a empresa ganha com isso?

Relacionados ao MPS.Br há poucos estudos, todavia se olharmos o CMMI (que é a mesma coisa) podemos ver que normalmente as empresas aumentam significativamente sua produtividade, assertividade nas estimativas, aumentam a satisfação de seus clientes, reduzem consideravelmente os custos e aumentam a qualidade de seus produtos. Estes mesmos estudos indicam que o retorno do investimento ocorre rapidamente.

Conheço quase 15 casos aqui no Brasil de implementações com MPS.Br e posso dizer que os patrocinadores estão muito contentes com os resultados obtivos e estão buscando os níveis posteriores pois perceberam que “valeu a pena”.

Conclusão

Este texto é apenas uma breve introdução ao assunto.
Vimos que o MPS.BR (e por extensão o CMMI) não é esse bicho de sete cabeças que as pessoas imaginam. A chave de tudo, na minha opinião, é a transparência e gestão do processo – com a conseqüente medição.

[Adaptado do texto de Samuel Diniz]

Olá pessoal, em TI a cada dia cria-se um novo termo e sempre fica a dúvida “O que é isso?”. Bom, como situações como esta são muito comuns, resolvemos compilar uma lista dos termos mais comuns.

Glossário de termos comuns em TI

Ação Corretiva
Ação realizada para eliminar um problema, não conformidade ou situação indesejada a fim de evitar sua repetição.

Ação Preventiva
Ação realizada evitar a ocorrência de um possível problema, não-conformidade ou defeito.

Agile
Modelo de desenvolvimento de software focado nas pessoas. Não há processos definidos, guias ou instituto certificador. A motivação e o cliente são aspectos primordiais nos métodos ágeis, todavia, praticar Agile é mais uma questão de cultura do que guias e processos.

Análise Crítica de Projeto
Análise completa e sistemática de um projeto a fim de avaliar sua capacidade de atender os requisitos para a qualidade, identificar problemas, se houver, e propor o desenvolvimento de soluções.

Análise de Pontos por Função
Técnica de estimativa de sistemas, também conhecida como FPA – Function Point Analysis, baseada na identificação das funções executadas pelos programas, ao invés de utilizar como base o volume ou a complexidade do código dos programas.
A técnica está baseada na visão externa do usuário, sendo portanto, independente da linguagem utilizada, permitindo calcular o esforço de programação e auxiliando o usuário final a melhorar o exame e avaliação de projetos.

Análise de Requisitos
Conjunto de atividades que permite identificar as necessidades do usuário de modo a obter uma definição clara das características (requisitos) de um sistema. Essas características descrevem o sistema em termos de funcionalidades, desempenho esperado, restrições de projeto, níveis de qualidade esperados, interface com outros elementos do sistema.

Auditoria
Verificação sistemática e independente, para determinar se as atividades da qualidade e seus resultados estão de acordo com o planejado, se foram implementadas com eficácia e se são adequadas.

Certificação
Modo pelo qual uma organização independente dá garantia escrita de que um produto, processo ou serviço está em conformidade com os requisitos especificados.

CMMI – Capability Maturity Model Integration
Modelo para avaliação da maturidade dos processos de software de uma organização e para identificação das práticas chave que são requeridas para aumentar a maturidade desses processos.

Confiabilidade
Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido.
Tem como subcaracterísticas: maturidade, tolerância a falhas e recuperabilidade.

Configuração
Relação entre versões de um objeto, ou seja, configuração é uma instância do sistema composta da união de uma versão específica de cada objeto componente. Arranjo de um sistema ou de seus componentes como definidos pelo seu número, natureza e interconexão de suas partes constituintes.

Controle de Versão
Procedimento de gestão do ciclo de vida de um produto. Consiste na identificação formal de modificações solicitadas ou efetuadas e no seu agrupamento, de modo a que fiquem incorporadas, todas elas, em uma determinada configuração do produto, num certo momento. Essa configuração recebe o nome de versão.

Custos da Qualidade
Custos relacionados com as perdas em função da qualidade insuficiente de processos, produtos ou serviços (custos da não-conformidade) ou com os investimentos em atividades que eliminem falhas ou elevem a qualidade de processos, produtos ou serviços (custos da conformidade). A identificação e a apropriação contábil desses custos permite que o administrador possa fazer uma análise do nível de qualidade de sua produção e possa tomar decisões para melhorar esse nível.

Declaração de Conformidade
Declaração, emitida pelo fornecedor ou pelo produtor de um software, assegurando que este opera em conformidade com certas normas ou especificações preestabelecidas.

Depurador Interativo
Software para apoio a testes, cuja função é permitir a visualização passo a passo da execução de uma rotina ou programa e do comportamento de seus elementos antes, durante e após a execução.

Dicionário de Dados
Listagem organizada de todos os elementos de dados que são pertinentes ao sistema, com definições precisas e rigorosas, de forma que tanto o usuário como o analista de sistemas tenham uma compreensão comum das entradas, das saídas, dos componentes dos depósitos de dados.

Driver de Teste
Software que permite a ativação de determinadas partes do software (módulos) com o intuito de testá-las. Normalmente, utilizam-se massas de teste previamente definidas e produzem resultados do teste, que podem ser verificados através da documentação de teste construída pelo analista ou engenheiro de software responsável pelos testes.

Eficiência
Conjunto de atributos que evidenciam o relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, sob condições estabelecidas. Tem como subcaracterísticas: comportamento em relação ao tempo e comportamento em relação aos recursos.

Engenharia da Informação
Popularizada por James Martin, é um caminho direcionado a dados para desenvolvimento de sistemas de informação, oposto à visão de direcionamento a processo de análise estruturada.

Entidade Certificadora
Órgão que realiza a certificação de conformidade, a partir da existência da garantia adequada de que um produto, processo ou serviço, devidamente identificado, está em conformidade com uma norma ou outro documento normativo especificado.

Garantia da Qualidade
Conjunto de atividades planejadas e sistemáticas, implementadas no sistema da qualidade e demonstradas como necessárias para prover confiança adequada de que uma entidade atenderá os requisitos para a qualidade.

Gerência de Projetos
Processo que tem início antes do trabalho técnico, prossegue à medida que o software se desenvolve do modelo conceitual para o modelo computacional e encerra somente quando o software se torna obsoleto.

Gerência de Requisitos
Estabelecimento e manutenção de um entendimento/acordo com o cliente sobre os requisitos para o projeto de software. Este acordo refere-se aos requisitos do sistema alocados para o software. O cliente pode ser interpretado como o grupo de engenharia do sistema, o grupo de marketing, outra organização interna, ou um cliente externo. O acordo compreende requisitos técnicos e não técnicos. O acordo forma a base para a estimativa, planejamento, execução e acompanhamento das atividades do projeto de software através do ciclo de vida do software.

Gerenciamento de Configuração (Software Configuration Management – SCM)
Atividade abrangente que é aplicada em todo o processo de engenharia de software, podendo ser vista como uma atividade de garantia da qualidade de software. Uma vez que uma mudança pode ocorrer a qualquer tempo, as atividades de SCM são desenvolvidas para identificar a mudança; controlar a mudança; garantir que a mudança esteja sendo adequadamente implementada; e relatar a mudança a outras pessoas que possam ter interesse nela. O gerenciamento de configuração de software é um conjunto de atividades que foi desenvolvido para administrar as mudanças em todo o ciclo de vida do software.

Gestão da Qualidade
Todas as atividades da função gerencial que determinam a política da qualidade, os objetivos e as responsabilidades, e os implementam por meios tais como: o planejamento da qualidade, o controle da qualidade, a garantia da qualidade e a melhoria da qualidade dentro do sistema da qualidade.

Gestão de Configuração
Atividade técnica e gerencial aplicada ao longo de todo o ciclo de vida do software que tem por objetivo garantir a integridade do produto sendo desenvolvido, mantendo um histórico de todos os itens sob controle. Basicamente, é composta de quatro tarefas: identificação da configuração, controle da configuração, balanço da configuração e auditoria da configuração.

ISO
International Organization for Standardization (Organização Internacional de Normalização).

ISO 9001
Quality systems – Model for quality assurance in design, development, production, installation and servicing.
Norma internacional da série ISO 9000. Modelo para garantia da qualidade em projetos, desenvolvimento, produção, instalação e serviços associados.É mais completa que as normas ISO 9002 e ISO 9003, da mesma série.

ISO/IEC 12207
Information technology – Software life cycle process.

ISO/IEC 15504
Information technology – Software process assessment.
Norma internacional para avaliação de processos de software, deselvolvida pelo projeto SPICE (Software Process Improvement and Capability dEtermination), o que a torna conhecida também como Modelo SPICE. Define um modelo de referência com processos e níveis de capacidade, orientações sobre como utilizá-lo para melhoria contínua ou determinação da capacidade, e um modelo exemplo compatível .

Lead Appraiser
Avaliador oficial SEI. Responsável por avaliações oficiais CMMI. Há também o High Maturity Lead Appraiser, que é o avaliador que pode realizar avaliações CMMI 4 e CMMI 5.

Medição de Linhas de Código (LOC)
É a métrica de código mais básica. A definição mais comum de LOC estabelece que qualquer linha do programa que não seja comentário ou linha em branco, independente do número de sentenças (lógicas ou operações) estão presentes naquela linha.

Melhoria de Processos de Software (Software Process Improvement)
Uma abordagem (SPI) para melhoria das organizações que desenvolvem e mantêm software. É baseada na melhoria da capacidade de processos fundamentais para organizações de software. Utiliza como referência um modelo de processo, como por exemplo, o CMM e a ISO/IEC 15504-SPICE.

Métrica de Qualidade de Software
Método e uma escala quantitativa que podem ser usados para determinar o valor que uma particularidade (feature) recebe em um produto de software específico.

MPS.Br
Modelo de melhoria de processos de software brasileiro muito similar e aderente ao CMMI porém com algumas diferenças como 7 níveis e novas áreas de processo (chamado pelo MPS.Br apenas por processo).

Peer-review
Técnica de revisão de um produto, na qual um colega (peer) do projetista ou do programador revisa o produto desenvolvido, buscando encontrar erros ou oferecer sugestões de melhoria.

Política da Qualidade
Intenções e diretrizes globais de uma organização relativas à qualidade, formalmente expressas pela alta administração.

Processo
Conjunto de recursos e atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas). Agrupamento em seqüência de todas as tarefas destinadas a obter um determinado resultado. É a combinação de equipamentos, instalações, mão-de-obra, métodos, técnicas, ferramentas, procedimentos e outros fatores, com a finalidade de elaborar um produto ou alcançar um resultado preestabelecido.

Processo de Software
Conjunto de atividades, métodos, práticas e transformações que as pessoas empregam para desenvolver e manter software e os produtos associados (por exemplo, planos de projeto, documentos de projeto/design, código, casos de teste, manual do usuário).

Programação Orientada a Objetos
Técnica de programação que enfatiza a descrição dos conceitos envolvidos com o domínio do problema (objetos) através de seus dados e operações, encapsulados e representados através de classes. Cada objeto é criado como pertencendo a uma classe. A utilização de um objeto, e sua eventual mudança de estado, se dá a partir de mensagens enviadas a ele, representadas pelas operações encapsuladas na classe. Novas classes podem ser criadas a partir de classes existentes e organizadas através de um processo de classificação e hierarquização, explorando o conceito de herança.Os programas são construídos como organizadores da ativação de mensagens para os objetos, desta forma fazendo com que as funcionalidades de um sistema sejam obtidas através da cooperação dos objetos.

Projeto de Software
Envolve tipicamente análise, especificação, projeto (design), desenvolvimento, teste e/ou manutenção dos componentes de software e da documentação associada.

Prototipação
Método de desenvolvimento que prevê a execução de vários ciclos de análise, especificação e codificação de um sistema.No primeiro ciclo, gera-se um produto simplificado em pouco tempo, de modo que o usuário possa examiná-lo e refinar as suas demandas.Nos ciclos seguintes, o produto é aperfeiçoado e novas funções são sucessivamente implementadas, até se chegar ao produto final.

QFD – Quality Function Deployment
Técnica de planejamento e de especificação de requisitos que consiste em reuniões com técnicos e clientes, nas quais são elaboradas matrizes em que se cruzam informações sobre “o que” é desejado (requisitos) e “como” implementar. É composta por quatro etapas – projeto, componentes, processo e produção, sendo gerada a cada etapa uma matriz, a partir da matriz anterior.As matrizes explicitam relações, conflitos, níveis de dificuldade, estágio tecnológico. Por seu formato peculiar, a matriz do QFD é conhecida como “casa da qualidade”.

Qualidade
Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas. Entidade pode ser uma atividade ou um processo, um produto, uma organização ou uma combinação desses.

Reengenharia de Software
Técnica de restruturação ou modificação de um código existente, ou de desenvolvimento de um novo código, preservando-se inalterada a especificação ou o projeto do software.

Requisitos
Necessidades básicas do cliente, geralmente explicitadas como condição de negócio no contrato com o fornecedor. São características, tais como especificações técnicas, prazo de entrega, garantia, que o cliente “requer” do produto. Uma condição ou capacidade necessitada por um usuário, para resolver um problema ou alcançar um objetivo.

Requisitos para a Qualidade
Expressão das necessidades ou sua tradução num conjunto de requisitos, explicitados em termos quantitativos ou qualitativos, objetivando definir as características de uma entidade a fim de permitir sua realização e seu exame.

Reuso de Código
Técnica de utilização de um programa, de uma rotina ou de uma biblioteca de rotinas em mais de uma aplicação, ou em diferentes implementações de uma aplicação. Para tal, o código deve ser escrito prevendo-se a sua reusabilidade e enfatizando aspectos de sua abrangência funcional e de independência de ambiente.

SPICE – Software Process Improvement and Capability dEtermination
Projeto estabelecido em junho de 1993 pela ISO/IEC JTC1/SC7 (Subcomitê de Engenharia de Software) com três objetivos principais: auxiliar o desenvolvimento de uma Norma Internacional para avaliação de processos de software; coordenar e analisar utilizações desta futura Norma para subsidiar revisões antes de sua publicação como norma (esta atividade é chamada de SPICE Trials); e disseminar a futura norma no mercado. A norma desenvolvida é a ISO/IEC 15504 que está publicada atualmente com relatório técnico da ISO/IEC. Já foram realizadas duas fases do SPICE Trials, com dados sobre cerca de 100 utilizações da futura norma e a fase 3 está em andamento.

Six Sigma
Modelo para melhoria de processos com base em dados e fatos. Utiliza o método DMAIC e é largamente usado por toda industria. É pouco utilizado em TI, normalmente é praticado nas organizações de alta maturidade.

Teste de Aceitação
Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais.Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

Teste de Campo
Verificação de um software ou um trecho de software durante a sua utilização real (em campo), de modo a detectar, confirmar ou examinar falha ou erro relatado.

Teste de Integração
Técnica sistemática para a construção da estrutura de programa, realizando-se ao mesmo tempo, testes para descobrir erros associados a interfaces. O objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi determinada pelo projeto. O teste de integração cuida das questões associadas aos duplos problemas da verificação e construção de programas.

Teste de Sistema
Processo de testar um sistema integrado de hardware e software para verificar se o sistema satisfaz seus requisitos especificados.

Teste de Unidade
Verificação de um componente de um software, através de teste funcional, desenvolvido a partir da especificação das funções previstas para o componente, ou de teste estrutural, desenvolvido a partir da descrição da estrutura do componente.

Teste de Usabilidade
Verificação e homologação individual do uso por um conjunto de usuários.

Teste Funcional
Teste conduzido para demonstrar a operacionalidade das funções que foram especificadas. O teste funcional (ou caixa-preta) é realizado olhando-se o software apenas através de suas interfaces, portanto testando sua funcionalidade.

Validação
Confirmação, por exame e fornecimento de evidência objetiva, de que os requisitos específicos para um uso pretendido são atendidos. Informações cuja veracidade pode ser comprovada com base em fatos obtidos através da observação, medição, ensaios ou outros meios constituem evidência objetiva.

Verificação
Confirmação, por exame e fornecimento de evidência objetiva, do atendimento aos requisitos especificados. Processo de avaliação de um sistema (ou componente) com o objetivo de determinar se o produto de uma dada fase do desenvolvimento satisfaz às condições impostas no início dessa fase.

Walkthrough Estruturado
Técnica de análise estática na qual um projetista ou programador apresentam aos membros do grupo de desenvolvimento e outros profissionais interessados uma parte de documentação ou código, e os participantes fazem perguntas e comentários sobre possíveis erros, violação de padrões de desenvolvimento ou sobre outros problemas

De tanto debatermos o tema “Geração Y”, podemos encontrar uma lista imensa de características e rótulos que já viraram clichê. Boa parte do que circula no tal senso comum é dito por quem não faz parte do grupo em questão, mas nossa geração se posiciona e participa desse debate defendendo nosso ponto de vista, principalmente na internet.

É curioso visitar sites, blogs e fóruns aonde jovens conversam, comentam, questionam e trocam idéias com autores e executivos, quase de igual para igual, mas você já fez isso com o seu gestor?

Tenho percebido que o mundo digital proporciona uma proximidade que às vezes não temos no dia a dia. Se você segue o Twitter de uma pessoa que admira, você praticamente se insere na rotina dela, e se permite retwittá-la ou mandar mensagens (sabendo que será lida). Quando você está na internet é como se estivesse aberto a ser visto, comentado e pronto para interagir.

Toda essa introdução sobre o relacionamento que a internet permite construir é para fazer um paralelo com o tema central desse texto: como é o relacionamento com o seu gestor? É tão próximo como o que você tem com aqueles que você segue no Twitter ou nos blogs que acompanha?

Talvez a internet atraia os jovens exatamente porque permite com muito mais facilidade criar relacionamento e, definitivamente, a Geração Y necessita se relacionar. Crescemos em redes e não deve ser surpresa para ninguém que uma tarefa seja muito mais agradável quando é solicitada por alguém que temos algum outro tipo de ligação.

Ok, isso se aplica a qualquer pessoa, mas nos Y essa característica é mais acentuada. Se o relacionamento com o seu gestor é distante e se limita ao que “deve ser feito”, a produtividade pode ser boa, mas não será excepcional.

O contexto que em a Geração Y está inserido é muito maior que apenas o trabalho. Queremos qualidade de vida e valorizamos muito o que podemos fazer depois do horário comercial. Perceber que o emprego não é tudo para nós, é fundamental no relacionamento com os gestores.

Se o chefe percebe isso, dá abertura e cria um relacionamento saudável, será muito mais fácil envolver o funcionário, motivá-lo, além de ser mais simples compreender nossa intensa necessidade por feedback e flexibilidade.

Ah! E se alguém ainda não percebeu que um bom relacionamento é a base para gerar comprometimento e também uma poderosa ferramenta de retenção, talvez seja a hora de rever seus conceitos sobre Geração Y, não?

Artigo de Liliane Fonseca.

Treinamento
O Coaching não se propõe a transferir conhecimento entre as partes. O que ocorre é o desenvolvimento de habilidades intrínsecas do cliente.

Mentoring
O mentor possui uma determinada expertise técnica e orienta um profissional a seguir uma determinada linha de conduta.

Consultoria
O consultor faz uma análise do cenário, tira conclusões e apresenta propostas de soluções ao cliente.

Aconselhamento
O aconselhador propõe de forma direta uma solução para alguém…

Diferente de tudo isso, o Coaching não dá o caminho das pedras; não tira conclusões nem apresenta soluções; não faz julgamentos; não induz o cliente a tomar qualquer decisão ou

atitude …

O papel do Coach é levar o Coachee (cliente) a profundas reflexões que o possibilita encontrar as respostas que lhe são mais adequadas. Afinal, cada ser humano é diferente um do outro e o “cérebro é uma máquina sem manual de operação”.

Ao contrário da psicologia, o Coaching não se preocupa com eventos do passado para explicar traumas, bloqueios ou mágoas. O foco está no presente e no futuro, ou seja, o importante é “plantar” hoje para “colher” no mesmo dia ou no futuro.

No Coaching, só existe um motivo para observar o passado: obter aprendizado para fazer diferente e melhor no futuro.

Em suma, o que importa é foco + ação + resultado + melhoria contínua.

[Alexandre]

Coaching…
Este é de longe o melhor método para adquirir conhecimento e melhorar o desempenho. Você realmente absorve muito conhecimento em pouco tempo e apesar de ser aparentemente mais caro, o investimento vale a pena.

Hoje em dia, se alguém me pergunta “o que fazer para aprender algo rápido” ou “como melhorar o desempenho pessoal” eu sempre recomendo coaching.

E o mesmo vale para programas de melhoria de processos. O coaching é um dos melhores aceleradores pois seu objetivo é maximizar o potencial humano de uma pessoa ou grupo permitindo maior auto-estima, auto-conhecimento, auto-confiança e geração de melhores resultados por meio de acompanhamento de um profissional.

A pessoa ou grupo que recebe o coaching é chamada de Coachee, já a pessoa que vai passar o conhecimento, treinar o coachee, se chama Coach (como técnico em inglês).

O objetivo do coach é melhorar o desempenho do coachee, logo ele se abstém de qualquer tipo de julgamento e conduz seu cliente a um estado mental acentuado de reflexão e descobertas.

O coaching tem foco em resultados, alcance de objetivos profissionais e até mesmo pessoais. Alguns dizem que coaching é consultoria, terapia, aconselhamento e até mesmo auto-ajuda, mas não é isso. Ele lhe ajuda a melhorar você mesmo, focar, priorizar e atingir resultados positivos.

No campo profissional, o coaching tipicamente foca no desenvolvimento de carreira, formação de executivos e melhoria de negócios. Já no campo pessoal, ele trabalha aspectos emocionais, sociais, físicos e mentais entre outros ajudando-o a transformar seus sonhos em realidade (e atingir seus objetivos pessoais).

Quer alguns exemplos práticos? Vamos ver onde o coaching te ajudaria:

• Aprender um outro idioma
• Tirar uma certificação (PMI, Java, etc)
• Melhorar o desempenho de uma determinada equipe de sua empresa
• Melhorar e uniformizar o desempenho dos gerentes
• Desenvolver sua carreira
• Implementar um novo método (Agile, CMMI, Six Sigma, etc)
• E diversos outros.

Enfim, com coaching você ganha tempo e consegue transformar seus sonhos em realidade.

Pergunta: Não consigo compreender o que é a tal da rastreabilidade bi-direcional e pra que ela serve. Você pode me ajudar?
- Mary Senko de São Paulo

Resposta: Primeiramente vamos entender que não existe um, mas três tipos de rastreabilidade:

• Rastreabilidade vertical
• Rastreabilidade horizontal
• Rastreabilidade bi-direcional

O que é a rastreabilidade bi-direcional é uma dúvida muito comum. É um assunto largamente discutido na comunidade de engenharia de software e cada um tem uma opinião (normalmente diferente).

A rastreabilidade nos ajuda a entender o relacionamento entre os produtos de trabalho, quer sejam eles especificações de requisitos, código, arquitetura, testes e vários outros, e nos ajuda a garantir a integridade entre estes elementos.

Para requisitos, a ratreabilidade nos ajuda a entender a relação entre os requisitos definidos pelo cliente e os produtos como especificações, protótipos, testes e até o produto final.

A capacidade de se iniciar do topo e rastrear todo o caminho até chegar aos seus casos de testes, ou começar por um determinado caso de testes e segui-lo até o topo é o que chamamos de rastreabilidade bi-direcional. Este também é um exemplo de rastreabilidade vertical e é também o que esta implícito em rastreabilidade de requisitos no CMMI.

Se você é um engenheiro de software, pense nele como um objeto. O objeto master tem abaixo dele vários outros objetos que o “apoiam” diretamente e herdam seus atributos e métodos e estes podem ser rastreados em conjunto como parte da taxonomia do objeto. O mesmo vale para os requisitos.

Já a rastreabilidade horizontal é menos comum (embora igualmente importante), e aplica-se ao rastreamento de funcionalidades através dos múltiplos componentes relacionados tais como interfaces ou componentes de acesso a dados, e ajuda a ser mais eficaz em testes de integração, solução de problemas e implementação.

Imagine o cenário onde você ganhou um contrato de manutenção de 100 sistemas de um banco. Neste contrato, não há muita documentação sobre os sistemas (o que quase nunca acontece), e solicitações vão chegando e você precisa alterar os programas dos sistemas. Se você não souber qual o impacto que uma alteração terá nos diversos outros sistemas da empresa, então é melhor nem continuar, pois o estrago será grande. Neste mesmo cenário, se você tiver como saber qual a relação entre os mais diversos produtos, e sistemas, o risco será bem menor e consequentemente o custo para a empresa.

A maioria parece concordar que a rastreabilidade vertical é o que REQM SP1.4 espera do modelo e que a rastreabilidade horizontal, embora valiosa, não é especificamente esperada pelo CMMI.

Enfim, rastreabilidade nasce já em momento de proposta e vai evoluindo ate chegar ao final do projeto com os (vamos chamar assim) termos de aceite.

Envie-nos suas perguntas!

O que são mapas mentais

Mapa Mental (Mind Map) é um diagrama usado para representar palavras, idéias, tarefas ou outros itens ligados a um conceito central e dispostos radialmente em volta deste conceito. É um diagrama que representa conexões entre porções de informação sobre um tema ou tarefa. Os elementos são arranjados intuitivamente de acordo com a importância dos conceitos. Eles são organizados em grupos, ramificações ou áreas.

Pela representação das informações e suas conexões de uma maneira gráfica, radial e não linear, o Mapa Mental estimula a imaginação e o fluxo natural de idéias livre da rigidez das anotações lineares (listagens).

O Mapa Mental explora o fato de que nosso cérebro:

• Não trabalha de forma linear, mas pula de uma idéia para outra, de forma aleatória, seguindo as associações que vai descobrindo;
• Processa melhor, memoriza e relembra mais facilmente informações que combinam palavras, números, ordem e seqüência com cores, imagens, dimensões, símbolos e ritmo visual.

Quando usar mapas mentais

O Mapa Mental é usado para gerar, visualizar, estruturar, e classificar idéias e como uma ajuda na pesquisa e organização de informações; planejamento de projetos, campanhas, cursos, livros, artigos e outras tarefas; solução de problemas e tomada de decisão, etc.

Apresenta muitas vantagens sobre as anotações na forma de listas:

• A idéia principal é definida com mais clareza. Ela é colocada no centro do gráfico.
• A importância relativa de cada idéia é claramente indicada; quanto mais perto do centro, mais importante.
• As conexões entre conceitos são imediatamente reconhecidas.
• As revisões são mais efetivas e mais rápidas.
• Fácil inclusão de novas informações.
• A natureza aberta do gráfico estimula o cérebro a fazer novas conexões.

Mapa mental feito na ferramenta Mind Node

Como usar um Mapa Mental em 6 passos

1. Comece pelo centro. Pegue uma folha de papel e desenhe no seu centro uma palavra ou imagem que represente o assunto sobre o qual você irá pensar.

2. Em volta do assunto central coloque os principais temas ligados ao tema central.
Estes temas podem ser comparados aos títulos dos capítulos de um livro. São as idéias ordenadoras que definem os focos do Mapa Mental.

3. Use linhas para ligar estes temas ao assunto central.

4. Desdobre cada um destes temas principais em temas secundários e os conecte ao tema “mãe”.

5. Se necessário, desdobre estes temas secundários em novos temas e os conecte ao tema de origem.

6. Prossiga com os desdobramentos até atingir o nível de detalhamento necessário.

As regras e técnicas do Mapa Mental

• Sempre use uma imagem central.
• Use cores variadas.
• Use imagens, símbolos, formas, texturas, etc.
• Use variações de tamanho das letras, linhas e imagens.
• Mostre a hierarquia entre os diversos níveis de informação.

Não interrompa o fluxo de idéias

• Anote as idéias imediatamente, como ocorrem.
• Não pare para fazer julgamentos, continue pensando.
• Deixe para mais tarde os julgamentos, modificações e melhorias.

Mostre as associações

• Use setas para mostrar conexões dentro e entre ramificações.
• Use cores.
• Use símbolos.
• Use formas como triângulos, círculos, retângulos, etc.

Seja claro

• Organize o espaço e deixe áreas em branco para futuras inserções.
• Somente uma palavra chave por linha.
• Use letras de imprensa, pois são mais fáceis de ler e lembrar.
• Escreva as palavras ao longo das linhas.
• Comprimento da linha igual ao comprimento da palavra ou imagem.
• Linhas centrais mais grossas; a espessura diminui à medida que se afastam do centro.

Desenvolva um estilo próprio

• Defina um layout personalizado.
• No uso de recursos gráficos para mostrar hierarquia, semelhanças e conexões.
• Na combinação própria de cores, imagens, formas, dimensões, etc.
• Use sua criatividade e torne seus mapas mais alegres, coloridos e artísticos.

Recursos usados

Setas: podem ser usadas para mostrar como conceitos que aparecem em diferentes partes estão conectados. As setas podem ser simples ou com ramificações e podem apontar em qualquer direção.

Pontuação e símbolos: asteriscos, pontos de exclamação e de interrogação, cruzes e muitos outros símbolos podem ser agregados às palavras para mostrar conexões ou evidenciar alguma informação.

Formas geométricas: triângulos, círculos, elipses, retângulos, etc. podem ser usados para marcar áreas ou palavras que têm alguma semelhança.Por exemplo: triângulos podem ser usados para mostrar áreas de possíveis soluções para o problema analisado.

Objetos tridimensionais: cubos, cilindros, esferas, pirâmides, etc. para destacar alguma idéia ou informação.

Imagens criativas: para ressaltar a natureza ou especificidade de um tópico. Use as imagens disponíveis em seu micro ou na internet. Melhor, crie você mesmo as suas próprias imagens.

Cores: as cores são particularmente úteis para ajudar a memória e a criatividade. Podem ser usadas, como as setas, para mostrar como conceitos localizados em diferentes partes do gráfico se conectam ou se relacionam.
Elas também podem ser usadas para delimitar as fronteiras entre as grandes áreas do gráfico.

Marcio Krüger

Para o pessoal da geração Y, que não vê na hierarquia tradicional um modelo a ser seguido à risca, ter um novo chefe pode ser uma situação bastante complexa. Por mais títulos, experiência e credenciais que a pessoa possua, não é o bastante para conquistar o respeito e a admiração de alguém desta geração.

Muitos artigos e livros dizem que o pessoal da Geração Y precisa de um modelo para se espelhar. Alguém, gestor ou não, que os inspire a crescer e seja uma pessoal acessível e confiável. Eu concordo com essa afirmação e vejo que se aplica na minha vida. Fico feliz de ter alguém que eu admiro e posso contar para decisões profissionais, e para alcançar essa relação é preciso, além de um ótimo currículo, proximidade.

Essa geração tem o poder de mudar o foco como vivemos e trabalhamos. Basta procurar a inovação na forma de agir como um todo, não apenas onde você esta trabalhando

Quando se deparam com um novo gestor – aquele que irá acompanhar as atividades diárias e traçar as diretrizes para seu crescimento – mais do que uma pessoa que manda e toma decisões, é necessário alguém que cative, escute e de fato demonstre interesse em trabalhar junto. Isso pode soar um pouco paternal, e de fato é. Faz parte do “lado ruim” da Geração Y, que foi criada recebendo troféus por qualquer cama que fosse arrumada antes de ir para a escola.

Isso não quer dizer que os gestores devem ser babás, pelo contrário. Ninguém quer e nem gosta de ser tratado assim. Esse aspecto tem mais a ver com respeito, proximidade e confiança mútua, por parte do gestor em delegar e dar autonomia, e por parte do liderado que deve ter em seu líder uma fonte de respostas e também a tranqüilidade de questionar sem ser repreendido. Outro ponto interessante é que a geração líder segue de fato os líderes e podemos até dizer que despreza os chefes.

É muito interessante a questão das gerações dentro das empresas e quase sempre conclui-se que a resolução de conflitos e a construção de uma boa relação devem ocorrer pelo diálogo, com o esforço dos mais velhos para falar a língua da Geração Y e entender suas limitações. Isso exige muita maturidade dos mais jovens para perceber que o mundo já está pronto e que os Y devem se adaptar a ele.

O pessoal das gerações passadas deve entender as necessidades do pessoal da Geração Y é tipicamente diferente das suas. Enquanto o pessoal da geração passada fazia cursos de datilografia depois dos 12 anos, começava a aprender inglês depois dos 15 anos e visitava bibliotecas, o pessoal da Geração Y já sabia digitar, compreendia inglês e conhecia usava o cade e google para pesquisas. A geração Y nasceu com a Informação e eles processam mais informações que as gerações passadas. Seus valores são diferentes e os gestores devem compreender isto.

Agora fica a pergunta… a nova geração que entrará no mercado de emprego em 2020… como ela será?

[Adaptado de MinhaCarreira.com]

Você já deve ter se perguntado algum dia: “Em quanto à motivação da equipe interfere no desempenho de um projeto?”

De acordo com diversas pesquisas, posso dizer com confiança que ela interfere muito mais do que você acredita. A motivação da sua equipe pode ser o limiar entre o sucesso ou o fracasso de um projeto.

Se sua equipe esta desmotivada, é praticamente certo que você terá problemas em seu projeto. Dois meses atrás um amigo me procurou pedindo ajuda, pois na empresa onde ele trabalha aconteceram diversas ações organizacionais que desmotivaram sua equipe e conseqüentemente o projeto começou a afundar e a produtividade caiu pela metade. “É como se estivessem jogando contra” indagou o mesmo.

Em outro caso de outra empresa, uma implementação CMMI ficou estacionada e não saia do lugar porque as equipes “não estavam nem ai para o CMMI”. Isto fez a empresa gastar CINCO vezes mais o que ela havia planejado para tirar o nível 2.

Já em alta maturidade, cheguei a ver modelos onde se a equipe estivesse desmotivada, o custo do projeto poderia aumentar em até 43%, já se a equipe estivesse motivada, o custo poderia ser reduzido em até 14%.
Mas… “o que é motivação?”

Em um resumo bem simplista podemos dizer que é “a pessoa querer fazer aquilo”, “alcançar aquele objetivo”, “fazer de tudo para consegui-lo”, enfim… ter garra.

Na nossa área de TI existem diversas formas de motivação.

A primeira e mais conhecida é o dinheiro – todos precisam de dinheiro e se houver bônus para desempenho acima da média, as pessoas vão perseguir este bônus.

A segunda e muito comum na nossa área é conhecimento – as pessoas anseiam por conhecimento e em TI isso é muito comum. Um projeto em uma arquitetura nova, ou novo negócio, ou até mesmo desafiador é um excelente instrumento de motivação.

O terceiro é o respeito e transparência – Todo mundo quer ser tratado com respeito (é óbvio) e transparência nas ações – existem formas e formas de se passar uma informação ou situação, e esta forma definirá se existe ou não respeito. Tenho amigos que não saem de jeito nenhum das empresas onde trabalham porque sentem que a empresa é séria e respeita o ser humano.

O quarto (vou parar no quarto) é o ambiente de trabalho – Um ambiente com harmonia, onde exista o sentimento de equipe e liderança é fundamental para a motivação. Em algumas cidades aqui do Brasil, as pessoas de TI tem medo de passar conhecimento para o colega que senta ao lado, existe um sentimento de “canibalismo”, e isto com certeza prejudica o desempenho. Outro fator é a liderança e ai vem aquela velha pergunta “Você é chefe ou líder? Por experiência própria, você obterá o dobro dos resultados se optar por ser um líder.

Enfim, a motivação é um fator de grande influencia no desempenho de (por exemplo) um projeto. Pesquise mais sobre isto e mantenha suas equipes motivadas que você obterá mais trabalhando bem menos.