Quem é o Agile Tester?

A definição

agile-tester-artigo1Segunda Lisa Crispin e Janet Gregory em seu livro Agile Testing: A Pratical Guide for Testers and Agile Team [1] o que define o Agile Tester é:

Definimos o Testador Ágil neste sentido: um profissional que encara as mudanças, colabora bem com pessoas técnicas e de negócio e entende o conceito de usar os testes para documentar os requisitos e guiar o desenvolvimento.

Testadores Ágeis tendem a ter bons conhecimentos técnicos, e sabem como colaborar com outros membros do time para automatizar testes e também são experientes em executar testes exploratórios.

Eles estão dispostos a aprender o que os clientes fazem para que eles possam entender melhor os requisitos.

Eu, propositalmente, dividi em três partes para ficar mais visível tudo o que um Agile Tester é e o que ele pode fazer!

Mas a primeira resposta a pergunta “Quem é o Agile Tester?” é: qualquer pessoa do time!

Porque qualquer pessoa pode pegar uma tarefa de teste para executar. Qualquer pessoa pode pensar como um usuário no momento de um planejamento. Qualquer pessoa pode executar um teste exploratório.

Para alguém do time possuir estes skills, primeiramente, ele precisa ter o MindSet do Teste Ágil.

O MindSet do Teste Ágil

agile-tester-artigo2O time, ao invés de entregar o melhor produto, deve entregar o melhor valor de negócio para o cliente através de um produto, certo?

A grande maioria dos times focam em entregar o melhor produto, mas nem sempre o melhor produto traz o melhor resultado de negócio.

É aqui que o MindSet entra: trocar informações constantes e colaborar com o cliente* a fim de ajuda-lo a expressar de forma adequada os requisitos.

O restante dos pontos é a viabilização disso (tarefas). O MindSet é único: colaboração com o cliente para que ele mesmo entenda o que está pedindo.

Alguns itens que podem ser adicionados ao MindSet são:

  • Criatividade
  • Estar aberto a novas ideias
  • Disposição para assumir qualquer tarefa
  • Foco no cliente
  • Visão constante na Big Picture (no todo)

* a palavra “cliente” pode ser interpretada como o cliente real ou o product owner (dono do produto)

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Técnico, Testes, Time de desenvolvimento

12 Dicas para uma Sprint Retrospective Meeting efetiva (Parte I)

A Sprint Retrospective é a oportunidade para todo o Scrum Team (Product Owner, ScrumMaster, e Development Team) para se inspecionar e criar um plano de ação para as melhorias para a próxima Sprint.

1.      Excelente ScrumMaster = Excelente Retrospectiva

Tudo o que você precisa é de um excelente ScrumMaster

certified-scrum-masterExistem milhares de técnicas de retrospectiva publicadas em livros e em blogs que quando BEM aplicadas alcançam resultados maravilhosos. A questão principal é saber como e quando aplicar uma determinada técnica ou fluxo ao invés de outra.

Eu sou muito fã da técnica StarFish e recomendo para os ScrumMasters iniciantes e experientes a utilização desta técnica. Pois já tive momentos bons assim como já vi colegas tendo resultados empolgantes com essa técnica.

Mas confesso que nem sempre tenho sucesso ao aplicar essa técnica e que o sucesso veio com a pratica. Pois a questão principal não era saber apenas a técnica e sim saber como facilitar uma retrospectiva.

Alguns colegas dizem que musculatura de retrospectiva só se ganha com o tempo, a pratica e a vontade de melhorar a facilitação. E assim se tornaram melhores facilitadores e suas Sprint Retrospectives se tornaram cada vez melhores assim como os seus Scrum Teams.

E finalmente o Certified Scrum Trainer Alan Cyment vai alem ao dizer que tudo que o Scrum precisa é de um excelente ScrumMaster para começar a fazer Sprint Retrospectives. Por isso espero que as próximas dicas te ajudem a se tornar um excelente ScrumMaster.

2.      Faça a Sprint Retrospective em um momento auspicioso

Uma Sprint não precisa terminar as Sextas

Existe uma tendência de se iniciar Sprints as segundas e terminar as sextas, todavia isto pode não funcionar.

E qual o problema de se fazer a Sprint Retrospective as Sextas?

O seu Development Team pode estar cansado de uma semana intensa de trabalho e participar apenas fisicamente da reunião e terá problemas para manter a presença mental na reunião.

Dependendo do horário da Sprint Review e da Sprint Retrospective alguns times ficam compelidos a fazer trabalhos complexos como implantação e testes exploratórios em um dia em que o foco pode estar no final de semana. Isso se não for encontrado um bug e o resultado da Sprint não for como o esperado.

E dependendo do que é falado na Sprint Retrospective muitos finais de semanas podem ser estragados, ou ainda, algumas situações podem ficar piores…

E finalmente, Estudos mostram que a sexta-feira tem uma ligação forte com os conceitos de “Liberdade” e “Partir”. De certa forma, sexta-feira é o dia que tipicamente as pessoas estão mais focadas em no fim de semana do que em qualquer outro tema. Basta lembrar quantas vezes na sexta-feira o assunto do seu Scrum Team é o final se semana.

