Avaliação de algumas práticas de Metodologias Ágeis escrito como trabalho para disciplina de Métodos Ágeis.

1. PRÁTICAS DE MÉTODOS ÁGEIS E POSSIBILIDADE DE EXECUÇÃO EM
AMBIENTES DE TRABALHO CONHECIDOS
Silvio Gonçalves
silvio@vexta.com.br
Prof. Pablo Schoeffel, Métodos Ágeis
RESUMO: Avaliação de algumas práticas de Metodologias Ágeis escrito como trabalho
para disciplina de Métodos Ágeis.
Palavras-chave: Metodologias Ágeis, Scrum, XP, Modelagem Ágil
1 INTRODUÇÃO
Extreme Programming (XP) é uma metodologia de desenvolvimento de software,
nascida nos Estados Unidos ao final da década de 90. Seu sucesso se deve ao fato ajudar a
criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais
econômica que o habitual. Para alcançar tais objetivos baseia-se em um pequeno conjunto de
valores, princípios e práticas, que diferem substancialmente da forma tradicional de se
desenvolver software.
Scrum é uma metodologia ágil voltada para a gestão e planejamento de projetos de
software. Os projetos são dividos em ciclos chamados de Sprints, dentro do qual um conjunto
de atividades deve ser executado. A lista de funcionalidades a serem implementadas em um
projeto é denominada Product Backlog. O Sprint inicia-se pela reunião de planejamento na
qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades
que ela será capaz de implementar durante o Sprint. As tarefas alocadas em um Sprint são
transferidas do Product Backlog para o Sprint Backlog. No final do Sprint, a equipe apresenta
as funcionalidades implementadas e faz uma Retrospectiva, partindo para o planejamento do
próximo Sprint, reiniciando o ciclo.
2 REUNIÕES DIÁRIAS EM PÉ
A reunião diária, ou Daily Scrum, é uma das práticas utilizadas pelo Scrum para
difundir informação sobre o que está acontecendo, planejar o trabalho do dia em curso, e

2. identificar os problemas mais importantes (KNIBERG; SKARIN, 2009, p.67). Recomenda-se
sua realização em pé para mantê-la curta, por isto chamada reunião em pé.
Alguns cuidados devem ser tomados para que a reunião consiga atingir seus objetivos.
FIGUEREDO (2007, p.18) alerta que “muitas equipes tem confundido os quinze minutos da
reunião diária com momentos de desabafo” em seu artigo sobre as armadilhas das reuniões
diárias. Nestes casos, cabe ao Scrum Master manter o foco da reunião, fazendo com que a
equipe se atenha somente a resposta das questões propostas pela prática: a)o que fiz desde a
última reunião diária? b)o que farei até a próxima? E c)estou tendo algum impedimento?
A difusão do informação por todo o time considero como umas das melhores
justificativas para sua utilização. Isto auxilia na formação de equipes homogêneas, aonde
todos tomam conhecimento dos problemas a serem resolvidos e das soluções encontradas. A
explanação de um problema, por si só, já faz com que pensem nele com uma visão mais
crítica, fazendo que com isto se chegue a uma solução mais rapidamente.
A aplicação isolada em uma empresa seria possível, provavelmente não com tanta
eficiencia que se aplicado com as outras prátivas ágeis, mas o objetivo principal – difindir a
informação – certamente poderia ser alçado.
3 SCRUM BOARD
É um quadro onde deverá contemplar todas as tarefas que serão realizadas dentro de
um Sprint e listadas de acordo com as prioridades de cada item. Mostra visualmente o
progresso do trabalho para os membros da equipe e as partes interessadas. Antes ou durante a
reunião diária o quadro é atualizado para refletir sempre a posição atualizada.
O quadro garante transparência e inspeção no processo de desenvolvimento.
Transparencia pois todos os comprometidos com o projeto podem acompanhar como está o
desenvolvimento de cada história e os problemas encontrados nelas. A inspeção é feita pela
interpretação do mesmo. Quando é identificado muitos impedimentos, certamente indica
problemas, bem como uma tarefa que está muito tempo sendo feita. Assim, problemas
complexos podem facilmente serem diagnosticados, de forma visual e intuitiva(O QUADRO
DE TAREFAS NO SCRUM, 2012).
A visualização rápida da posição das tarefas é o maior benefício da utilização do
quadro. Para que sua aplicação tenha efeito prático é necessário utilizar em conjunto com as
outras práticas do scrum, como a reunião diária, aonde é feita a atualização do quadro.

