Metodologias de Desenvolvimento Ágil – Parte 4: Scrum


Metodologias AgeisEsta é a quarta parte da série de artigos sobre Metodologias de Desenvolvimento Ágil. Estes artigos são baseados no Trabalho de Conclusão de Curso apresentado como exigência para a obtenção do grau de Bacharel em Ciência da Computação da Faculdade Anhanguera de Campinas – Unidade 3, denominado “Metodologias de Desenvolvimento Ágil Aplicadas No Desenvolvimento De Softwares Em Empresas De Pequeno Porte“, escrito por Felipe Morandin, Fernando Fonte e Tiago Souza.

Espero que você aproveite a leitura.

2.3 – Scrum

2.3.1 – Introdução ao conceito

O Scrum foi criado, a princípio, para ser um modelo de gerenciamento de projetos para empresas automobilísticas (Takeuchi, 1986). Esse modelo deu tão certo que anos mais tarde foi documentado e passou a ser usado também no desenvolvimento de software (Beedle, 2001).

Essa metodologia de desenvolvimento ágil herdou algumas formas e padrões de metodologias como a Lean[1], o Desenvolvimento Iterativo[2] e as idéias de Hirotaka Takeuchi e Ikujiro Nonaka, criadores do scrum para indústrias automobilísticas.

Como principais características do Scrum podemos citar os times pequenos, o cliente como parte atuante do desenvolvimento, as entregas sempre em intervalos de tempo curtos, os planejamentos freqüentes e as discussões diárias para poder levantar o que foi feito, o que ainda vai ser feito e se existe alguma coisa impedindo essas tarefas de serem executadas (Cohn, 2009).

Atualmente o Scrum é muito utilizado em desenvolvimento de software, mas graças a algumas de suas características é possível usá-lo em quase todo o tipo de projeto que se queira desenvolver.

2.3.2 – Características e Artefatos

Nesse tópico serão apresentadas as principais características e os artefatos que são gerados dentro de um processo de desenvolvimento utilizando Scrum. Algumas reuniões serão citadas nesse tópico e explicadas de forma mais detalhada no tópico seguinte.

O Scrum é característico por ser uma metodologia que prega entregas em tempo curto sem abrir mão da qualidade (Cohn, 2009).  Diferentemente do XP, não aplica metodologias e sim artefatos que são usados durante todo o período de desenvolvimento por todos os envolvidos no processo. Dentro do Scrum, além dos artefatos, existem também alguns papéis razoavelmente bem definidos. Todos esses artefatos, papéis e reuniões do Scrum serão apresentados nesse capítulo.

Para que um time desenvolva um produto e aplique o Scrum durante o seu desenvolvimento, primeiramente é preciso definir quem será o Product Owner e o Scrum Master, definir por quantas pessoas será composta a equipe e definir a duração de cada Sprint.

Sprint é o nome dado para o período de tempo em que o time executa suas atividades. Normalmente cada sprint dura de duas a três semanas começando no dia que foi realizada a Planning Meeting indo até o dia anterior à próxima Planning.

Product Owner é o cliente, o dono do produto que será construído, ele é o responsável por dizer o que tem que ser feito, assim como a ordem em que isso deve ser feito. É também o responsável por responder a maioria das dúvidas que o time tiver.

Definido quem será o Product Owner, também chamado PO, será a hora de escolher um Scrum Master, ele será o responsável por conduzir todas as reuniões relativas ao processo. Fica a cargo dele conduzir as reuniões de planejamento, as reuniões de status diário e as retrospectivas. O Scrum Master também é o responsável por tentar solucionar tudo o que esteja bloqueando o time de alguma forma. Muitas vezes, caso o Scrum Master não possa efetivamente desbloquear o time, ele entrará em contato com quem possa.

Como a própria metodologia prega, os documentos são diferentes e menores do que os utilizados na metodologia RUP[3], por exemplo. No lugar de vários requisitos completos e complexos, no Scrum é criado um único documento com todas as User Stories[4] do sistema chamado Product Backlog.

