Blog CMMI & MPS.BR

Há alguns meses um amigo me pediu umas dicas, pois eles estavam implementando o nível do CMMI 4. Ele iniciou falando que eles estavam muito bem, pois já iniciaram fazendo  um curso de CEP (Controle estatístico de processos), focado nos gráficos de controle e com base neste curso eles mapearam os indicadores que eles precisavam para o nível 4 (!!??).

Ele queria saber se eles estavam indo no caminho certo.

Quando se fala em alta maturidade (CMMI Níveis 4 e 5 – MPS.BR níveis A e B) tenho visto uma enxurrada de treinamentos de CEP focasos exclusivamente no gráfico de controle, e até agora não vi nenhum de alta maturidade propriamente.

Voltando a conversa com meu amigo, ele me mostrou o que estavam fazendo, como estavam calculando desempenho e por ai. Ao final da conversa disse que tinha uma péssima notícia pra ele, pois a implementação dele que ele achava que tinha 90% pronto, não tinha nem 20%.

Este é um problema de entendimento dos modelos. O uso de CEP é essencial em alta maturidade, mas, seu uso correto resolve no máximo 30% do nível 4 (MPS.BR B). E seu uso é feito no final de uma implementação nível 4. O maior trabalho em alta maturidade (antes do nível 5) é a estabilização dos processos e montagem dos modelos. Estas duas atividades demandam um bom tempo.

Para ajudar, na maioria das implementações de alta maturidade, as empresas têm que refazer boa parte dos níveis 2 e 3 por não estarem preparados para os níveis superiores.

Então a dica que vai é: “O gráfico de controle é importantíssimo, mas no final da cadeia de implementação do nível 4”. Antes de entender o controle estatístico de processos e elaboração de modelos de desempenho faça uma simples verificação:

“Seus processos estão estáveis?”

Se eles não estiverem estáveis, então, você tem muito trabalho pela frente, pois a estabilização demanda ajustes, novas medições, novo processo de institucionalização e outras coisas. Em resumo, leva tempo.

Somente com seus processos estáveis, você poderá iniciar alta maturidade.
Veja o post completo →

Por volta de 2003 gerenciei um projeto de um portal interno para uma grande multinacional. O esforço estimado com APF foi de aproximadamente 7.000h e estava bem justo.

Este era nosso primeiro projeto neste cliente e o mesmo estava muito apreensivo com a qualidade pois o projeto envolvia mais de 10 áreas da empresa (marketing, RH, Engenharia, Presidência, etc).

A equipe prevista era de dois analistas e seis programadores. Então decidi mudar um pouco e trocar um destes programadores por um tester. No começo várias pessoas falaram que não daria certo e que o projeto atrasaria porque “faltaria braço”.

A tester que coloquei no projeto (Fabiana Custódio) era uma pessoa muito integra e que realmente se preocupava com a imagem da empresa. Para fortalecer este processo, no lançamento do projeto divulguei a todos seu papel e que nada sairia da empresa sem o aval dela. Em apoio ao processo implementamos também a bonificação por produtividade.

O projeto foi andando e começaram a aparecer os bugs (internos sempre), a Fabiana realizava os testes, encontrava os bugs e passava para os programadores corrigirem. Em um determinado momento começou um “movimento” para tira-la do projeto pois segundo alguns “os problemas estavam aparecendo e isto não era bom”.

Tentaram de diversas formas me convencer de que ela atrapalhava o andamento do projeto, mas sempre fui firme. Do ponto de vista gerencial os resultados estavam excelentes pois o cliente não encontrava erros em nossas entregas. Comercialmente o cliente também estava muito satisfeito.

Veja o post completo →

A partir de hoje também estaremos falando de MPS.BR aqui no Blog CMMI. Então não estranhe pois quando falarmos de uma PA, também colocaremos o processo equivalente do MPS.BR.
Aos que não conhecem, o MPS.BR é um modelo de qualidade muito parecido com o CMMI e mantido pela Softex. Ele foi baseado na ISO 12107, ISO 15504 e no próprio CMMI. Outro ponto interessante é que ele também é organizado por estágios, mas, diferente do CMMI, ele tem 7 estágios.

A – Em Otimização;
B – Gerenciado quantitativamente;
C – Definido;
D – Largamente Definido;
E – Parcialmente Definido;
F – Gerenciado;
G – Parcialmente Gerenciado.

Ele tem poucos anos, mas tem trazido excelentes resultados à comunidade de software do Brasil. Atualmente mais de 100 empresas foram avaliadas em algum nível do MPS.BR e muitas destas continuam a jornada para os níveis mais altos.
Isto é excepcional pois acredito que dentro de 3 à 5 anos teremos pelo menos 40 empresas brasileiras avaliadas em alta maturidade.

No ritimo atual, acredito que este ano a quantidade de avaliações MPS.BR já deva passar a quantidade de avaliações CMMI aqui no Brasil.

Se você se interessou procure a Softex e veja como participar e obter subsidio do governo (sim, o governo subsidia parte do processo).

Enfim, é um modelo muito (muito mesmo) simular ao CMMI. Vale a pena o investimento.
Veja o post completo →

A pergunta “Quanto tempo é necessário para conseguir o CMMI?” esta entra as top 5. Para responde-la resolvi montar esse gráfico que responderá com precisão:

Estes dados foram obtidos do ultimo comunicado da SEI sobre o assunto.

Vamos entender o gráfico. Cada barra mostra o mínimo e máximo de tempo e a linha no meio representa a média, então se pegarmos o nível 2 veremos que você pode levar de 15 à 40 meses para se conseguir obter o CMMI nível 2, porém, o mais provável (média) é que você consiga em 19 meses.

Uma coisa interessante é que o nível mais demorado é o nível 4 (24 meses) e isto se dá porque muitas empresas não implementam a área de medições corretamente ou não possui um processo definido (algo básico desde o 3) e quando chegam no nível 4, ou fazem de verdade ou não tem como prosseguir.

Vale lembrar que estes dados contemplam mais de 8 anos e a realidade hoje pode ter mudado.

O tempo de implementação de um nível CMMI vai depender muito mais da estrutura da empresa do que da consultoria que vai ajudar. É mais ou menos assim, se a empresa quer “de fato”, vai ser mais rápido, mas, todos devem remar para o mesmo lado.

Se você esta implementando CMMI na sua empresa e tem resistências internas no seu corpo gerencial, saiba que você vai demorar mais (e gastar mais também).

Outra coisa que você deve ter em mente é a questão da maturidade (vou falar disto mais detalhadamente esta semana), o CMMI tem os níveis 2, 3 4 e 5 por uma razão, não adianta querer dividi-lo em 3 e 5, isto não existe e não é bem visto na SEI.
Veja o post completo →

Todos nós temos conhecimento que o desenvolvimento de projetos de software é uma tarefa árdua e extremamente difícil. Um sistema mal construído pode gerar milhões de reais em prejuízos em poucas horas, dependendo do tamanho do cliente e do porte da operação suplantada. O primeiro registro de “bug” foi em 1945 quando a Oficial Naval Grace Murray Hopper, encontrou uma traça dentro de um dos computadores da marinha americana. O fato de ter encontrado um “bug” (inseto em inglês) dentro de um computador que estava com mau funcionamento por conta dessa ocorrência, permitiu com que o termo se tornasse comum na área de desenvolvimento de software e associado a falhas durante a execução.

Ao longo da história evolutiva do computador e do desenvolvimento de aplicativos, é muito comum totalmente normal encontrarmos situações na qual existiram, existem e ainda irão existir situações de problemas durante a realização de alguma tarefa em um determinado sistema. Mas em muitos desses casos, as conseqüências desses atos foram resultados de tragédias calamitosas que sacrificaram vidas humanas ou até mesmo prejudiciais ao meio ambiente. Um caso interessante, foi à explosão do ônibus espacial Columbia em 1986, quando alguns funcionários da própria NASA que haviam sido demitidos após o fracasso do projeto, declararam para a imprensa que o acidente aconteceu por conta de falhas no software na hora do lançamento, pois não tiveram testes suficientes no software. Veja o post completo →

O que é PPQA?
PPQA significa Process and Product Quality Assurance (Garantia de qualidade de processo e produto) e é a área responsável no CMMI pela qualidade tanto nos projetos quanto organizacionalmente.

Como PPQA realiza seus trabalhos?
A principal ferramenta de trabalho do PPQA (vamos chamar apenas de PPQA o analista de PPQA) é o checklist de auditoria. O PPQA deve seguir o checklist e verificar se o processo esta sendo seguido conforme previsto

Qual o resultado dos trabalhos de PPQA?
Um relatório mostrando como foi a auditoria. Este relatório deve ser enviado à todos envolvidos no projeto

Como PPQA ajuda nos projetos?
O principal objetivo é mostrar à alta direção como esta o projeto (o que esta em conformidade e o que não esta)

PPQA audita apenas projetos?
Não, diversas outras atividades de suporte devem ser auditadas para garantir que o processo esta sendo seguido. O principal exemplo é OT.

A quem PPQA responde?
À alta direção da empresa (presidência ou direção)

Porque PPQA responde para a alta direção?
Para garantir independência e que não haverá conflito de interesses ou manipulação dos resultados. A alta direção deve saber a real situação dos projetos.
Veja o post completo →