Utilizando-se da pesquisa bibliográfica e
descritiva, este estudo objetivou compreender a
natureza e aplicações da metodologia ágil Scrum. Fundamentada em textos
acadêmicos como artigos científicos e teses (ABRAHAMSSON et al., 2001) (LEITÃO, 2010)
(SCHWABER, 2007) (UCHÔA,
2019), bem como no guia desenvolvido pelos criadores do
Scrum (Scrum Guide) (SCHWABER, Ken; SUTHERLAND, Jeff, 2019), esta pesquisa
constitui-se num levantamento bibliográfico que pode compreender, conhecer e
descrever o cenário geral da referida metodologia ágil em seus aspectos
qualitativos. Verificou-se que o Scrum é um framework ideal para projetos complexos, pois sua aplicação
auxilia a entrega do projeto dentro do prazo e orçamento previsto, sempre
priorizando a entrega de resultados com maior valor para o cliente.
Palavras-chave: Scrum. Ágil. Gestão. Metodologia. Framework.
Software.
ESCOLA SUPERIOR
ABERTA DO BRASIL – ESAB
NATUREZA E APLICAÇÕES DO SCRUM
Elderson Luciano
Mezzomo[1]
Resumo
Utilizando-se da pesquisa bibliográfica e
descritiva, este estudo objetivou compreender a
natureza e aplicações da metodologia ágil Scrum. Fundamentada em textos
acadêmicos como artigos científicos e teses (ABRAHAMSSON et al., 2001) (LEITÃO, 2010)
(SCHWABER, 2007) (UCHÔA,
2019), bem como no guia desenvolvido pelos criadores do
Scrum (Scrum Guide) (SCHWABER, Ken; SUTHERLAND, Jeff, 2019), esta pesquisa
constitui-se num levantamento bibliográfico que pode compreender, conhecer e
descrever o cenário geral da referida metodologia ágil em seus aspectos
qualitativos. Verificou-se que o Scrum é um framework ideal para projetos complexos, pois sua aplicação
auxilia a entrega do projeto dentro do prazo e orçamento previsto, sempre
priorizando a entrega de resultados com maior valor para o cliente.
Palavras-chave: Scrum. Ágil. Gestão. Metodologia. Framework.
Software.
1 Introdução
Com
o advento dos computadores após a segunda guerra mundial e consequentemente o
desenvolvimento de softwares, surgiu a necessidade de gerenciar o seu
desenvolvimento. Mesmo aplicando-se metodologias conhecidas por outras
engenharias, a engenharia de software sofreu impacto pela alta demanda e baixa
produtividade (pois cerca de 84% dos projetos fracassavam ou não eram
concluídos até 1994 segundo a pesquisa CHAOS Report [THE STANDISH GROUP, 2019]). Atualmente o ambiente de desenvolvimento de
software enfrenta constantes alterações quanto aos requisitos durante o ciclo
de desenvolvimento do produto (RISING; JANOFF, 2000), o que acarreta o alto
índice de fracasso mencionado. Este ambiente propiciou surgimento de novas
metodologias de gestão do desenvolvimento de software, visando atender a
necessidade de agilidade e adaptação mais frequentes (o que não era contemplada
pelos métodos tradicionais).
Dentre
as metodologias de gestão de projetos de desenvolvimento de software, no âmbito
das metodologias ágeis, destaca-se o Scrum: um “um framework para desenvolver, entregar e manter produtos complexos” (SCHWABER, Ken; SUTHERLAND, Jeff, 2019).
O objetivo geral é compreender a
natureza e aplicações da metodologia ágil Scrum. Especificamente, objetiva-se demonstrar a origem e o significado do Scrum (sua
natureza), apresentar um cenário geral de aplicações da metodologia ágil Scrum
e pesquisar em que contexto a aplicação do Scrum é recomendável.
A
pesquisa bibliográfica sobre a “natureza e aplicações do Scrum” visa
compreender a natureza (demonstrando a origem e significado do Scrum), bem como
apresentar um cenário geral de suas aplicações e em qual contexto é recomendado
seu uso. Nesse intuito, a revisão bibliográfica apresenta aspectos da evolução
das metodologias de desenvolvimento de software até a criação do Scrum e os
contextos de suas aplicações.
A
pesquisa científica é tipificada segundo três critérios: por meio de seus
objetivos, fontes e procedimentos (RYTHOWEM; OLIVEIRA; SOARES FILHO, 2006).
Objetivando compreender a natureza e aplicações da metodologia ágil Scrum,
opta-se pela pesquisa bibliográfica e descritiva. Quanto às fontes, por se
tratar de uma pesquisa bibliográfica, a revisão da bibliografia fundamentou-se
em textos acadêmicos como artigos científicos e teses, bem como o guia
desenvolvido pelos criadores do Scrum. Em relação aos procedimentos a pesquisa
constitui-se num levantamento bibliográfico visando compreender, conhecer e descrever
o cenário geral da referida metodologia ágil (portanto, com aspectos
qualitativos).
2 Desenvolvimento
Com a criação do computador e sua popularização houve um aumento
significativo na demanda pelo desenvolvimento de softwares que pudessem
auxiliar nesse processo de automatização de processos manuais, avaliações de
situações complexas e outras atividades cotidianas das organizações e das
pessoas. Para atender esta demanda, criou-se modelos de desenvolvimento de
softwares visando atender necessidades específicas e, inclusive, elaboração de
softwares complexos (UCHÔA, 2019).
Por se tratar de um novo campo de conhecimento (engenharia da computação),
muitas metodologias foram adaptadas de outros campos da engenharia e muito
recentemente, surgiram inovações nesta área. Para maior compreensão deste
cenário, observar-se-á na literatura o histórico das evoluções das metodologias
de gestão de projetos de desenvolvimento de software classificadas em duas
áreas: metodologias tradicionais e ágeis.
No início da computação, poucos programadores seguiam algum tipo de
metodologia, desenvolvendo os sistemas na informalidade, o que é chamado hoje
de modelo balbúrdia ou caos (VALENTE, 2007). Neste modelo se limitavam apenas a
fase de implementação e fase de implantação, consistindo, o processo em “codificar-e-corrigir”
(ALMEIDA, 2017). O resultado da ausência de metodologias eram softwares
fracamente estruturados, correções caras e baixa aderência às necessidades dos
usuários.
Neste cenário surgiu o modelo stagewise que considera que o software
deve ser desenvolvido em estágios sucessivos: plano operacional, especificação
operacional, especificação de codificação, codificação, testes paramétricos,
testes de integração, organização e avaliação de sistemas (BENNINGTON, 1956).
Acrescentando-se ao modelo stagewise,
entre outras coisas, a possibilidade de voltar para a etapa precedente no caso
de sistemas complexos, surge o modelo cascata ou waterfall (ROYCE, 1970). Também
chamado de clássico, linear ou tradicional, o modelo cascata
é caracterizado por possuir uma tendência na progressão sequencial entre uma
fase e a seguinte, podendo haver, eventualmente, uma retroalimentação de uma
fase para a fase anterior (UCHÔA, 2019). A figura 1 exibe o modelo cascata:
Figura 1: modelo cascata
Fonte: Royce (1970)
Pode-se descrever o modelo cascata como uma abordagem sistemática e sequencial,
consistindo em:
começamos com o levantamento de requisitos ou
necessidades junto ao cliente, depois vamos para a fase de planejamento onde
definimos estimativas, cronograma e acompanhamento, após isso partimos para a
modelagem onde fazemos a análise e projeto, seguindo da construção onde
codificamos e testamos, passamos para a implantação ou emprego onde efetuamos a
entrega, suporte e feedback do software concluído (DEVMEDIA, 2019).
Os principais benefícios do modelo cascata são as etapas claras,
favorecendo a organização das equipes de desenvolvimento e as especificações de
requisitos pelos clientes. Sua ênfase “em documentos muito elaborados como
critérios de completude para fases primárias de requisitos e design” trouxe um
modo mais efetivo para o desenvolvimento de algumas classes como compiladores e
sistemas operacionais de segurança, “tornando-se a base para a maioria dos
padrões de desenvolvimento e de aquisição de software no governo e na
indústria” (ALMEIDA, 2017, pg. 25-26).
O ciclo de vida cascata, em detrimento de ainda ser muito utilizado
atualmente, traz consigo alguns problemas tais como: demora excessiva, grandes
quantidades de códigos não utilizados no final e alto risco. O cliente só
receberá o produto ao final do projeto, o que pode acarretar a obsolescência do
mesmo, pois é muito difícil para o cliente especificar todos os requisitos
inicialmente e incrementar algumas mudanças nos requisitos durante o projeto. Há
alto risco, pois se um erro for cometido no início e não detectado, só será
descoberto ao final, o que pode ser desastroso para o projeto. Acrescenta-se
ainda o fato que uma equipe tem que aguardar a equipe anterior completar sua
fase, para, só então, iniciar seu trabalho (DEVMEDIA, 2019).
Broehl e Droeschel (1995) propuseram uma variação do modelo cascata
conhecido como modelo em “V” ou vorgehensmodell, que consiste em explicitar a
dependência entre as atividades de desenvolvimento e as atividades de
verificação, conforme figura 2:
Figura 2: modelo em “V”
Fonte: Broeh e Droeschel (1995).
No modelo em “V”, todas a atividades têm um nível de representação cada
vez mais detalhada do sistema, e cada nível de detalhe é verificado e testado
(FRANCO, 2007).
Os modelos supramencionados abrangem, em sua maioria, métodos
prescritivos, pois visam estabelecer antecipadamente todos os requisitos.
Alguns trabalhos objetivam seguir padrões estabelecidos na teoria, como PMBOK (Project Management Body of Knowledge) e a certificação IPMA (International Project Management Association).
No entanto, tendo em vista algumas deficiências dos modelos apresentados, novos
modelos surgiram, que foram chamados de modelos ágeis.
As dificuldades na aplicação de métodos de gestão de projetos no
desenvolvimento de produtos inovadores suscitaram a busca por soluções
alternativas, isto é, “teorias com princípios, técnicas e ferramentas, mais
tarde rotuladas por Gerenciamento Ágil de Projetos – GAP” (AMARAL et al.,
2011). Uma metodologia é considerada ágil porque é incremental, com entregas
frequentes e pequenas (particionado), clientes e desenvolvedores trabalham
juntos, é simples e adaptativa (ABRAHAMSSON et al., 2002).
Baseado no modelo cascata e visando resolver o problema das mudanças
constantes, o modelo espiral busca corrigir seu antecessor ao dividir a tarefa
de levantar requisitos em etapas (que não ocorrem todas de uma vez). Mesmo
possuindo as mesmas etapas do modelo cascata, o modelo espiral as executa
várias vezes ao longo do ciclo de desenvolvimento, de forma espiral,
proporcionando várias entregas de software ao cliente (ESPIG, 2008). Essa
abordagem cíclica (observe a figura 3) resulta em entregas incrementais que
combinam a natureza iterativa da prototipagem com aspectos controlados e
sistemáticos (PAULA FILHO, 2009). As principais vantagens é a constante
interação com o cliente (e seus requisitos) e a gestão de riscos (avaliando
alternativas, identificando e resolvendo riscos).
Fonte: Boehn
(1986).
No bojo do modelo espiral, pode-se citar variações com características
de prototipação e iteratividade (repetição de atividade). A prototipação visa
possibilitar ao desenvolvedor e ao usuário examinarem antecipadamente os
requisitos (reduzindo-se as incertezas e os riscos). As etapas básicas da
iteração consistem em levantar um conjunto simples de requisitos, fazer testes
e experimentações, revisar, alterar e detalhar o sistema, passando então para a
codificação. Em seguida, apresenta-se novamente as alternativas, que são
discutidas com os usuários, e todo o processo se repete (VALENTE, 2007).
Ao dividir o desenvolvimento de um produto em ciclos, o modelo iterativo
e incremental apresenta fases como: de análise, projeto,
implementação e testes (UCHÔA, 2019). No cerne do princípio de iteração está o
foco em “dividir o trabalho em pacotes menores, ordenar por prioridades,
desenvolver e implantar um pacote por vez”. Já o termo incremental representa
cada entrega significativa ao cliente, significando “aumento, ou incremento, em
relação ao cenário anterior” (ESPIG, 2008).
Dentre os modelos iterativos e incrementais,
destacam-se o RUP-Rational Unified Process (Processo Unificado
Racional que é desenvolvido
e mantido pela Rational Software Corporation, uma divisão IBM) e o CMMI-Capability Maturity Integration (desenvolvido
pela Carnegie Mellon University através do seu órgão SEI-Software Engineering
Institute) (VALENTE, 2007).
Principalmente com foco nas mudanças e na adaptabilidade, um grupo de 17
notáveis se reuniram em 2001 e publicaram o “manifesto para desenvolvimento
ágil de software”:
Estamos descobrindo
maneiras melhores de desenvolver softwares, fazendo-o nós mesmos e ajudando
outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e
interações mais que processos e ferramentas
Software em
funcionamento mais que documentação abrangente
Colaboração com o
cliente mais que negociação de contratos
Responder a
mudanças mais que seguir um plano
Ou seja, mesmo
havendo valor nos itens à direita, valorizamos mais os itens à esquerda (AGILE
ALLIANCE, 2017).
Neste contexto, a ênfase recai sobre o dinamismo e flexibilidade
exigidos no cenário atual. Levando em consideração a satisfação dos clientes
com os requisitos e objetivos do produto, as empresas procuram tornar suas
equipes mais ágeis, pois, desta forma, tendem a produzirem softwares com mais
qualidade e que melhor atendem aos requisitos impostos pelos clientes, bem como
introduzir seus produtos no mercado com muito mais rapidez (COHN, 2011). No intuito
de atender essa demanda por maior agilidade, surgiram várias metodologias,
descritas brevemente na figura 4.
Fonte: Dyba,
T. e Dingsoyr, T. (2008).
Antes
de apresentar um cenário geral de aplicações da metodologia ágil Scrum e
pesquisar em que contexto a sua aplicação é recomendável, faz-se necessário
definir a origem, seu significado e como funciona o Scrum.
A
partir da necessidade de um desenvolvimento mais flexível a mudanças e de um
processo menos custoso comparado aos métodos tradicionais de desenvolvimento de
software, foram criadas as metodologias ágeis. O termo “metodologia ágil” foi
cunhado a partir da publicação do manifesto ágil em 2001. Para ser considerada
ágil, a metodologia deve ser incremental, com entregas pequenas e frequentes,
ser cooperativa (cliente e desenvolvedores trabalhando juntos), ser simples
(fácil de aprender, modificar e adaptar: suscetível a sofrer alterações) (ABRAHAMSSON
et al., 2001).
A
metodologia ágil Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland
para a gestão, desenvolvimento e manutenção de software (SCHWABER, 2007). O
termo “Scrum” foi uma comparação entre os desenvolvedores de software e os
jogadores de rúgbi. Scrum no rúgbi é uma jogada que consiste em uma rápida
reunião dos jogadores com a estratégia de levar o time inteiro (em um só bloco)
para o campo adversário, passando a bola entre os componentes do time (MELO,
2009).
O
time Scrum é descrito agindo de forma integrada, com times pequenos,
flexibilidade dos prazos e dos resultados e com colaboração e revisões
frequentes. Portanto, seu foco está no gerenciamento da equipe e na organização
dos processos, no modo de execução das atividades, delegando ao time a escolha
da melhor forma de concluir as etapas de desenvolvimento (SAVOINE, 2009).
Scrum
não é considerado apenas um processo ou técnica para a construção de produtos e
serviços, mas sim em um framework em que é possível empregar vários processos e
técnicas, sendo “leve, simples de entender e difícil de dominar” (SCHWABER,
Ken; SUTHERLAND, Jeff, 2019). Cabe destacar que cada membro do time Scrum está
associado:
a papéis, eventos, artefatos e regras. Cada
componente dentro do framework serve a um propósito específico e é
essencial para o uso e sucesso do Scrum.
As regras do Scrum integram os papéis,
eventos e artefatos, administrando as relações e interações entre eles (SCHWABER, Ken; SUTHERLAND, Jeff, 2019, pg. 3).
O Scrum adota os princípios do Manifesto Ágil e se fundamenta em teorias
empíricas de controle de processos (com decisões baseadas no que é conhecido) empregando
abordagem iterativa e incremental (com objetivo de aperfeiçoar a
previsibilidade e gestão de riscos) (SCHWABER,
Ken; SUTHERLAND, Jeff, 2019).
O
controle de processos prescritos pelo Scrum está apoiado em três pilares:
transparência (com visibilidade e garantia de mesma compreensão dos aspectos
mais relevantes por todos os responsáveis), inspeção (diligente e frequente a
fim de detectar variações indesejadas em direção ao objetivo da sprint) e
adaptação (com ajuste o mais breve possível para minimizar os desvios
indesejáveis). A inspeção e adaptação devem ser realizadas durantes os seguintes
eventos formais: planejamento da sprint, reunião diária, revisão da sprint e
retrospectiva da sprint (SCHWABER, Ken; SUTHERLAND, Jeff, 2019). O
time Scrum deve incorporar os valores de comprometimento, coragem, foco,
transparência e respeito, pois:
O Sucesso no uso do Scrum depende das pessoas
se tornarem mais proficientes na vivência destes cinco valores. As pessoas se
comprometem pessoalmente em alcançar os objetivos do Time Scrum. O Time Scrum
precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis.
Todos focam no trabalho da Sprint e nos objetivos do Time Scrum. O Time Scrum e
seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios
com a execução dos trabalhos. Os membros do Time Scrum respeitam uns aos outros
para serem pessoas capazes e independentes (SCHWABER,
Ken; SUTHERLAND, Jeff, 2019,
pg. 5 e 6).
Além dos valores do Scrum, conforme o pilar da transparência, é de suma
importância a definição de “pronto” da entrega prescrita no backlog do produto.
De acordo com Schwaber e Sutherland (2019), a definição de pronto deve ser
clara e compartilhada por todos os membros do time Scrum, assegurando a
transparência sobre quando o trabalho está completo e aceitável com a entrega
de um incremento utilizável.
O funcionamento do Scrum é apresentado pelo diagrama de SIPOC (Supplier,
Inputs, Process, Outputs e Customers) do Scrum, que é uma ferramenta utilizada
para identificar os elementos do processo: entradas, saídas, papeis, artefatos
e eventos envolvidos. Através do SIPOC, pode-se observar a interação durante o
processo Scrum na figura 5:
Fonte: Expedith
(2019).
O funcionamento do Scrum, portanto, está baseado nos três pilares
(transparência, inspeção e adaptação), fundamentados em cinco valores
(comprometimento, coragem, foco, transparência e respeito), desenvolvidos ao
longo de cinco eventos (sprint, planejamento da sprint, reunião diária, revisão
da sprint e retrospectiva da sprint) e cumpridos por três papeis (Product Owner,
time de desenvolvimento e Scrum Master) que produzem três artefatos (backlog do
produto, backlog da sprint e incremento)
(SCHWABER, Ken; SUTHERLAND, Jeff, 2019).
O framework Scrum traz três papeis bem definidos: Product Owner (dono do
produto), time de desenvolvimento (dev team) e Scrum Master (mestre Scrum).
Todos os papeis são imprescindíveis e a equipe deve ser composta de 5 a 11
membros, possuindo todas as competências necessárias para compor o incremento e
sem auxílio de equipes externas (CUNHA, 2009).
O Product Owner representa o cliente (em alguns casos é o próprio
cliente), é o único responsável pelo escopo, mantem uma lista priorizada de
requisitos do projeto (backlog do produto) com estimativas de tempo para sua
implementação e visando sempre a maximização do valor do produto (gerenciando o
ROI-retorno sobre o investimento, objetivando sempre maior lucratividade/valor).
Cabe ao Product Owner também, expressar claramente os itens do backlog do
produto, garantindo que seja transparente, visível e claro para todos, bem como
a aceitação ou não do incremento (de acordo com a definição de pronto) (LEITÃO,
2010) (SCHWABER, Ken; SUTHERLAND, Jeff, 2019).
O time de desenvolvimento é composto por cinco a nove integrantes e responsável
pelo trabalho de desenvolvimento. Deve ser auto organizável, multidisciplinar, com
todas as competências necessárias para a elaboração do incremento (conforme
definição de pronto) e com autoridade para realizar a sua organização e
gerenciamento, ou seja, responsável por selecionar os itens do backlog que serão
executados a cada iteração. O time de desenvolvimento deve entregar incremento(s)
pronto(s) a cada sprint e não há títulos (distinção) entre seus membros
(LEITÃO, 2010) (SCHWABER, Ken;
SUTHERLAND, Jeff, 2019).
Já o Scrum Master age como suporte do time Scrum e promotor do Scrum
perante o time e à organização. Cabe ao Scrum Master garantir que todos
compreendam e sigam as regras do Scrum, agindo como líder-servidor ao remover
impedimentos (bloqueios), auxiliando o Product Owner (encontrando técnicas de
gerenciamento do backlog do produto e contribuindo para que os itens estejam
claros e concisos para o time de desenvolvimento) e servindo de escudo ao time
de desenvolvimento (para evitar interferências externas). Ele não gerencia
a equipe, mas ajuda a compreender a auto-gestão e a interdisciplinaridade e,
principalmente, deve garantir os eventos Scrum
(SCHWABER, Ken; SUTHERLAND, Jeff, 2019).
Os eventos Scrum consistem em sprint (arrancada), planejamento da sprint
(sprint planning meeting), reunião diária (daily meeting), revisão da sprint (sprint
review) e retrospectiva da sprint (sprint retrospective). Todos os eventos possuem
time-boxed (caixas de tempo), ou seja, tempo predeterminados, “de tal modo que
todo evento tem uma duração máxima. Uma vez que a Sprint começa, sua duração é
fixada e não pode ser reduzida ou aumentada”
(SCHWABER, Ken; SUTHERLAND, Jeff, 2019, pg. 9). Observe a descrição do ciclo do Scrum na figura
6:
Fonte: Valente
(2007).
A Sprint é considerada o núcleo do Scrum. Seu time-boxed é geralmente
entre 2 a 4 semanas, devendo entregar um incremento a cada iteração (LEITÃO, 2010).
A sprint só pode ser cancelada pelo Product Owner e o motivo é quando o objetivo
se torna obsoleto. Durante a sprint não são feitas mudanças que coloquem em
perigo seu objetivo e as metas de qualidade não diminuem. Dentro da sprint
encontram-se os demais eventos: reunião diária, planejamento, revisão e retrospectiva
da sprint (SCHWABER, Ken; SUTHERLAND,
Jeff, 2019).
Com no máximo 8 horas para uma sprint de 1 mês, o planejamento da sprint
ocorre com a reunião entre o time de desenvolvimento e o Product Owner para
priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que
podem ser realizadas dentro da sprint, resultando assim no backlog da sprint
(LEITÃO, 2010) (SCHWABER, Ken;
SUTHERLAND, Jeff, 2019).
Durante a execução da sprint, o Scrum Master assegura que serão
realizadas reuniões diárias de 15 minutos para o time de desenvolvimento.
Nestas reuniões:
o Time de Desenvolvimento planeja o trabalho
para as próximas 24 horas. Isso otimiza a colaboração e a performance do time
através da inspeção do trabalho desde a última Reunião Diária, e da previsão do
próximo trabalho da Sprint. A Reunião Diária é mantida no mesmo horário e local
todo dia para reduzir a complexidade.
[...]
Alguns Times de Desenvolvimento utilizarão
perguntas, outros se basearão em discussões. Aqui segue um exemplo do que pode
ser utilizado:
• O que eu fiz ontem que ajudou o Time de
Desenvolvimento a atingir a meta da Sprint?
• O que eu farei hoje para ajudar o Time de
Desenvolvimento atingir a meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou
o Time de Desenvolvimento no atingimento da meta da Sprint? (SCHWABER, Ken; SUTHERLAND, Jeff, 2019, pg. 12).
Ao final de cada iteração é realizada a revisão da sprint (de no máximo
4 horas para uma sprint de 1 mês). Na revisão da sprint o time de
desenvolvimento apresenta ao Product Owner um incremento potencialmente
entregável, o qual será (pelo Product Owner) aceito ou não. O resultado desse
evento inclui um backlog do produto revisado (que podem ser ajustados para
atenderem novas oportunidades) e com a definição de prováveis itens de backlog
do produto para a próxima sprint (SCHWABER,
Ken; SUTHERLAND, Jeff, 2019).
Por fim, enquanto a revisão da sprint foca o produto, a retrospectiva da
sprint (com duração de até 3 horas para uma sprint de 1 mês) foca no processo,
ou seja, é uma reunião que visa melhorar o processo/time (e por consequência o
produto) ao analisar a execução do projeto e as lições aprendidas que poderão
ser implementadas na próxima sprint. A retrospectiva da sprint é o evento
formal direcionado para inspeção e adaptação da equipe quanto aos seus
relacionamentos, processos e ferramentas utilizadas, identificação de
potenciais melhorias e criação de um plano para implementar tais melhorias (SCHWABER, Ken; SUTHERLAND, Jeff, 2019).
Vale ressaltar que durante a execução dos eventos Scrum, mesmo não sendo
definidos pelo Guia Scrum, são comumente utilizadas algumas ferramentas como o
quadro kanban, gráfico burndown, histórias de usuários, método planning poker,
etc. Estas técnicas e ferramentas aplicadas nos eventos Scrum auxiliam no dia a
dia na elaboração de seus artefatos.
Os artefatos produzidos através dos eventos Scrum são três: backlog do
produto, backlog da sprint e incremento. De acordo com Schwaber e Sutherland,
os artefatos foram definidos especificamente para “maximizar a transparência
das informações chave de modo que todos tenham o mesmo entendimento dos
artefatos” (SCHWABER, Ken; SUTHERLAND,
Jeff, 2019, pg. 12).
De responsabilidade do Product Owner, o backlog do produto é uma lista
de itens priorizados (baseados em valor) a serem desenvolvidos na sprint,
sempre associados a um valor do negócio, permitindo assim o controle e
gerenciamento do negócio. O backlog do produto deve listar:
todas as características, funções, requisitos, melhorias
e correções que formam as mudanças que devem ser feitas no produto nas futuras
versões. Os itens do Backlog do Produto possuem os atributos de descrição,
ordem, estimativa e valor. Os itens do Backlog geralmente incluem descrições de
testes que comprovarão sua completude quando “Prontos” (SCHWABER, Ken; SUTHERLAND, Jeff, 2019, pg. 14).
Já o backlog da sprint é uma lista de tarefas extraídas do backlog do
produto, sendo de competência do time de desenvolvimento selecionar e dividir
cada uma, de modo que tenham “de 4 a 16 horas de atividade para sua finalização
e somente a equipe pode alterar o Sprint Backlog, não sendo aceita a
intervenção de clientes, gerentes, usuários (chickens) durante o curto
tempo de uma sprint” (LEITÃO,
2010, p. 39). Juntamente com a lista de itens a serem entregues ao final
da sprint, estará seu respectivo plano “para entregar o incremento do produto e
atingir o objetivo da sprint” (SCHWABER, Ken;
SUTHERLAND, Jeff, 2019, pg.
16).
O total de todos os itens do backlog do produto completados (prontos)
constituem-se no incremento. Portanto, incremento é o artefato do Scrum “que
deve estar na condição de ser utilizado e atender a definição de “Pronto” do
Time Scrum” (SCHWABER, Ken; SUTHERLAND,
Jeff, 2019, pg. 16).
Ao
considerar a natureza do Scrum com seu conceito e funcionamento, pode-se
destacar, conforme o guia GUIA
SBOK™ (2019), algumas características: adaptabilidade (os projetos podem ser adaptáveis e abertos às
mudanças), transparência (todas
as informações são compartilhadas), feedback
contínuo (fornecido através das reuniões diárias), melhoria contínua (as entregas
melhoram progressivamente, etapa por etapa), entrega contínua de valor (processo iterativo que permite entrega
contínua de valor tão frequente quanto exigido pelo cliente), ritmo sustentável (as pessoas envolvidas
trabalham num determinado ritmo, que poderiam continuar sempre), entrega antecipada de valor (garante que
as exigências de maior valor, sejam atendidas primeiramente), processo de desenvolvimento eficiente (minimiza
o trabalho não essencial, conduz a níveis de alta eficiência), motivação (processo de conduzir
reunião diária e retrospectiva dos demais processos no qual conduz a motivação
dos colaboradores), solução dos
problemas de forma mais rápida (a colaboração e times multifuncionais
que conduzem a resolução de problemas), entregas
eficazes (revisões periódicas que garante entregas eficazes ao cliente),
foco no cliente (ênfase no valor
do negócio que garante uma estrutura orientada), ambiente de alta confiança (reunião diária e retrospectiva Sprint
que promove transparência e colaboração, resultando num ambiente de alta
confiança e garantindo baixos atritos), responsabilidade
coletiva (processo de aprovar, estimar e comprometer ao usuário, no qual
possibilita se sentir responsável pelo projeto e pelo seu trabalho, resultando
numa qualidade melhor), alta velocidade
(estrutura de colaboração que permite fins qualificados, com potencial e
alta velocidade) e ambiente inovador (ambiente
de introspecção, aprendizagem e adaptabilidade, que gera um ambiente de
trabalho inovador e criativo).
Além do GUIA SBOK™, outros autores corroboram a visão que o Scrum gera
vários benefícios, como:
aumento da satisfação de clientes, por meio
da diminuição das reclamações (MANN; MAURER, 2005; SALO; ABRAHAMSSON, 2008);
melhoria na comunicação e aumento da colaboração entre envolvidos nos projetos
(BERCZUK, 2007); aumento do retorno do investimento em projetos de novos
produtos (SULAIMAN; BARTON; BLACKBURN, 2006; SUTHERLAND, 2005); aumento da
motivação da equipe de desenvolvimento de produtos (KNIBERG; FARHANG, 2008;
PAASIVAARA; DURASIEWICZ; LASSENIUS, 2008); melhoria da qualidade do produto
produzido (SUTHERLAND et al., 2008; BARTON; CAMPBELL, 2007); diminuição dos
custos de produção (SUTHERLAND et al., 2007; BRUEGGE; SCHILLER, 2008); aumento
de produtividade da equipe de desenvolvimento (SUTHERLAND et al., 2008; MARÇAL
et al., 2007); diminuição no tempo gasto para terminar projetos de
desenvolvimento de novos produtos (SUTHERLAND et al., 2008; SANDERS, 2007); e
diminuição do risco em projetos de desenvolvimento de novos produtos (EDWARDS,
2008) (apud CARVALHO, Bernardo
Vasconcelos de; MELLO, Carlos Henrique Pereira, 2012, pg. 560).
Mesmo
diante dos vários benefícios do Scrum apresentados acima, é certo que o Scrum
não se constitui em “remédio” para todos os problemas. Para a compreensão de
quais situações pode-se empregar o framework Scrum, a abordagem do Cynefin pode
auxiliar.
O
Cynefin é um framework aplicado na gestão de mudanças e ajuda a classificar os
sistemas/problemas em 5 categorias: simples, complicado, complexo, caótico e
desordenado.
Figura 7: descrição do framework Cynefin
Fonte: Parola
(2019).
Utilizando
o Cynefin como base para classificação de sistemas e projetos, podemos concluir
que o Scrum é mais indicado para projetos complexos, pois:
O contexto complexo é caracterizado pela
imprevisibilidade, onde as causas são conhecidas, mas não se conhece os efeitos
oriundos das soluções escolhidas. Esses efeitos começam a ser percebidos ao
longo do caminho, e por isso, a necessidade do uso de metodologias e padrões
que priorizem o aprendizado através da experimentação e a rápida resposta a
mudanças (PAROLA, 2019).
Para
os autores do Scrum Guide, o Scrum tem sido usado amplamente para desenvolver e
gerenciar a operação de “quase
tudo que usamos em nosso dia-dia nas nossas vidas, como indivíduos e
sociedades” (SCHWABER, Ken; SUTHERLAND,
Jeff, 2019, pg. 4): software, hardware, software embarcado,
redes de funções interativas, veículos autônomos, escolas, governo, marketing,
empresas, etc.
O Scrum está sendo extensivamente
aplicado no mundo para pesquisa (de mercados viáveis, tecnologias e
funcionalidades de produtos), desenvolvimento, renovação e sustentação (de
produtos e melhorias), a liberação de produtos e melhorias frequentes (chegando
a várias vezes por dia) e o desenvolvimento e sustentação de ambientes
operacionais para uso de produtos, dentre outros. Portanto, o Scrum tem sido
efetivo na transferência de conhecimento iterativo e incremental e sua
utilidade em lidar com a complexidade é provada diariamente (SCHWABER, Ken; SUTHERLAND, Jeff, 2019).
3 Conclusão
Utilizando-se da pesquisa bibliográfica e descritiva, foi possível compreender a natureza e aplicações da metodologia
ágil Scrum. Fundamentada em textos acadêmicos como artigos científicos e teses,
bem como no guia desenvolvido pelos criadores do Scrum (Scrum Guide), esta
pesquisa constitui-se num levantamento bibliográfico que pode compreender,
conhecer e descrever o cenário geral da referida metodologia ágil em seus aspectos
qualitativos.
Verificou-se
que o Scrum é um framework
ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos (classificados
como projetos complexos), pois sua aplicação (utilizando prática enxutas) auxilia
a entrega do projeto dentro do prazo e orçamento previsto, sempre priorizando a
entrega de resultados com maior valor para o cliente.
Mesmo constatando-se a
tendência do uso de metodologias ágeis, evidenciou-se que o framework Scrum não
é adequado para todos os
tipos de organizações ou projetos, e sim para aqueles considerados complexos. Por
ser um framework relativamente recente, e como sua própria natureza prescreve, o
Scrum, bem como as demais metodologias ágeis, suscita mais pesquisas acadêmicas,
que levarão a aperfeiçoamentos e novas descobertas e aplicações.
Referências
AGILE
ALLIANCE. Agile aliance: Manifesto para desenvolvimento ágil de software.
Disponível em: <http://agilemanifesto.org/iso/ptbr/manifesto.html>.
Acesso em: 02 abr. 2019.
ABRAHAMSSON,
P.; HANHINEVA, A.: HULKKO, H.; IHME, T.; JÃALINOJA, J.; KORKALA, M.; KOSKELA,
J.; KYLLONEN, P.; SALO, O. Mobile-d: Na agile approach for mobile
application development. Proc of the OOPSLA’04 Conference, 2001.
ALMEIDA, Guilherme
Augusto Machado. Fatores de escolha entre metodologias de desenvolvimento de
software tradicionais e ágeis. Dissertação apresentada à Escola Politécnica
da Universidade de São Paulo para obtenção do título de Mestre em Ciências. São
Paulo, 2017.
AMARAL, D.
C., CONFORTO, E. C., BENASSI, J. L. G., & ARAUJO, C. (2011). Gerenciamento
ágil de projetos: aplicação em produtos inovadores. São Paulo: Saraiva.
BENNINGTON,
H. D. Production of large computer programs. Symposium on Advanced
Programming Methods for Digital Computers, 1956. 15-27.
BOEHM, B. A.
A spiral model of software development and enhancement. SIGSOFT Softw. Eng. Notes, New York,
v. 11, n. 4, p. 14-24, 1986.
BROEHL, A.
P.; DROESCHEL, W. Das V-model: Der Standard fuer die SOftwareentwicklung mit
Praxisleitfaden. 2ª. ed. München: Oldenbourg Verlag, 1995.
CARVALHO, Bernardo
Vasconcelos de; MELLO, Carlos Henrique Pereira. Aplicação do método ágil
scrum no desenvolvimento de
produtos de software em uma
pequena empresa de base tecnológica. Gest. Prod., São Carlos, v. 19, n. 3, p. 557-573,
2012.
COHN, Mike. Desenvolvimento de Software com Scrum: Aplicando métodos ágeis com sucesso. Porto Alegre: Bookman
Companhia Editora Ltda., 2011.
CUNHA, Thiago Ferraz Vieira da. SLeSS 2.0:
uma evolução da abordagem de integração do Scrum e Lean Six Sigma para
aplicações móveis. 2009. Dissertação (Mestrado em Ciência da Computação) – Departamento
de Computação, Mestrado e Doutorado em Ciência da Computação, Universidade
Federal do Ceará.
DEVMEDIA. Introdução ao modelo cascata. Disponível
em: <https://www.devmedia.com.br/introducao-ao-modelo-cascata/29843>.
Acesso em: 02 abr. 2019.
DYBA, T.; DINGSOYR, T. Empirical studies
of agile software development: a systematic review. Information and
software technology, v. 50, 833-859,
2008.
ESPIG, Robson
Silva. A
Disponível
em: <www.scrumalliance.org/resource_donwload/2378>. Acesso em: 27 abr.
2019.
FRANCO, M. A. P. Uma abordagem baseada em atividades para gestão e determinação de
custos do processo na engenharia de requisitos. USP, São Paulo: Dissertação
de Mestrado, 2007.
LEITÃO, Michele de Vasconcelos. Aplicação de
Scrum em ambiente de desenvolvimento de software educativo. 2010. Monografia
(Bacharelado em Engenharia da Computação) –Escola Politécnica de Pernambuco,
Universidade de Pernambuco.
GUIA SBOK™. Um guia para o conhecimento em
Scrum. SCRUM Study™, 2016. Disponível em:
<https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016-Portuguese.pdf>.
Acesso em: 28 abr. 2019.
MELO, Nilton Silva de. Adequação da
metodologia ágil Scrum à produção de advergames. 2009. Dissertação
(Mestrado Profissional em Ciência da Computação) – Centro de Informática, Universidade
Federal de Pernambuco.
PAROLA, Davi. Entendendo o modelo Cynefin. Dá pra usar em qualquer empresa, inclusive
na caixa!
PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 3. ed. Rio de
Janeiro: Ltc – Livros Técnicos e Científicos Editorial S.a., 2009.
RISING, L.;
JANOFF, N. S. The Scrum software development process for small teams.
IEEE Software, v. 17, n. 4, p. 26-32, 2000. Disponível em: <http://dx.doi.org/10.1109/52.854065>. Acesso em: 12 mar. 2019.
RYTHOWEM, M.; OLIVEIRA, T. M. DE; SOARES FILHO, V. Metodologia da Pesquisa. Palmas: Unitins, 2006.
ROYCE, W. W. Managing the development of
large software systems - Concepts and techniques. WESCON Technical Papers, Los Angeles, 1970.
SAVOINE,
M. Análise de Gerenciamento de Projeto de
Software Utilizando Metodologia Ágil XP e Scrum: Um Estudo de Caso Prático. In: XI Encontro de Estudantes de Informática
do Tocantins, 2009, Palmas. Anais do XI Encontro de Estudantes de Informática
do Tocantins.
SCHWABER, Ken. Agile Project management with
Scrum. [S.l.]: Microsoft Press, 2007.
SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum -
Um guia definitivo para o Scrum: as regras do jogo. Trad. Fábio Cruz e
Eduardo Rodrigues Sucena. Disponível em: <https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf>.
Acesso em: 10 mar. 2019.
THE STANDISH GROUP. The Chaos Report (1994).
Disponível em:
<https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf>.
Acesso em: 02 abr. 2019.
UCHÔA, Juliana Prado. Evolução da metodologia do
desenvolvimento de sistemas. Disponível em <http://www.linhadecodigo.com.br/artigo/2108/evolucao-da-metodologia-do-desenvolvimento-de-sistemas.aspx>.
Acesso em: 02 abr. 2019.
VALENTE, Carlos. Engenharia de software.
ESAB: Escola Superior Aberta do Brasil, 2007.
[1]
Pós-graduando em Engenharia de Sistemas na Escola Superior Aberta do Brasil –
ESAB. eldersonmezzomo@hotmail.com