mÉtodos Ágeis de desenvolvimento de software:...

MÉTODOS ÁGEIS DE

DESENVOLVIMENTO DE SOFTWARE:

UM CASO PRÁTICO DE APLICAÇÃO

DO SCRUM

Carlos Eduardo Costa de Carvalho (UFRJ)

[email protected]

Carolina Thome de Abrantes (UFRJ)

[email protected]

Renato Flórido Cameira (UFRJ)

[email protected]

Os ciclos de inovação tecnológica cada vez mais curtos têm exigido

das empresas flexibilidade e agilidade na entrega de seus produtos. Na

indústria de software, porém, os resultados entregues pelos projetos de

desenvovimento de sistemas de informação estão aquém do valor

esperado. Neste contexto, surgiram os métodos ágeis de

desenvolvimento de software com a proposta de fornecer maior

agilidade de resposta e flexibilidade de adaptação para as empresas

que desejam ter a velocidade e qualidade de entrega como diferenciais

competitivos. O Scrum, método ágil que tem se destacado nos últimos

anos, tem suas bases em conceitos tradicionais da engenharia de

produção como a filosofia enxuta e a teoria das restrições. Assim, o

objetivo deste artigo é apresentar um estudo de caso sobre a utilização

do Scrum em uma empresa do setor de software nacional embasado no

referencial teórico sobre o tema. Será tratado o processo de análise e

identificação de problemas da situação atual da empresa e a aplicação

do método em questão. Ao final, serão apresentados os principais

resultados obtidos, as limitações encontradas e conclusões que visam

embasar novas iniciativas de aplicação do Scrum.

Palavras-chaves: Desenvolvimento Ágil, Scrum, Empresa de Software,

Teoria das Restrições, Produção Enxuta

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no

Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.



2

1. Introdução

O atual padrão de competitividade tem destacado organizações que tenham conseguido,

através do lançamento de novos produtos e serviços, acompanhar ciclos de inovação cada vez

mais acelerados no mercado. Segundo Senge (1990), a real vantagem competitiva das

organizações é sua habilidade em aprender mais rapidamente que a concorrência, em gerar e

compartilhar conhecimento e melhorar de forma contínua sua atuação. Neste contexto, os

ciclos de inovação tecnológica se destacam nas últimas décadas. O tempo entre o lançamento

de novos produtos e serviços de tecnologia tem diminuído e as empresas que se deparam com

os desafios de aprendizado e lançamento de novidades no mercado.

Porém, as tentativas de melhoria em relação aos resultados e ao tempo de entrega de projetos

de software não têm gerado os resultados esperados. Uma pesquisa divulgada pelo The

Standish Group (2009) demonstra que apenas 32% dos projetos de software obtiveram

sucesso em 2009. Dos restantes, 44% foram entregues com problemas e 24% fracassaram. Em

outra pesquisa divulgada pelo mesmo instituto em 2006, constata-se que 45% das

funcionalidades entregues nunca foram utilizadas e apenas 7% são realmente utilizadas no

dia-a-dia.

Estes números revelam um cenário desfavorável relacionado à real entrega de valor

proporcionada por projetos de desenvolvimento de software. Este cenário se torna ainda mais

crítico frente à necessidade de constantes inovações para o alcance de posições de destaque no

mercado, conforme colocado anteriormente. Assim, nos últimos 20 anos, novos métodos de

desenvolvimento de sistemas de informação surgiram com a proposta de fornecer maior

agilidade e flexibilidade para as empresas. Dentre estes métodos, destaca-se o Scrum, método

ágil de desenvolvimento de software, criado na década de 1990 por Jeff Sutherland, com base

em conceitos tradicionais da engenharia de produção como a filosofia enxuta e a teoria das

restrições explorados por Takeuchi & Nonaka (1986) no artigo “The new new product

development game”, no qual descrevem as vantagens da utilização de times multidisciplinares

e autogerenciáveis no desenvolvimento de produtos.

Este artigo tem o objetivo de apresentar um estudo de caso sobre a utilização do método ágil

Scrum em uma empresa do setor de software nacional. Será tratado o processo de análise e

identificação de problemas da situação atual da empresa e como o método em questão foi

utilizado como referencial teórico para propor soluções de melhoria, orientando uma mudança

organizacional.

2. Método

Para a condução deste trabalho foi seguido um método que pode ser representado pela Figura

1. Esta pesquisa pode ser classificada como de natureza aplicada (GIL, 1999), isto é, trata-se

de uma pesquisa que envolve conhecimentos que buscam resolver lacunas teórico-práticas.



