Não se limite

Ontem participei de um treinamento sobre Scrum na empresa, ministrado pelo Rodrigo Yoshima.

O treinamento em si é excelente, com bastante prática, temperado com a visão lúcida do Rodrigo sobre desenvolvimento de software.

Quando o Rodrigo falou sobre o time no Scrum, ele enfatizou que as pessoas podem até ter uma função específica, onde possuem mais afinação e experiência, mas elas não devem se limitar a exercer apenas as tarefas associadas a essa função. Por exemplo:  ahh… eu sou testador, então eu só testo. Um time ágil necessita ser multidisciplinar.

Na minha opinião, o profissional deve ter muita prudência ao buscar uma especialização em determinada área/função, pois a especialização pode acaba se tornando um problema para o profissional.

No entanto, isso não significa que o profissional não pode buscar conhecer mais afundo uma determinada área, principalmente se for uma área que ele tem mais afinade e prazer em atuar.

A especialização da qual não gosto, é aquela cega, onde a pessoa abaixa a cabeça e só quer saber de estudar e/ou trabalhar em determinada área. Na minha opinião isso é um desperdício de potencial humano.

E o grande problema é que nós somos condicionados a especialização. Afinal, a nossa geração foi fortemente influenciada pela fase industrial, na qual a especialização era bem vista e necessária, pois boa parte dos profissionais atuavam em tarefas manuais, que exigiam conhecimentos específicos e eram exercidas durante toda a carreira do profissional.

Mas hoje na fase pós-industrial

Muita coisa mudou desde daquela época onde as linhas de produções ainda eram compostas por homens, mulheres e até crianças, que trabalhavam muito mais do que 8 horas diárias. Principalmente no que tange a expectativa de vida. Hoje vivemos MUITO e o bastante para que possamos fazer umas três faculdades e atuar em áreas bem diferentes entre si, se quisermos.

E no nosso caso, atuamos num mercado onde a grande moeda de troca é o conhecimento e por isso precisamos estar sempre atualizados, pois caso contrário, podemos nos tornar profissionais obsoletos.

Lógico, que ainda hoje a especialização é importante em várias outras áreas, por exemplo na Medicina. Porém, na área de TI há uma forte tendência para que os profissionais de TI, se tornem especialistas generalistas.

Putz Fabrício, você está ficando louco! A especialização é fundamental, o mercado demanda de profissionais especializados, essa coisa de especialista generalista é besteira.

Bem se você acha isso, recomendo fortemente a leitura desse artigo e o vídeo abaixo:

E não é só isso, hoje se formos olhar as vagas em empresas como Google, Yahoo! e ThoughtWorks (só para citar algumas), iremos ver que o perfil que pedem é justamente o de especialistas generalistas!

Por favor, não se limite

Isso é sério. Por favor, não se limite!

O ser humano tem uma capacidade incrível, porém somos condicionados a subutilizar as nossas capacidades.

E como não se limitar?

1. Fazendo o que você gosta. Isso é essencial, pois você irá evoluir muito mais rápido na área e geralmente, será natural não se limitar a apenas uma função específica;
2. Buscando novos conhecimentos (não apenas na sua área de atuação). E é bom estar preparado, pois nessa busca há um alto risco em você se interessar por outras áreas, que antes você não tinha o mínimo interesse ou era totalmente ignorante.

Por que não me limitar?

Tentando ser objetivo: porque hoje a nossa expectativa de vida é muito alta, e por isso temos mais tempo para explorar as nossas capacidades.

Sendo prático: porque o mercado de TI está cada vez mais demandando de profissionais especialistas generalistas. Mas tome cuidado para não se tornar um pato. 😉

Sendo realista: há tantos fatores e pessoas que nos limitam, que nós mesmos não podemos nos limitar. Pisa fundo!

Pra encerrar deixo uma frase do Oscar Wilde, que nos provoca, e faz pensar que podemos tirar muito mais de nós mesmos, e um bom começo para isso, é não se limitar.

Viver é a coisa mais rara do mundo. A maioria das pessoas apenas existe.

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

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

3º Encontro Mensal do Interior – Regional Sorocaba

Pessoal,

Quem mora em Sorocaba e região já deve conhecer o Encontro Mensal do Interior, organizado anteriormente pelo Robson Agapito e André de Oliveira, ex-membros da ALATS-SP. Agora os dois, junto com o Alexandre Marketti e a comunidade Testadores estão realizando mais uma nova edição do evento.

Desta vez o encontro terá a Renata Fidelis, palestrando sobre “O que é o SCRUM e como adaptar o processo de teste de software para o seu uso”.

O encontro será realizado no dia 24 de junho (uma quinta-feira) das 19:30 até às 22:00 no auditório da UNIP-Sorocaba.

As inscrições podem ser feitas gratuitamente até o dia 23 de junho,  sendo que as vagas são limitadas (50 vagas).  E no dia do evento é necessário levar 1 Kg de Alimento não perecível entregue no dia, que será doado para um instituição carente.

Maiores detalhes do evento podem ser obtidos no link abaixo, para o folder do encontro:

http://bit.ly/3EncontroMensalDoInterior

Você pode também acessar a página do evento no LinkedIn:

http://events.linkedin.com/3o-Encontro-Mensal-do-Interior-Regional/pub/348010

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

WorkFlows com diferentes abordagens do processo de teste de software com a utilização do SCRUM

O tema da 25ª Mesa Redonda DFTestes foi “WorkFlows com diferentes abordagens do processo de teste de software com a utilização do SCRUM”. A discussão teve 5 respostas e 4 participantes, sendo eles: eu, Sarah Pimentel, Ricardo Henrique e Humberto Barboza.

A discussão acabou não sendo tão movimentada como de costume, acredito que por já ter tido uma mesa redonda relacionada ao Scrum antes. Mas mesmo assim, acredito que o conteúdo da mesma pode ser útil, principalmente para aqueles que estão usando o Scrum.

Abaixo, segue o resumo da discussão, quem quiser conferí-la na íntegra é só acessar esse link (necessário ser inscrito no DFTestes).

Quais mudanças ocorrem no workflow quando utilizamos o Scrum?

Na minha opinião, o Scrum sendo um processo iterativo e incremental, acaba forçando o seu workflow a ser baseado em iterações e trabalhando de forma incremental também.

Se você já usa alguma metodologia incremental (ex.: XP), não haverá grandes mudanças.

O Humberto Barboza complementou dizendo:

Concordo quando o Fabrício diz que a mudança maior é na iteratividade. Ressalto ainda:  Como são “tiros curtos” precisamos planejar com eficiência, avaliar os riscos sob o olhar criterioso, priorizar as tarefas / estórias. Sem o devido planejamento, participação nas reuniões é impossível cumprir os prazos estabelecidos porque manter a documentação (Casos de Teste, Roteiros, Rastreabilidade) é extremamente custoso e um dia perdido têm impactos bem grandes.

Quais abordagens casam melhor com o Scrum?

Falando em Teste de Software, acredito que uma das que casa melhor é o Teste Baseado em Riscos (Risk-Based Testing), pois a cada sprint é necessário avaliar os riscos relacionados a mesma e fazer os testes associados aos riscos da sprint.

Como o tempo é bem curto, geralmente cada sprint tem 2 semanas, temos que ter foco nos testes. Por exemplo: num cenário de manutenção de software, é difícil realizar uma regressão de testes manuais completa.

Outra abordagem que destaco é a automação de testes, pois é muito difícil manter o teste de software sustentável sem buscar a automação, uma vez que trabalhamos com ciclos curtos e precisamos entregar valor constante para o cliente e software de qualidade.

Segundo o Humberto Barboza:

Acho que isso depende muito do projeto que trabalhamos. Precisamos sim avaliar os riscos claro que olhando para prazos e custos e perceber a melhor forma de trabalho com o que dispomos.

A metodologia de desenvolvimento de software da equipe de desenvolvimento é o que mais tem impacto no workflow do processo de Teste de Software. Sendo assim, é possível usar Scrum quando a equipe de desenvolvimento não usa?

