Edição38 2011

Modstia parte, sua
melhor opo para

se destacar no mercado!
A Escola Superior da Tecnologia da
Informao oferece as melhores
opes em cursos, formaes,
graduaes e ps-graduaes para
profissionais de desenvolvimento
e programao.
So programas voltados para a
formao de profissionais de elite,
com aulas 100% prticas, corpo
docente atuante no mercado,
acesso mais atualizada biblioteca
de TI do Rio, laboratrios equipados
com tecnologia de ponta, salas de
estudo e exames.
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
F ORMAES
Desenvolvedor Java
Desenv. Java: Sist. Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
r/esti
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti
TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
Rodrigo Oliveira Spnola

rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de
Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao (UNIFACS, 2001). Colaborador
da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para
implementao do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
Marco Antnio Pereira Arajo
Ano 3 - 38 Edio - 2011
maraujo@devmedia.com.br
Corpo Editorial
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa

em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em
Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do
curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e
Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador
da Engenharia de Software Magazine.
Editor
Rodrigo Oliveira Spnola
Colaboradores
Eduardo Oliveira Spnola

eduspinola@gmail.com
Jornalista Responsvel
Kaline Dolabella - JP24185
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o
mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA
(Grupo de Engenharia de Software e Aplicaes).
Na Web
www.devmedia.com.br/esmag
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se
voc tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/mancad
(21) 2220-5338
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc
gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para
entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
de publicar.
Apoio
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
EDITORIAL
or muito tempo a indstria se ancorou em mtodos que buscavam maior previsibilidade

para o desenvolvimento de software, procurando entender de antemo e geralmente
fixar qual seria o escopo, o custo e o prazo de desenvolvimento. Ao longo dos anos, contudo, percebeu-se que a to esperada previsibilidade no se provou verdadeira, especialmente para
projetos nos quais se busca o desenvolvimento cientfico de tecnologias que ainda no existem.
Contudo, mesmo para projetos em que a tecnologia de certa forma trivial, a complexidade dos
negcios envolvidos torna tambm o processo imprevisvel. muito comum o mercado mudar suas
necessidades, ou mesmo o prprio cliente no saber o que quer at que comece a ver partes disso
funcionando.
Desta forma, percebeu-se que os mtodos tradicionais de desenvolvimento como o Waterfall
ou mesmo o RUP eram pesados demais em termos de documentao e hierarquia entre os
indivduos e no permitiam o grau de aprendizado necessrio para que pudssemos simplificar
o desenvolvimento de software. Assim, no final dos anos 90, alguns autores comearam a experimentar mtodos mais leves, baseados em uma maior interao entre os indivduos e tambm
na entrega incremental e constante de software funcionando, que pudesse ser utilizado pelo
cliente mesmo antes de ter seu escopo completo.
Nesta mesma poca, algumas metodologias comearam a se consolidar e ento foi fundada a
Agile Alliance, uma organizao sem fins lucrativos que tem por objetivo disseminar o uso e o
desenvolvimento de todas as metodologias que compartilham dos mesmos princpios e valores
do manifesto gil. O grande objetivo do manifesto e da Agile Alliance fomentar o desenvolvimento
de software para permitir uma entrega de maior valor agregado mais rapidamente, buscando uma
indstria de software mais produtiva, humana e sustentvel.
Infelizmente, hoje muito fcil observar que diversas empresas ainda sofrem com ambientes improdutivos, de baixssima qualidade e, em alguns casos, desumanos. Sendo assim, encontrar uma
maneira efetiva e menos dolorosa para a adoo de mtodos geis tornou-se vital. Em geral, as
empresas iniciam este processo de adoo com Scrum, por tratar-se de um framework simples e
de fcil utilizao. Apesar de ser um framework que permite uma melhora significativa da produtividade e da gerenciabilidade, o Scrum peca em no trazer nenhuma orientao sobre as prticas de
engenharia. Ele permitir maior agilidade em responder s mudanas impostas pelo mercado, mas
responder a estas mudanas pode ser traumtico caso no estejamos preparados com uma base
de cdigo slida e que nos permita real segurana na hora de mudarmos nosso software. Como
a maioria das empresas que querem adotar mtodos geis no tiveram o uso de boas prticas de
engenharia, adotar o Scrum sem dar a devida ateno ao cdigo pode ser realmente doloroso.
Por este motivo, criou-se um conceito que visa auxiliar as empresas a equilibrar corretamente o uso
de prticas, princpios e valores em todos os nveis de uma organizao, com o objetivo de promover uma mudana segura e sustentvel na cultura interna e nos mtodos de desenvolvimento.
Este conceito foi batizado de A Pirmide Lean, ttulo do artigo de capa desta edio da Engenharia
de Software Magazine. Neste artigo veremos como equilibrar a aplicao de prticas, princpios e
valores no desenvolvimento de software a fim de criar uma cultura organizacional enxuta e gil. O
conceito abordado neste artigo serve para a criao, adoo e disseminao da cultura Lean e gil
de forma efetiva em uma organizao que desenvolve software.
Alm desta matria, esta edio traz mais seis artigos:
MacGyver: Gesto Perigo
Uma viso geral sobre o Scrum
A Gerncia de Projetos de Software em Duas Perspectivas Parte 2
Uso de metodologias geis em uma organizao baseada em linha de produto
Modelagem de processos usando ARIS
Refatorao para Padres Parte 11
Desejamos uma tima leitura!
Caro Leitor,
Para esta edio, temos um conjunto de 4 vdeo aulas. Estas vdeo aulas
esto disponveis para download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
NDICE
Por trs do bvio
06 MacGyver: Gesto Perigo
Glnio Cabral
Agilidade
07 - A Pirmide Lean: O Equilbrio das Foras geis
Samuel Crescncio
20 - A gerncia de projetos de software em duas perspectivas Parte 2: Scrum

Geraldo Magela Dutra Gonalves
Tipo: Processo
Ttulo: Curso Scrum Product Owner Partes 1 a 4
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Esta uma srie de aulas de um treinamento voltado exclusivamente para Product Owners. O Product Owner um papel prescrito
pelo mtodo gil SCRUM responsvel pelo sucesso ou fracasso do desenvolvimento de um produto. Este um papel complexo de ser exercido no
dia-a-dia e, este curso, distribudo em uma sequncia de vdeo-aulas, tem
como objetivo tornar mais fcil a transio para aqueles que pretendem
ou necessitam trabalhar como Product Owner.
27 - Uso de metodologias geis em uma organizao baseada em linha de produto

Giselle Tavares e Felipe Furtado
Engenharia
33 - Modelagem de processos usando ARIS
Ronney Moreira de Castro, Wellington Moreira de Oliveira e Jos Luis Braga
Desenvolvimento
40 - Refatorao para Padres Parte 11
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Edio 05 - Engenharia de Software Magazine
Por trs do bvio

Glnio Cabral
gleniocabral@yahoo.com.br
Administrador de Empresas, ps-graduado em Gesto de Pessoas e msico. Idealizador do site de educao infantil www.novainfancia.com.br.
MacGyver: Gesto Perigo
Engenharia de Software - MacGyver: Gesto Perigo
A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
D
s
D seu feedback sobre esta edio!
Feedback
eu
sobre e
s
importando os meios envolvidos. J ser eficaz alcanar os

resultados levando-se em conta a forma como sero alcanados. Em tempos de competitividade acirrada, organizaes
que agem focando apenas os resultados estaro dando um
grande passo rumo estagnao. Na nfase restrita aos
resultados, os meios acabam sendo desconsiderados e os objetivos finais so seriamente comprometidos. Gestes apenas
eficientes, baseadas no jeitinho brasileiro, estimulam a irresponsabilidade administrativa e o improviso para alcanar as
metas de qualquer maneira. Quem age assim muitas vezes
age sem pesquisa, sem planejamento, sem profissionalismo
e sem tica.
MacGyver sempre conseguiu alcanar bons resultados
sendo apenas eficiente. O problema surgia, ele improvisava
e pronto, tudo resolvido. Dava gosto de se v o talento do
cara. A questo que muito mais fcil ter sucesso sendo
eficiente no mundo imaginrio. Mas no mundo real, onde a
competitividade exige por parte das corporaes cada vez
mais planejamento, especializao e comprometimento, sobreviver na base do improviso e do jeitinho brasileiro como
assistir ao seriado do MacGyver: d at vontade de imitar,
mas no passa de uma fico.
edio
ta
as sries que mais fizeram a minha cabea nos anos

80 eu destacaria uma: MacGyver. MacGyver era um
agente especial do governo americano que enfrentava situaes de perigo usando apenas sua grande capacidade
de improvisao. O cara era to bom no improviso que se
fosse o caso ele conseguiria transformar um clipe de papel
em uma montanha russa! Haja criatividade...
Por isso sempre achei que esse seriado era inspirado no
povo brasileiro. Afinal, ningum, no mundo inteiro, to
bom na arte da improvisao quanto o povo das bandas de
c. O problema que de vez em quando esse trao marcante
de nossa cultura recebe um rtulo, digamos, meio pejorativo:
jeitinho brasileiro. O que ento o jeitinho brasileiro?
Jeitinho brasileiro toda ao que tenta resolver uma situao de conflito transgredindo temporariamente algumas
regras, no importando as questes morais envolvidas. Assim, trafegar pelo acostamento, entrar no estacionamento pela
contramo, dar dinheiro para o guarda esquecer a multa ou
furar uma fila so exemplos clssicos de aes impregnadas
pelo esprito do jeitinho, que visa impor o que conveniente
sobre o que certo. Em outras palavras, o coletivo que se
dane!.
A boa notcia que o jeitinho brasileiro apenas o lado
ruim da nossa capacidade inventiva. Algum j disse que a
criatividade do brasileiro to grande que se no for devidamente direcionada rumo eficcia, ser apenas eficiente em
seus resultados. o que acontece nas organizaes, quando
o jeitinho brasileiro se faz presente em suas rotinas.
Sabemos que h uma grande diferena entre ser eficiente e ser eficaz. Ser eficiente alcanar os resultados no
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
A Pirmide Lean
O Equilbrio das Foras geis
De que se trata o artigo?
Samuel Crescncio
samuel.crescencio@oncast.com.br
Twitter: @screscencio
Samuel atua como engenheiro de software

construindo sistemas de misso crtica desde 1994. Fundador e CEO da OnCast Technologies - empresa que tornou-se referncia
na Amrica Latina em metodologias geis
- Samuel adquiriu uma grande experincia
em desenvolvimento gil distribudo, fato
que tornou-o apaixonado pela melhoria
de processos. Reconhecido como um lder
na comunidade internacional, Samuel
foi presidente do giles2009 - a segunda
edio da Conferncia Latino Americana
de Mtodos geis e tambm do Pensando
Lean Forum internacional para corporaes enxutas. Samuel membro do comit
de organizao do Agile Brazil - Conferncia Brasileira de Metodologias geis e
tambm possui um assento no Board of
Directors da Agile Alliance. Samuel Lean
Software Development Practitioner desde
2003, Certified Scrum Master e profundo
conhecedor de diversas tecnologias.
Neste artigo veremos como equilibrar a aplicao

de prticas, princpios e valores no desenvolvimento de software a fim de criar uma cultura
organizacional enxuta e gil. O conceito abordado
neste artigo serve para a criao, adoo e disseminao da cultura Lean e gil de forma efetiva
em uma organizao que desenvolve software.
velocidade com que ocorreu o

desenvolvimento tecnolgico
nos ltimos 50 anos certamente impressionante. Em poucos anos
podemos ver tecnologias surgindo e
evoluindo muito rpido, algumas vezes
se tornando padres da indstria. Outras, porm, desaparecem com a mesma
velocidade que vieram. Esta mesma
evoluo pode ser tambm notada nos
mtodos que utilizamos para desenvolver software, mas possivelmente de uma
forma no to rpida.
Por muito tempo a indstria se ancorou
em mtodos que buscavam maior previsibilidade para o desenvolvimento de software, procurando entender de antemo
e geralmente fixar qual seria o escopo, o
custo e o prazo de desenvolvimento. Ao
longo dos anos, contudo, percebeu-se
que a to esperada previsibilidade no
Em que situao o tema til?

Qualquer empresa que visa aprimorar seus
mtodos de desenvolvimento vai usufruir do
conhecimento descrito neste artigo.
se provou verdadeira, especialmente

para projetos nos quais se busca o desenvolvimento cientfico de tecnologias
que ainda no existem. Contudo, mesmo
para projetos em que a tecnologia de
certa forma trivial, a complexidade dos
negcios envolvidos torna tambm o
processo imprevisvel. muito comum
o mercado mudar suas necessidades, ou
mesmo o prprio cliente no saber o que
quer at que comece a ver partes disso
funcionando. Quando o conhecimento
sobre a tecnologia e sobre os negcios
baixo, a gesto dos projetos torna-se muito complexa, algumas

vezes gerando caos e anarquia. Observe a Figura 1.
Figura 1. Interseo do conhecimento entre tecnologia e negcio
Desta forma, percebeu-se que os mtodos tradicionais de

desenvolvimento como o Waterfall ou mesmo o RUP eram
pesados demais em termos de documentao e hierarquia
entre os indivduos e no permitiam o grau de aprendizado
necessrio para que pudssemos simplificar o desenvolvimento de software. Assim, no final dos anos 90, alguns autores
comearam a experimentar mtodos mais leves, baseados em
uma maior interao entre os indivduos e tambm na entrega
incremental e constante de software funcionando, que pudesse ser utilizado pelo cliente mesmo antes de ter seu escopo
completo. Algumas vertentes surgiam e estes pesquisadores
observaram semelhanas entre os experimentos. Assim, em
2001, 17 especialistas em Engenharia de Software se reuniram
na cidade de Salt Lake City nos Estados Unidos e assinaram o
que hoje conhecemos como Manifesto gil para o desenvolvimento de software.
Nesta mesma poca, algumas metodologias comearam a se
consolidar e ento foi fundada a Agile Alliance, uma organizao sem fins lucrativos que tem por objetivo disseminar o
uso e o desenvolvimento de todas as metodologias que compartilham dos mesmos princpios e valores do manifesto gil.
O grande objetivo do manifesto e da Agile Alliance fomentar
o desenvolvimento de software para permitir uma entrega de
maior valor agregado mais rapidamente, buscando uma indstria de software mais produtiva, humana e sustentvel.
Com o advento dos mtodos geis, podemos observar uma
transio da indstria de software. Hoje, 10 anos depois do
evento em Salt Lake City, j falamos que o desenvolvimento
gil main stream na indstria e que as empresas que no
se adaptarem esto possivelmente fadadas ao fracasso, seja no
curto, mdio ou longo prazo.
Infelizmente, hoje muito fcil observar que diversas
empresas ainda sofrem com ambientes improdutivos, de
Engenharia de Software Magazine - A Pirmide Lean
baixssima qualidade e, em alguns casos, desumanos. Sendo assim, encontrar uma maneira efetiva e menos dolorosa
para a adoo de mtodos geis tornou-se vital. Em geral, as
empresas iniciam este processo de adoo com Scrum, por
tratar-se de um framework simples e de fcil utilizao. Apesar
de ser um framework que permite uma melhora significativa
da produtividade e da gerenciabilidade, o Scrum peca em no
trazer nenhuma orientao sobre as prticas de engenharia.
Ele permitir maior agilidade em responder s mudanas impostas pelo mercado, mas responder a estas mudanas pode
ser traumtico caso no estejamos preparados com uma base
de cdigo slida e que nos permita real segurana na hora de
mudarmos nosso software. Como a maioria das empresas que
querem adotar mtodos geis no tiveram o uso de boas prticas de engenharia, adotar o Scrum sem dar a devida ateno
ao cdigo pode ser realmente doloroso.
Por este motivo, criou-se um conceito que visa auxiliar as empresas a equilibrar corretamente o uso de prticas, princpios e
valores em todos os nveis de uma organizao, com o objetivo
de promover uma mudana segura e sustentvel na cultura
interna e nos mtodos de desenvolvimento. Este conceito foi
batizado de A Pirmide Lean, apresentado na Figura 2.
Figura 2. Pirmide Lean
O primeiro aspecto que precisamos trabalhar quando desejamos

adotar o desenvolvimento gil com eficcia a transformao
cultural necessria para o sucesso da empreitada. Um caso verdico ocorreu em uma das maiores empresas de ERP do Brasil. L
estavam presentes cerca de 35 pessoas, incluindo o presidente e
todo o conselho de administrao, juntamente com o primeiro
nvel de gerncias. Durante o trabalho, o presidente disse: esse
mtodo realmente maravilhoso e acredito que pode resolver nossos problemas, mas no posso simplesmente baixar um decreto
e esperar que seja usado. Com toda razo, a mudana cultural
no pode ser imposta, mas precisa ser suportada. O suporte
mudana precisa ser geral, no somente da gerncia executiva,
mas tambm do cho de fbrica. Normalmente, a primeira reao
das pessoas a resistncia sendo assim, imposio nunca ser
o melhor caminho. preciso abrir espao, dar as ferramentas
adequadas e criar um ambiente que seja propcio mudana.
M etod ologias geis
Uma das primeiras coisas necessrias para isso uma boa

definio e um claro entendimento dos valores e princpios
que a organizao segue. Os valores no servem apenas para
estar num quadro bonito na recepo da empresa. Conhecer
e exercitar os valores precisam ser uma tarefa diria de todos
os membros da organizao. Na OnCast, por exemplo, no se
trabalha como uma organizao hierrquica e burocrtica;
assim no h regras para tudo. Por este motivo, todos os colaboradores so orientados a refletirem quando esto tomando
uma deciso. Se esta deciso fere algum valor da empresa, eles
so encorajados a procurar uma alternativa. Veja a Figura 3.
mudar e, acima de tudo, disciplina e iniciativa para fazer

isto continuamente.
Alm desses princpios, no se pode deixar de frisar alguns
princpios do Lean definidos por Mary e Tom Poppendieck
que so tambm uma base slida para a construo do pensamento Lean:
Construir com integridade;
Respeitar as pessoas;
Entregar rpido;
Ver o todo.
Na indstria de software existem profissionais extraordinrios, mas h tambm muitos deprimentes. S h dois motivos
para algum fazer um trabalho ruim: falta de conhecimento
ou m vontade. De qualquer forma, a todos os seres humanos
viventes foi dado uma coisa igual, o tempo. O tempo igual
para todos. Por isso, devemos aproveitar as oportunidades
para fazer bem feito e com integridade absoluta tudo o que
nos foi confiado.
Figura 3. Valores considerados
Alm de definir adequadamente seus prprios valores, uma

organizao que deseja ser efetivamente gil precisa tambm
entender e trabalhar com os valores e princpios do manifesto
gil. O Manifesto gil costuma ser mal interpretado, especialmente por pessoas que nunca tiveram contato e no conhecem
o que significa ser gil. Por este motivo, importante tambm
refletir sobre seus princpios.
Depois de entender bem os valores da organizao, preciso
ento compreender os seus princpios. Os princpios do manifesto gil so uma excelente base, mas os princpios do Lean
so tambm utilizados na Pirmide Lean como pilares para a
criao de uma cultura que possa permear toda a organizao
e assim criar uma empresa efetivamente gil e enxuta.
Neste conceito da Pirmide Lean, foi criado um sumrio
dos princpios do Lean para que assim possamos entender
de forma simplificada como eles se aplicam na organizao.
Vamos a eles:
Entregar um fluxo contnuo de valor para os clientes;
Criar uma organizao que aprende;
Criar um ambiente de melhoramento contnuo.
Ter uma mente pensando de forma enxuta no tarefa muito
simples. s vezes parece fcil, mas geralmente as pessoas
esto habituadas ou acomodadas e ficam praticamente
cegas para os desperdcios existentes. O mesmo ocorre com a
questo do aprendizado. Quando se fala em uma organizao
que aprende, no se fala apenas em enviar os colaboradores
para treinamentos ou contratar consultores externos. Devese criar um processo de trabalho onde o aprendizado esteja
implcito e seja reconhecido como fundamental para o prximo passo, a melhoria contnua. Vamos observar tambm
que simplesmente aprender sobre o que precisa ser melhorado no suficiente. preciso ter coragem para adaptar e
Integridade
Mary e Tom Poppendieck definiram dois tipos de integridade:
conceitual e percebida, como exibido na Figura 4. Integridade
conceitual aquela que s os construtores sabem que existe.
Exemplo: os engenheiros de um avio sabem se a aeronave
pode suportar certa carga de peso, pois fizeram uma srie
de clculos para isto. J a integridade percebida aquela que
os usurios podem notar por exemplo, o design do avio, o
acabamento das poltronas, etc. O mesmo ocorre em software,
e para que se tenha integridade, preciso uma comunicao
efetiva, a fim de criar um fluxo contnuo de informaes entre
os desenvolvedores, usurios e clientes (e vice-versa).
Figura 4. Definio de integridade
Respeito
Seria timo se pudssemos lidar somente com a complexidade envolvida no desenvolvimento tecnolgico e no mundo
dos negcios. Porm, temos tambm que lidar diariamente
com o organismo mais complexo que existe na Terra: o ser
humano. Respeitar as pessoas do ponto de vista do Lean no
significa apenas aplicarmos o bom senso e a boa educao que
aprendemos em casa. A forma como uma equipe se organiza
para efetuar o trabalho pode influenciar profundamente no

respeito s pessoas. Coisas simples como dar visibilidade do
seu trabalho, prover e aceitar feedback, errar o quanto antes e
deixar todo mundo saber podem ser sim exemplos de respeito. Prover respeito uma ao to complexa que muitas vezes
magoamos as pessoas profundamente sem mesmo perceber.
Um ambiente Lean efetivo d espao para que possamos
aprender abertamente sobre este tipo de problema e assim
resolv-los de uma forma adequada.
Temos duas grandes razes para entregar rpido: para que

o nosso cliente no mude de ideia enquanto estamos construindo e para que nosso concorrente no entregue antes. Em
geral, as mudanas no mercado e a velocidade com que nosso
concorrente consegue entregar iro determinar o quo rpido
precisamos ser na hora da entrega. Alm disto, entregar rpido
e de forma incremental nos permite feedback e aprendizado
sobre o que estamos fazendo. As experimentaes de nosso
produto no mercado, ainda que inacabado, proporcionaro um
desenvolvimento muito mais assertivo.
ordem de compra at o momento em que coletamos o dinheiro.

Estamos reduzindo esta linha do tempo removendo tudo o que
no gera valor para o cliente, o desperdcio..
importante observar que ele citou linha do tempo. H
uma definio mais concisa em ingls para esta linha do
tempo: leadtime, o tempo decorrido entre o momento que
uma necessidade surge at o momento em que esta demanda
atendida. H uma ferramenta muito interessante no Lean
chamada Value Stream Mapping, ou mapeamento da cadeia de
valor. O objetivo desta ferramenta, como o prprio nome diz,
mapear tudo o que ocorre entre o surgimento e o completo
atendimento de uma requisio. Este mapeamento nos permite registrar o que tempo gasto com tarefas que adicionam
valor ao processo e o que desperdcio. Ao final, dividimos
o tempo de valor agregado pelo tempo total do processo e
teremos nosso coeficiente de eficincia operacional. Quando
aplicam esta ferramenta, normalmente as empresas se espantam em ver que seu coeficiente operacional gira em torno de
5 a 10%. Ou seja, apenas 5 a 10% do tempo total utilizado em
um processo tem efetivamente valor para o negcio. Todo o
resto desperdcio.
Ver o todo
Tipos de Desperdcio
Refletindo um pouco sobre o ltimo princpio enfatizado

