Blog CMMI & MPS.BR

O caso a seguir aconteceu no mesmo projeto do post “Qualidade custa mais?”.

Hoje em dia muitos falam sobre produtividade, mas compreender o que é de fato produtivo é algo bem complexo.

Naquele projeto, fiz um experimento interessante.
Tínhamos dois analistas programadores muito bons, o Primeiro (Leandro) era conhecido na empresa como um dos mais rápidos. Passei para ele um programa de 20h (programa A). Ele terminou o programa em aproximadamente 7h (35% do tempo).

A segunda analista programadora (Eline) também era conhecida como muito boa, mas não tão boa quanto o Leandro. Passei para ela um programa de 16h (programa B). Ela terminou o programa em aproximadamente 11h (68%).
Se você tivesse que premiar alguém, quem você premiaria? Olhando esses números você não tem dúvidas de quem é o melhor, certo?

Esta é a análise feita pela maioria das pessoas, mas… (há sempre um mas) os programas foram para a área de testes.

Quando retornaram da área de testes o programa A necessitava de várias correções e ajustes, já o programa B praticamente não teve erro.

Nas idas e vindas do programa A, utilizou-se mais 9h, ou seja, o programa dele não foi finalizado em 7h e sim em 16h.

Agora vamos refazer a análise.

• Leandro – utilizou 80% do tempo
• Eline – utilizou 68% do tempo

Agora você pode responder aquela pergunta sem com mais embasamento.

Ambos tiveram uma produtividade excelente, mas analisando os dados da forma correta, consegue-se ver quem foi o mais eficiente quem teve a melhor produtividade naquele projeto.

Enfim, como dito, a primeira análise é a mais comum (e equivocada), mas devemos sempre avaliar todo o ciclo para ter certeza de que estamos avaliando o processo da forma correta.
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 descrição de papéis e responsabilidades (também conhecida como descrição de cargos e responsabilidades) é uma coisa básica na industria, porém em TI ela ainda esta engatinhando.

Vamos fazer um teste, procure em sua empresa se há uma documentação definindo claramente o que você (ou alguém com o mesmo cargo) deve fazer. Bom… provavelmente em mais de 90% dos casos não haverá nada ou uma definição informal do que é.

O mesmo vale para os níveis de senioridade.

Mas, porque é tão importante ter essa descrição? Simples: organização, produtividade e escala.

Tendo os crítérios, você reduz riscos de:
Contratar um junior achando que é senior
Enviar demanda a um profissional que não esta apto a executa-la
Ter diferentes faixas salariais para o mesmo perfil
Não cumprimento de prazos
E outras

Vale lembrar que esta definição deve ser apoiada pela política organizacional e deve ter a aprovação e comprometimento da alta direção.

Agora, vamos a um exemplo simples de como deve ser uma “descrição de cargos e responsabilidades”:

Cargo: Programador Junior Java
Formação: Técnica, superior ou curso que ateste os conhecimentos

Conhecimentos:
1. UML
2. Java
3. …

Habilidades:
1. Conversação em inglês
2. Digitação rápida
3. …

Responsabilidades:
1. Entregar os produtos com a qualidade definida
2. Apontar diáriamente as horas trabalhadas nas tarefas específicas
3. …

A quem se reporta: Gerente de desenvolvimento

É muito importante você definir critérios para os elementos evitando que alguém que saiba apenas a frase “the book is on the table” seja classificado com “Conversação em Inglês – OK”

Lembrando, este é um exemplo básico, da pra evoluir bem com elementos como: “Elementos Obrigatórios e Opcionais”, “Faixa Salarial”, “Atuação secundária”,”autoridade”, etc, etc, etc

Os que estão envolvidos com OT ou GRH devem montar esta definição para cada cargo (papel ou função) de sua organização e segui-la.

Abraço a todos.
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 →

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 →