Vous êtes sur la page 1sur 48

Modéstia à parte, sua melhor opção para se destacar no mercado!

A Escola Superior da Tecnologia da Informação oferece as melhores opções em cursos, formações, graduações
A Escola Superior da Tecnologia da
Informação oferece as melhores
opções em cursos, formações,
graduações e pós-graduações para
profissionais de desenvolvimento
e programação.
PÓS-GRADUAÇÃO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAÇÃO
São programas voltados para a
formação de profissionais de elite,
com aulas 100% práticas, corpo
docente atuante no mercado,
acesso à mais atualizada biblioteca
de TI do Rio, laboratórios equipados
com tecnologia de ponta, salas de
estudo e exames.
Engenharia de Computação
Análise e Desenv. de Sistemas
FORMAÇÕES
Desenvolvedor Java
Desenv. Java: Sist. Distribuídos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
Acesse nosso site e conheça 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
EDUCAÇÃO
SUPERIOR
ORIENTADA AO
MERCADO
- cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800 EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO
Ano 3 - 38ª Edição - 2011 Corpo Editorial Editor Rodrigo Oliveira Spínola Colaboradores Marco
Ano 3 - 38ª Edição - 2011
Corpo Editorial
Editor
Rodrigo Oliveira Spínola
Colaboradores
Marco Antônio Pereira Araújo
Eduardo Oliveira Spínola
Marco Antônio Pereira Araújo
Eduardo Oliveira Spínola
Jornalista Responsável
Kaline Dolabella - JP24185
Na Web
www.devmedia.com.br/esmag
Dolabella - JP24185 Na Web www.devmedia.com.br/esmag Rodrigo Oliveira Spínola rodrigo.devmedia@gmail.com
Dolabella - JP24185 Na Web www.devmedia.com.br/esmag Rodrigo Oliveira Spínola rodrigo.devmedia@gmail.com
Dolabella - JP24185 Na Web www.devmedia.com.br/esmag Rodrigo Oliveira Spínola rodrigo.devmedia@gmail.com

Rodrigo Oliveira Spínola

rodrigo.devmedia@gmail.com

Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo ministrado cursos na área de Qualidade de Pro- dutos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação 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 Antônio Pereira Araújo

maraujo@devmedia.com.br

Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software,Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF,Professor e Coordenador do curso de Ba- charelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora,Professor do curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.

Eduardo Oliveira Spínola

eduspinola@gmail.com

É Colaborador das revistas Engenharia de Software Magazine,Java Magazine e SQL Magazine.É ba- charel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de Software,sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).

Fale com o Editor! Atendimento ao Leitor É muito importante para a equipe saber o
Fale com o Editor!
Atendimento ao Leitor
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você
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, endereço de bancas de
jornal, entre outros, entre em contato com:
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 sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria
www.devmedia.com.br/mancad
de publicar.
(21) 2220-5338
Apoio
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br

EDITORIAL

“P or muito tempo a indústria se ancorou em métodos que buscavam maior previsibilidade para o desenvolvimento de software, procurando entender de antemão e geralmente fixar qual seria o escopo, o custo e o prazo de desenvolvimento. Ao longo dos anos, con-

tudo, percebeu-se que a tão esperada previsibilidade não se provou verdadeira, especialmente para projetos nos quais se busca o desenvolvimento científico de tecnologias que ainda não existem. Contudo, mesmo para projetos em que a tecnologia é de certa forma trivial, a complexidade dos negócios envolvidos torna também o processo imprevisível.É muito comum o mercado mudar suas necessidades, ou mesmo o próprio cliente não saber o que quer até que comece a ver partes disso funcionando. Desta forma, percebeu-se que os métodos tradicionais de desenvolvimento como o Waterfall ou mesmo o RUP eram pesados demais em termos de documentação e hierarquia entre os indivíduos e não permitiam o grau de aprendizado necessário para que pudéssemos simplificar o desenvolvimento de software. Assim, no final dos anos 90, alguns autores começaram a expe- rimentar métodos mais leves, baseados em uma maior interação entre os indivíduos e também 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 começaram a se consolidar e então foi fundada a Agile Alliance, uma organização sem fins lucrativos que tem por objetivo disseminar o uso e o desenvolvimento de todas as metodologias que compartilham dos mesmos princípios 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 indústria de software mais produtiva, humana e sustentável. Infelizmente, hoje é muito fácil observar que diversas empresas ainda sofrem com ambientes im- produtivos, de baixíssima qualidade e, em alguns casos, desumanos. Sendo assim, encontrar uma

maneira efetiva e menos dolorosa para a adoção de métodos ágeis tornou-se vital. Em geral, as

empresas iniciam este processo de adoção com Scrum, por tratar-se de um framework simples e

de fácil utilização. Apesar de ser um framework que permite uma melhora significativa da produtivi- dade e da gerenciabilidade, o Scrum peca em não trazer nenhuma orientação sobre as práticas de engenharia. Ele permitirá maior agilidade em responder às mudanças impostas pelo mercado, mas responder a estas mudanças pode ser traumático caso não estejamos preparados com uma base de código sólida e que nos permita real segurança na hora de mudarmos nosso software. Como

a maioria das empresas que querem adotar métodos ágeis não tiveram o uso de boas práticas de

engenharia, adotar o Scrum sem dar a devida atenção ao código pode ser realmente doloroso. Por este motivo, criou-se um conceito que visa auxiliar as empresas a equilibrar corretamente o uso de práticas, princípios e valores em todos os níveis de uma organização, com o objetivo de pro- mover uma mudança segura e sustentável na cultura interna e nos métodos de desenvolvimento.

Este conceito foi batizado de “A Pirâmide Lean”, título do artigo de capa desta edição da Engenharia de Software Magazine. Neste artigo veremos como equilibrar a aplicação de práticas, princípios e valores no desenvolvimento de software a fim de criar uma cultura organizacional enxuta e ágil. O conceito abordado neste artigo serve para a criação, adoção e disseminação da cultura Lean e Ágil de forma efetiva em uma organização que desenvolve software. Além desta matéria, esta edição traz mais seis artigos:

• MacGyver: Gestão Perigo

• Uma visão geral sobre o Scrum

• A Gerência de Projetos de Software em Duas Perspectivas – Parte 2

• Uso de metodologias ágeis em uma organização baseada em linha de produto

• Modelagem de processos usando ARIS

• Refatoração para Padrões – Parte 11

Desejamos uma ótima leitura!

ÍNDICE Caro Leitor, Por trás do óbvio 06 – MacGyver:Gestão Perigo Glênio Cabral Para esta
ÍNDICE
Caro Leitor,
Por trás do óbvio
06 – MacGyver:Gestão Perigo
Glênio Cabral
Para esta edição, temos um conjunto de 4 vídeo aulas. Estas vídeo aulas
estão disponíveis para download no Portal da Engenharia de Software Ma-
gazine e certamente trarão uma significativa contribuição para seu apren-
dizado.A lista de aulas publicadas pode ser vista abaixo:
Agilidade
07
- A Pirâmide Lean:O Equilíbrio das Forças Ágeis
Samuel Crescêncio
20
- A gerência de projetos de software em duas perspectivas – Parte 2:Scrum
Geraldo Magela Dutra Gonçalves
27
- Uso de metodologias ágeis em uma organização baseada em linha de produto
Tipo: Processo
Título: Curso Scrum Product Owner – Partes 1 a 4
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta é uma série de aulas de um treinamento voltado ex-
clusivamente para Product Owners. O Product Owner é um papel prescrito
pelo método ágil SCRUM responsável pelo sucesso ou fracasso do desen-
volvimento de um produto. Este é um papel complexo de ser exercido no
dia-a-dia e, este curso, distribuído em uma sequência de vídeo-aulas, tem
como objetivo tornar mais fácil a transição para aqueles que pretendem
ou necessitam trabalhar como Product Owner.
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 - Refatoração para Padrões – Parte 11
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo
Desenvolvimento 40 - Refatoração para Padrões – Parte 11 Jacimar Fernandes Tavares e Marco Antônio Pereira

Por trás do Óbvio

Glênio Cabral gleniocabral@yahoo.com.br É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músi- co.
Glênio Cabral
gleniocabral@yahoo.com.br
É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músi-
co. Idealizador do site de educação infantil www.novainfancia.com.br.

MacGyver: Gestão Perigo

D as séries que mais fizeram a minha cabeça nos anos 80 eu destacaria uma: MacGyver. MacGyver era um agente especial do governo americano que enfrenta-

va situações de perigo usando apenas sua grande capacidade de improvisação. O cara era tão 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, ninguém, no mundo inteiro, é tão bom na arte da improvisação quanto o povo das bandas de cá. O problema é que de vez em quando esse traço marcante de nossa cultura recebe um rótulo, digamos, meio pejorativo:

“jeitinho brasileiro”. O que é então o jeitinho brasileiro? Jeitinho brasileiro é toda ação que tenta resolver uma situ- ação de conflito transgredindo temporariamente algumas regras, não importando as questões morais envolvidas. As- sim, trafegar pelo acostamento, entrar no estacionamento pela contramão, dar dinheiro para o guarda esquecer a multa ou furar uma fila são exemplos clássicos de ações impregnadas pelo espírito do jeitinho, que visa impor o que é conveniente sobre o que é certo. Em outras palavras, “o coletivo que se dane!”. A boa notícia é que o jeitinho brasileiro é apenas o lado ruim da nossa capacidade inventiva. Alguém já disse que a criatividade do brasileiro é tão grande que se não for devida- mente direcionada rumo à eficácia, será apenas eficiente em seus resultados. É o que acontece nas organizações, quando o jeitinho brasileiro se faz presente em suas rotinas. Sabemos que há uma grande diferença entre ser eficien- te e ser eficaz. Ser eficiente é alcançar os resultados não

importando os meios envolvidos. Já ser eficaz é alcançar os resultados levando-se em conta a forma como serão alcança- dos. Em tempos de competitividade acirrada, organizações que agem focando apenas os resultados estarão dando um grande passo rumo à estagnação. Na ênfase restrita aos resultados, os meios acabam sendo desconsiderados e os ob- jetivos finais são seriamente comprometidos. Gestões apenas eficientes, baseadas no jeitinho brasileiro, estimulam a irres- ponsabilidade administrativa e o improviso para alcançar as metas de qualquer maneira. Quem age assim muitas vezes age sem pesquisa, sem planejamento, sem profissionalismo

e sem ética. MacGyver sempre conseguiu alcançar bons resultados sendo apenas eficiente. O problema surgia, ele improvisava

e pronto, tudo resolvido. Dava gosto de se vê o talento do

cara. A questão é que é muito mais fácil ter sucesso sendo eficiente no mundo imaginário. Mas no mundo real, onde a competitividade exige por parte das corporações cada vez mais planejamento, especialização e comprometimento, so- breviver na base do improviso e do jeitinho brasileiro é como assistir ao seriado do MacGyver: dá até vontade de imitar,

s o b r e k e s c t a a b e d
s
o
b
r
e
k
e
s
c
t
a
a
b
e
d
mas não passa de uma ficção.
Dê seu feedback sobre esta edição!
d
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, através do link:
e
www.devmedia.com.br/esmag/feedback
i
e
ç
F
ã
o
u
e
s
ê
D

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

A Pirâmide Lean O Equilíbrio das Forças Ágeis
A Pirâmide Lean
O Equilíbrio das Forças Ágeis
ágeis. A Pirâmide Lean O Equilíbrio das Forças Ágeis Samuel Crescêncio samuel.crescencio@oncast.com.br Twitter:

Samuel Crescêncio

samuel.crescencio@oncast.com.br

Twitter: @screscencio

Samuel atua como engenheiro de software construindo sistemas de missão crítica des- de 1994.Fundador e CEO da OnCastTechno- logies - empresa que tornou-se referência na América Latina em metodologias ágeis - Samuel adquiriu uma grande experiência em desenvolvimento ágil distribuído, fato que tornou-o apaixonado pela melhoria de processos. Reconhecido como um líder na comunidade internacional, Samuel foi presidente do Ágiles2009 - a segunda edição da Conferência Latino Americana de Métodos Ágeis e também do Pensando Lean – Forum internacional para corpora- ções enxutas.Samuel é membro do comitê de organização do Agile Brazil - Confe- rência Brasileira de Metodologias Ágeis e também 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.

A velocidade com que ocorreu o desenvolvimento tecnológico nos últimos 50 anos é certa-

mente impressionante. Em poucos anos podemos ver tecnologias surgindo e evoluindo muito rápido, algumas vezes se tornando padrões da indústria. Ou- tras, porém, desaparecem com a mesma velocidade que vieram. Esta mesma evolução pode ser também notada nos métodos que utilizamos para desenvol- ver software, mas possivelmente de uma forma não tão rápida. Por muito tempo a indústria se ancorou em métodos que buscavam maior previ- sibilidade para o desenvolvimento de sof- tware, procurando entender de antemão e geralmente fixar qual seria o escopo, o custo e o prazo de desenvolvimento. Ao longo dos anos, contudo, percebeu-se que a tão esperada previsibilidade não

De que se trata o artigo?

Neste artigo veremos como equilibrar a aplicação de práticas, princípios e valores no desenvolvi- mento de software a fim de criar uma cultura organizacional enxuta e ágil. O conceito abordado neste artigo serve para a criação, adoção e disse- minação da cultura Lean e Ágil de forma efetiva em uma organização que desenvolve software.

Em que situação o tema é útil?

Qualquer empresa que visa aprimorar seus métodos de desenvolvimento vai usufruir do conhecimento descrito neste artigo.

se provou verdadeira, especialmente para projetos nos quais se busca o de- senvolvimento científico de tecnologias que ainda não existem. Contudo, mesmo para projetos em que a tecnologia é de certa forma trivial, a complexidade dos negócios envolvidos torna também o processo imprevisível. É muito comum o mercado mudar suas necessidades, ou mesmo o próprio cliente não saber o que quer até que comece a ver partes disso funcionando. Quando o conhecimento sobre a tecnologia e sobre os negócios é

baixo, a gestão dos projetos torna-se muito complexa, algumas vezes gerando caos e anarquia. Observe a Figura 1.

algumas vezes gerando caos e anarquia. Observe a Figura 1 . Figura 1. Interseção do conhecimento

Figura 1. Interseção do conhecimento entre tecnologia e negócio

Desta forma, percebeu-se que os métodos tradicionais de desenvolvimento como o Waterfall ou mesmo o RUP eram pesados demais em termos de documentação e hierarquia entre os indivíduos e não permitiam o grau de aprendizado necessário para que pudéssemos simplificar o desenvolvimen- to de software. Assim, no final dos anos 90, alguns autores começaram a experimentar métodos mais leves, baseados em uma maior interação entre os indivíduos e também na entrega incremental e constante de software funcionando, que pudes- se ser utilizado pelo cliente mesmo antes de ter seu escopo completo. Algumas vertentes surgiam e estes pesquisadores observaram semelhanças 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 desenvol- vimento de software. Nesta mesma época, algumas metodologias começaram a se

baixíssima qualidade e, em alguns casos, desumanos. Sen- do assim, encontrar uma maneira efetiva e menos dolorosa para a adoção de métodos ágeis tornou-se vital. Em geral, as empresas iniciam este processo de adoção com Scrum, por tratar-se de um framework simples e de fácil utilização. Apesar de ser um framework que permite uma melhora significativa da produtividade e da gerenciabilidade, o Scrum peca em não trazer nenhuma orientação sobre as práticas de engenharia. Ele permitirá maior agilidade em responder às mudanças im- postas pelo mercado, mas responder a estas mudanças pode ser traumático caso não estejamos preparados com uma base de código sólida e que nos permita real segurança na hora de mudarmos nosso software. Como a maioria das empresas que querem adotar métodos ágeis não tiveram o uso de boas práti- cas de engenharia, adotar o Scrum sem dar a devida atenção ao código pode ser realmente doloroso. Por este motivo, criou-se um conceito que visa auxiliar as em- presas a equilibrar corretamente o uso de práticas, princípios e valores em todos os níveis de uma organização, com o objetivo de promover uma mudança segura e sustentável na cultura interna e nos métodos de desenvolvimento. Este conceito foi batizado de “A Pirâmide Lean”, apresentado na Figura 2.

de “A Pirâmide Lean”, apresentado na Figura 2 . Figura 2. Pirâmide Lean consolidar e então

Figura 2. Pirâmide Lean

consolidar e então foi fundada a Agile Alliance, uma organi- zação sem fins lucrativos que tem por objetivo disseminar o uso e o desenvolvimento de todas as metodologias que com- partilham dos mesmos princípios e valores do manifesto ágil.

O primeiro aspecto que precisamos trabalhar quando desejamos adotar o desenvolvimento ágil com eficácia é a transformação cultural necessária para o sucesso da empreitada. Um caso verí- dico ocorreu em uma das maiores empresas de ERP do Brasil. Lá

O

grande objetivo do manifesto e da Agile Alliance é fomentar

estavam presentes cerca de 35 pessoas, incluindo o presidente e

o

desenvolvimento de software para permitir uma entrega de

todo o conselho de administração, juntamente com o primeiro

maior valor agregado mais rapidamente, buscando uma indús-

tria de software mais produtiva, humana e sustentável. Com o advento dos métodos ágeis, podemos observar uma

se

nível de gerências. Durante o trabalho, o presidente disse: “esse método é realmente maravilhoso e acredito que pode resolver nos- sos problemas, mas não posso simplesmente baixar um decreto

transição da indústria de software. Hoje, 10 anos depois do

e

esperar que seja usado”. Com toda razão, a mudança cultural

evento em Salt Lake City, já falamos que o desenvolvimento ágil é “main stream” na indústria e que as empresas que não

não pode ser imposta, mas precisa ser suportada. O suporte à mudança precisa ser geral, não somente da gerência executiva, mas também do chão de fábrica. Normalmente, a primeira reação

adaptarem estão possivelmente fadadas ao fracasso, seja no curto, médio ou longo prazo.

das pessoas é a resistência – sendo assim, imposição nunca será

Infelizmente, hoje é muito fácil observar que diversas empresas ainda sofrem com ambientes improdutivos, de

melhor caminho. É preciso abrir espaço, dar as ferramentas adequadas e criar um ambiente que seja propício à mudança.

o

Uma das primeiras coisas necessárias para isso é uma boa definição e um claro entendimento dos valores e princípios que a organização segue. Os valores não servem apenas para estar num quadro bonito na recepção da empresa. Conhecer

e exercitar os valores precisam ser uma tarefa diária de todos

os membros da organização. Na OnCast, por exemplo, não se trabalha como uma organização hierárquica e burocrática; assim não há regras para tudo. Por este motivo, todos os cola- boradores são orientados a refletirem quando estão tomando uma decisão. Se esta decisão fere algum valor da empresa, eles são encorajados a procurar uma alternativa. Veja a Figura 3.

encorajados a procurar uma alternativa. Veja a Figura 3 . Figura 3. Valores considerados Além de

Figura 3. Valores considerados

Além de definir adequadamente seus próprios valores, uma organização que deseja ser efetivamente ágil precisa também entender e trabalhar com os valores e princípios do manifesto

ágil. O Manifesto Ágil costuma ser mal interpretado, especial- mente por pessoas que nunca tiveram contato e não conhecem

o que significa ser ágil. Por este motivo, é importante também

