A quinta Mesa Redonda DFTestes foi sobre MPT – Melhoria do Processo de Testes. A discussão teve 13 respostas e 8 participantes: Fabrício Ferrari, Ueslei Aquino, Shmuel Gershon, Felipe Silva, Edwagney Luz, Robson Agapito, Wesley Baldan e o Wagner Duarte.
Na sequência, segue um resumo da discussão, quem quiser conferir a discussão na íntegra, pode acessá-la no DFTestes.
Na sequência, segue um resumo da discussão, quem quiser conferir a discussão na íntegra, pode acessá-la no DFTestes.
O MPT.BR
O Ueslei Aquino explanou sobre o que é o MPT.BR:
O MPT é um modelo que está em desenvolvimento, com o objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais.
Este Modelo está sendo elaborado com base em algumas áreas de processo do MPS.Br e também com referências ao CMMI e PMBOK (para termos de projeto).
O modelo foi projetado inicialmente com 7 níveis de maturidade, mas possivelmente será alterado para 5 tornando-o assim mais leve que previsto anteriormente (está em fase de aprovação). Mas esta mudança aconteceria do Nível 4 em diante, ou seja os níveis até agora definidos serão mantidos (Nível 1 e 2). O Nível 3 está em fase terminal de desenvolvimento e o Nível 4 em Desenvolvimento.
No meu Blog tem um pequeno post sobre o modelo com sua estrutura inicial, com 7 níveis.
A estrutura com 5 níveis deve ficar da seguinte forma:
• Nivel 1:
o GPT – Gerência do Projeto de Teste;
• Nivel 2:
o GRT – Gerência de Requisitos de Teste;
• Nivel 3:
o AQU – Aquisição (opcional);
o GCO – Gerência de Configuração;
o GQA – Garantia da Qualidade;
o MED – Medição;
o AQU – Aquisição (opcional);
o GCO – Gerência de Configuração;
o GQA – Garantia da Qualidade;
o MED – Medição;
• Nível 4:
o GRH – Gerência de Recursos Humanos;
o GRU – Gerência de Reutilização;
o GRI – Gerência de Riscos;
• Nível 5:
o VER – Verificação;
o VAL – Validação.
Atualmente 4 empresas encontram-se com processo de implementação do MPT nível 1 (GPT – Gerência de Projeto de Teste). Empresas como DataSus e iTeste (que provavelmente se certifica até o início de 2010), além de outras.
Ser certificado MPT vale a pena?
Segundo o Ueslei Aquino:
O modelo está em “gestação”, mas aqueles que gostam da área de processo e/ou pretendem investir nessa área, acho que é uma boa sim.
Por que os “selos” de qualidade e melhoria, são tão criticados hoje em dia, principalmente pelos agilistas?
O Ueslei Aquino acredita que:
Pelo fato de muitas empresas buscarem o selo apenas para serem melhor colocados em licitações mas depois que o avaliado vira as costas engavetam toda documentação e volta a vida normal. Implantar processo seguir práticas é um tanto quanto burocrático, se na organização não tiver o apoio da alta gerência para q tudo seja seguido nada funciona. Acredito que MPS resolveu essa situação colocando validade de 3 anos para a certificação, se uma empresa não se re-certificar sai da lista dos certificados em determinado nível.
Segundo o Shmuel Gershon:
Os agilistas não inventaram as críticas aos selos de qualidade… As reclamações são antigas, é só olhar para as críticas ao ISO9000 e ao Six Sigma.
Uma das limitações de todos os processos uniformizados, é, bem, a uniformidade do processo . Como ele é estático e uniforme, quem tem que se adaptar é a empresa e os empregados. Empresas não são uniformes, e elas são compostas por interações não uniformes entre pessoas não uniformes.
Empresas são diferentes, e programam software diferentes. O processo para tratar de qualidade é o mesmo em um produto web-based e embedded? Um controlador de equipamento médico e um administrador de conteúdo? Uma empresa com 700 empregados e uma com 7?
O comentário do Ueslei aparece como uma boa surpresa, pois o foco em “áreas de teste de software de tamanho reduzido” implica na fé de que existem contextos diferentes e o tamanho é um dos parâmetros – uma boa novidade na área de estandardização de processos, que tende a ver tudo como ‘tamanho único’.
Por outro lado:
a) O tamanho da empresa é um parâmetro fraco sobre seu contexto;
b) Comumente empresas com tamanho reduzido sentem menos a falta de processos do que grandes;
c) O comentário implica que tamanho reduzido resulta em níveis menores de maturidade
Sobre a limitação citada pelo Shmuel, acredito que é uma verdade, e o pior é como alguns profissionais encaram esses selos. Infelizmente, muitos ganham os seus uniformes (adorei essa analogia rs) e percebem que ficam bonitinhos com ele, daí então, a sua maior preocupação é deixar o uniforme bem limpinho.
Mas… e o cliente? ahh… ele terá uma primeira impressão muito boa da empresa uniformizada, e como dizem a primeira impressão é a que fica (ou não)
No entanto após um tempo, o cliente vai perceber que as aparências enganam.
O mais importante para qualquer fornecedor é atender bem o cliente, isso é tão “lógico”. Selos, certificações profissionais, etc são plus, primeiro você tem que comer o feijão com arroz, pra depois comer a sobremesa!
O Edwagney também fez um comentário sobre as colocações feitas pelo Shmuel, a respeito da padronização dos processos:
Excelente exemplo Shmuel,
Isso vem ao encontro de um texto que escrevi em meu blog sobre padronização com o título: “Padrão, todos nós deveríamos ter um.” (https://itqualityview.wordpress.com/)
Minha visão é exatamente essa. O ponto crucial de alguns processos de qualidade, e processos em geral, não darem certo em algumas organizações é que elas não lançam mão da sua cultura, da sua política, não usam o que tem de melhor. Não adaptam um determinado padrão aos padrões já existentes na empresa.nas empresas nas quais trabalhei, vi acontecer muito isso. A questão era: “Vamos implantar isso de qualquer forma.” Conhece o ditado: “Top-guela-down”? é mais ou menos por aí…
Usar padrões e processos faz parte da inovação e da melhoria da qualidade, porém, arrisco dizer que 80% do sucesso de um projeto nesse sentido, se ganha usando o lado bom do conhecimento e cultura da empresa.
Qual a posição do mercado em relação as empresas certificadas?
O Shmuel Gershon acredita que:
Em um primeiro momento, pareceria uma questão de oferta e demanda. É igual ISO9001… se a empresa vai perder mercado por falta de certificação, enão certamente vale a pena. Se a empresa consegue manter diferenciação comercial sem o certificado, então não vale a pena. Certo?
O único problema na situação descrita é que no caso de uma certificação sobre testes, quem cria a demanda são as próprias empresas certificadas.
Assim como nas certificações de indivíduos, existe tanta confusão ao redor do que testes e testadores fazem, que é fácil apresentar uma certificação e dizer “Aqui oh, não se preocupe, nos somos certificados, por isso somos melhores que a concorrência”. Ao criar a demanda, criamos um circulo vicioso aonde quem não se certifica fica pra traz.
No fim das contas, se uma empresa acredita que deve passar pelo processo de certificação, tudo bem, mas com cuidado e delicadeza…
É muito importante que o processo seja guiado por alguém (interno ou externo) que está atento as interações e os métodos implícitos no dia-a-dia, para que o processo não estraguem alguma área que já anda bem – ou para que o processo não esconda a realidade sobre uma área aonde existe incompetência.
No cenários em que a certificação representa um diferencial competitivo para a empresa, mas irá “atrapalhar” os processos internos da empresa, costuma haver uma grande resistência interna, um exemplo bem básico:
Se você é o Gerente de Teste e acaba de ser informado que a sua empresa irá tentar se certificar em um selo X, e sabe que isso irá trazer um grande impacto para o processo atual de Teste de Software, talvez você possa ser resistente a essa decisão, pois está olhando só para o seu nível.
Agora se você for analisar num nível macro a decisão, você poderá perceber que o selo X irá trazer grandes benefícios a nível de negócio para a empresa, podendo resultar em contratos importantes, que ir.
Moral da história: Precisamos sempre buscar ter uma visão ampla do nosso mundo. Para alcançar o sucesso, é necessário sacrifícios. (“O importante é termos a capacidade de sacrificar aquilo que somos para ser aquilo que podemos ser.” – Charles Dubois)
Para uma empresa cujo core business não é o Teste de Software, é interessante a certificação?
Para o Ueslei Silva:
Bom, se esta empresa usa SW e possui profissionais que testam o SW, acredito que sim. Trabalhei em uma empresa que mantém no mercado um grande ERP. A empresa possui uma fábrica de desenvolvimento de aproximadamente 70 desenvolvedores e um departamento de teste com 8 testadores, para o mercado seria interessante mostrar para os clientes que a qualidade do SW é assegurada por processos estabelecidos, maduros, etc. (eu era o gestor da área de testes, mas a empresa não estava preparada culturalmente para implantar um processo assim).
Para o Shmuel Gershon depende:
Uma possibilidade: Sim! – pelo menos vai ter um processo mais estruturado.
Outra: Não! Aonde existia incompetência caótica, agora existirá uma incompetência organizada e rigorosa. O problema desta última, é que agora ninguém mais percebe que tem que melhorar.
Ou ainda: Depende! Pode ser que o dono da empresa se sente inseguro e a certificação vai deixá-lo mais cordato para guiar a empresa. Ou pode ser que a equipe é madura o suficiente para não deixar a certificação ou o rigor do processo atrapalhar a operação. Pode ser que o gerente de testes não quer a certificação de jeito nenhum, e certifica-se vai criar rixas desnecessárias. Pode ser que a equipe é tão madura e com ótima performance que inserir as mudanças da certificação vai atrapalhar. Tudo pode ser.
Outra: Não! Aonde existia incompetência caótica, agora existirá uma incompetência organizada e rigorosa. O problema desta última, é que agora ninguém mais percebe que tem que melhorar.
Ou ainda: Depende! Pode ser que o dono da empresa se sente inseguro e a certificação vai deixá-lo mais cordato para guiar a empresa. Ou pode ser que a equipe é madura o suficiente para não deixar a certificação ou o rigor do processo atrapalhar a operação. Pode ser que o gerente de testes não quer a certificação de jeito nenhum, e certifica-se vai criar rixas desnecessárias. Pode ser que a equipe é tão madura e com ótima performance que inserir as mudanças da certificação vai atrapalhar. Tudo pode ser.
A melhor resposta depende de cada empresa, gerente, líder e equipe. A equipe deve se conhecer o suficiente para escolher.
A respeito do caos citado pelo Shmuel, nessa semana ouvi uma história interessante, de um amigo meu, sobre uma grande empresa que estava se preparando para o CMMI:
Ele trabalhava na empresa XPTO, e essa empresa estava se preparando para o CMMI, daí o cliente X, pediu uma nova funcionalidade no sistema dele, esse cliente estava acostumado com o processo antes o CMMI, sabe aquele processo padaria? (me ver um pãozinho aí = me ver uma funcionalidade X), porém o Gerente do Projeto, não podia mais seguir o processo padaria, e para explicar isso para o cliente? rsrs (para não chorar)
Alguém já participou de uma avaliação, avaliando ou sendo avaliado? E poderia relatar a experiência.
O Ueslei Aquino compartilhou um pouco da sua experiência com o MPT:
Eu mesmo conduzi as reuniões de implantação das práticas do nível 1 na iTeste, num projeto em que o Cliente encontra-se na Bélgica, o Desenvolvimento na Índia e os Testes são feitos aqui no Brasil (RJ). Detalhes:(1) O desenvolvimento utiliza scrum e ja estava com 1 ano iniciado sem muitas documentações. Foi necessário mapear casos de uso para que os casos de testes fossem realizados; (2) A fábrica de Teste não Fala com o Desenvolvimento, a comunicação é direta com o cliente e este passa os bugs para o Desenvolvimento. Apesar de todo este cenário, o Projeto está andando muito bem e seguindo as práticas do MPT nível 1.
O Shmuel Gershon compartilhou a sua experiência com o TPI:
Eu participei de processos TPI (Test Process Improvements), e no meu departamento tiramos nossas próprias conclusões sobre o que ajuda e o que deveríamos ignorar. Também faço parte de um grupo para a discussão de metodologias, mas não seguimos nenhum processo público. Judy Bamberger foi uma das autoras do CMM, e ela escreve que “acredito que ele (o CMM) não foi concebido para ser usado de maneira em que determinada empresa tem que alcançar o nível X em determinado tempo, ou que a empresa precisar “ser” um certo nível antes que outros negociem com ela” (tradução minha). Ou seja, as documentações normalizadas de processos são apenas auxiliares, mas não devem dominar o procedimento.
A CQA
Para o Felipe Silva:
“A hora” de certificar-se é quando o ambiente está pronto. Fazendo uma analogia, a empresa é um quarto, pode estar bagunçado e cheirando mal ou arrumado e cheiroso, a certificação seria uma placa que você colocaria do lado de fora da porta “Quarto organizado”, dai já dá pra tirar as conclusões de quando tentar colocar a placa ou não e os impactos de tentar colocar a placa no momento errado, já pararam pra pensar se o cliente resolve abrir a porta e ver como está realmente este quarto por dentro e vê algo assustador?
O fato é, se o quarto está arrumado, por que não sinalizar isso ao mercado? Sim, vale a pena para a empresa estes selos.
A respeito do ponto de vista do Felipe Silva, o Shmuel Gershon fez o seguinte comentário:
Seu exemplo é muito bom, mas eu gostaria de adicionar que ele falha em perceber a limitação das certificações de processos. Por exemplo: Meu jeito de arrumar o quarto e o de minha esposa são diferentes, os métodos de trabalho e os critérios de qualidade de nos dois difere também. Porém, ela performa com rapidez e segurança no seu modo – e consegue encontrar qualquer coisa em um piscar de olhos.
Se eu criar a CQA (certificacao de quarto arrumado), ela terá que mudar seu modo de trabalho – o quarto vai ficar do jeitinho que eu quero (e defini na documentação)… Mas será que ela vai estar executando a tarefa com a mesma satisfação? Será que ela vai encontrar as coisas com a mesma agilidade agora que as roupas estão guardadas por ordem alfabética?
E, mais importante: Será que a imposição de um método não natural a sua personalidade não vai afetar uma serie de outras áreas que a CQA não mede? Ou que eu não percebi serem cruciais para o bom funcionamento da família?
Enquanto o método de melhoria de processo de testes estiver aí para ensinar e guiar e deixar cada empresa criar seu próprio caminho para a excelência, maravilha. Mas ao tratar o conteúdo como uma ‘certificação’, o material acaba se tornando mandatório e standardizado – e o que pode ser bom para uma empresa pode ser perigoso para outra.
A resposta ao “vale a pena?” é “depende” – cada empresa e equipe deve analisar sua situação e necessidades.
Experiências com o MPS-BR
O Robson Agapito compartilhou a sua experiência com o MPS-BR:
Vou contar uma história verídica que aconteceu conosco na Mega em relação ao MPS-Br… estávamos procurando melhorar a qualidade de nosso produto, e buscamos o conhecimento oferecido pela Softex chegando então a certificação do Nível G… mas desde o início lutamos não pela certificação, e sim pela melhor qualidade e melhor controle de tudo que entrava (solicitações) pelos clientes e tudo que saia (melhorias e correções) do desenvolvimento/testes. E tínhamos em mente que a certificação seria uma conseqüência da melhoria de nosso processo.
Com certeza no inicio “travou” um pouco, mas com o andamento dos projetos e adaptações ao modelo proposto, melhorias foram identificadas durante o andamento do trabalho, e esta melhoria foi identificada por todos, inclusive pelos clientes que hoje sentem um produto final mais maduro e com uma melhor qualidade.
Então digo, o importante não é a certificação (claro que ajuda muito em uma venda), mas sim o conhecimento e a bagagem na melhoria da qualidade que conquistamos na implantação de processos para garantir a maturidade de nossos processos… a certificação foi conseqüência. Mas a cada dia batalhamos pela melhoria do processo, pois sempre podemos melhorar e jamais se acomodar.
Creio que o MPT vem para se tornar um apoio à todos da área de testes, ajudando a criar e melhorar processos de testes pelo Brasil, e futuramente pela América Latina.
O Wesley Baldan também compartilhou uma experiência com o MPS-BR:
Onde eu trabalho, foi um pouco diferente. Para obtermos o nível F (se eu não estou enganado, enfim, é o 2º nível) do MPS-Br a principal preocupação era com a aprovação, mas por conseqüência houve uma grande melhora… Claro, se está se preparando para obter um nível de qualidade as mudanças tem que ocorrer e por conseqüência há melhoras no produto final.
No começo foi muito difícil, porque antes era organizado, mas não tanto, então travava muito no começo o processo, mas depois de um tempo todos perceberam a melhora que aconteceu… É aquela coisa de quebrar a rotina, quando há uma mudança muitas pessoas não gostam.
Depois de obtido o nível, a empresa foi adquirida por outra e um dos pontos positivos da área de Desenvolvimento era a atenção com a qualidade.
Para encerrar o “resumo”, segue abaixo o comentário do Wagner Duarte, que levantou um ponto muito importante a atitude das pessoas, principalmente, dos que estão liderando a implementação:
Essa questão (mudança cultural) é e sempre foi um obstáculo na implementação de quaisquer melhorias e/ou mudanças em qualquer tipo de grupo.
Creio eu, que o problema não está apenas em quebrar paradigmas, mas principalmente no perfil daquele que propõem as mudanças.
Vejo hoje, que têm muitos “líderes” que não têm perfil ou apenas que não aprenderam algumas das boas práticas de um “bom líder”, para exercer tal atividade.
• A forma em que a solução/mudança é proposta pode causar discordância e desmotivação dos membros da equipe;
• Um “bom líder” tem que ter visão – para analisar um “Modelo” proposto e verificar o que se adéqua melhor à sua empresa/instituição;
• Os membros que participam da implantação das mudanças/melhorias devem ter qualidade nas veias, para proporem ainda mais melhorias e não, contaminarem e desestimularem o restante do grupo, por não gostarem de mudanças e serem comodistas.
O ponto levantado, faz-se bastante pertinente ao dizer que “o MPT diz o que deve ser feito e não como”, ou seja, isso o torna um modelo proposto que, para se alcançar um determinado nível faz-se necessária a implementação/modificação de uma metodologia. Porém, como a empresa fará para se atingir o nível esperado, depende muito do “líder” que conduzirá o movimento.
Post Original da Mesa Redonda no Blog do Fabrício Ferrari:
