ALM – Agilidade em Testes de Software – O que é ser Ágil? Parte 01 de 03

keep-calm-and-love-agil

Resolvi escrever esse post, depois que recebi um contato de uma amiga me pedindo se eu tinha materiais sobre Testes Ágeis. Então para deixar bem organizado, resolvi escrever um Post de 03 partes que, além de ajudar essa amiga, também deixar disponível caso alguém tenha interesse.

Primeiramente, antes de iniciar a leitura, gostaria de deixar claro que acredito particularmente que, todos os métodos, processos e frameworks são funcionais e bons, e tudo é questão de momento, tendências e realidades, conforme as necessidades de cada empresa e time. Que o objetivo desse post é apenas provocar uma reflexão sobre as tendências, se realmente temos o certo e errado dentro de processos e frameworks mundialmente utilizados e que tanto serviram a seus propósitos ao longo dos anos. E não sou um guru de testes ágeis, nem de DevOps, apenas estou expondo um pouco do que já vi e o conhecimento que tenho de ferramentas e processos.

Também que cada pessoa, grupo defende suas idéias e visões de processos, e que temos que estar com a mente bem aberta para ouvir o que cada um tem a dizer e tentarmos utilizar dentro da nossa realidade as idéias que nos parecem certas para o momento e caso não funcione, não necessariamente é uma má idéia e sim que não “coube” em nossa realidade naquele momento.

E que cada empresa tem sua fórmula de sucesso, e que, na minha humilde opinião, não devemos abandonar uma fórmula de sucesso, e sim, ir adaptando e melhorando para que ela continue sendo um sucesso ao longo dos anos, conforme as necessidades e objetivos que devem ser atingidos, pois o mercado muda constantemente e temos que sempre estar nos adaptando para continuarmos sempre competitivos.

Partindo disso, vamos lá:

Atualmente estamos em uma fase de agilidade (para mim sempre tivemos a diferença é que cada dia está se pedindo mais agilidade, o que é normal, pois não é novidade automatizar as coisas, valhe lembrar a Revolução Industrial de 1760… Smile) e escutamos todos os dias que devemos ser ágeis, entregas rápidas, que o mundo mudou, que as pessoas não têm mais paciência para esperar, que estamos mais competitivos, etc., o que não deixa de ser verdade.

Claro que todos nós gostaríamos de ser ágeis e ainda entregar com qualidade, responsabilidade e rastreabilidade. Mas o que me chama muito a atenção é que escuto muitas pessoas dizerem que “Ser Ágil” é quebrar processos, documentações, foco nas pessoas, etc. Será que é isso ou só isso mesmo? Não sei, e o objetivo desse post é fazer você pensar um pouco a respeito disso. Por isso, coloco alguns exemplos para pensarmos:

Imagine um processo de Gerenciamento de Serviços de TI usando-se ITIL, por exemplo. As famosas GMUDS, Change Request, Comite de Aprovação, cotações com no mínimo 03 fornecedores, etc. Em algumas empresas, esses processos e diretrizes, chega a levar até 03 meses para a disponibilização de ambientes para implantação de novos serviços.

Nesse caso acima citado, ser ágil seria interromper esses processos e focar na entrega do ambiente? Abrir mão do processo de cotação de 03 fornecedores para apenas uma cotação para ganhar tempo? Como garantir que abrindo mão do padrão de cotação, eu estarei comprando o melhor material (custo x benefício para a empresa)? Como disponibilizar um ambiente sem aprovação de um Comitê, responsável por “pagar” esse ambiente? Como gerar um ambiente seguro, funcional ou de alta disponibilidade, sem usar documentos de checklists e validações, boas práticas, análises, etc.

Imagine agora um outro cenário:

Em um processo de desenvolvimento de software, um processo ágil na área de testes seria abrir mão de uma análise de requisitos, funcionalidades e criação de um Planejamento de Testes (Plano de Testes)? Abrir mão de testes manuais funcionais e executar testes automatizados? Abrir mão da formalização de um BUG dentro de um sistema como o Team Foundation Server e conversar diretamente com a equipe para resolver e entregar? E como ficaria a rastreabilidade depois? Como proteger a empresa, se a equipe sair, onde ficaria o histórico do que tivemos de incidentes, bugs, impedimentos, etc.? Garantir sem usar um checklists de validação ou um Plano de Testes, que todos os itens foram avaliados? Que os testes de “manutenibilidade” ou testes não funcionais (não possíveis de serem automatizados) foram executados? Como extrair esses testes, se eu abro mão de uma análise de uma especificação documentada e criação de um Plano de Testes? Ou ser Ágil não necessariamente se abre mão disso? O que vocês acham?

Algumas empresas defendem a Gestão do Conhecimento, ou seja, manter o conhecimento através de documentação, Sistema de Gestão e tantos outros sistemas e técnicas dentro da empresa. Seria o processo Ágil um impeditivo para isso ou não? Uma vez que a Gestão do Conhecimento defende a disseminação de informações, e como manter essas informações ao longo dos anos? 

Será que ser Ágil é abrir mão disso, ou continuar com tudo isso, e mudar a mentalidade das pessoas?

Qual sua opinião sobre isso? Fora do contexto de TI, imagine um processo de entrega de encomendas:

Você precisa entregar um pacote a um destino e contrata o serviço de um caminhoneiro. Junto com esse pacote, você entrega um roteiro que o caminhoneiro deve seguir que incluiu:

– Instruções de como dirigir o caminhão e utilizar seus comandos;

– Quais as estradas que o caminhoneiro deve pegar;

– Qual posto de gasolina o caminhoneiro deve abastecer, que é onde você possui crédito;

– Quais locais que ele deve comer;

– Quantas paradas ele deve fazer;

Parece bobagem uma lista assim, mas imagine que você contrata sempre um terceiro e algumas vezes ele não conheçe tão bem o modelo do caminhão da sua empresa, o que faz necessário ter uma documentação para ele ler, ou você iria confiar seu caminhão de R$ 300.000,00 a uma pessoa que nunca dirigiu tal modelo? Sendo que você não consegue encontrar um profissional que tenha conhecimento no modelo de caminhão em questão.

Ou você deixaria de livre escolha o caminhoneiro abastecer no posto de sua preferência? Daria essa autonomia a ele? E se a gasolina escolhida fosse “batizada” e pudesse comprometer o motor do caminhão e consequentemente a entrega?

Quando saber que posso pular uma etapa, documentação ou “ritual” sem gerar um problema futuro para a equipe ou empresa? Ou como ser ágil sem perder essas informações exigidas por órgãos competentes?

Leia o Manifesto Ágil e tire suas conclusões!

Pense, comente, reclame, nos comentários pois darei minha humilde opinião no próximo post!

Até mais!

Leia também:

ALM – Agilidade em Testes de Software – O que é ser Ágil? Parte 02 de 03

Um comentário sobre “ALM – Agilidade em Testes de Software – O que é ser Ágil? Parte 01 de 03

  1. Pingback: Agilidade em Testes de Software – O que é ser Ágil? Parte 02 de 03 |

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s