3. 4 ESTIMATIVA ATRAVÉS DE PLANNING POKER
Técnica comumente utilizada em desenvolvimento ágil de software para estimar o
esforço ou o tamanho relativo de histórias. É uma técnica baseada no concenso. Este método
evita a influência dos outros participantes nas escolhas, e força com que cada participante
pense independentemente ao propor seus números ao mesmo tempo (PLANNING POKER,
2012). Os participantes que definirem a menor e a maior pontuação devem justificar suas
escolhas e, caso necessário, novas rodadas serão executadas até que o concenso seja
alcançado.
O fato de os participantes terem que justificar sua escolha faz com que repensem a
tarefa e exponham seus pontos de vistas e dificuldades visualizadas. Isto faz com que sejam
elencadas dificuldades que outro participante pode não ter visto. Esta prática abre espaço para
que todos os participantes da equipe possam expressar sua opinião, reforçando o conceito de
colaboração e aumentando o comprometimento.
Individualmente, em qualquer atividade que necessite estimantiva, acredito ser
possível utilizar esta tecnica, pelo fato de que a opinião de um participante sobre o outro seja
minimizada.
5 CLIENTE OU REPRESENTANTE DO CLIENTE JUNTO À EQUIPE
Dentre os papéis definidos pelo Scrum, o Product Owner é quem representa o cliente.
O Product Owner “é o responsável pelo Retorno do Investimento (ROI) do projeto, cabe a ele
priorizar os itens no Product Backlog (PB) de forma a obter o maior retorno possível” (O
PAPEL DO PRODUCT OWNER E PRIORIZAÇÃO DO PRODUCT BACKLOG, 2008).
Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões.
A proximidade do cliente junto a equipe de desenvolvimento agrega valor ao produto
final pelo fato de que o cliente, representado pelo Product Owner, é quem define as
prioridades, fazendo com que a equipe se concentre nas atividades que tragam mais valor para
ele. Além de um maior compromentimento do cliente.
Acredito que esta aproximação feita de forma desordenada ou sem que um
conhecimento/entendimento do scrum por parte do Product Owner pode trazer conseguencias
desagradaveis para a equipe.
6 RETROSPECTIVA

