UTILIZAÇÃO DO SCRUM NO DESENVOLVIMENTO ÁGIL DE SOFTWARE V2.1

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB
UTILIZAÇÃO DO SCRUM NO DESENVOLVIMENTO ÁGIL DE SOFTWARE
Marcus Vinícius Corrêa de Souza
RESUMO
Este estudo teve o objetivo de analisar uma estrutura dentro da qual as pessoas que trabalham com o gerenciamento e desenvolvimento de Software, podem lidar com problemas adaptativos complexos, enquanto produzem de forma produtiva e criativa produtos do mais alto valor possível. Dentre os autores pesquisados para a constituição conceitual deste trabalho, destacaram-se RAFAEL SABBAGH (1998), KEN SCHWABER (2016), JEFF SUTHERLAND (2016), ARMONY, R. S. (2010) e COCKBURN, A. (2007). A metodologia utilizada foi a pesquisa exploratória, tendo como coleta de dados o levantamento bibliográfico. As conclusões mais relevantes são apresentar as principais características da utilização do framework Scrum com o objetivo de reduzir os riscos de insucesso e entregar valor de forma ágil, se preparando melhor para as mudanças inevitáveis em sistemas complexos, transformando assim em vantagem competitiva da organização que se utilizam das técnicas Scrum, consequentemente entregando maior qualidade no produto gerado.
Palavras-chave: Scrum. Métodos Ágeis. Gestão de Projetos. Desenvolvimento de Software.
Introdução
A Utilização do Scrum no Desenvolvimento Ágil de Software tem se mostrado ser uma vantagem competitiva da Organização em um mercado cada vez acirrado, onde a busca por conhecimento e aprimoramento tecnológicos do controle dos processos podem definir o sucesso ou fracasso de um Projeto.
Neste sentido, organizações que procuram melhoria em seus processos de produção através de populares frameworks de gestão como Capabitity Maturity Model Integration (CMMI), COBIT, ITIL, entre outros, agora também acreditam que introduzir conceitos ágeis em seus processos buscando um equilíbrio entre agilidade e maturidade é uma alternativa capaz de promover a melhoria da qualidade dos seus produtos e, consequentemente, aumento da competitividade no mercado ARMONY, R. S. (2010).
O objetivo deste estudo é apresentar as principais características, benefícios e dificuldades na utilização e implementação do Scrum, que se destaca principalmente por ter um custo de implementação inferior as metodologias tradicionais de desenvolvimento de Software, trazendo assim mudanças benéficas do ciclo de desenvolvimento, como boa comunicação entre a equipe, entrega de valor em curto espaço de tempo, produtividade e consequentemente a satisfação do cliente.
Esta pesquisa justifica-se na importância do entendimento e utilização do Scrum como método ágil de desenvolvimento em um ambiente competitivo, sua utilização não exige experiência no desenvolvimento, mas um treinamento adequado para que as normas sejam obedecidas. Os métodos ágeis apresentam soluções práticas em menor tempo, por dispenderem mais atenção ao produto que ao processo, fato que torna o método Scrum, um dos métodos de gerenciamento ágil de projetos mais utilizado (BASSI FILHO, 2008; COCKBURN, 2007).
A pesquisa realizada no projeto tem propósito de levantar as vantagens da utilização da metodologia ágil Scrum no desenvolvimento ágil de Software. Sua abordagem será de caráter qualitativo. Quanto ao seu objetivo, a pesquisa é caracterizada como exploratória, fazendo uso de procedimento técnico bibliográfico 
Desenvolvimento
Existem várias metodologias ágeis no mercado, entretanto o Scrum se destaca por ser uma metodologia baseada nas melhores práticas, usadas e comprovadas por décadas e em crescimento constante nos ambientes de desenvolvimento de software. “Resultando em uma abordagem que reintroduz as ideias de flexibilidade, adaptabilidade e produtividade” [KEN SCHWABER 2016]
Segundo a definição da Scrum Alliance (2015), Scrum é um framework simples e pequeno e, assim, funciona bem em cada contexto se for usado em conjunto com outras técnicas e práticas a serem escolhidas, experimentadas e adaptadas.
Scrum Alliance (2015) afirma que uma das principais características do Scrum ou de qualquer outra metodologia de desenvolvimento ágil, é em fornecer valor ao negócio no início do projeto, reduzindo assim os riscos de não comprimento do contrato.
De acordo com RAFAEL SABBAGH (1998) em seu livro Scrum gestão ágil para projetos de sucesso, Scrum é um framework Ágil, simples e leve, sua aplicação depende de um grupo de pessoas que possuem seus papeis definidos, trabalhem juntas e colaborem em busca de um objetivo comum, esta metodologia possui como prioridade o correto gerenciamento da equipe de forma produtiva. 
As pessoas na equipe são mais importantes do que seus papéis em diagramas de processos. Assim, embora descrições de processos possam ser necessárias para se começar o trabalho, as pessoas envolvidas nos processos não podem ser trocadas como peças, Cockburn (2007).
Papéis Scrum.
Segundo definição da Scrum Alliance (2015), apenas três papéis são definidos pelo Scrum: o Time de Desenvolvimento, o Product Owner e o ScrumMaster. As pessoas que desempenham esses papéis são igualmente responsáveis e responsabilizadas pelos resultados do trabalho e, assim, se comprometem com o projeto.
Time de Desenvolvimento
Segundo ARMONY, R. S. (2010) o Time de Desenvolvimento é um grupo multidisciplinar de pessoas, responsável por realizar o trabalho de desenvolvimento do produto de ponta a ponta, possui entres seus membros todos os conhecimentos e habilidades necessários para realizar o trabalho de desenvolvimento do produto, evitando assim dependências externas, possui autonomia, dentro de limites estabelecidos pelo Scrum e pelo contexto organizacional, para realizar seu trabalho da forma que considerar mais apropriada, planejando-o, acompanhando seu progresso e buscando suas próprias soluções para os problemas que surgirão pelo caminho.
KEN SCHWABER (2016), entende que a equipe de desenvolvimento usa o Scrum diário para inspecionar o progresso em direção ao objetivo Sprint e para inspecionar como o progresso está tendendo para completar o trabalho no Sprint Backlog. O Scrum diário otimiza a probabilidade de que a equipe de desenvolvimento atenda ao objetivo da Sprint. 
Product Owner
A organização Scrum Alliance, afirma em: “O guia definitivo para Scrum” que o Product Owner, também chamado de P.O., é a pessoa responsável pela definição do produto, trabalho que é realizado de forma incremental ao longo de todo projeto. Seu objetivo primário é garantir e maximizar, a partir do trabalho do Time de Desenvolvimento, o retorno sobre o investimento para os clientes do projeto, satisfazendo suas necessidades com relação ao produto em desenvolvimento, ele é quem define qual o produto a ser desenvolvido, Incremento a Incremento. Ele é, de fato, o gerente do produto em um projeto que utiliza Scrum.
De acordo com JEFF SUTHERLAND (2016) o Product Owner é a única pessoa responsável pelo gerenciamento do Product Backlog. O gerenciamento de Backlog de produtos inclui:
“Claramente expressando itens de Backlog de produtos”;
“Encomendar os itens no Product Backlog para melhor atingir metas e missões”;
“Otimizar o valor do trabalho desenvolvido pela Equipe de Desenvolvimento”;
“Garantir que o Backlog do Produto seja visível, transparente e claro para todos e mostre o que a Equipe do Scrum trabalhará em seguida”; 
“Assegurar que a Equipa de Desenvolvimento entenda os itens no Backlog de Produtos para o nível necessário”.
Scrum Master
Na concepção da Scrum Alliance (2015), Scrum Master é o profissional que trabalha para facilitar e potencializar o trabalho do Time de Scrum. Ou seja, utilizando-se de seu conhecimento de Scrum, habilidade de lidar com pessoas, técnicas de facilitação e outras técnicas, ele ajuda o Product Owner e Time de Desenvolvimento a serem mais eficientes na realização do seu trabalho, com Scrum, o trabalho de gestão do projeto é distribuído pelos seus três papéis, ou seja, pelos membros do Time de Scrum. Assim, não há um Gerente de Projetos como é tradicionalmente definido.
Além de facilitar
o dia a dia de trabalho do Time de Scrum, o Scrum Master tem a importante função de atuar como um facilitador nos eventos do Scrum. Ele estimula os envolvidos a participarem ativamente das discussões, ajuda-os a manter o foco nos objetivos do evento e a chegarem a suas próprias conclusões, RAFAEL SABBAGH (1998).
Michael Wilkinson (2004), no livro The secrets of facilitation: the S.M.A.R.T. guide for getting results with groups, define uma sessão facilitada como: um encontro altamente estruturado no qual o facilitador “Scrum Master” guia os participantes por meio de uma série de passos predefinidos para que cheguem a um resultado que é criado, compreendido e aceito por todos os participantes. Ainda segundo o autor, técnicas de facilitação são apropriadas sempre que um grupo necessita de compreensão comum e aceitação para obter sucesso em se chegar a um determinado resultado.
Eventos Scrum
O time Scrum precisa organizar o desenvolvimento do projeto através de eventos e segundo JEFF SUTHERLAND (2016), os eventos Scrum são usados para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. Todos os eventos são eventos time-boxed, 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. Os eventos restantes podem terminar sempre que o propósito do evento é alcançado, garantindo que uma quantidade adequada de tempo seja gasta sem permitir perdas no processo.
Eventos do Scrum descreve as reuniões de Sprint Planning, de Daily Scrum, de Sprint Review e de Sprint Retrospective.
Sprint Planning
Scrum Alliance (2015), afirma que Reunião de Sprint Planning conta com a participação obrigatória do ScrumMaster, que atua como um facilitador, do Product Owner e dos membros do Time de Desenvolvimento. Os dois últimos colaboram e negociam o que será desenvolvido e qual o objetivo deve ser realizado a partir do produto do trabalho realizado nesse Sprint a Meta do Sprint.
Daily Scrum
JEFF SUTHERLAND (2016), entende que Daily Scrum é uma reunião curta realizada diariamente pelo Time de Desenvolvimento. Ela tem a duração máxima ou o timebox de quinze minutos, e acontece preferencialmente no mesmo local e na mesma hora, para que o time se acostume a realizá-la.
Sprint Review
A reunião de Sprint Review (ou revisão do Sprint), o Time de Desenvolvimento e o Product Owner trabalham em conjunto, com a facilitação do ScrumMaster, para demonstrar o trabalho pronto produzido durante o Sprint, para clientes do projeto e demais partes interessadas. Seu principal objetivo é a obtenção de feedback antecipado dessas pessoas sobre o Incremento do Produto produzido, já que um feedback mais concreto e profundo só poderá ser obtido após a entrega para seus usuários, Scrum Alliance (2015).
Sprint Retrospective
De acordo com o manifesto Ágil (1997), o Objetivo da Sprint Retrospective é a melhoria incremental contínua na forma como o Time de Scrum faz o seu trabalho (inspeção e adaptação), ela acontece no último dia de cada Sprint, após a reunião de Sprint Review é obrigatório a participação do Time de Desenvolvimento, Product Owner e ScrumMaster.
Um termo bastante utilizado nas metodologias ágeis é o “Sprint” considerado por KEN SCHWABER (2016) o coração do Scrum, as Sprints têm durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.
Para RAFAEL SABBAGH (1998), O coração do Scrum é um Sprint, uma caixa de tempo de um mês ou menos, durante a qual é criado um incremento de produto "Concluído", utilizável e potencialmente liberável. Sprints têm durações consistentes ao longo de um esforço de desenvolvimento. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior.
Ciclo de desenvolvimento em Scrum
JEFF SUTHERLAND (2016), explica que a Reunião Diária, ou Daily Scrum é um evento time-boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima Reunião Diária, 
A partir dessas considerações, RAFAEL SABBAGH (1998) entende que os Daily Scrums normalmente são realizados no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho, todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.
Na mesma linha de raciocínio KEN SCHWABER (2016) afirma que os Scrums diários melhoram as comunicações, eliminam outras reuniões, identificam impedimentos ao desenvolvimento para a remoção, destacam e promovem a tomada de decisão rápida, e melhoram o nível de conhecimento da equipe de desenvolvimento. Esta é uma chave de inspecionar e adaptar reunião.
Para JEFF SUTHERLAND (2016), o ciclo de desenvolvimento do Scrum começa com uma visão do produto que será desenvolvido, chamado de Product Backlog, que contém as características definidas pelo Product Owner, assim como as tecnologias necessárias para sua implementação. A equipe de desenvolvimento se reúne com Product Owner, antes do início de cada Sprint para priorizar o trabalho a ser feito e selecionar as tarefas que a equipe pode terminar na Sprint; as tarefas selecionadas compõem o Sprint Backlog. Nessa fase também são definidas as ferramentas a serem utilizadas e detectados os possíveis impedimentos. Conforme apresentada na figura 1 pode-se observar como funciona de forma resumida, o ciclo de desenvolvimento do Scrum:
Figura 1.0 Ciclo de desenvolvimento em Scrum.
Fonte: https://projetoseti.com.br/benchmark-agil-entendendo-o-scrum/ (2018).
Artefatos Scrum
JEFF SUTHERLAND (2016) entende que os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos.
Scrum originalmente define o uso de apenas quatro artefatos: O Product Backlog, O Sprint Backlog, A Definição de Pronto e o Incremento no Produto. Adiciono à lista a Definição de Preparado, artefato que pode ser importante para o trabalho de um Time de Scrum. RAFAEL SABBAGH (1998). 
A Figura 2.0 demonstra os quatro artefatos Scrum e a inclusão de “Definição de Preparado” adicionado à lista conforme entendimento de RAFAEL SABBAGH.
Figura 2.0: Artefatos do Scrum
Fonte: Scrum Gestão ágil para projetos de sucesso (1998).
Backlog do Produto.
Segundo KEN SCHWABER (2016), Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.
O mesmo pensamento tem RAFAEL SABBAGH (1998), Product Backlog é uma lista ordenada ou priorizada de itens sobre os quais o Time de Desenvolvimento trabalhará no decorrer do projeto, desde os itens do topo da lista, buscando realizar os objetivos do produto, comumente representados por uma Visão de Produto. Ele é atualizado, reordenado e refinado de acordo o nível de detalhes que é possível de se ter em cada momento do projeto.
Sprint Backlog
Explica ainda que o conjunto de itens selecionados e seu respectivo plano é chamado de Sprint Backlog, e é geralmente representado na forma de um Quadro de Tarefas. O Sprint Backlog existe apenas dentro do seu Sprint respectivo.
Conforme apresentada
na figura 3.0 pode-se observar a representação das tarefas de um Sprint Backlog.
Figura 3.0: Quadro de Tarefas representando o Sprint Backlog
Fonte: Scrum Gestão ágil para projetos de sucesso (1998).
Definição de Pronto
De acordo com COCKBURN, A. (2007), a Definição de Pronto é um acordo formal entre Product Owner e Time de Desenvolvimento sobre o que é necessário para se considerar que um trabalho realizado no Sprint está “pronto”. É um conjunto de critérios compartilhados para que, quando o Time de Desenvolvimento ou um de seus membros afirmem que um item ou o Incremento do Produto está pronto, todos compreendam o que isso significa.
A mesma Definição de Pronto se aplica a cada item do Sprint Backlog e ao Incremento do Produto como um todo, que é o conjunto dos itens desenvolvidos no Sprint. Ela ajuda o Time de Desenvolvimento no momento de planejar o trabalho a ser realizado no Sprint e guia o Time de Desenvolvimento durante a realização desse trabalho.
Incremento do Produto
Scrum é iterativo. O produto é desenvolvido em ciclos ou iterações, que se repetem em sua forma sucessivamente. Em cada um desses ciclos, é gerado um incremento no produto, que modifica e se soma ao que já se tem pronto do produto até o momento. Cada ciclo é como se fosse um pequeno projeto autocontido, com todas as atividades necessárias para se gerar uma parte do produto estável e funcionando KEN SCHWABER (2016).
RAFAEL SABBAGH (1998) afirma que o Incremento do Produto é a soma de todos os itens completos em um Sprint. Portanto, é um incremento de funcionalidades do produto prontas, de acordo com a Definição de Pronto.
Conforme apresentada na figura 4.0 pode-se observar todos os itens que compões a Definição de Pronto:
 
