Artigo02 Metodos Ageis de Desenvolvimento de Software

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO
Inovao Tecnolgica e Propriedade Intelectual: Desafios da Engenharia de Produo na Consolidao do Brasil no

Cenrio Econmico Mundial
Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
MTODOS GEIS DE
DESENVOLVIMENTO DE SOFTWARE:
UM CASO PRTICO DE APLICAO
DO SCRUM
Carlos Eduardo Costa de Carvalho (UFRJ)
caducn@gmail.com
Carolina Thome de Abrantes (UFRJ)
caroltabrantes@gmail.com
Renato Flrido Cameira (UFRJ)
cameira@pobox.com
Os ciclos de inovao tecnolgica cada vez mais curtos tm exigido

das empresas flexibilidade e agilidade na entrega de seus produtos. Na
indstria de software, porm, os resultados entregues pelos projetos de
desenvovimento de sistemas de informao esto aqum do valor
esperado. Neste contexto, surgiram os mtodos geis de
desenvolvimento de software com a proposta de fornecer maior
agilidade de resposta e flexibilidade de adaptao para as empresas
que desejam ter a velocidade e qualidade de entrega como diferenciais
competitivos. O Scrum, mtodo gil que tem se destacado nos ltimos
anos, tem suas bases em conceitos tradicionais da engenharia de
produo como a filosofia enxuta e a teoria das restries. Assim, o
objetivo deste artigo apresentar um estudo de caso sobre a utilizao
do Scrum em uma empresa do setor de software nacional embasado no
referencial terico sobre o tema. Ser tratado o processo de anlise e
identificao de problemas da situao atual da empresa e a aplicao
do mtodo em questo. Ao final, sero apresentados os principais
resultados obtidos, as limitaes encontradas e concluses que visam
embasar novas iniciativas de aplicao do Scrum.
Palavras-chaves: Desenvolvimento gil, Scrum, Empresa de Software,
Teoria das Restries, Produo Enxuta

1. Introduo
O atual padro de competitividade tem destacado organizaes que tenham conseguido,
atravs do lanamento de novos produtos e servios, acompanhar ciclos de inovao cada vez
mais acelerados no mercado. Segundo Senge (1990), a real vantagem competitiva das
organizaes sua habilidade em aprender mais rapidamente que a concorrncia, em gerar e
compartilhar conhecimento e melhorar de forma contnua sua atuao. Neste contexto, os
ciclos de inovao tecnolgica se destacam nas ltimas dcadas. O tempo entre o lanamento
de novos produtos e servios de tecnologia tem diminudo e as empresas que se deparam com
os desafios de aprendizado e lanamento de novidades no mercado.
Porm, as tentativas de melhoria em relao aos resultados e ao tempo de entrega de projetos
de software no tm 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% so realmente utilizadas no
dia-a-dia.
Estes nmeros revelam um cenrio desfavorvel relacionado real entrega de valor
proporcionada por projetos de desenvolvimento de software. Este cenrio se torna ainda mais
crtico frente necessidade de constantes inovaes para o alcance de posies de destaque no
mercado, conforme colocado anteriormente. Assim, nos ltimos 20 anos, novos mtodos de
desenvolvimento de sistemas de informao surgiram com a proposta de fornecer maior
agilidade e flexibilidade para as empresas. Dentre estes mtodos, destaca-se o Scrum, mtodo
gil de desenvolvimento de software, criado na dcada de 1990 por Jeff Sutherland, com base
em conceitos tradicionais da engenharia de produo como a filosofia enxuta e a teoria das
restries explorados por Takeuchi & Nonaka (1986) no artigo The new new product
development game, no qual descrevem as vantagens da utilizao de times multidisciplinares
e autogerenciveis no desenvolvimento de produtos.
Este artigo tem o objetivo de apresentar um estudo de caso sobre a utilizao do mtodo gil
Scrum em uma empresa do setor de software nacional. Ser tratado o processo de anlise e
identificao de problemas da situao atual da empresa e como o mtodo em questo foi
utilizado como referencial terico para propor solues de melhoria, orientando uma mudana
organizacional.
2. Mtodo
Para a conduo deste trabalho foi seguido um mtodo 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 terico-prticas.