pelos Poppendieck, pergunta-se: quantos em sua organizao
conhecem o que valor para o cliente? Quantos conhecem o
impacto de suas decises no negcio do cliente? Se as pessoas
em sua organizao no compreendem as respostas a estas
questes, elas devem estar trabalhando simplesmente porque
algum disse a elas o que devem fazer. Isto caracteriza um
sistema empurrado de trabalho e certamente os resultados
ficam muito aqum dos que seriam possveis em uma organizao Lean de sistema puxado. Por isto, no conceito da
Pirmide Lean, as pessoas precisam enxergar e compreender
o todo. Mais do que isto, precisam contribuir para melhoria da
organizao como um todo. Este princpio aplica-se tambm
na parte tcnica. Se voc tem especialistas em certas partes do
cdigo e s eles conseguem mexer l, certamente as demais
pessoas da equipe no esto vendo o todo. Mais adiante neste
artigo vamos abordar como resolver este tipo de problema.
Quando comeamos a identificar desperdcio, criamos tambm uma oportunidade para melhoria no processo. Ainda para
entender um pouco mais sobre desperdcio, vamos ver os trs
tipos definidos pelo Lean.
Entregar rpido
Entendendo Valor e Desperdcio

Se o princpio mais importante do Lean gerar um fluxo
contnuo de valor, precisamos aprender a identificar o que
desperdcio. A mente humana no foi treinada para identificar
aspectos negativos com facilidade. H uma tendncia natural
do homem a olhar para aquilo que gosta e identificar mais
claramente as coisas boas do que as ruins. Por este motivo,
precisamos exercitar a percepo sobre o que desperdcio.
Aqui temos uma boa definio do que desperdcio segundo
a perspectiva Lean: Desperdcio tudo aquilo que esgota recursos
de tempo, dinheiro e espao sem adicionar valor ao cliente.
Taichi Ohno, um dos grandes criadores do Lean, tem uma
citao famosa: Tudo o que estamos fazendo olhar para a
linha do tempo, desde o momento em que recebemos uma
10
Muda
Todo o tipo de atividade que no gera valor para o negcio.
Aplicando a ferramenta de mapeamento da cadeia de valor, podemos identificar como desperdcio alguns itens: filas, espera,
processos ineficazes que geram retrabalho e outras coisas mais.
Um outro exerccio que podemos fazer para identificar o muda
listar 15 atividades comuns que executamos diariamente,
incluindo ler e-mail, almoar, conversar, fumar (quando for
o caso), codificar, desenhar, documentar, testar, etc. Depois
classificamos estes itens, dando um peso de 1 a 5, sendo 5 o
que gera mais valor para o cliente e 1 o que menos gera. Aps
isto, basta contar quantas atividades tm o valor 4 ou 5 e voc
ver o grande nmero de coisas que faz diariamente que no
geram valor direto.
Muri
Sobrecarga de processo. comum empresas imporem perodos de rush, onde as pessoas precisam trabalhar longas
jornadas de trabalho, s vezes 12 ou 14 horas por dia, durante
dias seguidos. Ou seja, buscam ocupar seus funcionrios em
at 150% de sua capacidade. Porm, o que acontece se carregarmos um avio com 110% de sua capacidade? Possivelmente
teremos um acidente areo. Se subirmos isto para 130% ou
150%, certamente teremos uma tragdia. O mesmo ocorre com
o ser humano e com os processos que utilizamos para desenvolver software. Se estivermos funcionando a 100% de nossa
capacidade, certamente no teremos espao para absorver
M etod ologias geis
qualquer demanda inesperada. Ainda assim, grande parte

das empresas busca sacrificar seus recursos impondo uma
demanda muito grande. A teoria das filas nos mostra que, se
tivermos uma ocupao de cerca de 80% de nossa capacidade
produtiva, seremos mais produtivos e teremos espao para
absorver coisas inesperadas, oriundas de falhas no processo
ou mesmo de demandas externas.
Mura
Irregularidades. Todo o tipo de defeito existente considerado Mura. Mura tudo aquilo que no desejado, uma
inconsistncia ou, no jargo mais comum, um bug. O Mura
tambm pode ser oriundo do muri ou do muda. comum
observarmos a forma como as pessoas tratam o mura e vermos
que geralmente no h uma correo de fato, mas apenas uma
soluo paliativa para o problema. Vamos pegar como exemplo
um bug em um sistema, que foi identificado em uma fase de
homologao ou em produo. O bug relatado aos desenvolvedores que geralmente vo depurar o cdigo at encontrar o
problema. Consertam-no, compilam e devolvem outra verso
do binrio para a produo. Neste caso, grande a probabilidade deste defeito voltar ou de algum efeito colateral ser gerado
a partir desta correo sem considerar o tempo desperdiado
tentando achar o problema atravs de debug.
Equipes um pouco mais preparadas utilizam testes automatizados e vo reduzir o tempo com debug. Primeiro, iro criar um
teste automatizado que reproduz o problema e posteriormente
vo direto ao ponto para corrigir o bug. Como utilizam testes
automatizados, esta equipe saber imediatamente dos efeitos
colaterais causados com a alterao no cdigo e ter maior
segurana em devolver uma verso corrigida para a produo.
Esta equipe ainda ter o benefcio de no ter regresso, ou seja,
o problema dificilmente ir aparecer novamente, pois est bem
cercado pelos testes automatizados que podero ser facilmente
reproduzidos a qualquer momento. Aos olhos da maioria das
pessoas este procedimento parece bom. De fato , mas ainda
falta algo para que seja considerado excelente.
O pensamento Lean orienta reflexo sobre a causa raiz cada
vez que encontramos um problema. Em outras palavras, qual
foi a falha em nosso processo de desenvolvimento que permitiu que este erro passasse para a produo? Por que nossos
mtodos de testes no detectaram este erro antes? Trabalhar
na causa raiz do problema ser sempre o meio mais eficaz de
preveno. E a preveno, quando efetiva, ser sempre mais
barata do que a cura.
Tipos de desperdcio em software

O Lean foi originalmente concebido para gerenciar a linha
de produo da Toyota. Na manufatura, o maior desperdcio
existente o estoque. Estoque alto significa dinheiro parado,
matria prima ou produto que pode perecer e ser perdido.
Na rea de software temos os seguintes tipos de desperdcios
mais comuns:
Estoque Documentao no codificada, cdigo no sincronizado no ambiente de controle de verses, no testado
automaticamente, no documentado e que nunca foi para

produo;
Funcionalidades extras - Um estudo do Standish Group mostra que 20% das funcionalidades de um software so sempre
ou frequentemente utilizadas. Outros 35% so usadas algumas
vezes ou raramente e 45% das funcionalidades de um sistema
tpico nunca so utilizadas. Aplicando-se a Lei de Pareto temos
20% das funcionalidades de um software respondendo por
80% do valor gerado pelo mesmo;
Processos extras normalmente procedimentos que precisam ser executados somente para adequao a uma regra
ou norma;
Espera Todo tipo de espera entre uma atividade e outra;
Defeitos;
Complexidade.
No incio deste artigo observamos a complexidade que
pode ser gerada quando o conhecimento baixo sobre a tecnologia e os negcios. Agora podemos observar na Figura 5
que o custo do desenvolvimento de software sobe muito
ao longo do tempo quando no temos uma base de cdigo
limpa e simples.
Figura 5. Grfico do custo da complexidade
Princpios do Lean
Vamos explorar um pouco mais a fundo os princpios que
deram origem ao Lean e que permeiam todo o conceito da
Pirmide Lean.
Jidoka
Tambm conhecido como Autonomation ou Inteligent Automation,
a automao com um toque humano. Este foi um dos primeiros
conceitos criados por Sakichi Toyoda, fundador do Grupo Toyota. Ainda no sculo XIX, Sakichi observava sua me trabalhar
em teares manuais feitos de madeira e procurava maneiras de
facilitar o trabalho de tecelagem. Em 1890, Sakichi inventou um
tear de madeira manual que possibilitou um aumento de 50%
na produtividade, fazendo com que sua me utilizasse somente
uma das mos para fazer o trabalho que antes precisava das duas.
Seguindo esta ideia de automao, ele aprimorou seu invento e em
11
1906 criou o primeiro tear mecnico automatizado. Implementando o conceito de melhoria contnua, em 1924, Sakichi e seu filho
Kiichiro chegaram ao Modelo G, um tear automatizado de alta
velocidade que detectava quando um fio arrebentava e parava
automaticamente a mquina para que no produzisse tecidos
defeituosos. Suas inovaes para parada automtica e preveno
de desperdcios foram extraordinrias.
Com o invento, Sakichi eliminou a necessidade de ter um
operador monitorando as mquinas de tear continuamente.
Agora, um nico operador poderia monitorar at 30 mquinas,
possibilitando uma diminuio expressiva no custo, bem como
um aumento da qualidade e produtividade das mquinas de tear
da poca. Assim, com a automao, Sakichi criou um meio para
que as mquinas parassem automaticamente quando qualquer
problema ocorresse e, desta forma, nunca produzissem defeitos.
Sobretudo, o Jidoka eliminou a necessidade de monitoramento
humano contnuo e deu origem a uma cultura que uma das
bases do Lean, a Stop the Line.
Cultura Stop the Line

Na Toyota, qualquer operador de uma linha de produo tem
o dever de parar a linha ao sinal de qualquer problema. Estamos
falando de uma linha de produo de fluxo contnuo, integrada
aos fornecedores e que geralmente contabiliza cerca de duas mil
pessoas trabalhando. Nesses casos, todas as pessoas que trabalham param suas atividades e um pequeno grupo, normalmente
liderado pela pessoa que parou a linha, ir investigar o problema e
determinar sua causa raiz. A linha s tornar a ser ligada quando
a causa raiz do problema for solucionada. A produo nas fbricas
da Toyota para diversas vezes ao dia e assim, a empresa consegue
produzir carros de altssima qualidade e diminuir drasticamente
seus custos de correo de defeitos.
no local necessrio e quando necessrio. Em uma linha de

produo, o fluxo just in time permite diminuir estoques e
aumentar o giro de produtos. Associado a uma tcnica de
produo conhecida por sistema puxado, o just in time possibilita tambm minimizar as perdas com produo excessiva e
consequentemente aumentar a produtividade da linha de produo. O just-in-time tambm pode ser aplicado em software
de diversas maneiras, que vamos explorar mais adiante.
Sistema Puxado
Um sistema puxado de produo determina a carga de
trabalho de acordo com o consumo do cliente. Se no houver
consumo no haver produo, eliminando completamente o
desperdcio com a produo excessiva. Diferentemente de um
sistema empurrado, onde h produo independentemente da
demanda, o sistema puxado gerencia toda a cadeia produtiva
desde a extrao da matria prima at a transformao em
um produto acabado. Para auxiliar neste processo, Taichi Ohno
concebeu uma ferramenta chamada Kanban, que permite um
gerenciamento visual e colaborativo da produo puxada. O
Kanban tornou-se tambm uma ferramenta muito importante
para gerenciar o desenvolvimento de sistemas complexos.
Veremos mais adiante como aplic-lo a software.
Heijunka
O Heijunka uma tcnica de anlise da produo que auxilia no nivelamento da produo e consequente eliminao
do Muda, permitindo criar cadncia na demanda e nivelar a
produo para potencializar a vazo do sistema e o fluxo de
entrega de valor. Para aplicar o Heijunka, necessrio entender
o funcionamento do Kanban para identificar como so distribudas as cargas em um processo de desenvolvimento.
Poka-Yoke
Pessoas
Mecanismos a prova de erros. As linhas automatizadas de produo na Toyota so dotadas de mecanismos de deteco de falhas
que no permitem a insero de erros no processo. Nas mquinas
de solda, por exemplo, um mecanismo verifica se a mquina est
apta a fazer a soldagem se tudo estiver certo, a solda ser realizada. Aps o processo, outro mecanismo faz uma verificao para
ver se tudo ocorreu bem. Caso algum dos testes falhe, a linha de
produo para automaticamente. Para os procedimentos manuais,
existe uma srie de checklists que permitem validar cada etapa do
trabalho dos funcionrios. Novamente, quando uma etapa falha, a
linha de produo parada e o problema solucionado a partir de
sua causa raiz. Juntando a automao inteligente do Jidoka com os
mecanismos a prova de erros Poka-Yoke, e com uma cultura Stop
the Line, temos um processo produtivo maduro, padronizado e
de alta qualidade. Quando desenvolvemos software, precisamos
tambm ter estas caractersticas inseridas no processo vamos
discutir mais a frente como fazer isto.
Uma vez que temos definidos claramente quais so os

princpios e valores que norteiam a cultura de uma organizao, estamos prontos para definir a estratgia de negcio
e estabelecer a viso pela qual a empresa desenvolver seus
produtos. Esta viso precisa ser claramente conhecida por
todos os membros da organizao, de modo que cada um em
seu trabalho possa direcionar suas atividades para maximizar o valor gerado pela empresa. Desta forma, os objetivos
desta viso precisam ser definidos e comunicados em termos
quantitativos e qualitativos, considerando-se os aspectos de
performance, custo e qualidade.
Antes de entrarmos em detalhes sobre como definir e comunicar a viso, precisamos abordar um pouco o fator humano.
Como observamos no manifesto gil, importante termos
sempre os melhores processos e ferramentas disposio
para que uma equipe possa desenvolver de forma adequada
as atividades. Porm, ainda mais importante maximizar a interao e colaborao entre os indivduos. Tanto no Lean como
no desenvolvimento gil de software busca-se o fortalecimento
das pessoas atravs da criao de equipes multidisciplinares
e auto-responsveis, de maneira que uma nica equipe seja
Just in Time
Ter um processo just in time significa reduzir desperdcio
fazendo somente o que necessrio, na quantidade necessria,
12
M etod ologias geis
formada de modo completo, compreendendo todos os conhecimentos e habilidades necessrias para transformar a viso em
produtos que gerem valor efetivo para a organizao. Equipes
geis possuem a autonomia necessria para definir o que
valor de negcio e tambm para determinar qual a tecnologia
ser necessria para entregar tal valor. A Figura 6 demonstra
como uma equipe gil pode ser formada.
Figura 7. Efetividade da comunicao
Figura 6. Equipe gil
De fato, todo processo de desenvolvimento gil adaptativo

e o modelo de equipe adequado dever ser definido de acordo
com o projeto em questo.
Aqui vamos explorar e estabelecer como base a diferena
entre os modelos propostos pelo Lean e pelo Scrum.
Na Figura 6 h o modelo proposto pelo Lean, que de certa
forma bastante similar ao proposto pelo Scrum, todavia com
algumas importantes diferenas. A primeira delas est no
papel do Product Champion ou engenheiro chefe do produto.
Como o prprio nome j diz, o Engenheiro Chefe o responsvel final pela arquitetura e pelas principais decises tcnicas
do produto. Contudo, o Product Champion proposto pelo Lean
tambm responsvel por todas as decises de marketing.
Sendo assim, ele responsvel por definir todo o processo de
venda, suporte, precificao e a logstica de entrega.
Como podemos observar, o Product Champion o lder
mximo, que conhece as necessidades mercadolgicas e detm o conhecimento tecnolgico necessrio para liderar todo
o processo de desenvolvimento e, consequentemente, guiar
toda a equipe no cumprimento de seus objetivos. Na Toyota,
por exemplo, o Engenheiro Chefe algum que tem muitos
anos de prtica, em geral de 15 a 20 anos de experincia com
a cultura da organizao. Ademais, ele tambm procura viver
as experincias dos clientes. Em alguns casos, o Engenheiro
Chefe realmente se muda para viver com uma famlia que
tem o perfil de seu cliente alvo, para vivenciar na prtica seus
hbitos e costumes. S assim ele ter subsdios suficientes para
desenvolver produtos de sucesso.
Uma equipe Lean multidisciplinar completa ser formada
por subequipes que contemplam expertise em negcios, marketing, vendas, engenharia, arquitetura, design e produo. A
comunicao entre estes experts deve sempre ser a mais direta
e eficaz possvel. Logo, a Figura 7 demonstra a efetividade da
comunicao.
O principal objetivo do trabalho conjunto e integrado de uma

equipe Lean identificar com assertividade as necessidades
de negcio e promover a entrega incremental de valor efetivo.
fundamental uma equipe saber identificar o que valor e
qual a poro mnima de software necessria para entregar
tal valor. Por isso, cita-se propositadamente o termo entrega de
valor, em vez de entrega de software.
Podemos observar ainda a presena de um outro papel de
liderana, a do lder de competncias. Ele garante que a criao
de competncias esteja inserida implicitamente no processo
de desenvolvimento. No precisamos necessariamente parar
a equipe para receber um treinamento, mas fundamental
garantir que o aprendizado ocorra durante o desenvolvimento.
Logo vamos abordar como as tcnicas de engenharia que esto
na base da pirmide e o desenvolvimento iterativo permitem
a aquisio on-the-fly de conhecimento.
Com relao ao Scrum, a principal diferena na formao
da equipe que o Product Owner no possui conhecimento
tcnico suficiente para influenciar profundamente nas decises
tcnicas, bem como a equipe no conhece o negcio a ponto de
envolver-se nas decises. Em geral, as decises so tomadas
de forma conjunta, compartilhando-se conhecimento sobre
negcio e tecnologia. No podemos dizer que o modelo de
equipe do Lean melhor do que o do Scrum e vice e versa.
Ambos tm prs e contras e sero mais apropriados de acordo
com cada tipo de projeto.
Quebrando a Viso
Uma vez que a organizao tenha definido adequadamente
sua viso e estratgia de negcios partimos para a implementao, aplicando os princpios e valores do Lean e do
desenvolvimento gil nas demais camadas da organizao.
Dependendo do nvel de maturidade da empresa e das caractersticas dos projetos, ela poder optar por usar Scrum
ou Kanban para criar um processo de entrega de valor. Antes
disso, precisamos quebrar a viso em objetivos menores que
sejam especficos e mensurveis. Tanto no Scrum quanto no
Kanban vamos utilizar uma ferramenta para isto as estrias do usurio. Sendo assim, vamos entender melhor como
utilizar esta ferramenta antes de entrar em detalhes sobre
Scrum e Kanban.
13
Estrias
Uma estria, ou User Story, uma frase simples que descreve uma necessidade ou requisito de sistema. Estrias so
utilizadas no desenvolvimento gil para especificao de
requisitos, em conjunto com critrios de aceite devidamente
elaborados. Estrias so uma forma rpida e eficaz de coletar
e manter requisitos sem a necessidade de uma formalizao
burocrtica, adicionando agilidade no processo e facilitando
o planejamento.
Uma estria pode ser considerada a funcionalidade em si
dentro do ciclo de desenvolvimento de software. A estria, em
geral, uma requisio do Product Owner que, passada para
o time de desenvolvimento, se transformar em uma poro
do software funcionando. Detalhes sobre a estria emergem
durante as discusses nas sesses de planejamento. Entretanto,
algumas informaes adicionais podem acompanh-la desde
sua concepo, tais como: motivao do Product Owner para
requisit-la, critrios que iro reger sua aceitao e descries
tcnicas mais detalhadas, quando necessrio.
O time de desenvolvimento colabora com o ciclo de vida das
estrias na medida em que as transforma para que possam ser
classificadas como SMART:
Especfico: refere-se a uma interveno pontual no software
e no ao desenvolvimento de um artefato muito grande ou
complexo;
Mensurvel: deve ser possvel mensurar o custo de desenvolvimento e o valor gerado, alm de prever sua situao futura
aps o desenvolvimento da estria;
Alcanvel: na medida em que seu custo pode ser mensurado,
uma estria deve ser um objetivo possvel de ser alcanado,
cujo comprometimento com a entrega por parte da equipe
seja efetivo;
Realista: A tecnologia escolhida deve contemplar de forma
realista fatores como custo, tempo disponvel e capacidade
tcnica da equipe;
Time-boxed (tempo fixo para o desenvolvimento): uma estria
deve ser planejada para ser entregue por inteira dentro de um
ciclo de desenvolvimento. Porm, em um eventual atraso, ela no
deve ser motivo para atrasar ou adiantar a entrega do ciclo.
Figura 8. Backlog
14
Vale lembrar que estrias no so especificaes completas do

que deve ser feito. Na verdade, so apenas links de comunicao
entre a equipe e o Product Owner a respeito de um determinado assunto. Estrias so geralmente escritas em cartes (postits) e fixadas na parede (quadro de estrias), onde compem
uma lista chamada Product Backlog Figura 8. O Product
Backlog uma lista de estrias em constante priorizao que
representa o escopo do produto. Esta lista mutante, j que no
desenvolvimento gil as mudanas de escopo so bem vindas
a qualquer momento durante o desenvolvimento.
Estimativas e velocidade de desenvolvimento

Estrias contm estimativas e a responsabilidade por estimlas nica e exclusiva do time de desenvolvimento. Delegar
esta responsabilidade ao time uma forma efetiva de garantir
o comprometimento, j que nenhuma meta imposta, mas sim
proposta pelos prprios engenheiros de software.
A experincia do desenvolvimento gil de software mostra a
ineficcia do uso de uma medida de tempo (horas ou dias) para
estimar o custo de uma estria. As estimativas so feitas em
story points (sp), medida exclusiva de esforo, que demonstra o
tamanho de uma estria comparada a outras. A tarefa de estimar
em story points livre da preocupao sobre o tempo de durao
do projeto. Story points liberam o time de desenvolvimento da
presso por datas, possibilitando o foco na complexidade da
estria. Para acomodar as incertezas de estrias de grande porte,
costuma-se utilizar a escala Fibonacci para atribuio dos pontos,
j que ela inicia com uma granularidade menor nos primeiros
valores, partindo para apenas uma ordem de grandeza em
escalas maiores: 1, 2, 3, 5, 8, 13, 21... A escala Fibonacci permite
acomodar a incerteza do processo de desenvolvimento nos
intervalos entre um nmero e outro na escala.
A previsibilidade com a completude das estrias em datas
especficas vem da unio das estimativas com o conceito de
velocidade. A velocidade do time de desenvolvimento descoberta com a informao histrica sobre quantos story points
foram completados nas ltimas iteraes de desenvolvimento.
A representao de velocidade pode ser por iterao ou mesmo
por dia: 20sp por iterao ou 2sp/dia, por exemplo. Desta forma,
quando o time inicia uma nova jornada com 10 dias de desenvolvimento, pode se comprometer com a entrega de software
funcionando com um grupo de estrias que somam aproximadamente a sua velocidade mdia nas ltimas iteraes.
Outro aspecto interessante que a produtividade de uma
equipe aumenta medida que vai agregando mais conhecimento sobre a tecnologia e o negcio em questo. Consequentemente, as estimativas tornam-se tambm mais assertivas ao
longo do tempo. Em geral, uma equipe inicia com cerca de 30%
de sua velocidade nominal e aps trs ou quatro iteraes a
velocidade estabiliza em sua capacidade mxima. Entradas
ou sadas de integrantes da equipe podem tambm afetar a
velocidade, mesmo depois do grupo ter atingido uma estabilizao da velocidade.
Vale salientar que o custo de uma estria varia de equipe
para equipe e de poca de desenvolvimento para poca de
M etod ologias geis
desenvolvimento. correto utilizar velocidade e nmero de