4. A retrospectiva do Sprint é o momento em que o time “olha para traz” para analisar
como foi o último sprint. Neste momento ele responde a três questões principais sobre o
sprint: O que deu errado? O que deu certo? O que poderia ser melhorado para o próximo
sprint? (SCRUM, 2012).
Uma boa aplicação da reunião de retrospectiva resulta em melhoria contínua, sempre
analisando o que foi feito de errado e tomando cuidado para que estes erros não se repitam. É
o momento de colher o feedback do time sobre a aplicação do scrum em si.
A retrospectiva é importante não só para o scrum. No final do ano, por exemplo,
analise os pontos em que você logrou exito e aonde você errou. Certamente no próximo ano
você irá errar menos, ou pelo menos evitar os mesmos erros que você identificou.
7 JOGO DO PLANEJAMENTO (PRIORIZAÇÃO PELO CLIENTE)
O jogo do planejamento refere-se a reunião inicial do sprint aonde todos participam, e
o cliente (no papel do Product Owner), prioriza e seleciona as histórias que serão
desenvolvidas. O envolvimento do cliente neste fase gera maior comprometimento por parte
deste, pois ao definir as prioridades ele está sinalizando o que tem mais valor para ele neste
momento, alem de ele estar ciente do que está acontecendo e o que vai acontecer no projeto.
8 ENTREGAS FREQUENTES (SPRINTS)
Um dos principios do Manifesto Ágil sugere entregas frequentes de software
funcionando. Entregas rápidas e frequentes fazem com que se tenha também um feedback
rápido do cliente, o que pode evitar o desenvolvimento de funcionalidades desnecessárias ou
com um comportamento indesejado pelo cliente. O retorno sobre o investimento do cliente
também é acelerado, “já que na maioria das vezes o ROI real só será recebido pelo cliente
com o produto em produção” (RELEASE: O QUÃO CURTO E FREQUENTE FOR
POSSÍVEL, 2011).
Entregas rápidas faz com que se consiga respoder rapidamente com uma correção a
um bug, por exemplo, ou a uma melhoria solicitada. Isto melhora a relação com o cliente,
pelo fato dele visualizar progresso neste processo: algo que ele solicitou (e que tenha a devida
prioridade) seja entregue mais rapidamente. Mesmo que sejam pequenas melhoras, mas
rápidas e frequentes contribuem para um ambiente de melhoria contínua, em vez de grandes
liberações que muitas vezes também o são demoradas e que geralmente geram desconforto

5. pois o cliente tem que esperar muito tempo para ver o resultado do trabalho da equipe de
desenvolvimento.
9 METÁFORA
Metáfora é um recurso que pode ser utilizado para transmitir idéias complexas de
forma mais simples, facilitando o entendimento de um assunto (SANTOS, 2010). Seriam
descrições de um software sem a utilização de termos técnicos com a intenção de conduzir o
desenvolvimento de software de forma mais transparente possível para o cliente.
A dificuldade de encontrar material sobre o assunto me leva a crer que a utilização
deste artefado da metodologia ágil não é muito difundido. Mesmo porque não é fácil
encontrar uma metáfora que se encaixe em todos as histórias e ou projetos que estamos
tentando aplicar o método.
10 PROJETO SIMPLES
Refere-se ao décimo principio do manifesto ágil: “Simplicidade: a arte de maximizar a
quantidade de trabalho que não precisou ser feito.” Aplicando este princípio ao processo de
desenvolvimento é possível reduzir o trabalho ao mínimo e permitir o foco da equipe na
solução mais simples possível para criar valor ao negócio (10º PRINCÍPIO DO MANIFESTO
ÁGIL – SIMPLICIDADE, 2011).
Em resumo, faça o essencial. A importancia da abordagem simples vem do fato de
serem mais facilmente mudadas, adaptadas. O objetivo é satisfazer os requisitos atuais, sem a
preocupação com requisitos futuros.
A visão minimalista faz com que estejamos desenvolvendo o minimo possível,
basicamente o essencial para a existencia do produto, reduzindo desta forma as chances de
insucesso, pois estaremos implementando o que o cliente realmente quer e precisa. Desta
forma mantemos o foco em realmente criar valor para o cliente, controlando os custos pois
estamos o que é realmente essencial.
11 PROGRAMAÇÃO EM PARES
É a programação em duplas em um único computador. Um fica em frente ao
computador codificando e o outro ao lado, acompanhando e ajudando o desenvolvimento. Na