3

Figura 1 – Método de condução do trabalho

Fonte: os autores

Primeiramente foi realizada uma busca bibliográfica sobre os conceitos e definições de

Metodologias de Desenvolvimento de Sistemas (MDS). Partiu-se, então, para o

aprofundamento no método ágil de desenvolvimento de sistemas Scrum e os conceitos que

são referenciados como base para a criação deste método.

Foi então realizado um estudo de caso sobre a aplicação dos conceitos apresentados na

implementação do Scrum em uma empresa do setor de produção e comercialização de

software. A partir da análise do caso foram apresentados os principais resultados obtidos e as

limitações encontradas. Por fim, são apresentadas conclusões que visam embasar novas

iniciativas de aplicação do Scrum.

4. Referencial Teórico

Este item se propõe a apresentar os conceitos, terminologias e definições necessárias para o

entendimento do artigo. Serão apresentados conceitos da engenharia de software e das

metodologias de desenvolvimento de sistemas, com foco no Scrum, apontando suas

características e raízes na filosofia enxuta de produção.

4.1. A Engenharia de Software

A engenharia de software, segundo Staa (1987) estabelece e usa sólidos princípios de

engenharia para a obtenção econômica de softwares confiáveis e com funcionamento eficiente

em máquinas reais. Maffeo (1992) corrobora com esta visão e acrescenta que é a área

interdisciplinar que engloba as vertentes tecnológica e gerencial, visando abordar de modo

sistemático os processos de construção, implantação e manutenção de produtos de software

com qualidade assegurada, segundo cronogramas e custos previamente definidos.

A partir dessas duas visões, tem-se a necessidade de estabelecer metodologias de

desenvolvimento de software que cumpram os requisitos tecnológicos e gerencias para

garantir a qualidade do produto entregue e a eficiência dos processos envolvidos.

Cabe ressaltar ainda, segundo Maffeo (1992), os objetivos primários da engenharia de

software que, dentre outros, abrangem o aprimoramento da qualidade dos produtos de

software, o aumento da produtividade dos engenheiros de software e o atendimento aos

requisitos com eficiência e eficácia.



4

4.2. Metodologias de Desenvolvimento de Software (MDS)

O conceito de ciclo de vida do software surgiu devido à necessidade da especificação, em alto

nível, do conjunto de tarefas que compõem o processo de desenvolvimento de software.

(CARVALHO, 2009).

As diferentes metodologias existentes para o desenvolvimento de software trazem abordagens

distintas para o ciclo de vida de software. Entretanto, independentemente do modelo de ciclo

de vida e de suas características particulares, em geral esses modelos compartilham as

seguintes (macro) atividades (MAFFEO, 1992): Especificação de Necessidades,

Especificação de Requisitos, Projeto de Software (Design), Implementação de Software,

Implantação e Manutenção do Software.

Carvalho (2009) define as possíveis tipologias para as metodologias de desenvolvimento de

software que variam na forma com a qual dispõem os recursos (papéis, responsabilidades,

tempo, etc.) para a construção do produto software e para a entrega ao cliente final.

4.2.1. O Modelo Cascata ou Clássico

Nesta metodologia, o projeto de desenvolvimento de software é dividido em fases executadas

sequenciamente com um conjunto detalhado de documentos específicos a cada macro-

atividade. São características desse modelo o grau elevado de documentação, o controle

excessivo das atividades e a baixa participação do usuário final nos processos.

4.2.2. Prototipação

Nesse modelo, o conjunto inicial de necessidades é detectado e implementado rapidamente,

sendo posteriormente refinado de acordo com o aumento do conhecimento do sistema pelos

envolvidos no processo de desenvolvimento (YORDON, 1990).

A prototipação, porém, possui brechas para críticas, na medida em que a ausência de padrões

e processos deixa a qualidade do produto final imprevisível e passível de oscilações. Nesta

perspectiva, para ser um sistema real, aquele deveria seguir padrões de qualidade, segurança,

desempenho, capacidade, robustez e facilidade de manutenção, mas, por ser um protótipo,

padrões como os citados mostram-se insuficientes ou inexistem (ALVES; VANALLE, 2001).

4.2.3. O Modelo Espiral

As melhores características dos modelos cascata e prototipação podem ser encontradas no

modelo espiral com o acréscimo de um elemento – a análise dos riscos, inexistentes nos

outros dois modelos (PRESSMAN, 2002). O modelo é composto por quatro quadrantes, quais

sejam: Planejamento, Análise de Riscos, Engenharia e Avaliação.

4.2.4. O Modelo Iterativo e Incremental

