A seguir faço um “resumo” da discussão, quem quiser conferi-la na íntegra, é só acessar esse link.
SCRUM e Testes: Quais as melhores formas de implementar?
Para o Marcelo Andrade não há uma melhor maneira, e você terá que descobrir a melhor forma de implementar o Scrum:
Não há melhor maneira. Cada caso é um caso e ninguém vai poder responder a esta pergunta para você, a não ser você mesmo[1].
Scrum é empírico, e por mais que alguém se esforce para lhe dizer o que você deve fazer, ninguém está na sua pele, não tem a sua experiência nem vive a realidade da sua equipe. A responsabilidade de descobrir a melhor forma de implementar é SUA.
[1] http://tasafo.wordpress.com/2010/01/14/voce-e-responsavel-pelo-software-que-desenvolve/
Eu concordo com o Marcelo, não há uma melhor forma de implementar Scrum, pois ela irá variar caso a caso. O que existem são formas de implementar Scrum, como por exemplo:
- Fazer um projeto piloto;
- Treinar a equipe (na primeira vez que a gente implementou o Scrum, tivemos treinamento de 3 dias, com o Scrum Master do projeto que já tinha feito o curso de CSM);
- Implementar de forma gradativa;
- Envolver o PO, antes mesmo de começar a implementação.
Quais são os maiores desafios quando implementamos o Scrum em uma equipe de Teste de Software?
O Marcelo Andrade acha estranho o Scrum ser implementado por uma equipe de Teste de Software, por ter a opinião de que o Teste de Software não deveria existir por si só:
Huh… me prece estranho isso. Teste de software não existe (ou não deveria existir) por si só. Não é o fim, mas sim um meio para se gerar valor ao cliente. Mas enfim…
O comentário do Marcelo é bem pertinente. E na minha opinião: desde a revolução industrial, lá pelo século XVIII, surgiu um tal de capitalismo. E até hoje, ninguém descobriu ou conseguiu implantar um sistema econômico melhor. E o outsourcing de Teste de Software gera bastante capital, por isso que eu não acho estranho o Teste de Software existir “sozinho”. 
Logicamente, que há as vantagens e desvantagens do outsourcing, mas na minha opinião o cenário ideal de desenvolvimento de software é tendo uma equipe de Teste de Software interna e no caso do Scrum, o próprio time teria especialistas em Teste de Software.
A Renata Eliza, ao invés, de falar sobre as dificuldades comentou sobre os benefícios que o Scrum traz:
Vou descrever os benefícios efetivos que um uma Equipe de Teste traz ao Scrum, já implantado.
Essas informações se baseiam no resultado do mapeamento que estamos realizando no trabalho de conclusão de curso, cujo tema é: Scrum no Teste de Software.
Um fator que contribui para o sucesso do Scrum é a maneira como se trabalha em equipe, dividindo todos os recursos, em pequenos grupos, sendo sempre equipes pequenas, isso faz com que todos sejam mais participativos e se empenhem melhor em suas atividades. Com a participação ativa de todos, o andamento do processo acontece de forma clara, que de certa forma, gera também, aumento de produtividade.
Com a participação da Equipe de Teste, representada por exemplo por um Analista de Teste, em um Time do Scrum, podemos identificar os seguintes benefícios:
• Integração do time;
• Apoio de quem está desenvolvendo código durante a execução dos testes;
• Apoio de quem está testando código durante a codificação;
• Participação mais direta e ativa do profissional que está testando o software;
• Profissionais que estão desenvolvendo código interessados em aprender sobre teste;
• Profissionais que estão testando código interessados em aprender sobre programação;
• Agilidade, interação com testes;
• Acompanhamento de defeitos pelo profissional que está testando o software;
• Analistas de Teste deixaram de ser reativos para serem pró-ativos.Em suma, quando a Equipe de Teste participa efetivamente do Scrum, a equipe trabalha mais unida, a qualidade e o retrabalharam reduzem consideravelmente.
Então, depois de superadas as dificuldades de implantação e apesar da resistência inicial, no geral as empresas que aderem à utilização de um Processo Ágil como o Scrum, em um time que inclui a Equipe de Teste, tem boas experiências com ótimos resultados.
A respeito da colocação da Renata sobre o “sucesso do Scrum”, faço a seguinte colocação e levanto a uma questão:
A maior preocupação que a gente precisa ter não é com o sucesso do Scrum, aliás, como seria a definição de sucesso? O by the book? Colocando todos os princípios ágeis em ação?
Sinto muito, mas até o que vem da prática para a teoria (ex.: princípios ágeis) não é aplicado em todas situações, afinal, não existe fórmula mágica, receita de bolo, bala de prata, seja lá o nome q você for dar.
Quando aplicamos Scrum ou qualquer outra metodologia, estamos fazendo isso buscando o sucesso do nosso projeto, esse é e deve ser o foco.
Nas experiências que tive não conseguimos implantar todas as práticas do Scrum (famoso Scrum-but rs), mas mesmo assim, as considero sucesso, pois conseguimos melhorar e em muito, o nosso trabalho.
Aproveitando, segue o relato do Guilherme Chapiewski (ex Globo.com) que conta como estavam as coisas após mais de 2 anos de Scrum, mostrando bem o quanto é necessário adaptação e melhoria contínua, quando buscamos desenvolver software de maneira profissional:
http://gc.blog.br/2009/12/04/2-anos-de-scrum-e-agile-na-globo-com-e-algumas-coisas-que-eu-aprendi/
Segundo o Felipe Silva:
Primeiro a resistência das pessoas e principalmente do cliente, mudanças nas rotinas podem fazer o cliente esperar o feedback no momento de “sempre” e não ter ou ter o feedback de uma diferente ou através de uma pessoa diferente (isso é necessário alterar ou criar novos papéis organizacionais), treinamentos e cultura devem ser adquiridas pelo time, levantar uma análise completa que possa garantir um resultado satisfatório já na célula piloto (que eu recomendo que essa essa célula exista, para amadurecer um pouco o novo processo antes de espalhar para todo mundo), falta de comprometimento dos lideres do time (pois estes tem que fazer o novo processo funcionar nem que for na marra, se quiser ter sucesso), e o mais difícil pra boa saúde de qualquer processo é conseguir fazer as pessoas fazerem a coisa do jeito que tem que ser automaticamente (processo “no sangue”) ao invés de fazerem empurrado, por obrigação ou sem saber do valor agregado pelo mesmo, o processo ter que ser puxado e não empurrado pelo time.
Primeiramente, eu vejo que há dois contextos principais: o de uma equipe independente de fora (outsourcing) e o outro no qual existe uma equipe independente de Teste de Software interna.
A minha primeira experiência foi participando de uma equipe independente de Teste de Software interna, na qual enfrentamos os seguintes desafios/problemas:
- Alguns conhecimentos estavam apenas com uma pessoa, o que dificultava uma melhor interação de alguns membros da equipe com os demais;
- Resistência por parte da equipe (poucos inovadores e pessoas que adotam cedo);
- Rotina de trabalho muito intensa;
- Falta de uma experiência prévia com Scrum.
Alguns desafios/problemas mais genéricos, que costuma ser enfrentados durante a implementação do Scrum:
- Falsa expectativa “Scrum irá resolver todos os nossos problemas”, muito pelo contrário, Scrum irá JOGAR NA SUA CARA OS SEUS PROBLEMAS!!! (desculpa a caixa alta rs mas é sério isso);
- Mudar a cultura é algo muito difícil;
- O PO atuando apenas como um envolvido, ou pior ainda, pouco cooperando com a equipe;
- Definir o conceito de pronto e como entregar valor para o cliente.
O Jorge Diz deu a sua contribuição iniciando com uma ressalva:
Ressalva: minha experiência é mais na implementação de Scrum em equipes de desenvolvimento, com foco nas atividades de teste. Mas mesmo assim acho que dá para contribuir.
Um desafio neste contexto para quem defende testes é convencer o restante dos participantes sobre o retorno do investimento das atividades de teste e conseguir que as estimativas de cada user story e tarefa incluam o esforço de verificação e validação. Cartões devem poder ser adicionados no planejamento para atividades de teste que afetem todo o projeto: alterações do ambiente de teste, execução de testes de sistema, revisões.
No afã de mostrar que uma abordagem ágil funciona, algumas equipes caem na armadilha de forçar um ritmo que não considera os testes como prioridade. É necessário mostrar que isto provoca um endividamento técnico, riscos maiores e diminuição da capacidade de entrega que a equipe consegue sustentar. Fazendo uma analogia com motores, testes são o lubrificante dos processos ágeis.
Por que não é fácil implementar Scrum?
Segundo o Marcelo Andrade:
Para funcionar, Scrum *deve* mostrar todos os seus problemas, suas dificuldades, as fraquezas da sua equipe, seus erros, tudo o que sua equipe tem de ruim, tudo aquilo em que você está falhando, logo, de maneira crua, na sua cara, para todo mundo ver.
A facilidade em se adotar Scrum será diretamente proporcional à sua capacidade de aceitar seus próprios erros.
Você vai ter muito trabalho para fazer isto funcionar. Mas Scrum não é para preguiçosos[1]. Inspecionar e adaptar sempre. Aprenda a lidar com tudo isso, buscando o aprimoramento
constante de sua equipe e de seu produto e, depois de algum tempo, você poderá ter um caso de sucesso.Tenha em mente que em qualquer ambiente desenvolvimento de software você sempre terá problemas. A questão é que em
metodologias ágeis eles aparecem logo cedo, quando você tem tempo de sobra para corrigi-los.Se você “dá um jeitinho”, se “empurra com a barriga”, se “varre para debaixo do tapete” ou se transfere responsabilidades, você não é ágil.
[1] http://visaoagil.wordpress.com/2009/06/07/agile-nao-e-para-preguicosos/
O Felipe Silva deu a sua opinião dizendo:
Pelo mesmo motivo que não é fácil implementar qualquer outro projeto, pois processo são feitos de pessoas para pessoas, e pessoas tem problemas, pessoas tem opinião própria, pessoas tem preguiça, pessoas tem ego (principalmente quando é o “caro” do processo antigo), outra coisa é porque Scrum ainda é um incógnita para maioria, não é simples definir um processo Scrum, outra coisa é que as vezes descobre-se que para implementar tal mudança tenha que se fazer mudanças de grande risco à organização e estas fazem de tudo para contornar a situação (gerando o falado “Scrum-but”) o que não vai ser eu quem vai dizer se é errado ou certo, quem dirá isso será o tempo.
Porque não é uma questão de mudar apenas o processo, e sim mudar as atitudes, pensamentos, intenções, etc das pessoas.
Como o Felipe disse “o processo ter que ser puxado e não empurrado pelo time”.
Segundo o Jorge Diz:
Por quê é difícil implementar Scrum ? Desconfie se for fácil, porque mudar não é.
Ao introduzir novas práticas, reavaliamos nossas crenças e prioridades. Há uma linha tênue entre adaptar as práticas de Scrum à realidade e descaracterizá-lo (Scrum, but …): é muito fácil cair nesta armadilha.
É fácil confundir “Scrum Master” com gerente, principalmente quando a mesma pessoa que na semana passada tinha um papel passa a ter outro na segunda-feira. A palavra “master”, ainda mais se o fulano adicionar “certified”, passa a idéia de hierarquia e pode virar um símbolo de status. Prefiro o termo “facilitador” e colocar no papel alguém que no passado não tenha sido “dificultador” como certos gestores que só repassam ordens de cima.
Parte do sucesso de Scrum é porque, quando bem implementado, funciona. Se implementado na sua essência, problemas que antes ficavam ocultos passam a aparecer, e é necessário ter coragem e apoio da gestão para não abandonar e sair dizendo por ai que isso não funciona.
Mas também porque podemos dizer que usamos Scrum porque seguimos alguns rituais e mesmo assim ficar na zona de conforto. Funciona bem como marketing, mas não como forma de entregar valor ao cliente.
Dizer que se faz Scrum sem mudar as nossas técnicas é suspeito: o normal é que tenhamos que correr atrás dos problemas que já existiam e que Scrum bem implementado consegue fazer aparecer.
Como foram as suas experiências com a implementação de Scrum?
O Marcelo Andrade disse:
Nossa… por agora vou ficar devendo. Desenvolvendo software só tive uma oportunidade de (mal)utilizar Scrum (o que chamamos de Scrum-but, na verdade). Valeu pelo aprendizado. Mas teria muita coisa para escrever por hora (e já são quase 4am). Mas vale lembrar os 5 princípios do XP:
* Comunicação
* Coragem
* Feedback
* Respeito
* SimplicidadePor que minha experiência foi de Scrum-but? Porque teoricamente usávamos Scrum, MAS não usávamos testes (sem feedback). Teoricamente usávamos Scrum, MAS a equipe não tinha autonomia (sem respeito e sem simplicidade). Teoricamente usávamos Scrum, MAS não podíamos falar diretamente com o cliente (problemas de comunicação). Estou simplificando, mas basicamente foi isso mesmo. Também houve coisas boas e espero falar melhor noutra oportunidade.
O Felipe Silva compartilhou as suas experiências falando:
Ainda em fase de implementação, e neste cenário temos: Cliente resistente, fazendo de tudo para “barrigar” as mudanças e cair no esquecimento, mudanças propostas excelentes, papeis melhor definidos, novos papéis, time mais unido, mesmo no “Scrum-but” já temos bons resultados e satisfação do cliente (que não assume que a mudança do processo possibilitou a melhora), mas nossos lideres estão fortes e a nova metodologia vai entrar aos poucos.
A Lorena Lyra comentou a sua experiência:
Aproveito aqui para falar que na empresa em que trabalho começamos a usar o SCRUM.. e notamos logo de cara a diferença que se pode ter ao usar uma metodologia assim.Bom, no começo foi difícil, pelo fato de não entendermos como o nosso caso se aplicaria ao SCRUM… foram muitas dúvidas que tivemos de correr atrás para tirar. Mas uma vez que passamos pela fase inicial o resto foi moleza.Agora estamos tentando inserir a fase de teste. Não é o simples teste que os programadores fazem ao desenvolver o programa, mas o teste real com direito a fazer os requisitos e desenvolver toda a fase de teste que se tem de fazer. Mas de antemão digo a todos que não tem sido muito fácil e que muitas vezes ele preferem um “teste ai” do que um teste correto onde precisamos do essencial, TEMPO.
E uma coisa que fica bem clara com a sua utilização, é que o que faz a coisa acontecer são as pessoas, e pessoas interagindo, conversando e discutindo. E não cada um na sua baia.
Como vocês fazem para fazer os testes de que precisam e que demanda tempo quando se tem uma sprint de curto tempo?
(aliás, Risk Based Testing sempre hehe)E quando for definida a sprint, o tempo dos testes precisam já estar incluído. Milagre ninguém faz, mas para minimizar o impacto pode-se adotar algumas estratégias como por exemplo:* Fazer testes exploratórios pesados nos primeiros instantes (horas) do teste – isso funciona se sua equipe é sênior e conhece os requisitos tanto ou mais do que quem escreveu – para pegar “todos” os defeitos (70%-90%) logo no início e fazer o carro andar
* “Apertar” (saudavelmente) o time e aumentar a meta individual de cada um por dia acaba funcionando (se o time for sênior não vai impactar a qualidade, pois sabem que fazer mais rápido não é fazer de qualquer jeito)
* Buscar continuamente por novas ferramentas ou procedimentos que reduzam o tempo gasto extra-execução de testes (ter alguém(uns) sempre pensando em novas idéias e criando programas/aplicativos ou qualquer outra coisa)
* Caso o time for grande dividir ele em células ajuda na administração, comunicação e delegação de tarefas (que é um gargalo de risco)
* Os lideres de cada célula sempre tirarem tudo da frente dos executores dos testes, é importante que os testadores trabalhem focados sem outros assuntos ocupando a cabeça deles (técnica de pomodoro entra bem aqui)
* Criar novos papéis se necessário (se houver alguma tarefa que todo mundo faça toda dia gastando uns 30min-1h por dia, por que não colocar uma pessoa para cuidar disso)
* O Scrum master deve ter visão real do status atual
* Testes automatizados sempre que possível irá ajudar na próxima sprint
* Se testar 100% é impossível priorize os testes (como dito pelo Fabrício: Risk Based Testing)
* Simplificar processos sempre que necessário (com um time sênior – novamente falando – você pode simplesmente deixar de escrever casos de testes detalhados com um monte de passos e escrever apenas dois ou três passos que são os passos da validação, ou então nem escrever passos apenas escrever os detalhes: validação em questão, descrição do cenário)
* Fazer das células especialistas em partes do sistema ao invés de todo mundo testa tudo (embora muitos discordem de fazer isso, é fato que isso faz com que o time inteiro saibam tudo do sistema em pouco tempo)
* As tarefas devem ser executadas em tempo de execução e não também planejadas em tempo de execução (o time tem que estar igual um atleta posicionado na linha de saída só esperando pelo sinal para sair correndo)
* E por final as estimativas devem satisfazer a capacidade real do time, quando o time está em sua capacidade máxima de esforço não tem jeito de atender ao prazo sem aumentar a capacidade, aumentado o time.O fato é que a tendência é as sprints ficarem cada vez mais apertadas, então antes que não haja mais saída, trabalhe hoje pensando em facilitar a sua vida amanhã, e isso não ruim se olhar pelo ponto de vista feliz da coisa, isso pode ajudar trazer mais projetos e satisfazer os clientes internos e externos.
O Scrum que utilizamos, inclui também um passo que se chama “teste”. Neste passo eu poderia incluir os teste dos quais são necessários ou o certo seria cria um scrum em paralelo, onde teria se, em suposição, um tempo a mais para criar e desenvolver todo o passo a passo dos testes necessários ?
Trabalho com Scrum a mais ou menos 1 ano, e inclusive já realizamos alguns projetos com sucesso com este framework (se é que posso chamar Scrum assim) e outros nem tanto, mas que serviram como um grande aprendizado.O que posso falar a respeito sobre os testes dentro do Scrum:
1) Deixamos de descrever casos de testes, estes passaram a não ser tão detalhados como antes e possuem uma nova nomenclatura, chamamos de “Critérios de aceitação”. Cada user story descrita que será priorizada para o sprint possui um ou vários destes critérios. Os critérios de aceitação nada mais são do que os testes de aceitação, que são casos de testes em mais alto nível.
Como as user stories são descritas antes da sprint começar, os critérios de aceitação também são elaborados nesta fase. Ou seja, analise, levantamento de requisitos e documentação não fazem parte da sprint. (Isso tudo no meu caso)
2) Essas user stories são quebradas em tarefas (atividades) e são devidamente pontuadas pela equipe na reunião de planejamento do sprint. Esta pontuação leva em consideração dificuldade e esforço de implementação e (quem diria
3) Nosso kanban de atividades possui as fases: A fazer, Fazendo (que foi sub-dividida em: Implementando e Testando) e Pronto. O fazendo foi subdivido, mas apenas porque temos um número maior de pessoas desenvolvendo do que testando. Na maioria dos casos os testes estão juntos com a implementação e para isso temos usado a prática do TDD.
Atividades mais específicas, que necessitam testes de carga por exemplo também acabam passando pela fase de testes no kanban, mas digamos que estas são diminutas perto do todo.Outra coisa: O Scrum é simples mas é rígido. Tem muita gente aí que acha que está usando Scrum, mas na verdade está usando alguma referência da metodologia sem realmente estar aplicando. Já vi equipes Waterfall usando reuniões diárias por exemplo.
Então muito cuidado, ao dizer que estão usando Scrum.
Aliás, eu vejo que o teste de software está cada vez mais inerente ao desenvolvimento de software, seja o profissional de teste de software trabalhando junto com o desenvolvedor, seja o desenvolvedor criando os testes unitários e integrados.
Sinceramente, hoje eu acho estranho desenvolver algo sem testar a nível unitário e integrado, e digo isso por já ter criado testes para uma aplicação que desenvolvi para testar outra, ou seja, estou “praticamente” testando o meu próprio teste :sPor isso é importante encarar o teste como uma atividade comum no desenvolvimento de software, e não como um elemento estranho.
Agora falando dos testes a nível de sistema e aceitação, se eles são feitos pelos membros do time Scrum, sem dúvidas também precisam estar dentro da sprint desse time. Mas caso eles sejam criados por uma equipe de Teste de Software interna ou terceirizada, aí sim pode haver a possibilidade dessa outra equipe ter um processo em paralelo, e é interessante os dois Scrum Master, alinharem-se (Scrum de Scrum).
Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.
Fonte: qualidadebr.wordpress.com/
Nenhum comentário:
Postar um comentário