Thursday, 3 July 2014

Revisando o planejamento do Sprint

Esse post é  uma passada a limpo de anotações antigas, para fins de futura referência. São rabiscos de quando eu ainda trabalhava como desenvolvedor em um time Scrum. Havíamos recém contratado um novo Scrum Master, e estávamos para iniciar mais um planejamento do próximo Sprint. Baseado em frustrantes experiências passadas durante esses planejamentos, já entramos na sala "prontos para o abate", mas fomos surpreendidos - o novo SM era além de muito experiente, uma pessoa muito carismática, e com simpatia e excelente dinâmica conseguiu transformar o evento em algo bastante produtivo.


1. O Set up

1.1. Cores, post its, e lousas
 
Preparação é a alma do negócio. Um ambiente bem arrumado ajuda o time a manter momento e positividade. Utilizamos vários post-its, lousas e canetas de diferentes cores para salientar as várias perspectivas e status das estórias.

Do lado esquerdo da sala haviam duas  white boards, na primeira estavam escritas as REGRAS do jogo, e na segunda iríamos anotar os hangovers do sprint passado, isto é, as estórias que não foram completadas a tempo. Em REGRAS estavam listados os items abaixo discriminados, e antes do planejamento começar nosso SM foi explicando o que cada uma delas significava (em itálico, logo abaixo de cada item).

Do lado direito da sala colamos todas as fichas das estórias do Sprint anterior – nós utilizamos uma Sprint board de verdade - distribuídos sob 4 colunas: TO DO, BLOCKED, QA (TEST), e DONE. Isso ajuda a visualizar o hangover completo em termos de estórias que sequer foram começadas, estão bloqueadas ou apenas "esperam por testes".

REGRAS

A. Desafie
Vocês, como desenvolvedores, devem desafiar cada estória - devem verificar as razões por trás de sua origem e, se de fato elas são realmente necessárias. Pedir ao PO e demais stake holders que contextualise sua necessidade é sempre um excelente ponto de partida.

B. Liberdade
Defenda seu ponto de vista e suas estimativas. Não seja tímido e procure discutir os diferentes pontos de vistas visando alcançar consenso entre o time. Se eu acho que uma certa estória é 8, e alguém diz que é 20, é necessário discutir e encontrar a estimativa “real” que possa ser justificada e acordada pelo time.

C. Foco
Sem computadores ou celulares. Mantenham-se focados para que possamos realizar o planejamento de maneira prática e produtiva.

D. Animem-se!
Esse encontro é sobre nosso trabalho, sobre nossa profissão! É mais do que um evento realizado apenas por conta da empresa na qual trabalhamos. Devemos nos esforçar ao máximo para encontrar as melhores soluções. No fim do dia, independente do quanto você goste do seu emprego ou da empresa, o resultado ajuda a transformarmo-nos em melhores profissionais ao final de cada Sprint. Se isso ainda não é o bastante para te motivar, pense na remuneração a longo prazo que você irá obter ao aprimorar-se profissionalmente ao final de cada iteração.


1.2. PO e Stake holders na sala

Trazer outros stake holders para o encontro é essencial. Um dos participantes que fez enorme diferença em nosso planejamento fazia parte do time de Suporte ao Cliente, ele foi muito útil em ajudar o time a visualizar os problemas diários do seu departamento, e assim explicar e justificar a existência de algumas das estórias que seriam desenvolvidas a seguir. Chegamos até mesmo a mudar algumas estórias em termos de escopo e funcionalidade por conta dessa conversa!


Evitar proxys - o famoso "telefone sem fio" do Fulano que contou ao Beltrano que precisa disso ou daquilo - e permitir contato direto do time com essas pessoas é fundamental, não apenas dissemina informação de forma homogênea, mas porque permite que pessoas que antes sequer se falavam agora comecem a se cumprimentar e trocar idéias pelos corredores, e são atitudes desse tipo que alavancam inovação.


1.3. Comida boa

Dica fundamental: Um time de boca cheia reclama menos! Petiscos ajudam a manter o nível de açúcar alto e o time de cabeça fresca. O ideal é um balanço de favoritos mais tradicionais, como refrigerantes e salgadinhos fedidos e pratos saudáveis, nozes, frutas, etc. Se existe uma única lição importante que você pode tirar desse post, essa é a comida. Comida muda o ambiente. Acredite em mim! :-)


2. Começando

2.1. Aquecimento

Nosso planejamento cobre 2 semanas de desenvolvimento, o encontro leva cerca de 4 horas e teríamos 5 minutos de intervalo a cada 45 minutos de reunião. Em encontros passadas nosso planejamento costumava levar uma hora no máximo, então eu estava curiosos pra ver como o SM iria conseguir manter um grupo tão hiper-ativo na sala por tanto tempo, e o que exatamente iria requerer tanta discussão…