Este modelo apresenta uma ênfase na redução do lead time da produção do software. Sua

ênfase é na liberação de versões que são atualizadas e melhoradas em ciclos de

desenvolvimento consecutivos.

Assim, de cada iteração (composta pelas fases de requisitos, análise e projeto, codificação e

teste) resulta uma versão do software com um subconjunto de funcionalidades que crescem de

forma incremental a cada iteração até conformar o produto final desejado. (CARVALHO,

2009)

4.2.5. Técnicas da Quarta Geração



5

As técnicas de quarta geração, conhecidas pela sigla 4GT, trazem uma abordagem de

especificação de software utilizando funções significativas que aproximam a linguagem de

máquina à linguagem natural.

Tecnologias modernas que utilizam a 4GT conseguem passar automaticamente das fases de

especificação para a implementação, incluindo testes automatizados que garantem a

conformidade com os requisitos levantados. As técnicas de quarta geração já se tornaram

importantes para o desenvolvimento de aplicações de sistemas de informação (PRESSMAN,

2002).

4.2.6. Metodologias Ágeis

Um dos problemas relacionados às metodologias mais tradicionais de desenvolvimento de

software está na identificação, registro e tratamento dos requisitos de negócio. No atual

ambiente de desenvolvimento de software, os requisitos estão sujeitos a freqüentes

modificações durante o ciclo de desenvolvimento do produto para atender as alterações da

demanda (RISING; JANOFF, 2000).

Frente às dificuldades de adaptação dos métodos tradicionais às necessidades de mudanças

dos processos de desenvolvimento de software, surgiram, durante a década de 1990, os

chamados métodos ágeis. Estes métodos foram influenciados pelos princípios da manufatura

enxuta implementados pelas companhias Honda e Toyota e pelas estratégias de gestão do

conhecimento de Takeuchi e Nonaka (2004) e Senge (1990). Tratam-se de metodologias de

desenvolvimento adaptativas e flexíveis, e que são indicadas para cenários onde a mudança de

requisitos é constante e os resultados precisam ser entregues ao cliente em curtos espaços de

tempo. (CARVALHO; MELLO, 2009).

No lugar da aderência e conformidade aos planos iniciais é preferível adaptar aos cenários

atuais, levando em consideração o conhecimento adquirido durante o desenvolvimento (uma

vez que o desenvolvimento é uma atividade de aprendizado baseado em tentativas e erros),

aproveitando oportunidades emergentes e focando na entrega de valor real para os clientes.

(FRANCO, 2006)

Estas metodologias, portanto, focam nos indivíduos e na interação entre eles, no

funcionamento do software, na colaboração com o cliente e na resposta rápida às mudanças.

Isto é alcançado através de ciclos iterativos de desenvolvimento de sistemas com objetivos de

curto prazo, tonando possível a adaptação dos requisitos até o momento em que entram em

fase de desenvolvimento.

4.3. O Scrum

Segundo Carvalho e Mello (2009), dentre os diferentes métodos ágeis, o que mais se destaca é

o Scrum, uma abordagem enxuta de desenvolvimento de produtos. A primeira utilização deste

termo surgiu em um estudo de Takeuchi & Nonaka (1986), no qual, os autores notaram que

pequenos projetos que tinham equipes pequenas e multifuncionais obtinham os melhores

resultados. Este estudo serviu como base para que, em 1993, Jeff Sutherland criasse o Scrum.

O objetivo do Scrum é entregar a maior qualidade de software possível dentro de uma série de

pequenos intervalos de tempo fixo, chamados Sprints, que tipicamente duram menos de um

mês (SUTHERLAND et al., 2000). Ou seja, ao final de cada Sprint, espera-se que sejam

entregues funcionalidades que possam ser utilizadas pelo usuário, gerando valor para seu

negócio ou aumentando sua satisfação em relação ao produto entregue.

O método tem início com uma reunião denominada Sprint Planning. Na primeira parte desta

reunião, são eleitos os requisitos de sistema registrados no Product Backlog que serão



6

desenvolvidos ao longo do Sprint. Na segunda parte desta reunião, são discutidas e detalhadas

as atividades envolvidas na execução de cada item selecionado.

Após, dá-se início à fase de execução das atividades, o Sprint propriamente dito. Conforme

Carvalho et al (2009) apud Abrahamsson (2002), no caso do desenvolvimento de software, o

Sprint inclui as fases tradicionais do desenvolvimento de software: requisitos, análise, projeto

e entrega. Durante o Sprint, são realizadas reuniões diárias conhecidas como Scrum Meetings