O Product Backlog é o “coração” do Scrum (Kniberg, 2007). É nele que o processo começa a se desenvolver. Ele contém todas as User Stories, também chamadas US, itens do Backlog ou simplesmente estória, que o cliente deseja descritas de um jeito que todos do projeto tenham uma idéia do que ela se trata só de ler o título.

Esse backlog é normalmente escrito pelo PO, porém qualquer outra pessoa pode incluir uma nova estória. Qualquer outra estória que seja incluída no backolg por uma outra pessoa que não seja o PO não pode ter a importância definida pois isso é feito pelo PO.

Cada US é composta por um ID único, um nome curto e descritivo, a estimativa inicial da equipe em pontos de complexidade, o critério de aceitação da história e alguma nota ou observação. Todos estes itens serão explicados a seguir.

O ID é um número de identificação único para cada US. Esse número é incrementado a cada US adicionada no Product Backlog e ele é utilizado, principalmente, para evitar que se perca o controle sobre as estórias caso alguma delas tenha o nome alterado.

O nome é composto de duas a dez palavras, normalmente, e tem como função ser uma maneira rápida e fácil de identificação de uma história. O nome deve ser suficientemente claro para que quando um desenvolvedor, ou até mesmo o PO, for consultar o Backlog ele consiga ter uma idéia do que se trata e também que, através do nome, fique clara a distinção entre cada estória.

A Importância é definida pelo PO. Ele deve avaliar o quanto essa estória é importante para o projeto, o quanto ela gerará de valor comercial para o projeto. Normalmente a quantidade de pontos definidas pelo PO equivalem a prioridade da tarefa, mas isso nem sempre é verdade pois o PO pode ter uma estória que é muito importante para o projeto mas não é uma prioridade. Essa importância normalmente é quantificada através de números que representam o quanto é importante, quanto maior o número mais importante essa estória é para o PO.

Os responsáveis pelas Estimativas são os desenvolvedores e eles fazem isso durante a Planning Meeting I. As Estimativas são medidas usando pontos de complexidade que indicam o quão complexo é desenvolver a estória. São escolhidos levando-se em conta os critérios de aceitação e a quantidade de pessoas no time numa proporção de “homens/dia” Esse pontos podem ser calculados da seguinte forma: os desenvolvedores são questionados sobre quantos dias eles levariam para terminar aquela estória e quantas pessoas eles precisariam. Esse valor é multiplicado e então se tem a complexidade; como exemplo, podemos citar uma estória que levaria três dias para ficar pronta com uma equipe de quatro pessoas, sendo assim, ela deveria ter doze pontos de complexidade. Esta não é a única forma de se pensar nos pontos de complexidade, outra forma bastante comum é definir a menor história que existe no sprint, a mais simples de ser feita e, a partir dela, ir estimando as outras através de comparações. Todas essas formas de se pensar e definir os pontos de complexidade ocorrem na Planning Meeting I e esta será explicada mais a frente junto com todas as outras reuniões do Scrum.

Ainda dentro de uma estória é possível encontrar o Acceptance Criteria ou Critério de Aceitação que, nada mais é, que os pontos que os desenvolvedores devem cumprir antes de considerar aquela história como finalizada. O que deve ser feito, o que será testado e quais os resultados esperados são coisas que podem estar no Acceptance Criteria.

Para finalizar uma estória ainda temos, de forma não obrigatória, as Notas que podem conter esclarecimentos, outras fontes de informação ou qualquer outro tipo de informação que o PO ou até mesmo o time ache relevante, a Nota é sempre colocada de forma breve dentro da estória.

O Product Backlog normalmente é uma planilha mantida pelo PO e que fica compartilhada para que todo o time possa acessar sempre que tiver alguma dúvida sobre o que deve ser feito. Manter essa planilha compartilhada é útil também pois, normalmente, o time faz uma releitura, ao final do sprint, dos pontos de complexidade que foram estimados e se eles foram corretos ou não.

Segue um exemplo de Product Backlog:

ID Nome Imp. Est. Acceptance Criteria Notas
1 Depósito 30 5 – Realizar o Depósito Corretamente- Atualizar Saldo Cliente – Para realizar o depósito o usuário precisa estar logado no sistema.
2 Verificar histórico transações 10 8 – Exibir todo o histórico de transações- Exibir maiores informações de cada entrada no histórico

Tabela 1 – Product BackLog

Algumas vezes podemos extrair um outro documento de dentro do Product Backlog chamado de Definition of Done. Esse documento contém alguns critérios de aceitação que são gerais para qualquer estória. Quando esse documento existe, além dos critérios de aceitação de cada estória o desenvolvedor deve observar os itens do Definition of Done antes de falar que a estória está realmente finalizada.

Depois que o Product Backlog é montado chega a hora de definir o Sprint Backlog. Esse artefato é definido entre a Planning Meeting I e a Planning Meeting II e tem a função de manter separado, normalmente numa outra planilha, as estórias que serão feitas no Sprint que irá começar.

As estórias que serão feitas são definidas usando a Velocity do time. Essa Velocity é, basicamente, quanto o time consegue entregar de pontos de complexidade por Sprint e para achá-la o time vai fazendo comparações com os Sprints que já acabaram e vai chegando num valor médio. Muitas vezes, durante uma Planning o time pode pegar um pouco mais ou um pouco menos pontos de complexidade do que a velocidade média e, caso o time termine os pontos que pegou e ainda tiver tempo no Sprint ele pode começar a trabalhar no próximo item de backlog.

Quando um time está começando é normal que as estimativas de velocity não sejam precisas porém é uma tendência natural do time achar esse valor médio com o tempo.

Uma coisa importante a ser dita é que, pelo menos na teoria, só existe um backlog por produto e um PO por backlog, não deve existir um backlog que seja mantido por mais de um PO e nem mais de um backlog por projeto.

Podemos considerar como artefatos do Scrum os boards com as tarefas e com os gráficos. Depois da Planning Meeting 2 o time já tem o Sprint Backlog com as estórias divididas em tarefas. Essas tarefas são colocadas num quadro branco ou em uma parede, esse é o primeiro dos boards de um Sprint. Ele é dividido em três colunas, a primeira contém as estórias e as tarefas de cada estória, na segunda são colocadas as tarefas que estão sendo feitas naquele dia e na terceira as tarefas que já foram finalizadas. Algumas equipes fazem uma quarta coluna para colocar os blocks[5].

Esse quadro pode ser montado de diversas formas ficando a cargo da equipe decidir que material será usado. Alguns boards são montados usando post-its, os de cor amarela para tarefas, os de cor vermelha para bugs e blocks. Outras vezes são usados papéis de diferentes cores (definido pela equipe) mas sempre estórias técnicas, estórias não técnicas, bug e blocks são apresentados de cores diferentes como se pode ver na figura 1.

Figura 1 – Quadro com as tarefas do sprint

 

Um outro tipo de board são os gráficos ou burndowns. Neles são desenhadas linhas para a quantidade de tarefas total, quantas faltam e quantas já foram concluídas. Em alguns casos esse gráfico é feito de forma mais simples só traçando uma linha correspondente das tarefas que estão faltando.

Existe um outro board muito parecido com o de tarefas mas, ao invés de mostrar as informações referentes as tarefas ele mostra as informações referentes a complexidade. Nele, da mesma forma que no de tarefas, temos uma linha que indica a quantidade total de pontos de complexidade que serão entregues no sprint, uma outra linha indicando quantas já foram terminadas e uma outra indicando quantas faltam. Assim como no gráfico de tarefas , uma outra maneira de se desenhar é usando somente uma linha que corresponde a quantidade de pontos de complexidade que ainda não foram concluídos.

Alguns projetos utilizam um terceiro gráfico que é atualizado somente no final do sprint. Esse gráfico mostra, sprint por sprint, quantos pontos de complexidade o time se comprometeu a entregar e quantos pontos o time realmente entregou. Esse gráfico é muito utilizado para poder ter uma idéia da assertividade do time e é demonstrador na figura 2.