refletir sobre seus princípios. Depois de entender bem os valores da organização, é preciso então compreender os seus princípios. Os princípios do mani- festo ágil são uma excelente base, mas os princípios do Lean são também utilizados na Pirâmide Lean como pilares para a criação de uma cultura que possa permear toda a organização

e assim criar uma empresa efetivamente ágil e enxuta. Neste conceito da Pirâmide Lean, foi criado um sumário dos princípios do Lean para que assim possamos entender

de forma simplificada como eles se aplicam na organização. Vamos a eles:

Entregar um fluxo contínuo de valor para os clientes;

Criar uma organização que aprende;

Criar um ambiente de melhoramento contínuo.

Ter uma mente pensando de forma enxuta não é tarefa muito simples. Às vezes parece fácil, mas geralmente as pessoas estão habituadas – ou acomodadas – e ficam praticamente cegas para os desperdícios existentes. O mesmo ocorre com a questão do aprendizado. Quando se fala em uma organização que aprende, não se fala apenas em enviar os colaboradores para treinamentos ou contratar consultores externos. Deve- se criar um processo de trabalho onde o aprendizado esteja implícito e seja reconhecido como fundamental para o pró- ximo passo, a melhoria contínua. Vamos observar também que simplesmente aprender sobre o que precisa ser melho- rado não é suficiente. É preciso ter coragem para adaptar e

MEtodoLogiAS ÁgEiS

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

isto continuamente. Além desses princípios, não se pode deixar de frisar alguns princípios do Lean definidos por Mary e Tom Poppendieck que são também uma base sólida para a construção do pen- samento Lean:

Construir com integridade;

Respeitar as pessoas;

Entregar rápido;

Ver o todo.

Na indústria de software existem profissionais extraordiná- rios, mas há também muitos deprimentes. Só há dois motivos para alguém 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.

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 avião sabem se a aeronave pode suportar certa carga de peso, pois fizeram uma série de cálculos para isto. Já a integridade percebida é aquela que os usuários podem notar – por exemplo, o design do avião, o acabamento das poltronas, etc. O mesmo ocorre em software, e para que se tenha integridade, é preciso uma comunicação efetiva, a fim de criar um fluxo contínuo de informações entre os desenvolvedores, usuários e clientes (e vice-versa).

os desenvolvedores, usuários e clientes (e vice-versa). Figura 4. Definição de integridade Respeito Seria ótimo

Figura 4. Definição de integridade

Respeito

Seria ótimo se pudéssemos lidar somente com a complexi- dade envolvida no desenvolvimento tecnológico e no mundo dos negócios. Porém, temos também que lidar diariamente com o organismo mais complexo que existe na Terra: o ser humano. Respeitar as pessoas do ponto de vista do Lean não significa apenas aplicarmos o bom senso e a boa educação 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 respei- to. Prover respeito é uma ação tão complexa que muitas vezes magoamos as pessoas profundamente sem mesmo perceber. Um ambiente Lean efetivo dá espaço para que possamos aprender abertamente sobre este tipo de problema e assim resolvê-los de uma forma adequada.

Entregar rápido

Temos duas grandes razões para entregar rápido: para que

o nosso cliente não mude de ideia enquanto estamos cons-

truindo e para que nosso concorrente não entregue antes. Em geral, as mudanças no mercado e a velocidade com que nosso concorrente consegue entregar irão determinar o quão rápido

precisamos ser na hora da entrega. Além disto, entregar rápido

e de forma incremental nos permite feedback e aprendizado

sobre o que estamos fazendo. As experimentações de nosso produto no mercado, ainda que inacabado, proporcionarão um

desenvolvimento muito mais assertivo.

Ver o todo

Refletindo um pouco sobre o último princípio enfatizado pelos Poppendieck, pergunta-se: quantos em sua organização conhecem o que é valor para o cliente? Quantos conhecem o impacto de suas decisões no negócio do cliente? Se as pessoas em sua organização não compreendem as respostas a estas questões, elas devem estar trabalhando simplesmente porque alguém disse a elas o que devem fazer. Isto caracteriza um sistema “empurrado” de trabalho e certamente os resultados ficam muito aquém dos que seriam possíveis em uma orga- nização Lean de sistema “puxado”. Por isto, no conceito da Pirâmide Lean, as pessoas precisam enxergar e compreender

o todo. Mais do que isto, precisam contribuir para melhoria da

organização como um todo. Este princípio aplica-se também na parte técnica. Se você tem especialistas em certas partes do código e só eles conseguem mexer lá, certamente as demais pessoas da equipe não estão vendo o todo. Mais adiante neste artigo vamos abordar como resolver este tipo de problema.

Entendendo Valor e Desperdício

Se o princípio mais importante do Lean é gerar um fluxo contínuo de valor, precisamos aprender a identificar o que é desperdício. A mente humana não foi treinada para identificar aspectos negativos com facilidade. Há uma tendência 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 percepção sobre o que é desperdício. Aqui temos uma boa definição do que é desperdício segundo a perspectiva Lean: “Desperdício é tudo aquilo que esgota recursos de tempo, dinheiro e espaço sem adicionar valor ao cliente”. Taichi Ohno, um dos grandes criadores do Lean, tem uma citação famosa: “Tudo o que estamos fazendo é olhar para a linha do tempo, desde o momento em que recebemos uma

ordem de compra até o momento em que coletamos o dinheiro. Estamos reduzindo esta linha do tempo removendo tudo o que não gera valor para o cliente, o desperdício.”. É importante observar que ele citou “linha do tempo”. Há uma definição mais concisa em inglês 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 próprio nome diz,

é mapear tudo o que ocorre entre o surgimento e o completo

atendimento de uma requisição. Este mapeamento nos permi-

te registrar o que é tempo gasto com tarefas que adicionam

valor ao processo e o que é desperdício. Ao final, dividimos

o tempo de valor agregado pelo tempo total do processo e

teremos nosso coeficiente de eficiência operacional. Quando aplicam esta ferramenta, normalmente as empresas se espan- tam 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 negócio. Todo o

resto é desperdício.

Tipos de Desperdício

Quando começamos a identificar desperdício, criamos tam- bém uma oportunidade para melhoria no processo. Ainda para entender um pouco mais sobre desperdício, vamos ver os três tipos definidos pelo Lean.

Muda

Todo o tipo de atividade que não gera valor para o negócio. Aplicando a ferramenta de mapeamento da cadeia de valor, po-

demos identificar como desperdício alguns itens: filas, espera, processos ineficazes que geram retrabalho e outras coisas mais. Um outro exercício que podemos fazer para identificar o muda

é listar 15 atividades comuns que executamos diariamente,

incluindo ler e-mail, almoçar, 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. Após isto, basta contar quantas atividades têm o valor 4 ou 5 e você

verá o grande número de coisas que faz diariamente que não geram valor direto.

Muri

Sobrecarga de processo. É comum empresas imporem pe- ríodos 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 funcionários em até 150% de sua capacidade. Porém, o que acontece se carre- garmos um avião com 110% de sua capacidade? Possivelmente teremos um acidente aéreo. Se subirmos isto para 130% ou 150%, certamente teremos uma tragédia. O mesmo ocorre com

o ser humano e com os processos que utilizamos para desen-

volver software. Se estivermos funcionando a 100% de nossa

capacidade, certamente não teremos espaço para absorver

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 ocupação de cerca de 80% de nossa capacidade produtiva, seremos mais produtivos e teremos espaço para absorver coisas inesperadas, oriundas de falhas no processo ou mesmo de demandas externas.

Mura

Irregularidades. Todo o tipo de defeito existente é consi- derado Mura. Mura é tudo aquilo que não é desejado, uma inconsistência ou, no jargão mais comum, um bug. O Mura também pode ser oriundo do muri ou do muda. É comum observarmos a forma como as pessoas tratam o mura e vermos que geralmente não há uma correção de fato, mas apenas uma solução paliativa para o problema. Vamos pegar como exemplo um bug em um sistema, que foi identificado em uma fase de homologação ou em produção. O bug é relatado aos desenvol- vedores que geralmente vão depurar o código até encontrar o problema. Consertam-no, compilam e devolvem outra versão

do binário para a produção. Neste caso, é grande a probabilida- de deste defeito voltar ou de algum efeito colateral ser gerado

a partir desta correção – sem considerar o tempo desperdiçado

tentando achar o problema através de debug. Equipes um pouco mais preparadas utilizam testes automati- zados e vão reduzir o tempo com debug. Primeiro, irão criar um teste automatizado que reproduz o problema e posteriormente vão direto ao ponto para corrigir o bug. Como utilizam testes automatizados, esta equipe saberá imediatamente dos efeitos colaterais causados com a alteração no código e terá maior segurança em devolver uma versão corrigida para a produção.

Esta equipe ainda terá o benefício de não ter regressão, ou seja,

o problema dificilmente irá aparecer novamente, pois está bem

cercado pelos testes automatizados que poderão 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 à reflexão sobre a causa raiz cada

vez que encontramos um problema. Em outras palavras, qual foi a falha em nosso processo de desenvolvimento que per- mitiu que este erro passasse para a produção? Por que nossos métodos de testes não detectaram este erro antes? Trabalhar na causa raiz do problema será sempre o meio mais eficaz de prevenção. E a prevenção, quando efetiva, será sempre mais barata do que a cura.

Tipos de desperdício em software

O Lean foi originalmente concebido para gerenciar a linha

de produção da Toyota. Na manufatura, o maior desperdício existente é o estoque. Estoque alto significa dinheiro parado, matéria prima ou produto que pode perecer e ser perdido.

Na área de software temos os seguintes tipos de desperdícios mais comuns:

Estoque – Documentação não codificada, código não sin- cronizado no ambiente de controle de versões, não testado

MEtodoLogiAS ÁgEiS

automaticamente, não documentado e que nunca foi para produção;

Funcionalidades extras - Um estudo do Standish Group mos-

tra que 20% das funcionalidades de um software são sempre

ou frequentemente utilizadas. Outros 35% são usadas algumas vezes ou raramente e 45% das funcionalidades de um sistema típico nunca são 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 pre-

cisam ser executados somente para adequação a uma regra ou norma;

Espera – Todo tipo de espera entre uma atividade e outra;

Defeitos;

Complexidade.

No início deste artigo observamos a complexidade que pode ser gerada quando o conhecimento é baixo sobre a tec- nologia e os negócios. Agora podemos observar na Figura 5 que o custo do desenvolvimento de software sobe muito ao longo do tempo quando não temos uma base de código limpa e simples.

tempo quando não temos uma base de código limpa e simples. Figura 5. Gráfico do custo

Figura 5. Gráfico do custo da complexidade

Princípios do Lean

Vamos explorar um pouco mais a fundo os princípios que deram origem ao Lean e que permeiam todo o conceito da Pirâmide Lean.

Jidoka

Também conhecido como Autonomation ou Inteligent Automation, é a automação com um toque humano. Este foi um dos primeiros conceitos criados por Sakichi Toyoda, fundador do Grupo Toyo- ta. Ainda no século XIX, Sakichi observava sua mãe 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 mãe utilizasse somente uma das mãos para fazer o trabalho que antes precisava das duas. Seguindo esta ideia de automação, ele aprimorou seu invento e em

1906 criou o primeiro tear mecânico automatizado. Implementan- do o conceito de melhoria contínua, 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 máquina para que não produzisse tecidos defeituosos. Suas inovações para parada automática e prevenção de desperdícios foram extraordinárias. Com o invento, Sakichi eliminou a necessidade de ter um operador monitorando as máquinas de tear continuamente. Agora, um único operador poderia monitorar até 30 máquinas, possibilitando uma diminuição expressiva no custo, bem como um aumento da qualidade e produtividade das máquinas de tear da época. Assim, com a automação, Sakichi criou um meio para que as máquinas parassem automaticamente quando qualquer problema ocorresse e, desta forma, nunca produzissem defeitos. Sobretudo, o Jidoka eliminou a necessidade de monitoramento humano contínuo 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 produção tem

o dever de parar a linha ao sinal de qualquer problema. Estamos

falando de uma linha de produção de fluxo contínuo, integrada

aos fornecedores e que geralmente contabiliza cerca de duas mil pessoas trabalhando. Nesses casos, todas as pessoas que traba- lham 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 produção nas fábricas

da Toyota para diversas vezes ao dia e assim, a empresa consegue produzir carros de altíssima qualidade e diminuir drasticamente seus custos de correção de defeitos.

Poka-Yoke

Mecanismos a prova de erros. As linhas automatizadas de pro- dução na Toyota são dotadas de mecanismos de detecção de falhas que não permitem a inserção de erros no processo. Nas máquinas de solda, por exemplo, um mecanismo verifica se a máquina está apta a fazer a soldagem – se tudo estiver certo, a solda será reali- zada. Após o processo, outro mecanismo faz uma verificação para ver se tudo ocorreu bem. Caso algum dos testes falhe, a linha de produção para automaticamente. Para os procedimentos manuais, existe uma série de checklists que permitem validar cada etapa do trabalho dos funcionários. Novamente, quando uma etapa falha, a linha de produção é parada e o problema solucionado a partir de sua causa raiz. Juntando a automação 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 também ter estas características inseridas no processo – vamos discutir mais a frente como fazer isto.

Just in Time

Ter um processo just in time significa reduzir desperdício fazendo somente o que é necessário, na quantidade necessária,

no local necessário e quando é necessário. Em uma linha de produção, o fluxo just in time permite diminuir estoques e aumentar o giro de produtos. Associado a uma técnica de produção conhecida por sistema puxado, o just in time possi- bilita também minimizar as perdas com produção excessiva e consequentemente aumentar a produtividade da linha de pro- dução. O just-in-time também pode ser aplicado em software de diversas maneiras, que vamos explorar mais adiante.

Sistema Puxado

Um sistema puxado de produção determina a carga de trabalho de acordo com o consumo do cliente. Se não houver

consumo não haverá produção, eliminando completamente o desperdício com a produção excessiva. Diferentemente de um sistema empurrado, onde há produção independentemente da demanda, o sistema puxado gerencia toda a cadeia produtiva

– desde a extração da matéria prima até a transformação em

um produto acabado. Para auxiliar neste processo, Taichi Ohno

concebeu uma ferramenta chamada Kanban, que permite um gerenciamento visual e colaborativo da produção puxada. O Kanban tornou-se também uma ferramenta muito importante para gerenciar o desenvolvimento de sistemas complexos. Veremos mais adiante como aplicá-lo a software.

Heijunka

O Heijunka é uma técnica de análise da produção que au- xilia no nivelamento da produção e consequente eliminação do Muda, permitindo criar cadência na demanda e nivelar a produção para potencializar a vazão do sistema e o fluxo de

entrega de valor. Para aplicar o Heijunka, é necessário entender

o funcionamento do Kanban para identificar como são distri- buídas as cargas em um processo de desenvolvimento.

Pessoas

Uma vez que temos definidos claramente quais são os princípios e valores que norteiam a cultura de uma organi-

zação, estamos prontos para definir a estratégia de negócio

e estabelecer a visão pela qual a empresa desenvolverá seus

produtos. Esta visão precisa ser claramente conhecida por todos os membros da organização, de modo que cada um em seu trabalho possa direcionar suas atividades para maximi- zar o valor gerado pela empresa. Desta forma, os objetivos desta visão 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 comu- nicar a visão, precisamos abordar um pouco o fator humano. Como observamos no manifesto ágil, é importante termos sempre os melhores processos e ferramentas à disposição para que uma equipe possa desenvolver de forma adequada

as atividades. Porém, é ainda mais importante maximizar a in- teração e colaboração entre os indivíduos. Tanto no Lean como no desenvolvimento ágil de software busca-se o fortalecimento das pessoas através da criação de equipes multidisciplinares

e auto-responsáveis, de maneira que uma única equipe seja

formada de modo completo, compreendendo todos os conheci- mentos e habilidades necessárias para transformar a visão em produtos que gerem valor efetivo para a organização. Equipes ágeis possuem a autonomia necessária para definir o que é valor de negócio e também para determinar qual a tecnologia será necessária para entregar tal valor. A Figura 6 demonstra como uma equipe ágil pode ser formada.

Figura 6 demonstra como uma equipe ágil pode ser formada. Figura 6. Equipe ágil De fato,

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 questão. Aqui vamos explorar e estabelecer como base a diferença 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 diferenças. A primeira delas está no papel do Product Champion ou engenheiro chefe do produto. Como o próprio nome já diz, o Engenheiro Chefe é o responsá-

vel final pela arquitetura e pelas principais decisões técnicas do produto. Contudo, o Product Champion proposto pelo Lean

é também responsável por todas as decisões de marketing.

Sendo assim, ele é responsável por definir todo o processo de venda, suporte, precificação e a logística de entrega. Como podemos observar, o Product Champion é o líder máximo, que conhece as necessidades mercadológicas e de- tém o conhecimento tecnológico necessário 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 é alguém que tem muitos anos de prática, em geral de 15 a 20 anos de experiência com

a cultura da organização. Ademais, ele também procura viver

as experiências dos clientes. Em alguns casos, o Engenheiro Chefe realmente se muda para viver com uma família que tem o perfil de seu cliente alvo, para vivenciar na prática seus

hábitos e costumes. Só assim ele terá subsídios suficientes para desenvolver produtos de sucesso. Uma equipe Lean multidisciplinar completa será formada por subequipes que contemplam expertise em negócios, ma- rketing, vendas, engenharia, arquitetura, design e produção. A comunicação entre estes experts deve sempre ser a mais direta

e eficaz possível. Logo, a Figura 7 demonstra a efetividade da comunicação.

MEtodoLogiAS ÁgEiS

a efetividade da comunicação. MEtodoLogiAS ÁgEiS Figura 7. Efetividade da comunicação O principal objetivo

Figura 7. Efetividade da comunicação

O principal objetivo do trabalho conjunto e integrado de uma equipe Lean é identificar com assertividade as necessidades

de negócio e promover a entrega incremental de valor efetivo.

É fundamental uma equipe saber identificar o que é valor e

qual a porção mínima de software necessária para entregar tal valor. Por isso, cita-se propositadamente o termo entrega de

valor, em vez de entrega de software. Podemos observar ainda a presença de um outro papel de liderança, a do líder de competências. Ele garante que a criação de competências esteja inserida implicitamente no processo de desenvolvimento. Não precisamos necessariamente parar

a equipe para receber um treinamento, mas é fundamental

garantir que o aprendizado ocorra durante o desenvolvimento. Logo vamos abordar como as técnicas de engenharia que estão na base da pirâmide e o desenvolvimento iterativo permitem

a aquisição on-the-fly de conhecimento. Com relação ao Scrum, a principal diferença na formação da equipe é que o Product Owner não possui conhecimento técnico suficiente para influenciar profundamente nas decisões técnicas, bem como a equipe não conhece o negócio a ponto de envolver-se nas decisões. Em geral, as decisões são tomadas de forma conjunta, compartilhando-se conhecimento sobre negócio e tecnologia. Não podemos dizer que o modelo de equipe do Lean é melhor do que o do Scrum e vice e versa. Ambos têm prós e contras e serão mais apropriados de acordo com cada tipo de projeto.

Quebrando a Visão

