Posts de November, 2011

[Igor Macaubas] Backlog ready: gerenciando o risco do seu planejamento

Tuesday, November 29th, 2011

Recebi o Juan Bernabó na Globo.com, para dar uma volta no nosso ambiente de desenvolvimento. O Juan se surpreendeu com um indicador que temos usado há algum tempo para gerir os riscos do planejamento (ou da falta dele), o Backlog Ready. Esse indicador foi criado dentro da Globo.com, pelo Danilo Bardusco, e não estava documentado em lugar nenhum fora da Globo.com – então espero que esse post sirva para esse propósito.

Motivação

Um problema comum em organizações ágeis é o fenômeno de esvaziamento do product backlog. Isso pode acontecer porque o PO entrou de férias, licença médica, ou porque o mesmo estava muito ocupado fazendo outras coisas (esse é um sintoma de um outro problema, assunto para outro post!). Quando isso acontece, o time normalmente fica ‘faminto’ por histórias. Vão para o planning sem histórias definidas, e o processo de planning fica realmente sofrido.

Além disso, é saudável que o time conheça o seu terreno alguns sprints à frente – mesmo que o backlog mude. Evita o FUD (fear, uncertainty & doubt – medo, incertezas e dúvidas) que normalente se instala quando o time não conhece o seu futuro de curto prazo, minando a motivação e o ambiente de trabalho.

O conceito de ready

Há algum tempo atrás, o Serge Beaumont criou o conceito de READY, em conjunto com o Jeff Sutherland. É basicamente um checklist que serve para identificar itens de backlog que estão prontos para entrarem no sprint. O Serge criou esse conceito para garantir que as histórias que vão para o sprint planning tiveram três perguntas respondidas: Why? (porque), What? (o que) e How? (como), e além disso são pequenas o suficiente e foram estimadas. Nas palavras dele:

 READY is when the team says: ‘Ah, we get it’ ”. [...] In the end a User Story is READY if a team can implement it, and a Product Owner can prioritize it.

Baseado nessa definição, é possível criar o nosso próprio conceito de READY. Na Globo.com, uma história está READY quando:

  • Está escrita no formato de user-story (Como <ator> quero <funcionalidade> para <valor de negócio>
  • Foi estimadas pelo time utilizando planning poker
  • Possui valor de negócio
  • Está priorizada
  • Possui critérios de aceite

O objetivo é garantir o entendimento das histórias pelo time. Na definição do Serge, qualquer item de backlog que não se encaixa nessas características não é faz parte do Product Backlog – e sim de um Product Parking Lot, pois está esperando que time em conjunto com o PO terminem de entender e discutir a história. Esse conceito foi criado como um complemento da Definition of Done.

A mecânica

Eu estou sempre preocupado com o custo de coleta das métricas. É preciso ser o mais pragmático e crítico possível em relação à métricas, pois uma relação custo x benefício ruim pode minar completamente o propósito de uma medição – além de que os números podem ser manipulados (gamed).

Esta métrica tem um custo de coleta baixíssimo: é só contar a quantidade de pontos que estão no seu backlog no antes do planning de cada sprint (pois inclusive as histórias que vão para o Sprint Backlog ainda são backlog, pois ainda não foram entregues), registrar esse número, e seguir em frente. Tem o custo de alguns segundos de atenção ao quadro.

O backlog ready está acoplado à velocidade do time, então para que o mesmo funcione direito, você também precisa medir a velocidade do seu time. A velocidade do time é determinada pela média aritimética dos pontos entregues nos 3 últimos sprints. É uma métrica básica do Scrum, que você inclusive já deve coletar.

Por exemplo:

Sprint n: entregamos 43 pontos
Sprint n+1: entregamos 30 pontos
Sprint n+2: entregamos 45 pontos

Sua velocidade no Sprint n+2 será:
(43 + 30 + 45) / 3 = 39 pontos (desprezando os decimais).

O gráfico de velocidade desse time ficaria assim:

Gráfico da evolução da velocidade de um time

Considere que antes do planning de cada sprint, esse era o status do backlog desse time:

pré-Sprint n: 150 pontos
pré-Sprint n+1: 107 pontos
pré-Sprint n+2: 77 pontos

O Backlog READY é um indicador numérico, com uma escala percentual de 0% a 100%, indicando o volume de histórias que estão prontas para entrar no Sprint Backlog e serem desenvolvidas, onde:

  • 0% significa que não existe nenhuma estória em estado READY;
  • 100% significa que há um volume adequado de estórias bem conhecidas e entendidas pelo time;

Toda vez que o indicador está abaixo de 100%, é um sinal que o buffer de segurança está esvaziando e em breve o time pode ficar faminto, sem histórias para trabalhar. Hora de crescer o backlog!

Na Globo.com, convencionamos que 100% é o equivalente a 3 vezes a velocidade do time, ou seja, temos histórias bem escritas e conhecidas pelo time, suficientes para alimentar 3 Sprints. Menos que isso costuma gerar falta de visão de curto prazo, enquanto que mais do que isso costuma gerar desperdício e re-trabalho pelas mudanças inerentes ao negócio.

Portanto, é válido analisar o contexto do seu negócio e descobrir o número ótimo para o seu caso, de acordo com a sua realidade de planejamento, disponibilidade do PO, envolvimento do cliente etc.

A equação para cálculo desse indicador é:

equação para cálculo backlog ready

A fórmula acima definida é a que utilizamos na Globo.com. O número 3 destacado é o que define os três Sprints que convencionamos, e que define o mínimo do nosso backlog ready. Para o time utilizado no exemplo acima, essa seria a evolução do seu backlog ready:

evolução do indicador backlog ready ao longo de vários sprints

No exemplo acima, o backlog ainda estava num nível aceitável no Sprint 2, porém no Sprint 3 ele precisa ser urgentemente trabalhado.

O ministério da saude adverte: métricas podem causar estragos gigantes! Use com moderação!

Cuidado! Eu tenho quatro guias gerais a respeito de métricas que gostaria de compartilhar:

  1. Não seja escravo delas. As métricas devem trabalhar pra você, e não o contrário;
  2. Use o bom senso;
  3. Questione sempre a validade da medição. Porque e para que estou medindo?
  4. Números podem e sempre serão manipulados (gamed). Se vacine contra isso usando as regras anteriores.

Transformando isso num sistema pull

Uma forma simples de utilizar esse número é criar um sistema pull de manutenção de backlog. Nos times em que trabalhei, uma reunião de estimativa era disparada sempre que o número de backlog ready caia para abaixo de 90%.

E foi dessa forma que a métrica foi criada, e é assim que a utilizamos na Globo.com. Espero que seja útil para você também! Qualquer dúvida/sugestão ou comentário, por favor faça abaixo.

[Igor Macaubas] Scrum não é suficiente – ultrapassando o básico

Friday, November 25th, 2011

Finalmente consegui organizar o post inteiro. Agora está completo, com vídeo, slides e fotos. A palestra foi ministrada no dia 25/11/2011 no Agilidade na Prática/Agile Tour Recife 2011, no auditório do Porto Digital:

Começando com o vídeo:

Slides:

Scrum não é suficiente – ultrapassando o básico

E por fim, fotos da palestra :-)

