Ser ágil é estar dentro do problema

agil_problema.jpg

  • Onde o time está e onde quer chegar? não é uma tarefa simples de fazer, pois esbarra na mudança da cultura dos profissionais da área. O estudo sobre o uso do multi-skill e não single-skill, reduz etapas e deve ser uma prática constante, com isso a equipe de teste utiliza os atributos qualitativos de funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade, planejamento e analise de uma equipe ágil de teste constrói e verifica a acurácia dos testes.

O valor de cada indivíduo vai dar o resultado da equipe, mas para isso é preciso desenvolver a agilidade, o que torna os problemas de um projeto quase que inoperante. Há uma maior proximidade e interatividade maior das pessoas, o poder está na equipe quando se trabalha com ágil. Existe uma reclamação continua e constante quando uma equipe não trabalha com nenhum tipo de processo, somente passa o serviço e depois cobra, há um grande desgaste para ambas as partes e sempre o projeto acaba atrasado. Outro ponto positivo para atenuar o fracasso é quando a equipe de teste não entra no começo do projeto ou não está incluída na hora de vender o projeto ao cliente para baratear, os desenvolvedores precisam também fazer este papel dificultando o andamento de todo o processo.

Como desenvolvimento de software e de liberação torna-se mais complexo do que nunca, as organizações estão começando a adotar práticas que irão agilizar seus fluxos de trabalho e que lhes permitam apoiar metodologias ágeis, bem como ajudar as equipes a um melhor desempenho através de projetos ativos. Entendendo melhor as questões de projeto e potencializar a equipe alcançar uma maior maturidade de aprendizagem e metas.

As equipes podem aproveitar para colher benefícios significativos e transformar a maneira como eles pensam sobre processos de teste e prevenir definição de riscos numa fase inicial, como o burndow (previsibilidade) não é apenas para a equipe de teste, mas de todos no time porque todos têm uma meta em comum, e essa meta é a estratégia do time.

Nesta direção, criar um time ágil para ter um projeto ágil, é estar dentro do problema, sem isso, teremos um gerente de projeto como capataz sem inspiração, proporcionando uma falsa sensação de segurança. Uma equipe ágil prepara profissionais a serem Software Engineer, acaba com a rotina de somente testar ou desenvolver, surgem responsabilidades tais como:

• Analisar as ideias e opções;
• Descrever o projeto;
• Discutir com outras pessoas sobre o projeto;
• Aprender outras atividades;

Não é necessário ser um especialista numa área, mas conhecer bem todas as áreas. Ágil consegue fazer isso e também transformar muitos profissionais qualificados, mas é preciso mudar o ambiente de trabalho, como?

• Baixa formalidade (sem horários fixos e sem roupas formais)
• Criar uma sala de descompressão
• Incentivar com cursos e certificações

A metodologia ágil no projeto é também um meio de verificar a produtividade dos colaboradores, equipe e empresa. Não há função de analista, projetista, arquiteto, etc. Na equipe, todos têm qualificações para analisar, projetar, desenvolver ou testar da melhor maneira possível. Todos devem estar cientes dos requisitos, prazos e principalmente: o objetivo. Nas reuniões da equipe são discutidos o andamento dos projetos, dificuldades, mudanças e sugestões.

Agilidade transforma testadores e toda a equipe em generalistas, portanto, podemos dizer que a empresa terá uma “coleção de bibliotecas” para reaproveitar o trabalho e dados para o melhor andamento no próximo projeto.

Oscar Correia – Engenheiro de Testes no Fit - Flextronics
– Graduado em Análise e Desenvolvimento de Sistemas
– Atua em projetos voltados para Openstack, RFID, Recycling, Certificações e Ensaios
– Certificação: CSM (Certified Scrum Master)
– Escritor contratado pela editora Tate Publishing, USA

@Oscar-Correia disse:

Não é necessário ser um especialista numa área, mas conhecer bem todas as áreas.

Tava indo bem até a parte acima… eu entendo a necessidade de expandir conhecimentos e barreiras e parar de separar tarefas para pessoas específicas. Isso causa bottlenecks, desperdício, logo, rui. Porém, meu valor dentro da equipe está tanto na minha habilidade de saber cooperar quanto na minha especialização.

Tem um excelente texto que compara Agile e Special Forces e fala exatamente desse meu ponto de vista - ver em http://antonymarcano.com/blog/2011/05/updated-lessons-learned-in-close-quarters-battle/

Abraços !

@Oscar-Correia disse:

A metodologia ágil no projeto é também um meio de verificar a produtividade dos colaboradores, equipe e empresa. Não há função de analista, projetista, arquiteto, etc. Na equipe, todos têm qualificações para analisar, projetar, desenvolver ou testar da melhor maneira possível. Todos devem estar cientes dos requisitos, prazos e principalmente: o objetivo. Nas reuniões da equipe são discutidos o andamento dos projetos, dificuldades, mudanças e sugestões.