Uma vez que a organização tenha definido adequadamente sua visão e estratégia de negócios partimos para a imple- mentação, aplicando os princípios e valores do Lean e do desenvolvimento ágil nas demais camadas da organização. Dependendo do nível de maturidade da empresa e das ca- racterísticas dos projetos, ela poderá optar por usar Scrum ou Kanban para criar um processo de entrega de valor. Antes disso, precisamos quebrar a visão em objetivos menores que sejam específicos e mensuráveis. Tanto no Scrum quanto no Kanban vamos utilizar uma ferramenta para isto – as estó- rias do usuário. Sendo assim, vamos entender melhor como utilizar esta ferramenta antes de entrar em detalhes sobre Scrum e Kanban.

Estórias

Uma estória, ou User Story, é uma frase simples que des- creve uma necessidade ou requisito de sistema. Estórias são utilizadas no desenvolvimento ágil para especificação de requisitos, em conjunto com critérios de aceite devidamente

elaborados. Estórias são uma forma rápida e eficaz de coletar

e manter requisitos sem a necessidade de uma formalização

burocrática, adicionando agilidade no processo e facilitando

o planejamento. Uma estória pode ser considerada a funcionalidade em si

dentro do ciclo de desenvolvimento de software. A estória, em geral, é uma requisição do Product Owner que, passada para

Vale lembrar que estórias não são especificações completas do que deve ser feito. Na verdade, são apenas links de comunicação entre a equipe e o Product Owner a respeito de um determina- do assunto. Estórias são geralmente escritas em cartões (post- its) e fixadas na parede (quadro de estórias), onde compõem uma lista chamada Product Backlog – Figura 8. O Product Backlog é uma lista de estórias em constante priorização que representa o escopo do produto. Esta lista é mutante, já que no desenvolvimento ágil as mudanças de escopo são bem vindas

a qualquer momento durante o desenvolvimento.

Estimativas e velocidade de desenvolvimento

o

time de desenvolvimento, se transformará em uma porção

Estórias contêm estimativas e a responsabilidade por estimá-

esta responsabilidade ao time é uma forma efetiva de garantir

do software funcionando. Detalhes sobre a estória emergem durante as discussões nas sessões de planejamento. Entretanto,

sua concepção, tais como: motivação do Product Owner para

las é única e exclusiva do time de desenvolvimento. Delegar

algumas informações adicionais podem acompanhá-la desde

comprometimento, já que nenhuma meta é imposta, mas sim proposta pelos próprios engenheiros de software.

o

requisitá-la, critérios que irão reger sua aceitação e descrições técnicas mais detalhadas, quando necessário. O time de desenvolvimento colabora com o ciclo de vida das estórias na medida em que as transforma para que possam ser classificadas como SMART:

experiência do desenvolvimento ágil de software mostra a

ineficácia do uso de uma medida de tempo (horas ou dias) para estimar o custo de uma estória. As estimativas são feitas em story points (sp), medida exclusiva de esforço, que demonstra o tamanho de uma estória comparada a outras. A tarefa de estimar

A

Específico: refere-se a uma intervenção pontual no software

em story points é livre da preocupação sobre o tempo de duração

e

não ao desenvolvimento de um artefato muito grande ou

do projeto. Story points liberam o time de desenvolvimento da

complexo;

pressão por datas, possibilitando o foco na complexidade da

Mensurável: deve ser possível mensurar o custo de desenvol-

estória. Para acomodar as incertezas de estórias de grande porte,

vimento e o valor gerado, além de prever sua situação futura

costuma-se utilizar a escala Fibonacci para atribuição dos pontos,

após o desenvolvimento da estória;

já que ela inicia com uma granularidade menor nos primeiros

Alcançável: na medida em que seu custo pode ser mensurado,

valores, partindo para apenas uma ordem de grandeza em

uma estória deve ser um objetivo possível de ser alcançado, cujo comprometimento com a entrega por parte da equipe seja efetivo;

Realista: A tecnologia escolhida deve contemplar de forma

realista fatores como custo, tempo disponível e capacidade técnica da equipe;

Time-boxed (tempo fixo para o desenvolvimento): uma estória

deve ser planejada para ser entregue por inteira dentro de um ciclo de desenvolvimento. Porém, em um eventual atraso, ela não deve ser motivo para atrasar ou adiantar a entrega do ciclo.

deve ser motivo para atrasar ou adiantar a entrega do ciclo. Figura 8. Backlog A escala

Figura 8. Backlog

A escala Fibonacci permite

acomodar a incerteza do processo de desenvolvimento nos

intervalos entre um número e outro na escala.

A previsibilidade com a completude das estórias em datas

específicas vem da união das estimativas com o conceito de

velocidade. A velocidade do time de desenvolvimento é des- coberta com a informação histórica sobre quantos story points foram completados nas últimas iterações de desenvolvimento.

A representação de velocidade pode ser por iteração ou mesmo

por dia: 20sp por iteração ou 2sp/dia, por exemplo. Desta forma, quando o time inicia uma nova jornada com 10 dias de desen-

volvimento, pode se comprometer com a entrega de software funcionando com um grupo de estórias que somam aproxima- damente a sua velocidade média nas últimas iterações. Outro aspecto interessante é que a produtividade de uma equipe aumenta à medida que vai agregando mais conheci- mento sobre a tecnologia e o negócio em questão. Consequen- temente, as estimativas tornam-se também mais assertivas ao longo do tempo. Em geral, uma equipe inicia com cerca de 30% de sua velocidade nominal e após três ou quatro iterações a velocidade estabiliza em sua capacidade máxima. Entradas ou saídas de integrantes da equipe podem também afetar a velocidade, mesmo depois do grupo ter atingido uma estabi- lização da velocidade. Vale salientar que o custo de uma estória varia de equipe para equipe e de época de desenvolvimento para época de

escalas maiores: 1, 2, 3, 5, 8, 13, 21

desenvolvimento. É correto utilizar velocidade e número de estórias para comparar iterações consecutivas para uma mesma equipe. Entretanto, a comparação de iterações muito distantes ou de diferentes equipes carece de uma análise mais subjetiva. Além disso, a velocidade descoberta é uma média das últimas iterações, sendo normal na iteração atual um resultado com desvio para mais ou para menos. No caso de variação positiva da velocidade, mais estórias podem ser inseridas na iteração. Quando a velocidade varia negativamente, as estórias de menor prioridade são cortadas da iteração.

Priorização

Estórias de desenvolvimento normalmente são criadas pelo Product Owner, mas outras pessoas podem exercer esta função. Estórias de manutenção corretiva podem ser criadas por uma equipe de suporte. Estórias de refactoring criadas pelo time de desenvolvimento e estórias de novas funcionalidades, em geral, podem ser criadas por uma equipe de marketing ou até pelo usuário final. Independente da fonte, a estória será obrigatoriamente priorizada pelo Product Owner. Um Product Owner focado em maximizar o retorno do seu investimento certamente realizará um bom trabalho de prio- rização. Uma priorização adequada pode levar o desenvolvi- mento a alcançar um nível de produtividade representado pela Lei de Pareto. A Lei de Pareto diz que, com 20% do esforço de desenvolvimento, pode-se gerar 80% do valor no software. O mesmo poderá ser observado durante a manutenção corretiva do software, quando 80% dos problemas podem ser resolvidos atacando 20% das causas. A Figura 9 demonstra essa razão de esforço e resultado da Lei de Pareto.

essa razão de esforço e resultado da Lei de Pareto. Figura 9. Lei de Pareto Diversas

Figura 9. Lei de Pareto

Diversas técnicas de priorização podem ser utilizadas, e den- tre elas podemos citar o cálculo do Retorno do Investimento (ROI), onde se mensura o custo do desenvolvimento e o valor gerado, a técnica MoSCoW (Must, Should, Could, Won’t) e a análise de Kano. O cálculo do ROI é realizado elencando-se diversos fatores, como custo do desenvolvimento, custo da estrutura física de desenvolvimento e produção, e aspectos como capacidade de aumento nas vendas, conquista de novos clientes ou mesmo a retenção de atuais clientes. Para tanto, uma análise mais

MEtodoLogiAS ÁgEiS

aprofundada, reunindo especialistas das áreas de finanças, marketing, vendas e desenvolvimento, é necessária.

A técnica MoSCoW é uma das mais utilizadas. Através dela

e a partir da experiência do Product Owner, é possível deter-

minar quais estórias precisam (must), deveriam (should) e poderiam (could) estar com prioridade mais alta, bem como quais estórias não irão de fato ser priorizadas (won’t). Este último é um fator de priorização muito importante, conhecido também como not list, geralmente esquecido ou não utilizado por equipes menos experientes.

A Análise de Kano é um modelo de desenvolvimento de

produtos criado nos anos 80 pelo professor Noriaki Kano,

que classifica as preferências dos consumidores em cinco categorias (Figura 10).

dos consumidores em cinco categorias ( Figura 10 ). Figura 10. Análise de Kano Planejamento e

Figura 10. Análise de Kano

Planejamento e Controle da Produção

Uma vez tendo conhecimento sobre o que é preciso ser desenvolvido e sua adequada priorização, é preciso também

compreender como planejar e controlar a entrega dos artefatos.

É isso que iremos explorar neste tópico.

Ciclos: releases, iterações e entrega contínua

Uma das principais características 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 períodos, tentando identificar e mitigar todos os riscos possíveis logo de início. Ao longo dos anos descobriu- se que esta estratégia não funciona devido à própria natureza incerta do desenvolvimento de software e dos negócios onde normalmente são aplicados.

Através deste aprendizado, o Lean e as metodologias ágeis propõem ciclos curtos de planejamento e entrega, nos quais uma parte do produto final é projetada, desenvolvida e testa- da dentro de um período curto, chamado iteração ou Sprints no Scrum – Figura 11. Observem que não estamos falando de protótipos, e sim de uma parte do produto final que pode ser utilizada em produção e será continuamente melhorada e incrementada, iteração após iteração, respondendo às mudan- ças impostas pelo mercado e pela tecnologia, até que atinja o escopo necessário.

e pela tecnologia, até que atinja o escopo necessário. Figura 11. Esqueleto Scrum Ciclos curtos de

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 capacitação implícita nos processos de desenvolvimento que citamos an- teriormente, essencial para um ambiente Lean maduro. Com mais conhecimento, as equipes passam a diminuir a incerteza

e trabalham ancoradas em um processo confiável de entregas

de produto de alta qualidade e valor agregado. Com maior confiabilidade e previsibilidade é possível fazer

um planejamento de releases para o projeto, considerando as regras adequadas de priorização e a velocidade da equipe de desenvolvimento. Desta forma, os releases são entregas maiores que contemplam o que foi desenvolvido durante algumas itera- ções e, associado a um objetivo bem definido, o planejamento passa a ser uma forma valiosa de satisfazer as necessidades de mercado do cliente. Como são priorizadas as funcionalidades que geram maior valor e têm maior risco para o projeto, os ciclos curtos propi- ciam um produto de alto valor agregado, diminuindo os riscos

e o time-to-market. Consequentemente, a vantagem competitiva do cliente torna-se indiscutível.

Entrega contínua com Kanban

Quando a equipe atinge um alto nível de maturidade, os ciclos de desenvolvimento tornam-se cada vez mais curtos e eventualmente a parada para planejamento das iterações pode se tornar um desperdício. O Kanban pode ser utilizado para amadurecer o workflow e aumentar a eficiência do sistema, promovendo a entrega contínua de software e o aumento da produtividade da equipe.

De forma simplificada, o Kanban é um processo de produção 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 à produti- vidade da equipe. Limites inferiores vão auxiliar a garantir que sempre haja demanda suficiente para que o trabalho não pare. Ambos os limites ajudam a criar cadência no processo, nivelando a produção e potencializando ao máximo a en- trega e, consequentemente, vazão de valor. O nivelamento da produção (Heijunka) é necessário para evitar os períodos 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 benefícios, o Kanban auxilia na gestão visual do fluxo de trabalho, melhorando a comunicação e os processos de priorização. O Kanban também permite um foco grande na qualidade, através de seus critérios “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 métodos ágeis propiciam uma oportunidade diária para análise de riscos e tomada de decisão de modo a corrigir o mínimo desvio indevido de curso. Todas as ocorrências são disponibilizadas através das ferramentas de gestão como dashboard e burndown charts para todos os membros do projeto. Além disso, a comunicação direta entre equipes gera maior colaboração, visibilidade e controle do projeto. O próprio processo de ciclos curtos proporciona maior aprendizado e feedback concreto sobre o exato andamento do projeto, gerando maior segurança e consequente aumento de auto-estima para todos os envolvidos. Com base nas ferramentas e técnicas de metodologias ágeis, visibilidade e controle são potencializados da seguinte forma:

Dashboard – painel que contém as estórias e tarefas priori-

zadas no backlog e que demonstra a evolução no ciclo de vida do desenvolvimento;

Gráfico de evolução burndown charts proporcionam visi-

bilidade sobre a velocidade de produção da equipe e se esta

velocidade é adequada para os objetivos;

Aceites – o cliente aceita ou rejeita as estórias entregues ao final de cada ciclo de desenvolvimento. Tudo é documentado, incluindo o planejamento, o que foi realizado e eventuais diferenças;

Software funcionando – sempre ao final de cada iteração o

cliente recebe um software pronto para uso, proporcionando

feedback e retroalimentação da visão do produto;

Documentação embarcada – todo código é entregue com

documentação embarcada (javadoc), possibilitando o aumento do conhecimento;

Software Intelligence – todas as técnicas de automatização,

coleta de métricas e testes utilizadas pela equipe proporcio-

nam muita segurança e a certeza de se estar desenvolvendo

o produto correto.

A base da pirâmide Lean

A base da pirâmide é larga para poder sustentar o resto da

estrutura. Por este motivo, colocamos na base as práticas de Engenharia de Software que permitem uma efetiva e segura adoção de métodos ágeis. A utilização de Scrum ou Kanban para gestão dos projetos deixa mais fácil a tarefa de responder às mudanças e adequar o planejamento. Entretanto, se não houver uma base de código sustentável, essa resposta despreparada às mudanças pode significar um problema muito grande. Por este motivo é importante implementar na Engenharia de Software os princípios e valores do Lean e do Manifesto ágil.

Testes Automatizados

Testes automatizados são certamente uma das mais funda- mentais técnicas de desenvolvimento de software, que permite uma adição severa de qualidade ao código. O grande objetivo é criar esta qualidade durante a construção do código, ao invés de testá-lo mais tarde. Em geral, equipes que não investem na criação de testes automatizados necessitam de um longo perí- odo de testes ao final de cada ciclo de desenvolvimento. Esse investimento tardio na qualidade compromete o conhecimento

da real situação do software durante o desenvolvimento, o que gera atrasos, falta de visibilidade, gerenciabilidade e asserti- vidade do produto final.

O investimento em testes automatizados oferece a oportu-

nidade de obter feedback dos testes mesmo durante o desen- volvimento do software. A grande vantagem desta abordagem

o fato de se poder testar todo o sistema facilmente, a partir de apenas um botão na IDE. A reprodutibilidade dos testes encoraja sua execução, minimizando a necessidade e o custo

é

de manutenção corretiva. A aplicação de testes automatizados

é também a criação de um ambiente que permita o aprendiza-

do de forma implícita, conforme mencionado no início deste artigo. Os testes automatizados são blocos de código, chamados

códigos de testes, que exercitam o código de produção. Os testes confeccionados variam na sua abrangência e no foco. Quanto à abrangência, podem ser:

Testes unitários: testam cada menor trecho de código do

sistema;

Testes integrados: testam classes ou módulos do sistema de

forma integrada;

Testes funcionais: testam funções específicas do sistema de

ponta a ponta, abrangendo todo o fluxo da informação;

Testes de aceitação: testes inspirados na condição de acei-

tação do cliente ou usuário. Geralmente sãoão aplicadosaplicados direta-direta-

mente na interface do sistema.

MEtodoLogiAS ÁgEiS

A Figura 12 demonstra as camadas de um software e a

abrangência dos testes.

as camadas de um software e a abrangência dos testes. Figura 12. Exemplo de Arquitetura de

Figura 12. Exemplo de Arquitetura de Testes Automatizados

Quanto ao foco dos testes:

Corretude do funcionamento: são os testes mais comuns,

utilizados para certificar a aderência do sistema aos requisitos

funcionais;

Performance e consumo de memória: testes que certificam

o desempenho do sistema de acordo com requisitos não- funcionais;

Usabilidade: estes testes normalmente não são automatiza- dos. Envolvem especialistas em usabilidade e podem contar com a participação do próprio usuário.

Desenvolvedores utilizam testes automatizados na criação da tecnologia, auxiliando-os na escrita de código limpo e habilitando o refactoring para melhoria contínua. Especia- listas de negócio podem usufruir de testes automatizados para certificarem-se de que seu modelo de negócio segue efetivo e aceito, mesmo durante a contínua evolução da base de código.

Automatização do Ambiente

A Engenharia de Software requer que processos repetitivos

sejam executados inúmeras vezes. Estas atividades envolvem, por exemplo, a execução da suíte de testes, compilação do sistema, geração de versão de distribuição, configuração do ambiente de execução (como base de dados), notificação dos responsáveis em caso de erros nos testes, criação de relatórios de aderência aos padrões – enfim, a lista é bem extensa. De maneira geral, estas atividades, se desempenhadas por pessoas, requerem uma equipe dedicada e muito disciplinada. No entanto, a propensão a erros durante a execução da rotina é bastante alta, o que invariavelmente configuraria desperdí-

cios (Mura). Para a redução destes desperdícios recomenda-se a automa- tização de tais processos. Neste tópico serão discutidas ações que podem ser tomadas para automatizar seu ambiente.

Builds Automatizados

Existem ferramentas que podem auxiliar a automatização dos processos repetitivos de desenvolvimento. Tais ferramentas po- dem variar de acordo com a tecnologia. Alguns exemplos são:

Make, Ant e Maven. Para as tecnologias Java, os mais utilizados são Ant e Maven, ambos da Apache Software Foundation. Tratam-se de ferramentas para execução de rotinas descritas como instruções codificadas em arquivos de configuração XML, comumente chamados de builds. Devido às contribuições da comunidade de desenvolvimento, estas ferramentas possuem várias extensões e recursos que en- volvem compilação de código em várias linguagens, execução de testes (incluindo, mas não se limitando ao padrão xUnit), envio de e-mail, integração com servidores de aplicação e manipulação de banco de dados. A maneira de utilização destas ferramentas depende muito dos propósitos do projeto em que são utilizadas. Porém, de ma- neira geral, a compilação, empacotamento e testes do artefato de software desenvolvido são os principais objetivos. A utiliza- ção intensa propicia a coleta e a geração de artefatos para gestão da configuração que permitem a análise do desenvolvimento, adesão aos padrões e tomada de decisão quanto à qualidade dos artefatos gerados (veja o tópico Software Intelligence para mais informações dos benefícios e meios).

Integração Contínua

Dispor de builds automatizados para seu projeto é um grande passo rumo à automatização dos processos, suporte à decisão sobre investimentos em qualidade, visibilidade, entre outros. Entretanto, para que estes benefícios sejam de fato gerados, é necessário que estes processos automatizados sejam executados de maneira sistemática e autônoma. Por exemplo, a suíte de testes e a rotina para executá-los não obterão os benefícios desejados caso não sejam executados a cada contribuição dos desenvolvedores sobre o código fonte do software do projeto. O disparo do processo de execução periódica poderia ser executado pelo pessoal responsável por

poderia ser executado pelo pessoal responsável por Figura 13. Ambiente de Integração Contínua qualidade.

Figura 13. Ambiente de Integração Contínua