Agilidade na prática

Picture 1 of 15

[Igor Macaubas] Agilidade na prática + AgileTour Recife 2011

Tuesday, November 22nd, 2011

Agilidade na prática + Agile Tour Recife 2011

Na próxima sexta-feira, dia 25/11/2011, estarei na minha terra natal, em Recife, palestrando no evento Agilidade na prática + Agile Tour Recife 2011. A minha palestra será as 17:00 horas, a última palestra do dia. Espero chegar no evento logo após o almoço para acompanhar as palestras da tarde, e depois que tudo tiver terminado, como não poderia deixar de ser, vamos tomar uma agile beer no Recife Antigo! Quem anima?

Na minha palestra, vou falar um pouco de como percebemos que Scrum não era suficiente, em vários aspectos. A agilidade transformou a Globo.com, e vou mostrar um pouco de como isso aconteceu – como conseguimos passar do básico – scrum beyond the basics – e chegar aonde estamos hoje.

[Guilherme Garnier] Rails e mass assignment: como aumentar a segurança dos atributos

Tuesday, November 22nd, 2011

Ao utilizar o scaffold do Rails, ele criará todos os métodos necessários no controller. Depois que o usuário preenche os dados do formulário e envia, é executado o método create do controller. Este método faz algo semelhante ao código abaixo (no exemplo é um CRUD de usuário):

@usuario = Usuario.new(params[:usuario])

Na forma em que o Rails cria o formulário, os atributos do usuário são passados ao controller como um hash. O valor do params acima é algo parecido com isso:

{"authenticity_token"=>"xI1Cy+LvUZzg6FR/1Y/JHcaHVPRyWsHmRII8BhMOr0E=",
 "utf8"=>"?",
 "action"=>"create",
 "controller"=>"usuarios",
 "usuario"=>{"nome"=>"Novo usuario", "email"=>"novo@usuario.com"}}

Além da definição do token de segurança, codificação em utf-8, nome do controller e da action que será executada, o parâmetro usuario contém todos os atributos que foram preenchidos no formulário. Desta forma, é muito simples atribuir os parâmetros preenchidos a um objeto Usuario, seja criando um novo (@usuario = Usuario.new(params[:usuario])) ou editando (@usuario.update_params(params[:usuario])). O Rails chama isso de mass assignment.