Figura 4.0: Um exemplo de Definição de Pronto
Fonte: Scrum Gestão ágil para projetos de sucesso (1998).
Definição de Preparado
Na visão de RAFAEL SABBAGH (1998), Definição de Preparado é um artefato utilizado para garantir que os itens a serem considerados na reunião de Sprint Planning estejam preparados segundo um critério bem definido. É um acordo formal entre Product Owner e Time de Desenvolvimento sobre o estado em que um item do Product Backlog deve estar para ser considerado preparado para entrar no Sprint Backlog.
3 Conclusão
O desenvolvimento do presente estudo possibilitou uma análise das principais características do Scrum, papéis, artefatos, eventos e as regras necessárias para que esta ferramenta traga sucesso, além disso é importante ressaltar que a adoção de Scrum em larga escala não significa que todos os problemas estão resolvidos. Longe disso. Scrum é apenas uma ferramenta que pode trazer diversos benefícios em comparação a outras formas de se conduzir projetos, mas somente se bem utilizada.
De um modo geral, o Scrum permite reduzir os riscos de insucesso, entregar valor mais rápido e, desde cedo, lidar com as inevitáveis mudanças de escopo, transformando-as em vantagem competitiva. Seu uso pode também aumentar a qualidade do produto entregue e melhorar a produtividade das equipes. Demostra-se ser satisfatório os benefícios que da metodologia Scrum, podendo se destacar as entregas frequentes de retorno ao investimento dos clientes; redução dos riscos do projeto; maior qualidade no produto gerado; visibilidade do progresso do projeto; redução do desperdício; aumento da motivação e produtividade.
Também é de extrema importância verificar que a implementação das técnicas Scrum não são tão simples, visto que a cultura organizacional muitas vezes tem uma influência significativa na implementação do Métodos Ágeis, algumas organizações têm dificuldades em se adaptar a mudanças, que implicam em: “Desaprender valores, premissas e comportamentos antigos antes que se possa aprender os novos. Os elementos mais importantes dessa mudança cultural são: apoio executivo e treinamento. Eis aqui outro grande problema enfrentado pelos métodos ágeis durante sua implantação. É difícil obter o apoio das altas instâncias da organização, porém é fundamental. Os executivos devem liderar a transformação pela mudança de seus próprios comportamentos e assim inspirar os demais colaboradores” Graças aos resultados que vem sendo apresentados pelo Framework Scrum, cada vez mais as organizações vem acreditando e introduzindo os conceitos ágeis em suas organizações, buscando assim um diferencial competitivo.
Os estudos deixam claro o papel do grupo e o valor que profissionais envolvidos trazem em favor da Organização e o quanto ele pode ser um framework iterativo e incremental para se desenvolver produtos, ele também estimula que o próprio aprendizado acerca dos seus detalhes seja construído de forma participativa e entre seus adeptos a prática. Significa dizer que não exige compreensão de todos os ensinamentos a nível exemplar do framework Scrum para começar a usá-lo, percebe-se que “usar bem” o Scrum não pode ser alcançado de uma forma rápida, pois demanda comprometimento em todas as etapas que são abordadas nesta pesquisa.
Para que o Scrum se torne um framework mais popular e incluído na maioria das Organizações, o processo de adaptação as metodologias já usadas devem ser facilitadas, considerando que se permita extensibilidade saudável, de forma que possa ser adotado em qualquer tipo de ambiente organizacional.
Referências
AGILE MANIFESTO. Manifesto for Agile Software Development. 1997 Disponível em: http://www.agilemanifesto.org. Acesso em Agosto de 2018.
ARMONY, R. S. Fatores críticos para a prática de valores ágeis em equipes de tecnologia da informação. Rio de Janeiro, Brasil 2010. 
BASSI FILHO et al., 2009] SAVOINE, M.; et al. Análise de Gerenciamento de Projeto de Software Utilizando Metodologia Ágil XP e Scrum: Um Estudo de Caso Prático Centro de Estudos e Sistemas Avançados do Recife – CESAR, Pernambuco.
HIGHSMITH, J.; COCKBURN, A. Agile Software Development: The Business of Innovation. IEEE Computer. 2007.
KEN SCHWABER ; JEFF SUTHERLAND.. Guia do ScrumMR, 2016. Disponível em: https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf Acesso em Maio de 2018.
MICHAEL WILKINSON; The secrets of facilitation: the S.M.A.R.T. guide for getting results with groups 2004.
RAFAEL SABBAGH Scrum gestão ágil para projetos de sucesso, 1998. 
SUTHERLAND, JEFF. The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework. Version 1.1, Scrum, Inc., Cambridge, 2012. Disponível em: . Acesso em Agosto 2018
SWEBOK. The Guide to the Software Engineering Body of Knowledge. Disponível em: Acesso em Agosto 2018.