Começamos chegando as estórias que haviam sido completadas (DONE) e depois as que ficaram abertas (DOING, BLOCKED, e QA). Tudo o que não foi concluído no Sprint passado é parte do hangover e deve ser – com o consentimento do PO – levado para o próximo Sprint.

Uma fez feito a revisão das estórias em termos de concluídas e inacabadas, comparamos nossa board física com a virtual e descobrimos algo interessante, elas não batiam! - Explico: antes do novo SM chegar, nosso time usava apenas uma Sprint board virtual no Trello porque era "mais fácil" sincronizar com os desenvolvedores que trabalhavam remoto. Com a chegada dele, após muita luta o time aceitou voltar a usar uma board na parede, mas acabamos ficado com duas. Para evitar confusão concordamos que a board na parede é a verdadeira (the source of truth) e que tentaríamos sempre manter a board virtual sincronizada para facilitar a vida dos developers virtuais.

A diferença entre as boards ressaltou algo importante, que no passado estórias haviam sido adicionadas no Trello e os pontos dessas estórias não haviam sido considerados. Nós basicamente registrávamos menos pontos do que havíamos de fato entregue. Em uma borda física, fica muito mais fácil perceber quando uma certa estória foi adicionada a board e o PO "esqueceu" de avisar o time.

Durante esse caloroso debate o PO argumentou que seria responsabilidade do SM em manter as boards consistentes. Considerando-se  que somos todos partes do mesmo time, cada um deve responsabilizar-se individualmente por seu trabalho, e como um time, garantir que as boards sejam sincronizadas apropriadamente. Um por todos e cada um por si. A responsabilidade final por qualquer coisa que voce esteja trabalhando é sua. É sua responsabilidade adicionar uma nova ficha na board se você começar outra estória, como também é sua responsabilidade mudar o status das tarefas conforme elas sejam realizadas. No nosso caso, nas duas boards. Para cada tarefa ou estória que se está trabalhando deve haver uma ficha na board, e se você estiver trabalhando em algo que não está representado na board, você está se transformando em um impedimento para o time.



2.2. Planejando, Parte 1

Uma vez que as estórias do Sprint anterior foram re-visitadas, e o mistério das boards explicado, começamos o planejamento de fato. O PO começou mostrando o Backlog e os items de maior prioridade que ele estava interessado em implementar no próximo Sprint. No nosso caso, muitos desses items já haviam sido analisados em Sprints passados durante um encontro regular que chamamos de Refinamento do Backlog, então apenas alguns detalhes de última hora foram questionados.

O nosso Refinamento de Backlog funciona da seguinte maneira: nos encontramos geralmente uma vez na semana, de 30 a 60 minutos , e discutimos as estórias do topo do Backlog e fazemos seu grooming, isto é, garantimos que elas fazem sentido e são de qualidade (INVEST), e depois as estimamos. Durante o grooming muitas vezes o time  também opina sobre outras estórias em termos gerais  de tamanho (P, M, G) e possíveis requerimentos  e problemas que podem surgir, de forma a auxiliar o PO a ser capaz de escolher com segurança as estórias que irão agregar o maior valor possível ao produto durante as próximas  iterações.


Nosso SM  queria que discutíssemos cada estória em detalhes, ao ponto de reformularmos como alguma elas haviam sido originalmente escritas. O objetivo dessa atividade não é mostrar que poderíamos escrevê-las de uma maneira melhor – o que certamente era possível – mas estimular os participantes a discutirem abertamente cada item. A essa altura do campeonato algumas pessoas na sala começaram a ficar frustradas e entediadas. Eles queriam "terminar a reunião e programar", ao invés de mais conversas e discussões. O problema desse tipo de atitude é que ele não contribui em nada com o idéia de abrir os canais de comunicação entre o time e o business. Essa mensagem subliminar, muitas vezes sem intenção, de que tal discussão não é necessária, corta aquelas perguntas bobas que trazem profundos insights em termos de como abordar uma determinada tarefa.

Um desenvolvedor economizar uma hora aqui, ou outra ali, não fará o time mais rápido. Quanto mais discussão (com bom senso) e maior abertura e liberdade de comunicação, mais podemos inovar e ter certeza de que estamos fazendo a coisa certa, para as pessoas certas. Atalhos são tentadores, mas não ajudam a aumentar a velocidade, muito pelo contrário. Acelerar envolve muitas vezes reduzir a marcha e voltar aos fundamentos básicos. Lembra do Daniel Sam na casa do Sr. Miagui, repetindo e repetindo os movimentos? É mais ou menos, isso aí.

Resumindo, na primeira parte do encontro o time busca entender o que o PO quer, e porquê. Também é comum e conveniente e criação de um objetivo para o Sprint. Uma sentença que sintetize exatamente o que se está buscando atingir na próxima iteração, e esteja coeso com um tema de maior escopo.

