Muitas pessoas acreditam que Scrum é uma metodologia que ajuda a desenvolver melhores produtos. Isso não é verdade! Se a solução idealizada e projetada for ruim, o produto que será produzido também será ruim, independentemente da metodologia utilizada. Scrum não lhe dá a resposta de como desenvolver software de qualidade mais rapidamente. Trata-se de um framework que pode ser usado para identificar o que precisa ser feito para desenvolver software de qualidade rapidamente. Assim, aqueles que acreditam que o Scrum é uma bala de prata que irá sempre resolver todos os seus problemas de forma simplista e eficiente, se enganou! Tornar o Scrum eficaz e eficiente depende da correta aplicação dos conceitos que norteiam esse framework.
O Scrum, em sua essência, é simples de ser compreendido e aplicado. Porém, antes de explicar como funciona a engenharia desse processo é necessário compreender as pessoas que estão envolvidas e seus papéis. No Scrum existem três papéis de atuação:
- Product Owner
- Define as funcionalidades do produto;
- Decide a data de entrega e o conteúdo;
- Responsável pelo ROI (Return of Investiment) do produto;
- Prioriza as funcionalidades conforme o valor de negócio;
- Ajusta as funcionalidades e suas prioridades a cada Sprint;
- Aceita ou rejeita os resultados.
- Scrum Master
- Responsável pela aplicação dos valores e práticas do Scrum;
- Remove impedimentos;
- Assegura que a equipe está totalmente funcional e produtiva;
- Permite a cooperação entre os diversos papéis e funções;
- Protege o time das interferência externas.
- Time
- Grupo formado, preferencialmente, por 5 a 9 pessoas;
- Deve ser multifuncional;
- Preferencialmente, dedicado única e exclusivamente ao projeto;
- Auto-gerenciado.
A engrenagem do Scrum funciona de maneira a proporcionar rápida resposta a mudanças. Observe que primeiramente é concebida uma visão do problema existente. A partir dessa visão o Product Owner constrói o Backlog do Produto, o qual irá conter tudo o que é necessário para desenvolver e lançar um produto com sucesso. Trata-se de “uma lista de todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para versões futuras” [SCHWABER, 2009]. O Backlog do produto é formado por User Stories ordenadas por prioridade. Ele nunca está completo: evolui à medida que o produto e o ambiente em que ele será usado evoluem.
Figura 1 – A engrenagem do Scrum.
Fonte: Blog Gestão de Projetos Ágeis
Após a definição e priorização do Backlog do Produto, o próximo passo é o Planejamento da Sprint. Sprint nada mais é que uma iteração do projeto. Em um primeiro momento dessa reunião é decidido o que será feito na Sprint, mais conhecido como Sprint Backlog. Em seguida, o Time deverá entrar em um consenso sobre como desenvolverá essa funcionalidade. Cabe somente ao Time a decisão de quanto do Backlog ele deve selecionar. Somente o Time pode avaliar o que ele é capaz de produzir durante a Sprint. As user stories devem ser escolhidas baseando-se nas prioridades definidas pelo Product Owner e no prazo escolhido para essa iteração. Essas iterações são contínuas até que todo o Backlog do Produto tenha sido produzido. Podem ter duração entre duas e quatro semanas e devem ser acompanhadas pelas reuniões diárias. Essas reuniões devem ser conduzidas pelo Time, ter duração máxima de 15 minutos e ocorrerem sempre no mesmo horário e local. Durante a reunião diária, cada membro do Time deve explicar:
- O que ele realizou desde a última reunião diária;
- O que ele vai fazer antes da próxima reunião diária; e
- Quais obstáculos estão em seu caminho.
As reuniões diárias servem para melhorar a comunicação, eliminar outras reuniões, identificar e remover impedimentos para o desenvolvimento, ressaltar e promover a rápida tomada de decisão e melhorar o nível de conhecimento de todos acerca do projeto. Vale ressaltar que o Scrum Master ensina o Time a manter essa reunião com curta duração, reforçando as regras e garantindo que as pessoas falem de forma rápida e objetiva.
Após o término de cada Sprint deverá ser feita a Revisão da Sprint, onde o Time deverá apresentar o que foi feito (produto potencialmente utilizável) e validar com as partes interessadas. Obtém-se assim, entrega de valor ao cliente com uma maior frequência, num menor espaço de tempo. O Time também deverá discutir o que correu bem durante a Sprint, quais os problemas enfrentados e como eles foram resolvidos. A Revisão da Sprint fornece entradas de extremo valor para as próximas reuniões de Planejamento de Sprints.
A Retrospectiva da Sprint é o passo seguinte e deve ocorrer antes da próxima reunião de Planejamento da Sprint. Durante essa retrospectiva o Scrum Master encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais produtivo para a próxima Sprint. Neste momento deve ser inspecionado como correu a última Sprint, em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas. Ao final dessa etapa o Time deve ter identificado medidas de melhorias factíveis que deverão ser implementadas na próxima Sprint.
Por fim é válido ressaltar a importância da ferramenta Gráfico de Burndown, a qual nos fornece inúmeras possibilidades, tais como:
- Permite medir o progresso e velocidade do time.;
- Apresentar a quantidade de trabalho restante;
- Ser personalizável, a depender da necessidade do time;
- Permite avaliar riscos no projeto.
Portanto, vimos como a engrenagem do Scrum funciona de forma simples e objetiva, atacando os principais ideais defendidos pelo Manifesto Ágil: mais indivíduos e interações do que processos e ferramentas; mais software em funcionamento do que documentação abrangente; mais colaboração com o cliente do que negociação de contratos; e responder a mudanças mais facilmente do que seguir um plano. E lembre-se: o Scrum é o seu parceiro e não o seu chefe! Ele lhe fornece suporte (técnicas e ferramentas) para produzir produtos com qualidade mais rapidamente. Jamais ele irá lhe dizer como construir seu produto ou serviço! O leitor que deseja se aprofundar mais no assunto e conhecer mais detalhes sobre esse framework, basta acessar a seção Scrum no menu através da opção Documentos > Metodologias Ágeis ou através desse link.
SCHWABER, Ken. Guia da Scrum. ScrumAlliance, 2009. GOLDENBERG, Michel. Curso Certified Scrum Master. GoToAgile!, 2010.
Gostei do Artigo. vou favoritar o blog, será util em Ds3 😛
CurtirCurtir
Parabens pelo material esta muito bem escrito, eh uma referencia que agrega valor.
CurtirCurtir
Bem explicativo. Mas essa ‘metodologia’ é aplicável somente ao desenvolvimento de softwares? Não posso considerá-la para qualquer tipo de produto?
CurtirCurtir
Sim, prezado leitor. O framework Scrum pode ser utilizado para desenvolvimento de qualquer produto.
CurtirCurtir