É possível, mas dificilmente você vai conseguir usar todas as práticas do Scrum e conseguir cumprir as metas da sprint. O Teste de Software está fortemente ligado ao desenvolvimento (como irmãos siameses), por isso o melhor acaba sendo ambos usarem as mesmas metodologias/frameworks.

Mas algumas práticas do Scrum podem ser adotadas, como por exemplo: reunião diária, retrospectiva, quadro kanban e definição de metas de curto prazo.

O Humberto Barboza acredita que é possível, contanto que seja adaptado a nossa realidade:

Penso que sempre é possível, adaptando a metodologia à nossa realidade.

Bem pessoal é isso. Até a próxima! 😉

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

Cobertura CInTeQ 2010 – Dia 2 (parte 1)

Agora irei falar sobre como foram as palestras da parte da manhã, que ocorreram no segundo e último dia do CInTeQ 2010, um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB. Se você quiser saber como foram as palestras do primeiro dia, pode acessar esse post e esse.

Mauro Spínola – Qualidade e Produtividade em Sistemas e Software: Um Desafio Brasileiro

No segundo dia também cheguei um pouco atrasado, e perdi o início da palestra do Mauro, quando cheguei ele estava falando sobre produtividade.

O Mauro Spínola é Doutor e Livre-docente em engenharia pela Poli-USP e atua como consultor na área de TI e Qualidade de Software, ele também realiza treinamentos e assessoria através da Fundação Vanzolin.

A palestra teve como foco apresentar e discutir as exigências que as empresas enfrentam atualmente, assim como falar sobre a potencial contribuição que os modelos e normas podem ter nelas, quando as mesmas buscam a qualidade de sistemas e software.

Ao falar sobre produtividade o Mauro levantou a questão sobre o que é produtividade, que seria a relação entre o que a gente produz, com o quanto que a gente gasta para produzir.

Medir produtividade não é fácil, e medir produtividade em software é bem mais difícil, por isso precisamos saber qual tipo de produtividade nos interessa. Mas antes, precisamos ter a coragem de medir a produtividade.

Como obter maior produtividade?

O Mauro disse que as técnicas não são muito diferentes das usadas para obter qualidade, sendo elas:

• Arquitetura definida;
• Processo definido;
• Padrões;
• Ferramentas, automação;
• Reuso/componentização.

Logo após, o palestrante falou um pouco sobre qualidade, primeiro a de produto e depois de processo, citando as características que podemos avaliar no software (Norma NBR 13596):

Do ponto de vista de produto podemos avaliar o seguinte (Norma NBR 13596 [que hoje é a NBR ISO/IEC 9126]):

• Funcionalidade;
• Confiabilidade;
• Usabilidade;
• Eficiência;
• Manutenibilidade;
• Portabilidade.

Agora para falar sobre qualidade de processo o Mauro, citou vários modelos e normas que ajudam a obter um bom padrão, sendo alguns deles:

• ISO9000-2000/ISO90003;
• ISO12207;
• ISO15288;
• ISO1550;
• CMMI;
• MPT.BR.

Sobre CMMI e MPS.BR o Mauro citou alguns números interessantes:

• CMMI
  • Já foram feitas quase 5000 avaliações, boa parte das avaliações são feitas fora dos EUA, muitas empresas passaram para o nível gerenciado e definido;
  • O Brasil se encontra 117 avaliações no Brasil e 9 são de nível 5.
• MPS.BR
  • 205 avaliações MPS.BR foram realizadas até agora.

Alguns pontos interessantes levantados pelo Mauro foram:

• Uma empresa que não tem um padrão, dificilmente irá obter bons resultados mesmo com gênios;
• Só consegue avaliar a qualidade tendo claro as características que definem um bom software;
• Testes e codificação são atividades de menor cognição, quando comparadas com atividades de requisitos por exemplo.

O Mauro falou sobre pessoas, fazendo uma analogia onde disse, que uma alfaiataria é diferente de uma fábrica de ternos, e nas faculdades estamos formando bons alfaiates, que não estão preparados para atuar numa fábrica de ternos. Ele ainda enfatizou a necessidade de uma boa formação, para que o profissional possa lidar com as mudanças, afinal na área de tecnologia, mudanças ocorrem de forma constante, sempre precisamos nos manter atualizados.

Ainda foram citados alguns desafios que as empresas enfrentam:

• Manterem-se atualizadas;
• Investir em seus funcionários;
• Desenvolver processos maduros.

Por fim, o Mauro falou que as fábricas de software tendem a industrialização do software, e a “modularização” das atividades é necessária, pois não há sentido em continuar no desenvolvimento vertical.

Impressões da palestra

O Mauro falou sobre um assunto que realmente é um desafio, e na minha opinião a qualidade será cada vez mais um diferencial entre as empresas. E a necessidade da produtividade é inerente ao panorama atual, no qual o que é desenvolvido hoje, passa a ser ultrapassado, cada vez mais cedo.

Não concordo com alguns pontos levantados pelo Mauro, principalmente sobre testes e codificação serem atividades menos cognitivas do que atividades de requisitos, isso me remete a visão de um gerente fora da realidade, que pensa que codificar é igual montar peças de Lego e que testar é só inserir dados num formulário. Além disso, não acredito na tendência da industrialização do software, pelo menos não da maneira que deu a entender, onde o desenvolvimento de software estaria cada vez mais próximo de uma montadora de automóveis. Ainda sou da opinião de que desenvolver software é um processo muito mais artesanal do que industrial.

Neli E.Duarte – Test Mirror: a test strategy using Scrum in an outsourcing project

A Neli, Engenheira de Software na IBM, iniciou a sua palestra falando sobre as características do projeto, no qual eles usavam Scrum, FDD (Feature Driven Development) e outsourcing.

Como no FDD o desenvolvimento é dirigido a features (funcionalidades), havia o feature leader, que era o responsável pelo desenvolvimento da feature do começo ao fim.

E neste contexto, surgiu a necessidade de criar um papel para fazer interface com o feature leader, e aí “nasceu” o test mirror, que é justamente um  espelho do feature leader, só que voltado para os testes.

A Neli detalhou como era o relacionamento entre o feature leader e o test mirror:

• Na Sprint Planning a interação entre o test mirror e o feature leader ocorria o tempo todo;
• O feature leader precisava manter o test mirrors ciente de todas modificações feitas na features. Com essas informações o test mirror modelava os testes;
• Os desenvolvedores davam todo o feedback do que ocorreu, inclusive dando dicas de onde seria necessário fazer testes, e entre eles (feature leaders) também haviam troca de informações
• Na Sprint Review quem atua é o test leader, baseado nos reports levantados pelo test mirror, ele criando um relatório de qualidade (era o output do processo de teste) e o feature leader apresentava as funcionalidades. Ou seja, o test mirror agia apenas como um suporte ao test leader, durante a Sprint Review.

Também foram citadas alguns características do processo:

• O output da Sprint Planning era o plano geral dos testes;
• A primeira tarefa do tet mirror era a modelagem dos testes;
• Tudo era de acordo com a feature, então no mesmo sprint poderiam ocorrer várias fases em paralelo;
• Haviam reuniões semanais, onde participam o time Scrum e os core members das outras equipes, onde todos davam um panorama de como estavam as atividades da sprint;
• Haviam builds semanais;
• Os test mirrors eram os responsáveis por executar o teste de sanidade que ocorria no mesmo dia da liberação do build;
• Uma das funções do teste de sanidade era dá informações para o planejamento dos testes (ex.: se o teste de sms não funcionou, não tem como fazer o teste de envio
• do sms concatenado).

Depois ela falou sobre a interação com o outsourcing (4 empresas trabalhando no mesmo produto 3 de desenvolvimento e 1 de teste[não que uma só fazia testes e a outra as outras só desenvolviam]):

• Uma equipe entregava o cenário e a outra equipe criava os outros testes;
• Haviam troca de informações entre as equipes;
• O test mirror solicitava a execução dos testes, feitas pelo recurso externo, e esse enviava o report da execução dos testes;
• O test mirror validava todos os bugs reportados pela equipe da outra empresa, fazendo assim um filtro dos bugs;
• O test mirror era capaz de fazer a filtragem de bugs, pois tinha ciência da funcionalidade, já que estava sempre interagindo com o feature leader.

