Scrum Solo

  • 31

Scrum Solo

15 Flares Twitter 7 Facebook 8 Filament.io 15 Flares ×

É bem interessante ler coisas sobre metologias novas, ágeis, e muito frustrante no seu dia a dia ter que encarar o velho e ultrapassado modelo de trabalho cascata, que você tem duas certezas desde o início do projeto:

Certeza 1 – o projeto vai atrasar

Certeza 2 – o escopo vai mudar

Achar que o escopo não vai mudar é, como Martin Fowler diz, uma miragem! E, como ele também diz: “o que acho surpreendente a respeito dessa situação é que alguém ainda se surpreenda com ela”.

Realmente se nós refletirmos um pouco perceberemos que ele está certo. Pense no caso oposto: por acaso você já fez um projeto que o escopo não mudou? Pois é, eu também não.

A proposta da metodologia ágil é bem diferente, ela propõe que num projeto, por exemplo, você pode até ter um custo de desenvolvimento fixo, desde que o escopo seja maleável, na medida que a coisa vai sendo feita, o dono/responsável pelo projeto decide o que é mais importante e deve ser implementado primeiro.

Ok, idéias novas, que maravilha, mas eu estou na mesma situação que muitos por aí: se você pergunta se alguém sabe algo sobre XP, a resposta mais comum é “claro que sei, o problema é que ele ocupa muita memória do meu micro…” ; se pergunta algo sobre Scrum, a resposta mais comum é “O que? Spam?”.

Diante dessa situação fiz uma tentativa de me adaptar a essa mudança de paradigma, afinal numa etapa de evolução precisamos começar de algum lugar.

Comecei a ler o livro Scrum XP das trincheiras e fiquei empolgado. Ao mesmo tempo um colega de trabalho tinha suas tarefas para entregar e resolver organizar em um quadro de tarefas Kanban.

Depois disso eu recebi a minha pequena lista de tarefas e resolvi tentar colocar em prática algumas coisas que havia lido.

A wikipedia dá um bom resumo do Scrum, inclusive no meu caso:

O Scrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um só programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma versão adaptada para uso de programadores solo.

Ok, não é a primeira vez que alguém posta sobre isso, se eu der sorte será a primeira vez que alguém escreva sobre Scrum Solo em português =).

Vou tentar definir alguns conceitos básicos do Scrum antes de relatar o que eu fiz:

  • Scrum Master (Scrum Master): a pessoa que cuida das atualizações diárias do Scrum, papel equivalente ao de gerente de projeto.
  • Equipe Scrum (Scrum Team): uma equipe composta de desenvolvedores, DBAs e testers de QA responsáveis por desenvolver o produto final.
  • Dono do produto (Product Owner): é a pessoa que é a voz do cliente na equipe, responsável por manter o foco do projeto nos negócios , ficando em constante contato com os clientes e futuros usuários do sistema.
  • História (Story): é uma breve descrição de uma necessidade do cliente.
  • Backlog do projeto (Product Backlog): são as histórias pendentes.
  • Sprint (Sprint) – é um período de tempo que pode variar de uma semana até um mês que resulta numa parte do software pronto, que não tem todas histórias (funcionalidades) que o usuário pediu, mas ele já pode usar enquanto o restante é feito nos sprints seguintes.
  • Backlog do Sprint (Sprint Backlog): a interpretação técnica de backlog do projeto, que se resume às tarefas que serão feitas no decorrer do desenvolvimento pela equipe.
  • Gráfico de convergência (Burn Down Chart): gráfico da evolução diária de um sprint sobre o comprimento dos sprints.

Logo de cara eu tinha um problema: precisa informar uma data limite para entregar o projeto, então o que eu fiz apenas foi planejar as poucas alterações no sistema que deveria fazer em um único sprint.
Para planejar os dias necessários para todo o projeto, eu utilizei a fórmula que li no livro que citei acima:

[dias que preciso] X [foco] = [dias necessários]

No meu caso gasto algum tempo com reuniões e outras coisas, logo o meu foco de desenvolvimento não é 100%, é de 80%. Nas minhas contas conclui que precisava de 13 dias para desenvolver tudo:

[dias que preciso] X 0.8 = 13 dias
[dias que preciso] = 16 dias

Depois de listar os requisitos, eu tracei um mapa mental para detalhar os requisitos e montei o meu quadro:

Existem três colunas com nomes auto-explicativos: pendente, em andamento e feito. Daí eu peguei as histórias pendentes e coloquei na primeira coluna, ficando em cima as mais importantes.
Repare que no Scrum não existe meio termo, algo como está 73% pronto. Não, a situação de algo pendente sempre se encaixará em uma dessas três colunas. A unidade de medida é de dias e o menor valor existe é meio dia, ou seja, qualquer coisa que precise fazer levará o tempo mínimo de metade de um dia.

No Scrum temos as reuniões diárias que se decide o que se deve ser feito, isso eu fazia logo de manhã, e o quadro era uma grande ajuda para visualizar o que havia de pendente e o que era mais importante fazer no momento.
Depois de alguns dias desenvolvendo, o quadro ficou assim:

Comparem os dois gráficos e reparem o gráfico de convergência evoluiu e o ideal é que ele acompanhe o tracejado em preto (que é a hipotenusa do gráfico).

Ao final do projeto tudo estava implementado dentro do prazo:

Durante o desenvolvimento do projeto algumas pessoas me perguntaram o que era esse quadro e o gráfico, entre elas desenvolvedores e supervisores. O interessante é que todos eles entenderam facilmente o que o quadro representava e como acompanhar o andamento do projeto.

Isso deixou claro que apenas uma foto do quadro explica a situação do projeto melhor do que qualquer cronograma que já vi.

Vou tentar aplicar mais um Scrum solo se possível.

E vocês, já tentaram fazer algo parecido?

Fernando Boaglio, para a comunidade. =)


About Author

Fernando Boaglio

???

31 Comments

Jeveaux

27/dezembro/2007 at 7:15 am

Boaglio, muito legal a sua iniciativa cara, parabéns. E parabéns principalmente pelo post, muito bem escrito e detalhado. Agora, eu só fiquei com uma dúvida, como você fazia as suas reuniões diárias? Como era o esquema, você fazia apenas uma geral nas atividades e definia o foco do dia?

Fernando Boaglio

27/dezembro/2007 at 10:50 am

Obrigado Jeveaux, eu fazia a minha “meditação diária” exatamente como você disse: dava uma geral nas atividades e definia o foco do dia, priorizando as histórias que estavam mais no topo (as mais importantes). Eu procurava fazer sempre no mesmo horário, uma meia-hora depois de chegar no trabalho.

me

27/dezembro/2007 at 2:07 pm

Mas o ‘correto’ não seria fixar o tempo do sprint (e não do ‘prazo de entrega’) e alterar o escopo baseado no que dá pra fazer nesse tempo?

Digo, pelo que eu sei do Scrum, você não prevê quanto tempo você vai levar pra fazer tudo o que você quer em um sprint. Você define a duração de um sprint (digamos, uma semana), faz uma estimativa de custo em tempo de cada tarefa, e define que tarefas entram no sprint, levando em conta a prioridade das tarefas e a estimativa de dias/homem úteis (nº de pessoas * número de dias do sprint * ‘índice de correção’).

Ou estou viajando? 😛

Fernando Boaglio

27/dezembro/2007 at 5:02 pm

Você está certo, mas no meu caso eu tinha escopo fixo e data entrega, então apliquei da metodologia oferecida o que era viável para o meu projeto. Eu adoraria ter uma data de entrega fixa e um escopo variável, mas infelizmente não foi possível. O tempo de sprint não precisa ser fixo também, pode variar de uma semana até um mês conforme a necessidade; no meu caso o projeto foi tão pequeno que teve apenas um sprint pois na realidade consistia numa única história subdividida em algumas tarefas.

Urls Sinistras » Blog Archive » del.icio.us entre 19/12/2007 e 02/01/2008

2/janeiro/2008 at 11:58 pm

[…] Scrum Solo"Por acaso você já fez um projeto que o escopo não mudou? Pois é, eu também não." […]

Miller

12/janeiro/2008 at 12:25 pm

Estou começando a entrar no mundo Scrum agora… Gostei de ler o seu post, foi de grande ajuda… Gostaria de saber se esse livro que vc leu, existe em português? Se não existeir, vc saberia me indicar um livro que aborde o assunto sobre Scrum e que seja traduzido para o português?

Grande abraço

Fernando Boaglio

12/janeiro/2008 at 2:30 pm

Miller , que eu saiba não existe uma tradução oficial, mas existem artigos inspirados nele, como por exemplo esse:
http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf

Rafael Caceres » Blog Archive » Scrum Solo

23/julho/2008 at 4:14 pm

[…] Informações mais detalhadas sobre o Scrum Solo no blog Boaglio. […]

Rafael Cacres

24/julho/2008 at 12:40 am

Olá Fernando!

Realmente, a parte mais difícil é se manter motivado trabalhando sozinho. É aquele negócio também, não é melhor solo do que com equipe, mas certamente é muito melhor usar scrum que não usar uma metodologia burocrática pra trabalhar sozinho, ou não usar nada.

Você está aplicando isso ainda?

Fernando Boaglio

24/julho/2008 at 11:47 pm

Oi Rafael, felizmente hoje trabalho numa empresa onde se aplica o SCRUM, logo não preciso fazer o scrum solo. Eu tive uma segunda experiência que ainda não publiquei, como o resultado final não foi feliz, acho que pode ser interessante.

Scrum Solo 2 – o fracasso

1/agosto/2008 at 2:02 am

[…] que muitos de vocês voltaram aqui depois da minha primeira gloriosa tentativa de Scrum Solo e querem saber o que deu […]

Os 5 Sites Mais Espetaculares Pra Você Aprender o Que é a Metodologia Scrum para Desenvolvimento Ágil e Usá-la em Seus Projetos | PedroMenezes.com

3/novembro/2008 at 9:24 am

[…] Scrum Solo – Fernando Boaglio dá uma aula sobre Scrum voltada para programadores […]

Aguinelo Pedroso

3/novembro/2008 at 12:18 pm

