Scrum em um projeto pessoal!

Sabe aquele projeto pessoal que temos, mas que nunca conseguimos levar adiante? Então… Neste artigo escreverei como o Scrum me ajudou a realizar o meu próprio projeto pessoal. Se você também tem um projeto assim, que sempre desejou fazer, mas que nunca encontra tempo, ou sempre surgem obstáculos e você acaba adiando esse projeto sempre, esse artigo é perfeito para você.

Este artigo é uma adaptação de uma serie sobre acompanhamento Projetos Pessoais com o Scrum!. O relato é do seu autor original mas, eu por coincidência do destino passei exatamente pelo mesmo processo dele e como achei o texto muito legal e não ia conseguir escrever alguma coisa melhor que isso, decidi trazer aqui para vocês, embora em algumas partes coloquei minhas próprias vivencias quando estava neste processo.

O Scrum é uma metodologia ágil que nos ajuda a focar no que realmente deve ser feito, sempre priorizando o que é mais importante. Desta forma, conseguimos concentrar nosso trabalho no que realmente vai ser útil.

Neste artigo irei abordar a quebra desse projeto pessoal em ciclos, com o uso do conceito de Sprints. Esse conceito é muito importante no Scrum e está relacionado a diversos outros, mas esses serão mais bem trabalhados no decorrer do texto. Para facilitar o entendimento de como o Scrum funciona e como ele pode ser aplicado, ao longo de todo texto pretendo usar uma experiência vivida por mim.

Vamos lá! 🙂

O Projeto

Há algum tempo atrás vi uma reportagem que comparava hábitos de leitura dos brasileiros e americanos, e mencionava que em média, nós brasileiros, líamos cerca de 4,7 livros por ano, enquanto nos EUA a média de leitura anual era de 10 livros. Na época, eu com certeza estava abaixo da média brasileira. Embora já tivesse tentado por diversas vezes dedicar um tempo maior a leitura, inclusive tendo comprado diversos livros, ainda não conseguia fazer da leitura um hábito e lia muito pouco. Ao ver essa notícia resolvi que iria mudar esse cenário. 🙂

Estava decidido a ler mais, mas sabia que isso seria difícil. Das outras vezes que tentei mudar isso apenas consegui me dedicar por um período curto, e logo em seguida deixava esse objetivo de lado. Ao pensar isso surgiu a primeira preocupação:

Como me manter motivado?

Nesse momento pensei no Scrum pois era o que estava estudando na época e percebi que as técnicas usadas lá poderiam me ajudar muito.

Definindo uma meta mensurável

A primeira coisa que fiz foi me comprometer com uma meta.

Escolhi uma meta que seria desafiadora, mas ao mesmo tempo factível. Decidi que naquele ano leria 12 livros.

Usando Sprints

Ao ter essa meta definida percebi que a próxima coisa a ser feita era quebrar meu projeto em ciclos de trabalho. Nas metodologias ágeis, um projeto de anos é quebrado em ciclos que tem normalmente de 2 a 4 semanas. Estes ciclos são chamados de Sprints.

Minha dedicação a esse projeto seria basicamente nos fins de semana, pois na semana tinha aula e por isso achei melhor usar Sprints de 4 semanas. Ao definir esse tamanho teria um bom volume de trabalho por Sprint e ao mesmo tempo teria 13 ciclos de trabalho ao longo do projeto. Com isso, caso conseguisse manter uma média de um livro por ciclo, ainda teria um ciclo sobrando para qualquer eventualidade(na época eu ia pra festinhas e tal né).

Mantendo-se Motivado

O uso de Sprints implica em definir resultados/objetivos de curto prazo que contribuam para atingir o objetivo final do projeto. Ao final de cada Sprint estes resultados, bem como o andamento da Sprint, devem ser avaliados e em seguida deve-se planejar a próxima Sprint. As avaliações dos resultados, do andamento e o planejamento são realizados em reuniões, chamadas respectivamente de revisão, retrospectiva e planejamento, sendo que normalmente o planejamento é dividido em duas etapas. Porém, gostaria de destacar que embora estivesse em uma Eu-equipe (equipe de 1) vi que esses momentos eram importantes, pois seriam essenciais para eu conseguir aprender com o processo e não perder o foco e a motivação.

