Como usamos Scrum no Runrun.it

4.063 visualizações

Publicada em

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.

Publicada em: Tecnologia
0 comentários
10 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
4.063
No SlideShare
0
A partir de incorporações
0
Número de incorporações
42
Ações
Compartilhamentos
0
Downloads
257
Comentários
0
Gostaram
10
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Como usamos Scrum no Runrun.it

  1. 1. COMO USAMOS SCRUM Atualizado em Agosto de 2014 no Runrun.it Franklin Valadares Co-fundador e CTO do Runrun.it
  2. 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. 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. 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. 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. 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

×