qualidade. Entretanto, assim como a execução de processos repetitivos, delegar esta responsabilidade comumente resulta em falhas e consequente desperdício. Para tal, ferramentas de monitoramento de contribuição e execução automática estão disponíveis, dentre elas: Apache Continuum, Hudson, LuntBuild e CruiseControl. Trata-se de um serviço disponibilizado na infraestrutura de desenvolvi- mento, geralmente em um servidor dedicado para o fim de integração contínua. Os servidores de integração contínua comumente são con- figurados com um ambiente web, com suporte a ferramentas de comunicação (como e-mail e instant messenger) e link com outros servidores como Servidor de Controle de Versões e Servidor de Homologação. Estes recursos ampliam as capa- cidades dos builds automatizados, que podem publicar os relatórios gerados no ambiente web, enviar notificações aos desenvolvedores e outros interessados quanto ao status dos testes, entre outras possibilidades. A Figura 13 mostra três servidores: Servidor de Controle de Versões (SCV), Servidor de Homologação (SH) e Servidor de Integração Contínua (SIC). Note que os desenvolvedores colocam suas contribuições ao projeto no SCV. O SIC, continu- amente monitora o SCV em busca de modificações. Dada uma modificação detectada, o SIC atualiza sua cópia do projeto com as últimas atualizações detectadas, estando assim em sincronia com o SCV, e então executa o build automatizado do projeto.

Este build executará todas as rotinas automatizadas e pode- rá se valer do ambiente do SIC para fazer o deployment da nova versão do software em um servidor para homologação (SH). É possível também gerar relatórios para acompanhamento

e tomada de decisões em um ambiente web disponibilizado no próprio SIC.

Software Intelligence

Software Intelligence refere-se às habilidades, tecnologias, aplicações e práticas utilizadas para ajudar a todos os envol- vidos a entender melhor o contexto do negócio: desenvol- vimento de software. Para tal, existem ferramentas livres que possibilitam a varredura do código fonte na busca por indícios de bugs no software, cobertura de testes, métricas de qualidade, entre outras informações. Estas ferramentas, integradas ao sistema de builds automatizados, podem ser consideradas inteligência de software quando são combi- nadas com um processo que busca melhoria contínua. Na

prática, nas reuniões de retrospectiva e nas estórias de re- factoring, os relatórios de inteligência do software são fontes importantes de suporte a decisão. A seguir, são apresentadas algumas das ferramentas que poderão ser empregadas na presente proposta:

FindBugs. FindBugs é um programa que se propõe a achar bugs em aplicações Java por meio da análise estática do có- digo fonte. Este é um método utilizado para achar bugs em um sistema, sem executá-lo. A possibilidade de achar erros

e vulnerabilidades sutis, antes que elas ocorram meses ou

anos depois no sistema em produção, é a principal vantagem desse programa;

CPD. Trata-se de um Detector de Copia e Cola (Copy/Paste

Detector) para o código fonte da aplicação. Sua sensibilidade

pode ser configurada e costuma apresentar algumas sur- presas para seus usuários, principalmente em equipes de desenvolvimento médias, grandes e distribuídas. O principal benefício do CPD é reduzir a propagação de erros e o custo de todos os tipos de manutenção em códigos duplicados. Ele também encoraja o uso de boas práticas de orientação a

objetos como DRY (Don’t Repeat Yourself), pois evita a reco- dificação de entidades do sistema já implementadas;

PMD. O PMD é um programa que analisa o código fonte

na busca de uma suite de situações: códigos que poderiam ser melhor implementados quanto a performance, porções de código não utilizadas, tratamento deficiente de exceções

e sentenças desnecessariamente complexas;

Relatório dos testes. Resultados da execução da suíte

automatizada de testes. Deve ser mantido sempre verde,

passando. Em caso de erro, além da possível notificação aos interessados, a cor no relatório será vermelha e as causas serão apresentadas em detalhes;

Doxygen. Através de engenharia reversa aplicada às classes

e à documentação embarcada no código fonte, o Doxygen pode gerar diagramas UML com o estado real da aplicação, manuais e documentação online;

Checkstyle. É uma ferramenta que auxilia o time de de-

senvolvimento a se manter dentro de padrões de codificação. Assim como o CPD e o PMD, é ideal para times médios, grandes ou distribuídos;

Cobertura. Como o nome indica, esta ferramenta mensura

a cobertura dos testes automatizados no sistema. Ele gera

relatórios que podem ser confrontados no próprio código fonte, indicando as áreas que foram acionadas pelos testes

automatizados;

Mensurar a complexidade ciclomática. Apesar do nome

complicado, significa simplesmente mensurar a complexidade de códigos estruturados ou cíclicos. Esta informação pode reduzir custos de manutenção, gerando valor na medida em que explicita, por exemplo, implementações fora da arquite-

tura planejada;

Lobo. Lobo é uma ferramenta opensource desenvolvida

pela OnCast, que estende a API de testes padrão para Java,

oferecendo opções avançadas para testes de performance. Os relatórios gerados pelo Lobo mostram a evolução da perfor- mance do sistema ao longo do tempo do projeto. Se uma nova implementação compromete a performance de algum ponto

isolado do sistema, este problema é facilmente identificado

e isolado com a ajuda desta ferramenta.

Vale salientar que foram apresentadas algumas das fer- ramentas disponíveis no mercado. O emprego de cada uma delas no processo de desenvolvimento será analisado

MEtodoLogiAS ÁgEiS

confrontando o custo de manutenção do ambiente de software intelligence, com o valor gerado pelo mesmo. Uma escolha bem feita de um subconjunto destas ferramentas tem o po- tencial de formar um relatório significativo sobre o estado do desenvolvimento de um software.

Conclusão

Em todos os níveis da Pirâmide Lean é possível encontrar elementos trabalhando em conjunto para criação de valor na organização. Podemos observar que falamos sempre de pessoas, processos e ferramentas – tudo isso para a criação da melhor tecnologia. O Lean chama este processo de Systems Thinking, e orienta a olhar para a junção de pessoas, proces- sos 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 técnicas – testes automatiza- dos, TDD, refactoring, arquitetura emergente, simplicidade e integração contínua, por exemplo – são aplicadas corretamente, formamos uma base sólida para que a visão da organização seja rapidamente implementada e entregue com a mais alta qualidade. O correto equilíbrio na definição de valores e princípios e na aplicação das técnicas do Lean, Scrum e Kan- ban, conduz a organização para níveis de excelência ainda não alcançados. Esta excelência permitirá a criação de uma cultura baseada em relacionamentos fortes e duradouros, estimulando a criatividade e a inovação. Responsabilidade, disciplina, senso de propriedade, capacidade de auto-gestão, respeito e colaboração permitirão a criação de uma equipe extremamente ágil e coesa, que tenha prazer naquilo que faz e que, principalmente, construa uma relação de confiança entre si e para com seus clientes. Espera-se, pois, que a visão da Pirâmide Lean ajude a in- dústria de software a tornar-se mais produtiva, humana e sustentável.

 

Referências

Apresentação da Pirâmide 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

Site de Mary & Tom Poppendieck, criadores do Lean Software Development http://www.poppendieck.com/

s o b r e k e c s a t a b d e
s
o
b
r
e
k
e
c
s
a
t
a
b
d
e
Dê seu feedback sobre esta edição!
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, através do link:
e
d
www.devmedia.com.br/esmag/feedback
e
i
ç
F
ã
u
o
e
s
ê
D

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

A gerência de projetos de software em duas perspectivas – Parte 2 Scrum
A gerência de projetos de software em duas
perspectivas – Parte 2
Scrum
de software em duas perspectivas – Parte 2 Scrum Geraldo Magela Dutra Gonçalves geraldo.magela@ufjf.edu.br

Geraldo Magela Dutra Gonçalves

geraldo.magela@ufjf.edu.br

É graduado em Engenharia Civil e possui es- pecialização em Análise e Desenvolvimento de Sistemas, ambas pela Universidade Federal de Juiz de Fora. É técnico em TI da Universidade Federal de Juiz de Fora onde trabalha com desenvolvimento de sistemas de informação e informática desde 1988. É professor do Curso Superior de Tecnologia em Análise e Desenvol- vimento de Sistemas da Fundação Educacional D. André Arcoverde em Valença/RJ.

D esenvolvimento de sistemas é uma atividade que requer cria- tividade. Esse é um dos motivos

pelos quais não se pode automatizar completamente a própria atividade. Tal criatividade, característica marcante da mente humana, é requerida não só na solução de problemas complexos de forma única e inovadora, mas também, e principalmente, na adaptabilidade a situações novas e inusitadas. Desenvolvedores vêem-se constan- temente às voltas com situações não documentadas, mudanças de requisitos durante o projeto, além de variações no escopo levantado. Quando envolvidos em um projeto de TI, cujo modelo de gestão é baseado em processos pré- definidos, desenvolvedores ficam sem alternativas quando precisam lidar com acontecimentos não previstos. Modelos de gestão baseados em pro- cessos definidos estabelecem etapas sequenciais e entregas intermediárias rígidos, sem margens para manobra. Sis- temas de informações, ou outros projetos

De que se trata o artigo?

A série iniciada na última edição da Engenharia de

Software Magazine aborda duas perspectivas em Gerenciamento de Projetos de TI. Este segundo ar- tigo aborda características do Scrum, conjunto de técnicas de gerenciamento de projetos de desen- volvimento de software com foco em agilidade, ou seja, entregas rápidas de software operacional que agregue valor ao negócio do cliente. A inten-

ção dos artigos é estabelecer as bases necessárias

a uma comparação de metodologias, visando

fornecer subsídios para estabelecimento da

aplicabilidade das duas vertentes apresentadas.

O trabalho pretende auxiliar na escolha de uma metodologia de gerência adequada.

Em que situação o tema é útil?

Quando o escopo de um trabalho situar-se

numa área nebulosa em relação a qual técnica

é mais adequada ao planejamento, execução,

acompanhamento e controle de um determi- nado projeto. Variáveis comuns nesses casos, como por exemplo, natureza volátil dos requi- sitos, porte do sistema, disponibilidade de re- cursos, qualidade do produto resultante, entre dezenas de outras, podem dificultar a escolha acertada da metodologia de planejamento e gerência.

ainda mais ambiciosos de TI, são muito afeitos a ambientes dinâmicos de atuação, o que significa dizer que o modelo de gestão aplicável depende muito da natureza do projeto e da natureza do produto desejado. A evolução dos métodos de gestão de tais projetos seguiu ao longo das décadas baseando- se, principalmente, no princípio universal de tentativa e erro, ou seja, na experiência adquirida na prática diária. Como uma consequência natural dos fracassos colecionados em projetos com modelo de gestão baseados em processos de- finidos rígidos, surgiram, naturalmente, propostas de modelos de gestão que mudavam o foco do projeto de maneira bastante radical sem, contudo, eliminar totalmente os vínculos básicos que os interligam. Uma significativa quantidade de iniciativas compõe um conjunto de metodologias (ainda que algumas delas não se denominem assim) que podem ser genericamente designadas como ‘metodologias ágeis’ de desenvolvimento de sistemas.

A maior parte delas, senão todas, baseiam-se em um método

de gestão empírico, onde ao invés de empreender um grande esforço inicial de planejamento e projeto, para depois lançar-

se à construção do produto, o desenvolvimento do trabalho é

orientado para o desenvolvimento iterativo, vários ciclos de projeto, execução e entrega, gerando incrementos ao produto em desenvolvimento, sempre totalmente operacionais, entre outras características. Essa forma de gestão mostra-se mais flexível e adaptável quando os projetos tratados demonstram- se muito sensíveis a ambientes e condições extremamente sujeitos a incertezas. Em tais ambientes, pode-se considerar o alvo do projeto como algo móvel, que só poderá ser atingido por aproximação. Esse modelo de gestão é mais aplicável a situações de projeto onde tanto os processos de produção e gestão quanto os próprios produtos deles obtidos são pouco ou nada previsíveis. Como um processo de gestão e execução mais criativo e mais dinâ- mico, 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 culti- vados 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 gestão holístico (considera que o todo é maior que a soma das par- tes), 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 idéias apresentadas a um movimento presente no jogo de rugby, o Scrum. Surgia o nome do método. Em 1999, Ken Schwaber e Mike Beedle escreveram o primeiro livro sobre Scrum: Agile Software Development with Scrum. Os autores definem Scrum não como uma metodologia, mas como um framework conceitual, um conjunto de ideias,

MEtodoLogiAS ÁgEiS

técnicas e práticas que levam ao estabelecimento de uma atitude mental de trabalho. As equipes Scrum são formadas como times, e devem assumir um comprometimento com o trabalho que alcança níveis bem superiores aos encontrados em grupos de trabalho convencionais. Embora as origens de Scrum remontem, portanto, às décadas de oitenta e noventa, sua popularização entre desenvolvedores de sistemas se deu

a partir da divulgação, em 2001, do “Manifesto para o Desen- volvimento Ágil de Software”, mais comumente referido como “Manifesto Ágil”.

Manifesto para o desenvolvimento ágil de software

Esse manifesto é um documento que resume as conclusões de um debate ocorrido em 2001, entre diversos desenvolvedores de software, realizado com o intuito de estabelecer pontos de convergência e interseções observadas nas diversas metodo- logias praticadas por cada um dos integrantes daquele encon- tro. Embora tais pessoas tivessem, naquela ocasião, opiniões próprias e bem diferentes sobre como levar ao sucesso um projeto de desenvolvimento de software, o manifesto deixou

claro que um conjunto de características comuns existia e po- deria ser destacado sem ambiguidades. No texto do próprio

documento:

“Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a fazerem

o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas;

Software em funcionamento mais que documentação abrangente;

Colaboração com o cliente mais que negociação de contratos;

Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valoriza- mos mais os itens à esquerda”. Existem pelo menos doze princípios que norteiam, a partir do manifesto ágil, os trabalhos de equipes que desejam de-

senvolver software de maneira ágil, mas alguns deles estão 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 através de entregas rápidas e até adiantadas de software com valor agregado. Além disso, os incrementos devem ser disponibilizados como software operacional. Nenhuma outra definição de software pronto é aceita: software pronto é software que pode entrar em operação no ato da entrega. Um fantasma que assombra projetos baseados em processos pré-definidos, longos, e com a herança do desenvolvimento em cascata, é a presença de um conjunto de requisitos altamente voláteis. Como os métodos mais convencionais pontuam por projetar completamente antes de construir, mudanças durante

o curso do projeto são desastrosas. As metodologias ágeis aceitam sem traumas e sem grandes reações a chegada de mudanças. Na verdade, uma de suas características mais marcantes é a de trabalhar sempre em

pequenos ciclos, dentro dos quais pode-se desenvolver des- de projeto até implantação de incrementos e entre os quais, pode-se acomodar sem grande dificuldade as mudanças ao longo do processo. Isso na verdade produz um produto final que é invariavelmente mais adequado para o cliente do que

o produto idealizado a princípio; se os requisitos evoluem, o

produto evolui também. Equipes de desenvolvimento ágil só admitem integrantes motivados. Para compor uma equipe produtiva, as pessoas têm que dispor de condições materiais e mesmo emocionais favoráveis, sem o quê a produtividade esperada será afetada. A questão das comunicações eficazes é muito trabalhada nes- sas metodologias. É consenso entre os signatários do encontro, que a melhor maneira de efetuar comunicação e transmitir informações entre os integrantes da equipe é através de con- versação face a face. É claro que tais conversações podem (e segundo adeptos de metodologias mais tradicionais, devem) ser acompanhadas de documentação no mínimo básica, mas isso não invalida esse fundamento. Uma conversa face a face

é extremamente mais esclarecedora do que um e-mail. Como um fundamento central final, a equipe deve, periodica- mente, reunir-se e refletir sobre como tornar-se mais eficiente. Acreditar que já se chegou ao máximo incentiva a inércia e faz com que a equipe estacione.

Comparação 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 conclusões. 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 mudanças durante o percurso. O cliente pode sentir-se sempre à vontade para introduzir mudanças a qualquer tempo, desde que acordadas com a equipe. Nestes casos cabe à equipe julgar o que é possível realizar dentro do tempo acordado. Modelos tradicionais fixam-se em planejamento e controle.

A execução de uma etapa deve garantir que seu output seja o

input perfeito para a etapa seguinte. Os modelos ágeis aplicam- se mais em inspeções e adaptações, mantendo-se prontas para mudanças de direção ocasionais. Para isso, vale-se de peque- nos ciclos de desenvolvimento incremental, que produzem feedback contínuo. Modelos tradicionais são orientados a processos, assim como bem demonstra o PMBOK, discutido no artigo anterior. O foco de Scrum, e outras metodologias ágeis, é em pessoas, dando

à participação delas uma dimensão mais próxima de sua real

importância 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 tratarão de construí-lo em cama- das: camada1 + recheio + camada2 + cobertura, fazendo com que só possa ser apreciado ao final do trabalho. Metodologias ágeis vão construir o mesmo bolo em fatias finas: a partir da

primeira, os clientes já poderão provar, aceitar ou recusar o que estão comprando.

Elementos da metodologia SCRUM

As funcionalidades de um sistema de informações são, sob Scrum, classificadas pelo seu tamanho e abrangência. Grandes funcionalidades, que na verdade são grupos de funcionalidades menores, são denominados épicos. Estes elementos são compos- tos de funcionalidades denominadas user stories, que reunidas em grupos coesos e relacionados constituem temas. Para serem desenvolvidas, as stories são divididas em tarefas. Como um modelo de gestão iterativo e incremental, Scrum

é realizado em ciclos. Cada ciclo de Scrum é denominado

sprint, período de tempo em que um ou mais incrementos reais é desenvolvido e, ao final, tais incrementos devem ser demonstrados ao cliente. A duração de cada sprint pode va- riar de projeto para projeto, mas é aconselhável que dure de 2 a 4 semanas. São as durações consagradas pela experiência. Um sprint de 30 dias é realizado em sprints diários, 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 necessários para desenvolver todas as funcionalidades encomendadas pelo cliente. As funcionalidades (user stories) que devem ser desenvolvi- das compõem uma lista denominada product backlog. Esta lista não precisa estar completa antes do começo do desenvol-

vimento, ela cresce e se modifica ao longo do processo. Antes do início do sprint, o product backlog é avaliado para gerar o selected backlog, lista das funcionalidades que serão desenvol- vidas naquele sprint. As funcionalidades do selected backlog são então quebradas em tarefas gerando o sprint backlog. Tudo que acontece sob Scrum é realizado em um período fe- chado de tempo. Essa característica é denominada time boxing. As reuniões e outros eventos têm, todos, tempos definidos e fechados. Essa premissa é fundamental para quem deseja en- tregar software no menor tempo possível. A Figura 1 apresenta

a mecânica de um sprint completo.

A Figura 1 apresenta a mecânica de um sprint completo. Figura 1. Um sprint completo gerando

Figura 1. Um sprint completo gerando incrementos potencialmente implantáveis

Participantes do SCRUM e seus papéis

Uma das premissas de Scrum é a simplicidade. Isso se reflete nos papéis desempenhados pelas pessoas nesse processo:

são apenas três e não guardam entre si nenhum vínculo de hierarquia: são 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 legítimo representante deste. Sua presença, nos ciclos de planejamento, garante objetividade, foco e decisões acertadas

quanto ao rumo do projeto. Esse personagem fornece a visão