Com base nesses objetivos de curto prazo, não deixaria para avaliar se estava perto de alcançar minha meta apenas no final do ano. A cada 4 semanas avaliava como estava me saindo: quantos capítulos tinha lido, se estava tendo um bom ritmo de leitura, se o horário que tinha separado para leitura era adequado, enfim, assim como no Scrum, avaliava quais as dificuldades encontradas, o que poderia ser melhorado ou alterado para não prejudicar outros pontos da minha vida, como por exemplo, meus períodos de lazer(festinhas), atividades físicas e períodos de descanso.

Usando as Sprints, a cada 4 semana via que poderia atingir minha meta e que iria fazer isso de maneira natural, sem precisar ficar enfurnado em casa, ou deixando de lado minhas outras atividades. Isso foi fundamental para me manter motivado. A cada fim de Sprint era muito gratificante ter a sensação de dever cumprido, o que com certeza é um fator motivador em todo tipo de projeto. Além disso, ao acabar um ciclo e começar um novo sentia minhas energias renovadas e certamente esse foi um dos fatores mais importantes que me levaram a conseguir cumprir meu objetivo.

Neste momento gostaria de deixar a seguinte mensagem:

Sempre que tiver um novo projeto ou desafio pela frente, pense em como ele pode ser quebrado em metas de curto prazo. Feito isso, decida qual a próxima meta a ser alcançada, assim você conseguirá estar sempre motivado, pois a cada passo verá que está na direção certa e que vai atingir seu objetivo.

Reunião de Revisão

No Scrum, após terminado um ciclo de desenvolvimento é realizada a reunião de revisão, onde a equipe apresenta para o cliente o que foi desenvolvido durante a Sprint. Neste momento, o cliente avalia se o objetivo da Sprint foi alcançado.

Nos nossos projetos pessoais somos nosso próprio cliente e temos que ser capazes de nos auto avaliar da maneira mais imparcial possível. Ser imparcial nos leva a uma preocupação imediata: Como ter certeza que não estou me cobrando de mais ou de menos?”

Para lidar com isso, tentei ser o mais objetivo possível. No início da Sprint me comprometia com um objetivo claro e bem definido. Esse objetivo era por exemplo: ler ou terminar de ler um determinado livro; chegar até certa página do próximo livro, etc.

Com uma meta clara e bem definida fica muito fácil fazer essa avaliação. Ou você cumpriu ou não cumpriu, é algo simples e direto! Quanto mais transparente for a meta definida, mais fácil será avaliar o resultado da Sprint.

Enquanto o uso de Sprints te motiva por renovar as energias a cada ciclo, a reunião de revisão é o momento onde você tem, de fato, a sensação de dever cumprido e pode se sentir realizado e tranquilo por saber que está caminhando no rumo certo. Mas, se por acaso em alguma Sprint a meta não foi realizada 100%, fique tranquilo. A reunião de retrospectiva vai te ajudar a lidar com isso.

Reunião de Retrospectiva

O último ponto de uma Sprint é a reunião de retrospectiva. Nessa reunião são levantados todos os pontos positivos e negativos da Sprint. Deve-se refletir sobre tudo que ajudou ou atrapalhou a meta ser alcançada. Essa é uma reunião fundamental no Scrum, pois ela gera o aprendizado necessário para que seus ciclos de trabalhos sejam aperfeiçoados continuamente. É o momento de descobrir onde se está errando e o que pode ser melhorado.

No caso do meu projeto pessoal, o uso de Sprints de 4 semana e o fato de estar em uma Eu-equipe (equipe de 1) dificultava que lembrasse de tudo sempre e por isso passei a anotar ao longo da Sprint tudo o que acontecia. Mesmo que não parasse para pensar sobre aquilo de imediato, isso facilitava minha retrospectiva.

Em uma determinada retrospectiva notei que o que mais impactava minha Sprint eram eventos (provas, aniversário, festas) e também a empatia com um determinado livro.

Para lidar com esses eventos, percebi que antes de iniciar uma nova Sprint deveria olhar quais os compromissos que já tinha programado para aquele período. Me organizar melhor dentro da Sprint me permitiu manter o mesmo ritmo de leitura em todas as Sprints e com isso consegui alcançar meu objetivo sem precisar sobrecarregar nenhum dos períodos.