Figura 1 Mtodo de conduo do trabalho

Fonte: os autores
Primeiramente foi realizada uma busca bibliogrfica sobre os conceitos e definies de

Metodologias de Desenvolvimento de Sistemas (MDS). Partiu-se, ento, para o
aprofundamento no mtodo gil de desenvolvimento de sistemas Scrum e os conceitos que
so referenciados como base para a criao deste mtodo.
Foi ento realizado um estudo de caso sobre a aplicao dos conceitos apresentados na
implementao do Scrum em uma empresa do setor de produo e comercializao de
software. A partir da anlise do caso foram apresentados os principais resultados obtidos e as
limitaes encontradas. Por fim, so apresentadas concluses que visam embasar novas
iniciativas de aplicao do Scrum.
4. Referencial Terico
Este item se prope a apresentar os conceitos, terminologias e definies necessrias para o
entendimento do artigo. Sero apresentados conceitos da engenharia de software e das
metodologias de desenvolvimento de sistemas, com foco no Scrum, apontando suas
caractersticas e razes na filosofia enxuta de produo.
4.1. A Engenharia de Software
A engenharia de software, segundo Staa (1987) estabelece e usa slidos princpios de
engenharia para a obteno econmica de softwares confiveis e com funcionamento eficiente
em mquinas reais. Maffeo (1992) corrobora com esta viso e acrescenta que a rea
interdisciplinar que engloba as vertentes tecnolgica e gerencial, visando abordar de modo
sistemtico os processos de construo, implantao e manuteno de produtos de software
com qualidade assegurada, segundo cronogramas e custos previamente definidos.
A partir dessas duas vises, tem-se a necessidade de estabelecer metodologias de
desenvolvimento de software que cumpram os requisitos tecnolgicos e gerencias para
garantir a qualidade do produto entregue e a eficincia dos processos envolvidos.
Cabe ressaltar ainda, segundo Maffeo (1992), os objetivos primrios 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 eficincia e eficcia.

4.2. Metodologias de Desenvolvimento de Software (MDS)

O conceito de ciclo de vida do software surgiu devido necessidade da especificao, em alto
nvel, do conjunto de tarefas que compem 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 caractersticas particulares, em geral esses modelos compartilham as
seguintes (macro) atividades (MAFFEO, 1992): Especificao de Necessidades,
Especificao de Requisitos, Projeto de Software (Design), Implementao de Software,
Implantao e Manuteno do Software.
Carvalho (2009) define as possveis tipologias para as metodologias de desenvolvimento de
software que variam na forma com a qual dispem os recursos (papis, responsabilidades,
tempo, etc.) para a construo do produto software e para a entrega ao cliente final.
4.2.1. O Modelo Cascata ou Clssico
Nesta metodologia, o projeto de desenvolvimento de software dividido em fases executadas
sequenciamente com um conjunto detalhado de documentos especficos a cada macroatividade. So caractersticas desse modelo o grau elevado de documentao, o controle
excessivo das atividades e a baixa participao do usurio final nos processos.
4.2.2. Prototipao
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 prototipao, porm, possui brechas para crticas, na medida em que a ausncia de padres
e processos deixa a qualidade do produto final imprevisvel e passvel de oscilaes. Nesta
perspectiva, para ser um sistema real, aquele deveria seguir padres de qualidade, segurana,
desempenho, capacidade, robustez e facilidade de manuteno, mas, por ser um prottipo,
padres como os citados mostram-se insuficientes ou inexistem (ALVES; VANALLE, 2001).
4.2.3. O Modelo Espiral
As melhores caractersticas dos modelos cascata e prototipao podem ser encontradas no
modelo espiral com o acrscimo de um elemento a anlise dos riscos, inexistentes nos
outros dois modelos (PRESSMAN, 2002). O modelo composto por quatro quadrantes, quais
sejam: Planejamento, Anlise de Riscos, Engenharia e Avaliao.
4.2.4. O Modelo Iterativo e Incremental
Este modelo apresenta uma nfase na reduo do lead time da produo do software. Sua
nfase na liberao de verses que so atualizadas e melhoradas em ciclos de
desenvolvimento consecutivos.
Assim, de cada iterao (composta pelas fases de requisitos, anlise e projeto, codificao e
teste) resulta uma verso do software com um subconjunto de funcionalidades que crescem de
forma incremental a cada iterao at conformar o produto final desejado. (CARVALHO,
2009)
4.2.5. Tcnicas da Quarta Gerao