6. programação em pares o código produzido é sempre revisto por duas pessoas, diminuindo a
possibilidade de erros, além de se conseguir uma evolução da equipe e uma melhora nos
códigos gerados (PROGRAMAÇÃO EXTREMA, 2012). Os papéis devem ser alternados
constantemente assim como as duplas para que haja melhor aproveitamento desta prática.
Os benefícios desta prática num primeiro momento podem ser ofuscados pela ideia de
que os custos dobrarão, mas na prática, muitos autores tem mostrados que o ganho na
qualidade do código, diminuindo retrabalhos e erros, aumento no nível de conhecimento da
equipe pelo troca de conhecimento, acabam equilibrando esta conta. Ainda assim, acredito
que seja benefica esta prática pelo fato de melhorar a satisfação do cliente, por estar
recebendo softwares com menor taxa de erros.
12 TESTES AUTOMATIZADOS / TDD
Na metodologia XP, testar é parte da rotina diária dos desenvolvedores. A execução de
testes em um sistema é uma tarefa maçante e que demanda um grande esforço em tempo. Daí
a necessidade de automatizar o processo de testes, que nada mais é do que a utilizando um
software específico para efetuar testes em outro (AUTOMAÇÃO DE TESTE, 2012).
O Test Driven Development (TDD) é uma técnica que define que primeiro se
desenvolve os casos de teste e depois se implementam os códigos que devem ser testados.
Depois da implementação passar pelos teste ele pode ser refatorado para um código sob
padrões aceitáveis. O TDD garante, quando usado adequadamente, que todo o código seja
coberto por um teste, isto gera em toda equipe um nivel maior de confiança no software
(TEST DRIVEN DEVELOPMENT, 2012).
Testes são essenciais para que a qualidade do software seja mantida. Sob este ponto de
vista acredito ser importante a automatização dos teste e, mais ainda, que se façam testes para
conseguir melhorar a qualidade dos softwares entreges.
13 REFATORAÇÃO
Consiste em modificar um sistema com objetivo de melhorar sua estrutura,
simplificando, sem comprometer seu funcionamento, também melhorando o entendimento do
código, facilitando a manutenção e evitando a inclusão de defeitos. A garantida de que o

7. comportamento não foi alterado é feita pela utilização de testes automatizados
(REFATORAÇÃO, 2012).
Refatoração faz parte do processo de melhoria continua do software, desde que
acompanhada dos testes que garantam o correto funcionamento do código refatorado.
14 PROPRIEDADE COLETIVA
Todo código escrito pertence a equipe. Todos podem alterar qualquer parte do sistema.
É o que prega a metodologia XP. Um dos benefícios disto é a dissiminação do conhecimento,
o que permite que um membro da equipe possa tirar férias, por exemplo, pois os outros
conhecem os códigos que este implementa.
Mas para que esta prática possa ser aplicada é necessário, pelo menos, a utilização de
padrão de codificação.
15 INTEGRAÇÃO CONTÍNUA
Consiste na integração do trabalho diversar vezes ao dia, assegurando que o código
permaneça consistente ao final de cada integração atraves de testes principalmente. A
integração contínua aplica pequenas alterações ao todo em vez de aplicar todo o código ao
final do desenvolvimento, reduzindo também o tempo de entrega (CONTINUOUS
INTEGRATION, 2012).
Para a aplicação da integração contínua faz-se necessário a utilização de testes
automatizados para garantir a qualidade do código que está sendo integrado, bem como a
utilização de repositórios para os códigos (controle de revisão).
Com a integração contínua é possível identificar divergências nos códigos antes que
elas virem problema. Também comentários do tipo “isso funcionava na minha máquina”.
Devido a necessidade de aplicação desta prática em conjunto com outras já citadas,
como controle de revisão e automação dos teste, acredito ser difícil aplicar esta prática
individualmente.
16 SEMANA DE 40 HORAS
Por ser o desenvolvimento de software uma atividade que demanda lógica e
criatividade, a premissa de que horas extras aumentam a produtividade não é válida. A

