Categoria: Agile/Scrum/TDD

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

Série Agile:Qualidade Externa e Interna estimativas

Olá pessoal,

No post de hoje vou falar sobre qualidade externa e interna de quando vamos desenvolver um produto. Tá, não se preocupe porque vou explicar com mais detalhe durante o post, porém  responda a pergunta a seguir, se a resposta for sim, então já sabe o assunto que vamos tratar.

Algum cliente seu já pediu para você reduzir um pouco a sua estimativa para entregar alguma tarefa?

Se sua resposta foi sim, é disso que vamos falar:

como convencer o cliente que a qualidade não é negociável?

Lets go…

 

Starting

Como vocês, que tem acompanhado o blog e meu twitter, puderam ver, tenho me dedicado ao mundo Agile, mas o que vou falar aqui não está só ligado ao Agile, mas foi onde eu consegui perceber isso de forma mais face-to-face com o cliente e de certo modo foi onde houve menos questionamentos por parte dele e até uma aceitação de mudanças sem muita discussão. Eu sempre sofri com esse mal (desde da época de freelance), do cliente pedir para mudar uma estimativa, porém ele não queria mudar o escopo dele e sabemos que isso não é nada bom. Mas, como contornar a situação sem gastar muito tempo? Para isso é preciso ter duas coisas bem claras em mente:

  • Qualidade externa: aquilo que o cliente vê, tem acesso, que é o front-end, lentidão, etc.
  • Qualidade interna: aquilo que o cliente não tem acesso, tais como: refactoring, covertura de testes, code clear etc.

Quando o cliente pede para reduzirmos a estimativa ele está afetando a qualidade interna, algo como: “Sei que você tem a melhor equipe, com os melhores profissionais, será que não dá para fazer em 1 ou 2 dias a menos (isso aqui dá -16 hrs de trabalho, o que é muita coisa)?”

Normalmente não dá para mudar isso, pois nós sabemos do impacto. E como  resolver isso?

Resposta ao cliente

Podemos perguntar ao cliente se o escopo não pode ser alterado, que aquela parte onde temos as mensagens iterativas com o usuário não poderia ficar para o futuro e que por agora trataríamos com mensagens mais simples possível, por exemplo. Ou mudar o nível de importância, assim isso impactará em outras e saberemos o que deve ser entregue primeiro e isso forçará o product owner mover o backlog. Mas abrir mão da qualidade interna é algo que não deve ser feito, pois já sabemos dos problemas que vamos encontrar e o cliente não vai levar em conta essa redução de estimativa quando os problemas surgirem, principalmente se estes afetarem o “bolso dele”. Pense: “uma vez que se penetra que uma base de código se deteriore, é muito dificil recuperar a qualidade mais tarde”.

Um sistema com alta qualidade interna pode ainda ter baixa qualidade externa, porém um com baixa qualidade interna raramente terá uma qualidade externa alta, ou seja, não dá para construir algo bom se a base está pobre, então daí que dizemos que a qualidade interna simplesmente não é negociável.

Vou ficando por aqui. Espero que tenham gostado do post.

Abracos, see ya!