Empresas que desenvolvem softwares têm aderência maior à metodologia ágil Scrum. Desta forma, resolvemos criar esse pequeno documento que conta como é nossa metodologia de desenvolvimento interno, usando o Scrum e o Runrun.it em conjunto, a fim de controlar melhor as tarefas, projetos e sprints.

1. COMO
USAMOS
SCRUM
Atualizado em Agosto de 2014
no Runrun.it
Franklin Valadares
Co-fundador e CTO do Runrun.it

2. Scrum
O Runrun.it não é um software apenas
para empresas ou times de
desenvolvimento de software. Sua
metodologia simples de fluxo contínuo de
tarefas ajuda empresas que prestam os
mais variados tipos de serviços e não
querem investir tempo em metodologias
mais complexas de gestão de projetos.
Porém, empresas que desenvolvem
softwares têm aderência maior à
metodologia ágil Scrum. Especialmente
aquelas empresas que desenvolvem seus
próprios produtos. Um pouco menos
aquelas que desenvolvem software como
projetos para seus clientes (com
mudanças frequentes de escopo).
Desta forma, resolvemos criar esse
pequeno documento que conta como é
nossa metodologia de desenvolvimento
interno, usando o Scrum e o Runrun.it em
conjunto, a fim de controlar melhor as
tarefas, projetos e sprints.
A PRIORIZAÇÃO
Criamos um usuário chamado “Product -
backlog”, onde todas as funcionalidades
(descritas como histórias) que um dia vão
merecer a atenção da empresa ficam.
Além disso, temos os usuários “Bug
tracker” e o usuário “Dívidas técnicas -
backlog”. Neles ficam as tarefas que
precisam ser encaixadas a cada sprint, mas
tomamos cuidado para que elas ocupem
no máximo 20% do tempo total disponível
do sprint.
Todos os bugs que envolvam clientes e
que merecem atenção recebem tags
“prioridade alta” e são arrastados para o
alto da fila. Muitas vezes, entram até no
sprint em execução, substituindo alguma
tarefa planejada, uma vez que merecem
urgência.
Na segunda semana do sprint (os nossos
são geralmente de duas semanas),
marcamos uma reunião de validação das
prioridades, envolvendo o pessoal Técnico,
Atendimento ao Consumidor, Vendas e os
Sócios da empresa.
Nessa reunião, validamos se as histórias
(descritas como tarefas genéricas) desses
usuários “backlog”, estão em ordem
correta de prioridade.
Terminamos o sprint atual na sexta-feira e,
caso algo fique pendente para publicação
em ambiente de produção, deixamos para
a segunda-feira, quando temos o nosso dia
de projetos livres, os “Passion Projects”.
A SEGUNDA-FEIRA “LIVRE”
Essa segunda-feira, que seria o início do
próximo sprint, é dedicada a
funcionalidades que as pessoas adorariam
ver no Runrun.it, mas nunca entram como
prioridade na lista. Elas precisam ser
pequenas o suficiente para serem feitas
em um dia. Além disso, se a ideia vier de
um colaborador não-técnico, ele precisa
convencer alguém técnico da importância
daquilo e ajudar na especificação e testes.
Usamos parte dessa segunda-feira para
especificar as tarefas das histórias, quebrá-
las em “Post-its”, geralmente que podem
ser implementados de forma
independente. Esse é um ponto crucial da
metodologia “scrum” e não há software
que resolva. A inteligência humana e a
experiência da equipe ajudarão a melhorar
essa etapa a cada sprint.
Implementar parte 1 da
nova tela de usuários
Título da tarefa

3. Cada um desses “Post-its” se torna uma tarefa no Runrun.it com a seguinte
configuração:
Responsável: “Sprint – backlog”
Tipo de tarefa: (você decide)
Cliente > Projeto “Dev Sprints > Sprint X – (15-08-2014)”
Tags: (a funcionalidade)
Desta forma, ao final da especificação, teremos todas as tarefas no Runrun.it abertas
para o usuário “Sprint – backlog”. É lá que os desenvolvedores vão pegar as tarefas,
transferindo-as para si próprios.
Note que criamos um “Cliente” chamado “Dev Sprints” e a cada novo sprint criamos
um projeto chamado “Sprint X - <data final do sprint>”.,
Implementar parte 1 da
nova tela de usuários
Atualizamos o post-it
com o número da tarefa no RR.
#450
Esse também é um bom momento para tentar estimar, em conjunto com todos os
devs, o volume em horas úteis para cada uma das tarefas. O Runrun.it já possui uma
“Estimativa de esforço padrão” para cada “Tipo de tarefa”, que já ajuda bem para
times que querem pular essa parte.
(dica: o Runrun.it, com o tempo de uso, começa a calcular o tempo médio de entrega
de um determinado Tipo de Tarefa. Se você especificar bem os tipos,
terá insights de como estimar mais adequadamente o tempo das tarefas)
O ideal, nesse momento, é que todos os Devs que vão participar do sprint estejam
com suas listas de tarefas limpas. Daí, cada um pega as tarefas do sprint que mais
estão relacionadas com o seu perfil de desenvolvimento (transferindo as tarefas do
usuário Sprint - backlog) .
Agora você já tem o relatório Status Report com a previsão de entrega de cada uma
das tarefas abertas para o sprint. Se algum Dev ficou sobrecarregado ou se alguma
tarefa está indicando término fora da data final do sprint, repriorize ou transfira as
tarefas.