8. metodologia XP não recomenda que se trabalhe horas extras numa segunda semana
consecutiva pois, embora aumente a produtividade nos primeiros dias, os efeitos colaterais
aparecerão assim que os envolvidos se cansam (SANTOS, 2010). Horas extras numa segunda
semana consecutiva é sintoma de problema no projeto e este não deve ser resolvido
aumentando a carga horária, mas melhorando o planejamento (CONCEITOS BÁSICOS
SOBRE METODOLOGIAS ÁGEIS PARA DESENVOLVIMENTO DE SOFTWARE,
2012).
Esta prática, acima de tudo, gera melhor qualidade de vida para quem a utiliza, e por sí
só, acredito que isto justifique sua aplicação.
17 PADRÕES DE CODIFICAÇÃO
Entende-se por padrão de codificação a adoção de um estilo único de codificação por
todos os programadores do projeto. Esta prática ajuda a manter o código legível por todos no
projeto (SANTOS, 2010).
O padrão de codificação é imprescindível para uma melhora aplicação de outras
práticas já citadas aqui, como por exemplo programação em pares, propriedade coletiva,
refatoração.
18 UTILIZAÇÃO DE USER STORIES
User Stories é uma sentença escrita na liguagem cotidiana ou de negócio, que visa
capturar o que o usuário faz ou precisa fazer. Muito importantes nas metodologias ágeis, elas
definem o que deve ser contruido no projeto de software (USER STORIES, 2012). São
descrições simples dos requisitos do sistema, escritas sob o ponto de vista do usuário
(ESCREVENDO “USER STORIES” EFICAZES, 2012). Descrevem cenários com situações
de utilização que os usuários gostariam que o software viesse a oferecer. Elas são a base para
a criação de estimativas de tempo e para a elaboração dos testes de aceitação.
A user story normalmente é descrita no formato “Como um (usuário), Eu quero
(funcionalidade), Para que (necessidade)”.
O uso adequado das user stories traz diversos benefícios a equipe, pois de uma forma
simples e objetiva consegue-se identificar qual é a funcionalidade, qual é o usuário que vai
utilizar e para que ela serve.

9. 19 UTILIZAÇÃO DE CRCS
CRC é acronimo de Class, Responsibility, Collaborator, é uma tecnica que se utiliza
de cartões de papel. Baseia-se em identificar em cada cartão uma classe e suas propriedades e
as associações entre as classes (CRC - VOCÊ JÁ OUVIU FALAR NESTA TÉCNICA?,
2007). Esta técnica permite que todos os integrantes da equipe contribuam com o design e
quanto mais pessoas ajudarem, maior a quantidade de boas ideias que podem ser
incorporadas.
20 REFERÊNCIAS
10º PRINCÍPIO DO MANIFESTO ÁGIL – SIMPLICIDADE. 2011. Disponível em:
<http://blog.scrumhalf.com.br/en/2011/09/10%C2%BA-principio-do-manifesto-agil-
%E2%80%93-simplicidade/> Acessado em 11 Set 2012.
AGILE SOFTWARE DEVELOPMENT. In: WIKIPÉDIA: a enciclopédia livre. Flórida:
Wikimedia Foundation, 2012. Disponível em:
<http://en.wikipedia.org/w/index.php?title=Agile_software_development&oldid=509809158>
. Acessado em: 30 ago 2012
AUTOMAÇÃO DE TESTE. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia
Foundation, 2012. Disponível em:
<http://pt.wikipedia.org/w/index.php?title=Automa%C3%A7%C3%A3o_de_teste&oldid=31
694317>. Acesso em: 13 set. 2012.
CARTÕES CRC. 2003. Disponível em: < http://www.zemoleza.com.br/carreiras/12293-
cartoes-crc.html> Acessado em: 13 Set 2012.
CONCEITOS BÁSICOS SOBRE METODOLOGIAS ÁGEIS PARA
DESENVOLVIMENTO DE SOFTWARE. Disponível em:
<http://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis-para-
desenvolvimento-de-software-metodologias-classicas-x-extreme-programming/10596>
Acessado em 12 Set 2012
CONTINUOUS INTEGRATION. In: WIKIPÉDIA: a enciclopédia livre. Flórida: Wikimedia
Foundation, 2012. Disponível em:
<http://en.wikipedia.org/w/index.php?title=Continuous_integration&oldid=511429041>
Acessado em 11 Set 2012;
CRC - VOCÊ JÁ OUVIU FALAR NESTA TÉCNICA?. 2007. Disponível em:
<http://www.infoblogs.com.br/view.action?contentId=2654&CRC-Voce-ja-ouviu-falar-nesta-
tecnica.html> Acessado em 13 Set 2012.
ESCREVENDO “USER STORIES” EFICAZES. In: daily scrum blog, 2012. Disponível em:
<http://www.dailyscrumblog.com/posts/221> Acessado em 13 Set 2012.

