Metodologia XP (eXtreme Programming)
Entre 80% e 90% dos projetos de software fracassam devido a atrasos no cronograma; falta de planejamento; inúmeros bugs; incompreensão dos requisitos do negócio e sistema; e, mudanças constantes de requisitos, equipes, cronograma etc.
Os projetos de criação de software alcançam o sucesso se estiverem calcados em um processo de desenvolvimento. Sendo assim, já algum tempo, os desenvolvedores e gerentes de informática têm adotado metodologias que primam pela organização, através de um planejamento rigoroso e da elaboração de modelos que retratam as funcionalidades, partes componentes do software a ser implementado etc.
O uso de metodologias de desenvolvimento de fato possibilitou uma melhor gerência dos projetos de software, no entanto, foram criadas diversas tarefas adicionais que passaram a retardar a própria implantação do software.
O que se via no passado eram processos em que se deveria analisar, projetar e somente depois iniciar a codificação. Além disso, tais processos pressupunham a certeza do que se sabe hoje será exatamente o que se quer amanhã.
Qualquer mudança de requisitos depois de concluída a fase de análise e projeto consistia em uma grande preocupação por parte dos desenvolvedores. Com isso, a manutenção do software em etapas posteriores ao seu início seria mais custosa como ilustra o gráfico a seguir.
Com a adoção de processos mais ágeis incentivadores de pequenas iterações, mudanças em etapas posteriores se tornam mais baratas. A mudança passou a ser bem vinda, visto que a engenharia de software é diferente das outras engenharias, pois componentes, frameworks e bancos de dados podem absorver o alto custo da mudança. A próxima figura ilustra o conceito.
De acordo com o criador do XP, Kent Beck, Extreme Programming é uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança. XP é uma metodologia transparente, humana, produtiva, disciplinada e divertida. Extreme Programming (XP) prima pela satisfação do cliente e pela qualidade do software final. Vem causando, com isso, grande comoção em um mercado de desenvolvimento de software cansado do alto custo das metodologias pesadas tradicionais e do notório fracasso da maioria de seus projetos.
Dentre as principais diferenças da XP em relação às outras metodologias estão:
• Feedback constante • Abordagem incremental
• A comunicação entre as pessoas é encorajada.
A maioria das regras da XP causa polêmica à primeira vista e muitas não fazem sentido se aplicadas isoladamente. É a sinergia de seu conjunto que sustenta o sucesso de XP, encabeçando uma verdadeira revolução no desenvolvimento de software.
A XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas.
As regras, práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem.
A finalidade do princípio de comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação.
A comunicação entre os desenvolvedores e o gerente do projeto também é encorajada.
A simplicidade visa permitir a criação de código simples que não deve possuir funções desnecessárias. Por código simples entende-se implementar o software com o menor número possível de classes e métodos.
Outra idéia importante da simplicidade é procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro.
A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis.
A prática do feedback constante significa que o programador terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado.
Em relação ao cliente, o feedback constante significa que ele terá freqüentemente uma parte do software totalmente funcional para avaliar. O cliente então constantemente sugere novas características e informações aos desenvolvedores.
Eventuais erros e não conformidades são rapidamente identificados e corrigidos nas próximas versões. Desta forma, a tendência é que o produto final esteja de acordo com as expectativas reais do cliente.
É necessário coragem para implantar os três valores anteriores. Por exemplo, não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento. A coragem também dá suporte
à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar. Além disso, é preciso coragem para obter feedback constante do cliente.
A XP baseia-se nas 12 práticas a seguir:
Planejamento (Planning Game)
Consiste em decidir o que é necessário ser feito e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros.
Além disso, a XP procura evitar os problemas de relacionamento entre a área de negócios (clientes) e a área de desenvolvimento.
As duas áreas devem cooperar para o sucesso do projeto, e cada uma deve focar em partes específicas do projeto. Desta forma, enquanto a área de negócios deve decidir sobre o escopo, a composição das versões e as datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma detalhado para que o software seja entregue nas datas especificadas.
Entregas Freqüentes (Small Releases)
Visa à construção de um software simples, e conforme os requisitos surgem, há a atualização do software. Cada versão entregue deve ter o
menor tamanho possível, contendo os requisitos de maior valor para o negócio.
Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo, melhora as avaliações e o feedback do cliente, aumentando a probabilidade do software final estar de acordo com os requisitos do cliente.
Metáfora (Metaphor)
São as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o desenvolvimento do software.
Projeto Simples (Simple Design)
O programa desenvolvido pelo método XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros.
Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem. Esta forma de raciocínio se opõe ao “implemente para hoje e projete para amanhã”.
Testes (Teste-Driven Developmet –– TDD)
A XP focaliza a validação do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando primeiramente os testes.
Focaliza o aperfeiçoamento do projeto do software e está presente em todo o desenvolvimento. A refinamento deve ser feita apenas quando é necessário, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que é possível simplificar o módulo atual sem perder nenhuma funcionalidade.
Programação em Pares (Pair Programming)
A implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. O desenvolvedor que está com o controle do teclado e do mouse implementa o código, enquanto o outro observa continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos e semânticos e pensando estrategicamente em como melhorar o código que está sendo implementado.
Esses papéis podem e devem ser alterados continuamente. Uma grande vantagem da programação em dupla é a possibilidade dos desenvolvedores estarem continuamente aprendendo um com o outro.
Propriedade Coletiva (Collective Ownership)
O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça a bateria de testes necessária.
Isto é possível porque na XP todos são responsáveis pelo software inteiro. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto com poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada.
Interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos. Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem porque fica óbvio quem deve fazer as correções quando os testes falham: a última equipe que integrou código novo ao software.
Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ter livre acesso a todos os membros da equipe.
40 Horas de Trabalho Semanal (Sustainable Pace)
A XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo.
Esta prática procura ratificar o foco nas pessoas e não em processos e planejamentos. Caso seja necessário, os planos devem ser alterados, ao invés de sobrecarregar as pessoas.
Cliente Presente (Whole Team)
É fundamental a participação do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento.
Código Padrão (Coding Standard)
Padronização na arquitetura do código, para que este possa ser compartilhado entre todos os programadores. A figura a seguir resume as práticas do XP:
Planejamento
Dividindo Responsabilidades
A chave para a gestão de um projeto de software é o equilíbrio de poderes entre o cliente e a equipe de desenvolvimento. Por essa razão, o XP procura separar claramente o papel do cliente e da equipe de desenvolvimento. Isso origina a declaração de direitos do cliente e do desenvolvedor.
Direitos do Cliente
1. Você tem o direito de receber um plano geral para que você saiba o que poderá ser feito, quando e com que custo;
2. Você tem o direito de receber o máximo de valor de cada semana de trabalho da equipe de desenvolvimento;
3. Você tem o direito de acompanhar o progresso do projeto através de um sistema executável, que demonstra estar correto por passar nos testes que você especifica;
4. Você tem o direito de mudar de idéia, substituir funcionalidades e alterar prioridades sem ter que pagar um preço exorbitante;
5. Você tem o direito de ser informado sobre mudanças no cronograma a tempo de decidir como reduzir o escopo para ser capaz de manter a data original. Você pode cancelar o projeto a qualquer momento e receber um sistema executável que reflete todo o investimento que foi feito até a data do cancelamento.
Direitos do Desenvolvedor
1. Você tem o direito de saber quais são as necessidades, bem como suas prioridades;
2. Você tem o direito de produzir um trabalho de alta qualidade permanentemente;
3. Você tem o direito de pedir e receber ajuda de seus colegas e do cliente;
4. Você tem o direito de gerar a atualizar a suas estimativas;
5. Você tem o direito de escolher as suas responsabilidades, ao invés delas serem determinadas para você.
Escrevendo Estórias
Todas as funcionalidades do sistema são levantadas através de estórias (user stories) que são registradas em pequenos cartões (ver figura a seguir). Essas estórias devem ser sempre escritas pelo próprio cliente, com suas próprias palavras.
Não devem existir regras de formato para escrevê-las. A única coisa que o cliente deve fazer é respeitar o espaço do cartão, de modo que as estórias sejam sempre simples.
As estórias pode ser subdivididas em tarefas no caso de apresentarem um tamanho grande. Como exemplo de estória, pode-se citar:
“Produzir um extrato para cada conta, mostrando a data, o número, o beneficiário e a quantia da transação. Segue, um extrato de exemplo em anexo –– faça o relatório parecer com o exemplo”.
Estimando as Estórias
Os desenvolvedores costumam estimar indicando a quantidade de tempo (horas, por exemplo) que uma funcionalidade irá consumir. As estimativas em XP não se baseiam em tempo previsto de desenvolvimento porque isso pode gerar distorções.
Por exemplo, no início do projeto, estima-se que determinada estória irá consumir um dia para ser implementada. Contudo, a estória não é prioritária e o cliente decide que ela só deve ser implementada no quinto mês do projeto.
No quinto mês, essa estória levará mais de um dia, pois a equipe no início do projeto somente se preocupava com a implementação de
novas estórias, no entanto agora no quinto mês, a equipe tem outras atividades como, por exemplo, atualização do modelo de dados.
O XP utiliza o conceito de dia ideal de desenvolvimento que representa um dia no qual o desenvolvedor só trabalha na implementação de funcionalidades, sem ter que se preocupar com nenhuma atividade extra.
No XP, todas as estimativas são feitas, considerando dias ideais de trabalho.
Usando Pontos para Estimar
Para facilitar a comunicação, a equipe não usa o termo dia ideal de desenvolvimento. Ela simplesmente se refere a ele como sendo um ponto. O ponto é a unidade de medida usada para estimar e acompanhar todas as estórias.
Em projetos grandes nos quais as estórias são longas, o ponto pode significar uma semana ideal de desenvolvimento. O importante é que todos entendam bem o significado do ponto adotado em cada projeto. Além de simplificar a comunicação entre os membros da equipe, o ponto também é usado para registrar as estimativas nos cartões. Em cada cartão, a equipe registra a quantidade de pontos estimados.
Estimando por Comparação
A equipe deve procurar estimar por comparação sempre que isso for possível. Estimar por comparação significa buscar cartões que já tenham sido implementados e que sejam semelhantes ao que está sendo estimado.
Se um cartão com tal característica for encontrado, a equipe utiliza a quantidade de pontos realmente consumida pelo cartão como sendo a estimativa do novo cartão.
Estimando em Equipe
Quando um desenvolvedor gera uma estimativa sozinho, ele se baseia em um conjunto de conhecimentos técnicos, sentimentos, experiências passadas e atividades necessárias para a implementação da estória.
Se o mesmo desenvolvedor fizer a estimativa com a ajuda de um colega, o resultado final provavelmente será diferente. Nesse caso, a estimativa irá se basear em um conjunto maior de conhecimentos e experiências.
O XP recomenda que as estimativas sejam feitas sempre em equipe, de modo que todos possam avaliar as estórias e identificar aspectos importantes.
No XP, é muito importante que o cliente esteja presente durante a elaboração das estimativas. A sua presença permite que a equipe de desenvolvimento tire eventuais dúvidas sobre as estórias.
Isso ajuda a estimar de forma mais ágil e aumenta a qualidade das estimativas, pois as dúvidas são respondidas pelo cliente rapidamente, o que evita que os desenvolvedores assumam premissas que podem estar incorretas.
O XP se baseia fortemente em comunicação aberta e honesta entre todas as pessoas envolvidas no projeto.
O cliente não deve ser visto como uma pessoa que está for do desenvolvimento. Pelo contrário, ele precisa ser encarado como um membro da equipe de projeto, cuja participação é essencial para o seu sucesso.