de negócio, encurtando o tempo de domínio do grupo sobre a área de negócio contemplada. Como é de seu exclusivo interes- se, ele maximiza o que se chama ROI (Return Of Investment), garantindo que o menor tempo e menores recursos serão usados no desenvolvimento das funcionalidades consideradas importantes. Em reuniões com sua presença é 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 próximo sprint. Também é responsabilidade do product owner esclarecer dú- vidas da equipe, assim como julgar sobre a aceitação ou recusa

de entregas intermediárias ou sobre o produto final.

O Scrum master tem um papel de destaque no processo.

Esse personagem deve exercer o que se denomina, liderança

servidora, ou seja, uma espécie de capitão de time. Embora a ele sejam atribuídas funções consideradas vitais, ele permane- ce como um membro da equipe, participando ativamente de seus sucessos e de suas dificuldades. Ele conduz as reuniões

e se assegura de manter o time box de cada uma delas, age

como facilitador para que cada membro da equipe remova obstáculos à execução de suas tarefas, empenha-se em manter

o Scrum funcionando e protege o Scrum team de ameaças ex-

ternas. Embora não vista a pele de um gerente convencional,

suas atribuições se revelam ainda mais delicadas do que as daqueles. Além de auxiliar o Scrum team e o product owner

em suas tarefas, cabe a ele manter-se atento ao planejamento

e aos objetivos do próximo sprint.

O Scrum team é a equipe de desenvolvimento. Dentro de um

Scrum team não 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 não é 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 ob- jetivos dos sprints diários e mensais. O grupo deve manter comunicação constante, formal, através das reuniões progra- madas, como se verá adiante, e informalmente, através de relacionamentos no ambiente de trabalho. Os Scrum teams devem ser formados de entre 7 a 9 pessoas. A definição desse número, além de basear-se em experiência pura, está funda- mentada no clássico “mítico homem/mês”: produtividade

MEtodoLogiAS ÁgEiS

não está associada unicamente ao tamanho da equipe.

Scrum team que desenvolve os incrementos que comporão

o software.

É o

A dinâmica do SCRUM

A partir das definições de elementos básicos e de integrantes

e papéis apresentada, pode-se descrever a dinâmica do pro-

cesso, 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 reuniões de time box de até 4 horas cada uma. A primeira delas é realizada apenas entre o Scrum master e o product owner. Nessa reunião, os integrantes verificam o pro- duct backlog, quanto à completude e quanto à priorização das funcionalidades descritas no documento. Essas tarefas são de responsabilidade do product owner. Itens no product backlog obedecem a um critério denominado “itens potencialmente implantáveis”, ou seja, itens totalmente operacionais que re- solvem algum problema de um ou mais stakeholders.

A segunda reunião do Sprint Planning Meeting é realizada

entre o Scrum master e o Scrum team, o time de desenvolvi- mento, embora o product owner possa ser convidado a parti- cipar. Nessa reunião, o time selecionará, do product backlog, os itens ou user stories que se comprometerão a desenvolver nos próximos 28 dias do sprint. Para fazer isso, as user stories são quebradas em tasks (tare- fas), que constituem, idealmente, trabalho que pode ser reali- zado em um sprint diário. Essa quebra em tarefas é baseada em estimativas de tempo com métricas próprias da metodo- logia, como será visto adiante, e gera como produto um sprint backlog. Aqui, destaca-se uma característica vantajosa do

Scrum em relação às metodologias mais clássicas. Sob Scrum, quem faz a estimativa de tempo é o desenvolvedor, aquele que efetivamente cria o código, enquanto que nas metodologias clássicas esta tarefa é realizada por analistas de sistemas que não estão necessariamente envolvidos com codificação. A prá- tica demonstra que a experiência acumulada pelo codificador torna-o significativamente mais apto para estimar tempo e esforço do que um simples aplicador de métricas. Logo após a criação do sprint backlog, o time pode adotar como ferramenta de apoio um quadro denominado taskboard, que reúne e organiza as tarefas em categorias: stories, tasks, tasks em execução e tasks completadas. A Figura 2 apresenta um exemplo de taskboard onde foi traçado um gráfico burndown, que atualizado diariamente, mostra a evolução do esforço empreendido e o esforço remanescente.

A partir desse primeiro dia de planejamento, seguem-se 28

dias de trabalho baseados no selected backlog ou sprint backlog. Cada dia típico de trabalho começa com uma reunião rápida

denominada Daily Meeting, com time box de no máximo 15 minutos, para não comprometer a produtividade da equipe. Nessa reunião, o Scrum master ouve a equipe e procura remover impedimentos ao bom cumprimento das tarefas

alocadas a cada membro. É nesse momento também que se faz a alocação de tarefas, atividade feita preferencialmente de forma livre e democrática entre os participantes, ou seja, cada membro da equipe escolhe uma ou mais tarefas que deverá realizar até o final do dia.

ou mais tarefas que deverá realizar até o final do dia. Figura 2. Taskboard com Curva

Figura 2. Taskboard com Curva Burndown

Para que tais reuniões sejam expressas e objetivas, elas devem preferencialmente ser realizadas com os participantes de pé. Cada participante deve refletir e expressar-se sobre três 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 próprio membro. O Scrum master não 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 heterogênea 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 reuniões de fechamento, ambas com time box de 4 horas. A primeira delas, o sprint review, constitui um importante ponto de con- trole do Scrum: é o momento no qual o time e o Scrum master demonstram as funcionalidades desenvolvidas ao product owner. Pode-se imaginar a importância capital desse encontro:

funcionalidades efetivamente operacionais aumentam não só

a motivação e a autoconfiança da equipe como aumenta a con-

fiança 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 definição que pode gerar controvérsias. 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 é admissível; 80% de uma tarefa não significam nada sob Scrum, já que a

metodologia é orientada a objetivos, e não a tarefas. A segunda reunião do último dia é igualmente um momento significativo do Scrum. Como prática focada em melhoria contínua do processo, contrariamente à rigidez de outras

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 próximo? Não se trata de uma reunião de mútuas acusações, e sim um momento de reflexão com espírito de equipe. Todas as medidas corretivas adotadas serão motivadas pela melhoria do processo de desenvolvimento e da produtividade da equi- pe. Podem existir resistências: faz parte do desenvolvimento da própria equipe atingir transparência capaz de produzir melhorias reais.

Comprometimento e envolvimento

Como já ficou claro, Scrum se esforça para planejar menos e realizar mais. E um dos fundamentos para alcançar essa meta

é a objetividade com que as diversas atividades devem ser

realizadas. Embora quase todas as reuniões contem com a pre-

sença dos três atores típicos do Scrum, o nível de importância de cada um deles varia, dependendo do evento, de envolvido

a comprometido ou neutro. Essa escala de importância pode

ser compreendida pela divertida fábula do porco e da galinha

mostrada na Figura 3.

fábula do porco e da galinha mostrada na Figura 3 . Figura 3. Fábula do porco

Figura 3. Fábula do porco e da galinha

De maneira semelhante, dependendo do evento, cada parti- cipante pode ter sua importância reclassificada, tornando-se mais ou menos influente. A cada evento típico de Scrum, são identificados os participantes do tipo ‘galinha’, ou seja, pessoas que estão ‘envolvidas’, os participantes do tipo ‘neutro’, que não influenciam os resultados do evento, e os participantes do tipo ‘porco’, aqueles que estão 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.

Métricas para estimativa de esforço

Metodologias tradicionais utilizam-se de métricas de esti- mativa de esforço, tamanho da equipe e tempo, como FPA (Function Points Analisys) ou COCOMO (COnstructive COst MOdel), também clássicas por sua vez. Em Scrum, as estimativas são feitas utilizando métricas aderentes à filosofia de trabalho do Scrum: agilidade. Para tanto, o método se vale de uma técnica intitulada history points, uma contagem de pontos que define um tamanho para cada estória de maneira relativa às outras estórias de mesmo

projeto. É, portanto, uma medida do tamanho geral de uma atividade, não absoluta. Como ferramenta para realizar essa pontuação, o Scrum team utiliza um baralho especial chamado Planning Poker, cujas cartas são numeradas com uma adaptação da sequência de

Fibonacci: 1/2, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Três cartas especiais marcadas com 0 (zero), ? (ponto de interrogação) e café comple- tam o baralho. O zero é usado quando a estória já foi concluída ou é muito pequena. O ponto de interrogação significa que o membro não faz a mínima idéia de valor para aquela estória e

o cafezinho indica que é melhor parar para um café antes de

prosseguir. Os valores não expressam uma unidade qualquer, seja de tempo, seja de esforço. Eles são usados para quantificar

o ‘tamanho’ de uma estória em relação às demais. Durante a segunda reunião do Sprint Planning Meeting, o Scrum team se ocupa em realizar uma sessão de Planning Poker, onde o product owner apresenta uma estória do pro- duct backlog e os integrantes do time escolhem, cada um baseando-se em sua própria experiência em codificação, uma carta com um valor para a atividade. As cartas são colocadas viradas para baixo no centro de uma mesa e depois viradas em conjunto. O objetivo é alcançar um valor de consenso. Para tanto, os valores são comparados e as discrepâncias são

defendidas por seus autores: o autor da mais alta pontuação e

o autor da mais baixa pontuação. Logo após as breves defesas

apresentadas, é realizada uma nova rodada de pontuação, na qual todo membro pode manter o valor de sua carta, aumentá- lo ou diminuí-lo. Duas ou três rodadas podem ser suficientes para alcançar um valor de consenso. Embora a técnica seja baseada em uma pontuação relativa, ela só faz sentido se uma medida de velocidade for introduzida, ou seja, é necessário estabelecer um número de estórias entregues pela equipe em uma iteração. Embora esse número possa variar bastante com a natureza do sistema, recorrência do tema ou originalidade da solução, um número médio de capacidade da equipe pode ser derivado dos históricos acumulados pelo time ao longo de projetos. Com essas duas medidas é possível criar um cronograma de trabalho realizável.

Ao decidir sobre a pontuação de uma determinada story, cada membro da equipe deve considerar três fatores relativos

a ela: complexidade, esforço e incerteza. É preciso estar atento para o fato de duas stories poderem apresentar uma mesma pontuação, mas uma delas ter muito mais complexidade do que

a outra. Em termos práticos: alta complexidade e baixo esforço podem produzir uma contagem idêntica a baixa complexidade

e alto esforço.

Características adicionais do SCRUM

Scrum é uma metodologia baseada em simplicidade e adap- tabilidade. Um fundamento dessa filosofia é a manutenção da base desse conceito: equipes gerenciáveis. A maioria dos livros aponta equipes de no máximo 9 pessoas, multidisciplinar e motivada. Mas é inescapável a existência de projetos onde essa força de trabalho tem de ser multiplicada, devido ao tamanho do sistema sendo desenvolvido.

MEtodoLogiAS ÁgEiS

Aumentar uma equipe de 8 pessoas para 25 descaracteriza

o ideal do Scrum team e torna a equipe não gerenciável. Para

lidar com essas situações, o Scrum preconiza a prática Scrum de Scrums (Scrum of Scrum). As equipes são mantidas com

no máximo 9 pessoas e é formado um novo grupo com um membro de cada equipe, geralmente seu Scrum master. Scrum de Scrum então é a realização de encontros entre Scrum masters com a finalidade divulgar conhecimento entre os diversos times. A mecânica dessa reunião é bastante pereci- da com a dos daily Scrums, mas com foco na equipe ao invés de foco pessoal. Em outras palavras, cada Scrum master relata

o que a equipe fez nos sprint diários da última semana (se os encontros Scrum de Scrum forem semanais); o que a equipe fará nos sprints diários da próxima semana; existem impedi- mentos ao trabalho da equipe? A finalidade desses encontros

é manter as equipes sincronizadas e permitir o gerenciamento da totalidade e, principalmente, das sobreposições.

É claro que existem pontos que merecem atenção especial

como gerenciar o desenvolvimento do mesmo código fonte por duas ou mais equipes de trabalho. As estratégias para o enfrentamento dessas dificuldades são da responsabilidade dos Scrum masters reunidos. Reuniões Scrum de Scrum devem ser realizadas diariamente, sempre após as daily scrums. Mas se isso não for possível, um quarto questionamento deve ser investigado por cada um dos Scrum masters presentes: há algum impedimento que

você esteja preparando para introduzir nos próximos sprints diários? Essa pergunta procura adiantar os passos de uma semana, por exemplo, para que nenhuma equipe seja pega de surpresa por ações de outra.

A maneira de gerenciar Scrum de Scrum pode ser aplicada

em diversos níveis, até que a estrutura seja capaz de realizar o projeto de desenvolvimento em questão. Assim, pode-se chegar

a Scrum de Scrum de Scrum, e até além. 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.

Conclusão

Metodologias de desenvolvimento de sistemas existem às de- zenas. Um grande empecilho a um grande painel comparativo

é

a diferenciada natureza dos sistemas de informação. É no

mínimo arriscado afirmar que essa ou aquela metodologia é mais ou menos eficiente que outra. Parece sempre mais equi- librado perceber que cada uma delas tem qualidades e falhas,

e que sua aplicabilidade sempre depende de uma série não

trivial de fatores de influência. Outra abordagem interessante, considerando metodologias de desenvolvimento de sistemas, é nunca considerá-las e aplicá-las de forma dogmática, ou seja, sem admitir adaptações. Equipes e profissionais criativos sempre foram o diferencial em se tratando de inovações, o próprio Scrum é prova disso. De qualquer forma, a adoção de metodologias mais tradicionais

ainda pode se fazer necessária quando o projeto for altamente dependente de grande documentação, quando as equipes de

desenvolvimento forem realmente muito grandes, quando o produto sendo desenvolvido possuir um conjunto de requisitos muito amplo mas relativamente estável, e quando o tempo esti- mado para realização do trabalho for realmente significativo. Em

qualquer dessas situações, os diversos grupos de stakeholders irão 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. Não há como negar a evolução signifi- cativa das práticas de gerência introduzida por elas. Trazem benefícios a uma ampla faixa de projetos onde a presteza com que se entrega o produto é um fator crítico de sucesso. Mas não se deve confundir presteza com pressa! SCRUM se fun- damenta em foco no objetivo, mas fixando qualidade e tempo. Sob SCRUM a qualidade é um fator não negociável! Existem pelo menos cinco valores fundamentais do Scrum:

foco, abertura de espírito, comprometimento, respeito e cora- gem. O que são premissas dessa metodologia pode também 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. Não que isso não seja possível alcançar, mas existem desafios a vencer para formar equipes com esse perfil. Os membros de um time Scrum típico são atípicos, ou seja, não se encontram diariamente nos classificados de profissionais à procura de emprego. De qualquer forma pode-se esperar que, no futuro, a própria adoção de novas metodologias torne o encontro desses profissionais mais comum. Aos cinco fundamentos acima, que caracterizam Scrum como metodologia inovadora de gerência de projetos de TI, podem-se somar mais seis, que dão 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 capa-

cidade de auto-gerenciamento, o que acaba por desenvolver as

pessoas em relação às suas próprias capacidades e limitações, confiança na sua própria competência e na prática saudável de poder trabalhar nas atividades que escolheu, sem imposições (parece um pouco de conto de fadas, mas é possível!);

• comunicação eficiente, pessoas falando com pessoas, torna mais agradável o dia a dia do profissional;

• atividades desenvolvidas com tempo pré fixado, aguçando

o sentido de responsabilidade e compromisso;

• menos planejamento e mais ação, menos papel e mais código,

sem jamais abrir mão da qualidade; e finalmente;

• a quebra de um paradigma que persegue a décadas os

desenvolvedores de sistemas de computação: o cliente não é inimigo, mas parceiro.

De sua atuação espera-se que a equipe percorra no menor tempo o caminho até a compreensão suficiente pra produzir um resultado final que atenda ou supere as expectativas de seu financiador.

 

Links

ManifestoÁgil

http://agilemanifesto.org/

Artigo “Introduction to Scrum - An Agile Process” http://www.mountaingoatsoftware.com/Scrum

E-book “Scrum e XP direto das Trincheiras” http://www.chrisb.com.br/files/ScrumeXPdiretodasTrincheiras.pdf

s k o c a b b r d e Dê seu feedback sobre esta
s
k
o
c
a
b
b
r
d
e
Dê seu feedback sobre esta edição!
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, através do link:
e
www.devmedia.com.br/esmag/feedback
e
e
s
F
t
a
u
e
e
d
s
i
ç
ê
ã
D
o

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Uso de metodologias ágeis em uma organização baseada em linha de produto Um relato de
Uso de metodologias ágeis em uma
organização baseada em linha de produto
Um relato de experiência
baseada em linha de produto Um relato de experiência Giselle Tavares gitavares@hotmail.com Possui bacharel em
baseada em linha de produto Um relato de experiência Giselle Tavares gitavares@hotmail.com Possui bacharel em

Giselle Tavares

gitavares@hotmail.com

Possui bacharel em Ciência da Computação pela UNICAP e especialização em Gestão Á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 Me- lhoria de Software.

Felipe Furtado

felipe.furtado@cesar.org.br

Possui especialização em TI e mestrado em Ciências da Computação pelo Centro de In- formática da UFPE. Atualmente é doutoran- do no CIn, Gerente de Projetos do C.E.S.A.R, coordenador da pós-graduação em Gestão Ágil de Projetos do CESAR.EDU e docente do Mestrado Profissional em engenharia de software.Tem experiência há 14 anos na área de Engenharia de Software,com ênfase em Qualidade de Software e Gestão de Pro- jetos,atuando principalmente nos seguintes temas: Melhoria de Processos de Software, Modelos de Maturidade,Metodologias Ágeis e Estratégias de Melhoria de Produtividade.

N a última década as metodolo- gias ágeis vêm ganhando es- paço no mercado de Tecnologia

da Informação e Comunicação. Várias pesquisas mostram os bons resultados alcançados 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 organizações (53%), seguida do uso em conjunto com o XP (17%). Nesta mesma pesquisa, a adoção

De que se trata o artigo?

Com a necessidade de tentar melhorar os processos de desenvolvimento de software e acompanhando as tendências da Engenharia de Software, que trouxe mais visibilidade aos métodos ágeis, várias empresas optaram por implantá-los em sua organização, po- rém de maneira desordenada. Este relato descreve a implantação de metodologias ágeis em uma organi- zação baseada em linhas de produto e, com base nos resultados alcançados, propõe uma adaptação com o uso de Scrum, XP e Kanban.

Em que situação o tema é útil?

Em ambientes baseados em linhas de produto que possuem uma grande diversidade de clientes com prioridades diferenciadas e que necessitam de adaptações em seus processos de desenvolvi- mento de software.

conjunta de Scrum e Kanban (3%) come- ça a ser percebida. No entanto, algumas empresas encon- tram dificuldades na implantação das metodologias, ora por falta de conheci- mento, ora por dificuldade na adaptação de tais metodologias ao contexto de seus projetos. Por exemplo, empresas baseadas em linhas de produto possuem

características que dificultam a adoção de iterações de tamanho fixo e escopo fechado, conforme definido pelo Scrum. Este artigo relata a experiência de uma empresa baseada em linha de produto que iniciou a implantação de metodologias ágeis a partir do Scrum e, em seguida, a prática Pair Program- ming, originada do XP. A opção pelo Scrum veio para auxiliar no gerenciamento do projeto, percebendo-se que a equipe de desenvolvimento estava crescendo para suprir às demandas de customizações, e o Pair Programming para diminuir a curva de aprendizado dos novos integrantes da equipe. A partir da análise de alguns problemas, este artigo sugere a utilização de um processo adaptado em conjunto com o Scrum e Kanban,

