Você precisa de Agile?

Parece que de repente, “todo mundo” começou a buscar ser ágil.

A primeira vista isso pode até ser visto como bom, uma vez que vários métodos ágeis são bem mais sensatos do que os métodos tradicionais. Porém, infelizmente, muitos estão apenas indo na “onda do Agile”, e esses correm um alto risco de morrer na praia.

Por experiência própria, posso dizer que Agile não é pra qualquer empresa/equipe.

E dentre as várias coisas que aprendi (a duras penas), foi que nem sempre precisamos de Agile, ou melhor, nem sempre o que mais precisamos é Agile.

Para ilustrar esse aprendizado, vou utilizar o exemplo da famosa XPTO Solutions.

A XPTO Solutions também conheceu o Agile, por meio de materiais de terceiro é claro (uma dica: busque primeiro o conhecimento da fonte original). E após ver que os seus concorrentes já estavam utilizando métodos ágeis, decidiu adotar também. E como a maioria, começou com Scrum.

No começo tudo parecia uma maravilha, vários post-its coloridos na parede, o gráfico burn-down correndo bem, etc. Porém, após algumas sprints, percebeu-se que tinham finalizados várias funcionalidades, porém nada tinha ido para a produção, e nem o cliente tinha visto o software que estava sendo desenvolvido, pois estava distante, e o máximo de participação que ele tinha na sprint, era feita por e-mail ou telefone com o Scrum Master.

Outro problema que apareceu, foi que muitas tarefas eram retrabalhos e resoluções de bugs, pois eles não faziam testes unitários e 70% dos desenvolvedores ainda eram juniores, e não conheciam práticas como TDD e ainda não tinham uma base sólida na linguagem de programação que é usada na XPTO.

O problemas que aconteceram na XPTO não são incomuns. E se formos analisar muitos desses problemas não têm nenhuma relação com o Agile, e iriam acontecer independente da metodologia utilizada.

Problemas como equipe inexperiente, cliente distante, gestão de conhecimento ineficiente, falta de motivação, acomodação, etc são comuns em qualquer empresa. E a solução ou medidas que poderiam amenizar os seus efeitos não estão numa metodologia de desenvolvimento de software.

Por isso que eu enfatizo, que antes de implementar Agile, precisamos analisar o ambiente a nossa volta, assim como um agricultor verifica o terreno para saber o que pode plantar nele. Não adianta forçar ser Agile, o seu desenvolvedor não irá testar só porque agora é Agile, o seu cliente não irá participar mais e/ou aceitar o contrato de escopo negociável, só porque agora a sua empresa é Agile.

E é bom lembrar, que Agile não é um fim, e sim um meio para você construir software com mais eficiência e qualidade, ter uma equipe mais motivada e um cliente mais satisfeito.

É importante ter em mente, que Agile não é apenas uma questão de mudança de hábito, mas também cultural . Vários paradigmas precisam ser quebrados quando implementamos Agile, e alguns deles já foram quebrados por pessoas como o Ricardo Semler, muito antes do Manifesto Ágil surgir, como por exemplo: uma participação mais democrática da equipe no dia-a-dia e nas decisões da empresa e valorizar mais pessoas do que processo.

Podemos fazer uma implementação de Agile de forma mais harmoniosa e sensata, ao buscar saber o que realmente precisamos antes do Agile em sí, uma vez que muitos dos problemas que enfrentamos, não estão relacionados com a metodologia que está sendo usada. Lembre-se, que “para que a semente dê frutos, é necessário preparar a terra.”

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte imagens:

http://bit.ly/aevP0r

http://bit.ly/c2t8zd

http://bit.ly/a8Y15t

Anúncios

Teste de Software: resultado da imperfeição

Ontem comecei a ler o livro “O Ócio Criativo” do Domenico de Masi. E logo no começo, em uma das perguntas feitas pela entrevistadora Maria Serena Palieri ao de Masi, ele traz um insight muito interessante, no qual valoriza as imperfeições do ser humano.

Para entender melhor, reproduzo abaixo o trecho do livro em questão:

Quais foram, então, os momentos da História nos quais nós, seres humanos, atravessamos encruzilhadas, vimos que o mundo virava de cabeça para baixo, se torna “um outro” mundo?

Um primeiro longo período da história humana vai de setenta milhões a setecentos mil anos atrás. Durante esse período, quem vivia não percebia nenhuma mudança, se sentia sempre igual. Trata-se da longuíssima fase na qual o homem criou a si mesmo: aprendeu a andar ereto, a falar, a educar a prole.

Se refletirmos bem, estas são mudanças extraodinárias, todas elas decorrentes da compensação dos nossos defeitos. Rita Levi Montalcini explicou isso muito bem no seu livro L’elogio dell’imperfezione (O elogio da imperfeição). Tínhamos um olfato fraco, portanto não podíamos perseguir a caça farejando a terra, como fazem os animais, mas tínhamos que avistá-la: para isto devíamos caminhar de pé, já que a caça frequentemente fugia, desaparecendo na vegetação. Isto fez com que se tenham salvado somente aqueles indivíduos da nossa espécie que se tornaram mais aptos para caminhar eretos.

Tal fato nos faz entender melhor o surgimento de várias áreas e tecnologias. E uma das áreas decorrentes da imperfeição humana, é a de Teste de Software.

Todos conhecem aquela frase que diz que “errar é humano”. E a probabilidade da ocorrência do erro ainda pode ser maior dependendo do ambiente em que estamos inserido. Sendo que quando falamos de um ambiente de desenvolvimento de software, logo lembramos de palavras como: prazo, complexidade, pressão, dentre outras.

Portanto, os profissionais de TI acabaram ao longo do tempo, percebendo a importância de se testar o software, sendo ela uma ação derivada da imperfeição humana. Afinal, seria um desperdício de tempo e esforço testar algo produzido pelo ser humano, se ele fosse perfeito.

É interessante notar, que graças as nossas imperfeições, fomos forçados a nos adaptar melhor ao ambiente em que vivemos e ao longo da história da humanidade, grandes inventos foram feitos, justamente para tentar contrapor tais imperfeições.

Voltando ao texto do livro, podemos interpretar que ao aprender a andar ereto, diminuímos os riscos de não conseguir comida. E pensando no mundo do desenvolvimento de software, o Teste de Software acaba também diminuindo riscos, no caso, os riscos associados a qualidade do produto/serviço que iremos entregar ao cliente.

E a lição que podemos tirar de tudo isso, é que é importante reconhecer as nossas limitações e erros, e mais importante ainda, é buscar agir para contrapô-los. Sendo assim, testar um software acaba sendo uma das ações que podemos executar, para contrapor o fato de que não produzimos software perfeito.

Fique por dentro das novidades, assine o feed do QualidadeBR.