Figura 2 – Burndown

 

Como o Scrum é uma metodologia em que se faz pouca documentação, alguns times utilizam uma página onde todos tem acesso para ver e editar com algumas informações que são relevantes para o projeto como dicas de como corrigir alguns problemas, preparação de ambiente para o desenvolvimento, contato do time caso alguma pessoa de outro time precise, informações sobre backlogs e sprints ou qualquer outra informação que o time ache pertinente de ser divulgada.

2.3.3 – Reuniões do Scrum

2.3.3.1 – Planning Meeting I e II

As reuniões de planejamento são as mais importantes dentro do Scrum pois um único sprint mal planejado pode estragar todo o trabalho dentro do projeto. Normalmente dividida em duas partes, as reuniões de planejamento tem um prazo de duas horas cada uma e são feitas, quase sempre, no mesmo dia e uma logo após a outra.

Antes de começar as reuniões, principalmente a Planning Meeting I, é preciso que o backlog já esteja pronto e priorizado pelo PO pois ele é fundamental para a Planning Meeting I.

No começo dessa reunião normalmente o time apresenta ao PO a disponibilidade de cada membro da equipe, o PO define a data de entrega do Sprint e o time, juntamente com o PO define o horário e local das Stand ups.

Definidos esses itens chega a hora de realmente planejar. O PO apresenta para o time o backlog priorizado e começa a explicar para o time o que são as estórias e qual o critério de aceitação de cada uma. Durante a explicação se o time tiver alguma dúvida ele pergunta para o PO que irá tirar essa dúvida.

Depois que o time todo entendeu do que se trata uma estória e não tem mais dúvidas chega a hora de estimar. Para isso, normalmente, é utilizado o método de Planning Poker em que cada integrante do time tem um baralho e cada carta deste baralho representa um ponto de complexidade. Cada integrante do time, então, mostra, ao mesmo tempo, uma carta com a complexidade que ele acha necessária para finalizar aquela estória. Havendo diferenças entre os pontos de complexidade apresentados o time conversa entre si ou até mesmo faz mais perguntas para o PO para tentar acabar com a diferença de pontos. Depois dessa rodada de perguntas e discussão o time mostra novamente as cartas e, se pela segunda vez, o time não entrar em um acordo o processo se repete. Para não passar do tempo que é destinado para essa reunião esse processo de planning poker é realizado até três vezes.

Ainda dentro da Planning Meeting I, depois do time ter terminado de estimar as estórias chega a hora de montar o Sprint Backlog que é uma versão reduzida do Product Backlog contendo só as estórias que serão feitas dentro do Sprint.

Finalizada a Planning Meeting I chega a hora do time pegar as estórias que serão desenvolvidas no sprint e definir quais as tarefas que são necessárias para finalizar a estória, essa é a Planning Meeting II.

Na Planning Meeting II o PO não precisa, necessariamente, participar pois essa reunião é, na teoria, só para o time poder quebrar a estórias em tarefas. Em algumas situações o PO pode ser chamado na Planning Meeting II caso tenha surgido alguma dúvida do time sobre uma estórias específica que só apareceu na hora de quebrar as tarefas. Serão essas as tarefas que irão para o board.

Acabada as duas reuniões de planejamento o time já pode começar a trabalhar nas tarefas. Em alguns casos, no mesmo dia da Planning Meeting ao invés de começar a trabalhar o time monta todos os boards.

É ideal ainda que, no meio do sprint seja feita uma reunião de 1 hora para estimar alguns outros itens do backlog fazendo com o time sempre tenha um backlog maior do que o necessário já estimado o que faz com que a Planning Meeting I seja mais rápida ou que seja mais detalhada do que o normal.

2.3.3.2 – Stand up Meeting

Essa é uma reunião que acontece diariamente durante o Sprint num horário e local definido pelo time e pelo PO durante a reunião de planejamento. Todo o time participa dessa reunião que, assim como as outras é conduzida pelo Scrum Master.