Por fim, a Neli mostrou os resultados obtidos utilizando essa dinâmica:

• A comunicação melhorou muito (esse  é geralmente um dos primeiros sintomas, quando iniciamos o Scrum);
• Melhorou a rastreabilidade dos incidentes;
• Pacotes entregáveis mensalmente;
• Aplicação foi entrega no tempo e sem bugs críticos;
• Uma dinâmica muito intensa durante a sprint, um planejamento bem feito, sendo realizado duas vezes – o planejamento em si e o refinamento;
• Testes mais esperto!

Impressões da palestra

Sabe aquela palestra que você balança com a cabeça todo o tempo, afirmando o que foi dito? Foi esse o comportamento que tive durante a palestra da Neli.

Até comentei no twitter, que a melhor palestra “coadjuvante” do CInTeQ  foi a da Neli. E essa impressão deve-se aos seguintes fatores:

• Foi a palestra que mais se aproximou da minha realidade;
• A Neli apresentou um conceito novo, o Test Mirror;
• Mesmo com pouco tempo (meia hora de palestra apenas) a Neli conseguiu passar muito bem o conteúdo da apresentação.

Além disso, a palestra da Neli, na qual ela contou uma experiência de um projeto, mostrou que é possível aplicar práticas ágeis até mesmo na IBM (essa foi para os “ateus” em metodologias ágeis rs). 🙂

Adalberto Nobiato Crespo – Teste de Software no Contexto do Software Público Brasileiro

A palestra do Adalberto, Doutor em Engenharia Elétrica e membro da equipe técnica do CTI –  Centro de Tecnologia da Informação Renato Archer – Campinas, foi mais a título informativo sobre o Portal do Software Público Brasileiro, falando mais sobre o 5CQualiBr.

Ele começou falando sobre o que o a atuação do CTI e depois explicou sobre i que é o Software Público Brasileiro, que é um conjunto de soluções de tecnologia da informação e comunicação (TIC), disponibilizado para uso público, por meio de um portal Web.

Dentro desse ambiente existe um outro portal, chamado 5CQualiBR, no qual é tratado a qualidade do Software Público Brasileiro, que possui 6 vetores:

• Ecossistema;
• Qualidade de produto;
• Desenvolvedores de software;
• Prestadores de serviços;
• Interoperabilidade;
• Teste de Software.

O propósito é construir e disponibilizar no Portal do SPB uma Estrutura Tecnológica de Teste de Software, para os diversos usuários do SPB, além de tentar diminuir a distância que hoje existe entre a teoria e a prática.

Durante a sua apresentação o Adalberto enfatizou bastante o desenvolvimento junto com a comunidade do portal, pois quem faz ele é justamente as pessoas que tem experiência na área de Teste de Software.

Impressões da palestra

A palestra cumpriu a sua proposta de divulgação do SPB e do portal 5CQualiBr, eu já tinha visto ambos antes, e tinha achado interessante a ideia. Sem dúvidas o SPB e seus portais são excelentes fontes de conhecimentos, agora se ele realmente se tornará um portal da comunidade, só o tempo dirá.

Erik van Veenendaal – Test Maturity Model

Erik Van Veenendaal, uma das maiores referências da nossa área, apresentou sobre o TMMi (Test Maturity Model integration), que como a própria sigla já deixa claro, é um modelo de maturidade voltado para a área de Teste de Software.

O Erik começou falando que existimos para prevenir que defeitos vão para o mercado e estamos sempre enfrentando desafios e eles estão sempre crescendo, alguns números a respeito disso:

• O número de software dobram a cada 2 anos na Philips, temos mais softwares para testar;
• O número de requisitos para celulares dobram a cada 6 meses, segundo a Nokia;
• Defeitos dificilmente reduzem.

E tendo ciência desses desafios fica claro a necessidade de fazer testes de forma mais eficaz e profissional. Ou seja, precisamos de testadores de classe A, e visando essa necessidade foi criado o TMMi.

Mas antes de falar sobre o TMMi, o Erik disse que há três direções que podemos falar sobre teste:

• Pessoas;
• Infra-estrutura;
• O processo de teste.

Um dos comentários mais legais que feitos pelo Erik foi quando ele disse que para melhorar os testes é necessário buscar uma melhoria nesses três pilares, não adianta apenas focar em um dos pilares. Ou seja, ele mesmo assumi que o TMMi em si, não é a solução definitiva, o que demostra o profissionalismo e preocupação com a qualidade do Erik, e ainda complementa dizendo que melhoria não é apenas processo é também pessoas e infra-estrutura.

A respeito de pessoas, há pelo menos quatro área de habilidades necessárias para um testador:

• Conhecimento em Teste de Software;
• Conhecimento em TI (estamos nos aproximando dos desenvolvedores);
• Conhecimento sobre domínio;
• Habilidades não técnicas: comunicação, pensamento crítico e apresentação.

Já sobre infra-estrutura, o Erik citou algumas práticas fundamentais:

• Requisitos bem documentados e gerenciados;
• Existência de um planejamento do projetos;
• Gerenciamento de configuração.

Alguns pontos interessantes levantados pelo Erik:

• Você precisa de um orçamento para fazer a melhoria do processo;
• O gerenciamento precisa de suporte de bons testes, lembre-se que qualidade é fundamental;
• É preciso compreender o porquê que você está fazendo a melhoria;
• Testar é dar informações sobre riscos.

TMMi

O Erik começou a sua explicação sobre TMMi Foundation, dizendo que ela é uma organização sem fins lucrativos. O TMMi é baseado no CMM e considera toda as práticas já existentes, suas origens são: CMMI, ISTQB, TMM, IEEE e TPI.

Assim como o CMMI, o TMMi é dividido em 5 níveis, lembrando que o primeiro é onde todas empresas estão no nível 1 (Inicial).

Os Cincos Níveis do TMMi (fonte)

O Erik acredita que o nível 2 é bom para todas organizações e necessário para lidar com os projetos atuais, sendo que para chegar nele, geralmente leva 2 anos, pois é o nível que provoca mais mudanças. Já para ir para o nível 3, costuma levar 1 ano.

Para se certificar é necessário pedir uma avaliação formal. No processo de implementação e avaliação temos dois papéis principais, o Lead Assessor e o Assessor, sendo que dentro dos conhecimentos para ser um Lead Assessor e um Assessor estão:

• Lead Assessor
  • 5 anos de experiência e ISTQB avançada;
• Assessor
  • 3 anos de experiência e ISTQB fundamental.

Na sequência o Erik falou mais especificamente do nível 2 e nível 3.

O TMMi nível 2 leva a redução de tempo e atingi mais a parte funcional. Estando no nível 2 você está de acordo com o que pedido pelo CMMI nas áreas de Verificação e Validação.

Já o nível 3 atingi mais a parte organizacional, e significa um envolvimento mais cedo dos testes no desenvolvimento do software.

As seguintes melhorias no testes, na perspectiva e engenharia, foram citadas:

• Teste mais profissional;
• Responsabilidades claras;
• Planejamento de testes;
• Teste baseado em riscos;
• Testes parte do ciclo de vida do desenvolvimento;
• Envolvimento cedo;
• Uso de técnicas de modelagem de testes;
• Controle sobre o processo de Teste de Software.

Alguns dos resultados que podem ser reportados pela área de teste são:

• Detecção dos defeitos;
• Tempo do lançamentos das versões;
• Desvio entre o tempo do gasto X planejado;
• Satisfação do funcionários.

Depois o palestrante falou sobre como podemos começar a implantação do TMMi, dizendo que:

1. Defina uma política de testes e obtenha aprovação da gerência.
2. Tenha ciência que melhoria é um projeto e calcule a porcentagem de recursos e esforço;
3. Implante a maturidade do desenvolvimento na organização.

Algumas dicas dadas pelo Erik sobre como ter implantar o TMMi:

• Faça pequenos ciclos;
• Você não vai mudar só pela mudança;
• Não responsabilidade as tarefas de melhoria para um consultor, pois ele irá embora, deixe isso para alguém da sua organização, a sua organização deve ser o impulso não a consultoria;
• “Institualize” as melhorias;
• Tudo tem haver com mudar a gerência;
• Revise os objetivos (política), de forma contínua;
• A sua melhoria tem que ser visando o negócio.

O Erik também apresentou o Manifesto da melhoria do testes:

• Flexibilidade, sob detalhados processos;
• Melhores práticas, sob templates;
• Orientado ao deployment, sob orientado a processo;
• Revisões, sob departamentos de QA;
• Guiado pelo negócio, acima do guiado pelo modelo;
• O melhor não é o melhor do mundo é o melhor no seu contexto;
• Definir processo é fácil, difícil é instituir esse processo para as pessoas.

Por fim o Erik finalizou dizendo que o TMMi é ótimo quando feito da forma certa, sempre dirigido ao negócio.

Impressões da palestra

O Erik é uma palestrante muito bom, conseguiu passar bem as informações, descontrair a plateia com algumas brincadeiras e atingir a proposta da sua palestra. Eu já tinha uma noção do TMMi, mas com a palestra ficou muito mais claro a sua proposta, seus níveis e os resultados que podem ser obtidos com a sua aplicação. Uma pena que ainda não existem Lead Assessors e Assessors no Brasil, o que dificulta a popularização dele no Brasil (enquanto isso podemos acessar o material disponibilizado no site do TMMi).

Encerro aqui a primeira parte do segundo dia do CInTeQ, até a segunda parte, onde estarei terminando a cobertura das palestras do CInTeQ.

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

SCRUM e Testes: Quais as melhores formas de implementar?

A 14ª Mesa Redonda DFTestes foi sobre “SCRUM e Testes: Quais as melhores formas de implementar?”, a discussão teve 24 respostas e 7 participantes, sendo eles: eu, Marcelo Andrade, Renata Eliza, Felipe Silva, Lorena Lyra, Jorge Diz e Antonio Moraes.

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
* Simplicidade

Por 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.

As minhas experiências foram muito boas, como disse antes, mesmo não conseguindo implementar todas as práticas do Scrum, por às vezes não ser necessário, ou por dificuldades encontradas.

Eu particularmente, acho fantástico o Scrum e gosto bastante do assunto (o fantástico, por ele ser tão simples como processo, e tão difícil de ser implementado).

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?

Dúvida levantada pela Lorena, e minha resposta é a seguinte:

Testes automatizados! 🙂

Se houver muitos testes manuais, Risk Based Testing neles!!! 😀 (aliás, Risk Based Testing sempre hehe)E quando for definida a sprint, o tempo dos testes precisam já estar incluído. 🙂

Para o Felipe Silva:

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 ?

Mais uma dúvida levantada pela Lorena. 🙂

O Antonio Moraes respondeu contando um pouco da sua experiência com Scrum:

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 :-)) testes. Portanto a equipe necessariamente precisa ser multi-disciplinar.

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.

Na minha opinião os testes devem ser incluídos.

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.

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

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…

Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)

A discussão da sexta Mesa Redonda DFTestes foi sobre a “Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)”, discussão que gerou13 respostas, e teve 8 participantes: eu, Renata Eliza, Marcelo Andrade. Juliana Kryszczun, Felipe Silva, Ronaldo Cruz, Jorge Diz e o Vitor Machel.

Abaixo, segue um “resumo” do que foi discutido na mesa redonda, lembrando que é altamente recomendável, a leitura de toda a discussão caso você tenha interesse pelo assunto.

Metodologias Ágeis e Teste de Software, tudo a ver ou não?

Para o Marcelo Andrade, “não há como se seguir qualquer técnica dita “ágil” se não se tiver uma forte disciplina em teste de software” e ainda complementou dizendo:

Escrevi um post sobre isso há algum tempo no Blog do TaSAFO – http://tasafo.wordpress.com/2009/05/14/se-voce-nao-testa-voce-nao-e-agil/

Para simplificar, ao falar de testes, me refiro especificamente a testes de aceitação, uma vez que testes de unidade, a rigor, são parte do desenvolvimento de software. Assim, é importante levar a etapa de testes a sério, automatizar os testes, reforçar seu uso, etc. Um pensamento interessante que por acaso li hoje num post do InfoQ é que “automatização de testes de software É software”.

Enfatizo, entretanto, que se você não tem disciplina para conduzir seus testes adequadamente, de nada adiantará tentar “implantar agilidade”, com muito se diz. Isso me remete a outro tema proposto para a mesa redonda sobre como evitar o “Testa aí”, bem como também reforça uma opinião pessoal que tenho de que a palavra “ágil” é ruim, pois pode descambar muito facilmente para ser um mero termo mercadológico ou como marketing para empresas.

A respeito do que o Marcelo disse sobre a palavra “ágil”, acredito que o problema aqui é a interpretação das pessoas, e não a palavra em si. Quanto a ser um “mero termo mercadológico ou como marketing para empresas”, é fato mesmo, infelizmente, muitas empresas que antes diziam que utilizavam uma metodologia própria, agora dizem que usam metodologia ágil, pelo simples fato, de que está na moda ser ágil.

E outro ponto interessante, é que empresas que se dedicaram e se dedicam ainda, no estudo e no uso de metodologias ágeis, acabam sempre utilizando uma mescla das metodologias ágeis, e até alterando algumas coisas. Exemplo, a globo.com … ou seja, não existe a melhor metodologia, principalmente numa área tão volátil como a nossa.

A Juliana Kryszczun lembrou sobre o maior problema ao tentar implantar uma metodologia ágil:

O primeiro problema, na minha opinião, é a quebra de cultura. Estamos tão acostumados ao processo tradicional que ficaria um pouco complexo implantar um novo modelo de teste em uma equipe ‘velha’ e já definida.

O Felipe Silva ressaltou que o importante é o resultado a ser obtido com a mudança, se for melhorar vale a pena lutar:

O fato à ser considerado é, melhorar, melhorar e melhorar. Se existe algo, independente do nome, seja SCRUM, XP, LEAN, KAN BAN, e por aí vai, se isso for te acrescentar Benefício então vamos à “guerra”, mas não um contra o outro, porque senão “a casa cai”, mas vamos à guerra em equipe como um exercito, traça-se as estratégias, as táticas (ler A Arta de Guerra por Sun Tzu), analisa-se o terreno e o tempo, as fraquezas e as forças, conscientiza, motiva e integra os soldados no “problema”, o “problema” tem que ser de todos, uma vez o benefício também será de todos. Levantados os dados e os riscos é hora de marchar, repetindo e analisando a palavra “Marchar”, uma marcha é o exército todo em formação e alinhado cada um na sua posição dado passo à passo em sincronia, levantando e abaixando o pé ao mesmo tempo, seguidos pelas direções do general e pelo ritmo dos tambores, passo a passo (Não de uma vez, como tentam fazer alguns, que pensam que um processo novo cai de sem pára-quedas e irá funcionar), o general atento é quem observa se muda a direção ou o ritmo da marcha, ainda que esteja chovendo se o general diz “Marchem” assim deve ser feito para que se alcance o objetivo da estratégia traçada.

Para o Ronaldo Cruz para ser veloz, os testes são mais necessários ainda:

Claro que sim, uma vez que a elaboração de um produto tem de ser feita de forma mais rápida, os teste são ainda mais necessários, o risco de em meio a extrema velocidade se perder ou esquecer de alguma coisa é bem alto.

Segundo o Jorge Diz:

Sim: há uma grande sinergia. De fato, grande parte do (re?)nascimento do interesse em teste de software se deve à adoção de práticas de teste integradas ao desenvolvimento ágil. A comunidade ágil introduziu novos formalismos (ex: BDD, ATDD com planilhas, DSLs), novos mecanismos de isolamento de unidades  para teste (ex: test doubles/mocks), novas ferramentas (ex: JUnit) e, principalmente, novas formas de olhar  para os testes não apenas como mecanismos de controle da qualidade mas também como uma forma de especificação verificável mecanicamente, como forma de comunicação e como instrumento de gestão.

