“Você estava acenando esses dias pela janela do nosso quintal mas não entendi quem era, então hoje resolvi vim ver” – disse Ana, pela primeira vez no meu jardim da frente da casa.
Olá! sou seu novo vizinho! nos casamos faz pouco tempo e acabamos de nos mudar pra essa casa e não tinha certeza se você estava me cumprimentando naquele dia pela janela ou se estava fazendo outra coisa. Em todo caso acenei porque não enxergo bem à distância e ainda estou aprendendo os nomes dos vizinhos – Eu disse.
“Que legal! sou italiana, mas mudei pra esse país fazem muitos anos. Meu marido é inglês e moramos aqui já faz vários anos. Seja bem vindo!”
Que legal! também sou italiano! peró non parlo italiano molto bene. E continuei falando em inglês com ela.
Ana já era bem idosinha, e às vezes não dava pra entender muito o que ela falava em inglês. Mas a simpatia era nítida. Tipicamente de nonas italianas. Diretas mas muito gentis.
“Você gosta de pasta? qualquer dia desses poderiam vir jantar com a gente e eu posso fazer uma pasta” – disse Ana
Claro! respondi. Adoro pasta (macarrão de qualquer tipo). Mas naturalmente não levei o convite muito a sério, haja vista que havia acabado de me mudar e não é muito costumeiro pessoas te chamarem pra jantar na casa delas, mesmo que sendo vizinhas, acabando de conhecer.
Desde então, de vez em quando via a Ana pela minha janela cuidando do jardim dos fundos de sua casa. Ou cuidando do seu pé de tomate, feito o pequeno príncipe cuidando da rosa dele. Casas do interior da Inglaterra não tem muitos muros ou cercas. Apesar de ela morar duas casas abaixo da minha, nos víamos com frequência à distância. Raramente via seu marido no quintal.
Apesar disso, quando encontrava Ana nas redondezas e resolvia cumprimentá-la, ela não parecia me reconhecer. Devido a senioridade dela e eu ter convivido com um avô com Alzheimer anos antes, suspeitei que poderia ser algo do tipo, mas mantive minhas suspeitas pra mim mesmo.
Não pensava muito sobre o assunto até que um dia, uma outra vizinha me confirmou que de fato Ana tinha algum tipo de o que eles chamam aqui de demência.
Não sou médico, muito menos habilitado para diagnosticar qualquer coisa ligada à saúde física ou mental de ninguém. Mas a confirmação da doença da Ana, me foi contado por essa vizinha que a conhece há diversos anos fez todo sentido.
Desde então, quando via Ana pela rua, mantinha os cumprimentos. Às vezes ela me respondia. Outras vezes fazia aquela cara de que não fazia ideia de quem eu era. E era assim, sempre, por quase três anos.
Engraçado observar que por diversas vezes eu sentia o cheiro de algo queimando e fumaça, e saia preocupado pra olhar se não era a casa da Ana pegando fogo. Felizmente nunca foi o caso. Era só a Ana queimando lixo no final das tardezinhas.
Mais engraçado ainda que eu achava que isso era apenas um costume de pessoas da fazenda ou coisa do interior de onde cresci. Não esperava uma senhora italiana morando na Inglaterra queimando lixo religiosamente durante a tarde.
Diversas vezes via a Ana passando na frente do meu jardim da frente quando ela ia ao supermercado. Sempre sozinha. Quase sempre com seu chapeuzinho, vestida de saia e roupas características de nonna italiana. Acompanhada de um carrinho de compras. Postura com a coluna levemente encurvada para frente. Parecendo muito aquelas idosinhas características de desenho animado.
Hoje recebi a notícia que Ana faleceu ontem a noite. Ana se foi exatamente um mês após seu marido falecer.
“Você sabia que a Ana faleceu? O marido dela faleceu há exatos um mês e ela ficava esquecendo disso. Então ela me contou inúmeras vezes sobre o fato nesse último mês. Até que ontem, ouvi um barulho, corri pra ver, chamei ambulância e polícia e a Ana se foi” – O vizinho entre a casa minha e a dela me contou hoje quando eu chegava em casa.
Fiquei pensando em quanto foi triste pra Ana esse um mês de ter que ouvir repetidas vezes que seu marido de muitos anos havia falecido. Repetidas vezes, pois a demência a fazia esquecer do fato. Mais triste ainda comunicar o fato inúmeras vezes aos conhecidos.
Apesar das duas tristezas de saber que Ana e seu marido se foram. De ver as luzes todas apagadas e a sua casa vazia. Perguntei um pouco mais da vida da Ana pra esse vizinho que a conhecia por muitos anos.
Ele me disse que Ana e seu marido tiveram uma vida longa e feliz. Ambos se foram com mais de noventa anos de idade. Tiveram filhos e uma boa vida.
Sentindo uma sensação de perda e tristeza, respondi pro meu vizinho que é isso que podemos esperar dessa vida. E acredito que é isso que podemos realmente pedir e esperar: uma vida longa e feliz.
Nosso jantar com a pasta nunca aconteceu. Não mais sentirei o cheiro de fumaça e sairei correndo pra perceber que é você queimando coisas no quintal. Nem ficarei aflito de ver você se apoiando na casinha de ferramentas caindo aos pedaços do seu quintal e achando que ela desmontaria sobre você a qualquer segundo. Nem ainda te verei passando da minha janela pra fazer compras toda admirável.
Não fomos amigos próximos. Mas ter a Ana como vizinha fez parte da minha vida de uma certa forma. Parte do cenário dessa cidadezinha do interior da Inglaterra que tanto prezo. E fico feliz em saber que sua vida foi longa e feliz.
Vá em paz Ana. Também o marido da Ana que eu nunca soube o nome.
Os analistas de requisitos reúnem os requisitos, descrevendo-os em algum formato e passam para os desenvolvedores.
Os desenvolvedores desenvolvem o produto e enviam para os testers testarem.
Os testers realizam os testes, encontram um defeito e a guerra se inicia:
-DEV: isso não é um defeito, VOCÊ que não entendeu isso direito.
__TESTER: claro que é! olha aqui a descrição que o analista passou. VOCÊ esqueceu esse pequeno detalhe.
Dev “buffa” de raiva, diz AHRAM, e vai corrigir o defeito. O tester, sai com a alegria e orgulho de um “trabalho bem feito“. Com ar de herói, e que se não fosse ELE, o código estaria explodindo em produção.
UFA, pensa o tester, salvei a equipe de teste receber uma métrica ruim.
A tensão entre dev e testers aumenta a cada release e defeito encontrado. Nesse ambiente não há muito espaço para amizade, em uma guerra não tão fria que segue instalada. Testers trabalham isoladamente dos desenvolvedores, cada um em seu silo. O sentimento entre devs e testers é sempre o de inimigos mortais.
Esse cenário lhe soa familiar?
Em equipes que se dizem ágeis esse cenário não deveria mais existir.
Em equipes ágeis NÃO EXISTEM HERÓIS.
Melhores Amigos
Em equipes verdadeiramente ágeis as responsabilidades são compartilhadas pelos membros da equipe. Não existe aquela velha divisão em que cabe a célebre frase “isso não é meu trabalho”.
As linhas de divisão de trabalho estão cada vez mais tênues. Testers não só desenvolvem e realizam testes, mas participam ativamente desde a concepção das features. Revisam código em pull requests, chamam a atenção para possíveis problemas. Testers e devs sentam-se juntos para programar algo, ou resolver algum problema que um ou outro sozinho não conseguiria resolver.
Em ambientes verdadeiramente ágeis, realizar entregas frequentes e de qualidade é responsabilidade de toda a equipe. E para tanto, faz toda a diferença estarem genuinamente juntos, colaborando diariamente.
Como as outras características de software, a qualidade não é somente trabalho dos testers e muito menos de qualquer indivíduo isoladamente.
Testers, developers, donos do produto discutem os requisitos juntos. Existe até um nome para essa técnica, conhecida como 3 amigos. Os cenários são descritos de forma clara e testável, falei sobre o formato de descrevê-los usando BDD nesse texto aqui.
Assim, focando em como podemos entregar software de qualidade frequentemente, devemos nos fazer duas perguntas:
1. Qual o problema estou resolvendo?
2. Quais os problemas eu deveria estar resolvendo e como isso impacta no resultado da minha equipe como um todo?
Certamente que partindo dessas duas premissas, sem focar em culpados por detalhes específicos, encontraremos formas de contribuir em nossas equipes. E isso significa, controbuit muito além da área específica em que fomos contratados para atuar.
Existem vários cursos maravilhosos em diversas plataformas como Udemy, Pluralsight, Code academy. Alguns custam bem pouco (em torno de 30 reais) outros custam na casa das centenas de reais.
Mas e se eu não tenho dinheiro no momento? como fazer?
E foi por isso que resolvi listar algumas formas de aprender programação DE GRAÇA.
YouTube
Foi-se o tempo em que o youtube só possuía entretenimento. Basta dar uma pesquisada pra encontrar material de tudo e qualquer coisa e em Português! Existem diversos cursos muito bem produzidos e sólidos, como:
Eu particularmente gosto muito de vídeos para aprender sobre diversos assuntos. Porém, há quem prefira ler os conteúdos, como se estivesse em um livro.
Em todo caso, como em outras áreas, no caso de programação, não adianta só assistir os conteúdos, é preciso praticar! E existem alguns tutoriais que fazem o passo a passo para que haja a leitura e a prática em cada passo. Eis alguns:
JavaScript e outras tecnologias web na Khan Academy. A missão da Khan Cademy é prover educação gratuita e de qualidade em uma infinidade de assuntos. O legal é que agora eles possuem esse conteúdo em Português. O site disponibiliza o material com um passo a passo. Em cada passo do curso podemos executar os comandos no próprio navegador, sem precisar instalar nada no computador.
Kotlin. Kotlin está popularizando bastante, não só para desenvolvimento mobile mas para microserviços também (caso em que uso atualmente). No site da própria linguagem existe uma ferramenta interativa para aprender, passo a passo da mesma forma que o Khan Academy. Eu mesmo utilizei essa ferramenta quando estava aprendendo a linguagem. Vale a pena conferir. OBS> esse é em inglês.
Aprender Java na Code Academy. Há alguns anos atrás todos os cursos da Code Academy eram gratuitos. Eu mesmo aprendi Ruby inicialmente com eles ainda quando era gratuito. O site é mto bem construído e você pode executar os comandos no próprio navegador, assim como os outros dois acima. Hoje vários cursos são pagos, mas esse de introdução ao Java ainda é grátis. OBS> esse é em inglês.
Se você tem vontade de aprender programação, nem sempre precisa desembolsar rios de tinheiro pois atualmente existem diversas ferramentas e fontes para aprender a programar gratuitamente. Encontre a que você mais gosta e inicie hoje mesmo!
Conhece alguma outra ferramenta/site/tutorial de boa qualidade mas que eu não citei acima? me envie uma mensagem que eu a avalio e adiciono nessa lista.
Todos com bastante experiência em suas áreas, bem versados em métodos ágeis e muito bons no que faziam.
A empresa é uma multinacional, com mais de 100 anos de existência, que fatura bilhōes por ano e com bases em diversos países.
Mesmo com tanta experiência reunida em uma mesma equipe e com todo o aparato por parte da empresa, enfrentávamos diversos problemas como:
diversas vezes atrasamos as nossas entregas, mesmo sendo uma carga de trabalho que nós mesmos concordamos em fazer em uma determinada sprint;
quase nunca estávamos em acordo quanto as estimativas das histórias;
parear para trabalhar com outro colega era sempre difícil, parecia que as coisas não fluíam quando estávamos juntos;
era difícil perguntar mesmo coisas simples uns aos outros; a sensação de estar incomodando o colega quando perguntava alguma coisa era sempre frequente;
a comunicação do estado atual de cada tarefa era complicada: mesmo sentando juntos, conversando todo os dias, respeitando as cerimonias do scrum, por vezes quando alguém dizia que seria capaz de entregar tal tarefa amanhã, isso não se tornava realidade.
Até então, eu nunca tinha trabalhado em uma equipe assim.
Na minha trajetória profissional, havia tido a sorte de sempre trabalhar em equipes que, por maiores as dificuldades enfrentadas, o espírito de equipe imperava, e sempre conseguíamos dar um jeito e realizar entregar consistentes.
Mesmo no tempo em que trabalhei em órgão público no Brasil, enfrentei alguns desafios mas ainda assim conseguimos superá-los.
Mas esse não parecia ser o caso dessa equipe.
E alguns meses após essa equipe ser desfeita, e os membros dela redistribuídos em outras equipes, constatei que realmente o problema era realmente essa equipe.
MAS, o que faltava nela?
Em resumo, consigo dizer que faltava espírito de equipe.
Parece algo vago e que charlatōes com títulos vagos usariam para definir um problema de natureza abstrata sem significar muito.
Seja como quiser chamar, o fato é que, de alguma forma, pessoas boas, bons profissionais isoladamente, as vezes podem não funcionar bem juntos.
Essa foi a pior equipe em que estive. E conversando com alguns outros membros dela, após estarmos alocados em diferentes equipes, ouvi a mesma constatação.
A equipe era ruim não pelas pessoas em si, mas por elas juntas simplesmente não funcionar. Apesar dos diversos esforços do scrum master e outros gestores de melhorá-la, a melhor decisão, foi no fim desfazê-la.
E assim, aprendi na pele, que ser um bom team player e ter bons team players ao seu lado fazem toda a diferença.
Uma boa equipe
Uma boa equipe, significa muito mais do que ter excelentes profissionais com enormes experiências juntos. Eles devem interagir bem entre si, e serem capazes de constituir uma master mind, como diria Napoleon Hill, que é muito maior, melhor e poderosa do que qualquer indivíduo.
Devem ser capazes de prover feedback e também recebê-lo com prazer. Criticar um colega é muito mais fácil do que receber críticas. Mas ambos os casos devem ser verdade e feitos com o objetivo de melhorar.
Se todos possuem a mesma visão quanto ao seu papel de dar suporte e apoio aos demais membros de uma equipe e fazer muito mais que seu trabalho diário, as coisas fluem de uma forma incrível.
E você, já esteve em uma equipe ruim? o que fez para melhorá-la?
Pensei comigo: como assim? é praticamente dizer que meu trabalho não deveria existir. Quase ofendido, chateado, magoado, tipo criança quando xinga a mãe.
Mas respirei fundo, fiz cara de ser humano altamente maduro e evoluído e segui em frente. Porém, essa ideia não me saiu da mente tão rápido ou facilmente.
Sempre vejo esses questionamentos como oportunidades de crescimento. Defendo sempre que testers devem saber tudo de tudo. Quanto mais soubermos melhor seremos no que fazemos. Pontos de vista contrários são ótimos para nos confrontar quanto ao que sabemos e evoluir.
E essa “pulga atrás da orelha” me levou a grandes discussões sobre o assunto com alguns excelentes engenheiros de software tanto daqui quanto dos USA. Não foram discussões no sentido programa do ratinho ou programa da tarde mal sentido. Pelo contrário, o objetivo foi racionalizar sobre o que foi dito, pedindo esclarecimento e tentando ver pelo ponto de vista do outro.
Existe sim quem defenda que o teste está morrendo (ou morto, para os mais catastróficos).
Gostaria de dizer que após muito refletir, concordo em partes.
Concordo que o teste totalmente manual, da forma como era feita totalmente isolada e somente após a construção do software não seja mais adequada no mundo agile.
Além de automatizar para agilizar, precisamos estar integrados e remando para o mesmo objetivo, juntos, e com informação propagada igualmente nas equipes desde o inicinho da produção de alguma funcionalidade.
Em um mundo ideal testers realmente não deveriam existir. Em um mundo ideal não existem bugs. Os desenvolvedores realizam todos os testes unitários e de integração perfeitamente, respeitando as restrições das frameworks. As complexidades de integração entre componentes do software não geram novos defeitos. Não há falhas de comunicação nem especificação entre as diversas partes da equipe, localmente ou espalhadas pelo globo. Mas além disso, e principalmente:
O MUNDO IDEAL NÃO EXISTE
Se você já escreveu uma redação ou qualquer outro texto na vida, sabe bem que mesmo que o façamos com toda a atenção, revisemos diversas vezes sempre escapa algum erro.
Basta que uma outra pessoa leia nosso texto uma única vez que essa pessoa encontre esses erros e pontos de melhoria que não enxergaremos nas diversas revisões.
Simplesmente porque temos o viés de quem produz uma obra, de defender o que produzimos e isso torna difícil um olhar imparcial sobre nossa própria produção.
Quando testamos nós mesmos as linhas de código que produzimos, mesmo que de forma inconsciente, tendemos a fazer testes de confirmação ao invés de testes destrutivos como um tester faria.
É uma diferença de mindset mesmo. O mindset do teste é destrutivo enquanto o mindset do desenvolvimento é construtivo. Dois objetivos inerentemente diferentes, apesar de complementares que buscam produzir software de qualidade.
Fazer software é muito parecido com escrever texto. Só isso, tudo isso, muito mais que isso. É tentar traduzir da cabeça das pessoas as suas necessidades para o mundo da programação. Do abstrato das necessidades para o abstrado do código solucionando os problemas reais.
E essa atividade está sujeita a erros. Muitos erros. Vários erros!
“Partes que foram feitas independentes e testadas e que funcionam sozinhas deveriam funcionar bem juntas”
Essa afirmação parece ser verdade mas infelizmente para o mundo do software não é. Para quem conhece engenharia de sistemas isso não é de se assustar. Mas para quem nunca ouviu falar disso, procure saber sobre propriedades emergentes dos sistemas.
A complexidade que temos que lidar ao produzir grandes produtos de software escaláveis, distribuídos, confiáveis e tolerantes à falhas é enorme. E em cada etapa – requisitos, projeto, desenvolvimento, integração, teste – mais e mais erros são inseridos no processo de produção.
Frente a isso, a conclusão é:
o teste de software não morreu, e sinceramente não o vejo morrendo tão cedo. O teste evoluiu, da mesma forma como os processos, ferramentas e linguagens também evoluíram.
E continua extremamente relevante em um mundo altamente competitivo com clientes cada vez mais experientes e exigentes por experiências de usuário maravilhosamente desenvolvidas.
Sim, eu sei que é uma afirmação um tanto dura. E também sei que pode parecer obvia para alguns.
No entanto, durante minha carreira, eu a ouvi diversas vezes. As vezes direcionada a mim, as vezes direcionado a outros.
Embora nem sempre com essas palavras, em momentos ela vinha disfarçada e abrandada como diferenças salariais para um mesmo cargo e experiência parecida. Mas era sempre e exatamente com o mesmo sentido, se soubesse ler nas entrelinhas.
Confesso que as primeiras vezes isso me enfureceu pois sou do tipo que gosto de aprender tudo de tudo. Conhecimento para mim é diversão, e uma das coisas mais importantes da vida. Acredito sempre que não existe tal coisa como se ter conhecimento demais.
Levou um tempo para que a entendesse e por fim concordasse com essa afirmação.
Deixe-me ilustrar: suponha que aconteça um acidente de carro e uma pessoa seja ferida durante o acidente.
Passando perto do local há dois médicos:
Doctor T: teórico, ampla educação em medicina, com conhecimento profundo em como realizar procedimentos, mas com pouca experiência prática em como de fato realizá-los;
Doctor P: conhecimento teórico o suficiente, educação o suficiente, com conhecimento o suficiente em como realizar procedimentos, mas com muita experiência prática em como de fato realizá-los.
Eu sei, eu sei, é uma situação exagerada e um tanto quanto extrema. E também entendo que performar bem em determinada situação depende de inúmeros fatores palpáveis e não palpáveis como: cansaço, estresse, equipe em que se esta inserido, processo utilizado, etc etc etc.
Trazendo agora para o mundo do software. Você fez graduação em uma ótima faculdade, fez mestrado, tem inúmeras certificaçōes. Isso demonstra que você é um ótimo teórico e bom estudioso. Perfeito acadêmico.
Mas isso significa que você será o melhor na sua empresa? na sua equipe? não necessariamente.
Entenda que não estou defendendo de forma alguma não fazer uma graduação ou passar pela educação formal. Fui professor universitário, e ensinar é um amor que eu tenho pra vida. Vejo valor, e muito em se ter educação formal, por diversos motivos que não cabem aqui agora. Mas só o aprendizado pelo aprendizado, sem a ação com ele irá te recompensar em meios comerciais? dificilmente.
Existem casos por exemplo, em que pessoas sem educação formal (graduação/mestrado) mas com garra, dedicação e humildade, desempenham de longe muito melhor do que alguém extremamente academicamente educado mas com arrogância demais para assumir que não sabe algo, aprender e se desenvolver mais. Já vi isso pessoalmente, e continuo vendo, mesmo na empresa global em que estou atuando no momento.
O simples fato de saber muito sobre algo não lhe garante as melhores posiçōes no mercado. Saber por saber, sem saber fazer não é muito valorizado. Não é assim que o mercado recompensa indivíduos.
Parece muito contra intuitivo não? mas acontece, e muito. Não adianta se esconder atrás de seus títulos quando se deparar com algo que tem dificuldade em fazer. Aquele defeito catastrófico em produção não irá se resolver sozinho se você jogar seus títulos neles. E ainda, lembre-se que açōes falam muito mais alto que palavras. Não importa muito o que ou o quanto você diga algo, com o tempo, a inexperiência da parte prática fica evidente para quem já passou por esse processo.
Ganha-se muito mais assumindo que não sabe, “descendo do pedestal” e aprendendo com outros do que sustentar sempre a pose de detentor de todo conhecimento. Assim, alinha-se o conhecimento teórico com o prático. Essa é uma forma de definir inteligência, sabedoria e expertise.
A dura verdade é que somos recompensados para fazer algo com o que sabemos e agregar valor no ambiente em que estamos.