4. O SCRUM BOARD
Colocamos os post-its em um quadro (branco ou um vidro na parede) dividido pelas
histórias e pelos “status” para que fique fácil e aderente à metodologia tradicional do
Scrum. Porém, as telas de “equipe” e o “status report” do Runrun.it também funcionam
bem para a visualização rápida do andamento do sprint.
(insider info: estamos trabalhando em uma nova tela de “Projetos” onde a visualização
do burn down chart e evolução das tarefas por status estarão presentes, deixando o
produto mais aderente para quem optar em utilizar o Scrum 100% digitalizado).
Relatório
Status Report
Últimas entregas
estimadas de cada
desenvolvedor
Todas as tarefas
ainda na fila
Trabalhamos
com 4 histórias
por sprint mais
uma linha para
bugs e dívidas
técnicas
história1história2história3história4
bugse
dívidas
Tarefas a fazer (na lista dos devs) Trabalhando Em teste Entregue
Usamos os
Status das
tarefas para
controlar a
migração das
mesmas pelo
scrum board.

5. O INÍCIO DO SPRINT
Na terça-feira, iniciamos o sprint, já com a primeira reunião “Daily Scrum”. Todos
comentam qual tarefa estão, se precisam de algo, se têm alguma restrição, trocam
ideia rapidamente sobre algum ponto mais difícil e mãos à obra. Lembrem-se de
apertar o “play” na primeira tarefa de suas listas. O sistema passa a contar o tempo
automaticamente, pulando horários fora da sua jornada de trabalho. Horas extras
podem ser ajustadas manualmente.
Repetimos essa reunião diariamente para garantir a evolução sem surpresas no sprint.
Formalizamos todas as decisões através dos comentários nas tarefas no Runrun.it,
para garantir que a inteligência não se perca (lembre-se: os comentários e anexos das
tarefas só podem ser apagados após 15 minutos de sua criação. Depois disso é decisão
tomada. Pode tomar outra decisão, mas não dizer que a anterior não foi tomada.).
À medida em que os dias vão passando e as tarefas vão sendo entregues, podemos
consultar os relatórios do Runrun.it a acompanhar se nos mantivemos dentro do prazo
final do sprint.
Você pode clicar
nos gráficos e ver
a lista de tarefas
na fila, em
desenvolvimento
e as já entregues.

6. VANTAGENS DE USAR O RUNRUN.IT
•Previsibilidade: Como as tarefas são estimadas em horas úteis e o Runrun.it leva em
consideração a jornada de trabalho dos desenvolvedores, fica fácil prever se algo não
vai ser entregue no prazo necessário.
•Timesheet automático: O Runrun.it conta as horas gastas nas tarefas
automaticamente. Basta clicar em “trabalhar” e o sistema pula todas as horas não
úteis. (Ajustes manuais, como horas extras, também podem ser feitos.)
•É possível controlar o “orçado” versus “realizado” tanto em horas quanto em dinheiro.
Basta usar o relatório de “Custos”.
•Caso haja mudança de escopo, prioridade ou entrada de novas tarefas no sprint, o
sistema recalcula todas as datas de entrega automaticamente.
•Outros colaboradores da empresa, além dos gestores, receberão os reports do
andamento do sprint (como um projeto) e poderão colaborar para sua melhor
execução.
•Ao terminar o sprint, os post-its vão para o lixo, mas toda a inteligência, arquivos
trocados e decisões tomadas estarão dentro de uma só ferramenta.
O RESUMO DO PROCESSO
sprint anterior
Segunda
Livre
Início
sprint
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Priorização das
histórias
previamente criadas
no usuário Product
- backlog
Criação das tarefas
a partir das histórias
priorizadas. Todas
vão para o usuário
Sprint - backlog
Tarefas
distribuidas
entre os devs
Tarefas criadas para
o cliente Dev
Sprints, projeto
Sprint X – data de
fim
Priorização das
histórias para o
próximo sprint
Colaboração, centralização de informações e controle através do Runrun.it