Tag: agile

Série Agile:Como escrever boas user stories?

Olá Pessoal,

Mais um post, da série Agile e veremos como escrever boas user stories. Este é um ponto importante, pois uma boa user story deve ser entendida tanto pelo team técnico quanto pelo cliente/PO.

Lets…

Sabemos que escrever as user stories, é “trabalho” do PO, mas em teoria, porque na prática quem vai escrever ou é o ScrumMaster ou o time. Nem sempre dá para seguir o que temos na literatura de acordo com a realidade do mercado. Mas o objetivo deste post não é esse e sim tentar responder: “as use stories do seu projeto são boas?” Ou seja, para seu cliente, ela é valiosa? Ele olha para ela e sabe de fato o que significa que será feito?

Lendo o livro JR The samurai Agile (o qual em breve vou publicar um review), em um dos seus capítulos ele aborda sobre o assunto e vi que já cometi alguns erros quando precisei escrever algumas user stories alguns meses atrás em um projeto pessoal. Um dos problemas foi não ter percebido o quanto estava técnico alguns pontos na user story. E o JR fez uma pergunta interessante: “Se seu cliente estivesse com fome e apenas as duas opções abaixo ele teria para escolher, o que é mais claro para ele? “

1. Estória: Ernie’s Tech Diner

  • C++     3 days
  • Connection pooling    2 days
  • Model-View_presenter pattern          5 days

2.Estória: Sam’s Business Pancake House

  • Create user account 3 days
  • Notify subscribers of new listings 2 days
  • Cancel subscription 1 day

Com certeza a estória dois faz mais sentido para o negócio do cliente. Os termos são simples e fáceis de serem entendidos. E o mais comum: quando somos muito técnico é escrever como na primeira estória e SM deve ficar atento com isso caso todo o time esteja participando da escrita das US. E em outro exemplo o JR trouxe que podemos ser técnicos e o cliente entender. A estória abaixo não perde seu valor: 

Add database connection pooling: é dificil para o cliente entender

Mas…

Reduce page load time from 10 secs to 2 secs.

Parece que faz mais sentido para o cliente e você já sabe o que acontece nos bastidores para atingir o objetivo da user story (US).

Enfim, qualquer US deve ser do tipo INVEST, ou seja, independente, negociável, valiosa, estimável, small (pequena) e testável.

  • Independente: sua história não pode depender de outras histórias, caso isso aconteça é preciso quebrá-la.
  • Negociável: é que ela pode ser alterada e adaptada e não fechada.
  • Testável: que seja possível criar testes que valide aquela história. Algo como:

Login with expired:

Testable:

            – redireciona logins expirados

            – mostra mensagens de erros apropriadas

  • Small & Estimatable: não tem que ser grande e sim pequena para que possa ser estimável, quanto maior, mais difícil é estimar.

Vou ficando por aqui, espero que tenham gostado do post.

See ya!

Série Agile: O tester

Olá Pessoal,

No post de hoje vou falar o que os Testers fazem enquanto o time desenvolve. No post anterior falei sobre o conceito de Done, e um dos tópicos para considerar um item concluído tinha que ser qualificado por um tester. Mas, o que o tester faz enquanto não tem nada pronto para ser qualificado? É isso que vamos ver no post de hoje.

Lets go…

E o que o tester faz enquanto o team desenvolve? Vai para Praia?

Antes de mais nada queria reforçar o que eu acredito: todo projeto agile deveria ter no minimo 1 Tester. Falo isso porque vejo alguns comentários na comunidade, às vezes, que com Agile não precisa mais dos Testers. Não sei de onde tiraram isso. Os Testers são membros do time e eles são tão importantes quanto os demais membros (infelizmente há ainda pessoas que olham assim dev X testers), são profissionais que tem uma habilidade de qualificar se aquilo que você fez de fato atende ao requisito do cliente, do contrário ele vai encontrar falhas e vai te direcionar onde resolver. Quando um  Tester pega um bug, não quer dizer que você, Desenvolvedor, é ruim ou no pior, um animal de quatro patas. Não é isso. Eles apenas dizem: “olha, faltou isso”. Porém alguns desenvolvedores não olham assim e se sentem ofendidos. Há vários fatores que contribuem para um bug no sistema, não é apenas questão técnica. Mas isso não entra nesse post, pois é uma longa história :). Mas de fato, o que os Testers fazem enquanto os desenvolvedores ainda estão trabalhando nos itens do Sprint? Vão à praia e voltam daqui uns dias?

