Complementando a visão da user story com a técnica do “Los Tres Amigos”

Introdução

Um dos grandes desafios dos métodos ágeis sempre foi o entendimento compartilhado sobre uma feature/story. Muitos times, geralmente no Backlog Grooming e no Sprint Planning, tem o entendimento destes artefatos de uma forma muitas vezes incompleta não levando em consideração a visão de todos os papéis do time gerando confusões, duplicações, complexidade e retrabalhos.

Los Tres Amigos

Também conhecido na literatura como Power Of Three ou Specification Workshop este processo onde, durante uma reunião (que tem o melhor ganho sendo no Sprint Planning), um Analista de Requisitos, um Programador e um Testador irão discutir em conjunto a feature/story e revisar este(s) artefato(s). O ideal é que este processo esteja de um a dois timeboxes na frente da iteração atual (abaixo você entenderá os motivos).

O processo é simples:

  1. O Product Owner inicia e faz a mediação da sessão apresentando a feature/story apresentando todos os subsídios necessários para o entendimento dos Tres Amigos
  2. Os Tres Amigos (Analista de Negócio, Programador e Testador) identificam suas necessidades e expõe sua visão sobre a feature/story e listam todas as dependências, necessidades, problemas e criam exemplos para deixar mais claro o entendimento
  3. Depois dos Tres Amigos terem o entendimento compartilhado é o momento de prover estimativas de desenvolvimento e testes

los-tres-amigos

Quais os benefícios deste processo?

Obviamente o entendimento compartilhado que remove uma série de problemas e apresenta muitos benefícios:

  • Detalhamento de forma colaborativa: não haverá mal-entendidos os dúvidas básicas quando o trabalho é feito pelos Los Tres Amigos
  • O que deve ser testador é criado por todos: não é só tarefa do testador dizer o que pode ser testado, o que não pode e qualquer ação referentes a testes. Todo o time cria de forma colaborativa os testes
  • Revisão em conjunto: ao aplicar o processo já estamos revisando tudo o que é necessário em conformidade com o DoR e o DoD
Nenhum comentário »

Categorias deste post

Técnico, Testes

The Evolution of the Testing Pyramid

Introduction

As software testers, we’ve all heard about the Testing Pyramid. However, in my opinion (and in the opinion of others), there’s a misunderstanding in how we should apply the Testing Pyramid in our projects.

If you have never heard about the Testing Pyramid I recommend you read these posts in this sequence (believe me, doing this will help you understand this post better):

  1. Mike Cohn Testing Pyramid

  2. Test Pyramid by Martin Fowler

  3. Ice Cream Cone Anti-Patter by Alister Scott

  4. Cupcake Anti-Pattern

Let’s Think

Now, it’s time for some critical thinking.

Question: When we see a model, what is the first thing that we do?
Answer: Follow it!

Let’s be honest with ourselves: we follow the model without question (in most of the cases). But have you realizes that the Testing Pyramod is a model and a analogy?

The first post that I referred to says:

Remember that this is just a model, it is not a hard-and-fast rule that should be adhered to in every software project. (James Willet)

Many people try to use the Testing Pyramid like a hard-and-fast rule, believing that all of the tests should be pushing to the base of the pyramid because we need fewer and fewer tests in the UI. I disagree.

Testing Geometrics

After reading all these posts and concepts, do you agree with me that a strategy for testing automation is more like a Testing Geometrics than a Testing Pyramid?

Obviously, we have a lot of geometric shapes: pyramid, pentagon, rectangle, star, ellipse, and so on (try to google geometric shapes).

Now, consider the following in that mindset:

In a scenario in which you need to test a mobile app, the focus will be the user interface, correct? However, if you keep thinking that the Test Pyramid is a rule, you cannot focus (and put more tests than the other layers) in the UI layer. No, you can put however many tests you find necessary!

When we test a mobile app, at least three layers need to be tested: unit, services, and UI (this fits perfectly in the first Test Pyramid). However, if you miss a bug in the UI layer in production, what do you think is the first thing that the user will do? Obviously, it’s not reporting the bug; it’s a complete uninstallation of your app! (And the user, probably, will never return or install it again.)

So, wich geometric shape can you use to focus more on the UI layer? I say a cylinder because all of the tests in these three levels are important.

In a scenario in which you need to test microservices, the focus will be the unit tests, correct?

Again, if you keep thinking that the Testing Pyramid is a rule, you cannot focus (and cannot put more tests) in the Service layer.