O problema desta abordagem é que o usuário poderia facilmente inserir novos parâmetros neste hash, simplesmente adicionando tags input hidden no formulário (usando o Firebug, por exemplo):

<input type="hidden" name="usuario[admin]" id="usuario_admin" value="true" />

Adicionando o código acima, o novo usuário criado receberia o valor true no atributo admin, o que representa uma falha grave na segurança da aplicação.

O Rails oferece um mecanismo para garantir a segurança nestes casos, usando os métodos attr_protected e attr_accessible do ActiveModel. O primeiro permite definir atributos que não podem ser alterados através de mass assignment:

class Usuario
  attr_protected :admin
end

E o attr_accessible é uma forma mais segura: somente os atributos passados para este método poderão ser alterados com mass assignment. Os demais ficam protegidos:

class Usuario
  attr_accessible :nome, :email
end

Obviamente estes dois métodos não podem ser usados simultaneamente, pois um exclui o outro.

Se você quiser atualizar um objeto com mass assignment ignorando a segurança fornecida pelo attr_accessible e pelo attr_protected, basta utilizar o parâmetro without_protection (somente no Rails 3.1):

Usuario.create(
  {:nome => "Novo usuario", :email =>"novo@usuario.com", :admin => true},
  :without_protection => true)

No exemplo acima, o usuário criado terá o atributo admin igual a true, mesmo que tenha sido usado o método attr_protected ou o attr_accessible para evitar a alteração deste atributo.

Outra opção interessante para evitar a alteração de atributos indesejados é o método attr_readonly. Os atributos passados para este método só poderão ser definidos na criação do objeto, e não poderão ser alterados depois. Porém, este método faz parte do ActiveRecord::Base, e não do ActiveModel, ou seja, ele não estará disponível se você usar outro ORM. Há uma issue aberta no Github solicitando que este método seja movido para o ActiveModel.

Link relacionado:

Posts relacionados:


[Kenji Yamamoto] Mac App para Gmail

Thursday, November 17th, 2011

  Atualmente eu comecei a usar uma App chamada Mailplane, para gerenciar o gmail, muito fácil de usar, tem integração com teclas de atalho do MacOS, estava me atendendo muito bem, mas como ela se tornou paga e eu não tô afim de gastar uma grana com esse tipo serviço, eu acabei abandonando a app. [...]

Kenji Yamamoto is a RSS from: Kenji Yamamoto

[Kenji Yamamoto] Alinhamento vertical apenas CSS

Thursday, November 17th, 2011

Todo desenvolvedor Front-end já se deparou com aquele PSD em que voce tem um elemento centralizado verticalmente e com conteudo fluído. Formas de resolver esse problema, temos várias, faz um javascript que resolve, usa o display: table-cell, usa a boa e velha tabela, mas nenhuma solução verdadeiramente utilizando html e css apenas. Com essa necessidade [...]

Kenji Yamamoto is a RSS from: Kenji Yamamoto

[Kenji Yamamoto] Dicas sobre HTML5 e CSS3

Thursday, November 17th, 2011

Ultimamente conversando com alguns amigos vejo a insatisfação que eles tem de querer ter um efeito, ou uma forma dentro do seu site, mas são impedidos pelas limitações da tecnologia. Com isso vem a grande pergunta, vamos dar suporte a quais browser? Partindo desse ponto, podemos saber em que passo caminhar para a implementação de [...]

Kenji Yamamoto is a RSS from: Kenji Yamamoto

[Kenji Yamamoto] GrooveShark Widget for Mac

Thursday, November 17th, 2011

GrooveShark Widget for Mac

Kenji Yamamoto is a RSS from: Kenji Yamamoto

[Kenji Yamamoto] Que equipamento eu preciso para ser um fotógrafo do casamento?

Thursday, November 17th, 2011

Eu estava pensando hoje sobre o que eu gostaria de ter conhecido quando eu fiz a primeira saída como um fotógrafo de casamento em Tampa, percebi que, apesar da riqueza de informações disponíveis para o novato, não me lembro de alguma vez ter visto uma análise detalhada das equipamento de um fotógrafo de casamento típico. [...]

Kenji Yamamoto is a RSS from: Kenji Yamamoto

[Kenji Yamamoto] Help Portrait

Thursday, November 17th, 2011

um movimento de fotógrafos, que estão usando seu tempo livre, equipamento e conhecimento, para ajudar aqueles que são menos afortunados, nesta temporada de férias.

Kenji Yamamoto is a RSS from: Kenji Yamamoto