a fim de preencher lacunas nas quais as limitações das meto-

dologias implantadas não supriram. Este relato está organizado da seguinte maneira: inicial- mente são apresentados os conceitos sobre Linha de Produto, Scrum, XP e Kanban. Em seguida, é apresentada a análise da implantação do Scrum e do Pair Programming na empresa aqui estudada, e uma proposta para adaptação do processo implantado com o Kanban.

para adaptação do processo implantado com o Kanban. Figura 1. Metodologias ágeis mais utilizadas [7] Linhas

Figura 1. Metodologias ágeis mais utilizadas [7]

Linhas de Produto

Empresas de Linhas de Produto são aquelas que produzem um software possível de ser utilizado por segmentos de mercado diversos, mas que pode ser adaptável para cobrir as necessidades específicas de seus clientes, pensando ainda no valor de negócio como um todo. De acordo com o Software Engineering Institute, uma linha de produto utiliza técnicas e práticas de engenharia para criar um conjunto de sistemas que compartilham caracte- rísticas comuns, satisfazendo as necessidades específicas de um determinado segmento do mercado ou missão, e que são desenvolvidos a partir de um núcleo comum de maneira prescrita. Tem como atividade principal a integração ao invés do desenvolvimento.

Metodologias Ágeis: Scrum, XP e Kanban

Uma metodologia deve ser considerada ágil quando ao invés de tentar prever o futuro, aceita as mudanças naturalmente.

Aceitar mudanças nesse contexto ágil significa saber recebê-las

e respondê-las a custos menores [6].

O Scrum é um framework para planejamento e acompanha-

mento de projeto que segue os princípios do Manifesto Ágil. Por ser iterativo e incremental, ele funciona bem em um

ambiente de constante mudança. Provê equipes autogeren- ciáveis e propõe uma forma de trabalho flexível e adaptável, não apenas em relação ao escopo e requisitos de um projeto, mas também quanto à troca de equipes, de ferramentas, de linguagens de programação, etc. [4].

O XP (eXtreme Programming) é uma metodologia ágil vol-

tada para a Engenharia de Software, dando mais atenção à programação, e não tanto ao gerenciamento, como é o foco do

Scrum, motivo pelo qual normalmente são metodologias uti- lizadas juntas [3]. Foi criado por Kent Beck em 1996 e busca aprimorar um projeto de software utilizando cinco valores essenciais: comunicação, simplicidade, feedback, respeito e coragem. Foram definidas 12 práticas, sendo uma delas o Pair Programming, que consiste em juntar dois desenvolvedores em um único computador, concentrando-se no mesmo códi- go. Isto irá fazer com que a qualidade do software aumente, mas sem impactar na entrega. O principal benefício passa a ser a disseminação do conhecimento entre o time.

O Kanban traz consigo a filosofia do JIT (Just In Time) –

veja Nota 1, que significa produzir apenas o necessário, no tempo necessário, na quantidade necessária, e no local necessário, com qualidade e envolvimento das pessoas, eli- minando assim o desperdício, e garantindo o fluxo contínuo de produção [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 previsível e eleva a expectativa da entrega com maior nível de qualidade. Além disso, sendo um sistema puxado, facilmente se verifica onde está o gargalo no fluxo de trabalho. Ainda de acordo com Anderson, Kanban não é um processo de ciclo de vida de

gerenciamento de projeto ou de desenvolvimento, mas sim uma abordagem para gerenciar mudanças.

Nota 1: Just In Time JIT,ou Just In Time,é um sistema de administração da produção
Nota 1: Just In Time JIT,ou Just In Time,é um sistema de administração da produção

Nota 1: Just In Time

Nota 1: Just In Time JIT,ou Just In Time,é um sistema de administração da produção que
Nota 1: Just In Time JIT,ou Just In Time,é um sistema de administração da produção que

JIT,ou Just In Time,é um sistema de administração da produção que determina que nada deve ser produzido, transportado ou comprado antes da hora exata. Pode ser aplicado em qualquer organização para reduzir estoques e os custos decorrentes.

Nota 2: Work In Progress WIP, ou Work In Progress, define o limite para quantos
Nota 2: Work In Progress WIP, ou Work In Progress, define o limite para quantos

Nota 2: Work In Progress

Nota 2: Work In Progress WIP, ou Work In Progress, define o limite para quantos itens
Nota 2: Work In Progress WIP, ou Work In Progress, define o limite para quantos itens

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

Análise sobre o processo de implantação

Nesta seção será contextualizada a empresa analisada e será relatado o processo de implantação do Scrum, realizado há pouco mais de um ano, assim como os benefícios e as lições aprendidas. Por questões de confidencialidade, a empresa analisada não será identificada.

Características da Organização

A empresa estudada existe a mais de 20 anos no mercado

e dedica-se ao desenvolvimento de sistemas de gestão em diversas áreas de atuação em todo o território nacional. Sua matriz está localizada no Nordeste, e possui cerca de 250 funcionários. O processo analisado é utilizado para o de- senvolvimento 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 construção. O produto possui versões liberadas a cada dois meses e releases libe- rados para o cliente semanalmente. Cada liberação de uma nova versão é considerada um projeto, que por sua vez, se dá através do backlog do produto, com as datas de cada customi- zação já acordadas com os clientes, baseadas em estimativas realizadas pela equipe.

O Processo de Implantação do Scrum

A necessidade da implantação de métodos ágeis no ambiente

de trabalho deu-se ao serem observadas as dificuldades que o gerente de projetos vinha tendo ao tentar acompanhar o anda- mento de um projeto de um produto que estava crescendo em número de clientes. Este crescimento aumentou a demanda por customizações, que por consequência, trouxe a necessidade de aumentar também o número de colaboradores na equipe. Pelo processo corrente, o Analista de Sistemas deveria gerar uma série de artefatos para auxiliar o desenvolvimento, testes, do- cumentação, capacitação etc., além de estimar customizações, que era um procedimento longo o suficiente para um cliente desistir de esperar por um retorno. Para o Gerente de Proje- tos, acompanhar o andamento das atividades de dezenas de colaboradores era impraticável. A partir dessas situações, após 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 adaptação

do processo.

do Scrum utilizado como base para a adaptação do processo. Figura 2. Visão Geral do Processo

Figura 2. Visão Geral do Processo do Scrum

A primeira providência foi reunir os gerentes de diversas

áreas envolvidas no produto e explicar como funcionaria essa nova maneira de trabalhar. A reação dos gerentes de teste, de desenvolvimento e de projetos foi: e qual será a

MEtodoLogiAS ÁgEiS

minha função agora? Como vou acompanhar o projeto? Os Scrum Masters agora serão 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 possuía uma equipe em um local definido da empresa, e viu que com o Scrum o time de testes deveria ser distribuído em equipes. Os analistas de negócio foram escolhidos para serem os Product Owners (PO). Neste cenário, não 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 função deles como PO é passar aos times o backlog da Sprint, considerando que existe um cronograma do projeto com ocorrências em ordem de prioridade para cada módulo do produto, além de expli- car os requisitos. Sendo vários times e vários POs, apesar de cada time ter seu próprio PO dedicado, estes se reúnem antes da reunião de planejamento de Sprint para se alinharem e identificar possíveis impactos entre solicitações. Foram escolhidos para serem Scrum Masters, inicialmente, os analistas de sistemas com maior experiência em cada mó- dulo, mas sem deixar as suas funções originais. Por serem bastante solicitados para resolver problemas e constantes viagens para atender aos clientes, alguns deles foram subs- tituídos, pois não conseguiam desempenhar o novo papel adequadamente. A escolha de novos Scrum Masters foi feita novamente pela gerência, e o critério utilizado foi também o tempo na empresa e conhecimento, mas dessa vez, eles deveriam ter perfil de líder. Os desenvolvedores e testadores foram separados por módulos para que se formassem os times. O número de colaboradores no início, 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 customizações 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 negócio para as equipes de novatos, foi aplicada a técnica do Pair Programming, além da tentativa de dedicação do Scrum Master como líder técnico e de negócio para fazer mento- ring com os times. Essa experiência durou seis meses. Em princípio, a escolha das duplas foi aleatória. Na primeira troca de duplas, o critério foi juntar um membro do Time que tinha um conhecimento técnico e de negócio melhor, com outro com menor conhecimento. Dos artefatos de desenvolvimento e testes até então neces- sários, Especificação de Requisitos, Projeto de Implementa- ção, Estimativa de Testes, Documento de Visão, entre outros, passaram a não ser mais utilizados, considerando que todas essas informações eram passadas via Reuniões de Planeja- mento de Sprint 1 (especificação) e 2 (técnica). Porém, durante a Execução da Sprint, o time passou a sentir falta dos artefatos mencionados. Os analistas de sistemas passaram a ser mais requisitados que o normal, além de

desempenharem o papel de Scrum Masters. Várias maneiras de se registrar o que era discutido na Sprint foram executadas. Desde gravar as reuniões até a criação de ata em tempo real. Porém, o que se manteve foi uma planilha que dividia cada item de backlog, informando basicamente a sua descrição, critério de aceitação, complexidade estimada e descrição técnica, que era preenchida durante a reunião. Ainda durante a reunião de planejamento da Sprint, outra dificuldade encontrada pelos times é que, por não saberem

o que seria pedido na Sprint, não se preparavam antes. Não

em razão do entendimento do requisito, que seria passado pelo PO, mas sim pelo que seria discutido na Reunião de Planejamento 2. Entender os requisitos não era suficiente para saber rapidamente quais fontes, telas, tabelas etc., deveriam ser utilizados. Ou ainda, se havia alguma particu-

laridade, antes mesmo de definirem a melhor solução para customizar a solicitação. Sendo assim, resolveram utilizar uma planilha própria de estimativa para auxiliá-los nesta segunda reunião de planejamento, considerando que esta continha informações técnicas de cada customização.

A partir de um estudo do histórico das estimativas, e pelo

conhecimento dos analistas de negócio, 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 incluído no cronograma. Com o início da implantação do Scrum, o time era quem dizia ao PO o que cabia na Sprint, mas quando o final do projeto se aproximava, muitas solicitações ainda precisavam ser concluídas. 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 reunião de Planejamento 1 passou a ser apenas para entendimento, e a estimativa através do Planning Poker se manteve somente para saber se todos esta- vam entendendo o requisito, ou seja, caso houvesse alguma forte divergência de estimativas entre os participantes, esses levantavam seus pontos de vista.

O comprometimento do time passou a ser na Reunião de

Planejamento 2. Nessa reunião apenas o time se reúne, e tem

a chance, a partir da verificação técnica do que será imple- mentado, de reestimar as ocorrências, em horas, conforme

a Planilha de Estimativa, e argumentar que podem não

conseguir entregar a Sprint. Neste caso, ao final da reunião,

o PO é chamado para que a negociação seja feita. Durante a execução das atividades do time, foi percebido que nem todos focavam na mesma estória, isto porque às vezes não era possível dividi-la, ou porque era pequena, ou por impossibilidade técnica. A partir dessa situação, foi percebida uma maneira de obter mais comprometimento da equipe, sendo possível organizar a Reunião de Entrega de modo que quem apresentava determinada estória, era quem a havia desenvolvido. Quanto à reunião de Retrospectiva, logo no início em que passou a ser realizada sem o acompanhamento do SEPG

(Software Engineering Process Group) – Nota 3, não era utili- zada para melhoria do time no que se refere à entrega da Sprint com qualidade. Eram discutidos problemas de baixa relevância ao melhoramento de fato da produtividade do Time. Essa reunião, com o passar do tempo, passou a não 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 responsável pela definição, manutenção e melhoria do processo de Engenharia de Software.

 

Para tentar melhorar o foco dessa reunião, foi criado um ar- tefato específico para preenchimento em tempo real de ações de melhoria, separando-as por descrição, responsável e prazo. As ações de âmbito organizacional também eram indicadas no documento para que fossem periodicamente cobradas. Além disso, foi pedido pelos times que esta reunião fosse mensal, e não mais por Sprint. O motivo dado foi o fato des- sas Sprints quase nunca serem finalizadas corretamente, em consequência das suas constantes e inevitáveis mudanças de escopo. Logo, eles não viram necessidade em discutir o porquê de uma iteração não ter dado certo, mas sim em focar nos Bugs gerados, para tratarem das causas.

Lições Aprendidas

 

Os benefícios encontrados com a utilização do Scrum e do Pair Programming foram bons tanto do ponto de vista geren- cial quanto técnico. Problemas antes camuflados apareceram por conta da visibilidade aumentada, fundamental para a melhoria contínua. Toda a equipe do projeto passou a se envolver mais durante todo o ciclo. Antes da utilização das metodologias ágeis, os desenvolvedores apenas recebiam do analista de sistemas o Plano de Implementação, que possuía o local exato de alteração do código. Resumidamente, o desenvolvedor não possuía a oportunidade de dar opiniões a respeito das solu- ções, e o conhecimento ficava concentrado nos analistas. A integração entre a equipe de desenvolvimento e teste foi bastante benéfica. Não era mais necessário aguardar a libe- ração de um executável para que a equipe de testes iniciasse suas atividades. Neste novo formato de processo, logo que uma implementação é concluída, o teste é iniciado e, caso algum problema seja encontrado, a correção é imediata. Pessoas de outros departamentos passaram a frequentar as reuniões de planejamento e entrega como ouvintes. Isto fez com que as interrupções aos analistas de sistemas e de- senvolvedores para entenderem as funcionalidades fossem diminuídas. Quanto às solicitações de customização, estas vêm por vários canais, dependendo do tipo de ocorrência (evoluti- va, correção, customização legal, etc.) e do cliente. Alguns especialistas (que são os POs das equipes) são dedicados a alguns clientes, independente do módulo (utilizado para

30

Engenharia de Software Magazine - Uso de metodologias ágeis em uma organização baseada em linha de produto

divisão das equipes). Considerando esses fatores, além das solicitações da Sprint, havia gerentes cobrando correções de Bugs, especialistas cobrando prioridade para as ocorrências de seus clientes, e mais cobranças por outros stakeholders. Isso fazia com que o time perdesse o foco da Sprint, e o ScrumMaster passasse a gerenciar priorizações, trazendo uma série de problemas, como por exemplo, a não entrega do que foi planejado para a iteração.

A disseminação do conhecimento aconteceu através da

técnica de Pair Programming. Ela foi aplicada nas equipes compostas apenas por novatos, porém lideradas por um Analista de Sistemas com amplo conhecimento técnico e de negócio. 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 aplicação foi uma curva de aprendizado menor, comparando-se às experiências anteriores, sem a utilização desta técnica.

Proposta de adaptação do processo

Mesmo após a implantação das práticas ágeis relatadas anteriormente, algumas pessoas ainda sentiam necessidade de novas adaptações no processo, principalmente em fun- ção do alto índice de solicitações de mudança por parte de

diversos clientes. Diante disto, a sugestão para tentativa de melhoria de processo de desenvolvimento da empresa ana- lisada é então manter algumas práticas do Scrum e utilizar

o Kanban por completo.

O que deverá ser mantido do Scrum são as reuniões de

planejamento, reuniões diárias, reuniões de entrega e re-

trospectiva, além dos papéis do Scrum Master e do PO. O

que deverá ser rejeitado são as Sprints, o gráfico Burndown

e as estimativas por complexidade, que utilizam o Planning Poker.

A sugestão de retirada das iterações vem da realidade de

que as equipes não conseguem entregar as Sprints conforme acordado com o PO, porque solicitações consideradas urgen- tes aparecem, deixando o time sobrecarregado e sem espaço para concluir o prometido. A negociação para troca das solicitações quase nunca acontece, pois estas, na maioria das

vezes, tiveram seus prazos postergados por diversas vezes.

O Scrum admite mudanças, porém no backlog do produto, e

não no backlog da Sprint. Apesar de oficialmente as releases serem liberadas em um determinado dia da semana fixo,

podem haver outras liberações durante a mesma semana, ou mesmo atrasos. Além disso, pode acontecer de nem todas as equipes terem liberações a fazer durante este período.

O quadro apresentado na Figura 3 foi proposto para uma

equipe com dois Analistas de Sistemas, seis Desenvolvedo- res e quatro Testadores. Na Figura 3, o quadro possui duas linhas de fluxos. Uma para o desenvolvimento e outra para a análise de requisi- tos. Isto foi necessário, pois para determinados tipos de ocorrências, o cliente exige uma Especificação de Requisi- tos e um Protótipo, para que seja validado, e só assim ser

MEtodoLogiAS ÁgEiS

encaminhada ao desenvolvimento. As definições iniciais do WIP foram determinadas considerando a quantidade de mudanças existente, por isso o valor 3 para a coluna Selecionados, e a quantidade de colaboradores no Time de

acordo com sua função. Na coluna Backlog, o PO estaria à vontade para disponi- bilizar as solicitações, na ordem de prioridade. Na coluna Selecionados, o PO deverá disponibilizar as próximas so- licitações que deverão ser implementadas. A separação das colunas Backlog e Selecionados é para que o Time mantenha

o foco. Dessa forma, o Time estaria à vontade para realizar

as reuniões de Planejamento, mesmo não existindo mais Sprint. Essas solicitações selecionadas seriam explicadas pelo PO e, após isto, a reunião técnica aconteceria. Assim, pretende-se manter a disseminação de conhecimento.

Assim, pretende-se manter a disseminação de conhecimento. Figura 3. Quadro Kanban como sugestão de utilização na

Figura 3. Quadro Kanban como sugestão de utilização na empresa analisada

A coluna Desenvolvimento foi dividida em duas partes:

Iniciado e Pronto, facilitando o entendimento do que foi concluído ou não pelo desenvolvimento, para em seguida, os responsáveis pelos testes iniciarem suas atividades. Ao concluir os testes, a solicitação estaria pronta. Este teste exe- cutado é o teste unitário. Existe ainda o teste de integração realizado em outro momento. Para utilização do fluxo de Análise, estarão no Backlog apenas aquelas solicitações que necessitarão, antes do de- senvolvimento, dos artefatos de Especificação de Requisitos e/ou Protótipo, caso o cliente os requisite para validação. Levando em consideração a não utilização de iterações, o gráfico Burndown perde o sentido. Neste caso, outro gráfico de acompanhamento, como o diagrama de Fluxo Cumulati- vo, poderá ser utilizado. Independente da existência de iterações, periodicamente os releases precisam ser liberadas para os clientes. Dessa maneira, se mantém a reunião de entrega para que a vali- dação das solicitações seja feita.

A sugestão de manter a reunião de Retrospectiva é para que

as melhorias continuem sendo buscadas. Com o quadro Kan-

ban, durante a execução das atividades, os gargalos ficarão mais visíveis, já que o WIP estará funcionando de maneira

a bloquear o andamento das fases anteriores, até que pos-

síveis impedimentos sejam tratados nos passos seguintes.

Caso isso aconteça, a etapa atingida negativamente será de fácil identificação, e seus problemas deverão ser discutidos na retrospectiva do time.

Conclusões

A utilização de métodos á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 relação ao cenário aplicado. Apesar das implantações do Scrum e do Pair Programming não terem sido inseridas na empresa de forma correta, seja por falta de treinamento adequado, ou mesmo por práticas descartadas, após algumas análises, percebeu-se que o Scrum, sem algumas modificações ou sem a ajuda de outro método, não iria funcionar. Sendo assim, dentre todos os métodos estudados, a proposta de inclusão do Kanban aos processos dessa empresa, junta- mente com adaptações do Scrum aqui sugeridas, em princípio, poderá atenderá as lacunas existentes. Essas adaptações pro- postas serão aplicadas e uma nova análise será realizada, com foco na melhoria contínua do processo de desenvolvimento de software baseado em linha de produto.

 

Referências

1.

Ambler, S. (2008, 2010) “Agile Survey”.

http://www.agilemodeling.com/

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.

k c s a b o d b Dê seu feedback sobre esta edição! A
k
c
s
a
b
o
d
b
Dê seu feedback sobre esta edição!
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, através do link:
e
www.devmedia.com.br/esmag/feedback
r
e
e
F
e
u
s
t
e
a
s
e
ê
d
i
D
ç
ã
o

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros
Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Modelagem de processos usando ARIS Architecture of Integrated Information Systems
Modelagem de processos usando ARIS
Architecture of Integrated Information Systems
usando ARIS Architecture of Integrated Information Systems Wellington Moreira de Oliveira
usando ARIS Architecture of Integrated Information Systems Wellington Moreira de Oliveira

Wellington Moreira de Oliveira

wellington.moreira@ifsudestemg.edu.br

Mestrando em Ciência da Computação pela Universidade Federal de Viçosa (UFV). Especialista em Engenharia de Software e Bacharel em Sistemas de Informação pelo Centro de Ensino Superior de Juiz de Fora (CES). Atualmente é Professor/Pesquisador do Departamento de Ciência da Compu- tação do Instituto Federal de Educação, Ciência e Tecnologia do Sudeste de Minas – Campus Rio Pomba.Áreas de interesse:Sis- temas de Informação com foco em Infraes- truturas de Dados Espaciais e Engenharia de Software com foco em Processos.

José Luis Braga

zeluis@dpi.ufv.br

Pós-doutoramento em Tecnologias da Infor- mação na University of Florida (1988-1999). Doutor em Informática-Departamento de Informática da PUC-Rio (1990). Mestre em Ciências da Computação-Departamento de Ciência da Computação da UFMG (1980). Atualmente é Professor Titular do Departa- mento de Informática do Centro de Ciências Exatas e Tecnológicas da Universidade Fede- ral de Viçosa-MG. Atua na área de Ciência da Computação, com ênfase em Engenharia de Software e Sistemas de Informação. Áreas de Interesse: Qualidade de Software com Foco em Processos,Engenharia de Software Experi- mental, Engenharia de Software Apoiada por Ontologias, Engenharia de Software Baseada em Agentes,Sistemas de Apoio à Decisão.

Software Baseada em Agentes,Sistemas de Apoio à Decisão. Ronney Moreira de Castro ronneymc@gmail.com Mestrando e

Ronney Moreira de Castro

ronneymc@gmail.com

Mestrando e Especialista em Ciência da Computação pela Universidade Federal de Viçosa (UFV). Atua a mais de 13 anos no mercado de informática com desenvolvi- mento de software. Atualmente é Analista de Sistemas da Prefeitura de Juiz de Fora e Professor do Curso de Sistemas de Informa- ção do Instituto Metodista Granbery. Áreas de Interesse:Engenharia de Software,Qua- lidade de Software,Processos de Desenvol- vimento de Software.

A s empresas de hoje estão cada vez mais voltando sua atenção para os mercados emergentes

com o objetivo de conquistar clientes. A

qualidade de seus produtos deve ter um grau elevado de aceitação e qualidade e, para isso ser possível, é necessário possuir processos bem definidos e que sejam seguidos por toda a corporação. O Aris (Architecture of Integrated Information Systems) é uma platafor- ma completa de modelagem, controle e execução de processos, capaz de fornecer uma base para qualquer empresa orga- nizar, manter e inovar seus processos ao longo do tempo. Neste artigo, primei- ramente, será apresentada uma visão

De que se trata o artigo?

A modelagem de processos é hoje o principal mo- tor da organização para melhoria contínua de seus processos internos e externos. Neste contexto, o objetivo deste artigo é esclarecer os diversos aspec- tos e benefícios da modelagem e gerenciamento de processos utilizando o ARIS (Architecture of In- tegrated Information Systems).

Em que situação o tema é útil?

A modelagem de processos com ARIS pode ser aplicada nos mais diversos ambientes corporati- vos, visto a aplicabilidade universal do gerencia- mento de processos.

geral sobre o que é processo e qual o seu relacionamento com a indústria. Em se- guida serão apresentados os conceitos de modelagem e como utilizar a Plataforma ARIS para este propósito.

Um pouco de história

Na antiguidade, o homem descobriu que era necessário conviver em socieda- de. Nesse momento da história algumas pessoas encontraram oportunidade para um processo de comercialização de produtos e serviços com outros grupos.

Mais tarde as estruturas empresariais formais cresceram for- mando o grande sistema monetário que é conhecido hoje, onde o objetivo principal é o lucro. Isso demonstra que a finalidade principal tanto dos proprietários quanto dos empregados de uma organização é a geração do retorno financeiro em troca de tempo e recursos financeiros investidos [2]. Cada tipo de negócio disponibiliza produtos ou serviços diferentes para seus clientes com o objetivo de gerar lucro em forma de vendas e, além disso, agregar um valor final que pode ser criado de formas diferentes dependendo do tipo de negócio. Um exemplo é um lojista cujo principal ideal é a en- trega de produtos de qualidade para seu público alvo. Outro exemplo é do fabricante de veículos que consiste na produção de diferentes tipos e modelos de carros para atender necessi- dades e desejos diferentes de seus clientes. Com o crescimento da competição entre as empresas por diferentes mercados, recursos e competências, somente aquelas capazes de fornecer valor para seus clientes poderão sobreviver. Henry Ford disse: “O cliente pode ter o carro da cor que quiser, contanto que seja preto” [2]. Dessa forma, os clientes não pode-

riam expressar seus requisitos individuais, pois a cor era única.

O principal objetivo de Ford era alcançar uma maior eficiência

em termos de tempo e custo usando o conceito de “linha de pro- dução” ou “linha de montagem” repetindo continuamente uma sequência de tarefas. Através desse processo de decompor uma grande tarefa em pequenas tarefas mensuráveis, Ford reduziu

drasticamente o custo da produção. A cor preta possuía uma secagem mais rápida, com isso o valor era reduzido e o veículo poderia ser vendido por um preço menor. Ideias semelhantes podem ser associadas a Frederick Winslow Taylor com seu “Taylorismo” [11] que continua influenciando organizações até

os dias de hoje.

Praticamente tudo o que é feito em negócios é dirigido por processos. Até mesmo as pessoas têm 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 indústria da manufatura para outros setores como, por exemplo, o financeiro. Tudo o que é feito em uma organização que possa gerar valor, oferecendo produtos e serviços, é controlado por processos. Ge- renciar esses processos implica em verificar e analisar detalhada- mente atividades importantes e recursos da companhia, tais como mercado, tarefas, pessoas, transações financeiras, etc [8].

Nota 1. ad-hoc Neste contexto, o termo ad-hoc se refere a ciclos de construção de
Nota 1. ad-hoc Neste contexto, o termo ad-hoc se refere a ciclos de construção de

Nota 1. ad-hoc

Nota 1. ad-hoc Neste contexto, o termo ad-hoc se refere a ciclos de construção de software
Nota 1. ad-hoc Neste contexto, o termo ad-hoc se refere a ciclos de construção de software

Neste contexto, o termo ad-hoc se refere a ciclos de construção de software ou processos que não foram devidamente projetados em função da necessidade de atender rapidamente uma determinada demanda.

Segundo [2], em meados dos anos 80 e 90, muitos processos tradicionais passaram por uma transição devido à abertura de mercados globais e a quebra de barreiras tradicionais para co- mércio. Essa situação gerou o “Business Process Re-engineering” (BPR) como conceito de melhoria na eficiência e na eficácia de processos através de documentação, análise e mudança dos processos de negócio.

Essa reengenharia de processos foi incorporada por August- Wilhelm Scheer, um professor alemão de administração de empresas e informações de negócios da Saarland University, cuja pesquisa concentrou-se em informação e gestão de processos de negócios na indústria, serviços e administração. Ele ficou conhecido por desenvolver uma arquitetura de sistemas de informações denominada ARIS (Architecture of Integrated Infor- mation Systems) [10]. Além de incorporar esta nova concepção de processos de negócios, August Scheer refinou e definiu sua própria metodologia de BPM (Business Process Management) conhecida como ARIS Value Engineering. Esta metodologia é aplicável a qualquer tipo de negócio e, juntamente com esta, muitas ferramentas foram sendo incorporadas para dar supor- te ao BPM. No caso deste artigo em particular, o foco será a aplicação 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 mudança no foco na gerência de negócios [22]. Na época, a documentação

e o acompanhamento dos processos de negócio eram poucos

ou quase nulos. Todos os processos ficavam “armazenados” na cabeça de alguns gerentes/diretores e somente estes podiam modificá-los [9]. Quando uma empresa perdia um destes funcionários, toda ou boa parte do processo era perdida. Isto acontecia porque os processos não 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 des- crito quando um funcionário mudava de cargo e repassava o processo pelo qual era responsável para outro funcionário. Na maioria das vezes, os processos eram mal compreendidos pelo novo funcionário, porque não havia um padrão de descrição que pudesse ser adotado. Ele recebia as instruções e as inter- pretava de sua forma, sem um método específico determinado pela organização, e prosseguia assim moldando o seu próprio processo. Consequentemente, esse fato impactava diretamente na gestão 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 negócios: 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]. Além de suas próprias ferramentas, o ARIS fornece um fra- mework conhecido como ARIS House. Este framework conta com cinco visões, sendo quatro estáticas: Visão Organizacional,