No caso da empatia, havia um problema: O Scrum prega que não se deve mexer no escopo da Sprint atual, pois isso pode atrapalhar todo o planejamento e prejudicar a entrega. Porém, após refletir por 2 ou 3 Sprints, passei a me permitir trocar o livro que havia me comprometido a ler. Essa decisão deu um ótimo resultado, mas só foi tomada porque percebi que poderia reformular o que estava definindo como meta da Sprint. Ao invés de me comprometer com um livro específico, passei a me comprometer com um número de páginas ou capítulos. Isso me permitiu ler livros em paralelo e sempre que um livro era de difícil leitura, incluía outro que me permitisse alcançar minha meta, tanto da Sprint quanto do projeto.

Embora essas medidas sejam a respeito da Sprint, percebi que para garantir o efeito desejado era importante adotar as reuniões diárias.

Reuniões Diárias

No Scrum, a reunião diária é o momento onde cada membro da equipe relata o que fez, o que pretende fazer e quais impedimentos encontrou desde a reunião anterior. Essa reunião deve ser rápida, mas ao trabalhar em equipe, ela é fundamental para que todos tenham conhecimento do andamento da Sprint e analisem se alguma medida se faz necessária.

No meu caso, inicialmente achei que não precisaria fazer essas reuniões, afinal de contas, eu era o único integrante da equipe. 🙂

Porém, depois de algumas reuniões de retrospectiva percebi que lia pouco no início da Sprint e quando estava perto do fim desse ciclo fazia um esforço enorme para cumprir o prometido. Embora conseguisse entregar a meta estabelecida para cada Sprint, essa forma de trabalhar não fazia da leitura um hábito agradável, o que era uma das minhas preocupações iniciais quando comecei esse projeto.

Sendo assim, mesmo estando sozinho, resolvi separar um momento para essas reuniões. No meu caso, minha dedicação era basicamente aos fins de semana, então elas não seriam bem “Reuniões Diárias” mas teriam o mesmo papel.

Elas foram fundamentais, por exemplo, para lidar com compromissos que as vezes surgiam nos fins de semana que atrapalhavam meu planejamento inicial (Festaaas, eeehh 🙂). Nesses casos, mesmo que eu não tivesse tempo para ler no dia previsto, parava para decidir em qual momento iria repor aquele dia perdido. Muitas vezes, separava algumas horinhas em um dia ou outro durante a semana e assim ficava acumulando todo o atraso para a última semana da Sprint.

Estar atento ao andamento ao longo de toda a Sprint é fundamental para manter um ritmo de trabalho equilibrado. Isso pode parecer algo simples, e de fato é, mas ter um ritmo constante e controlado é muito importante para manter o animo e motivação da equipe. No meu caso, percebi que as reuniões diárias foram além e melhoraram minha satisfação com o projeto.

Antes de continuar com a reunião de planejamento, acho melhor falar um pouco sobre os papéis do Scrum.

Como Ficam os Papéis do Scrum em Projetos Pessoais?

No Scrum há 3 papéis a serem desempenhados: Scrum Master, Equipe de desenvolvimento e Product Owner (P.O.).

Como o próprio nome já diz, o P.O. é o dono do produto. Ele quem faz a ponte entre cliente e desenvolvedores. É função dele entender o que o cliente quer e com base nisso definir o que vai ser feito, quando será feito e quando será entregue.

O Scrum Master é o responsável por manter a casa em ordem. Ele que organiza as reuniões, remove obstáculos, garante que o processo corra bem, e atua junto a equipe para mantê-la motivada e produtiva.

Já a equipe de desenvolvimento, além de, é claro, ser responsável pela implementação do produto, deve ser auto-organizada e tem autonomia para decidir como o trabalho será feito.

O Scrum recomenda que os papéis não sejam acumulados por uma mesma pessoa, porém no caso do meu projeto pessoal tive que acumular não só esses 3 papéis, como também o papel do cliente.

De início, achei que seria tranquilo lidar com essa situação, até porque isso facilitaria muito para marcar reuniões 😝, mas brincadeiras a parte, aos poucos fui percebendo que era preciso tomar alguns cuidados.

Cada um desses papéis tem uma função bem definida e sobretudo uma forma de pensar e de ver o problema. Com isso, ao acumular papéis é muito importante conseguir analisar a situação pelo ponto de vista de cada um deles.

No caso do meu projeto pessoal, por duas Sprints consecutivas não consegui entregar o planejado (ler um livro por Sprint) e percebi que era preciso realizar algumas mudanças… Para não ir contra alguns princípios do Scrum, precisei analisar a situação pelo ponto de vista de cada um desses papéis.