Sprint Retrospectives na Sexta-Feira funciona em muitos Scrum Teams, todavia isso pode não ocorrer no seu ambiente de trabalho.

3.      O corpo fala

Escute as palavras e veja o real significado

o-corpo-falaInfelizmente ainda não é possível saber o que outra pessoa está pensando. Dessa forma entender as reais intenções de uma pessoa é algo que beira o impossível.

Podemos ter um melhor entendimento das reais intenções das pessoas por meio das expressões corporais. Por exemplo:

Braços cruzados podem significar desde uma postura defensiva ou de insegurança até uma postura de hostilidade. Uma posição relaxada com braços e pernas ligeiramente abertas demonstra autoconfiança e segurança. Já uma postura recolhida significa tédio.

Movimentos de cabeça de um lado para o outro significam negação, já movimentos de cabeça para cima e para baixo consentimento. Uma postura erguida demonstra segurança, valor e importância no que você está fazendo. E mãos na cintura significam desafio, agressividade.

Alguns sinais corporais podem trazer impressões incorretas, todavia desconsiderar essas informações valiosas em uma facilitação pode levar a resultados desastrosos.

Em outras palavras, comece a ler o Best Seller “O Corpo Fala – A Linguagem Silenciosa da Comunicação Não-verbal” do Pierre Weil e do Roland Tompakow.

4.      Presença obrigatória do Product Owner

A participação do Product Owner é essencial na Sprint Retrospective

O Product Owner é obrigado a participar da Sprint Retrospective. E acredite isto está escrito no Scrum Guide. A primeira frase do Scrum Guide sobre a Sprint Retrospective é a seguinte:

“A Sprint Retrospective é uma oportunidade para que o Scrum Team inspecionar a si próprio e criar um plano de melhorias para ser aplicado na próxima Sprint.”

Tendo em vista que o Scrum Team é compreendido pelos três papeis do Scrum incluindo o próprio Product Owner. A presença do Product Owner é obrigatória, seu Scrum Team gostando ou não.

A questão principal é que existe a responsabilidade do ScrumMaster em garantir a segurança psicologia de todos os envolvidos durante a Sprint Retrospective.

Por exemplo, com frequência o Development Team não se sente à vontade em frente ao Product Owner, por questões que vão desde arrogância, hierarquia, desconfiança, dentre outras. Nestes casos Peter Hundermark recomenda que, temporariamente, o Product Owner não participe das Sprint Retrospectives e o ScrumMaster trabalhe em paralelo estas questões objetivando a segurança psicológica da reunião.

Vale lembrar que o Scrum demanda muito trabalho do Product Owner e estes precisam ser capazes de colaborar com a melhoria continua dos processos dentro do Scrum. Como exemplo de processos em que o Product Owner é essencial tem-se a priorização e a preparação dos itens do Product Backlog e o relacionamento com os Stakeholders.

5.      Não buscar culpados

Diga não à caça às bruxas!

apontando-erradoUm dos maiores receios ao se entrar em uma Sprint Retrospective é o de que a reunião se torne uma sessão de caça às bruxas, onde a única coisa que importa é buscar culpados.

Claramente tal atitude não contribuirá para a evolução do time ou para um melhor desempenho coletivo. Com esse raciocínio Norman Keath define a primeira diretiva de uma boa Sprint Retrospective como:

“Independentemente do que descobrirmos, nós entendemos e realmente acreditamos que todos fizeram o melhor que podiam, dado o que eles sabiam no momento, as suas competências e capacidades, os recursos disponíveis, bem como a situação na mão. ”

Dessa forma a chave para uma Sprint Retrospective bem-sucedida e construtiva é garantir que todos os participantes estejam de acordo com essa diretiva. E assim teremos um tão sonhado evento de aprendizagem coletiva que irá dar bons resultados no longo prazo.

6.      Checar e Atuar

Sempre há algo a melhorar no processo

O mais importante de uma Sprint Retrospective é o comprometimento dos envolvidos com as melhorias do processo de desenvolvimento de software.

No Scrum temos diversos ciclos de PDCA (Plan-Do-Check-Act) sendo executados com diferentes objetivos. Na Sprint Retrospective é feito o Checagem do processo e a criação de um plano de ação para melhorias.

Jean Tabaka menciona que sair de uma Sprint Retrospective sem um plano de ação é uma das maiores falhas possíveis, mas de nada adianta criar um plano de ação e este não for foco de atuação durante a próxima iteração.

Existem estratégias como um backlog de melhorias, expor o plano de ação em local visível, e pedir para todos os envolvidos escrever o plano de ação auxiliam na implementação das melhorias. O ScrumMaster deve guiar a melhoria dos processos, todavia deve haver o comprometimento de todos os membros do Scrum Team com a melhoria continua de processos.

Jeff Sutherland finaliza neste vídeo com a seguinte definição de Sprint Retrospective:

“ A Sprint Retrospective é desenhada para corrigir o problema mais importante. E quando isso ocorre, o Development Team acelera e começa a ir mais rápido, assim como a qualidade também aumenta. Dessa forma a Sprint Retrospective é crítica para o aumento da performance do Development Team.”.

___________________________________________________________________________________________________________________

Gostou? Aqui você encontra as outras 6 dias para tornar a sua Sprint Retrospective ainda mais eficiente.

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

1 Comentário »

Categorias deste post

Daily Meeting, Scrum, Sprint, Sprint

Personas Ágeis para User Stories

Descrição completa

Por que personas são relevantes em contextos ágeis?

Em projetos ágeis “personas” devem ser vistas como uma ferramenta fantástica nas mãos de um time.
A equipe do Product Owner (composta pelo P.O., especialista em experiência do usuário, analista de negócios…) pode, facilmente, utilizar de “personas” para alinhar suas expectativas com o time funcional (arquitetos, desenvolvedores, testes…) proporcionando uma visão compartilhada e realista do produto em desenvolvimento. E usar personas pré-definidas como atores de user stories farão com que os requisitos descritos tenham mais credibilidade e mais envolvimento, aproximando-os ainda mais da realidade.

Detalhando:

personas-ageis-para-user-storiesPersonas é uma ferramenta de usabilidade que utiliza pessoas fictícias para representar usuários. Utilizamos personas em projetos centrados no usuário (For Them By Us), definindo os objetivos e desejos dos reais usuários, orientando decisões como: a interface, a navegação, os recursos e demais elementos do projeto de design.

Usar personas é recomendado quando não há nenhuma documentação sobre quem é o usuário do seu produto ou se quer especializar a UI (user interface) do produto para o seu público alvo, com base em pesquisas entrevistas, etc. Mas quando estamos em um projeto onde o usuário final não é humano, por exemplo um sistema system-to-system, uma API, etc. onde nenhum que irá interagir com o sistema é humano acho que não faz muito sentido usar personas.

personas-ageis-para-user-stories_2E como explica Martin Fowler, User Stories focam nos objetivos
do usuário e como o sistema alcança esses objetivos. User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno cartão

Alguns perguntarão o motivo desta proposta estar em “Design” – lembrando que design é a idealização, criação, desenvolvimento, configuração, concepção, elaboração e especificação de objetos que serão produzidos. O projeto de design necessita de uma análise informacional, a partir de um ponto de vista. Detectar corretamente as “personas-usuárias” e relacioná-las ao objetivo do projeto (user stories) é essencial para um bom planejamento, de modo que as ações sejam tomadas de forma correta – assim, segue esta proposta, pois para quem é designer, quem é o usuário, e quem é o público final, representa o primeiro passo.

Sugestão de dinâmica para aprendizado de Personas

Mecânica do Workshop

1) O grupo de participantes será dividido em 5 times, através de uma dinâmica simples, baseada na diversidade de informações sobre os próprios participantes (onde moram, onde trabalham, cargo exercido, idade, sexo, etc.) fazendo-os mixarem-se em times que prevaleça a diversidade. (time-box 5 minutos)

2) Um sistema web “fictício” em desenvolvimento será mostrado: loja online de feijoadas delivery. E algumas informações sobre cozinheiros, fornecedores de ingredientes e clientes desta loja online de feijoadas delivery serão apresentados: em slides e cartões de papel e entregues aos times.
A facilitadora se nomeará Product Owner principal do produto: loja online de feijoadas delivery. (time-box 5 minutos)

3) Uma introdução sobre personas “driven-design-personas” será apresentada aos times: em slides e cartões de papel e entregues aos times. (time-box 15 minutos)

4) Serão solicitados a criação de mais 2 personas por time, a partir das informações apresentadas previamente. (time-box 10 minutos)

5) Uma introdução sobre user stories, baseadas nos 3Ws e 3Cs será apresentada aos times: em slides e cartões de papel e entregues aos times. (time-box 10 minutos)

6) Serão solicitados a criação de mais 3 user stories por time, a partir das informações apresentadas previamente para as 2 personas criadas pelo próprio time. (time-box 15 minutos)
– Durante o processo de criação, de personas e US pelos times, a facilitadora irá circular pelos participantes esclarecendo dúvidas e pontuando conceitos dados.

7) Os times apresentarão suas personas e user stories para os demais participantes, com pequenas intervenções da facilitadora para garantir time-box e ressaltar conceitos vistos. (time-box 15 minutos)

8) Encerramento e dúvidas. (time-box 5 minutos)

Benefícios

Uma grande vantagem de se utilizar personas é que se pode facilmente interligá-las com user stories, em substituição do “ator”. Isto faz com que suas personas e user stories tenham mais credibilidade e mais envolvimento, aproximando ainda mais da realidade.

E a melhor forma de aprender sobre personas e interliga-las com user stories de um produto, é escrevendo ambas. Hand´s on.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Time de desenvolvimento