Olhando o Manifesto Ágil pela visão do Product Owner

O que sustenta a ponta de um iceberg dentro de um cenário ágil, seja em uma organização, time ou até mesmo um papel, é o Agile Mindset. Essa nova mentalidade que o ágil nos leva a entender, está estabelecida por meio de 4 valores, fundamentados em 12 princípios, ou seja, Manifesto Ágil, e manifestada através de diversas práticas, técnicas e métodos diferentes.

agile-mindset

Há uma grande distância entre ser ágil e estar fazendo ágil. Como Product Owner temos um radar de práticas, técnicas e métodos para ajudar de acordo com o contexto que estamos trabalhando, com isso, precisamos internalizar esse Mindset que está fundamentado e estabelecido no Manifesto Ágil e em momento algum podemos feri-lo.

Os valores do Manifesto Ágil:

INDIVÍDUOS E INTERAÇÃO mais que Ferramentas e Processos

SOFTWARE FUNCIONANDO mais que Documentação Abrangente

COLABORAÇÃO COM CLIENTE mais que Negociação de Contratos

RESPONDER A MUDANÇAS mais que Seguir um Plano

O Manifesto é composto de valores e princípios, assim como cada um de nós, para preservar um valor na sua vida é preciso definir alguns princípios, por exemplo: você pode torcer para seu time do coração e, para preservar esse valor na sua vida, é necessário estabelecer alguns princípios, como: ser um sócio torcedor, assistir todos os jogos, assistir pelo menos um treino apronto no mês, comprar camisa oficial. Certamente seguindo esses princípios esse valor de torcer para um time favorito estará vivo em seu dia a dia.

Abaixo temos 12 princípios que preservam os 4 valores do Manifesto Ágil.

Vamos destacar os princípios de bolso de um Product Owner:

  1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor – O Product Owner é responsável em criar, priorizar, fatiar e manter o product backlog, ou seja, é o dono do backlog (única fonte de requisitos do produto). A forma que o Scrum manifesta esse primeiro princípio é através de ciclos curtos que se chamam SPRINTS, com isso, o Product Owner determina o que é prioridade para o cliente no primeiro momento, buscando sempre a satisfação do cliente, e antecipa o poder de entregas (lembrando que não é somente entregar, também gerar percepção de valor em cada entrega).

visao-do-po_3

  1. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas – O Product Owner precisa entender que o cliente não está comprando o produto, mas sim investindo no produto, certo que em um curto espaço de tempo terá esse retorno. Com o foco em fazer o cliente tirar vantagens competitivas de mercado, o PO precisa estar aberto a aceitar mudanças. Quem nos disse que um plano não pode mudar? a única certeza que temos em desenvolvimento de produto é que ele vai mudar, mas com métodos ágeis isso vai acontecer o mais cedo possível, com isso, existe a necessidade de adaptação para responder à mudança sem traumas, lembrando que mudanças sempre são bem vindas. Os requisitos podem mudar a qualquer momento, o que é normal e aceitável, é necessário gerenciá-los conforme suas prioridades. Se os seus requisitos não mudam, tem alguma coisa de errado.
  1. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos – O Product Owner precisa decidir quais funcionalidades são prioridade no primeiro momento, fatiar pequenos incrementos com valor para o cliente. A entrega constante gera a percepção de rápido, pois o objetivo é entregar o mínimo o mais cedo possível para o cliente e gerar o feedback antecipado, gerando assertividade, ou seja, maior frequência de planejamento e maior qualidade das entregas. Com o conceito MVP, tudo isso fica mais claro, pois o objetivo é escolher o mínimo do produto necessário, colocar na mão do cliente e o cliente determina se é viável para evidenciar o aprendizado emergente do produto. O Product Owner pode trabalhar a concepção do produto para entender o todo e priorizar o que precisa entregar. Nesse momento os detalhes não são importantes (detalhes são refinados durante o tempo) e o esforço inicial não deve chegar a duas semanas, apenas dias.