Se isso fosse verdade, eu queria ser Tester \o/, mas a resposta é: Não. Eles não vão à praia. Aqui temos uma pilha de trabalho para eles:

  • Montar os use cases de cada item (ou itens) do Sprint backlog etc;
  • Preparar o ambiente de teste (homologação);
  • Interagir com o team, tirando dúvidas dos itens;
  • Sincronizar informações com o product owner.

Tudo isso consome tempo e é bom ter tudo pronto antes do primeiro item ficar pronto. Os Testers participam das reuniões diárias (afinal de contas ele é membro do time), do planning, então nada melhor que já ir montando os testes seguindo a ordem de prioridade dos itens que foi definido pelo PO.

É preciso adicionar um item no quadro de task para o Tester e ir acompanhando as atividades dele durante as daily meeting?

Não ou Sim. Eu acredito que não, na primeira Sprint eu não faria isso e talvez na próxima sim, como tudo é um aprendizado, vamos ver o que podemos aprender no Sprint 1 com esta abordagem. O motivo de não querer adotar um item exclusivo para o tester é por realmente não achar necessário, exceto se o PO colocasse isso no product backlog, onde acredito que ele não fará isso, porque o PO não está muito interessado no “como” será feito ou qualificado, desde que atenda aos critérios de qualidade e requisitos de negócios estabelecido por ele.  Uma forma seria adicionar uma task a cada item do tipo “preparação para teste” e em uma das daily meeting o desenvolvedor iria dizer: “olha, hoje termino o desenvolvimento e amanhã já tenho o item pronto para ser qualificado”. Então o tester já pegaria a task, colocaria  na coluna de “in progress” e dizendo “tá,eu vou começar a preparar o ambiente hoje e amanhã as X horas posso iniciar a validação”.  Essa foi uma abordagem que achei válida e bem prática até o momento, pois consegui manter a iteratividade entre tester e desenvolvedores em um projeto que participei no mês passado.

E você, como lida com esse cenário? Compartilhe sua experiência :).

Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!

Série Agile: Scrum lidando com Team remotos

Olá Pessoal,

Este é o nosso último post da série Scrum. Espero que essa sequência de post que vimos aqui por semanas tenha ajudado você a entender melhor como as coisas funcionam com Scrum, etc. Quero deixar claro que nada que escrevi aqui é fechado ou um fluxo que deve ser seguido e atingir o sucesso para gerenciamento de projeto de software. Pelo contrário, eu diria que Scrum é sinonimo de adaptação, ou seja, a forma que eu experimentei em um projeto não quer dizer que vai funcionar para outro, isso é muito dinâmico, pois há fatores que fazem isso mudar sempre e um deles são as pessoas. O que não podemos esquecer é o coração do que o framework Scrum diz, isso ai todos devemos falar igual, as definições de papéis, responsabilidade, quem faz as estimativas etc, isso é do framework. E para esse último post, separei um tema que considerei interessante: como lidar com equipe remotas? Essa foi uma das primeiras perguntas que eu fiz quando comecei a conhecer melhor o Scrum.

Lets go…

Como lidar com equipe ou membro longe geograficamente?

É de fato uma tarefa difícil (mas não é impossível), tendo como base o que se prega no Scrum, que é ter uma alta largura de banda de comunicação, algo como:

  • Habilidade de programar juntos, em pares;
  • Habilidade de participar cara-a-cara na reunião diária;
  • Habilidade de encontrar-se fisicamente para ter reuniões espontâneas com a equipe inteira.