As tcnicas de quarta gerao, conhecidas pela sigla 4GT, trazem uma abordagem de
especificao de software utilizando funes significativas que aproximam a linguagem de
mquina linguagem natural.
Tecnologias modernas que utilizam a 4GT conseguem passar automaticamente das fases de
especificao para a implementao, incluindo testes automatizados que garantem a
conformidade com os requisitos levantados. As tcnicas de quarta gerao j se tornaram
importantes para o desenvolvimento de aplicaes de sistemas de informao (PRESSMAN,
2002).
4.2.6. Metodologias geis
Um dos problemas relacionados s metodologias mais tradicionais de desenvolvimento de
software est na identificao, registro e tratamento dos requisitos de negcio. No atual
ambiente de desenvolvimento de software, os requisitos esto sujeitos a freqentes
modificaes durante o ciclo de desenvolvimento do produto para atender as alteraes da
demanda (RISING; JANOFF, 2000).
Frente s dificuldades de adaptao dos mtodos tradicionais s necessidades de mudanas
dos processos de desenvolvimento de software, surgiram, durante a dcada de 1990, os
chamados mtodos geis. Estes mtodos foram influenciados pelos princpios da manufatura
enxuta implementados pelas companhias Honda e Toyota e pelas estratgias de gesto do
conhecimento de Takeuchi e Nonaka (2004) e Senge (1990). Tratam-se de metodologias de
desenvolvimento adaptativas e flexveis, e que so indicadas para cenrios onde a mudana de
requisitos constante e os resultados precisam ser entregues ao cliente em curtos espaos de
tempo. (CARVALHO; MELLO, 2009).
No lugar da aderncia e conformidade aos planos iniciais prefervel adaptar aos cenrios
atuais, levando em considerao 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 indivduos e na interao entre eles, no
funcionamento do software, na colaborao com o cliente e na resposta rpida s mudanas.
Isto alcanado atravs de ciclos iterativos de desenvolvimento de sistemas com objetivos de
curto prazo, tonando possvel a adaptao dos requisitos at o momento em que entram em
fase de desenvolvimento.
4.3. O Scrum
Segundo Carvalho e Mello (2009), dentre os diferentes mtodos geis, o que mais se destaca
o Scrum, uma abordagem enxuta de desenvolvimento de produtos. A primeira utilizao 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 possvel dentro de uma srie de
pequenos intervalos de tempo fixo, chamados Sprints, que tipicamente duram menos de um
ms (SUTHERLAND et al., 2000). Ou seja, ao final de cada Sprint, espera-se que sejam
entregues funcionalidades que possam ser utilizadas pelo usurio, gerando valor para seu
negcio ou aumentando sua satisfao em relao ao produto entregue.
O mtodo tem incio com uma reunio denominada Sprint Planning. Na primeira parte desta
reunio, so eleitos os requisitos de sistema registrados no Product Backlog que sero

desenvolvidos ao longo do Sprint. Na segunda parte desta reunio, so discutidas e detalhadas

as atividades envolvidas na execuo de cada item selecionado.
Aps, d-se incio fase de execuo 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, anlise, projeto
e entrega. Durante o Sprint, so realizadas reunies dirias 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 transcendncia
cultural (SUTHERLAND et al., 2000).
Ao final do tempo determinado para o Sprint, realizada uma reunio de entrega do
incremento do produto. Esta ltima reunio chamada Sprint Review.
A ltima reunio 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
prximo ciclo de desenvolvimento.
A figura abaixo retrata a dinmica de processo do Scrum:
Figura 2 Dinmica de processo do Scrum