estrias para comparar iteraes consecutivas para uma mesma
equipe. Entretanto, a comparao de iteraes muito distantes
ou de diferentes equipes carece de uma anlise mais subjetiva.
Alm disso, a velocidade descoberta uma mdia das ltimas
iteraes, sendo normal na iterao atual um resultado com
desvio para mais ou para menos. No caso de variao positiva
da velocidade, mais estrias podem ser inseridas na iterao.
Quando a velocidade varia negativamente, as estrias de menor
prioridade so cortadas da iterao.
Priorizao
Estrias de desenvolvimento normalmente so criadas pelo
Product Owner, mas outras pessoas podem exercer esta funo.
Estrias de manuteno corretiva podem ser criadas por uma
equipe de suporte. Estrias de refactoring criadas pelo time
de desenvolvimento e estrias de novas funcionalidades, em
geral, podem ser criadas por uma equipe de marketing ou
at pelo usurio final. Independente da fonte, a estria ser
obrigatoriamente priorizada pelo Product Owner.
Um Product Owner focado em maximizar o retorno do seu
investimento certamente realizar um bom trabalho de priorizao. Uma priorizao adequada pode levar o desenvolvimento a alcanar um nvel de produtividade representado pela
Lei de Pareto. A Lei de Pareto diz que, com 20% do esforo de
desenvolvimento, pode-se gerar 80% do valor no software. O
mesmo poder ser observado durante a manuteno corretiva
do software, quando 80% dos problemas podem ser resolvidos
atacando 20% das causas. A Figura 9 demonstra essa razo de
esforo e resultado da Lei de Pareto.
aprofundada, reunindo especialistas das reas de finanas,

marketing, vendas e desenvolvimento, necessria.
A tcnica MoSCoW uma das mais utilizadas. Atravs dela
e a partir da experincia do Product Owner, possvel determinar quais estrias precisam (must), deveriam (should) e
poderiam (could) estar com prioridade mais alta, bem como
quais estrias no iro de fato ser priorizadas (wont). Este
ltimo um fator de priorizao muito importante, conhecido
tambm como not list, geralmente esquecido ou no utilizado
por equipes menos experientes.
A Anlise de Kano um modelo de desenvolvimento de
produtos criado nos anos 80 pelo professor Noriaki Kano,
que classifica as preferncias dos consumidores em cinco
categorias (Figura 10).
Figura 10. Anlise de Kano
Planejamento e Controle da Produo

Uma vez tendo conhecimento sobre o que preciso ser
desenvolvido e sua adequada priorizao, preciso tambm
compreender como planejar e controlar a entrega dos artefatos.
isso que iremos explorar neste tpico.
Figura 9. Lei de Pareto
Diversas tcnicas de priorizao podem ser utilizadas, e dentre elas podemos citar o clculo do Retorno do Investimento
(ROI), onde se mensura o custo do desenvolvimento e o valor
gerado, a tcnica MoSCoW (Must, Should, Could, Wont) e a
anlise de Kano.
O clculo do ROI realizado elencando-se diversos fatores,
como custo do desenvolvimento, custo da estrutura fsica de
desenvolvimento e produo, e aspectos como capacidade de
aumento nas vendas, conquista de novos clientes ou mesmo
a reteno de atuais clientes. Para tanto, uma anlise mais
Ciclos: releases, iteraes e entrega contnua

Uma das principais caractersticas da complexa tarefa de
criar produtos de software que funcionem corretamente e
atendam as expectativas do cliente a imprevisibilidade, o
que dificulta muito o processo de planejamento e controle.
Para reduzir esta imprevisibilidade, processos tradicionais
de desenvolvimento confiam em planejamentos intensivos
para longos perodos, tentando identificar e mitigar todos os
riscos possveis logo de incio. Ao longo dos anos descobriuse que esta estratgia no funciona devido prpria natureza
incerta do desenvolvimento de software e dos negcios onde
normalmente so aplicados.
15
Atravs deste aprendizado, o Lean e as metodologias geis

propem ciclos curtos de planejamento e entrega, nos quais
uma parte do produto final projetada, desenvolvida e testada dentro de um perodo curto, chamado iterao ou Sprints
no Scrum Figura 11. Observem que no estamos falando
de prottipos, e sim de uma parte do produto final que pode
ser utilizada em produo e ser continuamente melhorada e
incrementada, iterao aps iterao, respondendo s mudanas impostas pelo mercado e pela tecnologia, at que atinja o
escopo necessrio.
Figura 11. Esqueleto Scrum
Ciclos curtos de desenvolvimento proporcionam maior

feedback e aprendizado para todos os envolvidos no processo
de desenvolvimento. Esta uma das formas de capacitao
implcita nos processos de desenvolvimento que citamos anteriormente, essencial para um ambiente Lean maduro. Com
mais conhecimento, as equipes passam a diminuir a incerteza
e trabalham ancoradas em um processo confivel de entregas
de produto de alta qualidade e valor agregado.
Com maior confiabilidade e previsibilidade possvel fazer
um planejamento de releases para o projeto, considerando as
regras adequadas de priorizao e a velocidade da equipe de
desenvolvimento. Desta forma, os releases so entregas maiores
que contemplam o que foi desenvolvido durante algumas iteraes e, associado a um objetivo bem definido, o planejamento
passa a ser uma forma valiosa de satisfazer as necessidades
de mercado do cliente.
Como so priorizadas as funcionalidades que geram maior
valor e tm maior risco para o projeto, os ciclos curtos propiciam um produto de alto valor agregado, diminuindo os riscos
e o time-to-market. Consequentemente, a vantagem competitiva
do cliente torna-se indiscutvel.
Entrega contnua com Kanban

Quando a equipe atinge um alto nvel de maturidade, os
ciclos de desenvolvimento tornam-se cada vez mais curtos e
eventualmente a parada para planejamento das iteraes pode
se tornar um desperdcio. O Kanban pode ser utilizado para
amadurecer o workflow e aumentar a eficincia do sistema,
promovendo a entrega contnua de software e o aumento da
produtividade da equipe.
16
De forma simplificada, o Kanban um processo de produo

puxado que mapeia as etapas de desenvolvimento. Para cada
etapa identificada, ele estabelece limites para a quantidade de
trabalho sendo realizada simultaneamente. Os limites superiores
auxiliam a minimizar a multitarefa, neste caso nociva produtividade da equipe. Limites inferiores vo auxiliar a garantir que
sempre haja demanda suficiente para que o trabalho no pare.
Ambos os limites ajudam a criar cadncia no processo,
nivelando a produo e potencializando ao mximo a entrega e, consequentemente, vazo de valor. O nivelamento
da produo (Heijunka) necessrio para evitar os perodos
em que ocorre demanda excessiva, causando a sobrecarga de
processo (Muri) ou pouca demanda, causando ociosidade no
processo (Muda).
Quando o limite de uma das etapas do Kanban atingido,
parte da equipe que est atuando em outras etapas faz uma
pausa em suas atividades e auxilia a remover o gargalo. como
uma turma de jipeiros numa trilha. Se um jipe atola, todos
os demais descem do jipe para ajudar a desatolar o carro que
atolou. Dentre outros benefcios, o Kanban auxilia na gesto
visual do fluxo de trabalho, melhorando a comunicao e os
processos de priorizao. O Kanban tambm permite um foco
grande na qualidade, atravs de seus critrios Definition of
ready e Definition of done para cada uma das etapas.
Visibilidade e Rastreabilidade
Processos geis proporcionam total visibilidade, controle
e rastreabilidade de tudo o que ocorre durante o ciclo de
desenvolvimento. De fato, os mtodos geis propiciam uma
oportunidade diria para anlise de riscos e tomada de deciso
de modo a corrigir o mnimo desvio indevido de curso. Todas
as ocorrncias so disponibilizadas atravs das ferramentas
de gesto como dashboard e burndown charts para todos os
membros do projeto. Alm disso, a comunicao direta entre
equipes gera maior colaborao, visibilidade e controle do
projeto. O prprio processo de ciclos curtos proporciona maior
aprendizado e feedback concreto sobre o exato andamento do
projeto, gerando maior segurana e consequente aumento de
auto-estima para todos os envolvidos.
Com base nas ferramentas e tcnicas de metodologias
geis, visibilidade e controle so potencializados da seguinte
forma:
Dashboard painel que contm as estrias e tarefas priorizadas no backlog e que demonstra a evoluo no ciclo de vida
do desenvolvimento;
Grfico de evoluo burndown charts proporcionam visibilidade sobre a velocidade de produo da equipe e se esta
velocidade adequada para os objetivos;
Aceites o cliente aceita ou rejeita as estrias entregues ao
final de cada ciclo de desenvolvimento. Tudo documentado,
incluindo o planejamento, o que foi realizado e eventuais
diferenas;
Software funcionando sempre ao final de cada iterao o
cliente recebe um software pronto para uso, proporcionando
feedback e retroalimentao da viso do produto;
M etod ologias geis
Documentao embarcada todo cdigo entregue com

documentao embarcada (javadoc), possibilitando o aumento
do conhecimento;
Software Intelligence todas as tcnicas de automatizao,
coleta de mtricas e testes utilizadas pela equipe proporcionam muita segurana e a certeza de se estar desenvolvendo
o produto correto.
A Figura 12 demonstra as camadas de um software e a

abrangncia dos testes.
A base da pirmide Lean

A base da pirmide larga para poder sustentar o resto da
estrutura. Por este motivo, colocamos na base as prticas de
Engenharia de Software que permitem uma efetiva e segura
adoo de mtodos geis. A utilizao de Scrum ou Kanban
para gesto dos projetos deixa mais fcil a tarefa de responder s
mudanas e adequar o planejamento. Entretanto, se no houver
uma base de cdigo sustentvel, essa resposta despreparada s
mudanas pode significar um problema muito grande. Por este
motivo importante implementar na Engenharia de Software
os princpios e valores do Lean e do Manifesto gil.
Testes Automatizados
Testes automatizados so certamente uma das mais fundamentais tcnicas de desenvolvimento de software, que permite
uma adio severa de qualidade ao cdigo. O grande objetivo
criar esta qualidade durante a construo do cdigo, ao invs
de test-lo mais tarde. Em geral, equipes que no investem na
criao de testes automatizados necessitam de um longo perodo de testes ao final de cada ciclo de desenvolvimento. Esse
investimento tardio na qualidade compromete o conhecimento
da real situao do software durante o desenvolvimento, o que
gera atrasos, falta de visibilidade, gerenciabilidade e assertividade do produto final.
O investimento em testes automatizados oferece a oportunidade de obter feedback dos testes mesmo durante o desenvolvimento do software. A grande vantagem desta abordagem
o fato de se poder testar todo o sistema facilmente, a partir
de apenas um boto na IDE. A reprodutibilidade dos testes
encoraja sua execuo, minimizando a necessidade e o custo
de manuteno corretiva. A aplicao de testes automatizados
tambm a criao de um ambiente que permita o aprendizado de forma implcita, conforme mencionado no incio deste
artigo.
Os testes automatizados so blocos de cdigo, chamados
cdigos de testes, que exercitam o cdigo de produo. Os
testes confeccionados variam na sua abrangncia e no foco.
Quanto abrangncia, podem ser:
Testes unitrios: testam cada menor trecho de cdigo do
sistema;
Testes integrados: testam classes ou mdulos do sistema de
forma integrada;
Testes funcionais: testam funes especficas do sistema de
ponta a ponta, abrangendo todo o fluxo da informao;
Testes de aceitao: testes inspirados na condio de aceitao do cliente ou usurio. Geralmente s
o aplicados diretamente na interface do sistema.
Figura 12. Exemplo de Arquitetura de Testes Automatizados
Quanto ao foco dos testes:

Corretude do funcionamento: so os testes mais comuns,
utilizados para certificar a aderncia do sistema aos requisitos
funcionais;
Performance e consumo de memria: testes que certificam
o desempenho do sistema de acordo com requisitos nofuncionais;
Usabilidade: estes testes normalmente no so automatizados. Envolvem especialistas em usabilidade e podem contar
com a participao do prprio usurio.
Desenvolvedores utilizam testes automatizados na criao
da tecnologia, auxiliando-os na escrita de cdigo limpo e
habilitando o refactoring para melhoria contnua. Especialistas de negcio podem usufruir de testes automatizados
para certificarem-se de que seu modelo de negcio segue
efetivo e aceito, mesmo durante a contnua evoluo da base
de cdigo.
Automatizao do Ambiente
A Engenharia de Software requer que processos repetitivos
sejam executados inmeras vezes. Estas atividades envolvem,
por exemplo, a execuo da sute de testes, compilao do
sistema, gerao de verso de distribuio, configurao do
ambiente de execuo (como base de dados), notificao dos
responsveis em caso de erros nos testes, criao de relatrios
de aderncia aos padres enfim, a lista bem extensa.
De maneira geral, estas atividades, se desempenhadas por
pessoas, requerem uma equipe dedicada e muito disciplinada.
No entanto, a propenso a erros durante a execuo da rotina
bastante alta, o que invariavelmente configuraria desperdcios (Mura).
Para a reduo destes desperdcios recomenda-se a automatizao de tais processos. Neste tpico sero discutidas aes
que podem ser tomadas para automatizar seu ambiente.
Builds Automatizados
Existem ferramentas que podem auxiliar a automatizao dos
processos repetitivos de desenvolvimento. Tais ferramentas podem variar de acordo com a tecnologia. Alguns exemplos so:
17
Make, Ant e Maven. Para as tecnologias Java, os mais utilizados

so Ant e Maven, ambos da Apache Software Foundation.
Tratam-se de ferramentas para execuo de rotinas descritas
como instrues codificadas em arquivos de configurao
XML, comumente chamados de builds.
Devido s contribuies da comunidade de desenvolvimento,
estas ferramentas possuem vrias extenses e recursos que envolvem compilao de cdigo em vrias linguagens, execuo
de testes (incluindo, mas no se limitando ao padro xUnit),
envio de e-mail, integrao com servidores de aplicao e
manipulao de banco de dados.
A maneira de utilizao destas ferramentas depende muito
dos propsitos do projeto em que so utilizadas. Porm, de maneira geral, a compilao, empacotamento e testes do artefato
de software desenvolvido so os principais objetivos. A utilizao intensa propicia a coleta e a gerao de artefatos para gesto
da configurao que permitem a anlise do desenvolvimento,
adeso aos padres e tomada de deciso quanto qualidade
dos artefatos gerados (veja o tpico Software Intelligence para
mais informaes dos benefcios e meios).
Integrao Contnua
Dispor de builds automatizados para seu projeto um
grande passo rumo automatizao dos processos, suporte
deciso sobre investimentos em qualidade, visibilidade,
entre outros. Entretanto, para que estes benefcios sejam de
fato gerados, necessrio que estes processos automatizados
sejam executados de maneira sistemtica e autnoma. Por
exemplo, a sute de testes e a rotina para execut-los no
obtero os benefcios desejados caso no sejam executados a
cada contribuio dos desenvolvedores sobre o cdigo fonte
do software do projeto. O disparo do processo de execuo
peridica poderia ser executado pelo pessoal responsvel por
qualidade. Entretanto, assim como a execuo de processos

repetitivos, delegar esta responsabilidade comumente resulta
em falhas e consequente desperdcio.
Para tal, ferramentas de monitoramento de contribuio e
execuo automtica esto disponveis, dentre elas: Apache
Continuum, Hudson, LuntBuild e CruiseControl. Trata-se de
um servio disponibilizado na infraestrutura de desenvolvimento, geralmente em um servidor dedicado para o fim de
integrao contnua.
Os servidores de integrao contnua comumente so configurados com um ambiente web, com suporte a ferramentas
de comunicao (como e-mail e instant messenger) e link com
outros servidores como Servidor de Controle de Verses e
Servidor de Homologao. Estes recursos ampliam as capacidades dos builds automatizados, que podem publicar os
relatrios gerados no ambiente web, enviar notificaes aos
desenvolvedores e outros interessados quanto ao status dos
testes, entre outras possibilidades.
A Figura 13 mostra trs servidores: Servidor de Controle
de Verses (SCV), Servidor de Homologao (SH) e Servidor
de Integrao Contnua (SIC). Note que os desenvolvedores
colocam suas contribuies ao projeto no SCV. O SIC, continuamente monitora o SCV em busca de modificaes. Dada uma
modificao detectada, o SIC atualiza sua cpia do projeto
com as ltimas atualizaes detectadas, estando assim em
sincronia com o SCV, e ento executa o build automatizado
do projeto.
Este build executar todas as rotinas automatizadas e poder se valer do ambiente do SIC para fazer o deployment da nova
verso do software em um servidor para homologao (SH).
possvel tambm gerar relatrios para acompanhamento
e tomada de decises em um ambiente web disponibilizado
no prprio SIC.
Software Intelligence
Figura 13. Ambiente de Integrao Contnua
18
Software Intelligence refere-se s habilidades, tecnologias,

aplicaes e prticas utilizadas para ajudar a todos os envolvidos a entender melhor o contexto do negcio: desenvolvimento de software. Para tal, existem ferramentas livres
que possibilitam a varredura do cdigo fonte na busca por
indcios de bugs no software, cobertura de testes, mtricas
de qualidade, entre outras informaes. Estas ferramentas,
integradas ao sistema de builds automatizados, podem ser
consideradas inteligncia de software quando so combinadas com um processo que busca melhoria contnua. Na
prtica, nas reunies de retrospectiva e nas estrias de refactoring, os relatrios de inteligncia do software so fontes
importantes de suporte a deciso. A seguir, so apresentadas
algumas das ferramentas que podero ser empregadas na
presente proposta:
FindBugs. FindBugs um programa que se prope a achar
bugs em aplicaes Java por meio da anlise esttica do cdigo fonte. Este um mtodo utilizado para achar bugs em
um sistema, sem execut-lo. A possibilidade de achar erros
e vulnerabilidades sutis, antes que elas ocorram meses ou
M etod ologias geis
Concluso
Em todos os nveis da Pirmide Lean possvel encontrar
elementos trabalhando em conjunto para criao de valor
na organizao. Podemos observar que falamos sempre de
pessoas, processos e ferramentas tudo isso para a criao
da melhor tecnologia. O Lean chama este processo de Systems
Thinking, e orienta a olhar para a juno de pessoas, processos e ferramentas como um sistema, que precisa ser afinado e
regulado de modo a gerar o seu melhor potencial.
A partir do momento que certas tcnicas testes automatizados, TDD, refactoring, arquitetura emergente, simplicidade e
integrao contnua, por exemplo so aplicadas corretamente,
formamos uma base slida para que a viso da organizao
seja rapidamente implementada e entregue com a mais alta
qualidade. O correto equilbrio na definio de valores e
princpios e na aplicao das tcnicas do Lean, Scrum e Kanban, conduz a organizao para nveis de excelncia ainda
no alcanados. Esta excelncia permitir a criao de uma
cultura baseada em relacionamentos fortes e duradouros,
estimulando a criatividade e a inovao. Responsabilidade,
disciplina, senso de propriedade, capacidade de auto-gesto,
respeito e colaborao permitiro a criao de uma equipe
extremamente gil e coesa, que tenha prazer naquilo que faz e
que, principalmente, construa uma relao de confiana entre
si e para com seus clientes.
Espera-se, pois, que a viso da Pirmide Lean ajude a indstria de software a tornar-se mais produtiva, humana e
sustentvel.
Referncias
Apresentao da Pirmide Lean na web
http://prezi.com/w6pjte9n4bsq/the-lean-pyramid/
Blog da OnCast Technologies
http://onca.st/blog
Site da Agile Alliance (rico em artigos)
http://www.agilealliance.org

D
s
Site de Mary & Tom Poppendieck, criadores do Lean Software Development

http://www.poppendieck.com/
Feedback
eu
edio
ta
Vale salientar que foram apresentadas algumas das ferramentas disponveis no mercado. O emprego de cada
uma delas no processo de desenvolvimento ser analisado
confrontando o custo de manuteno do ambiente de software

intelligence, com o valor gerado pelo mesmo. Uma escolha
bem feita de um subconjunto destas ferramentas tem o potencial de formar um relatrio significativo sobre o estado
do desenvolvimento de um software.
19
sobre e
s
anos depois no sistema em produo, a principal vantagem

desse programa;
CPD. Trata-se de um Detector de Copia e Cola (Copy/Paste
Detector) para o cdigo fonte da aplicao. Sua sensibilidade
pode ser configurada e costuma apresentar algumas surpresas para seus usurios, principalmente em equipes de
desenvolvimento mdias, grandes e distribudas. O principal
benefcio do CPD reduzir a propagao de erros e o custo
de todos os tipos de manuteno em cdigos duplicados.
Ele tambm encoraja o uso de boas prticas de orientao a
objetos como DRY (Dont Repeat Yourself), pois evita a recodificao de entidades do sistema j implementadas;
PMD. O PMD um programa que analisa o cdigo fonte
na busca de uma suite de situaes: cdigos que poderiam
ser melhor implementados quanto a performance, pores
de cdigo no utilizadas, tratamento deficiente de excees
e sentenas desnecessariamente complexas;
Relatrio dos testes. Resultados da execuo da sute
automatizada de testes. Deve ser mantido sempre verde,
passando. Em caso de erro, alm da possvel notificao aos
interessados, a cor no relatrio ser vermelha e as causas
sero apresentadas em detalhes;
Doxygen. Atravs de engenharia reversa aplicada s classes
e documentao embarcada no cdigo fonte, o Doxygen
pode gerar diagramas UML com o estado real da aplicao,
manuais e documentao online;
Checkstyle. uma ferramenta que auxilia o time de desenvolvimento a se manter dentro de padres de codificao.
Assim como o CPD e o PMD, ideal para times mdios,
grandes ou distribudos;
Cobertura. Como o nome indica, esta ferramenta mensura
a cobertura dos testes automatizados no sistema. Ele gera
relatrios que podem ser confrontados no prprio cdigo
fonte, indicando as reas que foram acionadas pelos testes
automatizados;
Mensurar a complexidade ciclomtica. Apesar do nome
complicado, significa simplesmente mensurar a complexidade
de cdigos estruturados ou cclicos. Esta informao pode
reduzir custos de manuteno, gerando valor na medida em
que explicita, por exemplo, implementaes fora da arquitetura planejada;
Lobo. Lobo uma ferramenta opensource desenvolvida
pela OnCast, que estende a API de testes padro para Java,
oferecendo opes avanadas para testes de performance. Os
relatrios gerados pelo Lobo mostram a evoluo da performance do sistema ao longo do tempo do projeto. Se uma nova
implementao compromete a performance de algum ponto
isolado do sistema, este problema facilmente identificado
e isolado com a ajuda desta ferramenta.
Agilidade
A gerncia de projetos de software em duas

perspectivas Parte 2
Scrum
Geraldo Magela Dutra Gonalves

geraldo.magela@ufjf.edu.br
graduado em Engenharia Civil e possui especializao em Anlise e Desenvolvimento de

Sistemas, ambas pela Universidade Federal de
Juiz de Fora. tcnico em TI da Universidade
Federal de Juiz de Fora onde trabalha com
desenvolvimento de sistemas de informao e
informtica desde 1988. professor do Curso
Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional
D. Andr Arcoverde em Valena/RJ.
20
esenvolvimento de sistemas
uma atividade que requer criatividade. Esse um dos motivos
pelos quais no se pode automatizar
completamente a prpria atividade. Tal
criatividade, caracterstica marcante
da mente humana, requerida no s
na soluo de problemas complexos de
forma nica e inovadora, mas tambm,
e principalmente, na adaptabilidade a
situaes novas e inusitadas.
Desenvolvedores vem-se constantemente s voltas com situaes no
documentadas, mudanas de requisitos
durante o projeto, alm de variaes no
escopo levantado. Quando envolvidos
em um projeto de TI, cujo modelo de
gesto baseado em processos prdefinidos, desenvolvedores ficam sem
alternativas quando precisam lidar com
acontecimentos no previstos.
Modelos de gesto baseados em processos definidos estabelecem etapas
sequenciais e entregas intermedirias
rgidos, sem margens para manobra. Sistemas de informaes, ou outros projetos
A srie iniciada na ltima edio da Engenharia de