ou Daily Scrum. As Scrum Meetings permitem que o time de desenvolvimento possa

socializar o conhecimento de cada membro do Time e possui uma profunda transcendência

cultural (SUTHERLAND et al., 2000).

Ao final do tempo determinado para o Sprint, é realizada uma reunião de entrega do

incremento do produto. Esta última reunião é chamada Sprint Review.

A última reunião do Sprint é denominada Sprint Retrospective e serve para que os membros

do Time possam discutir a respeito das melhorias no processo de desenvolvimento para o

próximo ciclo de desenvolvimento.

A figura abaixo retrata a dinâmica de processo do Scrum:

Figura 2 – Dinâmica de processo do Scrum

Fonte: Mar e Schwaber (2001)

O Scrum possui três papéis fundamentais. O Scrum Master deve trabalhar para que o processo

Scrum aconteça e para que não existam impedimentos para que os membros da equipe

realizem seu trabalho. Remover os obstáculos apontados no Daily Scrum é seu dever, de

modo que os desenvolvedores se concentrem apenas nas questões técnicas (CARVALHO;

MELLO, 2009).

Outro papel importante no método é o do Product Owner. Este membro do time representa o

cliente interno ou externo. Ele deve definir quais são os requisitos e qual é o grau de

importância e prioridade de cada um deles (CARVALHO; MELLO, 2009).

Por fim, o último papel destacado pelo Scrum é o próprio Time, que deve ser multidisciplinar,

auto-gerenciável e todos devem estar em busca de um objetivo comum.

4.4. A Manufatura Enxuta (Lean Manufacturing)

Como citado, o Scrum tem suas raízes nos princípios da manufatura enxuta japonesa. Filho e

Fernandes (2004) propõem uma listagem com a síntese desses princípios, que são a base da

manufatura enxuta.



7

Tabela 1- Princípios da Manufatura Enxuta

Fonte: Filho e Fernandes (2004)

Uma das etapas iniciais e foco da manufatura enxuta é o mapeamento do processo de

construção do valor para o cliente (Value Stream Mapping). Através dessa ferramenta, são

identificadas as atividades que agregam valor e as que não agregam valor passam a ser

consideradas desperdícios e devem ser eliminadas.

Womack e Jones (2006) evoluem nas atribuições chave da manufatura enxuta e prescrevem os

passos para que uma organização utilize seus princípios para alavancar sua produção.

Forneça o valor de fato desejado pelos clientes. Resista ao desejo de trabalhar adiante a

partir da organização, dos ativos e do conhecimento existentes para convencer os clientes

de que eles querem aquilo que é mais fácil de ser produzido pela empresa.

Identifique o fluxo de valor para cada produto. Esta é a sequência de ações (o processo)

necessárias para trazer um bem ou serviço do conceito até o lançamento (pelo processo de

desenvolvimento) e de um pedido até as mãos do cliente (pelo processo de provisão).

Questione cada etapa nesses processos, para ver se eles realmente criam valor para o

cliente. Elimine as etapas que não criam.

Organize as etapas estantes em um fluxo contínuo. Elimine esperas e estoques entre etapas,

para reduzir os tempos de desenvolvimento e de resposta.

Deixe o cliente puxar o valor da empresa. Reverta os métodos de empurrar, usados pelas

empresas com tempos longos de resposta, as quais tentam convencer os clientes de que

eles querem aquilo que a empresa já projetou ou produziu.

Finalmente, uma vez estabelecidos o valor, o fluxo de valor e a puxada, comece novamente

a partir do início, numa busca indefinível pela perfeição, a situação feliz de valor perfeito

com desperdício zero.

4.5. A Teoria das Restrições

Desenvolvida por Eliyahu M. Goldratt, na década de 1980, a Teoria das Restrições aponta que

a meta de qualquer organização é maximizar o índice pelo qual cada empresa gera receita

através de suas vendas líquidas (conceito que em inglês é apresentado como throughput)

Segundo Goldratt e Cox (1990), a meta de qualquer organização é garantir dinheiro no

presente, bem como garantir sua continuidade no futuro. Para tal, a teoria parte da

identificação do gargalo produtivo. Entende-se gargalo como todo recurso que possui uma

capacidade menor do que a sua demanda (GOLDRATT; COX, 1990).

Para os autores, todas as organizações apresentam restrições, isto é, impedimentos que

reduzem a eficiência dos sistemas produtivos. Nesse sentido, parte da teoria dita que o foco do



8

esforço gerencial deve ser na otimização dos gargalos e na redução das restrições que