Fonte: Mar e Schwaber (2001)
O Scrum possui trs papis fundamentais. O Scrum Master deve trabalhar para que o processo
Scrum acontea e para que no existam impedimentos para que os membros da equipe
realizem seu trabalho. Remover os obstculos apontados no Daily Scrum seu dever, de
modo que os desenvolvedores se concentrem apenas nas questes tcnicas (CARVALHO;
MELLO, 2009).
Outro papel importante no mtodo o do Product Owner. Este membro do time representa o
cliente interno ou externo. Ele deve definir quais so os requisitos e qual o grau de
importncia e prioridade de cada um deles (CARVALHO; MELLO, 2009).
Por fim, o ltimo papel destacado pelo Scrum o prprio Time, que deve ser multidisciplinar,
auto-gerencivel e todos devem estar em busca de um objetivo comum.
4.4. A Manufatura Enxuta (Lean Manufacturing)
Como citado, o Scrum tem suas razes nos princpios da manufatura enxuta japonesa. Filho e
Fernandes (2004) propem uma listagem com a sntese desses princpios, que so a base da
manufatura enxuta.

Tabela 1- Princpios da Manufatura Enxuta

Fonte: Filho e Fernandes (2004)
Uma das etapas iniciais e foco da manufatura enxuta o mapeamento do processo de

construo do valor para o cliente (Value Stream Mapping). Atravs dessa ferramenta, so
identificadas as atividades que agregam valor e as que no agregam valor passam a ser
consideradas desperdcios e devem ser eliminadas.
Womack e Jones (2006) evoluem nas atribuies chave da manufatura enxuta e prescrevem os
passos para que uma organizao utilize seus princpios para alavancar sua produo.
- Fornea o valor de fato desejado pelos clientes. Resista ao desejo de trabalhar adiante a
partir da organizao, dos ativos e do conhecimento existentes para convencer os clientes
de que eles querem aquilo que mais fcil de ser produzido pela empresa.
- Identifique o fluxo de valor para cada produto. Esta a sequncia de aes (o processo)
necessrias para trazer um bem ou servio do conceito at o lanamento (pelo processo de
desenvolvimento) e de um pedido at as mos do cliente (pelo processo de proviso).
Questione cada etapa nesses processos, para ver se eles realmente criam valor para o
cliente. Elimine as etapas que no criam.
- Organize as etapas estantes em um fluxo contnuo. 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 mtodos 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 incio, numa busca indefinvel pela perfeio, a situao feliz de valor perfeito
com desperdcio zero.
4.5. A Teoria das Restries
Desenvolvida por Eliyahu M. Goldratt, na dcada de 1980, a Teoria das Restries aponta que
a meta de qualquer organizao maximizar o ndice pelo qual cada empresa gera receita
atravs de suas vendas lquidas (conceito que em ingls apresentado como throughput)
Segundo Goldratt e Cox (1990), a meta de qualquer organizao garantir dinheiro no
presente, bem como garantir sua continuidade no futuro. Para tal, a teoria parte da
identificao 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 organizaes apresentam restries, isto , impedimentos que
reduzem a eficincia dos sistemas produtivos. Nesse sentido, parte da teoria dita que o foco do

esforo gerencial deve ser na otimizao dos gargalos e na reduo das restries que
influenciam as etapas de agregao de valor.
Dentre as mximas da Teoria das Restries dito que uma hora perdida na operao do
posto gargalo uma hora perdida para o sistema todo. Desta afirmao retirada da prpria
obra A Meta (GOLDRATT; COX, 1990), tem-se que a operao do gargalo dita o
desempenho global da linha produtiva e do negcio.
5. O Caso
O caso apresentado baseado em um projeto de anlise da situao atual e proposies de
melhorias para a metodologia de desenvolvimento de sistemas de uma empresa do setor de
software, que resultou na implementao do Scrum em seu processo produtivo.
5.1. A Organizao e o Contexto do Projeto
Este trabalho foi realizado em uma empresa brasileira com atuao internacional
especializada em solues relacionadas Governana, Riscos e Compliance (GRC). A
empresa atua nas reas de desenvolvimento e comercializao de software para automatizao
de solues de GRC, consultoria e educao nesta rea. Seus clientes esto localizados no
Brasil, Amrica Latina, Estados Unidos e Europa.
Para manter seu sistema atualizado frente s inovaes do mercado de GRC e s necessidades
de customizao demandadas por seus clientes, a equipe tcnica da empresa lida
constantemente com uma srie de mudanas e atualizaes 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
atualizaes no software, o que gerou uma presso sobre a diretoria tcnica a respeito da
eficincia de sua equipe de desenvolvimento de sistema. Juntamente a este cenrio, a alta
gesto da empresa colocava em prtica aes para a otimizao de recursos. Assim, o diretor
tcnico, em parceria a um grupo externo, conduziu uma iniciativa para a avaliao da atual
metodologia utilizada para o desenvolvimento do software, identificao de pontos crticos e
proposio de melhorias.
5.2. A situao atual do processo de desenvolvimento de sistema da organizao
O estudo teve incio com o mapeamento da situao atual dos processos de desenvolvimento
de sistemas da empresa anteriormente implementao do Scrum. Em primeiro lugar, era
preciso entender como o processo de desenvolvimento estava organizado. Para tanto, foi
construdo um esquema que representava a situao atual do processo, desde a chegada de
novas demandas at a entrega do software.