Esta na minha lista para o próximo projeto solo…

Muito explicativo

Luiz

28/novembro/2008 at 5:19 pm

Lá vai SCRUM Solo

Anderson

14/janeiro/2009 at 11:15 am

Opa Boaglio, mto legal o seu gráfico, facil de entender, realmente o Scrum eh mais proveitoso que o XP, bom eu nunca imaginei uma forma de trabalhar com essas metodologias de maneira solo.
Eu só não entendi o que significa a vertical do seu gráfico. Se entendi bem, a horizontal é a linha do tempo né? O que está na vertical?

Abraços, parabéns pelo artigo, muito bom ^^

Fernando Boaglio

14/janeiro/2009 at 5:46 pm

No gráfico de convergência, a coluna vertical representa a quantidade (em dias) das tarefas, no meu caso eu tinha 16 dias de trabalho. Acho que o nome ideal para essa coluna é: “Dias restantes”. O gráfico pode ser feito em horas também, fica a seu critério.

xavier

1/junho/2009 at 8:42 pm

segue scrum solo

Rodrigo

10/junho/2009 at 4:57 pm

Caro Fernando,

Parabéns pelo post. Muito legal a abordagem sobre o SCRUM, muitas empresas adotaram o desenvolvimento ágil num processo down-top. Lógico que é mais demorado que o inverso, mas os benefícios do scrum como: o auto-gerenciamento, são muito valorizados pelos desenvolvedores já que a maioria sem saber aplica um pouco de scrum no seu dia-a-dia.

Parabéns de novo.

Ederson

18/agosto/2009 at 5:27 pm

Boaglio, muito bom o post, mas um detalhe que fiquei em dúvida: Após o final do projeto o quadro é limpo para recomeçar? Simplesmente assim?

Fernando Boaglio

20/agosto/2009 at 1:50 am

Sim, o quadro é limpo após o final do projeto, mas você deve adaptar essas práticas da maneira que achar melhor.

Fabio Pupo

21/outubro/2009 at 8:21 am

Boaglio, ótimo post! Ainda estou com dúvida no gráfico que você fez .. Na Vertical você tem os dias 0 ~ 16 e na Horizontal!? Não saquei ..

Fernando Boaglio

23/outubro/2009 at 8:49 pm

Na horizontak ficam os dias do mês representando o tempo. Leia também o comentário #12

Rodrigo Carreiro

6/novembro/2009 at 10:23 am

Meu camarada, simplesmente meus parabéns. Simples, prático e didático.

Vinicius Serpa

21/dezembro/2009 at 11:57 am

Fernando Boaglio :
No gráfico de convergência, a coluna vertical representa a quantidade (em dias) das tarefas, no meu caso eu tinha 16 dias de trabalho. Acho que o nome ideal para essa coluna é: “Dias restantes”. O gráfico pode ser feito em horas também, fica a seu critério.

Ou “tarefas”.

Tiago Calisto

3/agosto/2011 at 1:55 pm

Tentei fazer o mesmo com um projeto da faculdade, ficou muito bom… Com o andamento do projeto pude ver que funciona realmente pois conseguimos acompanhar ctodo andamento de nosso projeto é gratificante vermos o conhecimento saindo das trincheiras e sendo adotado na prática.

Ana Cristina

13/dezembro/2011 at 10:30 am

Mto Obrigada pelos esclarecimentos, estou iniciando a implantacao de gerencia de projetos na empresa onde trabalho e vc me deu mtas dicas, agradecida

Renato Muniz

27/fevereiro/2012 at 11:25 am

Excelente artigo. Temos poucas informações sobre SCRUM solo e me inspirei a usá-lo em meus projetos free-lancer.
Pena que a minha atual empresa é impossível aplicá-lo, mas enfim…
Obrigado por compartilhar sua experiência.

Andre

15/março/2016 at 11:17 pm

Olá boa noite!

Gostaria de saber, nessa sua experiência, como se trata de Scrum Solo, na sua adaptação você atuou nos 3 papéis do Scrum: Product Owner, Scrum Master e Time de Desenvolvimento? E em relação aos eventos scrum (aquelas reunioes e revisões) você usou todas?

Abraços!

Fernando Boaglio

16/março/2016 at 12:26 am

Eu era o Scrum Master e o time de desenvolvimento, o meu usuário era o Product Owner. As reuniões, fiz todas sim.

cal

11/novembro/2016 at 10:23 am

Não entendi a fórmula. Na fórmula quanto maior seu foco mais dias vc gastará, está certo isso ?
[dias que preciso] X [foco] = [dias necessários]

Fernando Boaglio

12/novembro/2016 at 12:28 pm

@cal veja esses 2 exemplos para entender melhor: 2 dias para fazer uma tela.
O valor do foco sempre varia entre 0 e 1.
exemplo 1 – 100% de foco – x 1 = 2 dias >>> = 2
exemplo 2 – 50% de foco –
x 0.5 = 2 dias >>> = 4

Leave a Reply

Quero saber mais sobre…

Inscreva-se para receber as novidades!

Arquivos

15 Flares Twitter 7 Facebook 8 Filament.io 15 Flares ×