A automação cresceu em importância (inicialmente, talvez exagerada) e puxou avanços na tecnologia de testes  como nunca antes na história da nossa área.

Para o Vitor Machel é necessário que o Teste de Software se adapte a nova metodologia:

Sim tem tudo a ver, como qualquer processo de desenvolvimento de sistemas, mas não se pode ficar com o mesmo pensamento com metodologias tradicionais, tem que se enquadrar também.

Na minha opinião, boa parte das metodologias ágeis (para não falar todas), nasceram da prática, da tentativa de fazer coisas diferentes para tentar obter resultados diferentes, E dentre essas “coisas” diferentes, os profissionais perceberam que Teste de Software é essencial, pois ajuda a garantir a qualidade do produto, e perceberam também, o quanto é importante executar o Teste de Software o mais cedo possível, seja por meio da revisão, proporcionada pela programação em par, seja pela própria criação de testes unitários pelos desenvolvedores.

Scrum e Teste de Software combinam?

A Renata Eliza acredita que sim:

Acredito sim, que as “Metodologias Ágeis” e o Teste de Software têm tudo a ver.

Falando especificamente do SCRUM, não há quem diga que ele pode ser utilizado em qualquer área da vida?!
Por quê não no Teste de Software?

Um projeto que utiliza Scrum terá uma maior facilidade para responder às mudanças que podem ocorrer.

Focando nos princípios dos processos ágeis aplicados pelo Scrum, é possível enumerar centenas de motivos para implantá-lo.

O maior objetivo continuará sendo a garantia da qualidade dos sistemas, porém, através o Scrum será possível gerenciar de forma rápida os testes.

Os objetivos são melhores definidos e as tarefas demandadas de forma mais direta, com prazos que são cumpridos quase em sua maioria. O foco, que geralmente se perde em alguns projetos, é levado a sério.

A Renata ainda citou alguns dos benefícios da implantação do Scrum:

Verificar o andamento de cada projeto como um todo;

Permitir a detecção e remoção de riscos e impedimentos;

Oferecer uma estimativa mais apurada;

Controlar conflitos de interesses e necessidades;

Compartilhar o conhecimento entre a equipe.

O Ronaldo Cruz lembrou que é de extrema importância a atitude dos envolvidos com o projeto:

Sim. Na verdade, todo modelo de desenvolvimento combina com teste. A questão é o quanto as pessoas e empresas estão dedicadas em fazer as coisas acontecerem. De nada vale dizer que usa SCRUM, XP, RUP, abobrinha, chuchu ou cenoura, se a empresa e os envolvidos não estão realmente engajados em implementar o modelo e fazê-lo acontecer.

O Jorge Diz acredita que sim e complementa:

O conceito de pronto-pronto, aplicado às user stories, tem que incluir testes. Apesar de Scrum ser um framework de práticas de gestão, ele acaba puxando a necessidade da adoção de práticas técnicas que permitam  entregas com qualidade, o que puxa a necessidade de investir na garantia e controle da qualidade: as práticas técnicas de XP casam bem nesse contexto.

Um anti-pattern comum é ficar só nas práticas de gestão, ignorando os sinais evidenciados pelo choque de transparência proporcionado pelo Scrum (radiadores de informação, reuniões diárias, retrospectivas). A necessidade de melhoria de processo envolve necessariamente as técnicas que usamos para entregar software.

Assim, é impossível melhorar o produto de software sem mudar as técnicas de requisitos, de desenvolvimento,  de integração e de teste. Se não houver mudanças, a equipe não consegue dar vazão às entregas. Como disse Einstein, é loucura continuar fazendo as mesmas coisas e esperar resultados diferentes: os post-its na parede não possuem  superpoderes.

O Vitor Machel acredita que não:

Se pensar à risca, não porque teste de software por equipe de teste, não entra no conceito de SCRUM

Eu acredito que Scrum combina com qualquer tipo de projeto, desde para organizar uma faxina na casa com a família, até a construção de um foguete.
E para nós, um dos pontos mais importantes do Scrum, é trazer o cliente para próximo do time, seja esse cliente, ou melhor PO (Product Owner), interno ou externo.

Preciso seguir a risca a metodologia ágil ao implantá-la?

Segundo o Ronaldo Cruz:

Não. Como o próprio nome diz, é um modelo, um meio estruturado de executar o trabalho. Cada empresa tem sua particularidade, seja do projeto, dos funcionários, do cliente, da cultura em si. Você pega as praticas do modelo e as adapta ao seu ambiente.

O Jorge Diz compartilhou a sua opinião dizendo:

Não creio que exista “a” metodologia ágil. Aliás, uma das premissas embutidas no conceito de agilidade é a crítica contínua ao processo. De alguma forma, a agilidade é uma reação ao “the one right way¨ de Taylor, imposta por decreto, que sobrevive neste início do século XXI como o eufemismo “melhores práticas”.

Reformulando a pergunta, dada uma metodologia documentada (Scrum, FDD, XP, …) identificada com os princípios da agilidade, é necessário implementar de acordo com o livrinho?

Alguns (o Kent Beck do XP, por exemplo), dizem que sim, por causa da sinergia entre as práticas. Minha posição é que precisamos ter jogo de cintura, mas sem descaracterizar as práticas que fazem a dinâmica funcionar. Sempre existem limitações e precisamos contorná-las.

O problema é que, quando somos iniciantes, ainda não temos incorporados os conceitos de uma metodologia: só aprendemos de verdade fazendo, descobrindo o que é importante e o que é acessório, onde precisamos bater o pé e onde podemos ceder, o que funciona bem num certo contexto e o que precisamos evitar. Por este motivo é importante também, se possível, ter um acompanhamento de pessoas mais experientes durante o início de uma transição para a agilidade (sou suspeito para falar, porque faço esse tipo de serviço)

É bastante comum que as organizações que adotam uma nova metodologia façam adaptações não por restrições externas, e sim para evitar as práticas que mais mudam a forma de trabalho à qual estão acostumadas, por acomodação ou por medo da mudança. Isto é tão comum no Scrum que já ganhou um nome: “Scrum, but …”.

“Estamos fazendo Scrum, mas dispensamos as reuniões diárias”. “Estamos usando XP, mas não temos testes unitários”. Neste anti-pattern, muda-se o processo muito precocemente, descaracterizando-o. O resultado é que a chance de sucesso diminui drasticamente, e a metodologia em questão aparece mal na foto.

Para mim o by the book está LONGE de ser a melhor maneira de implantar algo, principalmente na nossa área. Adaptação é a palavra chave, e adaptação não é feita uma única vez, temos que está sempre evoluindo e melhorando, e para isso a adaptação é essencial. 🙂

O que o XP tem a ver com o Teste de Software?

O Jorge Diz fez uma bela explanação respondendo a questão, deixando bem clara a relação entre o XP e o Teste de Software:

Muita coisa. XP representou no início uma visão bastante peculiar em relação a teste de software. Simplificando:

Há os “testes do programador”, de um teor mais técnico, e que funcionam como apoio ao desenvolvimento: o desenvolvedor é o responsável. Precisam passar integralmente o tempo todo, e ser muito rápidos para não quebrar o fluxo de trabalho do desenvolvedor (na ordem de alguns segundos).

Há os “testes do cliente”, mais próximos do negócio, que ajudam a detalhar os requisitos funcionais, e que são de responsabilidade do “cliente presente”, representante dos solicitantes. Funcionam como testes de aceitação e precisam passar para que a user story seja declarada pronta.

As atividades de inspeção se fundem dentro da prática de trabalho em pares (“pair programming”). Esta  inspeção contínua “dentro do fluxo” é em geral mais eficaz que as inspeções tradicionais “fora do fluxo”  (estilos Fagan e Gibbs). Está ai um exemplo de prática que faz sentido dentro da dinâmica, mas que é  resistida por problemas culturais e políticos: não podemos simplesmente ignorar a necessidade de inspeções. Se não podemos implementar inspeções no fluxo, precisamos substituir por outras formas de revisão ou inspeção fora do fluxo.