Do ponto de vista da equipe, percebi que havia um grave problema de motivação e uma dificuldade em superar obstáculos. Como Scrum Master, percebi que tínhamos uma meta muito rígida e que para pensar em mudanças precisava do P.O e provavelmente do Cliente. Como P.O. sabia que qualquer mudança na meta deveria continuar garantindo a entrega de um determinado volume de leitura periodicamente. Por fim, como cliente, percebi que essa meta poderia ser modificada, contando que o equivalente a um livro fosse lido em cada Sprint.

Com essa nova definição do escopo definida pelo cliente, agindo novamente no papel do P.O. percebi que caso as metas das Sprints fossem capítulos, poderia “entregar” capítulos de livros diferentes, desde que nunca entregasse capítulos de um mesmo livro fora de ordem. Como Scrum Master me comprometi a avaliar essa mudança no dia-a-dia da equipe, de modo a ter certeza que isso havia resolvido o problema. Por fim, como equipe e Scrum Master decidi evitar colocar mais de um capitulo de um livro novo em uma Sprint, de modo a poder conhecer um pouco de cada livro antes de entrar de cabeça nele. Dessa forma evitaria comprometer a Sprint com o livro que poderia ser de difícil leitura, e seria mais fácil prever quantos capítulos de cada livro conseguiria ler na Sprint seguinte.

Se fossemos analisar cada etapa dessa situação com a ótica de cada papel em uma equipe real e sem sobreposição de papeis, podemos exemplificar a situação com os seguintes acontecimentos:

1. Na reunião de revisão o P.O reclama que a equipe não está conseguindo entregar o prometido.
2. Na reunião de retrospectiva o Scrum Master e a equipe tentam entender porque o trabalho não está evoluindo bem e percebem que a falta de empatia com um livro é um impedimento para a leitura.
3. Ao levar essa questão para o P.O., esse conversa com o cliente para entender porque é importante que seja lido um livro por Sprint .
4. O cliente reporta que o objetivo do projeto é aumentar o ritmo de leitura e que deseja ter o equivalente a 12 livros lidos em 1 ano.
5. O P.O. percebe que essa meta fixa de 1 livro por Sprint pode ser modificada, e sugere ao cliente que a meta seja uma quantidade de capítulos equivalente a um livro.
6. Após o cliente aceitar, o P.O. passa então a priorizar capítulos ou partes de livros a serem lidos.
7. Uma vez priorizado os capítulos, a equipe, Scrum Master e P.O. planejam juntos quais capítulos de quais livros devem entrar na Sprint, obedecendo a regra de nunca entregar capítulos de um mesmo livro fora de ordem.
8. Scrum Master se compromete a acompanhar e avaliar a eficiência dessas mudanças.
9. Scrum Master e Equipe alertam ao P.O. que é melhor evitar colocar muitos capítulos de um livro novo na Sprint.
10. Scrum Master e Equipe definem que caso volte a ocorrer o problema de empatia com um determinado capítulo, a equipe tem agora liberdade para seguir a leitura com outro capítulo de um livro diferente, que esteja na Sprint ou se necessário incluir o próximo capítulo priorizado na Sprint.

É importante perceber que embora tenham pontos de vistas diferentes e que cada um tenha que defender o seu lado, todos trabalham juntos, buscando soluções e visando que o projeto ocorra da melhor maneira possível.

Reuniões de Planejamento

Continuando sobre a reunião de planejamento, no começo deste artigo, me referi a um planejamento inicial da Sprint, o qual é realizado na Reunião de Planejamento. Esta etapa deve ocorrer logo após as reuniões de retrospectiva e marca o início de uma nova Sprint.

No Scrum a reunião de planejamento costuma ser dividida em duas etapas. Na primeira etapa a equipe de desenvolvimento se reúne com o Scrum Master e PO (Product Owner) para definir o que será feito na Sprint. Feito isso, na segunda etapa do planejamento cabe à equipe definir como isso será feito.

Para definir o que será feito, o PO deve apontar as prioridades e a equipe deve estimar o esforço de cada prioridade. Além disso, esse é o momento de tentar prever como será a dedicação da equipe, reduzindo ao máximo o número de imprevistos e também o momento de definir o objetivo e a meta da Sprint.