influenciam as etapas de agregação de valor.

Dentre as máximas da Teoria das Restrições é dito que uma hora perdida na operação do

posto gargalo é uma hora perdida para o sistema todo. Desta afirmação retirada da própria

obra A Meta (GOLDRATT; COX, 1990), tem-se que a operação do gargalo dita o

desempenho global da linha produtiva e do negócio.

5. O Caso

O caso apresentado é baseado em um projeto de análise da situação atual e proposições de

melhorias para a metodologia de desenvolvimento de sistemas de uma empresa do setor de

software, que resultou na implementação do Scrum em seu processo produtivo.

5.1. A Organização e o Contexto do Projeto

Este trabalho foi realizado em uma empresa brasileira com atuação internacional

especializada em soluções relacionadas à Governança, Riscos e Compliance (GRC). A

empresa atua nas áreas de desenvolvimento e comercialização de software para automatização

de soluções de GRC, consultoria e educação nesta área. Seus clientes estão localizados no

Brasil, América Latina, Estados Unidos e Europa.

Para manter seu sistema atualizado frente às inovações do mercado de GRC e às necessidades

de customização demandadas por seus clientes, a equipe técnica da empresa lida

constantemente com uma série de mudanças e atualizações no sistema. O grande volume de

novos requisitos a serem desenvolvidos exige dinamismo à equipe de desenvolvimento, que

deve ser capaz de gerenciar a alta demanda e garantir qualidade e pontualidade de entrega de

seu produto final.

O crescimento das vendas da empresa durante 2010 aumentou ainda mais a demanda por

atualizações no software, o que gerou uma pressão sobre a diretoria técnica a respeito da

eficiência de sua equipe de desenvolvimento de sistema. Juntamente a este cenário, a alta

gestão da empresa colocava em prática ações para a otimização de recursos. Assim, o diretor

técnico, em parceria a um grupo externo, conduziu uma iniciativa para a avaliação da atual

metodologia utilizada para o desenvolvimento do software, identificação de pontos críticos e

proposição de melhorias.

5.2. A situação atual do processo de desenvolvimento de sistema da organização

O estudo teve início com o mapeamento da situação atual dos processos de desenvolvimento

de sistemas da empresa anteriormente à implementação do Scrum. Em primeiro lugar, era

preciso entender como o processo de desenvolvimento estava organizado. Para tanto, foi

construído um esquema que representava a situação atual do processo, desde a chegada de

novas demandas até a entrega do software.



9

Figura 3 – Macroatividades do processo de desenvolvimento de sistema

Fonte: os autores

A figura anterior representa o macroprocesso de desenvolvimento. Este tem início com o

recebimento de novos requisitos para serem implementados no sistema ou modificações em

requisitos já existentes. Estes requisitos são então priorizados e a equipe de especificação

produz, para cada um, um documento detalhado sobre suas características, regras de negócio

envolvidas e critérios de aceitação, chamado de Especificação do Requisito. Este documento é

utilizado em todas as demais etapas do processo e serve como padronização para as

informações que servirão de insumo para as atividades posteriores.

Após a Especificação do Requisito, é realizado o desenvolvimento do código do sistema e de

seu conteúdo (como questionários para avaliações de risco, por exemplo). O código passa

então por alguns testes e, após os ajustes necessários, ocorre a implantação do sistema para os

usuários internos à equipe técnica.

Assim, seguem-se os testes de qualidade no software (Quality Assurance - QA), onde são

simuladas situações cotidianas de utilização do sistema para a correção final de possíveis

erros. Então, o software pode ser liberado para o cliente final e instalado nos ambientes de

produção.

É possível perceber que o processo de desenvolvimento da empresa estava organizado

conforme o método cascata. Nesse modelo, o projeto passa por diversas etapas (análise,

design, documentação, codificação e testes) antes de ser entregue ao cliente (ROSE e MELLO

apud LOESER, 2010), diminuindo a flexibilidade do processo e prejudicando a obtenção de

repostas rápidas às exigências de mercado por parte da empresa (ROSE; MELLO, 2010).

Para entender detalhadamente de que forma estas características inerentes ao método cascata

afetavam a produtividade da equipe de desenvolvimento da empresa, o macroprocesso

identificado foi dividido em 45 atividades e os seus respectivos responsáveis foram

entrevistados. Para tal, foi utilizado um questionário padrão com as seguintes perguntas:

a) Qual o objetivo da atividade?

b) Quais são os inputs necessários para a execução da atividade? Qual a qualidade destes

inputs? Existe retrabalho para a atividade devido à má qualidade dos inputs?