If you are building a microservices, the UI layer is missing, and you will focus on the unit tests. However, the services are the heart of this. You must test them! Remember, you need to test all of the services.

So, wich geometric shape can you use to focus? I should say a star!

“But Elias, a star?” Yes!

You’ll do some unit tests, but (in my opinion) the services test will have more focus. You need to integrate each service in another test or suite in order to guarantee the sanity of this integration.

Nenhum comentário »

Categorias deste post

Técnico, Testes

3 Dicas para a Documentação de Teste em uma Equipe Ágil

  1. Minimize a sua documentação

Não crie documentos só porque é uma prática da empresa se você não sabe realmente onde ele será empregado (como será utilizado, quem irá ler o documento, etc…).

Criar documentação “só por criar” gera um custo muito alto, visto que temos sempre “pouco” tempo para uma entrega. Logo devemos criar somente entregáveis utilizáveis. Se o documento que você está criando não é utilizável interna ou externamente ele pode ser removido.

Se há documentos que você precisa criar por conta de alguma legislação, obviamente, crie! Mas não se esqueça que este deve ser estimado e priorizado (sim, ele vira uma tarefa) e precisa fazer parte da sua Definição de Pronto (DoR).

Exemplo prático referente a teste de software – Evidência de Teste

Muitas instituições financeiras necessitam documentar as evidências de teste. As evidências de teste são prints de telas, de partes estratégicas da aplicação, que são colocadas com uma descrição. É muito comum criarmos evidências de teste quando encontramos bugs para reportar a uma pessoa/equipe quando este não pode ser corrigido imediatamente, mas também é uma prática documentar os cenários de sucesso por conta de legislações vigentes em instituições financeiras (Sox)

doc-de-teste-agil-blog

  1. Mantenha a documentação sempre simples

Criar gráficos, tabelas, diagramas coloridos e qualquer outro apelo visual que só servirá para “deixar o documento mais bonito” e sem informação efetiva, ou com muita informação, só faz você perder tempo. Seja simples e direto no documento. Ninguém gosta de perder tempo (horas) lendo algo que poderia ser absorvido em minutos.

Exemplo prático referente a teste de software – Plano de Teste

Antigamente (não muito tempo atrás) e até hoje muitos testadores mesmo em times ágeis continuam criando documento de Plano de Teste em um padrão/template conhecido da IEEE 829 (referente a documentação de teste). O documento é muito extenso, possui vários tópicos e não é nada direto, ou seja, uma perda de tempo precioso para o time.

Agora pense comigo: o testador (ou o papel deste) não planeja os critérios de aceite com vocês (time)? Já não está saindo o planejamento ai? Precisa de documenta para isso?

Há alguns casos, obviamente, onde iremos fazer um planejamento prévio como por exemplo a aplicação de testes de Performance, Carga e Stress. Mas no dia a dia o documento é bem pouco utilizado e, mesmo que você crie, foque em pontos chave e não o deixe extenso.

Sugiro a leitura da sessão Test Planning do Livro Agile Testing.

  1. Documente somente quando necessário

Focar na criação de diversos documentos que você necessita ao longo do tempo não é uma boa ação (big-requirement-upfront). A documentação de teste deve ser criada por demanda e, se tiver necessidade, por partes. O tamanho da documentação também importa. A documentação tem que ser objetiva, mas não pode habilitar o contexto da comunicação como em uma User Story: o documento de testes deve ser entendido por todos os membros do time e agentes externos (stakeholders) para que todos tenham um exemplo real de como a funcionalidade/requisito/regra deve funcionar.

Exemplo prático referente a teste de software – Critérios de Aceite descrito como Especificação por Exemplos

Uma documentação obrigatória para habilitar o entendimento dos requisitos, guia do desenvolvimento e validação pelo usuário final é o Critério de Aceite. Ela é criada geralmente em conjunto com o time e o cliente.

Este pode ser escrito de diversas formas. A mais recomendada para o entendimento por todo time é através da Especificação por Exemplos.

Através dela podemos, de uma só vez, informar como será o detalhe do requisito em termos de utilização mais o exemplo de dados que utilizaremos.

Uma forma comum é adotar a escrita dos Critérios de Aceite através do Ghekin (Given, When, Then). Abaixo um exemplo:

Dado que eu estou na página inicial da Adaptworks

Quando eu pesquisar pelo treinamento “Agile Testing”