É grande a ênfase na automação dos testes. Isto puxou uma série de inovações técnicas para tornar o teste possível no ritmo necessário para apoiar o desenvolvedor. Na cultura de XP, inicialmente não era dada tanta importância aos  testes manuais.

Mais recentemente, têm sido dada importância aos testes manuais, principalmente pela contribuição da escola de “context-driven testing” para testes exploratórios gerenciados.

Uma ressalva: TDD = “test driven development” é considerada uma prática de apoio ao desenvolvimento (design de API, principalmente) e não uma prática de teste. TDD é a junção de duas práticas: “test-first” (escrever o teste automatizado logo antes que o código sob teste) e “refactoring” (limpeza do código sem alterar o comportamento funcional, tal como validado pelos testes). Brian Marick propõe substituir a frase “TDD” por “example-driven development” para esclarecer este fato.

Como foram as experiências de vocês ao utilizarem processos ágeis?

O Ronaldo Cruz compartilhou a sua experiência dizendo:

Para mim foi muito boa. Tornou o trabalho mais fácil por ter uma interação maior com todos os envolvidos. Mas também exigiu uma mudança maior na postura. Qualquer membro da equipe, seja desenvolvedor, banco ou teste, tem de se tornar ágil. Sair da cadeira e correr atrás, seja para desenvolver a atividade de outro membro ou tirar duvidas de teste ou negócio, não importa, cada um da equipe precisa deixar de ser acomodado e se tornar pró-ativo, buscar a solução e ajudar os demais a concluírem as suas atividades. Na equipe em que trabalho, me tornei analista de teste, negócioe dou suporte ao pessoal do desenvolvimento.

O Jorge Diz compartilhou um pouco da sua experiência como consultor, citando os problemas da disciplina de testes neste contexto:

É comum as pessoas empacarem justamente por dificuldades na automação de testes no nível necessário para  suportar a agilidade. Alguns pontos de atenção:

• Código legado difícil de testar;
• Falta de disciplina de test-first por parte dos desenvolvedores;
• Não domínio das técnicas de isolamento para testes unitários;
• Investimento excessivo em testes frágeis (GUI), que pode diminuir a velocidade das atividades de teste;
• Indisponibilidade de ambiente próprio para teste, onde a aplicação possa ser testada sob controle total da equipe de desenvolvimento/testes;
• Testadores ainda perdidos numa nova forma de organizar as equipes (testador residente em vez de operário de uma fábrica de testes);
• Dificuldade para satisfazer o pronto-pronto;
• Resistência à programação em pares.

O Vitor Machel contou um pouco da sua experiência:

Totalmente satisfatórias, os documentos (NÃO SÃO TODOS) que só serviram para ir para o lixo, nem existe mais. O conceito que estamos usando é “faça somente documentos para usar e entregue o software funcionando”, dificilmente estamos trabalhando (tanto teste quanto desenvolvimento) depois das 18 e sábados e domingo, o que eu mais gostei. Em resumo aqui, todos estão aprovando, cliente satisfeito é tudo, o resto é resto.

Eu tive ótimas experiências e também experiências ruins. 🙂

Abaixo, algumas conclusões tiradas dessas experiências:

• A cultura das pessoas e da organização é o que mais influencia a implantação de uma metodologia ágil;
• A maturidade das pessoas também é um fator bastante influenciador, principalmente, em relação ao tempo que a implantação vai levar e como ela ocorrerá;
• A comunicação é essencial, tanto interna quanto externa;
• O PO é o cara (no bom sentido é claro), a sua participação é essencial para o sucesso do projeto;
• As pessoas são o diferencial de qualquer projeto. As pessoas certas com domínio da tecnologia, conhecimento do projeto e determinação são capazes de resultados incríveis, e a adoção de metodologias ágeis potencializa esses resultados;
• A metodologia utilizada pode ter dado certo em um projeto, mas isso não garante que ela também irá funcionar em outro;
• Busque ter uma pessoa da área de Teste de Software, no seu time Scrum;
• Antes de implantar uma nova metodologia, der treinamentos a respeito dela para todos;
• Se algo deu errado, com certeza não é culpa da metodologia, e sim sua! 🙂

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

Impressões do 6º Encontro Mensal da ALATS São Paulo

Ontem (30/09/09) ocorreu o 6º Encontro Mensal da ALATS SP. Desta vez, sobre um tema bem atual “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, palestrada pelo Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, pela UNICAMP, e instrutor na Globalcode.

A seguir, relato as minhas impressões sobre o encontro.

Primeira parte

Ao chegar (cheguei alguns minutos atrasados) o Jorge estava mostrando uma cena do filme Matrix.

Em seguida, comentou que tentaria dá uma de Morpheus, referindo-se a apresentação de ambas metodologias tradicional (cascata/modelo-V) e a ágil (Lean, Scrum, XP e Context Driven). E ainda disse que seria necessário tomar a pílula vermelha para entender esse novo paradigma.

Um ponto bem interessante levantado pelo Jorge, logo no início, foi que errar faz parte do aprendizado, e como o desenvolvimento de software, acaba sendo um aprendizado constante, exercido durante um período de tempo (projeto), errar faz parte. E o fluxo do erro é o seguinte: erro -> defeito -> falha -> diagnóstico -> correção.

Portanto, precisamos tomar medidas para que o defeito se revele o mais cedo possível. Afinal, quanto mais cedo ele for descoberto, menor será o seu cu$to.

Depois o Jorge apresentou o modelo cascata de desenvolvimento de software e na sequência argumentou sobre as suas características relacionadas com a área de testes e seus resultados, que resumindo:

• Como é necessário que os requisitos sejam precisos, precisamos fazer com que o cliente pense tudo antes! Resultando em um detalhamento precoce dos requisitos;
• A arquitetura torna-se hipertrofiada, o design especulativo e o desenvolvimento Nostradamus. Pois acabamos tentando atender mais do que as necessidades do cliente, não há muito contato com o mesmo, durante o desenvolvimento. Portanto, pensamos no que achamos que ele gostaria de ter e não no que ele realmente precisa, e além disso o desenvolvedor é orientado ao e se…
• Poucos podem conversar com o cliente, e a orientação e de que é melhor nem ouvir, pois ele sempre irá pedir mais, ou mudar algo;
• Como há menor feedback do cliente, a chance de desenvolver funcionalidades inúteis é grande;
• A fase de teste acaba, geralmente, sendo zipada, ou seja, quando ela é iniciada o prazo está quase no fim, isso quando já não está estourado. Resultando numa entrega com um nível inadequado de testes e as falhas aparecem no pior momento possível, em produção.

Durante essa parte da apresentação o palestrante apresentou dois gráficos interessantes, um bem famoso e o outro nem tanto assim:

O primeiro é o famoso Princípio de Pareto aplicado ao desenvolvimento de software, pelo qual 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

Já o segundo apresenta uma comparação entre metodologias ágeis e tradicionais, onde é possível observar que o retorno do investimento (ROI) ocorre mais cedo e é maior do que utilizando metodologias tradicionais.

Para terminar a primeira parte o Jorge falou sobre inspeções e revisões.  Onde ficou claro que é importante realizar inspeções e revisões, porém elas não substituem os testes, até porque encontram outros tipos de defeitos.

Coffee Break

Vinte minutos de um delicioso coffee break, onde o pessoal pode conversar mais e se conhecer melhor, o famoso encontro das ilhas (rsrs).

Segunda parte

Voltando do coffee break o José Correia fez uma breve apresentação sobre a ALATS e o encontro semanal, trazendo novas notícias:

• Exame da CBTS será realizado pela 1ª vez em Campinas, na R. Teodoro Langard, 126 – Bonfim, próximo a nova rodoviária de Campinas;
• UNIESP abriu o circuito de palestras da ALATS em São Paulo;
• Embaixadores da ALATS;
• E ainda adiantou o tema do próximo encontro que será sobre Alta Automação, palestrada pelo pessoal do Grupo HDI (que estiveram no BRATESTE desse ano).

