Existem muitas vantagens em adotar uma metodologia de desenvolvimento de software como o Scrum, mesmo que você esteja trabalhando sozinho.
Utilizar uma metodologia para dimensionar corretamente suas tarefas do dia a dia pode ser incrivelmente libertador e produtivo.
Continue lendo para ver como utilizar o Scrum em seu fluxo de trabalho de desenvolvimento e como você pode aplicar no desenvolvimento de seus projetos, mesmo trabalhando sozinho.
A Equipe de Um
Quando você começa a trabalhar em uma nova empresa, geralmente há uma metodologia definida de desenvolvimento de softwares no geral. Como frequência de reuniões, como os prazos são tratados e assim por diante. Essa metodologia ajuda a definir se seus projetos serão bem-sucedidos, e se a equipe trabalhará otimizada e feliz.
Para desenvolvedores independentes ou freelancers, é um pouco diferente.
Talvez você esteja considerando ou até trabalhando como desenvolvedor independente neste momento. Basicamente a equipe é você em uma sala com seu computador e algumas idéias ou projetos. Não existe uma metodologia para seguir.
Tudo depende de você! A que horas vai começar a trabalhar, em quais aplicativos vai se concentrar, como organizar tarefas e etc. A liberdade que você tem para tomar decisões pode ser legal, mas ao mesmo tempo um pouco esmagadora.
A programação é apenas uma das muitas responsabilidades e, indiscutivelmente, nem mesmo a mais importante.
Os cronogramas começam a estourar e os projetos ficar em atraso.
Você pode ter ótimas ideias e clientes, mas também precisa ter um ótimo processo de desenvolvimento.
É importante ter um processo para tornar mais produtivo, aumentar os lucros e te deixar feliz com sua carreira independente.
Introdução ao Scrum
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.
Um time Scrum normalmente consiste em cerca de sete pessoas que trabalham juntas em iterações curtas e sustentáveis chamadas Sprints, com bastante tempo para revisão e reflexão. Um dos mantras do Scrum é “inspecionar e adaptar”, e as equipes Scrum são caracterizadas por um foco intenso de melhoria contínua de seu processo, mas também do produto.
Como uma equipe de uma pessoa é tão diferente da equipe normal, não são as características do Scrum de “equipe” que abordarei neste artigo, mas sim os princípios-chave que definem todo o processo. São esses princípios que formam a espinha dorsal do Scrum de uma pessoa.
Aqui estão os princípios fundamentais do Scrum:
Envie e compartilhe
Coloque seu produto nas mãos de outras pessoas regularmente, seja usuários finais, testadores ou até mesmo alguns amigos.
Por quê? Porque, se você não o fizer, poderá perder seu tempo em um recurso ou produto que ninguém deseja.
Pode ser muito fácil perder a perspectiva sobre a importância de certas tarefas, especialmente com uma operação de uma pessoa. Compartilhar uma versão Beta com seus testadores pode ser um processo tão rápido e, no entanto, o tempo economizado pode ser enorme!
Priorize a produtividade
Sua métrica de curto prazo mais importante é a produtividade. Não vendas, não número de funcionalidades, apenas pura produtividade.
Quanto trabalho valioso você está fazendo a cada semana? Para responder a essa pergunta, você realmente precisa quantificar seu progresso. Você verá como rastrear e otimizar seu progresso usando os pontos de tarefas.
Auto-reflexão e interação
Você vai precisar ter uma boa autocrítica para poder melhorar sua produtividade, renda e felicidade. Isso envolve olhar atentamente para si mesmo, seu processo e seus planos regularmente.
À medida que você avalia como está fazendo as coisas, fica muito mais fácil começar a testar outras abordagens e ver os efeitos em tempo real.
Como aplicar o Scrum
Agora que abordamos os princípios do Scrum, priorizando a produtividade e a reflexão/iteração, é hora de entrar nos detalhes. Como você pode usar essa técnica para gerenciar sua operação de uma pessoa?
Nós vamos ver uma variante do Scrum de uma pessoa que criei para o meu próprio trabalho. Eu adaptei muito do tradicional Scrum, então não há necessidade de especialização na metodologia.
O Sprint
Sprint é um período de tempo dedicado a um objetivo bem definido, como adicionar um novo recurso ao seu aplicativo ou resolver um conjunto de bugs complexos. Praticamente tudo o que você faz no Sprint deve ser profundamente focado em tornar essa meta (ou conjunto de metas) uma realidade.
Um Sprint é geralmente entre uma e quatro semanas, dependendo do seu estilo e do produto em si. Eu uso Sprints de uma á duas semanas e acho que é perfeito: tempo suficiente para realizar um conjunto significativo de tarefas, sem dar muito tempo e me deixar levar por tarefas sem importância.
Como você pode ver, um Sprint é feito de muito foco nas suas tarefas principais, além de um alguns eventos: a Reunião Diária (Daily) toda manhã; o semanário História; e, em seguida, a Entrega, Retrospectiva e Planejamento no final. Você pode ler sobre cada um deles em detalhes abaixo.
A Reunião Diária (Daily Scrum) de 5 minutos
Um dos elementos fundamentais do Scrum é a constante auto-reflexão e interação, especialmente quando se trata de produtividade. Então, quando você planeja concluir uma tarefa um dia, mas isso não acontece, você usa isso como uma oportunidade para descobrir o que deu errado e melhorar seu processo. O Daily Scrum ajuda a fazer isso acontecer.
A Reunião Diária ou Daily Scrum é a marca registrada do método Scrum. Tradicionalmente, é quando os membros da equipe compartilham o progresso do dia anterior, os planos de hoje e qualquer coisa que esteja bloqueando sua produtividade. A reunião é curta para evitar que o temido inchaço da reunião.
Na melhor das hipóteses, um bom scrum coloca todos na mesma página, traz desafios para a luz – obtendo ajuda dos membros da equipe – enquanto ajuda a equipe a crescer.
Então, como isso pode funcionar para uma pessoa?
Aqui é onde você pode usar um pouco de tecnologia para sua vantagem. Sua reunião individual torna-se um pequeno vídeo (ou texto) que você grava todas as manhãs de aproximadamente 45 segundos.
Veja como você faz isso:
- Revisão: Comece assistindo o vídeo anterior, prestando atenção ao que você disse que faria.
- Refletir: Não alcançou o objetivo de ontem? Tudo bem, é para isso que o Scrum serve. Pense em por que isso não aconteceu e o que você poderia ter feito melhor. Talvez você tenha marcado uma reunião no meio da tarde que atrapalhou seu fluxo de programação para o resto do dia. Ou talvez você estivesse preparando screenshots manualmente para a App Store, e demorou muito mais do que o esperado.
- Ensaie: Por não mais que um ou dois minutos, ensaie o vídeo de hoje. Algumas respostas sobre cada pergunta: o que você fez ontem, o que vai fazer hoje, o que está bloqueando você.
- Registro: Grave o vídeo no seu celular e pronto! Isso será particularmente útil na Retrospectiva.
História (Story Time) de 30-45 minutos
Em cada Sprint, você passará a maior parte do tempo como desenvolvedor, corrigindo bugs, adicionando novos recursos e assim por diante. Em vez de dedicar muito tempo a pensar em coisas grandes, como criar um novo aplicativo ou atualizar o atual.
A História ou Story Time é quando você coloca seu chapéu de CEO e começa a pensar em uma visão geral. Para esta parte do Sprint, eu gosto de sair do meu ambiente de trabalho normal e ir a um café ou até mesmo trabalhar em uma área diferente da minha casa.
Durante o Story Time, analisarei o feedback dos usuários, faço um brainstorming dos recursos do aplicativo que gostaria de adicionar. Este é também o momento em que vou pensar em novos aplicativos ou abandonar os antigos. Então, irei apresentar algumas ideias concretas e adicioná-las a uma lista especial chamada Product Backlog.
O Product Backlog é uma lista ordenada de tarefas gerais. Este será o primeiro lugar que você verá ao decidir sua meta para o próximo Sprint. Mas tão importante quanto adicionar novas tarefas ao seu backlog, o Story Time é sobre revisar e reorganizar o que já está lá.
Entrega (Sprint Release)
Um princípio fundamental do Scrum é colocar seu trabalho no mundo. Não precisa ser um lançamento do aplicativo completo, mas é muito importante que você pegue o feedback de outras pessoas, especialmente do seus clientes!
Pode ser uma nova versão para os testadores, um conjunto de wireframes para um novo Designer ou até mesmo uma pequena atualização para alguns testadores.
O escopo do seu lançamento provavelmente mudará durante o seu Sprint, especialmente no começo. Por exemplo, talvez você acabe lançando uma versão Beta com apenas dois dos três recursos planejados. Isso está ok. Ao reduzir o escopo à medida que você se aproxima da data de lançamento, você prioriza os recursos mais importantes sem atrasar o feedback valioso do testador.
Se os seus testadores nem sequer comentarem sobre a funcionalidade em falta, talvez não tenha sido tão importante. Se o fizerem, então você tem uma ideia clara do que priorizar em seu próximo Sprint!
Último dia do Sprint
Você passou nove dias trabalhando em sua meta de Sprint e agora chegou a hora do último dia. A boa notícia é que esse é fácil.
Este é um dia para fazer uma retrospectiva, limpar a lousa, planejar seu próximo Sprint e depois fazer algo divertido.
No começo, isso parece uma coisa muito estranha para passar um dia, especialmente se você está se afogando em prazos.
Certificar-se de que você está no caminho certo é o último dia do seu Sprint. É um único dia a cada duas semanas, quando você levanta a cabeça, olha em volta e faz as correções necessárias. Porque mesmo se você estiver sendo super produtivo, essa produtividade não valerá muito se estiver sendo desperdiçada na tarefa errada.
Agora, vamos pular para as três tarefas principais do dia.
Retrospectiva de aproximadamente 2 horas
Abra um novo documento de texto ou abra uma nova página no bloco de notas e comece a escrever suas impressões sobre a produtividade das duas últimas semanas. Aqui está sua oportunidade de descobrir o que está impedindo você de se tornar ainda mais produtivo e feliz.
Algumas perguntas de exemplo para você começar:
- O que você realizou?
- Você cunpriu seu objetivo de Sprint?
- O que funcionou muito bem nesse Sprint? O que poderia ter funcionado melhor?
- Existe alguma coisa que desnecessariamente estressou você, ou que você realmente gostou?
Se você achar que uma caminhada é melhor para refletir do que sentar em uma mesa, vá dar uma volta e simplesmente digite um breve resumo depois. Eu também acho que fazer isso fora do meu ambiente de trabalho usual é útil também.
Às vezes, um passeio é exatamente o que você precisa para uma boa Retrospectiva.
Finalmente, com base em suas reflexões, escolha duas coisas simples para melhorar em seu próximo Sprint:
- Uma coisa para tornar você mais produtivo.
- Uma coisa para te fazer mais feliz.
Planejamento (Sprint Plan) de aproximadamente 2 horas
Entre a Retrospectiva, os dois Story Times e o seu Product Backlog, você deve ter uma boa ideia do que trabalhar no seu próximo Sprint. Basta analisar o backlog bem e escolher os melhores itens!
O estágio de Planejamento da Sprint é quando você anota as metas, as tarefas e atribui algo chamado Pontos de Tarefa.
Aqui está um exemplo simples. Digamos que você tenha um aplicativo quase concluído, e seu próximo Sprint será para adicionar um recurso final, fazer alguns testes internos e, em seguida, disponibilizar uma versão Beta para o feedback do usuário. Em seu documento do Plano de Sprint, exponha algo como o seguinte:
- Adicionar Recurso X
- Design da tela – 3 pontos
- Atualizar interface – 2 pontos
- Adicionar recurso no código – 8 pontos
- Realizar testes – 2 pontos
- Finalizar o Aplicativo
- Revisar o cheklist de testes – 1 pontos
- Testar nos emuladores Android – 2 pontos
- Testar em um dispositivo real – 2 pontos
- Corrigir bugs – 5 pontos
- Entrega
- Publicar aplicativo em beta – 2 pontos
- Solicitar testes de clientes/usuarios – 3 pontos
Um Sprint de duas semanas, você provavelmente terá muito mais tarefas aqui! Mas é suficiente para ilustrar.
Veja esses números ao lado de cada tarefa. São chamados de pontos de tarefa. Eles não representam horas ou qualquer coisa mensurável, são completamente abstratos. Tudo o que importa é a consistência.
Por exemplo, uma tarefa de um ponto deve levar cerca de metade do tempo de uma tarefa de dois pontos (em média). Use o que quiser para sua própria escala. Pessoalmente, gosto de usar os números 1,2,3,5,8 que têm uma maneira de corrigir nossa tendência humana de subestimar tarefas maiores. Por exemplo, como não há 4, preciso arredondar para 5.
Ao planejar as tarefas de seu sprint, pense em quanto tempo cada uma levará em relação às outras. Dê uma olhada fria e calculista em cada tarefa e faça uma previsão razoável de quanto tempo levará para concluir.
Se uma tarefa for complicada, mas você tiver feito essa tarefa um milhão de vezes, ela será um pouco mais rápida e você poderá reduzir os pontos. Se uma tarefa for simples, mas você não estiver familiarizado com ela, levará mais tempo e você deverá aumentar os pontos alocados para essa tarefa.
Quando terminar, basta adicionar todos os pontos de tarefa e comparar a soma com o que você conseguiu nos últimos Sprints. Por exemplo, se você costuma passar de 80 a 100 pontos de tarefa em um Sprint, certifique-se de que esse próximo Sprint tenha cerca de 80.
Esta é uma das partes mais eficazes do Scrum, na minha experiência e a mais difícil. Muitas vezes, é nesse momento que me vejo cortando tarefas que quero fazer em favor de tarefas importantes. Isso me faz pensar mais como um CEO do que como um desenvolvedor.
Organizando o Quadro de Tarefas (Task Board)
Hora de se afastar do Sprint por um momento e falar sobre o Quadro de Tarefas. Minha organização de tarefas do dia-a-dia ocorre neste Quadro de Tarefas usando o Trello.
O quadro pode ter alguns elementos diferentes, mas a parte mais importante começa com esses três colunas: TODO, DOING e DONE.
No final de cada dia, escrevo as tarefas do dia seguinte na coluna TODO. Digamos que, em média, eu passei por 10 pontos de tarefas diárias nos últimos dois Sprints. Eu coloquei cerca de 10 pontos de tarefas para o dia seguinte.
Na manhã seguinte, vou até o Quadro de Tarefas e mudo minha primeira tarefa do dia, de TODO para DOING. Como a maior parte do dia é normalmente passada na frente de um computador, esse simples ato parece especialmente intencional, o que realmente me ajuda a focar.
Então, quando a tarefa estiver concluída, movo para DONE. Conforme a Sprint avança, a seção DONE se enche.
Descanso & Diversão
De volta ao Sprint. Agora você está entrando na última sexta-feira à tarde do Sprint. Termine o dia com algo divertido! Este é o momento em que eu levo meu laptop para o sofá e trabalho ou estudo algo divertido.
Não escolha algo que pareça uma tarefa. Faça algo pouco relacionado ao trabalho que você gosta.
Pegue uma bebida, ligue alguma música e comemore um Sprint bem feito!
Conclusão
Escolher a estrutura de trabalho certa como desenvolvedor independente e ou freelancer é algo muito pessoal. Precisa enfatizar seus pontos fortes, motivá-lo e estimular o crescimento constante.
Com isso em mente, você pode descobrir que certos elementos da minha variante de uma pessoa do Scrum funcionam para você, enquanto outros não. Sinta-se à vontade para adaptar as práticas diárias às suas necessidades e estilo.
Algumas dicas:
- Não se sinta mal se você terminar menos tarefas do que planejou em seus Sprints iniciais. Basta ajustar suas estimativas e carga de tarefas para o próximo.
- Revise seu Planejamento de Sprint todos os dias. Revise cada tarefa e ajuste os pontos de tarefa. Se a contagem total começar a ficar muito alta, você deverá remover algumas tarefas de prioridade mais baixa para compensar.
- É difícil planejar detalhes. Se você estiver usando Sprints de duas semanas, tudo bem se os planos de sua tarefa para a segunda semana forem um pouco menos detalhados. Seus ajustes diários preencherão esses detalhes à medida que a segunda semana se aproximar.
- É ótimo ter planos de longo prazo para seu projeto, mas não se atenha a eles cegamente. É melhor ter um ótimo Product Backlog que esteja vivo, sempre mudando e sempre se adaptando a novas evidências.
Quando percebi pela primeira vez que precisava de uma estrutura de trabalho melhor como um freelancer, tudo se resumia a três coisas: mais produtividade, mais receita com meus próprios aplicativos e mais felicidade.
Você tem alguma dica para compartilhar?
Ou, se você é um especialista em Scrum e tem algumas dicas para nos ajudar seria ótimo ouvir sua opinião também.