Então o treinamento “Agile Testing” é apresentado

 E o treinamento “Agile Testing Automation” é apresentado

Exemplo prático referente a teste de software – Plano para Testes de Performance

O plano para a execução dos Testes de Performance é um exemplo de uma documentação de teste evolutiva ao longo do projeto. Vamos pegar o exemplo onde precisamos executar testes de performance antes da entrega da Release. A cada iteração iremos planejar quais serão os fluxos criados para o script de teste, coletar a massa de dados necessária, conversar com o pessoal de infraestrutura para ter um ambiente suportado ou mesmo o ambiente de produção, aplicação de monitores em diversas partes da arquitetura, etc…

Isso é muito difícil de fazer em apenas uma iteração, onde dividimos todas as tarefas referente a esta ação em diversas partes.

___________________________________________________________________________________________________________________

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

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

Facebook  |  Twitter  |  Linkedin | Youtube

1 Comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

12 Dicas para uma Sprint Retrospective Meeting efetiva (PARTE II)

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

Aqui você encontra as 6 primeiras dicas para uma Sprint Retrospective eficiente.

7.      Faça a Sprint Retrospective

Não fazer a Sprint Retrospective é o mesmo que não usar Scrum

A Sprint Retrospective é o coração do Scrum, a ponto de muitos praticantes experientes dizerem que é a reunião mais importante. Jean Tabaka afirma que não fazer a Sprint Retrospective é a pior falha possível em relação a este evento.

A Sprint Retrospective é o momento em que os membros da equipe têm a oportunidade de inspecionar e adaptar o seu processo. E é nela que os membros do Scrum Team conversam sobre o que deu certo, o que poderia ter sido melhor e o que pode ser feito melhor para a próxima Sprint. O objetivo é o foco de ao menos uma melhoria no processo, ou Kaizen, e iniciar a implementação de imediato.

O processo da melhoria continua é considerado tão importante dentro do Scrum que é peça central do raciono do aumento de produtividade de um Scrum Team. Sendo considerado por Jeff Sutherland um dos principais artifícios para aumentar a produtividade do Scrum Team, ou um dos itens fundamentais para “fazer o dobro do trabalho na metade do tempo”.

srum-meeting8.      Todos têm algo importante a falar

Todos pensam, todos falam

Um ScrumMaster pode de forma inconsciente filtrar ou desconsiderar o que uma das pessoas está dizendo e isto pode destruir a Sprint Retrospective, segundo Jean Tabaka essa é uma das formas mais eficientes de destriu-la.

Existe um teste muito interessante proposto pelo Marcelo Leite para fazer uma autoavaliação da imparcialidade de um líder que deveria ser feito por todos os ScrumMasters que acreditam em sua imparcialidade.

Nele você é levado a se perguntar sobre sua relação com seu “Colega Não Favorito” e se você realmente consegue ser imparcial em sua relação a ele dentro do local de trabalho.

Caso você tenha tido um resultado próximo do meu, recomendo que você reflita o quão imparcial você é e se ao facilitar você tem momentos iguais ao do Deputado Frank Underwood, interpretado pelo Kevin Spacey, na série House of Cards.

9.      Musica dá o tom no ambiente

Música ajuda a relaxar e pode ajudar a dar o tom na sua Sprint Retrospective.

Estudos mostram que pessoas de diferentes épocas e culturas experimentam uma gama universal de reações emocionais a intervalos musicais específicos. Como se houvesse uma espécie de gramática universal tonal. Para ajudar, estudos mostram que nos esportes ouvir sua música preferida melhora o desempenho dos profissionais.

O difícil é descobrir músicas que funcionem, algumas dicas:

10.      Fluxo de facilitação na Sprint Retrospective

Utilize um fluxo para chegar em algum lugar

Não planejar a Sprint Retrospective e não seguir um fluxo podem ter consequências desastrosas em uma Sprint Retrospective. Principalmente em inicios de projeto ou quando a Meta da Sprint não foi alcançada.

Frisar a primeira diretiva do Norman Keath, uma dinâmica de warm-up, um momento especifico para falar o que foi bem, e um momento para que todos se comprometam com a melhoria podem ser a diferença entre o sucesso e o fracasso do projeto.

Existem muitos fluxos de Sprint Retrospective publicados na internet, para citar três exemplos famosos e que estão disponíveis gratuitamente:

11.      Foco nas três perguntas

Scrum não é patrocinado pela empresa que faz marcadores autoadesivos