Durante essa pequena reunião, que tem duração de quinze minutos, o time apresenta o que foi feito desde a stand up do dia anterior, o que será feito e se existe alguma coisa bloqueando o time para terminar a tarefa.

As atualizações de board são feitas ou durante a stand up ou logo após a sua finalização. Durante a stand up cada integrante do time fala o que fez, o que pretende fazer e se tem algo o bloqueando, ao mesmo tempo ele vai atualizando o quadro de tarefas movendo para a coluna de tarefas finalizadas o que ele já fez, para a coluna das que estão sendo feitas o que ele vai fazer e, se tiver um block, ele escreve um outro papel e coloca na coluna de blocks. Esse block é sempre o Scrum Master que deve resolver ou procurar quem possa resolver.

Logo após a stand up o time atualiza os gráficos e volta a trabalhar nas próximas tarefas até que no dia seguinte tem outra stand up e o processo se repete.

2.3.3.3 – Sprint Review

Essa reunião também é conhecida como Demo Meeting, tem duração estimada de uma hora e ocorre ou no último dia do sprint ou no dia seguinte ao final do sprint. Nela todos participam porém só o time e o Scrum Master falam. O Scrum Master é responsável por conduzir a reunião e o time apresenta o que foi feito durante o sprint.

Cada integrante do time demonstra o que fez durante o Sprint e, caso uma estória não tenha sido finalizada, ele explica o que aconteceu. Após cada demonstração de estória o PO diz se, de acordo com os critérios de aceitação, a estória realmente foi finalizada. O PO acompanha o desenvolvimento e o rendimento do time através das Stand up mas é durante a Demo que ele realmente vê o trabalho finalizado.

2.3.3.4 – Sprint Retrospecitve

A Restrospective é uma reunião que quase sempre é logo em seguida da Review e pode até ser confundida como uma única reunião. Nela o time discute o que foi bom e o que foi ruim ou não tão bom no sprint. A retrospective, assim como a review, tem duração de uma hora.

O PO vai anotando o que foi discutido e todos no time podem propor melhorias. Depois que a reunião acaba o time analisa o que foi levantado e se propõe a melhorar algumas coisas para o próximo sprint.

Alguns times realizam, no mesmo dia e em seqüência, a Review, a Retrospective e logo em seguida as reuniões de planejamento. Quando isso acontece o time usa quase o dia inteiro só nas reuniões e montando os boards.


[1]              Lean é uma metodologia também conhecida como Sistema Toyota de Produção e foi criada logo após a Segunda Guerra Mundial procurando aumentar a produtividade da fábrica que estava muito baixa.

[2]              Desenvolvimento Iterativo é uma estratégia de planejamento de retrabalho em que os tempos utilizados para a revisão e a melhoria do sistema já são pré-definidos.

[3]              RUP é uma metodologia de desenvolvimento que tem todos os documentos muito bem definidos e muito detalhados. Nessa metodologia todo os requisitos são definidos antes do desenvolvimento já prevendo, assim, todas as possibilidades de erro e todos os possíveis fluxos do sistema.

[4]              User Stories é o equivalente ao requisito, são elas que dizem o que o sistema deve ou não ter.

[5]              Block é algo que está acontecendo dentro de um sprint que impede que uma determinada tarefa seja completada.

Índice:

Últimos 5 artigos de Fernando Fonte

Sobre Fernando Fonte

De Campinas-SP, bacharel em Ciência da Computação. Atua como Analista Programador em uma empresa de tecnologia. Tem experiência no desenvolvendo de softwares para comunicação e controle de hadware via porta serial e sistemas ERP. Possui conhecimento em sistemas operacionais Windows, programação Delphi e Visual Basic 6 e Banco de Dados SQL Server e MySQL. Atualmente estuda C# e Android. Tem interesse em Jogos, Celulares, Smartphones, Notebooks e tudo que for relacionado a tecnologia. Fundador deste site e editor chefe, convidou amigos para lhe ajudar com este projeto.

Deixe uma resposta