Continuando a apresentação, o Jorge Diz comentou sobre o modelo V, analisando os resultados que ele traz para a área de Teste de Software:

• O tempo entre o erro e a correção ainda é longo;
• Ainda ocorre detalhamento precoce dos testes, sem execução para atestar sua validade.

Finalmente, o palestrante chegou ao tema do encontro, dizendo que era necessário um novo modelo para o desenvolvimento, e que esse novo modelo precisava encurtar os ciclos de desenvolvimento.

O Jorge fez uma boa introdução sobre metodologias ágeis explicando o seu nascimento, o manifesto ágil (espécie de pai-nosso das metodologias ágeis) e citou as principais metodologias ágeis:

• Lean: modelo conceitual;
• Scrum: gestão;
• XP: práticas de engenharia;
• Context-Driven: técnicas de testes.

E “lógico” que numa apresentação sobre metodologias ágeis, o pobre RUP tinha que ser criticado, então Jorge fez a comparação entre os papéis existentes no RUP (muitos) e os 3 papéis existentes no Scrum (solicitante – PO, facilitador – Scrum Master e time). Eu particularmente, não acho que o RUP seja o vilão, o que ocorreu/ocorre é que muitas pessoas não souberam interpretar ele (exemplo: os papéis do RUP são “chapéus”, e não cargos!).

Logo após ter feito a comparação entre os papéis do RUP X Scrum, que já tinha gerado uma discussão com o público, o Jorge comentou que a pessoa de teste está dentro do time de Scrum e que também necessita ter conhecimentos de programação, o que gerou mais uma boa discussão com o público.

Após a discussão, o Jorge Diz fez comparações do que é possível fazer em 15 segundos (entender um método), 15 minutos (gerar um build testado), 15 horas úteis (uma funcionalidade), 15 dias (um sprint) e 15 semanas (uma entrega).

E por fim o palestrante falou sobre o novo modelo de testes, no qual há mais testes unitários do que testes de integração e menos testes de sistemas do que de integração, ou seja, o inverso do que ocorre utilizando metodologias tradicionais. E explicou o quadrante de testes ágil, desenvolvido por Brian Marick.

Considerações finais

Na minha opinião, a palestra teve um excelente início, no qual o Jorge Diz contextualizou muito bem e com uma ótima explicação o cenário do Teste de Software, perante as metodologias tradicionais. Porém, essa parte foi muito longa e comprometeu a parte mais importante do encontro, já que o tema foi “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas” e deu tempo só para ver um pouco sobre metodologias ágeis. Sobre as ferramentas, o Jorge apenas citou algumas (autotest, Cucumber, Junit, FitNesse, etc), de forma rápida, no final da apresentação. Ou seja, acabamos sendo atingidos pelo Tsunami, mas morremos na praia, devido ao tempo. Quem sabe o Jorge Diz não pode voltar num próximo encontro, até porque, estava muito interessante e o pessoal estava com várias dúvidas.

Para encerrar o post, gostaria de agradecer a todos que foram, o auditório estava lotado! E parabéns a todos da ALATS-SP, em especial ao José Correia pela iniciativa do encontro e por seguirem firme, que venha o sétimo!

P.S.: Assim que for disponibilizada a apresentação utilizada no encontro, eu atualizo o post com ela. 😉

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

Fonte – Imagens

http://improveit.com.br/xp/desenvolvimento_tradicional

http://agile101.net/2009/07/22/self-funding-projects-a-benefit-of-agile-software-development/

6º Encontro Mensal da ALATS-SP

Pessoal,

O tema do 6º encontro mensal, promovido pela ALATS-SP, será “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, apresentado pelo Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP.

Acredito que será uma excelente oportunidade para compreender melhor a influência que as metodologias e práticas ágeis podem ter na nossa área, assim como trocar experiências sobre o assunto.

Segue abaixo, maiores informações sobre o encontro, retiradas da página da ALATS-SP:

Data: 30 de setembro (quarta-feira)
Horário: 18:30 – 22:00
Local: Av. Paulista, 726 – 17º andar conj. 1707D – próximo a estação de metro Brigadeiro

Objetivo:

Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:

Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas.

Conteúdo:

O modelo de desenvolvimento ágil sacode muitas das confortáveis premissas nas quais se baseava o desenvolvimento de sistemas até poucos anos atrás. A gestão da qualidade de software em geral, e as disciplinas de teste em particular, passam a ser afetadas substancialmente por este novo modelo:muda a inserção do profissional de testes dentro do processo, muda a importância relativa das técnicas de teste, muda a forma e o foco da gestão.

Novos focos e novas necessidades inspiram novas ferramentas. Paradoxalmente, coube aos desenvolvedores ágeis investir grande esforço em ferramental específico para testes e qualidade, mas os profissionais de testes e qualidade não têm participado ativamente deste processo.

Na primeira parte desta palestra, serão apresentadas as premissas do teste de software num contexto ágil, discutindo
como as mudanças do modelo afetam o perfil do profissional de testes do ponto de vista da gestão, da adoção da automação, das novas capacidades e habilidades necessárias, e dos papéis dentro da organização de desenvolvimento.

Na segunda parte, serão apresentadas novas ferramentas de teste originadas na comunidade ágil para suportar as necessidades de teste automatizado: bibliotecas para teste unitário, dublês de teste, (acceptance-)test-driven development, behavior-driven development, arquiteturas para favorecer a testabilidade, linguagens específicas de domínio e inserção do teste automatizado na integração contínua.

Agenda:

18:30 Credenciamento e networking entre os participantes
19:00 Início da palestra
20:00 Coffee break e networking
20:30 Continuação da palestra
21:30 Espaço aberto para discussão de temas da ALATS e da comunidade de Qualidade de Software em geral
22:00 Encerramento

Palestrante:
Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP.

Consultor com mais de 25 anos de experiência em tecnologia da informação, abrangendo desenvolvimento, testes, requisitos, liderança de projetos, pesquisa tecnológica e ensino. Atuou principalmente nos setores financeiro e de telecomunicações, em grandes empresas.

Começou a trabalhar com testes em 1994 e a estudar metodologias ágeis em 2000. Apresenta frequentemente palestras sobre tecnologia Java, testes e metodologia em eventos técnicos e acadêmicos, incluindo várias edições do JustJava e XP Brasil. Foi responsável pela trilha de metodologias no TDC (The Developers´ Conference) 2008 em São Paulo.

Atualmente é instrutor na Globalcode, onde se especializou em treinamento de teste de software baseado em ferramentas open source para times ágeis. Possui as certificações CSM, SCJP e SCWCD.

Inscrições:

– Associados ALATS: R$ 25,00
– Não Associados: R$ 30,00

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

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

Scrum

Há muito tempo, estava querendo fazer um post sobre Scrum. Mas só agora realmente, tomei iniciativa em fazê-lo.

Falar sobre Scrum é algo fácil e ao mesmo tempo difícil. Fácil por ser algo simples, e é difícil, pois há muitas outras pessoas falando sobre ele, então a chance de fazer um “post papagaio” é grande. E quando falo de muitas outras pessoas falando sobre Scrum, não é apenas quantidade e sim muita qualidade. E isso é um ponto muito forte, que vejo do Scrum, ele é muito vivo! As pessoas pesquisam, discutem, “blogam”, etc sobre Scrum.

O intuito desse post é passar algumas opiniões que tenho sobre Scrum, e também “papagaiar” um pouco sobre ele, afinal para muitos ele é ainda apenas mais um buzzword. Espero que gostem, qualquer coisa só “cornetar”, ou melhor, comentar. 🙂

Mas afinal o que é Scrum?

Vou primeiro colocar a definição que entendo como a melhor, do Ken Schwaber, um dos criadores do Scrum, e depois colocar uma definição pessoal:

“Um processo Ágil ou ainda um framework para gerenciamento de projetos Ágeis. É um processo de gerência de projetos, certamente não é uma metodologia, pois isto seria pesado demais.” (Ken Schwaber)

