Introdução
As constantes mudanças tecnológicas têm estimulado diversas empresas de Tecnologia da Informação (TI) a repensarem as suas práticas e oferecerem produtos com maior qualidade, no prazo estimado pelos seus clientes. A concorrência cada vez mais estimulada também impulsionou esse repensar e elevou as empresas a mudarem a sua cultura e também as metodologias e práticas empregadas nos seus processos e produtos. Tais empresas têm procurado metodologias que permitam otimizar o tempo e que seja fácil da equipa se adaptar.
Essas características podem ser adquiridas com o uso de metodologias ágeis, pois são metodologias que têm o foco na entrega dos produtos dentro do prazo determinado pelo cliente e estimado pela equipa de desenvolvimento. A adoção desse tipo de metodologia também permite o desenvolvimento de uma solução computacional com maior qualidade e valor agregado.
A metodologia ágil mais utilizada atualmente é a Scrum. Essa metodologia agrega quase todas as características que uma empresa procura quando o objetivo é garantir a qualidade do produto final entregue ao cliente. Entretanto, algumas empresas ainda têm receio de implantar essa metodologia quando essa implantação ocorre à posteriori e a equipa já está na etapa de desenvolvimento dos seus produtos.
É difícil fazer com que essa equipa aceite as mudanças trazidas com a implantação da nova metodologia, pois existe a possibilidade de regressão aos requisitos recolhidos e já implementados. Essas mudanças podem resultar em alterações substanciais no código produzido.
Do ponto de vista dos gestores, muitas vezes por não conhecerem corretamente a metodologia, existe a preocupação em perder dinheiro e também a credibilidade com os clientes.
Fundamentação Teórica
Desenvolvimento Ágil de Software (do inglês Agile Software Development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software que provê uma estrutura conceitual para reger projetos de engenharia de software. A literatura aponta diversas metodologias ágeis, entre elas: a eXtreme Programming (XP), Scrum, Rational Unified Process (RUP), Kanban, Lean Software Development (LSD), Feature-Driven Development (FDD), e OpenUP2. Entretanto, pesquisas apontam que Scrum tem sido a metodologia ágil mais utilizada atualmente. Essa metodologia foi escolhida como foco do estudo realizado no contexto deste trabalho por ser a mais atual e mais abrangente no mercado de desenvolvimento de softwares.
Nas subseções a seguir a metodologia Scrum, bem como seus princípios, papéis,
reuniões e artefatos são descritos. Também é descrito o Mapeamento Sistemático,
metodologia utilizada neste trabalho para realizar procuras sistemáticas na literatura sobre a implantação do Scrum em empresas de médio e pequeno porte.
Metodologia Ágil SCRUM
A metodologia Scrum é conhecida por ser uma metodologia ágil para gestão e para
planeamento do projeto.
O Scrum começou a ser utilizado no desenvolvimento de software no início dos anos 90 visando melhorar o trabalho em equipa. A metodologia sugere que todos os
stakeholders avistem um mesmo objetivo, que as tarefas sejam compartilhadas e os
feedbacks sejam repassados diariamente tanto em relação ao produto, quanto ao andamento do trabalho.
O Scrum porém, não é uma metodologia que reporta exatamente como deve ser
desenvolvido o produto ou como essa metodologia deve ser sistematicamente trabalhada na empresa. Trata-se de um framework utilizado para gerir o desenvolvimento de produtos e pode ser melhorado de acordo com a necessidade da empresa.
O Scrum define a formação de equipas (times) que são ligadas a papéis, eventos
(reuniões) e artefatos bem definidos. Para garantir um melhor resultado, bem como o sucesso na adoção do Scrum, deve-se seguir e empregar corretamente os eventos e artefatos propostos pela metodologia.
A implantação do Scrum é trabalhosa e exige entendimento, persistência, paciência,
adaptação e, acima de tudo, a quebra de paradigmas de uma empresa.
Segundo Ferreira, as principais características do Scrum são:
• Permitir a gestão e o controle no desenvolvimento de projetos;
• Aumentar a comunicação e maximizar a cooperação;
• Detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de
um produto;
• Ser escalável desde médio até grandes projetos em toda empresa.
O Scrum tem uma forma diferente de trabalhar, pois tem uma abordagem iterativa e
incremental, na qual o trabalho é dividido em quantos Sprints forem necessários para a conclusão do projeto.
Um Sprint é a unidade básica de desenvolvimento em Scrum e tende a durar entre 2 a 4 semanas.
No início de cada Sprint é realizado o Sprint Planning Meeting, reunião de
planeamento em que o Product Owner (proprietário do produto) determina as prioridades do Product Backlog (lista de requisitos desejados pelo cliente). Após a equipa definir quais as tarefas que entrarão no Sprint atual, as tarefas escolhidas são determinadas e transferidas ao Sprint Backlog (lista de tarefas do Sprint corrente). Neste momento do projeto, cada membro da equipa já tem uma tarefa destinada e todos conseguem visualizar as diversas tarefas e para quem estas foram destinadas. Assim, a equipa consegue acompanhar e ajudar, caso ocorra
algum imprevisto.
Feita a seleção das tarefas inicia-se a execução das mesmas. Todos os dias ocorre
uma reunião chamada Daily (reuniões diárias), com duração máxima de 15 minutos.
Após a conclusão do Sprint, a equipa apresenta as funcionalidades concluídas para as partes interessadas e o ciclo inicia-se novamente até que o produto seja concluído. A Figura 1 ilustra esse ciclo.
A metodologia Scrum utiliza vários papéis, reuniões e artefatos. Tais componentes
serão descritos nas subseções a seguir.
Papéis, Artefatos e reuniões do SCRUM
A metodologia Scrum propõe alguns papéis que representam as pessoas comprometidas com o projeto e que produzem o produto final, são:
Product Owner
O Product Owner é a pessoa, na metodologia, que define os itens do Product
Backlog e que passa as informações referentes aos requisitos, layout e determinações solicitadas pelo cliente. Deve comprometer-se que durante o Sprint não haverá mudanças e novos requisitos para a equipa. As mudanças podem ocorrer, mas não após o Sprint iniciado.
Scrum Master
O Scrum Master tem o papel de facilitador, deve ajudar a equipa em tudo que for
necessário e remover quaisquer obstáculos citados durante as reuniões. Também deve proteger a sua equipa, aconselhando para que ela não se comprometa excessivamente com as tarefas que serão realizadas durante o Sprint.
Geralmente o papel de Scrum Master é exercido por um gerente de projeto ou líder
técnico, mas, pode ser exercido por qualquer membro da equipa.
Scrum Team
Scrum Team é a equipa ou time, que deve ter entre 6 a 10 pessoas. A metodologia
não propõe uma separação de cargo, tal como desenvolvedor ou analista de teste, por exemplo. Todos trabalham juntos em prol do objetivo final: entregar o que se
comprometeram no início do Sprint.
Além dos papéis a metodologia Scrum propõe alguns artefatos que devem ser
elaborados no início do projeto e atualizados ao longo do processo de desenvolvimento, são:
Product Backlog
É uma lista ou planilha que contém todas as funcionalidades que o Product Owner
definiu para o produto. O Product Backlog cresce e muda com o passar do tempo. Ele não costuma ser completo no primeiro momento. Isso porque o Product Owner prioriza na reunião de planeamento do Sprint (Sprint Planning Meeting) os itens que devem ser desenvolvidos e entregues no prazo. Entretanto, a equipa que avalia quais os itens que serão possíveis de entregar durante o Sprint que está iniciando.
Sprint Backlog
É uma lista de itens que o Scrum Team escolheu de acordo com a prioridade determinada pelo Product Owner. São as funcionalidades que a equipa se compromete a entregar dentro de um Sprint. Esses itens são retirados do Product Backlog. Cabe ao Scrum Master manter o Sprint Backlog atualizado.
Burndown Chart
É um gráfico que deve ser atualizado diariamente e que mede o progresso do
Sprint, bem como a parte do trabalho concluído em comparação ao trabalho planeado. Um exemplo de Burndown Chart é ilustrado na Figura 2.
Fonte: Google.
O eixo horizontal do gráfico representa os dias do Sprint (do primeiro ao último). O
eixo vertical representa os pontos ou esforços estimados (em horas) para compor o Sprint (máximo de horas estimadas até o zero). A linha reta em azul aponta o cenário planeado (o ideal), a linha vermelha que sobrepõe a linha reta indica o cenário atual, ou seja, a velocidade na qual a equipa está a caminhar. A linha verde próxima ao eixo horizontal indica o ritmo diário da equipa considerando os impactos e imprevistos que ocorreram durante o Sprint.
Além dos artefatos e os papéis o Scrum propõe as seguintes reuniões para
acompanhamento do projeto:
Sprint Planning Meeting
Trata-se de uma reunião em que devem estar presentes o Scrum Master, o Product
Owner e todos do Scrum Team.
O objetivo da reunião é que o Product Owner descreva as funcionalidades que ele
priorizou no Product Backlog e que a equipa faça perguntas para que fique bem claro o que deve ser feito e entregue ao fim do Sprint. Após a explicação, o Scrum Team seleciona as tarefas a cumprir.
Daily Scrum
É uma reunião diária que tem como objetivo permitir que cada integrante da equipa
relate o que foi realizado, passando todas as informações necessárias para deixar a equipa alinhada. É também o momento de identificar e solucionar impedimentos. Essa reunião deve durar no máximo 15 minutos. Geralmente é realizada na mesma hora e local. O mais indicado é realizar a Daily com todos os integrantes da equipa no período da manhã.
Sprint Retrospective
O Sprint Retrospective deve ocorrer no fim de um Sprint e cada membro do Scrum
Team relata os pontos positivos que contribuíram para o desempenho da equipa e as entregas no prazo que todos se comprometeram. É também o momento de informar os pontos a melhorar e que de alguma forma prejudicaram o desenvolvimento das tarefas, deixando claro o que não pode ocorrer no próximo Sprint. Esclarecidos esses pontos, é função do Scrum Master realizar ações para melhorar os pontos considerados negativos.
Sprint Review Meeting
É uma reunião realizada no final de cada Sprint em que o Scrum Team deve
apresentar o que foi alcançado durante o Sprint. Nessa reunião devem participar os Product Owner, o Scrum Master, o Scrum Team, a gerência e membros de outros projetos.
- Metodologia SCRUM em empresas de TI – Parte II - 23 de Julho, 2019
- Metodologia SCRUM em empresas de TI – Parte I - 13 de Junho, 2019