Blog.Impact

Sim, você pode! Mas o correto seria perguntar como e não se pode!

Em alguns dias de pesquisa sobre ferramentas online para o auxilio e redução de consumo de papel (na busca de uma prática sustentável sem perder a produtividade), encontrei duas ferramentas que me chamaram a atenção e me fizeram publicar esse texto.

Mas a relação custo x benefício dessa prática não me agradou. A produtividade não me parece ser a mesma, quando se utiliza esses scrum-boards virtuais. O impact visual que um quadro branco tem na sua frente, durante seu dia de trabalho, é muito maior que um site onde você entra quando quer para ver as tarefas pendentes, ou faz um trabalho de estimativa.

Mas se é a única alternativa, no caso de equipes remotas, é melhor do que nada.

NOTA: Observei que se for possível, utilizar dois monitores, mantendo o SCRUM board virtual aberto em um dos monitores durante seu dia, essa questão do impacto visual diminui. Mas trocamos os gastos com papel por gastos com energia.

NOTA: Em uma empresa que visitei e está iniciando a aplicação do SCRUM agora, verifiquei a utilização de um scrum-board de vidro, e seus traços feitos com fitas coloridas. O uso de números identificando documentos relacionados as tarefas ao invés de post-its. É uma alternativa também.

Planning poker

Encontrei o site Planning Poker, que proporciona o jogo de cartas para estimativa online. Você, como product owner, acessa o sistema sendo moderador e convida seu time de desenvolvedores para fazer as estimativas através de uma URL. Os membros acessam essa URL e aguardam as histórias e o início das contagens para mostrar o resultado. Ele fornece opções para contar sua estória de forma estruturada, onde você responde algumas questões, ou de forma livre, onde é aceito qualquer coisa.

Após contar sua estória, você inicia a contagem do tempo. Após o resultado, você passa para a próxima estória. Uma mão na roda para quem não tem possibilidade de estar se encontrando frequentemente.

Na primeira reunião do projeto Marca Pelada, foi montado todo o product backlog sem estimativas. O planningpoker.com será utilizado para estimar e após esse resultado, será colocado aqui um update dessa experiência.

Scrum board

O scrum-board virtual realmente é um problema. Encontrei várias opções para uso no desktop, com alguma ajuda de um papél de parede interessante você consegue um bom resultado. Mas o impacto visual realmente fica prejudicado. E vai totalmente contra o DRY você ficar atualizando um scrum-board com as tarefas que os outros da sua equipe fizeram ao final da sua tarefa.

Mas como nem tudo são flores no desenvolvimento remoto, ou você faz isso ou utiliza sistemas online para controle de tarefas compartilhadas. Um simples todo ou até mesmo um aplicativo que gera os burndown chart, como o Acunote.com. Para um único projeto ele é gratuito. Após o cadastro, ele tem alguns dados preenchidos para demonstração.

Incrivelmente foi a única ferramenta que encontrei para esse tipo de controle. Mas unindo controles de versão, sistemas de tickets e um wiki, você consegue muito bem fazer o controle de forma objetiva e bem similar.

O importante é uma forma única e ágil da equipe se comunicar.

Mais recursos

1. Scrum Alliance – Resources

Um dos métodos de estimativas mais comuns no SCRUM é o uso do planning poker, um jogo de cartas numeradas com uma sequência de Fibonacci. A idéia é pontuar suas estórias, e a primeira estória pontuada serve como referência para pontuar as seguintes.

As cartas são geralmente as seguintes (pelas explicações que li, o modelo abaixo me parece o mais correto):

Ok… Mas qual o porquê dessa série de números?

Simples, os números menores conseguem ser mais precisos e refletem muito bem algo realmente possível de realizar. Os número maiores não são estórias muito claras, difíceis de estimar e que devem ser transformadas em estórias menores. Numa escala coerente, estimativas com números maiores que 13 já levantam questões como: “Isso é mesmo uma estória?”, “Isso não poderia ser quebrado em estórias menores?”, etc.

Cartas especiais

	Feito Essa estória já foi realizada, ou é tão simples, que levará apenas alguns minutos para ser realizada.
	Sem idéia Não se tem a mínima idéia do tempo que essa estória pode levar.
	Hora da pausa Hora de fazer uma pausa para descansar um pouco.

Como funciona