Software Magazine aborda duas perspectivas em
Gerenciamento de Projetos de TI. Este segundo artigo aborda caractersticas do Scrum, conjunto de
tcnicas de gerenciamento de projetos de desenvolvimento de software com foco em agilidade,
ou seja, entregas rpidas de software operacional
que agregue valor ao negcio do cliente. A inteno dos artigos estabelecer as bases necessrias
a uma comparao de metodologias, visando
fornecer subsdios para estabelecimento da
aplicabilidade das duas vertentes apresentadas.
O trabalho pretende auxiliar na escolha de uma
metodologia de gerncia adequada.

Quando o escopo de um trabalho situar-se
numa rea nebulosa em relao a qual tcnica
mais adequada ao planejamento, execuo,
acompanhamento e controle de um determinado projeto. Variveis comuns nesses casos,
como por exemplo, natureza voltil dos requisitos, porte do sistema, disponibilidade de recursos, qualidade do produto resultante, entre
dezenas de outras, podem dificultar a escolha
acertada da metodologia de planejamento e
gerncia.
Engenharia de Software Magazine - A gerncia de projetos de software em duas perspectivas Parte 2
M etod ologias geis
ainda mais ambiciosos de TI, so muito afeitos a ambientes

dinmicos de atuao, o que significa dizer que o modelo de
gesto aplicvel depende muito da natureza do projeto e da
natureza do produto desejado. A evoluo dos mtodos de
gesto de tais projetos seguiu ao longo das dcadas baseandose, principalmente, no princpio universal de tentativa e erro,
ou seja, na experincia adquirida na prtica diria.
Como uma consequncia natural dos fracassos colecionados
em projetos com modelo de gesto baseados em processos definidos rgidos, surgiram, naturalmente, propostas de modelos
de gesto que mudavam o foco do projeto de maneira bastante
radical sem, contudo, eliminar totalmente os vnculos bsicos
que os interligam.
Uma significativa quantidade de iniciativas compe um
conjunto de metodologias (ainda que algumas delas no se
denominem assim) que podem ser genericamente designadas
como metodologias geis de desenvolvimento de sistemas.
A maior parte delas, seno todas, baseiam-se em um mtodo
de gesto emprico, onde ao invs de empreender um grande
esforo inicial de planejamento e projeto, para depois lanarse construo do produto, o desenvolvimento do trabalho
orientado para o desenvolvimento iterativo, vrios ciclos de
projeto, execuo e entrega, gerando incrementos ao produto
em desenvolvimento, sempre totalmente operacionais, entre
outras caractersticas. Essa forma de gesto mostra-se mais
flexvel e adaptvel quando os projetos tratados demonstramse muito sensveis a ambientes e condies extremamente
sujeitos a incertezas.
Em tais ambientes, pode-se considerar o alvo do projeto como
algo mvel, que s poder ser atingido por aproximao. Esse
modelo de gesto mais aplicvel a situaes de projeto onde
tanto os processos de produo e gesto quanto os prprios
produtos deles obtidos so pouco ou nada previsveis. Como
um processo de gesto e execuo mais criativo e mais dinmico, ele pode ser significativamente mais caro, embora os
resultados possam facilmente compensar os custos.
SCRUM
Dentre as diversas propostas existentes, destaca-se o Scrum,
formalizado entre 1993 e 1995 por trabalhos de Jeff Sutherland
e Ken Schwaber, entre outros autores. Os fundamentos cultivados por Scrum baseiam-se em trabalhos muito anteriores,
de Ikujiro Nonaka e Hirota Takeuchi, da Toyota, que em 1986
publicaram um artigo onde propunham um estilo de gesto
holstico (considera que o todo maior que a soma das partes), onde a equipe busca, como em um jogo de futebol, de
forma integrada, chegar ao gol. Peter Degrace e Leslie Stahl,
ao mencionar o artigo de Takeuchi e Nonaka em seu livro
Wicked Problems, Righteous Solutions, comparam as idias
apresentadas a um movimento presente no jogo de rugby, o
Scrum. Surgia o nome do mtodo.
Em 1999, Ken Schwaber e Mike Beedle escreveram o primeiro
livro sobre Scrum: Agile Software Development with Scrum.
Os autores definem Scrum no como uma metodologia, mas
como um framework conceitual, um conjunto de ideias,
tcnicas e prticas que levam ao estabelecimento de uma

atitude mental de trabalho. As equipes Scrum so formadas
como times, e devem assumir um comprometimento com o
trabalho que alcana nveis bem superiores aos encontrados
em grupos de trabalho convencionais. Embora as origens de
Scrum remontem, portanto, s dcadas de oitenta e noventa,
sua popularizao entre desenvolvedores de sistemas se deu
a partir da divulgao, em 2001, do Manifesto para o Desenvolvimento gil de Software, mais comumente referido como
Manifesto gil.
Manifesto para o desenvolvimento gil de software

Esse manifesto um documento que resume as concluses de
um debate ocorrido em 2001, entre diversos desenvolvedores
de software, realizado com o intuito de estabelecer pontos de
convergncia e intersees observadas nas diversas metodologias praticadas por cada um dos integrantes daquele encontro. Embora tais pessoas tivessem, naquela ocasio, opinies
prprias e bem diferentes sobre como levar ao sucesso um
projeto de desenvolvimento de software, o manifesto deixou
claro que um conjunto de caractersticas comuns existia e poderia ser destacado sem ambiguidades. No texto do prprio
documento:
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o ns mesmos e ajudando outros a fazerem
o mesmo. Atravs deste trabalho, passamos a valorizar:
Indivduos e interaes mais que processos e ferramentas;
Software em funcionamento mais que documentao
abrangente;
Colaborao com o cliente mais que negociao de
contratos;
Responder a mudanas mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.
Existem pelo menos doze princpios que norteiam, a partir
do manifesto gil, os trabalhos de equipes que desejam desenvolver software de maneira gil, mas alguns deles esto na
base dessas metodologias. O fundamento considerado central
por todas elas o de que a prioridade dessas metodologias
deve ser a de satisfazer o cliente atravs de entregas rpidas e
at adiantadas de software com valor agregado. Alm disso,
os incrementos devem ser disponibilizados como software
operacional. Nenhuma outra definio de software pronto
aceita: software pronto software que pode entrar em operao
no ato da entrega.
Um fantasma que assombra projetos baseados em processos
pr-definidos, longos, e com a herana do desenvolvimento em
cascata, a presena de um conjunto de requisitos altamente
volteis. Como os mtodos mais convencionais pontuam por
projetar completamente antes de construir, mudanas durante
o curso do projeto so desastrosas.
As metodologias geis aceitam sem traumas e sem grandes
reaes a chegada de mudanas. Na verdade, uma de suas
caractersticas mais marcantes a de trabalhar sempre em
21
pequenos ciclos, dentro dos quais pode-se desenvolver desde projeto at implantao de incrementos e entre os quais,
pode-se acomodar sem grande dificuldade as mudanas ao
longo do processo. Isso na verdade produz um produto final
que invariavelmente mais adequado para o cliente do que
o produto idealizado a princpio; se os requisitos evoluem, o
produto evolui tambm.
Equipes de desenvolvimento gil s admitem integrantes
motivados. Para compor uma equipe produtiva, as pessoas
tm que dispor de condies materiais e mesmo emocionais
favorveis, sem o qu a produtividade esperada ser afetada.
A questo das comunicaes eficazes muito trabalhada nessas metodologias. consenso entre os signatrios do encontro,
que a melhor maneira de efetuar comunicao e transmitir
informaes entre os integrantes da equipe atravs de conversao face a face. claro que tais conversaes podem (e
segundo adeptos de metodologias mais tradicionais, devem)
ser acompanhadas de documentao no mnimo bsica, mas
isso no invalida esse fundamento. Uma conversa face a face
extremamente mais esclarecedora do que um e-mail.
Como um fundamento central final, a equipe deve, periodicamente, reunir-se e refletir sobre como tornar-se mais eficiente.
Acreditar que j se chegou ao mximo incentiva a inrcia e faz
com que a equipe estacione.
Comparao preliminar entre as duas metodologias

Vale a essa altura destacar os fundamentos que distinguem
as duas maneiras de desenvolver projetos de software sem,
contudo, adiantar quaisquer concluses.
Em primeiro lugar considera-se o foco de cada uma das
metodologias: o modelo tradicional trabalha desenvolvendo
sistemas onde o escopo pr-fixado, enquanto o modelo gil
fixa o tempo e a qualidade, deixando o escopo flutuar de acordo
com as mudanas durante o percurso. O cliente pode sentir-se
sempre vontade para introduzir mudanas a qualquer tempo,
desde que acordadas com a equipe. Nestes casos cabe equipe
julgar o que possvel realizar dentro do tempo acordado.
Modelos tradicionais fixam-se em planejamento e controle.
A execuo de uma etapa deve garantir que seu output seja o
input perfeito para a etapa seguinte. Os modelos geis aplicamse mais em inspees e adaptaes, mantendo-se prontas para
mudanas de direo ocasionais. Para isso, vale-se de pequenos ciclos de desenvolvimento incremental, que produzem
feedback contnuo.
Modelos tradicionais so orientados a processos, assim como
bem demonstra o PMBOK, discutido no artigo anterior. O foco
de Scrum, e outras metodologias geis, em pessoas, dando
participao delas uma dimenso mais prxima de sua real
importncia nos ciclos de desenvolvimento.
Por fim, para se obter uma analogia bem rica das duas formas
de desenvolver, compare um sistema a ser criado com um bolo:
as metodologias tradicionais trataro de constru-lo em camadas: camada1 + recheio + camada2 + cobertura, fazendo com
que s possa ser apreciado ao final do trabalho. Metodologias
geis vo construir o mesmo bolo em fatias finas: a partir da
22
primeira, os clientes j podero provar, aceitar ou recusar o

que esto comprando.
Elementos da metodologia SCRUM

As funcionalidades de um sistema de informaes so, sob
Scrum, classificadas pelo seu tamanho e abrangncia. Grandes
funcionalidades, que na verdade so grupos de funcionalidades
menores, so denominados picos. Estes elementos so compostos de funcionalidades denominadas user stories, que reunidas
em grupos coesos e relacionados constituem temas. Para serem
desenvolvidas, as stories so divididas em tarefas.
Como um modelo de gesto iterativo e incremental, Scrum
realizado em ciclos. Cada ciclo de Scrum denominado
sprint, perodo de tempo em que um ou mais incrementos
reais desenvolvido e, ao final, tais incrementos devem ser
demonstrados ao cliente. A durao de cada sprint pode variar de projeto para projeto, mas aconselhvel que dure de
2 a 4 semanas. So as duraes consagradas pela experincia.
Um sprint de 30 dias realizado em sprints dirios, onde os
integrantes da equipe idealmente devem realizar uma tarefa
completa. Cada sprint um ciclo completo PDCA (Plan Do
Check Act). O projeto completo composto de quantos sprints
forem necessrios para desenvolver todas as funcionalidades
encomendadas pelo cliente.
As funcionalidades (user stories) que devem ser desenvolvidas compem uma lista denominada product backlog. Esta
lista no precisa estar completa antes do comeo do desenvolvimento, ela cresce e se modifica ao longo do processo. Antes
do incio do sprint, o product backlog avaliado para gerar o
selected backlog, lista das funcionalidades que sero desenvolvidas naquele sprint. As funcionalidades do selected backlog
so ento quebradas em tarefas gerando o sprint backlog.
Tudo que acontece sob Scrum realizado em um perodo fechado de tempo. Essa caracterstica denominada time boxing.
As reunies e outros eventos tm, todos, tempos definidos e
fechados. Essa premissa fundamental para quem deseja entregar software no menor tempo possvel. A Figura 1 apresenta
a mecnica de um sprint completo.
Figura 1. Um sprint completo gerando incrementos potencialmente

implantveis
M etod ologias geis
Participantes do SCRUM e seus papis

Uma das premissas de Scrum a simplicidade. Isso se reflete
nos papis desempenhados pelas pessoas nesse processo:
so apenas trs e no guardam entre si nenhum vnculo de
hierarquia: so o product owner (o dono do produto), Scrum
master (um coordenador do time) e o Scrum team (time de
desenvolvimento).
O product owner quase sempre o financiador do projeto ou
um legtimo representante deste. Sua presena, nos ciclos de
planejamento, garante objetividade, foco e decises acertadas
quanto ao rumo do projeto. Esse personagem fornece a viso
de negcio, encurtando o tempo de domnio do grupo sobre a
rea de negcio contemplada. Como de seu exclusivo interesse, ele maximiza o que se chama ROI (Return Of Investment),
garantindo que o menor tempo e menores recursos sero
usados no desenvolvimento das funcionalidades consideradas
importantes. Em reunies com sua presena que se define
o product backlog. Antes de cada ciclo de desenvolvimento,
chamado no Scrum de sprint, o product owner atualiza e
prioriza o product backlog, ou seja, ele quem decide que
funcionalidades devem ser desenvolvidas no prximo sprint.
Tambm responsabilidade do product owner esclarecer dvidas da equipe, assim como julgar sobre a aceitao ou recusa
de entregas intermedirias ou sobre o produto final.
O Scrum master tem um papel de destaque no processo.
Esse personagem deve exercer o que se denomina, liderana
servidora, ou seja, uma espcie de capito de time. Embora a
ele sejam atribudas funes consideradas vitais, ele permanece como um membro da equipe, participando ativamente de
seus sucessos e de suas dificuldades. Ele conduz as reunies
e se assegura de manter o time box de cada uma delas, age
como facilitador para que cada membro da equipe remova
obstculos execuo de suas tarefas, empenha-se em manter
o Scrum funcionando e protege o Scrum team de ameaas externas. Embora no vista a pele de um gerente convencional,
suas atribuies se revelam ainda mais delicadas do que as
daqueles. Alm de auxiliar o Scrum team e o product owner
em suas tarefas, cabe a ele manter-se atento ao planejamento
e aos objetivos do prximo sprint.
O Scrum team a equipe de desenvolvimento. Dentro de um
Scrum team no existe, idealmente, nenhum tipo de hierarquia,
como programadores, analistas ou arquitetos. As pessoas
assumem tarefas de acordo com suas capacidades, e formam
uma equipe multidisciplinar. Como o Scrum master no o
gerente, esse grupo auto gerenciado: cada um assume tarefas
que quer e pode fazer, e cada um se compromete a cumpri-la,
mantendo um compromisso com a equipe e consigo mesmo.
Para isso, cada membro tem autonomia pra cumprir os objetivos dos sprints dirios e mensais. O grupo deve manter
comunicao constante, formal, atravs das reunies programadas, como se ver adiante, e informalmente, atravs de
relacionamentos no ambiente de trabalho. Os Scrum teams
devem ser formados de entre 7 a 9 pessoas. A definio desse
nmero, alm de basear-se em experincia pura, est fundamentada no clssico mtico homem/ms: produtividade
no est associada unicamente ao tamanho da equipe. o

Scrum team que desenvolve os incrementos que comporo
o software.
A dinmica do SCRUM
A partir das definies de elementos bsicos e de integrantes
e papis apresentada, pode-se descrever a dinmica do processo, ou seja, como esses elementos interagem para produzir
software de forma gil e com qualidade. Para descrever como
isso se d, considere-se sprints com time-box de 30 dias.
O primeiro dia de cada sprint dedicado ao Sprint Planning
Meeting, ou encontro de planejamento do sprint, composto
de duas reunies de time box de at 4 horas cada uma. A
primeira delas realizada apenas entre o Scrum master e o
product owner. Nessa reunio, os integrantes verificam o product backlog, quanto completude e quanto priorizao das
funcionalidades descritas no documento. Essas tarefas so de
responsabilidade do product owner. Itens no product backlog
obedecem a um critrio denominado itens potencialmente
implantveis, ou seja, itens totalmente operacionais que resolvem algum problema de um ou mais stakeholders.
A segunda reunio do Sprint Planning Meeting realizada
entre o Scrum master e o Scrum team, o time de desenvolvimento, embora o product owner possa ser convidado a participar. Nessa reunio, o time selecionar, do product backlog,
os itens ou user stories que se comprometero a desenvolver
nos prximos 28 dias do sprint.
Para fazer isso, as user stories so quebradas em tasks (tarefas), que constituem, idealmente, trabalho que pode ser realizado em um sprint dirio. Essa quebra em tarefas baseada
em estimativas de tempo com mtricas prprias da metodologia, como ser visto adiante, e gera como produto um sprint
backlog. Aqui, destaca-se uma caracterstica vantajosa do
Scrum em relao s metodologias mais clssicas. Sob Scrum,
quem faz a estimativa de tempo o desenvolvedor, aquele que
efetivamente cria o cdigo, enquanto que nas metodologias
clssicas esta tarefa realizada por analistas de sistemas que
no esto necessariamente envolvidos com codificao. A prtica demonstra que a experincia acumulada pelo codificador
torna-o significativamente mais apto para estimar tempo e
esforo do que um simples aplicador de mtricas.
Logo aps a criao do sprint backlog, o time pode adotar
como ferramenta de apoio um quadro denominado taskboard,
que rene e organiza as tarefas em categorias: stories, tasks,
tasks em execuo e tasks completadas. A Figura 2 apresenta um
exemplo de taskboard onde foi traado um grfico burndown,
que atualizado diariamente, mostra a evoluo do esforo
empreendido e o esforo remanescente.
A partir desse primeiro dia de planejamento, seguem-se 28
dias de trabalho baseados no selected backlog ou sprint backlog.
Cada dia tpico de trabalho comea com uma reunio rpida
denominada Daily Meeting, com time box de no mximo 15
minutos, para no comprometer a produtividade da equipe.
Nessa reunio, o Scrum master ouve a equipe e procura
remover impedimentos ao bom cumprimento das tarefas
23
alocadas a cada membro. nesse momento tambm que se

faz a alocao de tarefas, atividade feita preferencialmente de
forma livre e democrtica entre os participantes, ou seja, cada
membro da equipe escolhe uma ou mais tarefas que dever
realizar at o final do dia.
metodologias, Scrum depende de feedback constante sobre

a performance do time para, a partir delas, adaptar suas
futuras medidas. Esse feedback recolhido durante a sprint
retrospective, durante a qual o Scrum master e o Scrum team
refletem e discutem sobre: O que foi bom durante o sprint? O
que pode melhorar para o prximo?
No se trata de uma reunio de mtuas acusaes, e sim
um momento de reflexo com esprito de equipe. Todas as
medidas corretivas adotadas sero motivadas pela melhoria
do processo de desenvolvimento e da produtividade da equipe. Podem existir resistncias: faz parte do desenvolvimento
da prpria equipe atingir transparncia capaz de produzir
melhorias reais.
Comprometimento e envolvimento
Figura 2. Taskboard com Curva Burndown
Para que tais reunies sejam expressas e objetivas, elas devem

preferencialmente ser realizadas com os participantes de p.
Cada participante deve refletir e expressar-se sobre trs itens:
O que eu fiz no dia anterior? O que eu pretendo fazer no dia
de hoje? Existe alguma coisa impedindo meu trabalho? Se a
tarefa do dia anterior est incompleta, e o que ser feito para
compensar essa falha, de responsabilidade exclusiva do
prprio membro. O Scrum master no assumir um papel de
cobrador de responsabilidades; seu papel o de conciliador e
solucionador de problemas que impedem o trabalho do time.
A natureza de tais impedimentos muito heterognea e varia
desde problemas com hardware ou software at problemas
pessoais e de relacionamento entre membros da equipe.
No 30 dia do sprint, acontecem duas importantes reunies
de fechamento, ambas com time box de 4 horas. A primeira
delas, o sprint review, constitui um importante ponto de controle do Scrum: o momento no qual o time e o Scrum master
demonstram as funcionalidades desenvolvidas ao product
owner. Pode-se imaginar a importncia capital desse encontro:
funcionalidades efetivamente operacionais aumentam no s
a motivao e a autoconfiana da equipe como aumenta a confiana do product owner na equipe, diminuindo as incertezas.
Nesse momento ele tem uma ideia muito clara sobre o destino
de seus investimentos.
Funcionalidades efetivamente operacionais uma definio
que pode gerar controvrsias. A equipe Scrum deve acordar
com o product owner o que se entende como tarefa realizada ou
pronta. O que importa aqui definir sem ambiguidades o que
pronta. Aceito o conceito, nada diferente disso admissvel;
80% de uma tarefa no significam nada sob Scrum, j que a
metodologia orientada a objetivos, e no a tarefas.
A segunda reunio do ltimo dia igualmente um momento
significativo do Scrum. Como prtica focada em melhoria
contnua do processo, contrariamente rigidez de outras
24
Como j ficou claro, Scrum se esfora para planejar menos e

realizar mais. E um dos fundamentos para alcanar essa meta
a objetividade com que as diversas atividades devem ser
realizadas. Embora quase todas as reunies contem com a presena dos trs atores tpicos do Scrum, o nvel de importncia
de cada um deles varia, dependendo do evento, de envolvido
a comprometido ou neutro. Essa escala de importncia pode
ser compreendida pela divertida fbula do porco e da galinha
mostrada na Figura 3.
Figura 3. Fbula do porco e da galinha
De maneira semelhante, dependendo do evento, cada participante pode ter sua importncia reclassificada, tornando-se
mais ou menos influente. A cada evento tpico de Scrum, so
identificados os participantes do tipo galinha, ou seja, pessoas
que esto envolvidas, os participantes do tipo neutro, que no
influenciam os resultados do evento, e os participantes do tipo
porco, aqueles que esto comprometidos. O participante do
tipo porco tem sempre muita responsabilidade no evento em
que participa e o sucesso de tal evento depende diretamente
de seu desempenho.
Mtricas para estimativa de esforo

Metodologias tradicionais utilizam-se de mtricas de estimativa de esforo, tamanho da equipe e tempo, como FPA
(Function Points Analisys) ou COCOMO (COnstructive COst
MOdel), tambm clssicas por sua vez.
Em Scrum, as estimativas so feitas utilizando mtricas
aderentes filosofia de trabalho do Scrum: agilidade. Para
tanto, o mtodo se vale de uma tcnica intitulada history
points, uma contagem de pontos que define um tamanho para
cada estria de maneira relativa s outras estrias de mesmo
M etod ologias geis
projeto. , portanto, uma medida do tamanho geral de uma

atividade, no absoluta.
Como ferramenta para realizar essa pontuao, o Scrum team
utiliza um baralho especial chamado Planning Poker, cujas
cartas so numeradas com uma adaptao da sequncia de
Fibonacci: 1/2, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Trs cartas especiais
marcadas com 0 (zero), ? (ponto de interrogao) e caf completam o baralho. O zero usado quando a estria j foi concluda
ou muito pequena. O ponto de interrogao significa que o
membro no faz a mnima idia de valor para aquela estria e
o cafezinho indica que melhor parar para um caf antes de
prosseguir. Os valores no expressam uma unidade qualquer,
seja de tempo, seja de esforo. Eles so usados para quantificar
o tamanho de uma estria em relao s demais.
Durante a segunda reunio do Sprint Planning Meeting, o
Scrum team se ocupa em realizar uma sesso de Planning
Poker, onde o product owner apresenta uma estria do product backlog e os integrantes do time escolhem, cada um
baseando-se em sua prpria experincia em codificao, uma
carta com um valor para a atividade. As cartas so colocadas
viradas para baixo no centro de uma mesa e depois viradas
em conjunto. O objetivo alcanar um valor de consenso.
Para tanto, os valores so comparados e as discrepncias so
defendidas por seus autores: o autor da mais alta pontuao e
o autor da mais baixa pontuao. Logo aps as breves defesas
apresentadas, realizada uma nova rodada de pontuao, na
qual todo membro pode manter o valor de sua carta, aumentlo ou diminu-lo. Duas ou trs rodadas podem ser suficientes
para alcanar um valor de consenso.
Embora a tcnica seja baseada em uma pontuao relativa, ela
s faz sentido se uma medida de velocidade for introduzida, ou
seja, necessrio estabelecer um nmero de estrias entregues
pela equipe em uma iterao. Embora esse nmero possa variar
bastante com a natureza do sistema, recorrncia do tema ou
originalidade da soluo, um nmero mdio de capacidade
da equipe pode ser derivado dos histricos acumulados pelo
time ao longo de projetos. Com essas duas medidas possvel
criar um cronograma de trabalho realizvel.
Ao decidir sobre a pontuao de uma determinada story,
cada membro da equipe deve considerar trs fatores relativos
a ela: complexidade, esforo e incerteza. preciso estar atento
para o fato de duas stories poderem apresentar uma mesma
pontuao, mas uma delas ter muito mais complexidade do que
a outra. Em termos prticos: alta complexidade e baixo esforo
podem produzir uma contagem idntica a baixa complexidade
e alto esforo.
Caractersticas adicionais do SCRUM