Visão de Dados, Visão de Funções e Visão de Produtos; e uma dinâmica: Visão de Controle [1].

Business Process Management (BPM)

As empresas são organizadas em estruturas que correspon- dem às suas funções organizacionais, nas quais as pessoas só têm a noção de suas responsabilidades limitadas ao universo de resultados de seu departamento. Segundo [16], a eficácia

e a eficiência dos processos de negócios internos e externos

desempenham um papel importante na determinação do su- cesso econômico e, dessa forma, ao aplicar o BPM, a empresa

estará implantando uma gestão com foco na abordagem de processos possibilitando uma integração organizacional [16].

O Business Process Management (BPM) está longe de ser um

conceito novo. Ele é uma abordagem de gestão que surgiu no início de 1990. As primeiras discussões estavam fortemente centralizadas em aspectos organizacionais de curto prazo (BPR). O objetivo era obter mudanças rápidas e radicais nos

processos de negócios baseado em um projeto. Atualmente, é uma abordagem integrada e contínua que trata conjuntamente de questões organizacionais e tecnológicas.

O BPM representa um processo composto de várias fases

sendo elas: estratégia, definição, implementação e controle de processos. O objetivo é implementar essa técnica em uma empresa, tanto em termos organizacionais quanto em termos tecnológicos. O movimento de ser uma organização funcio- nal para ser uma organização orientada para o processo está diretamente associado com o BPM. Da mesma forma, existe uma série de questões que estão diretamente relacionadas ao Business Process Management. EssasEssas incluemincluem aa gestãogestão dede qualiquali-- dade introduzida pela norma ISO 9000-2002 que é orientada para o processo e exige um sistema integrado de gestão e planejamento de necessidades de pessoal, que será capaz de oferecer apenas uma visão incompleta sem a utilização do BPM. A padronização de processos, sistemas e equipamentos de trabalho em empresas é um exemplo típico com foco a longo prazo que implica em um enorme impacto sobre a eficiência. Em termos de TI, o seu conceito se torna indispensável. Os sistemas ERP (Enterprise Resource Planning) ou SIGE (Siste- mas Integrados de Gestão Empresarial) permitem às empresas atingir um nível máximo de integração e flexibilidade somente se o Business Process Management estiver implantado. Além disso, o processo de terceirização vem se destacando muito ultimamente. Para isso, é necessário que as empresas tenham um nível de padronização definido para contratar estes servi- ços. Será impossível tomar decisões a este nível sem possuir o processo implantado na empresa [2] [8] [16]. Os principais objetivos do BPM são a satisfação do cliente e a melhoria da produtividade e competitividade. Usá-lo significa aplicar métodos e técnicas para modelar, implantar, monitorar e melhorar continuamente os processos com o objetivo de alcançar agilidade operacional, maior confiabilidade, redução dos custos, maior capacidade de resposta às mudanças requi- sitadas pelos clientes internos e externos e, principalmente, o alinhamento aos objetivos empresariais.

ARIS: Apresentação Contextual

A arquitetura ARIS é alinhada ao BPM e foi construída em

três níveis: estratégia, especificação (composta de Design, Otimização e Controle) e execução, como pode ser visto na Figura 1. No nível de estratégia, aspectos como a verificação, planejamento e especificação da arquitetura dos processos são

definidos (o processo pode ser entendido como a visão dos processos da empresa). O próximo passo é a especificação,

PRoCESSo

onde todos os conceitos elaborados são transformados em modelos (como diagramas e simulações). O último passo é utilizar estes modelos no nível de execução, no qual tudo o que foi construído será colocado em prática. Esta execução deverá ser monitorada e um feedback será importante para o controle das atividades [14].

será importante para o controle das atividades [14]. Figura 1. Modelo em três camadas (Fonte: Aris

Figura 1. Modelo em três camadas (Fonte: Aris for DoDAF)

Princípios básicos de modelagem

Antes de se iniciar um processo de modelagem, é de suma importância 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á utilizá- lo, que tipo de informação será requisitada e qual o formato necessário. Deve-se considerar que o modelo não deve ser uma réplica do mundo real, mas sim uma representação, um ponto de vista. Um dos pontos fortes do ARIS é sua capacidade de produzir diferentes pontos de vista com dados (informações) 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. Não se pode presu- mir que um determinado modelo criado para uma especificação atenderá ou será adequado a outros objetivos [13]. Para [17], é importante que sejam considerados dois conselhos antes de se começar um processo de modelagem. Um deles é considerar seus usuários, ou seja, documentar os objetivos de acordo com seus stakeholders (ler Nota 2) e o outro refere-se a seis fatores conhecidos por 6W’s ou: “Why, Who, What, When, Where and HoW are you modeling?”

Nota 2. Stakeholders Stakeholder em português, parte interessada: Conceito utilizado por muitas áreas, tais como
Nota 2. Stakeholders Stakeholder em português, parte interessada: Conceito utilizado por muitas áreas, tais como

Nota 2. Stakeholders

Nota 2. Stakeholders Stakeholder em português, parte interessada: Conceito utilizado por muitas áreas, tais como
Nota 2. Stakeholders Stakeholder em português, parte interessada: Conceito utilizado por muitas áreas, tais como

Stakeholder em português, parte interessada: Conceito utilizado por muitas áreas, tais como administração e TI, para definir qualquer pessoa ou organização que tenha interesse ou seja afetada pelo projeto.

Why are you modeling? (Porque você vai modelar?): Para do- cumentar os processos organizacionais, capturar informações para melhoria do processo, apoiar a reestruturação do negócio, fornecer requisitos para o desenvolvimento de TI, possibilitar o lançamento de novos produtos, etc.

Who are the models for? (Para quem será o modelo?): Usuários do negócio, arquitetos de processo, usuários do processo, profissionais de TI envolvidos no processo, etc. What are you modeling? (O que você está modelando?): Toda a Organização (Empresa), um processo de um departamento específico, processos envolvidos em atividades de melhorias, processos que serão automatizados, etc. When will the models be relevant? (Quando os modelos serão relevantes?): “Como são” (os processos como estão agora), “Serão” (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 poderão ser utilizados?): Seus modelos serão publicados na Internet? Serão utilizados para gerar documentação? 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 ob- jetos, quais modelos), usando notações de modelagem padrão, tais como BPMN (Business Process Modeling Notation) ou UML (Unifield Modeling Language), seguindo padrões especificados próprios da empresa, etc.

O que é ARIS?

O ARIS evoluiu de uma busca por melhoria contínua em

processos. Assim, o seu principal foco é o Business Process Management. Para tanto, o ARIS se cerca de um Método de Modelagem. Esse método é dividido em duas partes: as Téc- nicas de Modelagem e os Mecanismos. Dentro das técnicas de modelagem tem-se o procedimento de modelagem que é o ARIS Value Engineering e as Linguagens de Modelagem que são compostas pelas mais diversas formas de representação de mo- delos de processo como BPMN, BPEL, EPC, UML, etc [25].

O método de modelagem ARIS se apóia dentro de ciclo de

vida BPM com quatro plataformas bem definidas:

• Plataforma de Estratégia;

• Plataforma de Projeto;

• Plataforma de Implementação;

• Plataforma de Controle.

Plataforma ARIS e a modelagem de processos

A plataforma ARIS é composta por várias ferramentas que

fornecem apoio e suporte ao planejamento, modelagem e exe- cução do BPM. Estas ferramentas estão distribuídas dentro das várias fases que compõem 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 Manage- ment e o Continuous Improvement que tratam do gerenciamento de mudanças e dos melhoramentos contínuos que fazem a “roda” girar com o mínimo de atrito, ou seja, com a maior efi- ciência possível buscando uma realização eficaz dos processos de negócios. Na parte inferior observa-se o rótulo Compliance Process que reflete a consonância do andamento dos processos

com a sua transparência na gerência e controle de riscos e na qualidade de seus processos [16]. O ARIS suporta variados padrões de modelagem de pro- cessos, com suas linguagens e notações que descrevem o significado de seus elementos. Segue uma relação de suporte e compatibilidade que a plataforma ARIS possui com os diversos padrões de modelagem e seu significado [25]:

BPEL: Business Process Execution Language é uma notação téc-

nica usada para descrever modelos de processos executáveis e orientados à integração. A plataforma ARIS conta com a ferra-

menta ARIS SOA Architect & Designer para modelar e também exportar processos seguindo a padronização do BPEL.

BPMN: Business Process Modeling Notation é uma notação

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 manipulação de modelos BPMN na sua última versão 2.0.

EPC: Event Driven Process Chains é um conjunto de atividades

ou tarefas (processos) inter-relacionadas e consumidoras e/ou geradoras de determinadas ações (eventos) que tem por finali- dade o cumprimento de um objetivo específico. A plataforma ARIS dá suporte a esta representação de processos através das

ferramentas ARIS Business Architect & Designer, ARIS IT Archi- tect & Designer, ARIS SOA Architect & Designer, ARIS Process Governance e ARIS Business Architect for SAP.

UML: Unified Modeling Language é um padrão para descrição 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 des-

crição de interfaces para Web Services. Com a ferramenta ARIS

SOA Architect & Designer é possível exibir a WSDL graficamente

e também importá-la ou exportá-la.

XPDL: XML Process Definition Language é uma notação téc-

nica padronizada que utiliza o XML para definir processos

que podem ser realizados por Web Services. Com ARIS SOA Architect & Designer é possível exportar modelos de processos para a linguagem do XPDL.

XSD: XML Schema Definition é uma padrão para descrever a

troca de dados entre Web Services. A plataforma ARIS disponi-

biliza o ARIS SOA Architect & Designer para importar, exportar