c) Quem e quantos são os envolvidos na execução da atividade?

d) Quais são os recursos utilizados (documentos, sistemas etc.)?

e) Quanto tempo, em média, demora a execução da atividade?

f) Quais são os outputs gerados pela atividade? Qual a qualidade destes outputs? Existe

retrabalho para a atividade devido à má qualidade dos outputs?



10

g) Quais críticas podem ser colocadas quanto à atividade, aos recursos necessários e à

comunicação com as equipes responsáveis pelas demais atividades?

Como resultado das informações obtidas através das entrevistas, foi possível a caracterização

mais detalhada da situação atual da empresa. Alguns pontos críticos foram postos em

evidência, demonstrando algumas dificuldades encontradas pela equipe técnica:

Um ano antes deste estudo, houve uma reestruturação na metodologia de desenvolvimento

da empresa devido à migração do software para uma versão mais avançada. Novas

atividades foram criadas, dentre elas, a especificação dos requisitos.

Esta atividade, apesar de ser considerada crítica para a garantia da qualidade do produto

final, era realizada por uma equipe com pouca experiência na empresa e ainda não possuía

papéis e responsabilidades bem definidos.

Conforme mencionado, a equipe de especificação era responsável pela elaboração das

Especificações dos Requisitos utilizadas como base por todas as demais etapas do processo

de desenvolvimento. Devido à pouca experiência desta equipe, o aparente

subdimensionamento e a falta de processos que orientassem a execução das atividades,

pode-se identificar o seguinte cenário.

Figura 4 – Ponto crítico do processo produtivo: divergência de informações

Fonte: os autores

O processo de desenvolvimento de sistemas exige interpretação da Especificação do Requisito

para sua tradução em códigos de programação. Porém, a baixa qualidade destes documentos

levava os codificadores a implementar funcionalidades diferentes das descritas, sem o correto

registro das mudanças realizadas no documento original (a Especificação do Requisito).

Após a codificação, o software era repassado para as demais etapas. Uma vez que as equipes

responsáveis por estas atividades posteriores utilizavam a Especificação do Requisito como o

documento que detalhava o que deveria estar implementado no software, a divergência entre o

documento e o que era encontrado no sistema gerava conflitos de informações e retrabalho

para toda a equipe técnica dada a falta de registro das mudanças realizadas.

De acordo com Womack e Jones (2006), uma das atividades relacionadas à filosofia enxuta de

produção consiste em identificar o fluxo de valor para cada produto, do ponto de vista do

cliente, questionar cada etapa desses processos sobre a real criação de valor e buscar eliminar

as etapas que não criam o valor real. Nesta empresa, a correção da documentação e

recodificação do sistema podem ser classificadas como atividades que não agregavam valor

para o cliente. Estas eram resultado de erros cometidos pela equipe técnica. Sendo assim, de

acordo com a filosofia enxuta, o retrabalho gerado pela baixa qualidade das especificações

deveria ser eliminado.



11

Além disso, a capacidade de entrega da equipe de especificação ainda não havia atingido o

nível de eficiência que as demais áreas já tinham adquirido devido a sua pouca experiência em

lidar com as particularidades do sistema daquela empresa, comparada às demais equipes.

Segundo Goldratt e Cox (1990), à luz da teoria das restrições, entende-se gargalo como todo

recurso que possui uma capacidade menor do que a sua demanda. Assim, a etapa de

especificação foi considerada como um gargalo para o processo de desenvolvimento do

software da empresa. Ainda segundo esta teoria, toda a capacidade produtiva do sistema

estava sendo limitada por esta etapa e o foco gerencial deveria ser na otimização deste

gargalo.

5.3. Implementação da metodologia Scrum

Como já mencionado, a metodologia de sistemas Scrum foi criada com base nos princípios

enxutos de produção, visando eliminar os gargalos e balancear o fluxo de produção do método

tradicional através da criação de times multidisciplinares, que deveriam trabalhar em

conjunto, prezando pela comunicação entre seus membros e o foco em uma meta

compartilhada. Sobre o fluxo de produção, Takeuchi e Nonaka (1986) colocam que o ritmo de

cada indivíduo e o ritmo do grupo se tornam o mesmo, criando um pulso completamente

novo. Este pulso serve como uma força motriz e move o time para frente.

Um estudo realizado por Carvalho e Mello (2009) revelou que o benefício proporcionado pelo

Scrum mais citado pelas publicações sobre o tema é a “melhoria na comunicação e aumento

da colaboração entre os envolvidos”. Além disso, Sutherland (2004) relata que em um projeto