Tudo isso de fato é importante e faz toda a diferença, não podemos negar. Mas hoje muitos projetos tem times remotos por vários motivos: custo, falta de mão de obra qualificada, tipo do negócio, etc. Então não podemos rodar Scrum em projetos assim? Quem disse que não? Podemos sim. Hoje há várias ferramentas de auxilio, como Skype, Virtual Room HP, Halo, comunicadores de mensagens instantânea etc. Mas estas ferramentas ainda não são capazes de substituir o estado de estar fisicamente (a Halo é a mais próxima de um estado físico). E qual é a melhor?

Não tem receita de bolo, não. O fato é que vamos precisar testar ==> Adaptar ==> Testar ==>Adaptar... e ir fazendo isso day-by-day até atingirmos um nível confortável para a equipe e o projeto. Particularmente já usei a virtual Room da HP, a qual achei eficiente, permitindo compartilhamento de desktop, dá permissão a outros usuários para controlar o desktop durante a sessão, chats privados, gravação da reunião, etc. A Halo é outra tecnologia HP que permite uma projeção da imagem das pessoas nos ambientes e essa seria o ideal, porém exige um investimento maior. Eu também já vi algumas equipes adotando telas grandes em cada local, mostrando o que está acontecendo nos outros locais. Seria uma espécie de telas virtuais entre as equipes que estão longe geograficamente. Com a tela podemos ver quem está nas mesas e quem está conversando com quem. E dá para fazer uma video conferência entre os teams. Enfim, há varias possibilidades de aproximar ao máximo um ambiente físico, mas nada substitui o contato presencial com os membros. E você, o que tem feito para minimizar esse impacto com time remotos?

Vou ficando por aqui, e não deixe de compartilhar sua experiência.

Abracos, see ya!!!

Séri Agile: Como calcular pontos em uma Sprint?

 

Olá Pessoal,

O post de hoje da série Agile trata-se de um assunto que não é fácil para o scrum master, equipe e product owner: definir a quantidade máxima de um ponto que um Sprint pode suportar, ou seja, quantas estórias do backlog podem fazer parte do sprint backlog? É isso que veremos neste post. Claro que o que abordaremos aqui não é a única forma e mais adequada para ser implementada em qualquer projeto, porém é bem utilizada por scrum master mais experientes, como o Crisp :).  Eu particularmente gosto de ter os cases do Crisp como referência.

Lets go…

Definir prazo, quantidade de trabalho dentro de um número X de dias, não é uma tarefa fácil. Claro que quanto mais experiência vamos adquirindo, as chances de erros tendem a diminuir, mas não quer dizer que não podemos errar em estimativas e sabemos que esse tipo de erro gera grandes impactos, até porque o cliente está diretamente envolvido, já que prometemos entregar em uma Sprint 5 novas features, mas conseguimos apenas concluir 3, por exemplo e isso é frustrante. Então como podemos evitar isso? Vamos ver como Kniberg nos ajuda entregar tudo aquilo que prometemos e manter uma boa saúde da equipe.

Lá vem a pergunta: como uma equipe define as estórias que vão para um Sprint?

1         Pode ser por sentimento ou instinto: essa aqui é bem comum e pode ser a primeira opção a ser adotada. É errado? Não. Tudo depende da equipe e auto-confiança da mesma nas estórias definidas no backlog do product owner.

2         Estimativas de cálculo de velocidade:  essa aqui é um pouco mais matemática e não envolve sentimento ou instinto. E o objetivo final da “velocidade” ajuda a saber a quantidade de trabalho que pode ser adicionado ao sprint.  Porém temos duas formas de  fazer o cálculo:

Forma 1 – Tempo de Ontem: é assim que é chamada, onde olhamos para o Sprint anterior e somamos os pontos do que foi entregue e podemos ter uma margem para próxima Spring.

Forma 2 – Fator foco: é onde uma estimativa de como a equipe é focada para achar o fator foco, então o calculo para encontrar esse “fator foco” seria:

fator foco(%) = soma das estimativas

homem-dia