Scrum uma metodologia baseada em simplicidade e adaptabilidade. Um fundamento dessa filosofia a manuteno da
base desse conceito: equipes gerenciveis. A maioria dos livros
aponta equipes de no mximo 9 pessoas, multidisciplinar e
motivada. Mas inescapvel a existncia de projetos onde essa
fora de trabalho tem de ser multiplicada, devido ao tamanho
do sistema sendo desenvolvido.
Aumentar uma equipe de 8 pessoas para 25 descaracteriza

o ideal do Scrum team e torna a equipe no gerencivel. Para
lidar com essas situaes, o Scrum preconiza a prtica Scrum
de Scrums (Scrum of Scrum). As equipes so mantidas com
no mximo 9 pessoas e formado um novo grupo com um
membro de cada equipe, geralmente seu Scrum master.
Scrum de Scrum ento a realizao de encontros entre
Scrum masters com a finalidade divulgar conhecimento entre
os diversos times. A mecnica dessa reunio bastante perecida com a dos daily Scrums, mas com foco na equipe ao invs
de foco pessoal. Em outras palavras, cada Scrum master relata
o que a equipe fez nos sprint dirios da ltima semana (se os
encontros Scrum de Scrum forem semanais); o que a equipe
far nos sprints dirios da prxima semana; existem impedimentos ao trabalho da equipe? A finalidade desses encontros
manter as equipes sincronizadas e permitir o gerenciamento
da totalidade e, principalmente, das sobreposies.
claro que existem pontos que merecem ateno especial
como gerenciar o desenvolvimento do mesmo cdigo fonte
por duas ou mais equipes de trabalho. As estratgias para o
enfrentamento dessas dificuldades so da responsabilidade
dos Scrum masters reunidos.
Reunies Scrum de Scrum devem ser realizadas diariamente,
sempre aps as daily scrums. Mas se isso no for possvel,
um quarto questionamento deve ser investigado por cada um
dos Scrum masters presentes: h algum impedimento que
voc esteja preparando para introduzir nos prximos sprints
dirios? Essa pergunta procura adiantar os passos de uma
semana, por exemplo, para que nenhuma equipe seja pega de
surpresa por aes de outra.
A maneira de gerenciar Scrum de Scrum pode ser aplicada
em diversos nveis, at que a estrutura seja capaz de realizar o
projeto de desenvolvimento em questo. Assim, pode-se chegar
a Scrum de Scrum de Scrum, e at alm. Nessa estrutura de
gerenciamento, as stories descem pela hierarquia at as equipes
via product owners enquanto os impedimentos sobem at as
esferas superiores via scrum masters.
Concluso
Metodologias de desenvolvimento de sistemas existem s dezenas. Um grande empecilho a um grande painel comparativo
a diferenciada natureza dos sistemas de informao. no
mnimo arriscado afirmar que essa ou aquela metodologia
mais ou menos eficiente que outra. Parece sempre mais equilibrado perceber que cada uma delas tem qualidades e falhas,
e que sua aplicabilidade sempre depende de uma srie no
trivial de fatores de influncia.
Outra abordagem interessante, considerando metodologias
de desenvolvimento de sistemas, nunca consider-las e
aplic-las de forma dogmtica, ou seja, sem admitir adaptaes.
Equipes e profissionais criativos sempre foram o diferencial em
se tratando de inovaes, o prprio Scrum prova disso.
De qualquer forma, a adoo de metodologias mais tradicionais
ainda pode se fazer necessria quando o projeto for altamente
dependente de grande documentao, quando as equipes de
25
De sua atuao espera-se que a equipe percorra no menor

tempo o caminho at a compreenso suficiente pra produzir
um resultado final que atenda ou supere as expectativas de
seu financiador.
Links
Manifestogil
http://agilemanifesto.org/
Artigo Introduction to Scrum - An Agile Process
http://www.mountaingoatsoftware.com/Scrum

D
s
E-book Scrum e XP direto das Trincheiras

http://www.chrisb.com.br/files/ScrumeXPdiretodasTrincheiras.pdf
Feedback
eu
edio
ta
26
pessoas em relao s suas prprias capacidades e limitaes,

confiana na sua prpria competncia e na prtica saudvel de
poder trabalhar nas atividades que escolheu, sem imposies
(parece um pouco de conto de fadas, mas possvel!);
comunicao eficiente, pessoas falando com pessoas, torna
mais agradvel o dia a dia do profissional;
atividades desenvolvidas com tempo pr fixado, aguando
o sentido de responsabilidade e compromisso;
menos planejamento e mais ao, menos papel e mais cdigo,
sem jamais abrir mo da qualidade; e finalmente;
a quebra de um paradigma que persegue a dcadas os
desenvolvedores de sistemas de computao: o cliente no
inimigo, mas parceiro.
sobre e
s
desenvolvimento forem realmente muito grandes, quando o

produto sendo desenvolvido possuir um conjunto de requisitos
muito amplo mas relativamente estvel, e quando o tempo estimado para realizao do trabalho for realmente significativo. Em
qualquer dessas situaes, os diversos grupos de stakeholders iro
se sentir mais tranquilos se tiverem acesso a um planejamento
mais robusto em face da envergadura do projeto.
Na outra ponta est o SCRUM e outras metodologias geis,
como XP, por exemplo. No h como negar a evoluo significativa das prticas de gerncia introduzida por elas. Trazem
benefcios a uma ampla faixa de projetos onde a presteza com
que se entrega o produto um fator crtico de sucesso. Mas
no se deve confundir presteza com pressa! SCRUM se fundamenta em foco no objetivo, mas fixando qualidade e tempo.
Sob SCRUM a qualidade um fator no negocivel!
Existem pelo menos cinco valores fundamentais do Scrum:
foco, abertura de esprito, comprometimento, respeito e coragem. O que so premissas dessa metodologia pode tambm ser
sua maior fragilidade. Scrum s pode funcionar com equipes
altamente treinadas, pessoas convencidas da qualidade do
Scrum e mais que tudo isso: realmente comprometidas. No
que isso no seja possvel alcanar, mas existem desafios a
vencer para formar equipes com esse perfil. Os membros de
um time Scrum tpico so atpicos, ou seja, no se encontram
diariamente nos classificados de profissionais procura de
emprego. De qualquer forma pode-se esperar que, no futuro, a
prpria adoo de novas metodologias torne o encontro desses
profissionais mais comum.
Aos cinco fundamentos acima, que caracterizam Scrum como
metodologia inovadora de gerncia de projetos de TI, podem-se
somar mais seis, que do o tom final de sua qualidade:
um processo iterativo e incremental, portanto apresenta
resultados em tempo de diminuir as incertezas de todos os
stakeholders;
as equipes formadas sob Scrum devem desenvolver a capacidade de auto-gerenciamento, o que acaba por desenvolver as
Agilidade
Uso de metodologias geis em uma

organizao baseada em linha de produto
Um relato de experincia
Giselle Tavares
gitavares@hotmail.com
Possui bacharel em Cincia da Computao

pela UNICAP e especializao em Gesto
gil de Projetos pelo C.E.S.A.R. H 12 anos
trabalhando na rea de TI, sendo quatro
deles com Qualidade e Processos de Melhoria de Software.
Felipe Furtado
felipe.furtado@cesar.org.br
Possui especializao em TI e mestrado em

Cincias da Computao pelo Centro de Informtica da UFPE. Atualmente doutorando no CIn, Gerente de Projetos do C.E.S.A.R,
coordenador da ps-graduao em Gesto
gil de Projetos do CESAR.EDU e docente
do Mestrado Profissional em engenharia
de software. Tem experincia h 14 anos na
rea de Engenharia de Software, com nfase
em Qualidade de Software e Gesto de Projetos, atuando principalmente nos seguintes
temas: Melhoria de Processos de Software,
Modelos de Maturidade, Metodologias geis
e Estratgias de Melhoria de Produtividade.
a ltima dcada as metodologias geis vm ganhando espao no mercado de Tecnologia

da Informao e Comunicao. Vrias
pesquisas mostram os bons resultados
alcanados por essas empresas, por
exemplo, a pesquisa conduzida por
Scott Ambler em 2008 que relatou que
82% das empresas tiveram melhorias
na produtividade, enquanto que 77%
apresentaram melhorias na qualidade
do produto. Em 2010, Ambler relata uma
taxa de sucesso de 55% dos projetos que
utilizaram metodologias geis.
De acordo com a Figura 1, dentre as
metodologias mais utilizadas, o Scrum
normalmente aparece como uma das
preferidas pelas organizaes (53%),
seguida do uso em conjunto com o XP
(17%). Nesta mesma pesquisa, a adoo
Com a necessidade de tentar melhorar os processos

de desenvolvimento de software e acompanhando
as tendncias da Engenharia de Software, que trouxe
mais visibilidade aos mtodos geis, vrias empresas
optaram por implant-los em sua organizao, porm de maneira desordenada. Este relato descreve a
implantao de metodologias geis em uma organizao baseada em linhas de produto e, com base nos
resultados alcanados, prope uma adaptao com o
uso de Scrum, XP e Kanban.

Em ambientes baseados em linhas de produto
que possuem uma grande diversidade de clientes
com prioridades diferenciadas e que necessitam
de adaptaes em seus processos de desenvolvimento de software.
conjunta de Scrum e Kanban (3%) comea a ser percebida.

No entanto, algumas empresas encontram dificuldades na implantao das
metodologias, ora por falta de conhecimento, ora por dificuldade na adaptao
de tais metodologias ao contexto de
seus projetos. Por exemplo, empresas
baseadas em linhas de produto possuem
27
caractersticas que dificultam a adoo de iteraes de tamanho

fixo e escopo fechado, conforme definido pelo Scrum.
Este artigo relata a experincia de uma empresa baseada em
linha de produto que iniciou a implantao de metodologias
geis a partir do Scrum e, em seguida, a prtica Pair Programming, originada do XP. A opo pelo Scrum veio para auxiliar
no gerenciamento do projeto, percebendo-se que a equipe de
desenvolvimento estava crescendo para suprir s demandas
de customizaes, e o Pair Programming para diminuir a curva
de aprendizado dos novos integrantes da equipe. A partir da
anlise de alguns problemas, este artigo sugere a utilizao de
um processo adaptado em conjunto com o Scrum e Kanban,
a fim de preencher lacunas nas quais as limitaes das metodologias implantadas no supriram.
Este relato est organizado da seguinte maneira: inicialmente so apresentados os conceitos sobre Linha de Produto,
Scrum, XP e Kanban. Em seguida, apresentada a anlise
da implantao do Scrum e do Pair Programming na empresa
aqui estudada, e uma proposta para adaptao do processo
implantado com o Kanban.
Figura 1. Metodologias geis mais utilizadas [7]
Linhas de Produto
Empresas de Linhas de Produto so aquelas que produzem
um software possvel de ser utilizado por segmentos de
mercado diversos, mas que pode ser adaptvel para cobrir as
necessidades especficas de seus clientes, pensando ainda no
valor de negcio como um todo.
De acordo com o Software Engineering Institute, uma linha
de produto utiliza tcnicas e prticas de engenharia para
criar um conjunto de sistemas que compartilham caractersticas comuns, satisfazendo as necessidades especficas
de um determinado segmento do mercado ou misso, e que
so desenvolvidos a partir de um ncleo comum de maneira
prescrita. Tem como atividade principal a integrao ao invs
do desenvolvimento.
Metodologias geis: Scrum, XP e Kanban

Uma metodologia deve ser considerada gil quando ao invs
de tentar prever o futuro, aceita as mudanas naturalmente.
Aceitar mudanas nesse contexto gil significa saber receb-las
e respond-las a custos menores [6].
28
O Scrum um framework para planejamento e acompanhamento de projeto que segue os princpios do Manifesto gil.
Por ser iterativo e incremental, ele funciona bem em um
ambiente de constante mudana. Prov equipes autogerenciveis e prope uma forma de trabalho flexvel e adaptvel,
no apenas em relao ao escopo e requisitos de um projeto,
mas tambm quanto troca de equipes, de ferramentas, de
linguagens de programao, etc. [4].
O XP (eXtreme Programming) uma metodologia gil voltada para a Engenharia de Software, dando mais ateno
programao, e no tanto ao gerenciamento, como o foco do
Scrum, motivo pelo qual normalmente so metodologias utilizadas juntas [3]. Foi criado por Kent Beck em 1996 e busca
aprimorar um projeto de software utilizando cinco valores
essenciais: comunicao, simplicidade, feedback, respeito e
coragem. Foram definidas 12 prticas, sendo uma delas o Pair
Programming, que consiste em juntar dois desenvolvedores
em um nico computador, concentrando-se no mesmo cdigo. Isto ir fazer com que a qualidade do software aumente,
mas sem impactar na entrega. O principal benefcio passa a
ser a disseminao do conhecimento entre o time.
O Kanban traz consigo a filosofia do JIT (Just In Time)
veja Nota 1, que significa produzir apenas o necessrio,
no tempo necessrio, na quantidade necessria, e no local
necessrio, com qualidade e envolvimento das pessoas, eliminando assim o desperdcio, e garantindo o fluxo contnuo
de produo [2].
Para David Anderson, o fato do Kanban possuir limite
fixo do trabalho em progresso (WIP, Working In Progress
Nota 2), proporciona um tempo de ciclo previsvel e eleva a
expectativa da entrega com maior nvel de qualidade. Alm
disso, sendo um sistema puxado, facilmente se verifica onde
est o gargalo no fluxo de trabalho. Ainda de acordo com
Anderson, Kanban no um processo de ciclo de vida de
gerenciamento de projeto ou de desenvolvimento, mas sim
uma abordagem para gerenciar mudanas.
Nota 1: Just In Time
JIT, ou Just In Time, um sistema de administrao da produo que determina que nada deve
ser produzido, transportado ou comprado antes da hora exata. Pode ser aplicado em qualquer
organizao para reduzir estoques e os custos decorrentes.
Nota 2: Work In Progress

WIP, ou Work In Progress, define o limite para quantos itens podem estar em andamento em
cada estado do processo, por exemplo, quantas estrias podem ser executadas ao mesmo
tempo dentro de uma fase do processo.
Anlise sobre o processo de implantao

Nesta seo ser contextualizada a empresa analisada e ser
relatado o processo de implantao do Scrum, realizado h
pouco mais de um ano, assim como os benefcios e as lies
aprendidas. Por questes de confidencialidade, a empresa
analisada no ser identificada.
Engenharia de Software Magazine - Uso de metodologias geis em uma organizao baseada em linha de produto
M etod ologias geis
Caractersticas da Organizao
A empresa estudada existe a mais de 20 anos no mercado
e dedica-se ao desenvolvimento de sistemas de gesto em
diversas reas de atuao em todo o territrio nacional. Sua
matriz est localizada no Nordeste, e possui cerca de 250
funcionrios. O processo analisado utilizado para o desenvolvimento de um ERP (Enterprise Resource Planning), com
cerca de 20 anos, e que possui em torno de 80 colaboradores
ligados diretamente em sua fase de construo. O produto
possui verses liberadas a cada dois meses e releases liberados para o cliente semanalmente. Cada liberao de uma
nova verso considerada um projeto, que por sua vez, se d
atravs do backlog do produto, com as datas de cada customizao j acordadas com os clientes, baseadas em estimativas
realizadas pela equipe.
O Processo de Implantao do Scrum

A necessidade da implantao de mtodos geis no ambiente
de trabalho deu-se ao serem observadas as dificuldades que o
gerente de projetos vinha tendo ao tentar acompanhar o andamento de um projeto de um produto que estava crescendo em
nmero de clientes. Este crescimento aumentou a demanda por
customizaes, que por consequncia, trouxe a necessidade de
aumentar tambm o nmero de colaboradores na equipe. Pelo
processo corrente, o Analista de Sistemas deveria gerar uma
srie de artefatos para auxiliar o desenvolvimento, testes, documentao, capacitao etc., alm de estimar customizaes,
que era um procedimento longo o suficiente para um cliente
desistir de esperar por um retorno. Para o Gerente de Projetos, acompanhar o andamento das atividades de dezenas de
colaboradores era impraticvel. A partir dessas situaes, aps
alguns estudos, foi verificado que possivelmente o framework
Scrum atenderia essas necessidades. A Figura 2 ilustra o fluxo
do framework do Scrum utilizado como base para a adaptao
do processo.
Figura 2. Viso Geral do Processo do Scrum
A primeira providncia foi reunir os gerentes de diversas

reas envolvidas no produto e explicar como funcionaria
essa nova maneira de trabalhar. A reao dos gerentes de
teste, de desenvolvimento e de projetos foi: e qual ser a
minha funo agora? Como vou acompanhar o projeto? Os

Scrum Masters agora sero os chefes? Como eu vou saber o
que a equipe est fazendo? Vou perder a autoridade?
O gerente de testes foi o mais relutante, pois ele possua
uma equipe em um local definido da empresa, e viu que
com o Scrum o time de testes deveria ser distribudo em
equipes.
Os analistas de negcio foram escolhidos para serem os
Product Owners (PO). Neste cenrio, no h a possibilidade
de ter os clientes como POs, pois se trata de um produto com
centenas de clientes, e todos estes analistas possuem um
conhecimento profundo do sistema. A funo deles como
PO passar aos times o backlog da Sprint, considerando que
existe um cronograma do projeto com ocorrncias em ordem
de prioridade para cada mdulo do produto, alm de explicar os requisitos. Sendo vrios times e vrios POs, apesar de
cada time ter seu prprio PO dedicado, estes se renem antes
da reunio de planejamento de Sprint para se alinharem e
identificar possveis impactos entre solicitaes.
Foram escolhidos para serem Scrum Masters, inicialmente,
os analistas de sistemas com maior experincia em cada mdulo, mas sem deixar as suas funes originais. Por serem
bastante solicitados para resolver problemas e constantes
viagens para atender aos clientes, alguns deles foram substitudos, pois no conseguiam desempenhar o novo papel
adequadamente. A escolha de novos Scrum Masters foi feita
novamente pela gerncia, e o critrio utilizado foi tambm
o tempo na empresa e conhecimento, mas dessa vez, eles
deveriam ter perfil de lder.
Os desenvolvedores e testadores foram separados por
mdulos para que se formassem os times. O nmero de
colaboradores no incio, em cada time, variava entre 6 e
12. Depois, esse intervalo cresceu para algo entre 8 e 16.
Aconteceu ainda de ter dois times (compostos apenas por
novatos) para customizaes exclusivas solicitadas por dois
importantes clientes, e alocado um nico Scrum Master,
sendo este um analista de sistemas dos mais solicitados.
Para tentar minimizar a falta de treinamento do negcio
para as equipes de novatos, foi aplicada a tcnica do Pair
Programming, alm da tentativa de dedicao do Scrum
Master como lder tcnico e de negcio para fazer mentoring com os times. Essa experincia durou seis meses. Em
princpio, a escolha das duplas foi aleatria. Na primeira
troca de duplas, o critrio foi juntar um membro do Time
que tinha um conhecimento tcnico e de negcio melhor,
com outro com menor conhecimento.
Dos artefatos de desenvolvimento e testes at ento necessrios, Especificao de Requisitos, Projeto de Implementao, Estimativa de Testes, Documento de Viso, entre outros,
passaram a no ser mais utilizados, considerando que todas
essas informaes eram passadas via Reunies de Planejamento de Sprint 1 (especificao) e 2 (tcnica).
Porm, durante a Execuo da Sprint, o time passou a sentir
falta dos artefatos mencionados. Os analistas de sistemas
passaram a ser mais requisitados que o normal, alm de
29
desempenharem o papel de Scrum Masters. Vrias maneiras

de se registrar o que era discutido na Sprint foram executadas.
Desde gravar as reunies at a criao de ata em tempo real.
Porm, o que se manteve foi uma planilha que dividia cada
item de backlog, informando basicamente a sua descrio,
critrio de aceitao, complexidade estimada e descrio
tcnica, que era preenchida durante a reunio.
Ainda durante a reunio de planejamento da Sprint, outra
dificuldade encontrada pelos times que, por no saberem
o que seria pedido na Sprint, no se preparavam antes. No
em razo do entendimento do requisito, que seria passado
pelo PO, mas sim pelo que seria discutido na Reunio de
Planejamento 2. Entender os requisitos no era suficiente
para saber rapidamente quais fontes, telas, tabelas etc.,
deveriam ser utilizados. Ou ainda, se havia alguma particularidade, antes mesmo de definirem a melhor soluo para
customizar a solicitao. Sendo assim, resolveram utilizar
uma planilha prpria de estimativa para auxili-los nesta
segunda reunio de planejamento, considerando que esta
continha informaes tcnicas de cada customizao.
A partir de um estudo do histrico das estimativas, e pelo
conhecimento dos analistas de negcio, estes passaram a dar
a estimativa inicial ao cliente, e somente quando esta era
aceita, que o analista de sistemas detalhava a estimativa
para se obter de fato o tempo gasto de desenvolvimento para
ser includo no cronograma.
Com o incio da implantao do Scrum, o time era quem
dizia ao PO o que cabia na Sprint, mas quando o final do
projeto se aproximava, muitas solicitaes ainda precisavam
ser concludas. A partir disso, a ideia foi fazer com que o
PO chegasse com o backlog da Sprint priorizado de acordo
com o cronograma do projeto, baseado no prazo dado aos
clientes. Com isso, a reunio de Planejamento 1 passou a
ser apenas para entendimento, e a estimativa atravs do
Planning Poker se manteve somente para saber se todos estavam entendendo o requisito, ou seja, caso houvesse alguma
forte divergncia de estimativas entre os participantes, esses
levantavam seus pontos de vista.
O comprometimento do time passou a ser na Reunio de
Planejamento 2. Nessa reunio apenas o time se rene, e tem
a chance, a partir da verificao tcnica do que ser implementado, de reestimar as ocorrncias, em horas, conforme
a Planilha de Estimativa, e argumentar que podem no
conseguir entregar a Sprint. Neste caso, ao final da reunio,
o PO chamado para que a negociao seja feita.
Durante a execuo das atividades do time, foi percebido
que nem todos focavam na mesma estria, isto porque s
vezes no era possvel dividi-la, ou porque era pequena,
ou por impossibilidade tcnica. A partir dessa situao, foi
percebida uma maneira de obter mais comprometimento
da equipe, sendo possvel organizar a Reunio de Entrega
de modo que quem apresentava determinada estria, era
quem a havia desenvolvido.
Quanto reunio de Retrospectiva, logo no incio em que
passou a ser realizada sem o acompanhamento do SEPG
30
(Software Engineering Process Group) Nota 3, no era utilizada para melhoria do time no que se refere entrega da
Sprint com qualidade. Eram discutidos problemas de baixa
relevncia ao melhoramento de fato da produtividade do
Time. Essa reunio, com o passar do tempo, passou a no
ser mais realizada pelos times, alegando discutirem sempre
as mesmas coisas.
Nota 3. SEPG
SEPG, ou Software Engineering Process Group, o Grupo estabelecido e designado como
responsvel pela definio, manuteno e melhoria do processo de Engenharia de Software.
Para tentar melhorar o foco dessa reunio, foi criado um artefato especfico para preenchimento em tempo real de aes
de melhoria, separando-as por descrio, responsvel e prazo.
As aes de mbito organizacional tambm eram indicadas no
documento para que fossem periodicamente cobradas.
Alm disso, foi pedido pelos times que esta reunio fosse
mensal, e no mais por Sprint. O motivo dado foi o fato dessas Sprints quase nunca serem finalizadas corretamente, em
consequncia das suas constantes e inevitveis mudanas de
escopo. Logo, eles no viram necessidade em discutir o porqu
de uma iterao no ter dado certo, mas sim em focar nos Bugs
gerados, para tratarem das causas.
Lies Aprendidas
Os benefcios encontrados com a utilizao do Scrum e do
Pair Programming foram bons tanto do ponto de vista gerencial quanto tcnico. Problemas antes camuflados apareceram
por conta da visibilidade aumentada, fundamental para a
melhoria contnua.
Toda a equipe do projeto passou a se envolver mais durante
todo o ciclo. Antes da utilizao das metodologias geis, os
desenvolvedores apenas recebiam do analista de sistemas
o Plano de Implementao, que possua o local exato de
alterao do cdigo. Resumidamente, o desenvolvedor no
possua a oportunidade de dar opinies a respeito das solues, e o conhecimento ficava concentrado nos analistas.
A integrao entre a equipe de desenvolvimento e teste foi
bastante benfica. No era mais necessrio aguardar a liberao de um executvel para que a equipe de testes iniciasse
suas atividades. Neste novo formato de processo, logo que
uma implementao concluda, o teste iniciado e, caso
algum problema seja encontrado, a correo imediata.
Pessoas de outros departamentos passaram a frequentar
as reunies de planejamento e entrega como ouvintes. Isto
fez com que as interrupes aos analistas de sistemas e desenvolvedores para entenderem as funcionalidades fossem
diminudas.
Quanto s solicitaes de customizao, estas vm por
vrios canais, dependendo do tipo de ocorrncia (evolutiva, correo, customizao legal, etc.) e do cliente. Alguns
especialistas (que so os POs das equipes) so dedicados a
alguns clientes, independente do mdulo (utilizado para
M etod ologias geis
diviso das equipes). Considerando esses fatores, alm das