de desenvolvimento realizado pela Microsoft onde foi utilizada a lógica do Scrum, foi obtida

a maior produtividade por desenvolvedor já documentada.

Assim, o Scrum se demonstrou a solução que melhor supria as necessidades da empresa

estudada. Esta decisão significava o reprojeto do macroprocesso produtivo da empresa e o

apoio da alta direção foi considerado fator crítico para o sucesso da implementação da

metodologia.

Uma particularidade da implantação do Scrum na empresa diz respeito à decisão de deixar os

profissionais da área de Quality Assurance fora dos times multidisciplinares. Por questões de

política interna à empresa, preferiu-se não envolver estes profissionais inicialmente e apostar

em uma inclusão progressiva visando uma curva de aprendizagem.

Conforme mostra a figura 2, apresentada anteriormente, que explicita a dinâmica do processo

do Scrum, o resultado entregue ao final dos Sprints deve ser um incremento do produto.

Porém, a figura abaixo demonstra que, para a empresa estudada, o resultado entregue pelos

times Scrum não pode ser diretamente entregue ao cliente, visto que ainda resta a etapa de

testes realizada pela equipe de QA (que não foi incluída nos times). Esta foi a solução

encontrada para uma barreira política da empresa, que adaptou o método para o momento da

mudança imediata.



12

Figura 5 – Composição dos times Scrum

Fonte: os autores

Foi decidido por uma estratégia de mudança na qual todos os profissionais das áreas

envolvidas no Scrum migrariam de uma só vez para os times multidisciplinares. Este processo

demandou um trabalho intenso de conscientização e disseminação da cultura ágil por toda a

equipe técnica. Para tanto, todos receberam um treinamento no método Scrum. Após a

realização do treinamento, foram definidos os componentes dos times e houve a escolha dos

Scrum Masters (que seriam trocados a cada três meses).

Para a adaptação dos profissionais à nova metodologia, ao longo de janeiro de 2011 foram

realizados dois Sprints experimentais, apenas para a resolução de bugs antigos do sistema.

Este período de adaptação foi utilizado para observar possíveis pontos de melhoria no método

implementado.

Por fim, para o controle da evolução da nova metodologia, foram determinados alguns

indicadores de desempenho como “Eficácia do Trabalho”, “Índice de Trabalho

Remanescente”, “Densidade de erros por linha de código”, “Tempo Médio de Resolução de

Impedimentos” e “Avaliação da Satisfação do Product Owner”.

O processo de implantação do Scrum ocorreu durante 40 dias e foi finalizado na segunda

semana de janeiro de 2011. Desde então, o progresso do método vem sendo acompanhado

através de indicadores de desempenho e, de acordo com as necessidades impostas pela rotina

e pelas particularidades da organização, são feitos ajustes nos processos.

Com a formação de times multidisciplinares, os profissionais responsáveis pela especificação

dos requisitos passaram a ter a oportunidade de adquirir experiência com outros profissionais

da equipe técnica e o processo de comunicação constante ajuda a diminuir o retrabalho devido

a inconsistências nos documentos gerados.

5.4. Conclusões

Este estudo apontou a utilização de um método ágil de desenvolvimento de sistemas, o

Scrum, como referencial para a transformação da estrutura de processos de uma empresa do

setor de software. Foram apresentados os conceitos que suportam a discussão e, em seguida, o

caso foi explicitado.

Após a implantação da situação projetada, pode-se considerar que houve uma mudança

significativa na organização, uma vez que esta iniciativa impactou o dimensionamento do



13

quadro de pessoal, a divisão de papéis e responsabilidades, os mecanismos de coordenação e

os processos produtivos.

Todavia, durante este estudo foram identificadas dificuldades práticas na execução dos

conceitos previstos pelo Scrum, que devem servir de motivação para novos estudos que

avancem no conhecimento sobre a aplicabilidade do método. Entre elas, pode-se citar a

dificuldade de reprojetar a estrutura de cargos e salários para uma nova realidade em que

novos papéis são propostos e as estruturas de poder são alteradas.

Ainda, a multifuncionalidade total do time, isto é, a presença de profissionais com habilidades

e conhecimentos que garantissem todas as etapas necessárias para a entrega do produto, não

conseguiu ser implantada. Dentre os motivos para essa decisão aponta-se o conflito de

interesses e o impacto para a divisão de poder da empresa, podendo ser um fator contra o

objetivo de ganho de produtividade e melhoria na comunicação interna. Optou-se então por

uma solução híbrida que manteve fora do time multifuncional uma área de qualidade (QA).