e representar graficamente o XSD.

Além de toda a estrutura que o ARIS entrega através de sua plataforma, suportada por inúmeras ferramentas, padrões de modelagem e pela definição de seu ciclo de vida BPM, também conta com um framework conhecido como ARIS House (assim denominado pela analogia ao formato de uma casa através da disposição de seus elementos). Esse framework integra quatro visões estáticas: Organization View, Data View, Function View e Product/Service View. Essas visões estáticas são interligadas através de uma visão dinâmica denominada Control View. Na Figura 3 observa-se a disposição de cada uma das visões estáticas sendo interligadas pela visão dinâmica:

Product/Service View: Estrutura todas as entradas e saídas

materiais e não materiais que são trazidas ou executadas por

processos de negócio. O método de modelagem a ser utilizado são os Diagramas de produto.

Data View: São descritas as informações dos objetos e seus

atributos, bem como as relações entre eles. Os eventos também são atribuídos à exibição de dados. O método de modelagem

a ser utilizado é o MER (Modelo de entidade relacionamento)

ou UML (Unified Modeling Language).

Function View: São descritas as transações que transformam

performances e os relacionamentos estáticos entre elas. Termos como “função”, “transação” e “atividade” são utilizados como sinônimos. Os sistemas aplicativos também estão incluídos na function view, porque determinam as regras de processamento do computador com suporte para as atividades. O método de modelagem a ser utilizado é o Diagrama em Forma de Árvore

(Function Tree).

Organization View: São descritos os elementoslementos organiza-organiza- cionais e seus relacionamentos. Além dos recursos humanos, os recursos operacionais e hardware de computador também são atribuídos a este ponto de vista. O método de modelagem

a ser utilizado são os Organogramas.

Control View: Exibe conexões entre os objetos de dados, fun- ções, desempenho, visões de organização e fluxo cronológico de processos. O método de modelagem a ser utilizado poderá ser o EPC (Event Driven Process Chain) ou o eEPC (Extended Event Driven Process Chain).

Um exemplo de modelo usando ARIS Express

A IDS Scheer disponibiliza uma ferramenta gratuita para modelagem de processos de negócios, conhecida como ARIS Express [20]. Com ela é possível realizar não somente a mode- lagem de processos, mas também a criação de organogramas, modelos de dados, definição de modelos da infraestrutura

de TI, diagramas com visão macro de processos e sistemas, além de diagramas de aplicação geral, em que o usuário pode atribuir o significado de cada item que o compõe. Para a mo- delagem de processos, que é o foco principal deste trabalho, o ARIS Express permite a utilização de duas linguagens gráficas amplamente conhecidas e difundidas nos ambientes corpora- tivos: 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 opção de tipo de pagamento (cartão ou boleto) e finaliza a operação, tendo seu pedido futuramente entregue no local escolhido por ele. Para isso, foi utilizado o eEPC (Extended Event Driven Process Chain), que é uma versão estendida do EPC, com símbolos para definir pessoas ou pa- péis, unidades organizacionais, informações ou dados, produ- tos ou serviços e objetivos. Segue uma relação e especificação dos símbolos do eEPC (ver Figura 4):

Unidades Organizacionais: representam departamentos

envolvidos em um processo;

Pessoas: representam pessoas ou papéis envolvidos em um processo;

PRoCESSo

pessoas ou papéis envolvidos em um processo; PRoCESSo Figura 2. Plataforma Aris (Fonte: Aris Value Engineering)

Figura 2. Plataforma Aris (Fonte: Aris Value Engineering)

Figura 2. Plataforma Aris (Fonte: Aris Value Engineering) Figura 3. Aris House (Fonte: Aris for DoDAF)

Figura 3. Aris House (Fonte: Aris for DoDAF)

Informação ou dados: representam informação utilizada ou gerada em um processo;

Produtos ou serviços: são gerados ou consumidos pelo

processo;

Objetivos: representam o motivo da realização de um pro- cesso ou tarefa.

As ideias envolvidas no EPC resumem, de certa forma, as principais características do ARIS. Assim, esta linguagem gráfica de modelagem de processos foi preferida para a de- monstração de um exemplo de aplicação de uma modelagem de processos utilizando o ARIS Express. A Figura 5 exibe o diagrama deste exemplo construído no ARIS Express, com a notação do eEPC. O ARIS Express gera vários tipos de modelos estáticos para o gerenciamento de negócios. Dessa forma, não é possível realizar uma simulação do processo modelado utilizando esta ferramenta.

Figura 4. Componentes e símbolos utilizados no EPC e no eEPC, respectivamente Figura 5. Modelagem

Figura 4. Componentes e símbolos utilizados no EPC e no eEPC, respectivamente

e símbolos utilizados no EPC e no eEPC, respectivamente Figura 5. Modelagem de processos de negócio

Figura 5. Modelagem de processos de negócio de uma livraria online usando notação eEPC

A simulação é de extrema relevância para o refinamento sucessivo

dos processos, pois através da mesma, é possível corrigir vários

problemas e executar alterações antes do processo entrar em produção. Para a realização desta importante funcionalidade,

a plataforma ARIS disponibiliza a ferramenta ARIS Architect Designer que é disponibilizada em uma versão paga.

Considerações finais

Este artigo apresentou uma visão mais abrangente e formal de como se modelar processos de negócios 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 possível.

A modelagem de processos de negócio deve ser considerada

como um elemento fundamental dentro de uma organização. No mundo atual, a concorrência é imensa e somente empresas

que estejam alinhadas ao mesmo poderão sobreviver. Tais empresas devem possuir processos bem estruturados e orga-

nizados para fornecer produtos e serviços de qualidade a seus “consumidores”.

O grande problema enfrentado pela maioria das organizações

que desejam implantar um método ou padrão para modelagem de processos é estabelecer qual linguagem e/ou ferramenta

utilizar. Hoje, têm-se várias linguagens, tais como BPMN, EPC, UML, entre outras, que podem ser utilizadas para atender objetivos diversos. Além disso, a gama de ferramentas para modelagem de processos é bem grande. A literatura acadêmica evidencia muito o processo de modelagem em si, não dando ênfase nas linguagens e ferramentas, o que sugere, na prática, que as organizações devem estar confusas ou mesmo perdidas para orientar seus esforços em modelagem de processos. Atualmente, o valor que o BPM agrega a corporação e aos seus produtos é indiscutível. Com o ARIS é possível modelar não só processo, mas também dados, organizações, sistemas, informações, produtos, conhecimento, objetivos do negócio e fluxos de informação. Porém, 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 gestão da ferramenta pode ser facilmente adap- tado de forma que possa atender às normas corporativas das empresas e de todas as funcionalidades de modelagem para o grupo-alvo de representação específica;

Possui assistentes e uma série de opções de análise como, por exemplo, análises de impacto;

Capacidade de desenvolver completamente um modelo

distribuído;

Possui boas ferramentas para navegação entre modelos;

Suporta uma abordagem hierárquica para decomposição

funcional;

Gera modelo para criação de novos modelos e pontos de vista;

Suporta variáveis e união de modelos;

Fornece animação e simulação de processos;

Suporta os objetivos de negócio, medidas e Balanced Scorecard.

Algumas desvantagens para se usar ARIS:

• O ARIS permite que objetos novos sejam inseridos com for-

mas distintas dos que estão presentes na ferramenta, porém

com algumas limitações, ou seja, permite somente a substitui- ção de um símbolo por outro, mas não permite alterações de suas propriedades (regras de conexão, por exemplo);

• Em alguns casos, a qualidade visual do modelo representado

é bastante inferior aos representados por outras ferramentas;

• Não é possível exportar toda a informação gerada na Pla- taforma, dessa maneira o ARIS possui um padrão único e exclusivo.

No mundo todo, mais de 7500 companhias adotaram o ARIS como padrão 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, Volkswa- gen, Wella, Xerox, entre outras. O ARIS pode ser aplicado a:

• Modelagem, análise e otimização de processos de negócio;

• Implementação de soluções SAP;

• Definição de arquiteturas de TI (arquiteturas empresariais);

PRoCESSo

• Construção de arquiteturas orientadas a serviço (SOA);

• Modelagem e gerenciamento de regras de negócio;

• Criação de sistemas de governança, riscos e de conformidade para empresas em geral;

• Implementação de inteligência de processos e gerenciamento de desempenho.

Não basta ter uma ferramenta eficiente, mas a cooperação entre os funcionários é vital para qualquer projeto. O con- teúdo deve estar centralizado e disponibilizado para todos dentro da organização, permitindo o entendimento comum

e um desenvolvimento/normalização das tarefas. O ARIS

fornece componentes poderosos e dinâmicos para publicação permitindo o acesso aos dados através da Intranet da Empresa, ou seja, suporte Web. Além disso, ele possibilita fornecer aos usuários permissões diferenciadas provendo a alguns, por exemplo, a alteração de informações, enquanto outros somente

k c s a o b d a visualização das informações. b Dê seu feedback
k
c
s
a
o
b
d
a visualização das informações.
b
Dê seu feedback sobre esta edição!
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, através do link:
e
r
www.devmedia.com.br/esmag/feedback
e
e
F
e
s
u
t
e
a
s
e
ê
d
i
D
ç
ã
o
 

Referências

 
 

1.

DAVIS, Rob. ARIS Design Platform: Advanced Process Modelling and Administration. Springer-Verlag,

14.Aris for Dodaf – White Paper – Disponível em:http://www.aris-portal.ru/docs/ARIS_for_DoDAF_White_ Paper.pdf

London,2008.

2.DAVIS,Rob;BRABÄNDER,Eric.Aris design platform.Getting Started with BPM.Springer-Verlag,London,2007.

15.Aris Solution for Enterprise Architecture Management - Disponível 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.

 

16.Aris Value Engineering – Concept – WhitePaper – Junho 2005 - Disponível em:http://www.sdn.sap.com/

4.KARAGIANNIS,Dimitris and KÜHN,Harald.Metamodelling Platform.Springer-Verlag,Viena,2002.

irj/scn/go/portal/prtroot/docs/library/uuid/eae8e311-0b01-0010-0f9c-8d26e2714a91?QuickLink=index&ov

5.

KELLNER, M. (1999). Software process simulation modeling: Why? What? How? Journal of Systems and

erridelayout=true

 

Software,46(2-3),91-105.doi:10.1016/S0164-1212(99)00003-5.

 

17.

http://www.ariscommunity.com/users/rob-davis/2010-06-22-dont-leap-modelling-think-about-your-

6.

RYAN, J., & HEAVEY, C. (2006). Process modeling for simulation. Computers in Industry, 57(5), 437-450. doi:

customers-first

 
 

10.1016/j.compind.2006.02.002.

 
 

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.

19.http://www.omg.org

 

8.

SCHEER W.A., KRUPPKE H., JOST W., KINDERMANN H., Agility by ARIS Business Process Management. Berlin:

20.http://www.ariscommunity.com/aris-express/download

 

Springer-Verlag,2006.

 

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:

23.

IDS

Sheer

Corporate

Factbook.

Disponível

em:

http://www.ids-scheer.de/set/408/BR_210x297_

Springer-Verlag,2006.

Factbook_100920_en.pdf

 
 

11.TAYLOR,W., 1960. Princípios de Administração Científica. São Paulo: Atlas.

24. SOA Governance for Oracle. Disponível 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.Disponível em:http://www.ncbi.nlm.nih.gov/pubmed/20218073

25. Modeling Standards Supported by ARIS. Disponível em: http://www.softwareag. com/br/products/aris_ platform/modeling/default.asp

 

13.

Aris Academy - Before you start modelling – Disponível em http://cdn.ariscommunity.com/aris_online_

academy/before_start_modelling2/rebdnesz/player.html

26.Modelagem de Processos de Negócio ARIS & Event Driven Process Chain (EPC). Disponível em: http://wiki.

xexeo.org/tiki-download_file.php?fileId=226

 

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos
Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software

Refatoração para Padrões – Parte 11 Substituir código de tipo por classe, limitar instanciação com
Refatoração para Padrões – Parte 11
Substituir código de tipo por classe, limitar instanciação com singleton e
introduzir objeto nulo
instanciação com singleton e introduzir objeto nulo Jacimar Fernandes Tavares
instanciação com singleton e introduzir objeto nulo Jacimar Fernandes Tavares

Jacimar Fernandes Tavares

jacimar.tavares@studentpartners.com.br

Bacharel em Ciência da Computação FAGOC - Faculdade Governador Ozanam Coelho, Microsoft Student Partners.

Marco Antônio Pereira Araújo

maraujo@devmedia.com.br

É Doutor e Mestre em Engenharia de Sis- temas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Com- putacionais e Bacharel em Informática pela UFJF,professor do curso de Bacharelado em Ciência da Computação da FAGOC,professor dos Cursos de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora e da Faculdade Metodista Granbery,Analista de Sistemas da Prefeitu- ra de Juiz de Fora, Editor da Engenharia de Software Magazine.

M elhorar o projeto de código

existente é um dos objetivos

das técnicas de refatoração

para padrões. Sabe-se também que me- lhorar o projeto existente não implica apenas em implementar padrões de projeto e tornar o código reutilizável. Aumentar a segurança de tal código também é contribuir para uma melhoria do projeto de código existente. Não ter a

segurança de que um dado de um tipo específico foi ou não modificado pode ser um problema quando se precisa ter certeza de que o dado não foi alterado antes de ser requisitado. Melhorar o projeto de código existente também está relacionado à necessidade de melhorar o desempenho do sistema através de modificações no código.

De que se trata o artigo?

Aborda o tema refatoração para padrões com o ob- jetivo de mostrar como o desenvolvedor pode usá-

lo para melhorar o código-fonte de suas aplicações.

Para que serve?

Para prover conhecimento ao desenvolvedor sobre refatoração para padrões e demonstrar através de exemplos práticos a aplicação das técnicas de refa- toração para padrões Substituir Código de Tipo por Classe, Limitar Instanciação com Singleton e Intro- duzir Objeto Nulo.

Em que situação o tema é útil?

O tema se torna fundamental para desenvolve-

dores que já estão familiarizados com padrões de projeto e já os implementam em seus softwares

e que querem saber mais sobre refatoração para

padrões, conhecendo os benefícios que sua uti- lização traz.

Um exemplo pode ser uma classe com várias instâncias em memória, prejudicando o desempenho. Limitar as instâncias para apenas uma contribui no sentido de liberar memória e aumentar o desempenho.

Em outro cenário, melhorar o projeto de código existente pode estar relacionado à remoção de código duplicado. Cen-

tralizar código que verifica se valores nulos foram atribuídos

a objetos contribui para a redução de código que normalmente

ficaria espalhado por pontos onde se fazem necessárias tais verificações. Nesse sentido, o objetivo deste artigo é apresentar a técnica de refatoração para padrões Substituir Código de Tipo por Classe como alternativa para uma melhoria do projeto de

código existente em relação a tipos, além das técnicas de refa- toração para padrões Limitar Instanciação com Singleton, que tem como objetivo implementar o padrão de projeto Singleton,

e Introduzir Objeto Nulo, responsável pela implementação do

padrão de projeto Objeto Nulo. As técnicas de refatoração para padrões citadas implicam na necessidade de aprendizagem das técnicas de refatoração Extrair Classe, Extrair Subclasse e En- capsular Atributo (ver Nota 1) e também das teorias referentes aos padrões de projeto Objeto Nulo, que será apresentado, e

Singleton, já abordado em artigos anteriores.

Refatoração Encapsular Atributo

Esta refatoração é pertencente ao grupo de refatorações clas- sificadas como Organizando Dados. Nome da refatoração: O nome original da refatoração é Encapsular Campo, mas é citada nas técnicas de refatoração para padrões como Encapsular Atributo. Resumo: Campos públicos devem ter seus moderadores al-

terados para privados e métodos de acesso (gets e sets) devem ser criados para possibilitar o acesso a esses campos. Motivação: Usa-se esta refatoração para permitir que campos (ou atributos) de uma classe passem a ter métodos de acesso, permitindo assim que o encapsulamento dos dados seja man- tido, o que é um dos princípios da orientação a objetos. Mecânica: Os passos que serão descritos podem sofrer va- riações em algumas linguagens, portanto serão mostrados os passos referentes às linguagens C# e Java.

• Crie métodos get e set para os atributos que não possuem.

• Busque pelo código fonte referências a esses atributos e

modifique-os para que, a partir desse momento, passem a referenciar os métodos de acesso, e não mais os atributos. Em Java, deve-se verificar se o método 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 então altere os modificadores de acesso dos atributos para private.

Padrão de projeto Objeto Nulo

Nome do padrão de projeto: Objeto Nulo. Pertencente ao conjunto dos padrões de projeto classificados como Padrões Estruturais. O problema: Em algumas aplicações é comum ver a escrita de código com lógica condicional a fim de verificar se uma variável não é nula para então uma tarefa ser executada. Esse tipo de verificação em alguns momentos é muito útil, pois evita que operações sejam realizadas com nulos.

dESENvoLviMENto

 

Nota 1. Refatorações apresentadas em outros artigos

 

As técnicas de refatoração Extrair Classe e Extrair Subclasse já foram apresentadas em outras edições da Engenharia de Software Magazine.

 
 

O

padrão de projeto Objeto Nulo permite a criação de um

objeto que é utilizado para substituir a lógica de verificação de nulos. As consequências: O uso desse padrão de projeto evita a duplicação de código para verificação de nulos na aplicação,

tornando o código mais simples e manutenível.

 
 

A

partir deste momento, visto as teorias que envolvem o

processo de refatorar para padrões deste artigo, serão apresen- tadas as técnicas Substituir código de Tipo por Classe, Limitar Instanciação com Singleton e Introduzir Objeto Nulo.

Refatoração para padrões Substituir Código de Tipo por Classe

 

Resumo: Atributos de tipos primitivos podem ser inseguros quando se atribui algum valor a eles. Trocam-se os tipos pri- mitivos por instâncias de uma classe. Motivação: Dado que tipos primitivos são passíveis de er-

ros, no sentido de permitir atribuições inválidas, essa técnica de refatoração para padrões proporciona a definição de um mecanismo onde os atributos de tipos inseguros e passíveis de erro, como strings, serão substituídos por tipos de classes, evitando que atribuições inválidas sejam feitas a eles, visto que a atribuição ficaria controlada pela classe fornecedora do novo tipo mediante as suas verificações. Vantagens: Permite a definição de um mecanismo que evita atribuições e comparações inválidas. Desvantagens: Leva a escrita de mais código do que normal- mente seria necessário para tipos primitivos. Mecânica:

1.

Buscando por um atributo do tipo primitivo que se deseja

substituir, aplica-se a refatoração Encapsular Atributo, caso necessário.

2.

Cria-se uma classe que será a responsável por substituir o

atributo do tipo primitivo por uma instância, certificando para que seu nome corresponda ao atributo que será substituído.

3.

Para cada atributo encontrado no passo 1, definem-se atribu-

tos iguais na classe criada no passo 2, sendo eles constantes.

4.

Na classe que contém o atributo encontrado no passo 1,

declara-se um atributo do tipo da classe criada no passo 2 e

um método que altera seu valor.

 

5.

Buscando por trechos onde o atributo encontrado no pas-

so 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 código onde o atributo primitivo é usado

devem ser substituídos pelo seu correspondente na classe criada no passo 2. Isto talvez implique em fazer modificações na classe criada