Existe um lado lúdico e romantizado ao se utilizar flipchart e marcadores adesivos nesta reunião. Para muitos a Sprint Retrospective se resume ao ScrumMaster facilitar uma reunião mediada por uma técnica.

Primeiramente Post-it não faz parte do core do Scrum, da mesma maneira que o Planning Poker, a User Story, e o quadro de Kanban não fazem parte do framework.

O Rafael Nascimento, Agile Coach na Adaptworks, comenta que passou mais de um ano em uma multinacional facilitando diversas reuniões e nunca usou um post it.

O foco do Rafael em uma Sprint Retrospective era sempre fazer com que as seguintes três perguntas fossem respondidas:

  • O que foi bom?
  • O que melhorar?
  • Como melhorar?

srummaster12.      O ScrumMaster é uma pessoa

O ScrumMaster isento existe?

Muito se fala e lê sobre o ScrumMaster se manter isento durante esta reunião. A maior dificuldade está relacionada ao fato que em sua essência o ScrumMaster é uma pessoa.

E uma pessoa e por isso tem vieses cognitivos. Como exemplo de vieses posso citar:

Uma pessoa que busque evidencias que confirmem uma hipótese inicial de problema ou solução e não permita enxergar outras possibilidades pode parecer teimosia, mas para psicólogos isso tem o nome de viés da confirmação.

Aliado ao fato do viés do observador, o ScrumMaster pode enxergar com clareza um problema que não existe e mesmo assim tentar soluciona-lo.

Um exemplo claro nisso é um observador externo ao time enxergar anarquia em um time auto organizado. Para um observador externo a anarquia é imensa, mas na realidade não existe um padrão facilmente detectável de organização. O problema fica gigantesco quando o observador tendência a propor soluções centralizadoras para uma característica do sistema auto organizado.

Estudos mostram que as escolhas das massas influenciam diretamente como uma pessoa faz escolhas mesmo que vá contra o próprio juízo da pessoa. Esse é o famoso viés da conformidade.

O extremo do viés da conformidade nos leva ao pensamento de manada, que é um fenômeno em que o desejo pela harmonia do grupo faz com que as opiniões pessoas sejam suprimidas. Pois pensamentos contrários se tornam tóxicos e fica mais difícil ainda alterar o status quo.

Um ScrumMaster não consciente desses vieses pode se deixar levar pela opinião do grupo e suprimir ideias e opiniões importantes.

Já o efeito de ancoragem é um viés cognitivo que que descreve em se “ancorar” em uma característica ou parte da informação recebida. Em outras palavras, a dificuldade de se afastar da primeira impressão.

Dessa forma um ScrumMaster que tenha a impressão que a culpa de um insucesso seja um determinado processo irá se ancorar e terá dificuldade em ver o que está realmente ocorrendo.

De forma resumida, o ScrumMaster não é uma máquina de facilitação, mas sim uma pessoa. Que deve sempre focar em processos de facilitação para se isentar o máximo possível.

Referencias

As dicas foram baseadas na minha experiência pessoal, no e-book do Better Scrum, vídeos como o da Jean Tabaka no Scrum Australia, de websites como o do Norman Kerth, e artigos como: http://www.administradores.com.br/artigos/carreira/voce-e-realmente-um-lider-imparcial-faca-o-teste-e-descubra/79793/ do Marcelo Leite, Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana (http://blog.loomio.org/2013/11/20/occupy-scrum/).

Vale ressaltar que li intensamente o Scrum Guide de 2013 para que o conteúdo ficasse aderente ao que consta no texto base do Framework Scrum.

___________________________________________________________________________________________________________________

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

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

Facebook  |  Twitter  |  Linkedin | Youtube

1 Comentário »

Categorias deste post

Scrum, Sprint, Sprint

O que buscar em uma plataforma ALM Agile ?


Application Lifecycle Management
(ALM) é o processo de gestão de todas as fases do ciclo de desenvolvimento de software a partir de requisitos iniciais até o lançamento de uma release. Plataformas de ALM são end-to-end de soluções integradas para a gestão destes processos de uma empresa, bem como, a perspectiva técnica.
Agile é uma metodologia de desenvolvimento de software interativo que vem crescendo rapidamente entre os desenvolvedores e está moldando o mercado de ALM, com desenvolvedores corporativos cada vez mais preocupados em migrar das metodologias tradicionais de desenvolvimento de software para uma abordagem mais ágil. Ágil e ALM, dois segmentos de mercado distintos, estão agora começando a se consolidar. Como resultado, temos agora o que chamamos de plataformas ALM Agile.

 

