Gerenciamento de projetos com Scrum.

Gerenciamento de projetos com Scrum.
Resumo: O framework Scrum permite gerenciar projetos de forma simples, focando nos
artefatos e eventos mais importantes ao desenvolvimento do software, reduzindo o tempo utilizado na
elaboração de documentos e formalidades desnecessárias. A proximidade e participação do cliente
fornecendo informações sobre requisitos durante o desenvolvimento do projeto reduz o tempo gasto
produzindo documentos de requisitos e com isso o projeto é concluído em menor tempo.
O Framework Scrum.
Scrum é um framework de gerenciamento de projetos de desenvolvimento de software
caracterizado pela flexibilidade dos requisitos do projeto. O framework Scrum permite o
desenvolvimento de projetos onde os requisitos não são completamente conhecidos no início ou
mudam durante o desenvolvimento do projeto. Em projetos gerenciados com Scrum acontece maior
comunicação entre o cliente, que define os requisitos, e os programadores que o implementam.
O framework Scrum organiza os membros do time definindo papéis para eles, suas respectivas
atividades e os produtos gerados por elas. Dessa forma, cada membro do time tem um papel definido e
o escopo de suas atividades está definido pelo seu papel. Cada membro do time é responsável pelos
produtos definidos pelas suas atividades no projeto.
Os papéis definidos pelo framework Scrum são: Scrum Product Owner, Scrum Master, and the
Scrum Team.
A principal função do Scrum Product Owner é gerenciar os requisitos. Os requisitos são todos
armazenados em uma fila chamada Backlog. É responsabilidade do Scrum Product Owner organizar os
requisitos e definir as prioridades dos mesmos. Os requisitos tem o formato de historias. Um exemplo
de historia é o seguinte:
“Sendo um usuário autenticado no sistema, eu quero editar um produto do cadastro de
produtos.”
No exemplo acima, a historia especifica que somente usuarios autenticados devem ter acesso a
edição de produtos. Trata-se de um requisito funcional onde o usuário executa uma operação do
sistema. Existem outros tipos de historias referentes a requisitos não-funcionais, por exemplo:
“Criar script para configurar banco de dados.”
Exemplo de Backlog:
#
História
1
Criar script para configurar banco de dados.
2
Sendo um usuário autenticado no sistema, eu quero editar
um produto do cadastro de produtos.
Prioridade
Estimativa (hrs)
alta
2
media
6
O Backlog pode ser alterado pelo Scrum Product Owner em qualquer momento do projeto.
Porém, ele deve ser o primeiro a ser criado, antes do projeto começar, pois todas as demais atividades
dependem dele.
Observe que no momento em que os requisitos são definidos, não há necessidade de
documentos completamente detalhados. O Framework Scrum aceita o fato de que os requisitos podem
mudar ou não são totalmente conhecidos no início do projeto. Os documentos de baixo nível, como
detalhes de formulários ou telas, são fornecidos pelo Scrum Product Owner somente no momento em
que eles estão prestes a serem implementados pelos programadores. Isso torna necessária maior
comunicação entre o Scrum Product Owner, Scrum Master e os programadores durante a execução dos
requisitos.
O Scrum Master é outro papel importante no Framework Scrum. Suas principais tarefas são
coordenar tecnicamente o trabalho dos programadores eliminando suas duvidas ou quaisquer
problemas que estiverem atrapalhando suas tarefas, além de conduzir as reuniões definidas pelo
framework Scrum.
O número sugerido de membros em um time é 7 pessoas, sendo um Scrum Master e um Scrum
product Owner para cada cinco programadores. Se houver a necessidade de maior quantidade de
recursos, outros times podem ser criados para executar simultaneamente os requisitos do mesmo
Backlog. Neste caso, os Scrum Product Owners dos times serão gerenciados pelo Chief Scrum Product
Owner.
As reuniões definidas pelo framework Scrum são listadas abaixo e ocorrem na seguinte ordem:
1.Sprint Planning Meeting:
As entregas dos produtos da execução dos requisitos são feitas em grupos de requisitos. O
grupo de requisitos que serão entregues juntos define a Sprint. A Sprint é a execução de um
determinado grupo de requisitos escolhidos de acordo com suas prioridades e tempos necessários para
execução (estimativas). Todos os membros do time participam na seleção dos requisitos que serão
incluidos na Sprint: O Scrum Master e os programadores definem o tempo necessário para executar
cada requisito enquanto o Scrum Product Owner seleciona os requisitos que devem ser priorizados.
Este planejamento da Sprint é o primeiro evento de cada Sprint, chamado Sprint Planning Meeting e
define o que será feito e como será feito. Os requisitos devem ser selecionados de forma que o tempo
necessário para executar a Sprint seja de 2 a 4 semanas.
Planning Poker:
O Planning Poker permite obter a estimativa por meio de um jogo de cartas, que deve permitir
que todos os membros do time participem colocando a sua opiniao de complexidade atraves da carta
do baralho.
No Planning Poker cada integrante tem a sua disposição um baralho de 13 cartas, numeradas em
uma sequência similar a encontrada nos números de Fibonacci. As cartas contém os tamanhos de 0, ½,
1, 2, 3, 5, 8, 13, 20, 40 e 100, havendo ainda uma carta com o símbolo de interrogação no qual
representa que o estimador não está apto a estimar.
Durante o Planning Poker devem ser realizadas rodadas para obter a estimativa de um requisito
a desenvolver. As diferenças que surgirem durante as rodadas deverão ser mediadas por um
coordenador, que no Scrum este papel é de responsabilidade do Scrum Master. O Product Owner, é o
responsável por explicar o que deverá ser desenvolvido, sendo um importante papel para retirar
possíveis dúvidas a respeito do cartão, evitando assim, o retrabalho.
2.Daily Scrum Meeting:
Todos os dias, antes de iniciar o trabalho, o time é reunido por 15 minutos, em pé, para cada
membro informar os seguintes itens:
–
O que fez no dia anterior ou depois da ultima reunião.
–
O que vai fazer no dia.
–
Se existem problemas que estejam atrapalhando suas tarefas.
3.Sprint Review Meeting:
Após os requisitos ou tarefas da Sprint terem sido todos executados ou o prazo ter sido
encerrado, o time mostra ao Scrum Product Owner os produtos que foram gerados pela execução dos
requisitos. Nesta reunião, o Scrum Product Owner aceita os resultados ou solicita correções e alterações
através da criação de novos requisitos no Backlog.
4.Sprint Retrospective Meeting:
O limite de requisitos de uma Sprint é restrito ao tempo e quantidade de membros no time. Os
requisitos presentes no Backlog não são todos executados em uma unica Sprint. O restante dos
requisitos presentes no Backlog são executados propositalmente em Sprints subsequentes para permitir
a melhoria continua. Entre a entrega de uma Sprint e o inicio da próxima, acontece a Sprint
Retrospective Meeting, onde os erros ou problemas da Sprint anterior são analisados pelo time para que
não voltem a acontecer na Sprint seguinte.
Características do processo Agile de desenvolvimento de projetos.
O framework Scrum possui, portanto, as seguintes características de projetos Agile:
•
Desenvolvimento incremental e iterativo: cada Sprint, desde seu planejamento até a
entrega constitui uma iteração. Ocorrem várias Sprints durante o projeto, sempre incrementando o
código já existente.
•
Realiza entregas de software frequentemente.
•
Envolve o cliente durante o desenvolvimento do software.
•
O time possui membros com diferentes funções e se auto organiza na forma que
considera mais eficiente.
Relatorio de progresso da Sprint: Sprint Burndown.
O grafico Sprint Burndown mostra a quantidade de trabalho restando a fazer em horas por dia
de trabalho. Esta relação permite calcular a velocidade da equipe e prever o término das tarefas da
Sprint.
Exemplo de grafico Sprint Burndown.
Referencias:
http://www.scrum-institute.org
http://www.devmedia.com.br
Sobre o autor:
Gustavo Antonio Toretti ([email protected]), é certificado como Scrum Web Developer,
IBM Solution Designer for IBM Rational Unified Process (RUP), entre outras tecnologias utilizadas
em desenvolvimento de software e tem mais de 10 anos de experiência desenvolvendo sistemas.