Categoria: Series

Confira Séries de post técnicos

Série Agile: Conceito de Done

Olá Pessoal,

No post desta semana vamos ver o que colocar no conceito de Done do seu projeto Scrum. Claro que não há uma regra universal para o que deve ser colocado, pois isso vai variar de projeto para projeto. Vou abordar uns que considero mais tradicionais.

                                               O que colocar no conceito Done no projeto Scrum?

É algo que parece ser fácil de definir, mas não é como parece. Alguns projetos levam em consideração apenas o foi acordado entre o Product Owner e o ScrumMaster para adotar o conceito de Done, outros buscam um concenso com o team; qual a melhor? Não há melhor ou pior e sim aquele que se adapta ao projeto (eu particularmente preferia discutir com o meu team o que vamos considerar como Done). Claro que  a contribuição do Product Owner é importante também, porém evitaria de deixar a discussão apenas entre PO & SM. Mas seria algo como:

  • Todas as tarefas devem estar cumpridas: parece ser óbvio, mas nem é. Algo bem comum é: terminei todo o desenvolvimento, mas o build não está ok, então você precisa arrumar o build para poder concluir seu ítem. Não importa quem quebrou, mas precisa estar fixed, é esperado que quem provocou  a situação que arrume, caso esta pessoa esteja disponível.
  • Código refatorado (refactoring): sabemos que a primeira vez que vimos o código, apenas fizemos ele para que as coisas pudessem funcionar, então ter um código bem refatorado é required (se você usa TDD terá menos trabalho);
  • Pair Review: o código deve ter sido revisado por dois outros membros da equipe; (usar uma ferramenta com o review board)
  • Build passando;
  • Unit Tests passando e cobertura > 80% ;
  • Design atualizado;
  • Qualificado pelo Tester: Ou seja, teste funcional feito de preferência por um tester, pois eles são bons em encontrar bugs no menor tempo possível.

 Uma experiência que quero compartilhar com vocês é sobre o ponto de refactoring acima. É muito importante colocar ele no conceito de Done. O motivo? Quantos desenvolvedores você conhece que faz refactoring (de verdade e não apenas o rename)? Acredito você não consegue fechar uma “mão” com o  resultado, mas não só por isso. O cliente não está disposto a pagar pelo refactoring, não se esqueça disso, pois para o cliente, algo dado como Done já possui certos padrões de qualidade e refactoring na visão do cliente não agrega valor ao produto, caso for feito à parte, consumindo mais horas. E eu tenho que concordar com ele, realmente já deveríamos entregar isso quando concluímos o item do backlog, afinal de contas nós que estimamos o tempo que levaria para entregar o item e nesse momento eu deveria colocar quanto tempo levaria no refactoring. Para o cliente, não importa o como você vai fazer, desde que tenha qualidade e atenda ao que ele pediu. Então, o melhor lugar para colocar o refactoring seria no conceito de Done, assim todo desenvolvedor terá que garantir que isso foi feito, enviar o peer review, etc. Outro item que gostaria de citar da lista é o “qualificado pelo tester”, parece estranho, pois em projetos ágeis cada membro é responsável por testar e garantir que está funcionando. Bem, não podemos seguir tudo ao pé da letra ou interpretar com uma única linha de raciocínio. Em um projeto meu, seria bom e interessante eu ter um tester para ir qualificando os itens que fossem ficando prontos e no final do Sprint todos os itens deveriam passar por ele. Mas por que isso? Para garantir que de fato está funcionado. Apesar do desenvolvedor já ter testado, eu considero que não é uma tarefa fácil nós pegarmos os nossos próprios bugs, sempre vamos testar pelo “caminho da felicidade”. Os testes de fato são bons, vão testar cobrindo vários cenários com base no escopo, testar em ambiente e formas diferentes e ver o resultado esperado. Então, ter isso no conceito de Done ajuda a encontrar possíveis bugs mais cedo e ajuda aumentar a qualidade do produto.

Vou ficando por aqui. No próximo post falarei mais sobre o papel do Tester. Agora eu fiquei curioso. E você, o que coloca no seu “conceito de done” ?

Compartilhe…

Abracos, 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!!

Série Agile: Agilista

Olá pessoal,

Vou trazer pontos os quais acredito que todo Agilista tenha passado quando este começou a falar de Agile para alguém ou um team “No Agile here.”

Lets go..

O que todo Agilista sofre:

  • Vira motivo de risada: todos dão risada dele e dizem: “ele acha que a metodologia Agile é a bala de prata e vai mudar o mundo”. Na verdade o Agilista que deveria rir, porque ele conseguiu “mudar” e aqueles profissionais que são resistentes a qualquer tipo mudança estão com os dias contados :);
  • Ser ignorado: todo agilista é ignorado no início;
  • No bugs: associa que um agilista acredita que ao desenvolver um software usando metodologias não se cria bugs. Mas ninguém diz isso, porém acusação sobre o coitado do agislita é servera;

O que os demais acreditam:

  • Que a forma que tem usado até hoje é a correta, senão o projeto não existia, porém esquece que se existe até hoje talvez seja por consequência;
  • Que software sem bug tem algo de errado e que alguma das funcionalidades não foram implementadas, pois não é possível desenvolver software sem bug;
  • Aumentar a cobertura de unit tests depois do código já escrito é sinonimo de qualidade;

Bom vou ficando por aqui. E você já passou por isso ou algo pior? Comente… 

abracos, see ya!!