Scrum são boas práticas para gerenciar projetos de forma a otimizar o ambiente de trabalho, motivar as pessoas e satisfazer as reais necessidades do cliente. (Fabrício Ferrari de Campos)

Mas por favor, não se apegue muito as definições, o importante é conhecer as práticas e conceitos que o Scrum traz e os benefícios que podemos ter aplicando-os na nossa empresa.

As características principais do Scrum são:

• Ágil;
• Empírico;
• Incremental;
• Iterativo.

Mas o que significa a sigla Scrum?

Que sigla?… Não, não. Scrum não é uma sigla, é o nome de um tipo de jogada que acontece no jogo de rugby para retornar a bola,  onde é necessário a participação de todos os jogadores. Se um falhar, todos falham. Por isso que você ver uma imagem parecida com essa abaixo, em vários posts sobre Scrum (e não poderia ser diferente nesse…rsrs).

Quem é quem no Scrum?

O Scrum organiza de forma diferente os papéis existentes num projeto:

• Scrum Master: Remove os impedimentos, garante o uso do Scrum e protege o time de interferências externas. Líder colaborador!
• Product Owner (PO): Preocupado com o ROI, se voltará dinheiro para o bolso do cliente, conhece as necessidades do cliente, funciona como proxy em ambientes com mais de um cliente. Gerencia a visão e a entrega!
• Time: Formado geralmente por 4 ou 5 pessoas e multidisciplinar. Ele define metas das iterações, auto-gerenciado e produz produto com qualidade e valor para o cliente. Gerencia a sprint de desenvolvimento.

Como é o processo do Scrum?

Só clicar na imagem para vê-la ampliada.

Como você pode ter percebido, o Scrum tem um processo bem definido e neste ponto ele é rígido, até pelo fato dele determina poucas coisas (tanto que consegui ilustrar num único desenho), mas o que determina você tem que seguir. Por isso, é rígido.

Vantagens e Desvantagens

Como é de praxe ao conhecer algo novo, sempre buscamos saber quais são as vantagens e desvantagens, portanto, segue abaixo as principais vantagens e desvantagens do Scrum:

• Vantagens
  • Os papéis são bem definidos, todos têm conhecimento sobre as suas responsabilidades;
  • É um processo ágil e flexível, tornando melhor a reação as mudanças que ocorrem durante o projeto;
  • É focado no controle e gerenciamento, buscando minimizar os riscos e maximizar a qualidade;
  • Os times são pequenos, a comunicação é mais eficiente;
  • Espírito colaborativo.
• Desvantagens
  • Ausência de práticas de Engenharia de Software, pois é voltada para o gerenciamento do projeto;
  • Necessita a associação de uma outra metodologia de Engenharia de Software, por exemplo XP;
  • É difícil de ser implementada, principalmente devido a resistência de mudanças culturais.

As duas primeiras desvantagens poderiam até ser desconsideradas, pois Scrum é voltado para a gerência de projetos e não para o desenvolvimento.

Scrum é mais uma modinha? Ou veio para ficar?

Acredito que a resposta depende muito da perspectiva que a pessoa tem, pois olhando de fora parece sim mais uma modinha, assim como ocorreu com o PMBOK. Sendo simplista a pessoa poderia até pensar que é apenas mais uma metodologia que tenta ser melhor do que as demais. Porém, para quem tem uma visão interna, que está realmente envolvido com o dia-a-dia do projeto, Scrum veio para ficar sim, ou melhor, os seus valores vieram para ficar.

Daí você pode está se perguntando, mas que valores são esses?

• Transparência;
• Ser empírico;
• Auto-organização;
• Integridade;
• Entrega de valor.

Além disso, o Scrum também tem como base os princípios ágeis do manifesto ágil:

• Indivíduos e iteração entre eles mais que processos e ferramentas.
• Produto em funcionamento mais que documentação abrangente.
• Colaboração com o cliente mais que negociação de contratos.
• Responder a mudanças mais que seguir um plano.

Nossa! Então Scrum é a famosa bala de prata!? Irá resolver todos os meus problemas?

Eu particularmente, sou bastante cético quando alguém fala que tal metodologia, framework, etc irá garantir o sucesso do seu projeto de desenvolvimento de software. Por isso, minha opinião é a mesma com Scrum.

Para mim ele é muito bom! Dentre os conhecimentos que temos sobre metodologias e afins na empresa em que trabalho, é o que melhor se encaixou a nossa realidade e o que trouxe mais melhorias.

Mas voltando a pergunta original do tópico, ele não irá resolver todos os seus problemas, pelo contrário, ele irá torná-los mais visíveis, e esse é um ponto que acho incrível. Pois se algo não estiver indo bem todos irão perceber bem rápido. Aliás uma das ferramentas que o Scrum traz  e que ajuda na visualização do andamento do projeto é o gráfico Burndown.

Qualquer pessoa, consegue identificar pelo gráfico acima, que a quantidade de testes automatizados esperada para o sprint 1 não foi alcançada. Eu poderia listar uma série de causas que fez com que o objetivo não fosse alcançado, afinal o gráfico apresenta um cenário real. Mas não é esse o intuito do post.

Portanto, precisamos nos lembrar que a metodologia em si não irá resolver os problemas, mas sim, poderá nos ajudar. Quem resolve os problemas são as pessoas!!!

Scrum é fácil de ser implantado?

Se fosse fácil qualquer um faria!

Há uma série de obstáculos que fazem com que a implantação do Scrum não seja uma missão fácil, entre eles:

• Não tem como você exigir que haja auto-gestão na sua equipe se ela não é uma característica dos membros da equipe;
• Implantar numa equipe grande demais (mais de 5 pessoas, por exemplo);
• O seu cliente não tem o menor interesse de cooperar. Ele é parecido com uma criança mimada que só quer e ainda bate o pé;
• O único comprometimento que os membros da sua equipe tem, é em relação ao salário deles.

Mas me diga uma coisa, alguém já disse para você que desenvolvimento de software é fácil?

É para todos os obstáculos apresentados há uma ou mais soluções:

• Treine a sua equipe, uma das maiores capacidades do ser humano é da aprendizagem, portanto incentive o seu uso;
• Divida a sua equipe, “modularize” melhor o sistema;
• Converse com o seu cliente, explique que a cooperação dele é fundamental para o sucesso do projeto;
• Motive a sua equipe, mostre que o que ela faz não é apenas garantir a própria sobrevivência.

Portanto, temos que está sempre preparados para superar os obstáculos, transformando-os em motivação. Afinal seria muito chato se você chegasse no trabalho e fizesse sempre o mesmo trabalhinho sem a menor dificuldade. 😉

Última pergunta. Por que falam tanto sobre Scrum?

No meu entender são dois motivos principais:

• Scrum está dando certo na empresas;
• As pessoas gostam de trabalhar com Scrum.

Quando você faz alguma coisa é dá certo, qual é a sua reação? Conta para outras pessoas, não é!? E irá contar para mais pessoas ainda quando você gosta do que está fazendo. Eu mesmo, falo sobre Teste e Qualidade de Software porque gosto, simples assim. E estou agora falando sobre Scrum pelo mesmo motivo. 🙂

Mas por favor, não interprete errado a minha simples pesquisa, não estou falando que usar as práticas do PMBOK não dá certo, ou coisas do gênero.

Minha intenção é que esse seja o primeiro de muitos posts sobre Scrum, afinal esse foi mais um bombardeio de informações. Até mais!

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

Fonte:

Você sabe o que é Scrum? – Nelson Abu

Scrum é um framework? – Luiz Claudio Parzianello

Scrum Gathering 2009 – Primeiro dia – Parte 2 – André Pantalião

SCRUM Processo de Desenvolvimento de Software – Dra. Eliane Martins (UNICAMP)

Magno, A. Apresentação do curso Certified Scrum Master (CSM). São Paulo, Caelum, 2008.

Imagens:

Formação do Scrum – Faculdade Oberlin

Define metas das iterações, auto-gerenciado e produz produto com qualidade e valor para o cliente. Gerencia a sprint de desenvolvimento.