solicitaes da Sprint, havia gerentes cobrando correes de
Bugs, especialistas cobrando prioridade para as ocorrncias
de seus clientes, e mais cobranas por outros stakeholders.
Isso fazia com que o time perdesse o foco da Sprint, e o
ScrumMaster passasse a gerenciar priorizaes, trazendo
uma srie de problemas, como por exemplo, a no entrega
do que foi planejado para a iterao.
A disseminao do conhecimento aconteceu atravs da
tcnica de Pair Programming. Ela foi aplicada nas equipes
compostas apenas por novatos, porm lideradas por um
Analista de Sistemas com amplo conhecimento tcnico e
de negcio. Periodicamente era executada a troca dos pares,
sendo sempre um membro do time que tivesse adquirido
mais conhecimento com outro que tivesse adquirido menos
conhecimento. O resultado dessa aplicao foi uma curva
de aprendizado menor, comparando-se s experincias
anteriores, sem a utilizao desta tcnica.
encaminhada ao desenvolvimento. As definies iniciais

do WIP foram determinadas considerando a quantidade
de mudanas existente, por isso o valor 3 para a coluna
Selecionados, e a quantidade de colaboradores no Time de
acordo com sua funo.
Na coluna Backlog, o PO estaria vontade para disponibilizar as solicitaes, na ordem de prioridade. Na coluna
Selecionados, o PO dever disponibilizar as prximas solicitaes que devero ser implementadas. A separao das
colunas Backlog e Selecionados para que o Time mantenha
o foco. Dessa forma, o Time estaria vontade para realizar
as reunies de Planejamento, mesmo no existindo mais
Sprint. Essas solicitaes selecionadas seriam explicadas
pelo PO e, aps isto, a reunio tcnica aconteceria. Assim,
pretende-se manter a disseminao de conhecimento.
Proposta de adaptao do processo

Mesmo aps a implantao das prticas geis relatadas
anteriormente, algumas pessoas ainda sentiam necessidade
de novas adaptaes no processo, principalmente em funo do alto ndice de solicitaes de mudana por parte de
diversos clientes. Diante disto, a sugesto para tentativa de
melhoria de processo de desenvolvimento da empresa analisada ento manter algumas prticas do Scrum e utilizar
o Kanban por completo.
O que dever ser mantido do Scrum so as reunies de
planejamento, reunies dirias, reunies de entrega e retrospectiva, alm dos papis do Scrum Master e do PO. O
que dever ser rejeitado so as Sprints, o grfico Burndown
e as estimativas por complexidade, que utilizam o Planning
Poker.
A sugesto de retirada das iteraes vem da realidade de
que as equipes no conseguem entregar as Sprints conforme
acordado com o PO, porque solicitaes consideradas urgentes aparecem, deixando o time sobrecarregado e sem espao
para concluir o prometido. A negociao para troca das
solicitaes quase nunca acontece, pois estas, na maioria das
vezes, tiveram seus prazos postergados por diversas vezes.
O Scrum admite mudanas, porm no backlog do produto, e
no no backlog da Sprint. Apesar de oficialmente as releases
serem liberadas em um determinado dia da semana fixo,
podem haver outras liberaes durante a mesma semana, ou
mesmo atrasos. Alm disso, pode acontecer de nem todas as
equipes terem liberaes a fazer durante este perodo.
O quadro apresentado na Figura 3 foi proposto para uma
equipe com dois Analistas de Sistemas, seis Desenvolvedores e quatro Testadores.
Na Figura 3, o quadro possui duas linhas de fluxos. Uma
para o desenvolvimento e outra para a anlise de requisitos. Isto foi necessrio, pois para determinados tipos de
ocorrncias, o cliente exige uma Especificao de Requisitos e um Prottipo, para que seja validado, e s assim ser
Figura 3. Quadro Kanban como sugesto de utilizao na empresa analisada
A coluna Desenvolvimento foi dividida em duas partes:

Iniciado e Pronto, facilitando o entendimento do que foi
concludo ou no pelo desenvolvimento, para em seguida,
os responsveis pelos testes iniciarem suas atividades. Ao
concluir os testes, a solicitao estaria pronta. Este teste executado o teste unitrio. Existe ainda o teste de integrao
realizado em outro momento.
Para utilizao do fluxo de Anlise, estaro no Backlog
apenas aquelas solicitaes que necessitaro, antes do desenvolvimento, dos artefatos de Especificao de Requisitos
e/ou Prottipo, caso o cliente os requisite para validao.
Levando em considerao a no utilizao de iteraes, o
grfico Burndown perde o sentido. Neste caso, outro grfico
de acompanhamento, como o diagrama de Fluxo Cumulativo, poder ser utilizado.
Independente da existncia de iteraes, periodicamente
os releases precisam ser liberadas para os clientes. Dessa
maneira, se mantm a reunio de entrega para que a validao das solicitaes seja feita.
A sugesto de manter a reunio de Retrospectiva para que
as melhorias continuem sendo buscadas. Com o quadro Kanban, durante a execuo das atividades, os gargalos ficaro
mais visveis, j que o WIP estar funcionando de maneira
a bloquear o andamento das fases anteriores, at que possveis impedimentos sejam tratados nos passos seguintes.
31
2. Anderson, D. (2010) Kanban. Estados Unidos: Blue Hole Press.

3. Kniberg, H. (2007) Scrum e XP direto das Trincheiras. Estocolmo: C4Media Inc.
4. Schwaber, K.; Beedle, M. (2002) Agile Software Development with Scrum. New
Jersey: Prentice Hall.
5. SEI, Software Engineering Institute. (2010) Software Product Lines.
http://www.sei.cmu.edu/productlines/
6. Soares, M. (2004) Comparing Agile and Traditional Methodologies for Software
Development. Infocomp Journal. Year III, Vol. 2, pp. 8-13, ISSN 1807-4545.
7. VersionOne. (2010) State of Agile Development Survey Results.
http://www.versionone.com.

32
Feedback
eu
sobre e
s
A utilizao de mtodos geis em empresas de linhas de

produto pode funcionar bem. A capacidade da metodologia
atender um determinado fluxo de processo vai depender da
adaptabilidade da mesma em relao ao cenrio aplicado.
Apesar das implantaes do Scrum e do Pair Programming
no terem sido inseridas na empresa de forma correta, seja
por falta de treinamento adequado, ou mesmo por prticas
descartadas, aps algumas anlises, percebeu-se que o Scrum,
sem algumas modificaes ou sem a ajuda de outro mtodo,
no iria funcionar.
Sendo assim, dentre todos os mtodos estudados, a proposta
de incluso do Kanban aos processos dessa empresa, juntamente com adaptaes do Scrum aqui sugeridas, em princpio,
poder atender as lacunas existentes. Essas adaptaes propostas sero aplicadas e uma nova anlise ser realizada, com
foco na melhoria contnua do processo de desenvolvimento de
software baseado em linha de produto.
1. Ambler, S. (2008, 2010) Agile Survey.

http://www.agilemodeling.com/
D
s
Concluses
Referncias
edio
ta
Caso isso acontea, a etapa atingida negativamente ser de

fcil identificao, e seus problemas devero ser discutidos
na retrospectiva do time.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Modelagem de processos usando ARIS

Architecture of Integrated Information Systems
Wellington Moreira de Oliveira
Ronney Moreira de Castro
wellington.moreira@ifsudestemg.edu.br
ronneymc@gmail.com
Mestrando em Cincia da Computao

pela Universidade Federal de Viosa (UFV).
Especialista em Engenharia de Software e
Bacharel em Sistemas de Informao pelo
Centro de Ensino Superior de Juiz de Fora
(CES). Atualmente Professor/Pesquisador
do Departamento de Cincia da Computao do Instituto Federal de Educao,
Cincia e Tecnologia do Sudeste de Minas
Campus Rio Pomba. reas de interesse: Sistemas de Informao com foco em Infraestruturas de Dados Espaciais e Engenharia
de Software com foco em Processos.
Mestrando e Especialista em Cincia da

Computao pela Universidade Federal de
Viosa (UFV). Atua a mais de 13 anos no
mercado de informtica com desenvolvimento de software. Atualmente Analista
de Sistemas da Prefeitura de Juiz de Fora e
Professor do Curso de Sistemas de Informao do Instituto Metodista Granbery. reas
de Interesse: Engenharia de Software, Qualidade de Software, Processos de Desenvolvimento de Software.
Jos Luis Braga

zeluis@dpi.ufv.br
Ps-doutoramento em Tecnologias da Informao na University of Florida (1988-1999).

Doutor em Informtica-Departamento de
Informtica da PUC-Rio (1990). Mestre em
Cincias da Computao-Departamento de
Cincia da Computao da UFMG (1980).
Atualmente Professor Titular do Departamento de Informtica do Centro de Cincias
Exatas e Tecnolgicas da Universidade Federal de Viosa-MG. Atua na rea de Cincia da
Computao, com nfase em Engenharia de
Software e Sistemas de Informao. reas de
Interesse: Qualidade de Software com Foco
em Processos, Engenharia de Software Experimental, Engenharia de Software Apoiada por
Ontologias, Engenharia de Software Baseada
em Agentes, Sistemas de Apoio Deciso.
s empresas de hoje esto cada

vez mais voltando sua ateno
para os mercados emergentes
com o objetivo de conquistar clientes. A
qualidade de seus produtos deve ter um
grau elevado de aceitao e qualidade
e, para isso ser possvel, necessrio
possuir processos bem definidos e que
sejam seguidos por toda a corporao.
O Aris (Architecture of Integrated
Information Systems) uma plataforma completa de modelagem, controle e
execuo de processos, capaz de fornecer
uma base para qualquer empresa organizar, manter e inovar seus processos ao
longo do tempo. Neste artigo, primeiramente, ser apresentada uma viso
A modelagem de processos hoje o principal motor da organizao para melhoria contnua de seus
processos internos e externos. Neste contexto, o
objetivo deste artigo esclarecer os diversos aspectos e benefcios da modelagem e gerenciamento
de processos utilizando o ARIS (Architecture of Integrated Information Systems).

A modelagem de processos com ARIS pode ser
aplicada nos mais diversos ambientes corporativos, visto a aplicabilidade universal do gerenciamento de processos.
geral sobre o que processo e qual o seu

relacionamento com a indstria. Em seguida sero apresentados os conceitos de
modelagem e como utilizar a Plataforma
ARIS para este propsito.
Um pouco de histria
Na antiguidade, o homem descobriu
que era necessrio conviver em sociedade. Nesse momento da histria algumas
pessoas encontraram oportunidade para
um processo de comercializao de
produtos e servios com outros grupos.
33
Mais tarde as estruturas empresariais formais cresceram formando o grande sistema monetrio que conhecido hoje, onde
o objetivo principal o lucro. Isso demonstra que a finalidade
principal tanto dos proprietrios quanto dos empregados de
uma organizao a gerao do retorno financeiro em troca
de tempo e recursos financeiros investidos [2].
Cada tipo de negcio disponibiliza produtos ou servios
diferentes para seus clientes com o objetivo de gerar lucro em
forma de vendas e, alm disso, agregar um valor final que
pode ser criado de formas diferentes dependendo do tipo de
negcio. Um exemplo um lojista cujo principal ideal a entrega de produtos de qualidade para seu pblico alvo. Outro
exemplo do fabricante de veculos que consiste na produo
de diferentes tipos e modelos de carros para atender necessidades e desejos diferentes de seus clientes. Com o crescimento
da competio entre as empresas por diferentes mercados,
recursos e competncias, somente aquelas capazes de fornecer
valor para seus clientes podero sobreviver.
Henry Ford disse: O cliente pode ter o carro da cor que quiser,
contanto que seja preto [2]. Dessa forma, os clientes no poderiam expressar seus requisitos individuais, pois a cor era nica.
O principal objetivo de Ford era alcanar uma maior eficincia
em termos de tempo e custo usando o conceito de linha de produo ou linha de montagem repetindo continuamente uma
sequncia de tarefas. Atravs desse processo de decompor uma
grande tarefa em pequenas tarefas mensurveis, Ford reduziu
drasticamente o custo da produo. A cor preta possua uma
secagem mais rpida, com isso o valor era reduzido e o veculo
poderia ser vendido por um preo menor. Ideias semelhantes
podem ser associadas a Frederick Winslow Taylor com seu
Taylorismo [11] que continua influenciando organizaes at
os dias de hoje.
Praticamente tudo o que feito em negcios dirigido por
processos. At mesmo as pessoas tm processos em seu dia a
dia, mesmo que sejam totalmente ad-hoc (ler Nota 1). A ideia de
analisar e otimizar os processos foi transferida da indstria da
manufatura para outros setores como, por exemplo, o financeiro.
Tudo o que feito em uma organizao que possa gerar valor,
oferecendo produtos e servios, controlado por processos. Gerenciar esses processos implica em verificar e analisar detalhadamente atividades importantes e recursos da companhia, tais como
mercado, tarefas, pessoas, transaes financeiras, etc [8].
Nota 1. ad-hoc
Neste contexto, o termo ad-hoc se refere a ciclos de construo de software ou processos que
no foram devidamente projetados em funo da necessidade de atender rapidamente uma
determinada demanda.
Segundo [2], em meados dos anos 80 e 90, muitos processos

tradicionais passaram por uma transio devido abertura de
mercados globais e a quebra de barreiras tradicionais para comrcio. Essa situao gerou o Business Process Re-engineering
(BPR) como conceito de melhoria na eficincia e na eficcia de
processos atravs de documentao, anlise e mudana dos
processos de negcio.
34
Essa reengenharia de processos foi incorporada por AugustWilhelm Scheer, um professor alemo de administrao de
empresas e informaes de negcios da Saarland University, cuja
pesquisa concentrou-se em informao e gesto de processos
de negcios na indstria, servios e administrao. Ele ficou
conhecido por desenvolver uma arquitetura de sistemas de
informaes denominada ARIS (Architecture of Integrated Information Systems) [10]. Alm de incorporar esta nova concepo
de processos de negcios, August Scheer refinou e definiu sua
prpria metodologia de BPM (Business Process Management)
conhecida como ARIS Value Engineering. Esta metodologia
aplicvel a qualquer tipo de negcio e, juntamente com esta,
muitas ferramentas foram sendo incorporadas para dar suporte ao BPM. No caso deste artigo em particular, o foco ser a
aplicao dessa metodologia e ferramenta denominada ARIS
Platform para a modelagem de processos de software.
O ARIS uma arquitetura que foi criada em julho de 1984 pela
IDS Scheer, como uma resposta a uma necessidade de mudana
no foco na gerncia de negcios [22]. Na poca, a documentao
e o acompanhamento dos processos de negcio eram poucos
ou quase nulos. Todos os processos ficavam armazenados na
cabea de alguns gerentes/diretores e somente estes podiam
modific-los [9]. Quando uma empresa perdia um destes
funcionrios, toda ou boa parte do processo era perdida. Isto
acontecia porque os processos no eram documentados para
se tornarem um bem da empresa, ou seja, agregar valor a esta
empresa. Um exemplo de uma forma de perda pode ser descrito quando um funcionrio mudava de cargo e repassava o
processo pelo qual era responsvel para outro funcionrio. Na
maioria das vezes, os processos eram mal compreendidos pelo
novo funcionrio, porque no havia um padro de descrio
que pudesse ser adotado. Ele recebia as instrues e as interpretava de sua forma, sem um mtodo especfico determinado
pela organizao, e prosseguia assim moldando o seu prprio
processo. Consequentemente, esse fato impactava diretamente
na gesto de gastos e na qualidade dos produtos da empresa,
tornando-a menos competitiva no mercado.
Em 1992, a IDS Scheer firmou uma parceria com a SAP e, neste
mesmo ano, foi apresentada a primeira ferramenta de software
para analisar e descrever processos de negcios: a ARIS Toolset.
J em 2006, outra parceria foi firmada com a empresa Oracle e,
a partir da, a plataforma ARIS passou a oferecer o midleware
Oracle Fusion [23].
Alm de suas prprias ferramentas, o ARIS fornece um framework conhecido como ARIS House. Este framework conta com
cinco vises, sendo quatro estticas: Viso Organizacional,
Viso de Dados, Viso de Funes e Viso de Produtos; e uma
dinmica: Viso de Controle [1].
Business Process Management (BPM)

As empresas so organizadas em estruturas que correspondem s suas funes organizacionais, nas quais as pessoas s
tm a noo de suas responsabilidades limitadas ao universo
de resultados de seu departamento. Segundo [16], a eficcia
e a eficincia dos processos de negcios internos e externos
Engenharia de Software Magazine - Modelagem de processos usando ARIS
processo
desempenham um papel importante na determinao do sucesso econmico e, dessa forma, ao aplicar o BPM, a empresa
estar implantando uma gesto com foco na abordagem de
processos possibilitando uma integrao organizacional [16].
O Business Process Management (BPM) est longe de ser um
conceito novo. Ele uma abordagem de gesto que surgiu no
incio de 1990. As primeiras discusses estavam fortemente
centralizadas em aspectos organizacionais de curto prazo
(BPR). O objetivo era obter mudanas rpidas e radicais nos
processos de negcios baseado em um projeto. Atualmente,
uma abordagem integrada e contnua que trata conjuntamente
de questes organizacionais e tecnolgicas.
O BPM representa um processo composto de vrias fases
sendo elas: estratgia, definio, implementao e controle
de processos. O objetivo implementar essa tcnica em uma
empresa, tanto em termos organizacionais quanto em termos
tecnolgicos. O movimento de ser uma organizao funcional para ser uma organizao orientada para o processo est
diretamente associado com o BPM. Da mesma forma, existe
uma srie de questes que esto diretamente relacionadas ao
Business Process Management. Essas
incluem a gesto de qualidade introduzida pela norma ISO 9000-2002 que orientada
para o processo e exige um sistema integrado de gesto e
planejamento de necessidades de pessoal, que ser capaz de
oferecer apenas uma viso incompleta sem a utilizao do
BPM. A padronizao de processos, sistemas e equipamentos
de trabalho em empresas um exemplo tpico com foco a longo
prazo que implica em um enorme impacto sobre a eficincia.
Em termos de TI, o seu conceito se torna indispensvel.
Os sistemas ERP (Enterprise Resource Planning) ou SIGE (Sistemas Integrados de Gesto Empresarial) permitem s empresas
atingir um nvel mximo de integrao e flexibilidade somente
se o Business Process Management estiver implantado. Alm
disso, o processo de terceirizao vem se destacando muito
ultimamente. Para isso, necessrio que as empresas tenham
um nvel de padronizao definido para contratar estes servios. Ser impossvel tomar decises a este nvel sem possuir o
processo implantado na empresa [2] [8] [16].
Os principais objetivos do BPM so a satisfao do cliente e a
melhoria da produtividade e competitividade. Us-lo significa
aplicar mtodos e tcnicas para modelar, implantar, monitorar
e melhorar continuamente os processos com o objetivo de
alcanar agilidade operacional, maior confiabilidade, reduo
dos custos, maior capacidade de resposta s mudanas requisitadas pelos clientes internos e externos e, principalmente, o
alinhamento aos objetivos empresariais.
ARIS: Apresentao Contextual

A arquitetura ARIS alinhada ao BPM e foi construda em
trs nveis: estratgia, especificao (composta de Design,
Otimizao e Controle) e execuo, como pode ser visto na
Figura 1. No nvel de estratgia, aspectos como a verificao,
planejamento e especificao da arquitetura dos processos so
definidos (o processo pode ser entendido como a viso dos
processos da empresa). O prximo passo a especificao,
onde todos os conceitos elaborados so transformados em

modelos (como diagramas e simulaes). O ltimo passo
utilizar estes modelos no nvel de execuo, no qual tudo o que
foi construdo ser colocado em prtica. Esta execuo dever
ser monitorada e um feedback ser importante para o controle
das atividades [14].
Figura 1. Modelo em trs camadas (Fonte: Aris for DoDAF)
Princpios bsicos de modelagem