10. FIGUEIREDO, Alexandre Magno. Scrum e as armadilhas das reuniões diárias. Visão Ágil,
Ano I, Edição 01, página inicial e final, Julho de 2007. Disponível em:
<www.visaoagil.com/edicoes>. Acesso em: 09 Set 2012.
KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum: obtendo o melhor de ambos. 2009.
Disponível em: <http://www.infoq.com/br/minibooks/kanban-scrum-minibook> Acessado
em: 09 Set 2012.
MANIFESTO ÁGIL. Disponível em: <http://agilemanifesto.org/iso/ptbr/principles.html>
Acessado em 10 Set 2012.
O PAPEL DO PRODUCT OWNER E PRIORIZAÇÃO DO PRODUCT BACKLOG. In:
Antonio Carlos Silveira: Blog, 2008. Disponível em:
<http://www.acarlos.com.br/blog/2008/02/papel-do-product-owner-e-priorizacao-do-product-
backlog/> Acessado em 09 Set 2012.
O QUADRO DE TAREFAS NO SCRUM. 2012. Disponível em:
<http://blog.scrumhalf.com.br/2012/01/o-quadro-de-tarefas-no-scrum/> Acessado em 11 Set
2012
PLANNING POKER. In: WIKIPÉDIA: a enciclopédia livre. Flórida: Wikimedia Foundation,
2012. Disponível em:
<http://en.wikipedia.org/w/index.php?title=Planning_poker&oldid=508312745> Acessado
em 09 Set 2012.
PROGRAMAÇÃO EXTREMA. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia
Foundation, 2012. Disponível em:
<http://pt.wikipedia.org/w/index.php?title=Programa%C3%A7%C3%A3o_extrema&oldid=3
1918373>. Acesso em: 13 set. 2012.
REFATORAÇÃO. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation,
2012. Disponível em:
<http://pt.wikipedia.org/w/index.php?title=Refatora%C3%A7%C3%A3o&oldid=31680365>.
Acesso em: 13 set. 2012.
RELEASE: O QUÃO CURTO E FREQUENTE FOR POSSÍVEL. 2011. Disponível em:
<http://www.adaptworks.com.br/blog/2011/01/27/release-o-quao-pequeno-e-frequente-for-
possivel/> Acessado em 11 Set 2012.
SANTOS, Tiago dos. Utilizando metodologias ágeis em projetosde software. 2010. 44 Folhas.
Trabalho de Conclusão de Curso – Faculdade Comunitária de Taubaté da Anhanguera
Educacional S.A., Taubaté. Disponível em: <http://www.scribd.com/doc/61603274/TCC-
Metodologias-Ageis-V-Final>.
SCRUM. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation, 2012.
Disponível em: <http://pt.wikipedia.org/w/index.php?title=Scrum&oldid=32095022>. Acesso
em: 9 set. 2012.
SCRUM. Disponível em: <http://epf.eclipse.org/wikis/scrum> Acessado em: 10 Set 2012

11. TEST DRIVEN DEVELOPMENT. In: WIKIPÉDIA, a enciclopédia livre. Flórida:
Wikimedia Foundation, 2012. Disponível em:
<http://pt.wikipedia.org/w/index.php?title=Test_Driven_Development&oldid=30097216>.
Acesso em: 13 set. 2012.
USER STORIES. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation,
2012. Disponível em :
<http://en.wikipedia.org/w/index.php?title=User_story&oldid=510407570> Acessado em: 13
Set 2012.