Figura 3 Macroatividades do processo de desenvolvimento de sistema

Fonte: os autores
A figura anterior representa o macroprocesso de desenvolvimento. Este tem incio com o

recebimento de novos requisitos para serem implementados no sistema ou modificaes em
requisitos j existentes. Estes requisitos so ento priorizados e a equipe de especificao
produz, para cada um, um documento detalhado sobre suas caractersticas, regras de negcio
envolvidas e critrios de aceitao, chamado de Especificao do Requisito. Este documento
utilizado em todas as demais etapas do processo e serve como padronizao para as
informaes que serviro de insumo para as atividades posteriores.
Aps a Especificao do Requisito, realizado o desenvolvimento do cdigo do sistema e de
seu contedo (como questionrios para avaliaes de risco, por exemplo). O cdigo passa
ento por alguns testes e, aps os ajustes necessrios, ocorre a implantao do sistema para os
usurios internos equipe tcnica.
Assim, seguem-se os testes de qualidade no software (Quality Assurance - QA), onde so
simuladas situaes cotidianas de utilizao do sistema para a correo final de possveis
erros. Ento, o software pode ser liberado para o cliente final e instalado nos ambientes de
produo.
possvel perceber que o processo de desenvolvimento da empresa estava organizado
conforme o mtodo cascata. Nesse modelo, o projeto passa por diversas etapas (anlise,
design, documentao, codificao e testes) antes de ser entregue ao cliente (ROSE e MELLO
apud LOESER, 2010), diminuindo a flexibilidade do processo e prejudicando a obteno de
repostas rpidas s exigncias de mercado por parte da empresa (ROSE; MELLO, 2010).
Para entender detalhadamente de que forma estas caractersticas inerentes ao mtodo cascata
afetavam a produtividade da equipe de desenvolvimento da empresa, o macroprocesso
identificado foi dividido em 45 atividades e os seus respectivos responsveis foram
entrevistados. Para tal, foi utilizado um questionrio padro com as seguintes perguntas:
a) Qual o objetivo da atividade?
b) Quais so os inputs necessrios para a execuo da atividade? Qual a qualidade destes
inputs? Existe retrabalho para a atividade devido m qualidade dos inputs?
c) Quem e quantos so os envolvidos na execuo da atividade?
d) Quais so os recursos utilizados (documentos, sistemas etc.)?
e) Quanto tempo, em mdia, demora a execuo da atividade?
f) Quais so os outputs gerados pela atividade? Qual a qualidade destes outputs? Existe
retrabalho para a atividade devido m qualidade dos outputs?

g) Quais crticas podem ser colocadas quanto atividade, aos recursos necessrios e
comunicao com as equipes responsveis pelas demais atividades?
Como resultado das informaes obtidas atravs das entrevistas, foi possvel a caracterizao
mais detalhada da situao atual da empresa. Alguns pontos crticos foram postos em
evidncia, demonstrando algumas dificuldades encontradas pela equipe tcnica:
- Um ano antes deste estudo, houve uma reestruturao na metodologia de desenvolvimento
da empresa devido migrao do software para uma verso mais avanada. Novas
atividades foram criadas, dentre elas, a especificao dos requisitos.
Esta atividade, apesar de ser considerada crtica para a garantia da qualidade do produto
final, era realizada por uma equipe com pouca experincia na empresa e ainda no possua
papis e responsabilidades bem definidos.
- Conforme mencionado, a equipe de especificao era responsvel pela elaborao das
Especificaes dos Requisitos utilizadas como base por todas as demais etapas do processo
de desenvolvimento. Devido pouca experincia desta equipe, o aparente
subdimensionamento e a falta de processos que orientassem a execuo das atividades,
pode-se identificar o seguinte cenrio.
Figura 4 Ponto crtico do processo produtivo: divergncia de informaes

