|
Há
alguns anos, um grupo de veteranos na área
de software se reuniu, nos EUA, para discutir
formas de melhorar o desempenho de seus projetos.
Embora cada envolvido tivesse suas próprias
práticas e teorias sobre como fazer um
projeto de software ter sucesso, cada qual com
suas particularidades, todos concordavam que,
em suas experiências prévias, um
pequeno conjunto de princípios sempre
era respeitado quando os projetos davam certo.
Com base nisso eles criaram o Manifesto para
o Desenvolvimento Ágil de Software, frequentemente
chamado apenas de Manifesto Ágil, e o
termo Desenvolvimento Ágil passou a descrever
abordagens de desenvolvimento que seguissem
estes princípios, que são apresentados
a seguir:
"Estamos descobrindo maneiras melhores
de desenvolver software fazendo-o nós
mesmos e ajudando outros a fazê-lo. Através
desse trabalho, passamos a valorizar:
- Indivíduos e interações
mais do que processos e ferramentas
- Software funcionando mais do que documentação
abrangente
- Colaboração com o cliente mais
do que negociação de contratos
- Responder a mudanças mais do que seguir
um plano
Ou seja, mesmo havendo valor nos itens à
direita, valorizamos mais os itens à
esquerda."
O Manifesto Ágil, criado em 2001, descreve
a essência de um conjunto de abordagens
para desenvolvimento de software criadas ao
longo da última década. A mais
conhecida delas é o Extreme Programming,
também conhecido pela abreviação
XP, uma metodologia criada por Kent Beck no
final dos anos 90. O XP é composto por
um pequeno conjunto de práticas, que
giram em torno de alguns valores básicos.
Valores
Feedback
Algumas pessoas seriam capazes de caminhar
na beira de um precipício com os olhos
fechados, ou colocar a maior parte do seu dinheiro
em um investimento com elevada chance de prejuízo
sem acompanhá-lo de perto. Entretanto,
a maioria das pessoas provavelmente manteria
os olhos bem abertos em ambos os casos. Isso
é particularmente verdade no caso de
equipes trabalhando com XP.
Normalmente, quanto mais cedo descobrimos um
problema, menos prejuízos ele pode causar
e maiores são as chances de resolvê-lo
de forma barata. Por isso, projetos XP estabelecem
formas de encurtar ao máximo a defasagem
de tempo entre o momento em que uma ação
é executada e o seu resultado é
observado. Assim, por exemplo, desenvolvedores
procuram entregar novas funcionalidades no menor
prazo possível, para que o cliente compreenda
rapidamente as conseqüências daquilo
que pediu. Os clientes, por sua vez, procuram
se manter presencialmente próximos dos
desenvolvedores para prover informações
precisas sobre qualquer dúvida que surja
ao longo do desenvolvimento.
Comunicação
Para que os desenvolvedores compreendam o que
o cliente deseja e este último entenda
os desafios técnicos que precisam ser
vencidos, é preciso que haja comunicação
entre as partes. Diálogos são
mais eficazes que videoconferências, que
são melhores que telefonemas, que são
mais expressivos que emails e assim sucessivamente.
Conscientes disso, aqueles que trabalham com
XP priorizam o uso do diálogo presencial,
com o objetivo de garantir que todas as partes
envolvidas em um projeto tenham a chance de
se compreenderem da melhor maneira possível.
Simplicidade
O XP utiliza o conceito de simplicidade em
inúmeros aspectos do projeto para assegurar
que a equipe se concentre em fazer, primeiro,
apenas aquilo que é claramente necessário
e evite fazer o que poderia vir a ser necessário,
mas ainda não se provou essencial.
Coragem
Equipes XP acreditam que errar é natural
e quebrar o que vinha funcionando acontece cedo
ou tarde. É necessário ter coragem
para lidar com esse risco, o que em XP se traduz
em confiança nos seus mecanismos de proteção.
As práticas do XP são voltadas,
entre outras coisas, para proteger o software
de inúmeras formas. Equipes XP confiam
na eficácia destas práticas e
destes mecanismos de proteção
e isso é o que as tornam receptivas a
mudanças. Assim, ao invés de frear
a criatividade do cliente e evitar mudanças,
equipes XP as consideram inevitáveis
e procuram se adaptar a elas com segurança
e com coragem, isto é, com confiança
em seus mecanismos de proteção.
Práticas
Cliente Presente
Projetos XP procuram contar com a presença
do cliente, junto à equipe de desenvolvimento,
tanto quanto possível. Isso não
significa que ele tenha que estar 100% do tempo
com os desenvolvedores, mas sim que deve procurar,
no mínimo, visitá-los e dialogar
com eles inúmeras vezes ao longo do projeto,
com a maior freqüência possível.
A presença do cliente permite que os
desenvolvedores compreendam melhor o que se
espera do software, bem como permite que o cliente
receba feedback imediato sobre o avanço
do projeto
Jogo do Planejamento
O software é desenvolvido de modo iterativo
e incremental em projetos XP. Ou seja, uma vez
por semana os desenvolvedores se reúnem
com o cliente para priorizar um pequeno conjunto
de funcionalidades que, no conjunto, possam
ser implementadas e testadas completamente naquela
semana. Terminado esse período, que é
chamado de iteração, o cliente
tem a oportunidade de utilizar e avaliar o que
foi produzido. Com base nos resultados, reúne-se
novamente com a equipe e estabelece novas prioridades
de acordo com o que acabou de aprender concretamente
com o software. Essa reunião semanal
recebe o nome de Jogo do Planejamento. Nela,
o cliente tem o direito de informar as funcionalidades,
também chamadas de histórias,
bem como indicar a prioridade das mesmas. Os
desenvolvedores, por sua vez, têm o direito
de estimar e apresentar suas considerações
técnicas. O objetivo do jogo do planejamento
é criar um plano para uma semana de trabalho,
que seja capaz de gerar (através de funcionalidades)
o máximo de valor possível para
o negócio do cliente, naquela semana.
Stand Up Meeting
O stand up meeting é uma reunião
rápida (em torno de 15 minutos) realizada
no início de cada dia, onde os participantes
normalmente ficam em pé (daí a
origem do nome), cujo objetivo é atualizar
todos os membros da equipe a respeito do que
ocorreu no dia anterior e priorizar as atividades
do dia que se inicia. Ela é uma forma
simples de assegurar que as pessoas obtenham
feedback rápido sobre qualquer aspecto
do projeto, bem como um mecanismo para planejar
o que precisa ser feito primeiro, fazendo com
que todos relembrem e reavaliem frequentemente
o que é mais importante de se fazer a
cada dia.
Programação em Par
Programação em par é uma
das práticas mais conhecidas e mais polêmicas
utilizadas em projetos XP. Quando adotada, todo
e qualquer código produzido no projeto
é implementado por duas pessoas juntas,
diante do mesmo computador, revezando-se no
teclado. À primeira vista, parece impensável,
pois dá a impressão incorreta
de que consome mais recursos ou eleva o tempo
do desenvolvimento. Mas, não é
o que acontece.
Companhias aéreas, por exemplo, utilizam
co-pilotos, quando na prática, o piloto
teria condições de realizar todo
o trabalho sozinho. Elas colocam dois profissionais
(exaustivamente treinados e relativamente caros)
para fazer o trabalho que um só poderia
fazer porque acredita-se (e as estatísticas
confirmam) que a chance de duas pessoas errarem
seja significativamente menor que a probabilidade
de uma única pessoa se equivocar.
A programação em par é
uma forma eficaz de reduzir a incidência
de bugs, pois trata-se de um mecanismo de inspeção
de código que opera permanentemente ao
longo do projeto. Ela ajuda os desenvolvedores
a criarem soluções mais simples,
mais rápidas de implementar e mais fáceis
de manter. Isso ocorre devido à oportunidade
de dialogar, trocar idéias e explorar
mais alternativas do que os desenvolvedores
fariam se estivessem sozinhos.
A programação em par também
produz um efeito conhecido como pressão
do par que faz com que os desenvolvedores tenham
maior foco na atividade e faz com que isso se
mantenha por mais tempo. Maior foco significa
menos dispersões ao longo do dia, o que
por sua vez significa que a empresa aproveita
melhor o tempo que o desenvolvedor passa com
ela.
Uma das características mais marcantes
da programação em par é
a sua capacidade de disseminar conhecimento,
que ajuda a elevar rapidamente as habilidades
técnicas dos membros da equipe. Isso
tem efeitos extraordinários no médio
e longo prazos, porque quanto mais habilidoso
um desenvolvedor é, melhores se tornam
suas soluções. Elas ficam mais
claras, mais limpas, mais fáceis de compreender
e se acerta mais vezes. Além disso, normalmente
se consegue gerar tais soluções
com maior rapidez. O efeito cumulativo de inúmeras
soluções melhores e mais rápidas
ao longo do projeto representa um enorme ganho
de produtividade.
O conjunto de características apresentadas
acima faz com que a programação
em par acelere o desenvolvimento e o torne mais
econômico, embora à primeira vista
pareça o contrário. Em função
da redução de bugs (e conseqüente
redução no tempo de depuração),
pressão do par, maior simplicidade das
soluções, disseminação
do conhecimento, maior confiança nas
soluções, entre outros efeitos
que a programação em par produz,
uma atividade feita em par normalmente é
encerrada mais rapidamente que outra feita por
um programador solitário. Alem disso,
a solução tende a ser melhor e
mais confiável. |
