SCRUM - Uma abordagem prática

Metodologias Ágeis vem ganhando um espaço mais do que merecido no meio da comunidade, e vem sendo adotado de forma acelerada por grandes empresas, como Microsoft, Xerox, IBM, etc..
As vezes seguir a risca metodologias como RUP nem sempre é a melhor opção para as empresas que possuem um tempo escasso para entregar o software com qualidade em prazos cada vez mais curtos, foi quando nos dias 11 a 13 de Fevereiro de 2001, caras como Martin Fowler, Kent Beck, Alistair Cockburn, Ward Cunningham e Ken Schwaber se reuniram em resort de ski em Snowbird (Utah) para mudar o rumo do desenvolvimento de software, foi nesta reunião que nasceu o XP, Scrum, DSDM, Crystal, FDD, e outras metodologias que visam "desburocratizar" o desenvolvimento de software, entre as metologias propostas esta o Scrum idealizado por Ken Schwaben, que vem ganhando cada vez mais adeptos.
Esse post é um tutorial prático de SCRUM, para que se interessarem no assunto recomendo o livro Agile Project Management with Scrum de Ken Schwaben
OBS> Esse tutorial é fortemente baseado no documento pdf Scrum And Xp From The Trenches e no livro Agile Project Management with Scrum de Ken Schwaben.

O que é Scrum ? SCRUM é uma metodologia (ou Framework de acordo com o criador Ken Schwaber) onde a espinha dorsal é que chamamos de Sprint. Que nada mais é do uma lista de objetivos ou requisitos bem definidos cujo time de desenvolvimento irá trabalhar focado em um período de 30 dias.

Papéis no Scrum ?

No Scrum existem 3 papéis que devem estar bem definidos, que são:

Product Owner	Scrum Master	Scrum Team
É o "cliente" focal, responsável por reunir todas as mudanças planejadas para o produto e priorizar as funcionalidades possíveis. Administra o Backlog do Produto e assegura que o Scrum Team esta trabalhando com as tarefas certas na perspectiva do negócio.	O Scrum Master lidera o time de desenvolvimento, resolve possíveis impedimentos e trabalha para assegurar que o time possui a ferramentas e condições necessárias para alcançar os objetivos estabelecidos pelo Sprint. Realiza reuniões diárias “Daily Scrum” com o Scrum Team para o acompanhamento das atividades.	São os membros que formam o time de desenvolvedores, designers, consiste de 5 a 9 pessoas. Interagem com o Product Owner para determinar o objetivo do Sprint e priorizar as funcionalidades, e quebrar o Sprint em tarefas detalhadas. O time é auto organizável e tem a responsabilidade conjunta pelos resultados.

	O Product Owner é responsável por compilar todas as requisições e especificações no documento chamado Product Backlog, essas mudanças são referentes ao produto, como novas funções e correções de bugs. As prioridades devem ser feitas durante a criação de cada tarefa.
	Em um período de 30 dias, é feito uma reunião que será definido o Sprint Backlog de acordo com os itens do product backlog levantado pelo Product Owner, ou seja, de acordo com os itens de maior prioridade é criado o Sprint Backlog que a equipe terá a responsabilidade de terminar até o próximo Sprint.
	Uma vez com o Sprint definido, o Scrum Master diariamente faz o “Daily Scrum”, que é uma reunião com o Scrum Team cujo propósito é eliminar qualquer impedimento. Cada integrante deve responder a 3 perguntas: 1º O que você fez desde a ultima reunião ? 2º O que você vai fazer entre esse e a próxima reunião ? 3º Tem algo impedindo você de efetuar a sua tarefa ?

Qual é o critério para decidir a história que será incluída no Sprint ?

* Base da conversa

* Cálculo de Velocidade
Base da conversa, é ideal quando a equipe não possui histórico de sprints, ou seja, para equipes que nunca trabalharam com Scrum e não possuem dados estátiscos para realizar o calculo de velocidade.
A conversa gira em torno dos desenvolvedores, onde o Scrum Master pergunta para cada membro do time quanto tempo uma atividade do Backlog demora para ser desenvolvida (em horas), e com base nisso as horas necessárias para o projeto.
Quando já passou por alguns ciclos com Sprints, é utilizado o Cálculo de Velocidade é uma medida em cima do “total do trabalho feito”, onde cada item recebe um peso de acordo com a sua estimativa inicial.

.

Como estimar a velocidade ?
Resp: A maneira mais simples de estimar a velocidade é verificar o histórico do time. Qual foi a velocidade do time nos últimos Sprints ? Então assumir que a velocidade será a mesma para o último Sprint, mas isso só funciona se o time já tive feito alguns Sprints antes.
Outra maneira de calcular é através de cálculo de recurso. Por exemplo, vamos assumir que estamos planejando um Sprint de 3 semanas (15 dias) com um time de 4 pessoas. O recurso João ficará dois dias de folga, Zezinho apenas 50%, colocando tudo isso no papel ficará:

Recursos	Disponibilidade em dias
Zezinho	7	Esta não é ainda nossa estimativa de velocidade, a nossa unidade de estimativa são os pontos de estória, que no nosso caso corresponde ao “dias de recurso ideal”.
Wagner	15
João	13
Trainee	15
Total	50 Dias de Recurso disponível para este Sprint

Estimamos que a velocidade estimada será menor que 50. Mas quanto menos ? Utilizamos o termo “Fator Foco” para isso:
Fórmula para velocidade estimada do Sprint:
(Dias de Recurso Disponível) * (Fator Foco) = (Velocidade Estimada)
Fator Foco é uma estimativa de como o time esta focado no Projeto. Um fator foco baixo significa que o time espera encontrar vários inconvenientes. A melhor maneira de determinar um Fator Foco concreto é analisando o ultimo Sprint, ou melhor, a média dos últimos Sprints.
Fator Foco do último Sprint:
(Fator Foco) = (Velocidade Atual) .
(Dias de Recurso Disponível)
Velocidade atual é a soma da estimativa inicial de todas as estórias que foram finalizadas no Sprint anterior. Por exemplo, no ultimo Sprint complemos 18 pontos em um time de 3 pessoas, trabalhando por 3 semanas para um total de 45 Dias de Recurso. Vamos calcular o novo Sprint baseado nestes dados, para complicar imagine que chegou mais um recurso (Trainee), que totalizando dá 50 Dias de Recurso com treinamentos, feriados, etc...

Fator Foco do último Sprint:	(40%) =(18 Pontos de estória) (45 Dias de Recurso)
Velocidade Estimada Sprint:	(50 Dias de Recurso) * (40%) = (20 Pontos estória)

Desta maneira a velocidade estimada para o próximo Sprint é de 20 pontos de estória. Isso significa que o time deve adicionar estórias para o Sprint até o mesmo chegar perto de 20 pontos.

Index Cards: O que são ?
As reuniões de planejamento são gastas lidando com estórias do Product Backlog. Fazendo estimativas, priorizando-os, discutindo-os.
Scrum propõe uma maneira muito mais ágil de expor os problemas que serão discutidos que são os Index Cards. Na verdade para cada item do backlog é criado um cartão e estes cartões são expostos em um mural.
EX:

** Estas informações serão as mesmas do Product Backlog que podem ser armazenadas em arquivo Excel

Os cartões deverão conter as seguintes informações **: ID: Identificador único Nome: Descrição curta da estória. Importância: Grau de importância da estória. Ex: 10–50. Alto: Mais importante. Estimativa inicial: Estimativa do time de quanto trabalho é preciso, a medida é feita por pontos de estória que corresponde a “Dias de Recurso” Demonstração:Uma descrição de alto nível de como será feito a demo do Sprint. Observação: Outras informações...

Quebrando estórias em tarefas:
A diferença entre estórias e tarefas, é que estórias são as funções que o Product Owner solicitou e que espera que elas sejam entregues.
Desmembramos as estórias em tarefas unitárias de modo a distribuir as atividades do desenvolvimento da estória para toda a equipe.
Ex:

No nosso exemplo o quadro branco (consulta de clientes) seria a estória (item de Sprint) e os post its amarelos as tarefas deste item de backlog.

Gráfico Burndown de acompanhamento diário.

Na linha vertical, colocamos a quantidade de pontos de estória, que é a quantidade de trabalho que deve ser feito para este Sprint através do cálculo de velocidade por atividade, é a velocidade estimada de todo o Sprint. Na linha horizontal, marcamos o primeiro dia do Sprint, nor exemplo 1º de Augusto, e esperamos terminar este Sprint no dia 19 de Junho, a linha tracejada indica a estimativa de trabalho. A linha azul indica o trabalho realizado, no exemplo o gráfico nos mostra que no dia 16 ainda temos aproximadamente 15 pontos de estória de trabalho para fazer. O gráfico é atualizado diariamente durante o Daily Scrum.

Indicadores:De acordo com o gráfico podemos tomar algumas decisões, e saber diariamente o que esta acontecendo no projeto, se está dentro do prazo, etc...

Dissecando o quadro indicador:

Retrospectiva
Ao final de cada Sprint é ideal a equipe e o Scrum Master e discutir o que cada um achou da Sprint e dar suas opiniões. A idéia central se resume na seguinte pergunta: O que podemos melhorar no próximo Sprint ?
No quadro no exemplo, temos 3 colunas:
1ºBom (Good): Se tivéssemos que fazer outra Sprint, faríamos da mesma maneira.
2ºPoderíamos fazer melhor (Could have been better): Se tivéssemos que fazer outra Sprint, faríamos de maneira diferente..
3º Melhorias (Improvements): Idéias concretas que poderíamos implementar no futuro

Exemplo de um quadro de sugestões / análise:


É possível ainda mesclar Scrum com XP, o que torna o trabalho ainda mais produtivo, em tempo oportuno mostrarei algumas das técnicas utilizadas..