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:

utilizacaofuncionalidades

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:

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.

TestingPyramid

testquad

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/

Anúncios

9 comentários sobre “Impressões do 6º Encontro Mensal da ALATS São Paulo

  1. Olá Ferrari,

    Estive ontem neste mesmo evento. O Jorge Diz tem um conhecimento que nem precisa ser mencionado, sua vasta experiência na área e apresentações já feitas o introduzem, porém acredito que o tema proposto ontem, não foi abordado, de leve foi feita uma pequena introdução. Para qualquer um que tenha um pouco de conhecimento sobre técnicas ágeis em testes pode ter percebido que nem ao clímax da palestra chegou.
    É uma lástima, pois acredito que todos que foram ontem tinham a intenção de discutir sobre Scrum em Testes, e não perder o foco da discussão em assuntos que particularmente acredito serem “temas livres” para uma bela filosofia de bar =).

    Abraços!

    Responder
    • @José Papo

      Obrigado pelo comentário, já tinha lido os artigos, e recomendo para aqueles que ainda não leram. 😉

      @Evandro

      Concordo. A minha expectativa era ver uma palestra sobre como metodologias ágeis influenciam a nossa área, o que não ocorreu ontem. Pelo que vi a apresentação tinha mais de 110 slides e parou no 60 mais ou menos. Realmente estávamos um pouco longe do clímax da palestra. Uma pena.

      Abraços! E obrigado pelo comentário.

  2. Olá Ferrari e Fabricio,

    Conversei com o Jorge Diz após o evento, realmente a apresentação dele era muito grande para o tempo que dispunhamos, gastou-se muito tempo na conceituação e quando chegou a parte de metodologias agéis já estavamos até mesmo atrasados para concluir. Das duas partes que o evento pretendia cumprir, não saimos da primeira.

    Não gostaria de prejudicar o Jorge, que é um profissional muito competente, que por ser um apaixonado pelo assunto, como todos puderam constatar no evento, mas que acabou se perdendo na administração do tempo. Nem os participantes, que não obtiveram as informações que os atrairam ao evento. Nesse sentido, estamos convidando a todos os inscritos a uma nova palestra, completando o conteúdo que faltou na quarta-feira, 14 de outubro, no mesmo local e horário, sem qualquer ônus.

    E nós da ALATS SP iremos daqui em diante verificar com maior atenção o conteudo das apresentações no sentido da duração da palestra.

    Peço desculpas pelo incidente e espero que todos ou grande parte dos participantes possam voltar e fazer essa complementação.

    Ferrari, conto com que nos dê a oportunidade de corrigir a situação através da sua presença no evento e com um novo post com as observações sobre se a nova apresentação alcançou o esperado.

    Obrigado e abraços,

    Responder
  3. Felizmente a ALATS-SP ministrará a segunda parte da palestra(a mais esperada, com o conteúdo exibido incompletamente), no dia 14/10, para os participantes da primeira. Isso demonstra o compromisso e a responsabilidade que a ALATS tem com a comunidade de testes e interessados.

    Responder
  4. Olá,

    também estive na palestra. Porém não gostei muito, pois o foco demorou a ser abordado. E gerou uma duvida em minha cabeça, principalmente com relacao ao analista de testes saber codigo e uma empresa utilizar scrum. Nós estudamos, nos especializamos em testes para depois fazermos outro trabalho? Nao vejo sentido nisso, e creio que uma equipe que todo mundo faz tudo acaba fazendo tudo mais ou menos …

    bem, o scrum e etcs tem la suas vantagens, acho importantissima a reuniao diaria, todos saberem de tudo que acontece no projeto…mas ainda acho que cada um tem seu lugar…tem seu papel!

    Responder
    • Olá Regiane!

      Na minha opinião, o Analista de Teste em um time Scrum pode auxiliar os desenvolvedores na criação de testes unitários por exemplo, mas chegar a implementar uma funcionalidade sozinho já não faz muito sentido mesmo. Utilizando Scrum o time é multidisciplinar, mas isso não que dizer que os integrantes também necessitam ter conhecimentos técnicos de várias áreas.

      Há uma boa discussão no grupo Scrum-Brasil sobre o assunto, vale a pena dar uma lida:

      http://br.groups.yahoo.com/group/scrum-brasil/message/4574

      Quanto a saber programar… é um conhecimento que pode ser muito útil para o pessoal de Teste de Software, assim como é muito útil saber banco de dados, redes, SOs, etc. Tudo depende da natureza do projeto, que irá exiger conhecimentos específicos do pessoal de teste, e também o nível do profissional de teste.

      Agora é esperar pelo dia 14/10 para podemos ver a segunda parte da palestra. 😀

      Abraços!

  5. Fabrício:

    Obrigado pelos comentários sobre a palestra: vc resumiu muito
    bem o conteúdo e passou a essência do que eu queria apresentar.

    Realmente houve o problema da administração do tempo e de
    expectativas. Vou tentar amenizar isso na próxima quarta 14/10,
    apresentando demonstrações das principais ferramentas.

    Sei que o assunto do papel dos profissionais de teste no contexto da agilidade dá muito pano para manga. As discussões em cima do artigo recente do José Papo (excelente por sinal) e a minha própria experiência mostram isso.

    O ponto é que, se queremos entregar software com qualidade, devemos prestar atenção a tudo o que afeta essa qualidade. Eu advogo que o profissional de testes não pode ter medo de meter a colher onde sua contribuição faz diferença.

    Infelizmente, o papel dos testes no apoio ao time ainda não é enxergada por muitos: a mentalidade de controle da qualidade prevalece. Precisamos é de “promoção da qualidade”

    Prefiro não usar a expressão “garantia da qualidade”, em parte porque ela foi encampada, no mindshare dos profissionais de TI, por modelos nos quais não acredito. Também porque, até hoje,
    não encontrei nenhum modelo consistente para quantificar um nível de garantia da qualidade: as métricas que poderiam ser usadas em
    acordos de nível de serviço não têm correlação com diversos aspectos da qualidade que, por enquanto, permanecem subjetivos e intangíveis.

    []s

    Jorge

    Responder
  6. Pingback: Impressões do 6º Encontro Mensal da ALATS São Paulo – parte 2 « QualidadeBR

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s