Gravei a palestra em vídeo, mas como o auditório estava super cheio (ainda bem!) a filmagem não ficou legal ! Vou tentar salvar pelo menos o áudio e publico um podCast!

Slides:

Algumas fotos da minha palestra e do espaço da Globo.com no evento:

Agile Brazil 2012

◄ Back

Next ►

Picture 1 of 28

Após enfrentar cerca de 3 horas de peregrinação, eu era o mais novo proprietário de um iPhone 4S de 32GB! E foi aí que o meu pesadelo começou: logo no primeiro dia, eu já estava extremamente incomodado com a performance da bateria. Mas tudo bem, primeiro dia com o telefone, é normal que a bateria quando nova tenha uma performance cerca de 40% inferior da sua performance após 3 cargas completas… enfim.

Mas o que eu esperava não aconteceu. Mesmo após 3 dias de uso, e 3 cargas completas, eu continuava experimentando uma performance horrível de bateria. Em média, cada hora em stand-by, sem uso algum do aparelho, me custava 10% de carga. Recorri aos forums da Apple, e descobri várias dicas interessantes, que conseguiram melhorar significativamente a vida da minha bateria. São elas:

Notification center: desative tudo que você não precisa

Desabilite todas as porcarias que você tem no seu notification center que não servem de nada. O widget de bolsa de valores é um bom exemplo: no Brasil é totalmente “para inglês ver”, pois não serve absolutamente para nada, a não ser que você seja o Eike Batista e tenha ações nas bolsas dos EUA. Deixei no meu notification center só as apps que eu realmente uso e quero receber notificações. Todas as demais levaram um off. Tentei não ficar muito paranóico, pois se você sair desabilitando tudo seu iPhone vai virar um iPod que liga. Deixei as notificações de Twitter, Facebook, Path, Instagram, todas ativadas. Só desliguei as que realmente não uso mesmo – por exemplo, para que o jogo InifityBlade2 precisa mandar uma notificação pra mim? Para nada! Sumi com ele.

Deixei somente o que importa no notification center (App Settings, depois opção ‘Notifications’).

Desativei sem piedade as bobagens.

Location services: desative algumas coisas que você não precisa, mas não sabe.

Pelas pesquisas que fiz nos forums da Apple, do mesmo jeito que existem várias apps que usam notificações em vão, existem várias apps que usam Location Services em vão. E ficam sugando a sua bateria em vão também. Então, é bom desativar essas bobagens. (app Settings, opção ‘Location Services’):

Desative os locations services das apps que você não precisa.

Mas o que faz a maior diferença mesmo é lá no final dessa tela, na opção de System Services. Nessa tela, pode desativar sem medo de ser feliz as seguintes opções:

- Diagnostic & Usage: para enviar suas coordenadas de localização quando um crash de alguma app ocorrer. Ou seja, para nada além de sugar sua bateria.

- Location Based iAds: para exibir anúncios do tipo ‘Solteiras procurando por uma noite quente no Rio de Janeiro’. Ou seja, para nada além de sugar sua bateria.

- Setting Time Zone: esse é até útil. Se você viajasse todos os dias para locais com fuso-horários diferentes. Ou seja, para nada além de sugar sua bateria. Esse aqui eu ainda ativo, quando viajo, para o iPhone ajustar o horário automaticamente. E uma vez o horário ajustado (não demora mais do que 5 minutos), vou lá e desativo de novo.

Notificações individuais das apps: desative as que você não precisa.

Essa é meio chatinha de se configurar. Vá na App Settings e vá de uma a uma nas configurações de todas as apps que você tem instaladas no seu iPhone. Procure por apps que são muito ‘fominhas’ por push notifications. A do Facebook é um bom exemplo: tem 10 eventos diferentes de notificações push. Isso consome uma bateria incrível. Desative tudo que você não precisa. Na app do Facebook, por exemplo, só deixei o Push ativo para Mensagens, Posts na minha Wall e Solicitações de Amizade. Todo o resto não é importante o suficiente para que eu receba uma notificação Push. Essa parte é chata porque você tem que ir de um por um, mas tenha em mente que por mais sutis que sejam, notificações push são intrusivas e interrompem você.

Desative todo o lixo de notificações que o Facebook tenta empurrar

Depois disso tudo…

… a vida útil da minha bateria voltou a ser como era na época do iPhone 4. Chego no final de um dia de uso moderado ainda com 50% da bateria. Num dia de uso intenso, 20%. E, não perco mais do que 5% de bateria numa noite de 10 horas (média de 0.5% de descarga por hora). Um bom indicador para saber o quão bem anda a sua bateria é indo lá na app Settings -> General -> Usage. Lá você vai saber à quanto tempo de uso (uso = tela acesa, não necessariamente navegando ou falando ao telefone) e a quanto tempo de standby você submeteu o seu aparelho. No momento em que eu escrevia esse artigo, estava com o seguinte cenário:

51% de bateria restante, quase 20 horas após a última carga. Nada mal.

Algumas outras dicas para prolongar a vida útil da sua bateria:

- Não deixe muitos programas rodando em background. A maioria deles acaba com a sua bateria. O Twitter é um grande ladrão de bateria quando fica em background.

- Dê pelo menos um ciclo de carga completo por semana. Deixe sua bateria descarregar até o iPhone desligar. Use até o osso mesmo. Depois, plugue no carregador de parede (na tomada) e deixe carregar até os 100%, mas de preferência procure deixa-lo ligado pelo menos 2 horas (mesmo que ele atinja os 100% de carga antes desse tempo, deixe ele ligado um pouco mais). Se puder ser de um dia para o outro, melhor ainda.

- Deixe poucas contas de email e calendário configuradas. Aprenda a usar a funcionalidade de foward, e deixe no máximo 2 contas de email e calendário configuradas no seu iPhone. Mais do que isso e a sua bateria começará a ser sugada para manter tudo sincronizado. Também procure evitar usar contas exchange – vi relatos de que ele é muito mais ‘gastão’ do que as contas de Gmail, Hotmail e iCloud.

Particularmente, eu não gosto de desabilitar notificações push e nem reduzir demais as configurações de sincronismo. A mágica do iPhone está justamente na velocidade da coisa. Tenho amigos que configuram as contas de email para fetch manual, de 1 em 1 hora, e desabilitam absolutamente todas as notificações push. Acho isso exagero. Com certeza a bateria dele deve durar umas 3 ou 4 horas a mais do que a minha, mas na minha opinião o trade-off não vale à pena.

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:

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 é:

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:

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.

Começando com o vídeo:

Slides:

E por fim, fotos da palestra

Agilidade na prática

◄ Back

Next ►

Picture 1 of 15

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.