Estamos treinados a entender plataformas ALM que dividam em grandes ciclos o desenvolvimento do software, como: planejamento, gestão, construção, teste e elaboração de relatórios.

Precisaremos adquirir conhecimento prévio sobre metodologias e frameworks ágeis, para então realizar a avaliação segura de uma ferramenta que trabalhe em harmonia com as metodologias ágeis aderentes a realidade do time e tamanho de empresa, quando pensamos em escala. Essa avaliação levará em conta alguns dos principais passos envolvidos no ciclo de desenvolvimento e entrega de software em produção:
alm

1)
Integrar valores ágeis, processos e princípios para a plataforma de ALM;
2) Gerenciar o ciclo de vida do aplicativo como um Fluxo de Valor Único;
3) Alinhar o negócio com a TI mantendo foco no “entregável”;
4) Suportar a diversidade de ambientes de desenvolvimento;
5) Ser horizontal no gerenciamento de times e flexível;
6) Proporcionar transparência e rastreabilidade;
7) Suporte End-to-End – visibilidade estratégica.
Sabemos que valorizar indivíduos e interação entre eles mais que processos e ferramentas é ser ágil, então quando avaliar uma ferramenta estiver em pauta, esta avaliação deve ser baseada em critérios claros de consolidação entre os conceitos de ALM e os conceitos ágeis. E essa ferramenta deve proporcionar imagens claras, precisas ou imediata de um estado de produto ou fluxo de valor em desenvolvimento.

___________________________________________________________________________________________________________________

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

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

Product Backlog Building

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

Como chegar ao Backlog?

Como construir algo que tenha valor?

Como encontrar a real necessidade do cliente?

Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

A dinâmica do PBB consiste em vivenciar na prática a construção do Product Backlog utilizando o Backlog Canvas como ferramenta. Essa dinâmica leva todos os envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais benefícios:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.

 

 

PBB é representado por um canvas chamado de Backlog Canvas que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

Veja abaixo o fluxo de construção do Backlog:

IDENTIFICAÇÃO: A primeira etapa é identificar o produto que será construído.

PROBLEMAS: Nesta etapa o ponto de partida é identificar e compreender o Estado Atual pontuando um conjunto de problemas, neste momento as partes interessadas buscam de forma colaborativa a mesma compreensão do estado atual, pontuando os problemas que desejam que sejam resolvidos. É importante conhecer o problema antes de criar a solução.

EXPECTATIVAS: Nesta etapa é importante identificar o Estado Desejado, alinhando suas expectativas aos problemas do estado atual, para que, de uma forma compartilhada, todos os envolvidos possam alinhar suas expectativas.


PARTES INTERESSADAS: Nesta etapa saiba quem são os usuários, papéis e responsáveis envolvidos no negócio. Alinhando seu contexto de negócio, suas atividades de negócio, seus problemas e dores, necessidades e objetivos.

 


ÁREAS DE NEGÓCIO:
A partir desse momento, identificado as PARTES INTERESSADAS, identifique as suas ÁREAS DE NEGÓCIOS e os principais objetivos de negócio das partes interessadas de cada área.

 

 

 

 

 

 

 

 

ATIVIDADES DE NEGÓCIO: Em seguida, identifique as ATIVIDADES DE NEGÓCIO de acordo com suas respectivas ÁREAS DE NEGÓCIO já identificadas, as atividades que cada PARTE INTERESSADA realiza dentro do negócio, mapeando na sequência de uso da esquerda para a direita. Descreva a ATIVIDADE DE NEGÓCIO com uma breve descrição da atividade, sempre pontuando o “Problema” e a “Expectativa” da parte interessada relacionada a essa atividade de negócio.

overview-product-backlog-building-atividade-de-negocio

FUNCIONALIDADES: Finalizando as etapas, para cada passo da ATIVIDADE DE NEGÓCIO, escreva as funcionalidades que satisfaça, podendo representá-las por User Stories ou modelo ARO (<AÇÃO><RESULTADO><OBJETO>). Construindo a lista de funcionalidades, podendo organizar(priorizar) verticalmente o que é mais importante.

 

Essas são as etapas de forma resumida do “PRODUCT BACKLOG BUILDING”. Etapas que compõem o Canvas:

[Identificação > Problemas > Expectativas > Partes Interessadas > Áreas de Negócio > Atividades de Negócio > Funcionalidades]

