Nos anos 1970/80, empresas japonesas implementaram inovadoras técnicas de gestão e planejamento. Em 2001, dezessete desenvolvedores de software, cansados de projetos muito abertos e prazos apertados, reuniram-se para discutir formas de melhorar o desempenho de seus projetos. Nesse mesmo ano, foi lançado o “Manifesto para o Desenvolvimento Ágil de Software”, ou simplesmente Manifesto Ágil, cujos doze princípios podem ser vistos no link. Basicamente, falam sobre completar e apresentar tarefas menores e em menor tempo, com maior cooperação entre desenvolvedores e clientes, o que permite rápidas adaptações.
O Scrum (“ataque” em inglês) é uma estrutura metodológica que é usada para implementar o desenvolvimento Ágil. Seu nome foi inspirado em uma jogada de Rugby, na qual até oito jogadores de cada time reúnem-se ao redor da bola no lugar onde a penalização ocorreu. O objetivo é retirar os obstáculos à frente do jogador que correrá com a bola, para que ele possa avançar o máximo possível no campo e marcar pontos.
No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints (“corrida” em inglês). O Sprint representa um Time Box (“prazo”) dentro do qual um conjunto de atividades deve ser executado. As funcionalidades a serem implementadas no projeto são mantidas em uma lista, conhecida como Product Backlog (“lista de produtos”).
Cada Scrum Team (“equipe” que trabalha no projeto) deve possuir entre 3 e 9 pessoas, sendo que duas delas são o Product Owner (“dono do produto”) e o Scrum Master (“líder do time”). O Product Owner (P.O.) é a pessoa que define os itens que compõem o Product Backlog e define a prioridade de cada um. O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Essas atividades são promovidas na Sprint Planning Meeting (“encontro de planejamento da Sprint”), cujas tarefas do Product Backlog são priorizadas pelo P.O., selecionadas pelo time conforme a velocidade de execução das stories (“tarefas”) e transferidas para o Sprint Backlog.
As stories podem ser escritas em papéis do tipo “Post-It”, com o nome da story, duração e nome do responsável pela sua execução. Eles devem ficar em um mural visível por toda a equipe. Esse sistema é conhecido como Kanban. Criado nos anos 1960 pela Toyota, é parte do sistema Just in Time, que determina que tudo deve ser produzido, transportado ou comprado na hora exata. É comum dividir os “kanbans” em colunas de To do (“a fazer”), In progress (“em execução”), Testing (“em teste”) e Done (“feito”).
Você pode montar um painel com post-it fisicamente ou usar alguma plataforma de gerenciamento estilo kaban. O Trello é uma ferramenta gratuita para esse fim – basta se cadastrar para ter acesso. Pode ser criado um quadro para cada projeto. Dentro, são criadas listas (colunas), onde os cartões contém as tarefas. Você pode convidar outros usuários do Trello para compor o time de um quadro ou cartão. Veja mais informações no Guia de introdução ao Trello. Os quadros podem ser públicos, reservados ao time ou privados – você pode colocar sua lista de compras lá, sem necessariamente compartilhar com todo mundo do seu trabalho! =P
Geralmente no iníco de cada dia de uma Sprint, a equipe faz uma breve reunião, chamada Daily Scrum ou Stand Up Meeting (“encontro de pé”, para forçar a reunião ser rápida). O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting (“reunião de revisão da Sprint”). Finalmente, faz-se uma Sprint Retrospective (“retrospectiva”) e a equipe parte para o planejamento do próximo Sprint. Geralmente, um Sprint demora de 2 a 4 semanas.
O Guia Oficial do Scrum em português pode ser consultado gratuitamente no link.
Cálculo da velocidade
A velocidade de trabalho é calculada como o produto entre a capacidade de produção e o fator de foco. Capacidade de produção é o número de dias do sprint multiplicado pelo número de recursos (pessoas envolvidas, por exemplo). Já o fator de foco é definido como a capacidade de se concentrar. Ele pode ser estimado pela razão entre o número de pontos produzidos e a capacidade de produção do time. Geralmente esse fator fica entre 60% (iniciantes no método) e 80% (equipes mais maduras).
Esse pontos são dados pela dificuldade da tarefa (ou “story”), estimada pela equipe como um valor em uma sequência de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34). Cada participante estima individualmente um valor nessa escala, onde quanto maior o valor, mais difícil a tarefa, e apresenta ao grupo. Quando todos entrarem em consenso quanto a um valor, esse será o número de pontos da tarefa.
Cada story deve ser resolvida em até uma jornada de trabalho diária (geralmente 8 horas); se for muito complexa ou demorada para esse prazo, deve ser quebrada em mais stories. Através de um gráfico do tipo Burndown (o número de atividades vai reduzindo até a finalização do projeto ao longo do tempo), é possível acompanhar o avanço (ou não) do time.
Mais informações no post Calculando o prazo de um projeto Scrum.
Existe um outro “método” de trabalho conhecido como eXtreme Go Horse (XGH). Na verdade, é um anti-método, que serve como sátira aos métodos utilizados no mercado. Infelizmente, muitos ambientes de trabalho atuam dessa forma em vários momentos, então é interessante ler seus pontos como uma auto-crítica.
