Scrum – Entidades e Sprints

em Metodologias Ágeis.

Nesse post entraremos em alguns detalhes de como funciona o Scrum no dia-a-dia. Antes, é importante falar sobre algumas entidades da metodologia, que cumprem papéis diferenciados fazendo com que o processo funcione.

(Obs: As entidades estão escritas em maiúsculas no texto; algumas entidades secundárias são auto-explicativas e não necessitam de detalhamento)

Entidades do Scrum

– Product Owner (PO): É o cliente (ou seu representante) da Equipe. É responsável pela manutenção do Produto, através do Product Backlog, ou Backlog de Histórias. Esse Backlog é uma lista de requisitos funcionais e não-funcionais escritos de maneira não detalhada, contendo somente uma ou duas frases que descrevam a fucionalidade a ser desenvolvida. A razão de não ser detalhada é agilidade: ao invés de serem escritos e revistos em um documento de n páginas, os requisitos são discutidos entre toda a Equipe durante a Reunião de Planejamento. Considera-se que o Backlog nunca está completo, ou seja, Histórias são adicionadas e removidas conforme necessário.

– Scrum Master: É o facilitador da Equipe. É responsável por interagir com o PO e com outras Equipes para remover as pendências que possam impactar o Sprint. Não é necessariamente um líder, já que as Equipes são auto-gerenciáveis, mas é importante que o Scrum Master tenha contatos com outras Equipes para agilizar a resolução de problemas. É responsável também pelo agendamento das reuniões, pela atualização diária dos gráficos de Burndown e Burnup de cada Sprint, e de apresentar os resultados na Reunião de Revisão.

– Equipe: No Scrum o objetivo é que a Equipe seja auto-organizada, permitindo que todas as decisões sejam tomadas em grupo e sem a necessidade de um líder gerenciando informações e Atividades. É recomendável que a Equipe tenha um número máximo de 10 pessoas – mais que isso recomenda-se quebrar a Equipe em outras menores. Cada membro da Equipe decide quais Atividades irão trabalhar durante o dia, dentro do escopo definido para cada Sprint. Os membros decidem também como farão o Pareamento, onde duas pessoas trabalham na mesma Atividade, trocando experiências e soluções, e assim garantindo a Qualidade do código.

“Chickens” e “Pigs”: São duas entidades que surgiram de uma anedota em inglês, conforme ilustra a tirinha abaixo (“The Classic Story of the Pig and Chicken”, retirado do blog Implementing Scrum):

“Chickens” são pessoas envolvidas nos Sprints, mas que não necessariamente fazem parte da Equipe. São solicitantes de Histórias, pessoas de outras Equipes que acompanham os resultados de um determinado Sprint, ou interessados em geral. Já “Pigs” são os comprometidos diretamente no Sprint – o PO, o Scrum Master e a própria Equipe.

Scrum na Prática – Sprints

Sprints são as iterações cíclicas de Atividades. Diferente da metodologia tradicional cujo ciclo demora meses ou anos, no Scrum, assim como no XP e em outras Metodologias Ágeis, as iterações são curtas, de poucas semanas. Na Locaweb consideramos que o tempo ideal de um Sprint é de duas semanas.

A figura abaixo ilustra o processo de um Sprint:

– Planejamento 1: No início do Sprint, PO e Equipe fazem a primeira parte do Planejamento (Sprint Planning 1), onde o PO apresenta as Histórias com maior prioridade, e a Equipe discute e estima (em story points) cada uma dessas Histórias. No fim geram um Selected Product Backlog, ou uma lista das Histórias que serão desenvolvidas durante o Sprint. As Histórias que não foram selecionadas voltam para o Backlog para serem discutidas no Sprint seguinte. Se durante o Sprint a Equipe perceber que alguma História não poderá ser entregue, esta deve ser negociada junto ao PO, tanto para rever o seu escopo, quanto para eventualmente retirar a História do Sprint para ser re-planejada para o próximo. Contudo, caso essa situação aconteça, é importante ser discutida na Reunião de Revisão para entender a origem do problema.

– Planejamento 2: Em seguida, a Equipe (sem o PO) faz a segunda parte do Planejamento (Sprint Planning 2), onde cada História é quebrada em Atividades técnicas e estimadas, dessa vez em horas. Recomenda-se que cada Atividade seja estimada em no máximo 16 horas – mais que isso a Atividade deve ser quebrada em duas ou mais. No fim dessa parte, a Equipe terá o Sprint Backlog, um planejamento detalhado do que deverá ser feito durante o Sprint. Esse Backlog de Atividades pode ser alterado pela Equipe durante o Sprint, porém, muitas alterações podem ser indício de algum problema de planejamento. Os gráficos de Burndown e Burnup serão de grande utilidade pra identificar essas situações.

– Sprint: Durante os dias seguintes, a Equipe faz reuniões diárias de no máximo 15 minutos (as Daily Meetings ou Stand-Up Meetings) para definir quais Atividades foram realizadas no dia anterior, quais os problemas enfrentados, e quais Atividades serão feitas durante o dia atual. É importante que essa conversa não passe de 15 minutos – caso haja alguma discussão em um determinado item, esta deve ser feita à parte, fora dessa reunião. Recomenda-se seguir literalmente a prática de stand-up (ou seja, fazer em pé), para manter a agilidade.

– Revisão de Sprint: No final do Sprint, tem-se a Retrospectiva, ou Reunião de Revisão de Sprint. Nessa reunião a Equipe apresenta para o PO os resultados do Sprint – quais Histórias foram finalizadas, quais não foram, e quantos story points a equipe atingiu. Em seguida todos revisam os gráficos de Burndown e Burnup em busca de alguma distorção de planejamento. Por fim, discutem as práticas que funcionaram bem e que devem ser mantidas, as práticas que não funcionaram e devem ser revistas, e as dúvidas gerais que surgiram durante o Sprint. Essa reunião é uma das fases mais importantes de todo o processo, já que é aqui que se tomam decisões do que deve ser corrigido e melhorado, visando assim a aplicação da Melhoria Contínua, prática herdada da Metodologia Lean.

Feedback Visual

No Scrum quanto mais informação visual, mais fácil se torna para os “chickens” e “pigs” acompanharem o andamento dos Sprints. Quadros brancos e flipcharts com gráficos e status gerais são sempre úteis. Dois gráficos são bastante utilizados:

– Burndown: Indica o quanto a Equipe está performando em relação ao planejado. Contém a informação de quantas horas restam por dia, tanto planejadas quando realizadas. No exemplo ao lado, a Equipe começou realizando próximo do planejado; em seguida algum problema causou o aumento de horas restantes; no final, a Equipe se re-estabilizou, zerando as horas restantes ao final do Sprint.

– Burnup: Indica o quanto a Equipe está trabalhando em direção ao final do Sprint. Contém a informação de quantas horas serão entregues no total, e quantas horas estão sendo realizadas por dia. A linha de cima reflete as eventuais alterações nas Atividades, se mais ou menos horas foram necessárias para cumprir o Sprint. No exemplo ao lado, complementar ao anterior, a Equipe trabalhou normalmente nos primeiros dias; em seguida houve um replanejamento com a adição de mais horas, e no final algumas Atividades foram cortadas, provavelmente depois de renegociadas com o PO.

Esses gráficos são muito úteis durante a Reunião de Revisão, pois a Equipe tem informações visuais de quando ocorreram as eventuais distorções, e assim podendo identificar suas razões e o que fazer para evitá-las.

Nos próximos posts falaremos um pouco sobre Histórias e sobre Planejamento de Releases. Até lá.

Você também pode gostar