Antes de se iniciar um processo de modelagem, de suma
importncia que esteja bem claro o porqu se est modelando.
Segundo [1], muitas pessoas iniciam uma modelagem sem ao
menos saber para que o modelo ser utilizado, quem ir utilizlo, que tipo de informao ser requisitada e qual o formato
necessrio. Deve-se considerar que o modelo no deve ser uma
rplica do mundo real, mas sim uma representao, um ponto
de vista. Um dos pontos fortes do ARIS sua capacidade de
produzir diferentes pontos de vista com dados (informaes)
comuns. Os objetivos da modelagem podem mudar durante o
tempo de vida de um projeto. Isso se deve ao fato da descoberta
de novos requisitos, novas oportunidades. No se pode presumir que um determinado modelo criado para uma especificao
atender ou ser adequado a outros objetivos [13].
Para [17], importante que sejam considerados dois conselhos
antes de se comear um processo de modelagem. Um deles
considerar seus usurios, ou seja, documentar os objetivos de
acordo com seus stakeholders (ler Nota 2) e o outro refere-se a
seis fatores conhecidos por 6Ws ou: Why, Who, What, When,
Where and HoW are you modeling?
Nota 2. Stakeholders
Stakeholder em portugus, parte interessada: Conceito utilizado por muitas reas, tais como
administrao e TI, para definir qualquer pessoa ou organizao que tenha interesse ou seja
afetada pelo projeto.
Why are you modeling? (Porque voc vai modelar?): Para documentar os processos organizacionais, capturar informaes
para melhoria do processo, apoiar a reestruturao do negcio,
fornecer requisitos para o desenvolvimento de TI, possibilitar
o lanamento de novos produtos, etc.
35
Who are the models for? (Para quem ser o modelo?): Usurios
do negcio, arquitetos de processo, usurios do processo,
profissionais de TI envolvidos no processo, etc.
What are you modeling? (O que voc est modelando?): Toda
a Organizao (Empresa), um processo de um departamento
especfico, processos envolvidos em atividades de melhorias,
processos que sero automatizados, etc.
When will the models be relevant? (Quando os modelos sero
relevantes?): Como so (os processos como esto agora),
Sero (considerando os processos no futuro). O tempo
importante para seu modelo? A modelagem pode durar alguns
dias, semanas ou at mesmo anos para ser feita.
Where will the models be used? (Onde seus modelos podero
ser utilizados?): Seus modelos sero publicados na Internet?
Sero utilizados para gerar documentao? Utilizados para
definir interfaces (regras) para os fornecedores (empresas
terceirizadas, por exemplo)?
How will you go about modeling? (Como ser a modelagem?):
Usando o ARIS (Quais ferramentas da plataforma, quais objetos, quais modelos), usando notaes de modelagem padro,
tais como BPMN (Business Process Modeling Notation) ou UML
(Unifield Modeling Language), seguindo padres especificados
prprios da empresa, etc.
O que ARIS?
O ARIS evoluiu de uma busca por melhoria contnua em
processos. Assim, o seu principal foco o Business Process
Management. Para tanto, o ARIS se cerca de um Mtodo de
Modelagem. Esse mtodo dividido em duas partes: as Tcnicas de Modelagem e os Mecanismos. Dentro das tcnicas
de modelagem tem-se o procedimento de modelagem que o
ARIS Value Engineering e as Linguagens de Modelagem que so
compostas pelas mais diversas formas de representao de modelos de processo como BPMN, BPEL, EPC, UML, etc [25].
O mtodo de modelagem ARIS se apia dentro de ciclo de
vida BPM com quatro plataformas bem definidas:
Plataforma de Estratgia;
Plataforma de Projeto;
Plataforma de Implementao;
Plataforma de Controle.
Plataforma ARIS e a modelagem de processos

A plataforma ARIS composta por vrias ferramentas que
fornecem apoio e suporte ao planejamento, modelagem e execuo do BPM. Estas ferramentas esto distribudas dentro das
vrias fases que compem o ciclo de vida BPM, como pode ser
visualizado na Figura 2: Process Strategy, Process Design, Process
Implementation, Process Controlling e Change Managment [16].
Esse modelo de ciclo de vida tem como eixo o Change Management e o Continuous Improvement que tratam do gerenciamento
de mudanas e dos melhoramentos contnuos que fazem a
roda girar com o mnimo de atrito, ou seja, com a maior eficincia possvel buscando uma realizao eficaz dos processos
de negcios. Na parte inferior observa-se o rtulo Compliance
Process que reflete a consonncia do andamento dos processos
36
com a sua transparncia na gerncia e controle de riscos e na

qualidade de seus processos [16].
O ARIS suporta variados padres de modelagem de processos, com suas linguagens e notaes que descrevem o
significado de seus elementos. Segue uma relao de suporte e
compatibilidade que a plataforma ARIS possui com os diversos
padres de modelagem e seu significado [25]:
BPEL: Business Process Execution Language uma notao tcnica usada para descrever modelos de processos executveis e
orientados integrao. A plataforma ARIS conta com a ferramenta ARIS SOA Architect & Designer para modelar e tambm
exportar processos seguindo a padronizao do BPEL.
BPMN: Business Process Modeling Notation uma notao
padronizada para a modelagem de processos. A plataforma
ARIS disponibiliza as ferramentas ARIS Business Archictect &
Designer, ARIS IT Architect & Designer, ARIS SOA Architect &
Designer e ARIS Business Architect for SAP para a manipulao
de modelos BPMN na sua ltima verso 2.0.
EPC: Event Driven Process Chains um conjunto de atividades
ou tarefas (processos) inter-relacionadas e consumidoras e/ou
geradoras de determinadas aes (eventos) que tem por finalidade o cumprimento de um objetivo especfico. A plataforma
ARIS d suporte a esta representao de processos atravs das
ferramentas ARIS Business Architect & Designer, ARIS IT Architect & Designer, ARIS SOA Architect & Designer, ARIS Process
Governance e ARIS Business Architect for SAP.
UML: Unified Modeling Language um padro para descrio
de modelos em projetos de software. A UML est integrada
s ferramentas ARIS UML Designer e ARIS SOA Architect &
Designer que fazem parte da plataforma ARIS.
WSDL: Web Services Description Language padroniza a descrio de interfaces para Web Services. Com a ferramenta ARIS
SOA Architect & Designer possvel exibir a WSDL graficamente
e tambm import-la ou export-la.
XPDL: XML Process Definition Language uma notao tcnica padronizada que utiliza o XML para definir processos
que podem ser realizados por Web Services. Com ARIS SOA
Architect & Designer possvel exportar modelos de processos
para a linguagem do XPDL.
XSD: XML Schema Definition uma padro para descrever a
troca de dados entre Web Services. A plataforma ARIS disponibiliza o ARIS SOA Architect & Designer para importar, exportar
e representar graficamente o XSD.
Alm de toda a estrutura que o ARIS entrega atravs de sua
plataforma, suportada por inmeras ferramentas, padres de
modelagem e pela definio de seu ciclo de vida BPM, tambm
conta com um framework conhecido como ARIS House (assim
denominado pela analogia ao formato de uma casa atravs da
disposio de seus elementos). Esse framework integra quatro
vises estticas: Organization View, Data View, Function View
e Product/Service View. Essas vises estticas so interligadas
atravs de uma viso dinmica denominada Control View.
Na Figura 3 observa-se a disposio de cada uma das vises
estticas sendo interligadas pela viso dinmica:
processo
Product/Service View: Estrutura todas as entradas e sadas

materiais e no materiais que so trazidas ou executadas por
processos de negcio. O mtodo de modelagem a ser utilizado
so os Diagramas de produto.
Data View: So descritas as informaes dos objetos e seus
atributos, bem como as relaes entre eles. Os eventos tambm
so atribudos exibio de dados. O mtodo de modelagem
a ser utilizado o MER (Modelo de entidade relacionamento)
ou UML (Unified Modeling Language).
Function View: So descritas as transaes que transformam
performances e os relacionamentos estticos entre elas. Termos
como funo, transao e atividade so utilizados como
sinnimos. Os sistemas aplicativos tambm esto includos na
function view, porque determinam as regras de processamento
do computador com suporte para as atividades. O mtodo de
modelagem a ser utilizado o Diagrama em Forma de rvore
(Function Tree).
Organization View: So descritos os e
lementos organizacionais e seus relacionamentos. Alm dos recursos humanos,
os recursos operacionais e hardware de computador tambm
so atribudos a este ponto de vista. O mtodo de modelagem
a ser utilizado so os Organogramas.
Control View: Exibe conexes entre os objetos de dados, funes, desempenho, vises de organizao e fluxo cronolgico
de processos. O mtodo de modelagem a ser utilizado poder
ser o EPC (Event Driven Process Chain) ou o eEPC (Extended
Event Driven Process Chain).
Figura 2. Plataforma Aris (Fonte: Aris Value Engineering)
Um exemplo de modelo usando ARIS Express

A IDS Scheer disponibiliza uma ferramenta gratuita para
modelagem de processos de negcios, conhecida como ARIS
Express [20]. Com ela possvel realizar no somente a modelagem de processos, mas tambm a criao de organogramas,
modelos de dados, definio de modelos da infraestrutura
de TI, diagramas com viso macro de processos e sistemas,
alm de diagramas de aplicao geral, em que o usurio pode
atribuir o significado de cada item que o compe. Para a modelagem de processos, que o foco principal deste trabalho, o
ARIS Express permite a utilizao de duas linguagens grficas
amplamente conhecidas e difundidas nos ambientes corporativos: a BPMN e o EPC.
O estudo de caso aqui apresentado considera uma livraria
online, no qual um cliente acessa o site da livraria, escolhe seus
produtos (livros), faz opo de tipo de pagamento (carto ou
boleto) e finaliza a operao, tendo seu pedido futuramente
entregue no local escolhido por ele. Para isso, foi utilizado o
eEPC (Extended Event Driven Process Chain), que uma verso
estendida do EPC, com smbolos para definir pessoas ou papis, unidades organizacionais, informaes ou dados, produtos ou servios e objetivos. Segue uma relao e especificao
dos smbolos do eEPC (ver Figura 4):
Unidades Organizacionais: representam departamentos
envolvidos em um processo;
Pessoas: representam pessoas ou papis envolvidos em um
processo;
Figura 3. Aris House (Fonte: Aris for DoDAF)
Informao ou dados: representam informao utilizada ou

gerada em um processo;
Produtos ou servios: so gerados ou consumidos pelo
processo;
Objetivos: representam o motivo da realizao de um processo ou tarefa.
As ideias envolvidas no EPC resumem, de certa forma, as
principais caractersticas do ARIS. Assim, esta linguagem
grfica de modelagem de processos foi preferida para a demonstrao de um exemplo de aplicao de uma modelagem
de processos utilizando o ARIS Express. A Figura 5 exibe o
diagrama deste exemplo construdo no ARIS Express, com a
notao do eEPC.
O ARIS Express gera vrios tipos de modelos estticos para o
gerenciamento de negcios. Dessa forma, no possvel realizar
uma simulao do processo modelado utilizando esta ferramenta.
37
A simulao de extrema relevncia para o refinamento sucessivo

dos processos, pois atravs da mesma, possvel corrigir vrios
problemas e executar alteraes antes do processo entrar em
produo. Para a realizao desta importante funcionalidade,
a plataforma ARIS disponibiliza a ferramenta ARIS Architect
Designer que disponibilizada em uma verso paga.
Consideraes finais
Figura 4. Componentes e smbolos utilizados no EPC e no eEPC,
respectivamente
Figura 5. Modelagem de processos de negcio de uma livraria online

usando notao eEPC
38
Este artigo apresentou uma viso mais abrangente e formal

de como se modelar processos de negcios sobre a plataforma
ARIS, atentando para um dos desafios perenes da engenharia
que desenvolver produtos de alta qualidade e valor agregado
com o menor custo possvel.
A modelagem de processos de negcio deve ser considerada
como um elemento fundamental dentro de uma organizao.
No mundo atual, a concorrncia imensa e somente empresas
que estejam alinhadas ao mesmo podero sobreviver. Tais
empresas devem possuir processos bem estruturados e organizados para fornecer produtos e servios de qualidade a seus
consumidores.
O grande problema enfrentado pela maioria das organizaes
que desejam implantar um mtodo ou padro para modelagem
de processos estabelecer qual linguagem e/ou ferramenta
utilizar. Hoje, tm-se vrias linguagens, tais como BPMN, EPC,
UML, entre outras, que podem ser utilizadas para atender
objetivos diversos. Alm disso, a gama de ferramentas para
modelagem de processos bem grande. A literatura acadmica
evidencia muito o processo de modelagem em si, no dando
nfase nas linguagens e ferramentas, o que sugere, na prtica,
que as organizaes devem estar confusas ou mesmo perdidas
para orientar seus esforos em modelagem de processos.
Atualmente, o valor que o BPM agrega a corporao e aos
seus produtos indiscutvel. Com o ARIS possvel modelar
no s processo, mas tambm dados, organizaes, sistemas,
informaes, produtos, conhecimento, objetivos do negcio e
fluxos de informao. Porm, como toda ferramenta, possui
suas vantagens e desvantagens:
Algumas vantagens para se usar ARIS:
uma ferramenta permanente e de disponibilidade global;
uma ferramenta intuitiva e de alto desempenho;
O processo de gesto da ferramenta pode ser facilmente adaptado de forma que possa atender s normas corporativas das
empresas e de todas as funcionalidades de modelagem para o
grupo-alvo de representao especfica;
Possui assistentes e uma srie de opes de anlise como, por
exemplo, anlises de impacto;
Capacidade de desenvolver completamente um modelo
distribudo;
Possui boas ferramentas para navegao entre modelos;
Suporta uma abordagem hierrquica para decomposio
funcional;
Gera modelo para criao de novos modelos e pontos de
vista;
Suporta variveis e unio de modelos;
Fornece animao e simulao de processos;
processo

D
s
No basta ter uma ferramenta eficiente, mas a cooperao

entre os funcionrios vital para qualquer projeto. O contedo deve estar centralizado e disponibilizado para todos
dentro da organizao, permitindo o entendimento comum
e um desenvolvimento/normalizao das tarefas. O ARIS
fornece componentes poderosos e dinmicos para publicao
permitindo o acesso aos dados atravs da Intranet da Empresa,
ou seja, suporte Web. Alm disso, ele possibilita fornecer aos
usurios permisses diferenciadas provendo a alguns, por
exemplo, a alterao de informaes, enquanto outros somente
a visualizao das informaes.
Feedback
eu
Referncias
1. DAVIS, Rob. ARIS Design Platform: Advanced Process Modelling and Administration. Springer-Verlag,
London, 2008.
14. Aris for Dodaf White Paper Disponvel em: http://www.aris-portal.ru/docs/ARIS_for_DoDAF_White_

Paper.pdf
2. DAVIS, Rob; BRABNDER, Eric. Aris design platform. Getting Started with BPM. Springer-Verlag, London, 2007.
15.Aris Solution for Enterprise Architecture Management - Disponvel em:http://www.ids-scheer.de/set/2238/

EA%20expert%20paper.pdf
3. DAVIS, Rob. Business Process Modeling with ARIS: A Pratical Guide. Springer-Verlag, London, 2001.
4. KARAGIANNIS, Dimitris and KHN, Harald. Metamodelling Platform. Springer-Verlag,Viena, 2002.
5. KELLNER, M. (1999). Software process simulation modeling: Why? What? How? Journal of Systems and
Software, 46(2-3), 91-105. doi: 10.1016/S0164-1212(99)00003-5.
6. RYAN, J., & HEAVEY, C. (2006). Process modeling for simulation. Computers in Industry, 57(5), 437-450. doi:
10.1016/j.compind.2006.02.002.
16. Aris Value Engineering Concept WhitePaper Junho 2005 - Disponvel em: http://www.sdn.sap.com/
irj/scn/go/portal/prtroot/docs/library/uuid/eae8e311-0b01-0010-0f9c-8d26e2714a91?QuickLink=index&ov
erridelayout=true
17. http://www.ariscommunity.com/users/rob-davis/2010-06-22-dont-leap-modelling-think-about-yourcustomers-first
18. http://www.ariscommunity.com
7. SPIEKERMANN, S. (2006). Introduction into ARIS : System Analysis and System Views Institute of Information
Systems. Information Systems, 1-21.
8. SCHEER W.A., KRUPPKE H., JOST W., KINDERMANN H., Agility by ARIS Business Process Management. Berlin:
Springer-Verlag, 2006.
19. http://www.omg.org
20. http://www.ariscommunity.com/aris-express/download
21. http://www.sap.com
9. SCHEER W.A., ABOLHASSAN F., KIRCHMER M., Business Process Change Management ARIS in Practice. Berlin:
Springer-Verlag: 2003.
22. http://www.ids-scheer.it/set/6473/9-monthreport_2004_en.pdf
10. SCHEER, W.A., JOST W., HELGE H., KRONZ, A., Corporate Performance Management: ARIS in practice. Berlin:
Springer-Verlag, 2006.
23. IDS Sheer Corporate Factbook. Disponvel em: http://www.ids-scheer.de/set/408/BR_210x297_

Factbook_100920_en.pdf
11.TAYLOR,W., 1960. Princpios de Administrao Cientfica. So Paulo: Atlas.
24. SOA Governance for Oracle. Disponvel em: http://www.soa.com/solutions/oracle/ soa_governance_for_

oracle/
12. Engineering-, A. V. (2005). Business process management. Waves of efficiency. Health management
technology, 26(2), 46, 48. Disponvel em: http://www.ncbi.nlm.nih.gov/pubmed/20218073
13. Aris Academy - Before you start modelling Disponvel em http://cdn.ariscommunity.com/aris_online_
academy/before_start_modelling2/rebdnesz/player.html
25. Modeling Standards Supported by ARIS. Disponvel em: http://www.softwareag. com/br/products/aris_

platform/modeling/default.asp
26.Modelagem de Processos de Negcio ARIS & Event Driven Process Chain (EPC). Disponvel em: http://wiki.
xexeo.org/tiki-download_file.php?fileId=226
39
sobre e
s
Algumas desvantagens para se usar ARIS:

O ARIS permite que objetos novos sejam inseridos com formas distintas dos que esto presentes na ferramenta, porm
com algumas limitaes, ou seja, permite somente a substituio de um smbolo por outro, mas no permite alteraes de
suas propriedades (regras de conexo, por exemplo);
Em alguns casos, a qualidade visual do modelo representado
bastante inferior aos representados por outras ferramentas;
No possvel exportar toda a informao gerada na Plataforma, dessa maneira o ARIS possui um padro nico e
exclusivo.

No mundo todo, mais de 7500 companhias adotaram o ARIS
como padro para modelagem de seus processos. Entre essas
companhias pode-se citar: AB Volvo, Audi, Avon, BASF, Bayer,
Carrefour, Epson, Fujitsu, Hewlett-Packard, Hitachi, IBM, Japan
Airlines, Lufthansa, Mitsubishi, Nestl Deutschland, Peugeot, Philip
Morris, Philips, PUMA, SAP, hyssenKrupp, Vodafone D2, Volkswagen, Wella, Xerox, entre outras.
O ARIS pode ser aplicado a:
Modelagem, anlise e otimizao de processos de negcio;
Implementao de solues SAP;
Definio de arquiteturas de TI (arquiteturas empresariais);
Construo de arquiteturas orientadas a servio (SOA);

Modelagem e gerenciamento de regras de negcio;
Criao de sistemas de governana, riscos e de conformidade
para empresas em geral;
Implementao de inteligncia de processos e gerenciamento
de desempenho.
edio
ta
Suporta os objetivos de negcio, medidas e Balanced

Scorecard.
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres Parte 11

Substituir cdigo de tipo por classe, limitar instanciao com singleton e
introduzir objeto nulo
Aborda o tema refatorao para padres com o objetivo de mostrar como o desenvolvedor pode uslo para melhorar o cdigo-fonte de suas aplicaes.
Para que serve?
Jacimar Fernandes Tavares

jacimar.tavares@studentpartners.com.br
Bacharel em Cincia da Computao FAGOC

- Faculdade Governador Ozanam Coelho,
Microsoft Student Partners.

maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,

Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informao do Centro de Ensino Superior
de Juiz de Fora e da Faculdade Metodista
Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de
Software Magazine.
40
elhorar o projeto de cdigo

existente um dos objetivos
das tcnicas de refatorao
para padres. Sabe-se tambm que melhorar o projeto existente no implica
apenas em implementar padres de
projeto e tornar o cdigo reutilizvel.
Aumentar a segurana de tal cdigo
tambm contribuir para uma melhoria
do projeto de cdigo existente. No ter a
segurana de que um dado de um tipo
especfico foi ou no modificado pode
ser um problema quando se precisa ter
certeza de que o dado no foi alterado
antes de ser requisitado.
Melhorar o projeto de cdigo existente
tambm est relacionado necessidade
de melhorar o desempenho do sistema
atravs de modificaes no cdigo.
Engenharia de Software Magazine - Refatorao para Padres Parte 11
Para prover conhecimento ao desenvolvedor sobre

refatorao para padres e demonstrar atravs de
exemplos prticos a aplicao das tcnicas de refatorao para padres Substituir Cdigo de Tipo por
Classe, Limitar Instanciao com Singleton e Introduzir Objeto Nulo.

O tema se torna fundamental para desenvolvedores que j esto familiarizados com padres de
projeto e j os implementam em seus softwares
e que querem saber mais sobre refatorao para
padres, conhecendo os benefcios que sua utilizao traz.
Um exemplo pode ser uma classe

com vrias instncias em memria,
prejudicando o desempenho. Limitar as
instncias para apenas uma contribui no
sentido de liberar memria e aumentar
o desempenho.
Desenvolvimento
Em outro cenrio, melhorar o projeto de cdigo existente

pode estar relacionado remoo de cdigo duplicado. Centralizar cdigo que verifica se valores nulos foram atribudos
a objetos contribui para a reduo de cdigo que normalmente
ficaria espalhado por pontos onde se fazem necessrias tais
verificaes.
Nesse sentido, o objetivo deste artigo apresentar a tcnica
de refatorao para padres Substituir Cdigo de Tipo por
Classe como alternativa para uma melhoria do projeto de
cdigo existente em relao a tipos, alm das tcnicas de refatorao para padres Limitar Instanciao com Singleton, que
tem como objetivo implementar o padro de projeto Singleton,
e Introduzir Objeto Nulo, responsvel pela implementao do
padro de projeto Objeto Nulo. As tcnicas de refatorao para
padres citadas implicam na necessidade de aprendizagem das
tcnicas de refatorao Extrair Classe, Extrair Subclasse e Encapsular Atributo (ver Nota 1) e tambm das teorias referentes
aos padres de projeto Objeto Nulo, que ser apresentado, e
Singleton, j abordado em artigos anteriores.
Refatorao Encapsular Atributo

Esta refatorao pertencente ao grupo de refatoraes classificadas como Organizando Dados.
Nome da refatorao: O nome original da refatorao
Encapsular Campo, mas citada nas tcnicas de refatorao
para padres como Encapsular Atributo.
Resumo: Campos pblicos devem ter seus moderadores alterados para privados e mtodos de acesso (gets e sets) devem
ser criados para possibilitar o acesso a esses campos.
Motivao: Usa-se esta refatorao para permitir que campos
(ou atributos) de uma classe passem a ter mtodos de acesso,
permitindo assim que o encapsulamento dos dados seja mantido, o que um dos princpios da orientao a objetos.
Mecnica: Os passos que sero descritos podem sofrer variaes em algumas linguagens, portanto sero mostrados os
passos referentes s linguagens C# e Java.
Crie mtodos get e set para os atributos que no possuem.
Busque pelo cdigo fonte referncias a esses atributos e
modifique-os para que, a partir desse momento, passem a
referenciar os mtodos de acesso, e no mais os atributos. Em
Java, deve-se verificar se o mtodo a ser usado o get (onde
h referencias ao valor do atributo) ou o set (onde se altera o
valor do atributo).
Execute os testes e certifique-se que tudo est correto, e ento
altere os modificadores de acesso dos atributos para private.
Padro de projeto Objeto Nulo

Nome do padro de projeto: Objeto Nulo. Pertencente ao
conjunto dos padres de projeto classificados como Padres
Estruturais.
O problema: Em algumas aplicaes comum ver a escrita
de cdigo com lgica condicional a fim de verificar se uma
varivel no nula para ento uma tarefa ser executada. Esse
tipo de verificao em alguns momentos muito til, pois evita
que operaes sejam realizadas com nulos.
Nota 1. Refatoraes apresentadas em outros artigos

As tcnicas de refatorao Extrair Classe e Extrair Subclasse j foram apresentadas em outras
edies da Engenharia de Software Magazine.
O padro de projeto Objeto Nulo permite a criao de um

objeto que utilizado para substituir a lgica de verificao
de nulos.
As consequncias: O uso desse padro de projeto evita a
duplicao de cdigo para verificao de nulos na aplicao,
tornando o cdigo mais simples e manutenvel.
A partir deste momento, visto as teorias que envolvem o
processo de refatorar para padres deste artigo, sero apresentadas as tcnicas Substituir cdigo de Tipo por Classe, Limitar
Instanciao com Singleton e Introduzir Objeto Nulo.
Refatorao para padres Substituir Cdigo de Tipo