Fonte: os autores
O processo de desenvolvimento de sistemas exige interpretao da Especificao do Requisito

para sua traduo em cdigos de programao. Porm, a baixa qualidade destes documentos
levava os codificadores a implementar funcionalidades diferentes das descritas, sem o correto
registro das mudanas realizadas no documento original (a Especificao do Requisito).
Aps a codificao, o software era repassado para as demais etapas. Uma vez que as equipes
responsveis por estas atividades posteriores utilizavam a Especificao do Requisito como o
documento que detalhava o que deveria estar implementado no software, a divergncia entre o
documento e o que era encontrado no sistema gerava conflitos de informaes e retrabalho
para toda a equipe tcnica dada a falta de registro das mudanas realizadas.
De acordo com Womack e Jones (2006), uma das atividades relacionadas filosofia enxuta de
produo consiste em identificar o fluxo de valor para cada produto, do ponto de vista do
cliente, questionar cada etapa desses processos sobre a real criao de valor e buscar eliminar
as etapas que no criam o valor real. Nesta empresa, a correo da documentao e
recodificao do sistema podem ser classificadas como atividades que no agregavam valor
para o cliente. Estas eram resultado de erros cometidos pela equipe tcnica. Sendo assim, de
acordo com a filosofia enxuta, o retrabalho gerado pela baixa qualidade das especificaes
deveria ser eliminado.
10

Alm disso, a capacidade de entrega da equipe de especificao ainda no havia atingido o

nvel de eficincia que as demais reas j tinham adquirido devido a sua pouca experincia em
lidar com as particularidades do sistema daquela empresa, comparada s demais equipes.
Segundo Goldratt e Cox (1990), luz da teoria das restries, entende-se gargalo como todo
recurso que possui uma capacidade menor do que a sua demanda. Assim, a etapa de
especificao 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 otimizao deste
gargalo.
5.3. Implementao da metodologia Scrum
Como j mencionado, a metodologia de sistemas Scrum foi criada com base nos princpios
enxutos de produo, visando eliminar os gargalos e balancear o fluxo de produo do mtodo
tradicional atravs da criao de times multidisciplinares, que deveriam trabalhar em
conjunto, prezando pela comunicao entre seus membros e o foco em uma meta
compartilhada. Sobre o fluxo de produo, Takeuchi e Nonaka (1986) colocam que o ritmo de
cada indivduo e o ritmo do grupo se tornam o mesmo, criando um pulso completamente
novo. Este pulso serve como uma fora motriz e move o time para frente.
Um estudo realizado por Carvalho e Mello (2009) revelou que o benefcio proporcionado pelo
Scrum mais citado pelas publicaes sobre o tema a melhoria na comunicao e aumento
da colaborao entre os envolvidos. Alm disso, Sutherland (2004) relata que em um projeto
de desenvolvimento realizado pela Microsoft onde foi utilizada a lgica do Scrum, foi obtida
a maior produtividade por desenvolvedor j documentada.
Assim, o Scrum se demonstrou a soluo que melhor supria as necessidades da empresa
estudada. Esta deciso significava o reprojeto do macroprocesso produtivo da empresa e o
apoio da alta direo foi considerado fator crtico para o sucesso da implementao da
metodologia.
Uma particularidade da implantao do Scrum na empresa diz respeito deciso de deixar os
profissionais da rea de Quality Assurance fora dos times multidisciplinares. Por questes de
poltica interna empresa, preferiu-se no envolver estes profissionais inicialmente e apostar
em uma incluso progressiva visando uma curva de aprendizagem.
Conforme mostra a figura 2, apresentada anteriormente, que explicita a dinmica do processo
do Scrum, o resultado entregue ao final dos Sprints deve ser um incremento do produto.
Porm, a figura abaixo demonstra que, para a empresa estudada, o resultado entregue pelos
times Scrum no pode ser diretamente entregue ao cliente, visto que ainda resta a etapa de
testes realizada pela equipe de QA (que no foi includa nos times). Esta foi a soluo
encontrada para uma barreira poltica da empresa, que adaptou o mtodo para o momento da
mudana imediata.
11