Agora, calculando os pontos por estória para o Sprint, é só pegar o percentual do fator foco anterior e multiplicar pela quantidade homem-dia do Sprint seguinte, assim chegamos ao total de pontos que o Sprint a seguir deve atingir, para garantir a entrega. Se o resultado for 20 pontos por exemplo, então esse será o valor máximo que o Sprint backlog pode ter. Cálculo:

Pontos = fator foco(%) * homem-dia

O que é homem-dia ?

Se nunca viu este termo, homem-dia é quantas pessoas teremos disponíveis para aquela Sprint e o cálculo não é por “cabeça” e sim por disponibilidade. O fato de ter 3 pessoas não quer dizer que temos elas 100%, podemos ter o seguinte cenário:

Camilo: 20 dias

João: 20 dias

Maria: 10 dias

50 homens-dia disponiveis

Vamos considerar que seja um Sprint de 20 dias, então no cenário acima, apenas 2 dos 3 tem disponibilidade 100% para toda a Sprint, e isso tem um grande impacto na quantidade de estórias para o backlog.

Simulação

Supondo que tivemos 40% de fator foco no Sprint anterior, quantos pontos máximos devemos ter na próxima Sprint, com base no homem-dia anterior ?

Pontos = 40 %* 50 = 20

Então sabemos que  não podemos ultrapassar o valor de 20, do contrário já estaremos comprometendo  a entrega de estórias do Sprint.  Vamos supor as seguintes estórias  no backlog:

  • fazer página login (7)
  • autenticação DB (6)
  • Test de Perfomance (5)
  • Popular DB (3)

As estórias  acima atingem 21 pontos. O que fazer? Colocar apenas por causa de 1 ponto? É possível pensar assim, mas a melhor escolha poderia ser escolher o menor número, ou seja, até 18 pontos  (no caso acima) e evitar ultrapassar  o limite de pontos para o Sprint. Em alguns casos pode colocar o item que sobrou, como se tiver um tempo de folga e for possível ser implementado, mas o product owner não pode contar com aquela estória ao final da Sprint.

E quando não temos nenhuma Sprint para fazer os cálculos?

Isso acontece quando vamos para primeira Sprint. Então que fator foco adotar? Ai é questão de análise do ScrumMaster conhecer sua equipe e ter uma ideia do escopo. Você vai encontrar livros Scrum que falam 70%, 50%, 80% , enfim, fica a seu critério, eu adotaria 70%, por não ser algo muito alto, nem tão baixo.

Vou ficando por aqui com mais um post Agile e espero que tenham gostado. Não deixe de compartilhar sua experiência. 🙂

Abracos, see ya!

Série Agile: Diferença entre User stories e Documentos de Especificações

 

olá Pessoal,

Neste post vou trazer o que ganhamos ao escrever User Stories ao invés de ter que gastar mais tempo escrevendo documentações de requisitos. Não estou dizendo que não devemos documentar, pelo contrário. Porém ,a idéia é saber o que e como documentar.

Lets go..

User Stories promove os seguintes pontos:

– Aprendizado;

– Traz precisão;

– Encoraja a comunicação face-to-face com o cliente;

– Possibilita feedback em tempo real;

– Evita a falsa sensação de que temos tudo documentado correto e só falta implementar;

– Permite uma colaboração e inovação com o time.

Documentos de requisitos

– São grandes e cansativos;

– Encoraja o trabalho por imaginação com falsos ‘achismos’;

– É difícil de planejar;

– Feedback em tempo real é inexistente;

– Desencoraja abertura de colaboração e invocação com o time

Isso quer dizer que não vou documentar? Não. Em projeto Agile há documentação sim, porém ela não é o meio primário de obter as coisas e nossa última fonte de obter o entendimento, conversar com o cliente, é mais importante.A diferença é que aqui evitamos o desperdício do tempo documentando, pois ao terminar toda documentação, o que foi escrito no inicio talvez não tenha mais valor para o cliente.

Vou ficando por aqui, espero que tenham gostado do post.

abraços, see ya!!