Cada membro da equipe possui um conjunto dessas cartas.

O product owner, junto da equipe, seleciona a estória que mais se aproxima de uma pontuação 2. Essa pontuação no momento, é apenas 2, não significa 2 dias, nem duas horas¹.

A questão aqui é definir uma estória referência. Apartir dessa estória, serão feitas as estimativas para outras estórias seguindo o planning poker.

Todos pensam, selecionam suas cartas e as pões sobre a mesa com o verso para cima. Quem não prestou atenção, acaba não tendo saída e pedir que o product owner explique novamente a estória.

Se houverem muitas divergências de opiniões, o que é comum, o menor valor estimado e o maior, explicam o motivo que os levou a estimar tal valor, questão de um minuto mesmo. É feita a rodada de estimativas novamente. Havendo consenso, a estória fica estimada e se passa para a próxima. Se ainda houverem muitas divergências, outra rodada se torna necessária, se nessa rodada nada for decidido, toma-se a opinião da maioria como a real. É importante que o SCRUM master esteja envolvido para evitar discussões e brincadeiras durante esse momento.

Atenção: Esse artigo foi baseado em uma palestra realizada pelo Juca, do CESAR, através do Treina Tom e na página Planning Poker. Sendo partes do texto apenas transcrições do texto original.

¹ Story points parece ser a forma mais bacana de estimar, mesmo parecendo ser algo muito abstrato inicialmente. Essa abstração se vai, apartir do momento em que o primeiro sprint é executado. No final do sprint, essa pontuação virou referência, e já pode ser considerada num gráfico pontos x tempo.

A resposta é simples: medindo!

Se você nunca medir, nunca saberá o tempo que leva. Todo trabalho de estimativa baseia-se na experiência (registros passados) do tempo que levou. Medir o tempo pode parecer uma coisa simples, mas é importante ser sempre pessimista, problemas podem ocorrer, e todo o tempo que ganhou no projeto, pode ser perdido na última tarefa.

Estimativa é um indicador, e como qualquer outro indicador, você precisa de uma referência. Se você nunca mediu seu tempo, comece agora, sem esses dados suas estimativas serão chutes, e a entrega do projeto na data marcada será uma loteria.

Divida todo seu trabalho em tarefas equivalentes. Reduza seu nível ao mais operacional possível, onde você possua apenas instruções de trabalho. Um exemplo disso é uma tarefa “Programar formulário de cadastro de pessoas”. Reduzindo ao nível mais operacional possível, você evita que a evolução das tarefas possam ser mensuradas (a tarefa A está 78% concluída) e acabem não mostrando sua real evolução dentro do projeto.

Isso não é novo, o SCRUM prega isso, e nele uma tarefa só pode estar pendente, em andamento ou concluída. Estou no início dos meus estudos sobre SCRUM, e pode ter muita coisa que eu entendi errado, mas de qualquer forma, aprendi uma porção de coisas bacanas que podem ajudar mesmo não sendo o padrão correto.

Meu maior problema era definir o que seria uma estória e o que seria uma tarefa. Um exemplo que me ajudou a definir isso esta no livro Scrum and XP from the Trenches e segue abaixo de maneira simplificada:

Quebrando suas estórias em estórias menores

Quebrando estórias em tarefas

Então, defina suas estórias, suas tarefas e então inicie seus trabalhos. Leia sobre SCRUM e XP para ter uma idéia melhor, acredito que isso lhe ajudará muito mesmo, não apenas no seu trabalho, mas para organização de sua vida.

Após o início dos seus trabalhos, acompanhe a evolução do seu trabalho x tempo. Esse indicador é muito importante e será, após a conclusão dos trabalhos, seu indicador base. Vai ser com ele que você saberá o tempo real necessário para concluir um número X de tarefas. É um número aproximado, mas é melhor que número nenhum.

Com isso, você terá uma estimativa real – aproximada, mas real – do potencial de trabalho que tem em mãos. Como ele será possível definir os trabalhos que poderão ser feitos em determinado tempo e até planos para melhoria desse potencial, como treinamentos, aumento do número de pessoas na equipe ou até mesmo troca de membros que possam não estar se adequando a forma de trabalho.

1. InfoQ: Scrum and XP from the Trenches
2. Scrum na Wikipedia
3. Implementing Scrum
4. Planning Poker Game