Figura 5 Composio dos times Scrum

Fonte: os autores
Foi decidido por uma estratgia de mudana 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 conscientizao e disseminao da cultura gil por toda a
equipe tcnica. Para tanto, todos receberam um treinamento no mtodo Scrum. Aps a
realizao do treinamento, foram definidos os componentes dos times e houve a escolha dos
Scrum Masters (que seriam trocados a cada trs meses).
Para a adaptao dos profissionais nova metodologia, ao longo de janeiro de 2011 foram
realizados dois Sprints experimentais, apenas para a resoluo de bugs antigos do sistema.
Este perodo de adaptao foi utilizado para observar possveis pontos de melhoria no mtodo
implementado.
Por fim, para o controle da evoluo da nova metodologia, foram determinados alguns
indicadores de desempenho como Eficcia do Trabalho, ndice de Trabalho
Remanescente, Densidade de erros por linha de cdigo, Tempo Mdio de Resoluo de
Impedimentos e Avaliao da Satisfao do Product Owner.
O processo de implantao do Scrum ocorreu durante 40 dias e foi finalizado na segunda
semana de janeiro de 2011. Desde ento, o progresso do mtodo vem sendo acompanhado
atravs de indicadores de desempenho e, de acordo com as necessidades impostas pela rotina
e pelas particularidades da organizao, so feitos ajustes nos processos.
Com a formao de times multidisciplinares, os profissionais responsveis pela especificao
dos requisitos passaram a ter a oportunidade de adquirir experincia com outros profissionais
da equipe tcnica e o processo de comunicao constante ajuda a diminuir o retrabalho devido
a inconsistncias nos documentos gerados.
5.4. Concluses
Este estudo apontou a utilizao de um mtodo gil de desenvolvimento de sistemas, o
Scrum, como referencial para a transformao da estrutura de processos de uma empresa do
setor de software. Foram apresentados os conceitos que suportam a discusso e, em seguida, o
caso foi explicitado.
Aps a implantao da situao projetada, pode-se considerar que houve uma mudana
significativa na organizao, uma vez que esta iniciativa impactou o dimensionamento do
12

quadro de pessoal, a diviso de papis e responsabilidades, os mecanismos de coordenao e

