PROGRAMAÇÃO EXTREMA - XP

Transcrição

1 PROGRAMAÇÃO EXTREMA - XP Hoje em dia o maior problema para a entrega de um projeto, é a quantidade de riscos que podem ocorrer com o mesmo, como atraso na entrega, sistema que está sendo entregue não é o mesmo que foi solicitado, assim, cria-se uma grande lista de problemas que ocorrem com um projeto. Segundo Kent [BECK, 2004] alguns riscos podem ocorrer no desenvolvimento de um projeto como, por exemplo: deslizes no cronograma, projeto cancelado, taxa de erros, negócios mal compreendidos, modificações nos negócios e outros. O mesmo relata, ainda, o que a XP pode fazer para reverter essa situação como, por exemplo: Taxa de Erros a XP faz testes sob a perspectiva tanto do programador desenvolvendo testes a cada função quanto do cliente desenvolvendo testes a cada funcionalidade do programa. A XP traz quatro valores com ela, que é a comunicação, a simplicidade, o feedback e a coragem. No primeiro, a XP procura fazer com que os integrantes de uma equipe se comuniquem da melhor forma possível, pois isso ela procura montar um ambiente físico de forma que todos possam se comunicar sem barreiras (paredes ou divisórias altas) faz também com que os programadores programem em dupla para que ocorra uma maior interação com os mesmo. No quesito simplicidade, a XP defende que é melhor programar uma coisa mais simples agora do que fazer algo que possa ser grandioso e nunca ser usado, pois ela pensa que fazendo o que é simples no momento, posteriormente é mais simples incrementar, mesmo que tenha que pagar por isso, pois se for algo muito grande logo no inicio, pode ocorrer que o que foi feito nunca será utilizado por completo. No que se diz respeito ao Feedback, a XP defende que quanto mais feedback tiver no desenvolvimento, melhor será a comunicação e a simplicidade do projeto, pois o feedback é o que vai mostrar o que está sendo feito e qual o grau de satisfação de todos os envolvidos, podendo assim fazer as mudanças necessárias par que possa seguir em frente com o projeto. No ultimo quesito relata-se a coragem, que defende a atitude da equipe ou de um membro da equipe, pois como é citado por Kent [BECK, 2004], às vezes é necessário jogar o código fora e refazê-lo de forma mais clara e mais simples, pois assim quando ocorrer um erro ou algo do tipo será mais simples para fazer uma manutenção, diz também que a coragem está diretamente ligada a comunicação, pois é necessário você saber o que está ocorrendo para poder fazer algo que ninguém espera, por exemplo.

2 PRÁTICAS DA PROGRAMAÇÃO EXTREMA - XP metodologia XP. Praticas é o que ocorre no dia a dia de uma equipe de programação que utiliza a Práticas em XP representam aquilo que você verá as equipes XP fazendo diariamente. Práticas por si só são estéreis. A menos que você dê algum propósito, dado por um conjunto de valores, elas não fazem muito sentido. Programação em par, por exemplo, não faz sentido como algo para simplesmente ir fazendo. Fazer par simplesmente para agradar o chefe é frustrante. Programação em par para comunicar, obter feedback, simplificar o sistema, capturar erros e aumentar sua coragem faz bastante sentido. Práticas dependem da situação, do contexto. Se a situação muda, você seleciona práticas diferentes para abordar estas condições. Seus valores, por sua vez, não têm que mudar para se adaptar a uma nova situação. Alguns novos princípios podem vir a ser necessários quando se muda de domínio. [TELES, 2006]. A seguir serão explicadas as 12 praticas que envolvem a Programação Extrema segundo Kent [BECK, 2004]: O JOGO DO PLANEJAMENTO Determine brevemente o escopo da próxima versão combinando prioridades de negócios e estimativas técnicas. Quando a realidade se opuser ao planejamento, atualize o planejamento. [BECK, 2004]. É o jogo jogado por todos os envolvidos no projeto, é o escopo do que deverá ser feito com o projeto, as etapas do desenvolvimento, isso significa que as pessoas na área de negócio têm que decidir sobre o escopo, prioridade, composição das versões e datas de entrega. Sendo assim a parte técnica também necessita tomar suas decisões em relação às estimativas, consequências, processo e cronograma detalhado. Isso tudo serve para que todo o processo corra de uma forma simples e organizada. ENTREGAS FREQUENTES Coloque um sistema simples rapidamente em produção e depois libere novas versões. [BECK, 2004]. Esse procedimento é para manter o cliente informado de que o sistema está sendo feito e de forma rápida, não significa que será entregue mais rápido, em vez de entregar tudo em um ano, pode-se fazer esse procedimento todo mês, assim em cada mês é entregue um modulo do sistema, ajudando também a equipe, para que saibam se o que estão fazendo está de acordo com que o cliente quer. O que essas entregas ajudam é fazer com que seja entregue o que realmente foi solicitado, sendo que, o cliente, com o passar do tempo, possa ate pedir para não