Um objetivo para o Sprint também dá ao time maior flexibilidade de escopo em termos do que eles planejam entregar, porque mesmo se eles precisem remover algum item, eles ainda assim concordam em entregar algo tangível e pronto, que esteja de acordo com o espírito definido no objetivo do Sprint.


2.3. Planejando, Parte 2 - Estórias e tarefas…
  
Uma vez selecionadas as estórias do próximo Sprint, o PO deixou o resto do time para discutir as tecnicalidades  de como implementar os items que o grupo decidiu aceitar, bem como escrever as tarefas que seriam necessárias para completar cada uma delas. 
Ele estaria disponível em sua sala, caso precisássemos tirar alguma dúvida.

Normalmente nosso time começa com discussões sobre o design em uma lousa e uma vez que a idéia geral foi entendida por todos, o time decompõe as estórias em tarefas mais refinadas e granulares. O ideal é que as tarefas sejam pequenas a ponto de poderem ser realizadas em um dia, ou menos.


Essa segunda parte do encontro tem normalmente o mesmo tamanho da primeira, cerca de duas horas. O Scrum deixa em aberto, mas no nosso caso utilizamos velocidade passada para estimar quantos pontos deveríamos nos comprometer para a próxima iteração, e também consideramos coisas fora do nosso controle como férias e outras razões que afetem o time.

Nosso time prevê a quantidade de trabalho que pode completar até o final do Sprint. O PO não tem controle em termos de quanto o time irá entregar, mas sabe que os items que estão sendo trazidos do topo do Backlog são os que ele considera de maior valor e prioridade. Também podemos barganhar para que items mais abaixo no Backlog sejam trazidos para o Sprint, isso geralmente acontece quando o time e o PO percebem que algo de menor prioridade encaixa facilmente com o resto dos items de maior prioridade.

Devido a natureza da nossa arquitetura um problema recorrente que tínhamos com nossas estórias passadas era que elas muitas vezes pareciam mais tarefas do que estórias isoladas end-to-end. Muitas vezes acabávamos com estórias cheias de dependências que ao menor problema comprometiam a entrega completa do Sprint. Quando começamos a discutir as estórias em mais detalhes, foi mais fácil evitar esse tipo de problema e começamos lentamente a produzir estórias menores e que realmente eram end-to-end. Obviamente que nem tudo são rosas mas as coisas estavam melhorando conforme amadurecíamos.

Também acordamos que tentaríamos criar feature files para pelo menos 20% de nossas estórias e, aos poucos, mudar a forma com que escrevíamos nossos critérios de aceitação logo abaixo das estórias. Os feature files contém não apenas cenários mais bem formulado, mas já embutem critérios de aceitação, e são mais um passo em direção a adoção do BDD.

Ao final da segunda parte nosso time define uma previsão realista do que acreditamos ser capazes de entregar até o final do Sprint. Nós evitamos dizer que "nos comprometemos a entregar" e preferimos dizer que "estimamos entregar", porque afinal de contas, nós só sabemos se seremos capazes ou não, quando terminarmos! Então colamos as estórias e suas devidas tarefas na nossa Sprint Board (também chamada de Sprint Backlog) e começamos o trabalho de desenvolvimento.

  
Considerações finais

Algo interessante que nosso SM frisou durante o planejamento é que de acordo com Scrum, nós precisamos mudar um pouco nossa atitude e buscar ser mais versado possível em diferentes tecnologias. Não se trata de criar generalistas, mas os membros do time devem ir onde o trabalho está e ajudar sempre que possível, ao invés de refugiar-se atrás de sua especialidade ou preferência. Devemos trabalhar juntos e aprender uns com os outros.

Consequentemente, durante a elaboração das tarefas do Sprint não é necessário – nem apropriado – que alguém seja voluntário das tarefas “que eles podem fazer melhor.” O ideal é que, na medida do possível, um desenvolvedor escolha tarefas que irão propositadamente requerer aprendizado (programando em par com alguém mais experiente, por exemplo). Tudo com bom senso, evidentemente.

Em termos de métricas, não há problemas em estimar-se estórias sem entender completamente todos os possíveis cenários e condições de aceitação (durante o grooming, por exemplo) e se em algum momento o time suspeita que a estória é de fato muito maior (ou menor), não há problema em re-estimar. Considerando a complexidade envolvida na criação de software, você sempre começa com várias incógnitas e ao longo do processo precisa verificar se as idéias iniciais estavam corretas.


O importante é não perder de vista que o objetivo final é entregar software que será usado pelo cliente, e não perder tempo com gráficos, valores e estimativas que apenas gastam recursos e não agregam nenhum valor.