os processos produtivos.
Todavia, durante este estudo foram identificadas dificuldades prticas na execuo dos
conceitos previstos pelo Scrum, que devem servir de motivao para novos estudos que
avancem no conhecimento sobre a aplicabilidade do mtodo. Entre elas, pode-se citar a
dificuldade de reprojetar a estrutura de cargos e salrios para uma nova realidade em que
novos papis so propostos e as estruturas de poder so alteradas.
Ainda, a multifuncionalidade total do time, isto , a presena de profissionais com habilidades
e conhecimentos que garantissem todas as etapas necessrias para a entrega do produto, no
conseguiu ser implantada. Dentre os motivos para essa deciso aponta-se o conflito de
interesses e o impacto para a diviso de poder da empresa, podendo ser um fator contra o
objetivo de ganho de produtividade e melhoria na comunicao interna. Optou-se ento por
uma soluo hbrida que manteve fora do time multifuncional uma rea de qualidade (QA).
Como fator positivo que merece destaque neste estudo foi o patrocnio da alta direo da
empresa que orientou as mudanas internas no sentido da implantao da nova estrutura
organizacional, o treinamento em Scrum oferecido para todos os profissionais e uma
campanha de comunicao eficiente que orientou todos nas transformaes que seriam feitas
nas estruturas de cargos e salrios da empresa.
O principal ganho para a organizao foi o aumento da responsividade s mudanas
necessrias no software que comercializa e, com isso, a rapidez de entrega de novas verses e
atualizaes para o mercado. Uma vez que o contexto apresentado, no qual o mercado de
sistemas de informao demanda organizaes que tenham flexibilidade e trabalhem com um
equilbrio nos fatores qualidade e prazo, o mtodo Scrum se apresentou uma referncia
eficiente para a estruturao dos processos de desenvolvimento de software ajustado s
necessidades de mercado.
Todavia, esse estudo serviu tambm para apresentar possveis restries e dificuldades que
futuras organizaes possam vir a ter com a escolha do mtodo. Para isso, abrem-se novos
campos de estudo para entender em quais outras ocasies essas restries tambm se aplicam
e, com isso, evoluir na compreenso do Scrum.
Referncias Bibliogrficas
ALVES, R. F., VANALLE, R. Ciclo de Vida de Desenvolvimento de Sistemas viso conceitual dos modelos
clssico, espiral e prototipao, 2001.
CARVALHO, B. V.; MELLO, C. H. P. Reviso, anlise e classificao da literatura sobre o mtodo de
desenvolvimento de produtos gil Scrum. Anais do XII Simpsio de Administrao da Produo, Logstica e
Operaes Internacionais - SIMPOI, So Paulo/SP, 2009. FRANCO, 2006
CARVALHO, E. Engenharia de Processos de negcios e a engenharia de requisitos: anlise e comparaes de
abordagens e mtodos de elicitao de requisitos de sistema orientada por processos de negcio. 2009. 225 f.
Dissertao (Mestrado em Engenharia de Produo) COPPE, UFRJ. Rio de Janeiro, 2009.
FILHO M. G.; FERNANDES, F. C. F. Manufatura enxuta: uma reviso que classifica e analisa os trabalhos
apontando perspectivas de pesquisas futuras, Gesto e Produo, 2004
GIL, A. C. Mtodos e tcnicas de pesquisa social. So Paulo, Atlas, 1999.
GOLDRATT, E. M. e COX, J. A Meta. So Paulo, IMAM, 1990.
MAFFEO, B. Engenharia de Software e Especificao de Sistemas. Rio de Janeiro: Campus, 1992.
13

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

Consultado em abril de 2011.
MENEGON, N. L.; ANDRADE, S. R. Projeto do Produto em Engenharia de Produo, Encontro Nacional de
Engenharia de Produo ENEGEP, 1998.
PRESSMAN, R.S. Software Engineering: a practitioners 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 sistemtica para a gesto de projetos baseada na metodologia gil
Scrum, Encontro Nacional de Engenharia de Produo ENEGEP, So Carlos, So 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 Tcnicos e Cientficos, 1987.
STANDISH GROUP. Extreme CHAOS. The Standish Group International Inc., 2009. Disponvel 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. 137146, 1986.
YOURDON, E. Anlise Estruturada Moderna. 3 ed. Rio de Janeiro: Campus, 1990.
WOMACK, J. P.; JONES, D. T. Solues Enxutas: Como Empresas e Clientes Conseguem Juntos Criar Valor
e Riqueza. Editora Campus, 2006.
14

Artigo02 Metodos Ageis de Desenvolvimento de Software

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Artigo02 Metodos Ageis de Desenvolvimento de Software

Загружено:

Авторское право:

Доступные форматы

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Inovao Tecnolgica e Propriedade Intelectual: Desafios da Engenharia de Produo na Consolidao do Brasil no

Os ciclos de inovao tecnolgica cada vez mais curtos tm exigido

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Figura 1 Mtodo de conduo do trabalho

Primeiramente foi realizada uma busca bibliogrfica sobre os conceitos e definies de

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

4.2. Metodologias de Desenvolvimento de Software (MDS)

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

desenvolvidos ao longo do Sprint. Na segunda parte desta reunio, so discutidas e detalhadas

Figura 2 Dinmica de processo do Scrum

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Tabela 1- Princpios da Manufatura Enxuta

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

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Figura 3 Macroatividades do processo de desenvolvimento de sistema

A figura anterior representa o macroprocesso de desenvolvimento. Este tem incio com o

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Figura 4 Ponto crtico do processo produtivo: divergncia de informaes

O processo de desenvolvimento de sistemas exige interpretao da Especificao do Requisito

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Alm disso, a capacidade de entrega da equipe de especificao ainda no havia atingido o

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Figura 5 Composio dos times Scrum

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

quadro de pessoal, a diviso de papis e responsabilidades, os mecanismos de coordenao e

XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

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

Вам также может понравиться