visao-do-po_2

  1. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente durante todo o curso do projeto – O Product Owner está sempre engajado e disponível para o time de desenvolvimento, respondendo a quaisquer dúvidas relacionadas ao negócio. Durante sessões facilitadas, é importante o envolvimento dos desenvolvedores com as partes interessadas, facilitando o entendimento do negócio.
  1. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho – O Product Owner está muito próximo do time de desenvolvimento e é importante que todos saibam que ele faz parte do time (Scrum). O PO deve ter o conhecimento necessário sobre o negócio assim como ter toda confiança para que possa fazer seu trabalho, precisa priorizar o que deve ser feito, tem que ter poder de decisão e, principalmente, saber dizer “NÃO” para necessidade do cliente quando não está alinham com a visão do produto.
  1. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara – O Product Owner é responsável em manter o Product Backlog priorizado e com valor, o time de desenvolvimento em entregar o que está se comprometendo em cada Sprint. Com isso, há uma aproximação forte através de conversas ativas e sessões facilitadas, colaborando constantemente para entender os itens do backlog que podem ser apresentados por User Stories. Valoriza os momentos de conversas cara a cara para dar o entendo de negócio do que está representado através das User Stories, lembrando que ela é apenas um “lembrete” da necessidade do cliente, ou seja, fornece um flash da comunicação, representa os requisitos (necessidades) mais do que documentá-los. Os melhores documentos nos ajudam a recordar nossas conversas, eles não a substituem. Para provocar a colaboração de todas as partes interessadas, pode-se adotar ferramenta simples, como cartões, post-it, papéis, flip-chart, paredes ou quadro em branco, certamente incentivará a comunicação ativa de todos interessados no produto.
  1. Software funcional é a medida primária de progresso – Todo incremento do produto representa uma entrega funcional de valor do produto para o cliente. O Product Owner é o responsável por demonstrar esse progresso de valor para todos interessados.
  1. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes – O Product Owner entrega o que precisa ser desenvolvido para o time, ajudá-lo no entendimento do negócio para que o time possa fatiar e estimar. O trabalho do Product Owner de refinamento dos requisitos é um esforço contínuo durante todo o projeto.
  1. Contínua atenção à excelência técnica e bom design, aumenta a agilidade – O Product Owner contribui constantemente ajudando o time de desenvolvimento a entender a visão e roteiro do produto, seus objetivos de negócio e principais features, deixando claro todo contexto de negócio, com isso o time facilmente consegue identificar riscos técnicas, arquitetura, buscando sempre a excelência técnica.

  1. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito
    –  A principal ferramenta do Product Owner é dizer “NÃO” para um item entrar no backlog. Todo o esforço de refinamento do Product Owner está nos itens de maior prioridade para o cliente, ou seja, saber o que é importante para o produto e saber o momento certo de parar, neste cenário “menos é mais”.
  1. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis – O Product Owner é o responsável pelo backlog e definir sua prioridade, mas em um projeto todos têm toda condição, habilidades e conhecimento necessário para auto organizar e se comprometer com o trabalho que precisa ser feito.
  1. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo –  O Product Owner reconhece que o seu papel precisa se adaptar e melhorar a medida que o produto evolui e está bem alinhado com todo o processo. Retrospectivas frequentes conduzem a melhoria contínua e a forma como o time trabalha para maximizar o valor para seus clientes.

visao-do-po

___________________________________________________________________________________________________________________

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Product Owner, Scrum

Planejamento para Automação de Teste em Ágil

Introdução

Sabemos que a automação de teste em um contexto ágil é obrigatória, independente se esta ação será feita por uma pessoa focada (testador) ou pelos membros do time. O importante é saber como podemos planejar a automação em cada pequena fase que temos.

A seguir veremos como é a big Picture dos Níveis de Detalhe para o Planejamento e, na sequência, como podemos nos planejar para o Nível de Release.

 

Níveis de Detalhe (precisão) para o Planejamento

Há quatro níveis que podemos facilmente identificar quando focamos no planejamento da automação de teste em projetos ágeis:

  • Nível de Release: Visão do todo e planejamento em alto nível sobre automação
  • Nível de Feature: Visão de uma funcionalidade e planejamento específico
  • Nível de Story: Visão macro do que será feito frente a o planejamento
  • Nível de Tarefas: Visão micro e aplicação prática de todo o planejamento

01_niveis_detalhe

Planejamento em Nível de Release

No planejamento de um release o time já tem uma ideia da visão do produto. Como é uma visão nós podemos fazer um planejamento em alto nível. Neste momento devemos também pensar no todo, principalmente no que podemos aplicar de novas práticas, ferramentas, necessidades de ambiente e aplicação de algumas técnicas de teste.

Ao final do release é necessário ter todos estes pontos já desenvolvidos e desempenhados, logo o planejamento em termos de automação no release foca mais em aspectos que possam mudar ou impactar o planejamento como vem sendo feito.

Quando a release inclui um produto com novas tecnologias é necessário separar um tempo para experimentos, aplicações e aprender sobre possíveis problemas de design. Também é necessário levantar todos os riscos necessários

02_nivel_release

Em resumo, no Nível de Release:

  • O Time já tem uma boa visão do todo
  • É o melhor momento de pensar em:
    • Ferramentas
    • Ambiente
    • Práticas/Técnicas de Teste (Performance, Segurança, etc…)
  • Quando há novas tecnologias é necessário:
    • Fazer experimentos
    • Levantar possíveis problemas de design
    • Riscos
Nenhum comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

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