*As três últimas etapas são baseadas no conceito do FBS (Feature Breakdown Structure) do FDD.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreensão e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

 

Como resultado teremos um Product Backlog totalmente alinhado com o valor de negócio do cliente.

O Scrum não fala como podemos representar cada item no Backlog, podemos escrever de várias forma, inclusive de forma textual. A User Story é a forma mais usadas hoje pelos times ágeis para representar um item no Backlog. História de Usuário é uma breve descrição do que é necessário para o cliente ter no produto, que pode representar uma necessidade do usuário ou uma descrição de uma funcionalidade.

A estrutura de uma História de Usuário basicamente responde 3 perguntas: QUEM? O QUE? POR QUÊ?

 

O PBB nos ajuda na escrita das User Stories. Como podemos notar no PBB temos o “QUEM?” que é a Parte Interessada, o “O QUE?” que nesse caso são as funcionalidades já representadas em modelo ARO e por último, o “POR QUÊ?” que está no objetivo e benefício que a parte interessada destacou na atividade de negócio.  A figura abaixo exemplifica de uma forma bem simples como fica fácil escrever as User Story com ajuda do Product Backlog Building.

 

Como podemos perceber o grande poder do PBB é a facilitação e a colaboração que provoca com todos os envolvidos na construção de um Backlog, sempre levando todos a  um entendimento compartilhado do contexto de negócio e a descoberta de itens do Backlog totalmente alinhado com o valor de negócio do cliente.

Pronto! todas as funcionalidades descobertas representarão os itens do Backlog. Agora é só priorizar o Backlog usando quaisquer técnica de priorização e começar entrar…

Baixe aqui o seu Backlog Canvas e comece a construir seu Product Backlog:

Vídeo: Product Backlog Building com Fábio Aguiar | Test-Drive

___________________________________________________________________________________________________________________

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

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

Facebook  |  Twitter  |  Linkedin | Youtube

2 Comentários »

Categorias deste post

Agile, Scrum

A origem do Agile Testing

Origem

Se você já leu algo referente a Agile Testing vai lembrar logo do livro Agile Testing, que foi lançado em 2009, e associar que a origem do termo veio das duas autoras Janet Gregory e Lisa Crispin, certo? Errado!

Em 2002 Bret Pettichord já falava sobre Agile Testing [1] associando ele também com princípios de Context Driven Testing [2]. Na sequência, em 2003 Brian Marick criou o Quadrante de Teste Ágil para distinguir dentro de um processo ágil os testes baseados em negócio e em tecnologia, e os de suporte ao time dos de crítica ao produto.

A Elisabeth Hendrickson em 2008 também já falava sobre Agile Testing na sua palestra Agile Testing, Nine Principles and Six Concrete Practices for Testing on Agile Teams [3].

Lisa Crisprin, em 2002, trabalhou em um time que aplicavam as práticas de XP – Extreme Programming e já começava a criar algumas técnicas de como um testador poderia trabalhar em um time XP. Logo após o primeiro livro formal sobre o assunto foi lançado: Testing Extreme Programmimg [4]. Anos depois ela e a Janet Gregory lançaram o livro Agile Testing que é um compilado das experiências das autoras no processo de transição do Teste Tradicional para o Teste Ágil e como o testador pode ajudar a equipe.
Hoje este livro é a principal referência sobre Agile Testing.

Teste Tradicional x Agile Testing

A imagem abaixo já vai ilustrar uma similaridade e a diferença da adoção de cada abordagem:

origem-agile-testing

origem-agile-testing_2

No projeto por fazes podemos ver nitidamente que há uma fase de testes, mas esta depois do desenvolvimento ter sido concluído. A ideia do tamanho das caixas nos passa uma falsa impressão que realmente teremos tempo para testar, mas o que acontece em diversos projetos (até hoje) é a fase de testes ser diminuída e termos uma nova caixa antes da Entrega: o “Teste->Bug->Correção->Reteste” que toma muito mais tempo do que qualquer planejamento inicial de testes.

No Agile os testadores trabalham em cada Interação junto ao time e testam a funcionalidade mesmo quando ela está em desenvolvimento. A funcionalidade/requisito/regra (User Story + Critérios de Aceite) só estarão realmente entregues depois de testado (que são pontos do DoD – Definition o of Done).

___________________________________________________________________________________________________________________

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, Testes, Time de desenvolvimento