3 implementar alguns módulos, pois está vendo que o que está sendo entregue já é o suficiente. METÁFORA Guie o desenvolvimento com uma simples história, compartilhada por todos, sobre como o sistema funciona como um todo. [BECK, 2004]. Aqui podemos criar uma história para o sistema, fazendo com que todos entendam o que o mesmo fará quando for entregue, e também qual foi a história do sistema antes de começarem a implementá-lo, assim todos vão falar a mesma língua e programar de forma coerente e conjunta. PROJETO SIMPLES O sistema deve ser projetado da maneira mais simples possível em qualquer momento. A complexidade desnecessária é removida assim que for descoberta. [BECK, 2004]. Aqui a equipe faz com que o sistema seja feito de forma mais simples possível, deixando o que é complexo de fora, pois se torna desnecessário, pois o que é simples é que realmente é para ser feito. Edward Tufte propões um exercício para designers gráficos desenhe um gráfico de forma que você quiser. Então apague todos os elementos, desde que você não remova nenhuma informação. O que restar quando você não puder apagar mais nada é o design certo para o gráfico. [KENT, 2004] TESTES Os programadores escrevem testes de unidade continuamente, os quais devem executar sem falhas para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as funções estão terminadas. [BECK, 2004]. É um tópico muito importante, pois depois de digitar os códigos os programadores e clientes fazem os testes para que possam ter certeza de o que está sendo pedido foi o que acabaram de fazer, então isso será repetido em todos os módulos ate que tenha que ser feito no projeto todo, pois cada módulo testado e aprovado proporciona maior segurança para os envolvidos.

4 REFATORAÇÃO Os programadores reestruturam o sistema sem alterar seu comportamento a fim de remover duplicidade, melhorar a comunicação, simplificar e acrescentar flexibilidade. [BECK, 2004]. Trata-se simplesmente do programador procurar um jeito melhor de digitar o código, depois que ele termina um modulo ele fica pensando como é possível fazer o mesmo código de uma melhor forma, pois assim ele pode simplificar uma função ou mesmo dar um jeito de o sistema responder de forma mais rápida. PROGRAMAÇÃO EM PARES Todo código de produção é escrito por dois programadores em uma máquina. [BECK, 2004]. É a nova forma de programar, fazendo com que um integrante da dupla fique com o mouse e o teclado programando, enquanto o outro está pensando se tudo aquilo vai dar certo mesmo. Se há necessidade de todas aquelas linhas de código. Se há uma melhor forma para simplificar o código. Assim, a dupla programa de uma melhor forma. PROPRIEDADE COLETIVA Qualquer um pode modificar qualquer código, em qualquer lugar do sistema, a qualquer momento. [BECK, 2004]. Significa que todos da equipe estão aptos a alterar qualquer parte do código, pois o mesmo é feito de uma forma simples para que todos entendam. Assim, a propriedade coletiva ocorre é necessário que siga um padrão de codificação, fazendo também que a equipe toda fique sabendo o que está sendo feito pela a comunicação do grupo. INTEGRAÇÃO CONTINUA Integre e atualize as versões do sistema várias vezes por dia, cada vez que uma tarefa for terminada. [BECK, 2004]. O que a equipe deve fazer é sempre está melhorando o código, fazendo vários testes por dia e procurando a cada nova tentativa fazer de uma melhor forma, assim o sistema se mantém vivo para novas modificações e atualizações que possam ocorrer.

5 SEMANA DE 40 HORAS Como regra, trabalhe no máximo 40 horas por semana. Nunca faça hora extra por duas semanas seguidas. [BECK, 2004]. Essa é a ideia de que se a equipe estiver trabalhando mais do que 40 horas semanais por mais de duas semanas significa que algo está errado no projeto. Pois as horas extras não devem se tornar rotina. Pois as mesmas são para cumprir algo rápido e não se tornar obrigações. Assim o gerente deve ver o que pode ser feito para que se cumpra essa rotina de 40 horas semanais para que todos tenham tempo de descansar e de fazer um ótimo serviço no dia seguinte, sendo que isso se deve repetir todos os dias. CLIENTE PRESENTE Inclua um cliente real no time, disponível todo tempo para responder as questões. [BECK, 2004]. Esse cliente se tornará membro da equipe enquanto o seu projeto estiver sendo codificado, pois servirá para responder as questões levantadas no desenvolvimento. Assim, os desenvolvedores terão uma melhor visão do projeto fazendo com que seja feito de uma forma mais simples e correta, pois qualquer dúvida o cliente está junto para sanálos. PADRÕES DE CODIFICAÇÃO Os programadores escreverão código respeitando as regras que enfatizam comunicação através do código. [BECK, 2004]. Toda a codificação será feita da mesma forma por toda a equipe, fazendo assim com que todos entendam o que está sendo feito, e quem estiver apto a fazer mudanças está liberado para fazer, pois conhece a forma como o código foi feito. A equipe que codifica dessa forma é uma equipe completa, pois todos entendem o que cada um está fazendo, assim todos se comunicam todo o tempo, tanto nas reuniões e em conversar paralelas com a programação e, também quando verificam um código de um companheiro, pois sabe perfeitamente o que ele está querendo passar com aquela função, por exemplo.

6 REFERÊNCIA BECK, Kent. Programação extrema explicada: acolha as mudanças. Porto Alegre, RS: Bookman, 2004.