Você acredita mesmo que todos têm as qualificações para atuar em qualquer papel no projeto?
Eu sei que pregam isso mas eu não consigo enxergar dessa forma (confesso que gostaria rs), pois temos skills, eu acredito que todos sim conseguem ajudar em papéis diferentes e que sim tentará fazer da melhor maneira possível mas não que será da mesma forma que se executasse um papel de acordo com seu perfil.

Acredito que a conscientização do time de colaboração, de que todos somos responsáveis que no fim é o que diz a última frase é super válido, agora afirmar que um desenvolvedor será tão produtivo fazendo um teste cruzado quanto codificando isso não consigo assimilar, não é a praia dele, a tarefa será concluída, mas não é a mesma coisa que uma pessoa com esse skill executar.

O que acha a respeito desses pontos Oscar?

@Gabriel-Oliveira Olá Gabriel tudo bem? fico muito honrado com seu comentário. Não sei se tem acesso ao https://www.scrumalliance.org/, lá você vai entender melhor sobre o que citei.

Ou pode acessar o artigo que escrevi que explica de forma detalhada, com esse artigo fui chamado para ser palestrante em uma trilha de testes (São Paulo) e recebi um e-mail da Petra Cross, gerente de TI da Google, agradecendo a ajuda através do artigo: http://convergecom.com.br/tiinside/services/01/07/2015/estrategias-para-uma-equipe-de-projeto-agil/

Você consegue se especializar em várias áreas, por exemplo, quando a equipe está alinhada e consegue uma vez por semana fazer um workshop para que os demais colaboradores da equipe possam ficar na mesma página, esse é um exemplo de várias. Espero ter ajudado.!!

@afizac Olá tudo bem? muito contente por seu comentário. Creio que não me fiz entender, quando falo que não há função de analista, projetista, etc, é porque todos do time (e não equipe) são chamados de “Desenvolvedores”. Com isso o time fica mais unido e acabam adquirindo outras qualificações.

O processo ágil lapida a pessoa, mostrando suas qualificações. Conforme for passando o tempo, a pessoa acaba adquirindo o C H A V S, o líder do projeto pode ajudar usando a “JANELA DE JOHARI” para tabular aquela pessoa e torná-lo como um lider e ele usar a mult funcionlidade. Espero ter ajudado, forte abraço e tenha uma boa semana.

@Oscar-Correia, eu conheço razoavelmente bem o Scrum by the book e conheço um tantinho também o Scrum de forma prática. Dessa vivência, aprendi que a realidade muitas vezes supera o que esperaríamos.

Pessoas, são diferentes e tem diferentes perfis e características e skills. Dizer que todos dentro de uma equipe ágil devem ter os mesmos skills é uma simplificação didática da realidade. O seu post e seu comentário aqui estão pregando essa simplificação que, embora importante para explicar o uso de ágil e a diferença entre equipes ágeis e não ágeis, continuam sendo uma aproximação utópica da realidade.

Diversidade e cooperação são características que essa simplificação está ignorando. Trabalhar com pessoas dispostas a te ajudar e a receber ajuda, mesmo tendo jeitos diferentes de pensar, culturas diferentes da sua e skills diferentes das suas me parece uma realidade muito mais plausível do que o sugerido.

Claro, todos do time deveriam saber fazer todas as tarefas propostas. Mas um Dev de 10 anos de experiência vai corrigir bugs bem mais rápido do que eu, especializado em Testar. Embora eu também soubesse o que precisa ser feito e como fazer, a especialização individual faz a diferença. Exigir o mesmo nível de especialização de todos do time em todas as tarefas é utópico demais para ser factível.

Meus cents:
Sobre os papéis, ninguém nasce desenvolvedor, testador ou arquiteto. Todas as competências são adquiridas com estudo e prática. Conheço times que só tem desenvolvedores e eles desenvolvem e testam muito bem, não tendo a necessidade de um profissional com formação/experiência em testes. Assim como conheço times que não sobreviveriam se não tivessem alguém com essas especialização. Vai bastante da maturidade e do interesse dos envolvidos em adquirir e melhorar essas competências. Uma coisa bem legal que um dos times aqui fez foi colocar como meta 2015 pro time, que os devs “aprendessem” a testar e os testadores “aprendessem” a desenvolver. E assim todos estão trabalhando juntos e compartilhando conhecimento para atingir essa meta. Eu mesma comecei com testes, mas com o passar do tempo na área vi a necessidade de melhorar minhas habilidades de desenvolvimento e infraestrutura.
:)

Samy

@Gabriel-Oliveira Grande Gabriel, obrigado por seu comentário, fico feliz em conhece-lo. Uma vez por mês escrevo um novo artigo, vou postando por aqui também!! bom trabalho.

-Oscar Correia

@Samanta-Cicilia Minha amiga Samanta, seu comentário foi deveras importante. E de grande importância, vou tentar fazer aqui o que você fez aí em relação a meta.!!

-Oscar Correia

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.