Arquivo de Abril de 2009

Rodrigo Yoshima

Agile Beer Drinking Fortaleza

Amigos(as) Cearenses,

Neste mês de abril estarei em Fortaleza, ministrando treinamentos em parceria com a Fortes. E como é costume, teremos um bate-papo com os agilistas de Fortaleza.

agilebeerdrinking fortaleza 1 2 - agilebeerdrinking fortaleza 1 2

Cascateiros também podem participar, afinal, são eles que dão o tom irônico desses encontros.

Veja os fatos e fotos dos encontros anteriores:

http://blog.aspercom.com.br/2008/09/22/bsb-restrospective/
http://blog.aspercom.com.br/2008/06/19/agile-beer-drinking-sao-paulo/

Rodrigo Yoshima

O que é um TIE e um BAD BEAT

Fazia um tempo que não postava nada sobre Poker, e como algumas pessoas pediram algumas peripécias das mesas segue as coisas interessantes de hoje:

Primeiro, veja este TIE (nunca aconteceu isso comigo):

TIE - tie

Note que foi bem no início do torneio (blinds em 10/20). Entre o flop e o turn algumas pessoas deram raises baixos (de 20 e 40). Quanto virou o river todo mundo checkou e eu era último. Dei um raise maior para 80 no blefe. Os outros oponentes hesitaram demais, mas acabaram pagando… tremi nas bases, mas quando o dealer apontou o TIE não acreditei… 3 pessoas com 10 e 4.

Bad_Beat - bad_beat

No mesmo torneio, já com blinds mais altos nosso amigo “SLOWPOKEDAD” já estava se despedindo da mesa com 175 fichas só. Saí com AQ e dei um raise médio para 200 fichas. Todo mundo fugiu, menos esse infeliz. Ele tinha 4 e 5, e pagou (já triste indo vestir o pijama para dormir). Quando virou A, 10 e 2 no flop já estava quase escrevendo “bye, bye, sucker” no chat. Aí vira um safado de um 3 no river. BAD BEAT total.

Sem problemas, levamos BAD BEATS nos negócios e no poker. Antes no Poker que nos negócios!!!

Se você é leitor do blog e joga poker deixe seu recado aí! Quem sabe não marcamos um jogo?

Rodrigo Yoshima

Estimativa não é ciência exata

Perguntinha na lista scrum-brasil@yahoogrupos.com.br:

Para se saber quantos pontos cabem na sprint atual, tomamos como base a sprint anterior certo? Dessa forma, vamos que seja colocada na sprint atual a mesma quantidade de pontos que foi atingida na sprint anterior.

Porém pelo que entendi, não temos a velocidade individual de cada um na sprint, não sabemos quantos pontos CADA DESENVOLVEDOR cumpre, pois cada um tem uma velocidade (baseada na capacidade, experiência, enfim, uma pessoa nunca é igual a outra). Só que como vamos saber qual será a velocidade da equipe na próxima sprint, ou seja, como vamos saber quantos pontos caberão na sprint, se a cada sprint eu tiver uma quantidade de pessoas diferentes trabalhando na sprint?

Porque eu pergunto isso? Imaginem que na sprint anterior tivemos 4 desenvolvedores trabalhando full time. Na próxima, um deles não poderá trabalhar 1 dia (irá fazer uma viagem a trabalho, por algum motivo) e outro faltou por uma questão de saúde, por exemplo. Dessa forma, minha velocidade já não é a mesma, pois não tive 4 pessoas full time.

Como tratar essas situações? Inclusive isso é muito comum na minha opinião.

Bem, estimativa não é uma ciência exata…

Uma das coisas que mais gosto nas práticas ágeis de planejamento e estimativa é exatamente o fato de não existir métricas individuais. Sim, nas equipes existem pessoas mais produtivas do que outras, porém, a variabilidade é tão grande entre pessoas e entre iterações que isso não vale a pena ser controlado, pois não somos robôs. Fred Brooks diz que há variação de até 80% na produtividade entre programadores. Algo que não ocorre com pedreiros como exemplo.

As práticas do Scrum e das estimativas ágeis (Planning Poker, literatura do Mike Cohn) são muito humanistas. Não são fatores deterministas que darão a produtividade da equipe. Se alguém na equipe teve que se ausentar, está com problemas na família, está doente ou está grávida, tudo isso é levado em conta na sua velocidade e ninguém é melhor que a própria equipe para fornecer parâmetros sob essa ótica tão empírica. Não é um gerente ditador que faz a equipe engolir a métrica. A EQUIPE É RESPONSÁVEL PELA ESTIMATIVA, sob todos os aspectos. É isso que faz a métrica funcionar.

No treinamento Scrum da Aspercom nós temos atividades práticas com estimativas ágeis, e é muito interessante como a aceitação de tal métrica é geral. Vejo o mercado cansado de métricas pesadas e pouco assertivas.

Respondendo a pergunta do nosso amigo do fórum, nas minhas equipes, no “planning” rolaria uma conversa mais ou menos assim:

“Se na Sprint 3 fizemos 39 pontos com todo mundo e nessa Sprint 4 o Claudervanderson vai viajar 1 dia, vamos estimar nossa velocidade em 37 pontos, fazendo as stories X, Y, Z, W, H, U, V, O…. concordam?”

A resposta para a velocidade sempre é dada pela Equipe… pense na velocidade como uma tendência e não como uma certeza. Pense na velocidade como uma aplicação financeira com riscos: “rentabilidade passada não garante rentabilidade futura”.

BusinessPeoplePlanning - BusinessPeoplePlanning

No cenário acima, se na Sprint 4 o Valdercleudiney ficar doente uns dois dias e vocês matarem 32 pontos ao invés de 37, não precisamos cortar os pulsos. Isso era esperado, certo? Então, no Planning da Sprint 5 pode rolar uma conversa assim:

“Bem, nessa Sprint 5 ninguém estará ausente e o Valdercleudiney melhorou. Vamos estimar nossa velocidade em 39 novamente? Concordam em planejar as Stories U, V, O, M, N, L, Q?”

A decisão é em grupo. Repetindo: É empírico.

Ou então você pode usar a tabela de fatores de correção da AMM:

Dor de Dente -4%
Enxaqueca -22%
Diarréia -46%
TPM -84%
Corinthians perdeu no Sprint anterior -26%
Gravidez -36%
Briga na família -26%
Problemas com alcolismo -21%
Diretor está de férias -49%
O cara que cuida dos processos está de férias +75%

Francamente!!!!!