por Classe
Resumo: Atributos de tipos primitivos podem ser inseguros
quando se atribui algum valor a eles. Trocam-se os tipos primitivos por instncias de uma classe.
Motivao: Dado que tipos primitivos so passveis de erros, no sentido de permitir atribuies invlidas, essa tcnica
de refatorao para padres proporciona a definio de um
mecanismo onde os atributos de tipos inseguros e passveis
de erro, como strings, sero substitudos por tipos de classes,
evitando que atribuies invlidas sejam feitas a eles, visto
que a atribuio ficaria controlada pela classe fornecedora do
novo tipo mediante as suas verificaes.
Vantagens: Permite a definio de um mecanismo que evita
atribuies e comparaes invlidas.
Desvantagens: Leva a escrita de mais cdigo do que normalmente seria necessrio para tipos primitivos.
Mecnica:
1. Buscando por um atributo do tipo primitivo que se deseja
substituir, aplica-se a refatorao Encapsular Atributo, caso
necessrio.
2. Cria-se uma classe que ser a responsvel por substituir o
atributo do tipo primitivo por uma instncia, certificando para
que seu nome corresponda ao atributo que ser substitudo.
3. Para cada atributo encontrado no passo 1, definem-se atributos iguais na classe criada no passo 2, sendo eles constantes.
4. Na classe que contm o atributo encontrado no passo 1,
declara-se um atributo do tipo da classe criada no passo 2 e
um mtodo que altera seu valor.
5. Buscando por trechos onde o atributo encontrado no passo 1 recebe dados, define-se um mecanismo para atribuir o
valor correspondente ao atributo primitivo na classe criada
no passo 2.
6. Os pontos no cdigo onde o atributo primitivo usado
devem ser substitudos pelo seu correspondente na classe
criada no passo 2. Isto talvez implique em fazer modificaes
na classe criada no passo 2.
7. Apagam-se as definies relacionadas ao atributo
inseguro.
41
8. Finalizando, substitui-se o restante do cdigo que manipula

o atributo primitivo por seu correspondente na classe criada
no passo 2.
Exemplo: O exemplo a ser usado neste artigo mostra uma
classe onde o atributo acesso o atributo identificado como
instvel, e que ser o alvo desta refatorao para padres. A
Listagem 1 mostra a classe que ser trabalhada.
Para o atributo do tipo String chamado acesso, aplica-se a
refatorao Encapsular Atributo. O passo 2 sugere a definio
de uma classe que ser utilizada para substituir o atributo
primitivo. A Listagem 2 mostra a definio da classe.
Listagem 1. Classe StatusAcesso
01. public class StatusAcesso

02. {
03. private String acesso;
04. private Boolean estado;
05.
06.
07.
08.
private String Aberto = Aberto;

private String Fechado = Fechado;
private String Ocioso = Ocioso;
private String Bloqueado = Bloqueado;
09. public String VerificarAcesso()

10. {
11. if(acesso.Equals(Aberto))
12. {
13.
estado = false;
14.
acesso = Fechado;
15. }
16. else if(acesso.Equals(Fechado))
17. {
18.
estado = true;
19.
acesso = Aberto;
20. }
21. else if(acesso.Equals(Ocioso))
22. {
23.
estado = true;
24.
acesso = Aberto;
25. }
26. else if(acesso.Equals(Bloqueado))
27. {
28.
estado = true;
29.
acesso = Aberto;
30. }
31. return acesso;
32. }
33. }
Listagem 2. Classe Acesso
01. public class Acesso

02. {
03. }

02. {
03. private readonly String Aberto = Aberto;
04. private readonly String Fechado = Fechado;
05. private readonly String Ocioso = Ocioso;
06. private readonly String Bloqueado = Bloqueado;
07. }
42
O passo 3 sugere a definio de atributos idnticos aos

do tipo primitivo na classe Acesso. A Listagem 3 mostra o
resultado.
O passo 4 envolve a declarao de um atributo da classe de
acesso dentro da classe StatusAcesso. A Listagem 4, linha 9,
mostra a concluso deste passo.
O passo 5 envolve a criao de um mecanismo que viabilize a
atribuio realizada ao atributo primitivo acesso, linhas 20, 25,
30 e 35 da Listagem 4, agora ao seu correspondente na classe
Acesso. Essa ao acompanha mudanas na classe Acesso, o
que sugere o passo 6. A Listagem 5 mostra as mudanas na
classe Acesso, enquanto a Listagem 6 mostra as mudanas
realizadas na classe StatusAcesso para suprir as necessidades
do passo 5.
Analisando a classe StatusAcesso (Listagem 5), pode-se ver
que existem dois mtodos AlterarAcesso, sendo que o segundo
refere-se s mudanas sugeridas pelo passo 5, ou seja, agora
a classe StatusAcesso da Listagem 5, atravs do segundo mtodo AlterarAcesso, faz referncia ao objeto da classe Acesso,

02. {
05.
06.
07.
08.

09. private Acesso objAcessoSeguro;

10. private String AlterarAcesso(String tipo)
11. {
12. this.acesso = tipo;
13. return acesso;
14. }
16. {
17. if (acesso.Equals(Aberto))
18. {
19.
estado = false;
20.
AlterarAcesso(Fechado);
21. }
22. else if (acesso.Equals(Fechado))
23. {
24.
estado = true;
25.
AlterarAcesso(Aberto);
26. }
27. else if (acesso.Equals(Ocioso))
28. {
29.
estado = true;
30.
31. }
32. else if (acesso.Equals(Bloqueado))
33. {
34.
estado = true;
35.
36. }
37. return acesso;
38. }
39. }
Desenvolvimento
declarado na linha 9. J na Listagem 6, as mudanas podem

ser vistas na criao do mtodo construtor da classe Acesso,
linhas 8 a 11, que permite que o atributo nome (linha 7) receba
um valor.
Neste ponto, o tipo primitivo j pode ser removido. Seguindo
esta refatorao para padres, os passos 7 e 8 sugerem modificaes na classe StatusAcesso, removendo todas as declaraes relacionadas ao atributo primitivo, deixando apenas as
definies que trabalham com os atributos da classe Acesso,
alm de restringir os demais atributos como somente leitura,
aumentando a segurana dos seus atributos. A Listagem 7
mostra o resultado dessas mudanas, o que conclui esta refatorao para padres.
Na classe da Listagem 7 possvel ver que um dos mtodos
AlterarAcesso foi removido (primeiro mtodo AlterarAcesso
presente na Listagem 5). A partir deste momento, a classe
StatusAcesso far uso de um tipo seguro, que o tipo da classe
Acesso, como pode ser visto nas linhas 8 a 16 da Listagem 7.
Refatorao para padres Limitar Instanciao com

Singleton
Resumo: O sistema instancia vrios objetos de uma classe,
gastando muita memria e prejudicando o desempenho.
Substituem-se as vrias instncias por uma instncia de
Singleton.
Motivao: Esta refatorao para padres inversa Internalizar Singleton, pois ao invs de remover o padro Singleton,
ela prope a implementao de um, baseando-se em alguns
problemas encontrados. H momentos em que se deve implementar um Singleton, e esses casos ocorrem devido ao fato de
que vrias instncias de um objeto esto sendo criadas e isto
est prejudicando o desempenho da aplicao ou gastando
muita memria. Limitar em apenas uma instncia, e mant-la
globalmente na aplicao pode ser a soluo, e essa soluo
proposta por esta refatorao para o padro singleton.
Vantagens: Ajuda a melhorar o desempenho da aplicao.
Desvantagens: Faz com que o objeto instanciado fique acessvel globalmente, o que pode no ser uma boa alternativa em
alguns projetos; se torna intil quando o estado de um objeto
no pode ser compartilhado.
Mecnica: Essa mecnica considera que se tem um cenrio
onde a definio de um singleton necessria.
1. Buscando pela classe que cria mltiplas instncias de um
objeto, aplica-se a refatorao para padres Substituir Construtores por Mtodos de Criao, removendo todos os construtores ao criar mtodos de criao de objetos.
2. Analisando as caractersticas que fazem uma classe possuir
uma nica instncia, crie as definies necessrias para que
ela instancie apenas um objeto.
3. Permita que o objeto instanciado continue sendo retornado,
mas agora ele ser como uma instncia nica. A refatorao
para o padro singleton finaliza aps a execuo de testes.
Exemplo: A refatorao para padres Internalizar Singleton
trouxe um exemplo de uma aplicao que no necessitava de

02. {
05.
06.
07.
08.


10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
private String AlterarAcesso(String tipo)

{
this.acesso = tipo;
return acesso;
}
private String obterAcesso()
{
return objAcessoSeguro.nome;
}
private void AlterarAcesso(Acesso objAcesso)
{
this.objAcessoSeguro = objAcesso;
}

24. {
25. if (obterAcesso().Equals(Aberto))
26. {
27.
estado = false;
28.
AlterarAcesso(Fechado);
29.
AlterarAcesso(Acesso.Fechado);
30. }
31. else if (obterAcesso(). Equals(Fechado))
32. {
33.
estado = true;
34.
35.
AlterarAcesso(Acesso.Aberto);
36. }
37. else if (obterAcesso(). Equals(Ocioso))
38. {
39.
estado = true;
40.
41.
42. }
43. else if (obterAcesso(). Equals(Bloqueado))
44. {
45.
estado = true;
46.
47.
48. }
49. return objAcessoSeguro.nome;
50. }
51. }

02. {
03. public readonly static Acesso Aberto = new Acesso(Aberto);
04. public readonly static Acesso Fechado = new Acesso(Fechado);
05. public readonly static Acesso Ocioso = new Acesso(Ocioso);
06. public readonly static Acesso Bloqueado = new Acesso(Bloqueado);
07. public readonly String nome;
08. public Acesso(String nome)
09. {
10. this.nome = nome;
11. }
12. }
43

02. {
04.
05.
06.
07.
private readonly String Aberto = Aberto;

private readonly String Fechado = Fechado;
private readonly String Ocioso = Ocioso;
private readonly String Bloqueado = Bloqueado;

09. private String obterAcesso()
10. {
12. }
13. private void AlterarAcesso(Acesso objAcesso)
14. {
15. this.objAcessoSeguro = objAcesso;
16. }
18. {
19. if (obterAcesso().Equals(Aberto))
20. {
21.
estado = false;
22.
AlterarAcesso(Acesso.Fechado);
23. }
24. else if (obterAcesso().Equals(Fechado))
25. {
26.
estado = true;
27.
28. }
29. else if (obterAcesso().Equals(Ocioso))
30. {
31.
estado = true;
32.
33. }
34. else if (obterAcesso().Equals(Bloqueado))
35. {
36.
estado = true;
37.
38. }
40. }
41. }
Listagem 8. Classe AcessoBancoDados
01. public class AcessoBancoDados

02. {
03. private String stringconnection = Data Source=02DESKTOP\\
SQLEXPRESS; Initial Catalog=HotelMaster;Integrated Security=
SSPI;MultipleActiveResultSets=True;
04. private static SqlConnection objConexao = null;
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20. }
44
public AcessoBancoDados()
{
objConexao = new SqlConnection();
objConexao.ConnectionString = stringconnection;
objConexao.Open();
}
public SqlConnection getConexao()
{
new AcessoBancoDados();
return objConexao;
}
public static void fecharConexao()
{
objConexao.Close();
}
uma classe singleton e, por isso, foi refatorada. Ao contrrio

dela, tem-se agora uma aplicao que cria vrias instncias
de uma classe, o que est prejudicando o desempenho, j que
os recursos de hardware so muito limitados. A Listagem 8
mostra o cdigo da classe em questo, responsvel por abrir
conexes com o banco de dados.
O primeiro passo envolve a utilizao da refatorao para
padres Substituir Construtores por Mtodos de Criao. A
Listagem 9 mostra o resultado. Nela possvel observar que o
mtodo construtor da Listagem 8 foi substitudo pelo mtodo
CriarObjConexao (linhas 5 a 10 da Listagem 9).
Posteriormente, avalia-se a classe em questo e visualiza-se uma
forma de limitar suas instanciaes. Isto ser possvel fazendo
com que o mtodo getConexao faa uma verificao com nulos, e
se um objeto conexo j tiver sido instanciado, ele no instanciar
outro. O resultado pode ser visto na Listagem 10, onde tem-se o
mtodo getConexao da Listagem 9 recebendo um if que verificar
se no h uma conexo aberta. Caso no haja, ser criado um
objeto de conexo (linha 5).
A refatorao para o padro singleton est finalizada. Assim,
uma nica instncia da classe AcessoBancoDados ser criada,
podendo o mtodo getConexao ser invocado na inicializao da
aplicao, o que criar um objeto. A partir da, todas as outras vezes que o mtodo getConexao for invocado, ele retornar o objeto
j existente e no uma nova instncia de AcessoBancoDados.
Listagem 9. Classe AcessoBancoDados
01 public class AcessoBancoDados

02 {
03 public String stringconnection = Data Source=
02DESKTOP\\SQLEXPRESS; Initial Catalog=HotelMaster;
Integrated Security=SSPI;MultipleActiveResultSets=True;
04 private static SqlConnection objConexao = null;
05 private void CriarObjConexao()
06 {
07 objConexao = new SqlConnection();
08 objConexao.ConnectionString = stringconnection;
09 objConexao.Open();
10 }
11 public SqlConnection getConexao()
12 {
13 CriarObjConexao();
14 return objConexao;
15 }
16 public static void fecharConexao()
17 {
18 objConexao.Close();
19 }
20 }
Listagem 10. Mtodo getConexao da classe AcessoBancoDados
01. public SqlConnection getConexao()

02. {
03. if (objConexao == null)
04. {
05. CriarObjConexao();
06. }
07. return objConexao;
08. }
Desenvolvimento
Refatorao para padres Introduzir Objeto Nulo

Resumo: Em vrios pontos da aplicao encontra-se cdigo
para trabalhar com valores nulos que so atribudos a variveis
e atributos. Modificam-se esses pontos substituindo o cdigo
que trabalha com nulos por um objeto de uma classe que ser a
responsvel por carregar cdigo de verificao de nulos.
Motivao: O padro de projeto Objeto Nulo permite a definio
de um mecanismo que contm lgica de manipulao de nulos.
Ele se torna til para evitar que cdigo para verificaes com
nulos sejam espalhadas pela aplicao, centralizando-o em um
ponto, que poder ser acessado quando necessrio. Esta prtica
visa formar uma maneira uniforme de tratar nulos e reduzir
duplicao de cdigo toda vez que for preciso verificaes com
valores nulos.
Vantagens: Fornece uma maneira de definir lgica para manipulao de nulos sem duplic-la por vrios pontos no sistema;
simplifica o projeto de cdigo existente.
Desvantagens: Pode complicar o projeto de cdigo existente
se no houver vrios pontos que necessitam de verificaes
com objetos nulos; complica os testes caso no se entenda bem
como se d a implementao de um objeto nulo. Pode complicar
a manuteno do cdigo se a estrutura do padro objeto nulo
utilizar polimorfismo.
Mecnica:
1. Utilizando a refatorao Extrair Subclasse em uma das classes
que contm cdigo para verificao de nulos, cria-se a subclasse
que ser responsvel pela implementao do padro Objeto Nulo.
Caso, por uma deciso de projeto, a subclasse extrada deva implementar uma interface, utilize a refatorao Extrair Interface.
2. Caso haja cdigo cliente que invoca verificaes com nulos,
substitua-o por chamadas a um mtodo criado na subclasse objeto
nulo, permitindo que ele seja sobrescrito.
3. Repete-se o passo 2 at que no se ache mais cdigo para verificao de nulos em clientes.
4. O cdigo para verificao de nulos deve ser removido e levado
para o mtodo da subclasse objeto nulo, citado no passo 2. Se tal
mtodo ainda no tiver sido criado, defina-o neste instante na
subclasse.
5. Repete-se o processo do passo 4 enquanto houver cdigo para
diferentes formas de verificao com nulos.
6. Os passos 4 e 5 devem ser repetidos em todas as classes do
sistema que possuam cdigo de verificao de nulos.
Exemplo: Para este exemplo iremos considera o cdigo da
Listagem 11. A classe da Listagem 11 pertence a uma calculadora
que s permite a execuo de operaes matemticas bsicas aps
uma verificao com nulos. O problema dessa verificao que
ela a mesma para todos os mtodos da classe OperacaoBasica,
no entanto tal lgica de verificao de nulos est espalhada.
O primeiro passo a ser realizado envolve a aplicao da
refatorao Extrair Subclasse, formando uma subclasse de
OperacaoBasica chamada ObjetoNulo. A subclasse criada ser
responsvel por carregar todo cdigo de verificao de nulos
presentes em todos os pontos da aplicao. A Listagem 12
mostra o resultado do passo 1.
Listagem 11. Classe OperacaoBasica
01. public class OperacaoBasica

02. {
03. ...
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
public Boolean MetodoSomar(Decimal x, Decimal y)

{
if (ModeloCalculadora != null && TipoCalculadora != null)
{
EnviarResultado(x + y);
return true;
}
else
{
return false;
}
}
public Boolean MetodoDividir(Decimal x, Decimal y)
{
{
EnviarResultado(x / y);
return true;
}
else
{
return false;
}
}
28. public Boolean MetodoMultiplicar(Decimal x, Decimal y)

29. {
30.
31.
{
32.
EnviarResultado(x * y);
33.
return true;
34.
}
35.
else
36.
{
37.
return false;
38.
}
39. }
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53. }
public Boolean MetodoSubtrair(Decimal x, Decimal y)

{
{
EnviarResultado(x - y);
return true;
}
else
{
return false;
}
}
...
Listagem 12. Classe ObjetoNulo
01. public class ObjetoNulo: OperacaoBasica

02. {
03. }
45
Listagem 14. Classe OperacaoBasica
01 public class OperacaoBasica

02 {
03 ...
04 private ObjetoNulo nulo;
05 public Boolean MetodoSomar(Decimal x, Decimal y)
06 {
07 if (nulo.VerificaCondicaoCalculadora())
08 {
09
EnviarResultado(x + y);
10
return true;
11 }
12 else
13 {
14
return false;
15 }
16 }
17 public Boolean MetodoDividir(Decimal x, Decimal y)
18 {
19
if (nulo.VerificaCondicaoCalculadora())
20
{
21
EnviarResultado(x / y);
22
return true;
23
}
24
else
25
{
26
return false;
27
}
28 }
46
public Boolean MetodoMultiplicar(Decimal x, Decimal y)

{
{
EnviarResultado(x * y);
return true;
}
else
{
return false;
}
}
public Boolean MetodoSubtrair(Decimal x, Decimal y)
{
{
EnviarResultado(x - y);
return true;
}
else
{
return false;
}
}
...
A constante busca por projetos de cdigo cada vez melhores passa por diversas verificaes. Neste artigo foram
abordadas trs tcnicas de refatorao para padres com
esta finalidade. Ciente das formas de se implementar tais
melhorias, cabe ao conhecedor do projeto de cdigo existente
aplic-las e, com isso, obter um cdigo refatorado.
Referncias
GAMMA, Erich, 2000. Padres de Projeto: solues reutilizveis de software orientado a objetos,
1ed. Porto Alegre: Bookman, 2000.
KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.
FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.

Feedback
eu
sobre e
s
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54 }
Concluso
D
s
01. public class ObjetoNulo: OperacaoBasica

02. {
03. public Boolean VerificaCondicaoCalculadora()
04. {
05. if (ModeloCalculadora != null && TipoCalculadora != null)
06. {
07.
return true;
08. }
09. return false;
10. }
11. }
No cdigo cliente no h chamada com verificao de

nulos, portanto nesse momento deve-se levar a lgica de
verificao de nulos para a classe ObjetoNulo. Isto ser
possvel graas implementao de um mtodo que carregar em seu corpo a lgica de verificao. A Listagem 13
mostra o resultado.
A lgica utilizada pelos mtodos da Listagem 11 foi carregada para o mtodo recm criado na classe ObjetoNulo.
Agora, o que se tem a fazer remover a duplicao de cdigo
de verificao de nulos presente na classe OperacaoBasica.
Para isto, declarado um objeto da classe ObjetoNulo na
classe OperacaoBasica e, em seguida, o cdigo de verificao
de nulos presente nos mtodos da classe OperacaoBasica
removido, dando lugar chamada do mtodo VerificaCondicaoCalculadora, conforme apresentado na Listagem 13. A
Listagem 14 mostra o resultado destas aes, o que conclui
esta refatorao para padres, onde pode-se perceber, nas
linhas 7, 19, 31 e 43, que o cdigo de verificao de nulos deu
lugar chamada do mtodo VerificaCondicaoCalculadora
da classe ObjetoNulo. Neste caso, o cdigo de verificao de
nulos inicialmente encontrado na classe OperacaoBasica foi
movido para a classe ObjetoNulo, eliminando a duplicao
e o espalhamento de cdigo de verificao de nulos, que
agora est concentrado na classe ObjetoNulo.
edio
ta
Listagem 13. Classe ObjetoNulo
Desenvolvimento
47
48

Edição38 2011

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Edição38 2011

Transféré par

Droits d'auteur :

Formats disponibles

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Ano 3 - 38 Edio - 2011

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa

Eduardo Oliveira Spnola

Fale com o Editor!

or muito tempo a indstria se ancorou em mtodos que buscavam maior previsibilidade

20 - A gerncia de projetos de software em duas perspectivas Parte 2: Scrum

27 - Uso de metodologias geis em uma organizao baseada em linha de produto

Edio 05 - Engenharia de Software Magazine

Por trs do bvio

MacGyver: Gesto Perigo

Engenharia de Software - MacGyver: Gesto Perigo

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

D seu feedback sobre esta edio!

importando os meios envolvidos. J ser eficaz alcanar os

as sries que mais fizeram a minha cabea nos anos

De que se trata o artigo?

Samuel atua como engenheiro de software

Neste artigo veremos como equilibrar a aplicao

velocidade com que ocorreu o

Em que situao o tema til?

se provou verdadeira, especialmente

Edio 38 - Engenharia de Software Magazine

baixo, a gesto dos projetos torna-se muito complexa, algumas

Figura 1. Interseo do conhecimento entre tecnologia e negcio

Desta forma, percebeu-se que os mtodos tradicionais de

Engenharia de Software Magazine - A Pirmide Lean

Figura 2. Pirmide Lean

O primeiro aspecto que precisamos trabalhar quando desejamos

M etod ologias geis

Uma das primeiras coisas necessrias para isso uma boa

mudar e, acima de tudo, disciplina e iniciativa para fazer

Figura 3. Valores considerados

Alm de definir adequadamente seus prprios valores, uma

Figura 4. Definio de integridade

Edio 38 - Engenharia de Software Magazine

para efetuar o trabalho pode influenciar profundamente no

Temos duas grandes razes para entregar rpido: para que

ordem de compra at o momento em que coletamos o dinheiro.

Refletindo um pouco sobre o ltimo princpio enfatizado

Entendendo Valor e Desperdcio

Engenharia de Software Magazine - A Pirmide Lean

M etod ologias geis

qualquer demanda inesperada. Ainda assim, grande parte

Tipos de desperdcio em software

automaticamente, no documentado e que nunca foi para

Figura 5. Grfico do custo da complexidade

Edio 38 - Engenharia de Software Magazine

Cultura Stop the Line

no local necessrio e quando necessrio. Em uma linha de

Uma vez que temos definidos claramente quais so os

Engenharia de Software Magazine - A Pirmide Lean

M etod ologias geis

Figura 7. Efetividade da comunicao

Figura 6. Equipe gil

De fato, todo processo de desenvolvimento gil adaptativo

O principal objetivo do trabalho conjunto e integrado de uma

Edio 38 - Engenharia de Software Magazine

Engenharia de Software Magazine - A Pirmide Lean