É 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?