Como fator positivo que merece destaque neste estudo foi o patrocínio da alta direção da

empresa que orientou as mudanças internas no sentido da implantação da nova estrutura

organizacional, o treinamento em Scrum oferecido para todos os profissionais e uma

campanha de comunicação eficiente que orientou todos nas transformações que seriam feitas

nas estruturas de cargos e salários da empresa.

O principal ganho para a organização foi o aumento da responsividade às mudanças

necessárias no software que comercializa e, com isso, a rapidez de entrega de novas versões e

atualizações para o mercado. Uma vez que o contexto apresentado, no qual o mercado de

sistemas de informação demanda organizações que tenham flexibilidade e trabalhem com um

equilíbrio nos fatores qualidade e prazo, o método Scrum se apresentou uma referência

eficiente para a estruturação dos processos de desenvolvimento de software ajustado às

necessidades de mercado.

Todavia, esse estudo serviu também para apresentar possíveis restrições e dificuldades que

futuras organizações possam vir a ter com a escolha do método. Para isso, abrem-se novos

campos de estudo para entender em quais outras ocasiões essas restrições também se aplicam

e, com isso, evoluir na compreensão do Scrum.

Referências Bibliográficas

ALVES, R. F., VANALLE, R. Ciclo de Vida de Desenvolvimento de Sistemas – visão conceitual dos modelos

clássico, espiral e prototipação, 2001.

CARVALHO, B. V.; MELLO, C. H. P. Revisão, análise e classificação da literatura sobre o método de

desenvolvimento de produtos ágil Scrum. Anais do XII Simpósio de Administração da Produção, Logística e

Operações Internacionais - SIMPOI, São Paulo/SP, 2009. FRANCO, 2006

CARVALHO, E. Engenharia de Processos de negócios e a engenharia de requisitos: análise e comparações de

abordagens e métodos de elicitação de requisitos de sistema orientada por processos de negócio. 2009. 225 f.

Dissertação (Mestrado em Engenharia de Produção) – COPPE, UFRJ. Rio de Janeiro, 2009.

FILHO M. G.; FERNANDES, F. C. F. Manufatura enxuta: uma revisão que classifica e analisa os trabalhos

apontando perspectivas de pesquisas futuras, Gestão e Produção, 2004

GIL, A. C. Métodos e técnicas de pesquisa social. São Paulo, Atlas, 1999.

GOLDRATT, E. M. e COX, J. A Meta. São Paulo, IMAM, 1990.

MAFFEO, B. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Campus, 1992.



14

MAR, K.; SCHWABER, K. Scrum With XP. Disponível em <http://www.controlchaos.com/XPKane.htm>.

Consultado em abril de 2011.

MENEGON, N. L.; ANDRADE, S. R. Projeto do Produto em Engenharia de Produção, Encontro Nacional de

Engenharia de Produção ENEGEP, 1998.

PRESSMAN, R.S. Software Engineering: a practitioner’s approach. 3 ed. New York: McGraw-Hill, 1992.

RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small Teams, IEEE Software, Vol.

17, No. 4, July-August 2000.

ROSE, T. P.; MELLO, C. H. Proposta sistemática para a gestão de projetos baseada na metodologia ágil

Scrum, Encontro Nacional de Engenharia de Produção – ENEGEP, São Carlos, São Paulo, 2010.

SENGE, P. The Fifth Discipline: the Art and Practice of the Learning Organization. New York: Currency,

1990.

STAA, A.V. Engenharia de Programas. 2ª ed. Rio de Janeiro: Livros Técnicos e Científicos, 1987.

STANDISH GROUP. Extreme CHAOS. The Standish Group International Inc., 2009. Disponível em:

<http://www.standishgroup.com>. Consultado em abril de 2011.

SUTHERLAND, J. Agile Development: lessons learned from the first scrum. Cutter Agile Project Management

Advisory Service. Executive Update, Vol. 5, No. 20. 2004

SUTHERLAND, J.; SCHWABER, K.; SHARON, Y.; DEVOS, M.; BEEDLE, M. SCRUM: An extension

pattern language for hyperproductive software development, 2000.

TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p. 137-

146, 1986.

YOURDON, E. Análise Estruturada Moderna. 3ª ed. Rio de Janeiro: Campus, 1990.

WOMACK, J. P.; JONES, D. T. Soluções Enxutas: Como Empresas e Clientes Conseguem Juntos Criar Valor

e Riqueza. Editora Campus, 2006.

mÉtodos Ágeis de desenvolvimento de software:...

Documents