Uma vez com as prioridades definidas, os esforços necessários, o objetivo e a meta, todos juntos definem o que vai ser feito na Sprint. Uma Sprint normalmente é composta de várias histórias, que são partes do projeto entregáveis e que agregam valor ao produto final. Quando as histórias são colocadas na Sprint elas obedecem à ordem de prioridade definida pelo PO e devem ser realizadas seguindo essa ordem.

No caso do meu projeto, eu teria que desempenhar todos os papeis do Scrum, ou seja, na hora de planejar uma Sprint teria que conseguir analisar o ponto de vista tanto da equipe, quanto do PO, quanto do Scrum Master. Como PO, ao criar as histórias decidi inicialmente que cada livro seria uma história. Desta forma, a cada Sprint bastaria priorizar qual livro seria lido e pronto, trabalho resolvido. Como equipe, bastaria olhar o número e páginas do livro para estimar o esforço/tempo necessário para ler aquele livro. Tudo bem simples e prático né? É, mas infelizmente logo percebi que desta maneira não estava dando certo.

O fato de ter definido cada livro como uma história fez minhas primeiras Sprints terem uma única história. Na primeira o livro era fácil de ler e foi bem tranquilo. Porém, já na segunda Sprint optei por pegar um livro “mais pesado” e a leitura não estava andando praticamente nada.

Conforme comentei no subtitulo anterior “Como Ficam os Papéis do Scrum em Projetos Pessoais”, quando isso aconteceu, tentei ver o problema segundo o ponto de vista de cada um dos papéis e, no final, percebi que era melhor colocar cada capítulo como sendo uma história. A diferença parece pequena mas, me permitiu colocar na Sprint seguinte apenas o primeiro capítulo de alguns livros e com isso, aprender previamente qual o ritmo de leitura de cada livro.

Esse aprendizado permitiu que na reunião de planejamento seguinte o Eu-Equipe estimasse muito melhor o esforço para ler os outros capítulos. Agora, além do número de páginas poderia estimar o esforço de um capítulo usando a velocidade da leitura dos capítulos já lidos daquele livro.

Com isso, consegui aproveitar mais um dos pontos do Scrum, que é ter uma maior precisão ao estimar o trabalho. Essa maior precisão vem tanto do fato de estar lidando com afazeres menores, agora capítulos e não mais livros inteiros, quanto do fato de poder aprender com algo que já foi feito e usar isso para estimar o esforço de algo muito parecido.

Na segunda etapa do planejamento as histórias normalmente são quebradas em tarefas. A granularidade dessa quebra pode variar, mas de um modo geral as tarefas devem poder ser concluídas em um dia trabalho. Desta forma, ao longo da Sprint, durante as reuniões diárias de acompanhamento os membros da equipe podem facilmente relatar o que foi concluído no dia anterior e o que será feito a seguir.

No caso do meu projeto já havia uma quebra natural dos capítulos dos livros em tópicos ou mesmo páginas e essa etapa foi muito simples de ser realizada. Porém, caso esse não seja o seu caso, é muito importante pensar nessa quebra de tarefas antes de iniciar uma história, pois nessa etapa muitas vezes descobrimos impedimentos importantes que podem indicar que essa história não deve ser colocada nessa Sprint.

Conclusão

Espero que tenham entendido um pouco como aplicar o Scrum em um projeto pessoal, e que tenha lhe sido útil para conhecer um pouco mais do Scrum sem entrar tanto nos termos da área.

Quero deixar aqui também para vocês coisas que aprendi com o Scrum e que o Felipe Franco me lembrou é:

Feito é melhor que perfeito. Coloque seus projetos em prática, não espere pelas condições perfeitas para fazer as coisas acontecerem, pois a gente sempre vai acabar encontrando desculpas para não sairmos do lugar.

Busque sempre melhorias contínuas. Sempre olhe para seus projeto e o que você faz e sempre procure o que pode melhorar, o que pode fazer diferente para que possa elevar a qualidade dos seus projetos.

Seja feliz 😆. Faça sempre o que deixa você melhor, entrar de cabeça em algum projeto ou trabalho em que não gosta geralmente não vai dar os melhores resultados. então faça o que lhe deixa bem e gosta.

E por fim “Não queira abraçar o mundo”. Nos achamos que somos multi-tarefa, mas a ciência já provou que não somos capazes de fazer de processar varias informações ao mesmo tempo. Então faça uma coisa de cada vez, não tente ser o “badass” e fazer tudo ao mesmo tempo, foque-se em um projeto e faça o seu melhor naquele projeto.