O Cesar Brod publicou no Dicas-L um artigo introdutório e muito claro sobre o conceito de Exterme Programming (XP), que vem sendo cada vez mais utilizado para melhorar a qualidade e eficiência das equipes de desenvolvimento de software:
“Quando comecei a assistir à palestra do pessoal da Hiperlógica sobre Extreme Programming na LinuxExpo que aconteceu em São Paulo, em maio de 2001, cheguei a pensar: “Justo agora que adotamos a UML me aparecem com mais uma metodologia…”. Logo notei, porém, que a metodologia Extreme Programming, ou XP, não chega a se opor à UML e é, em praticamente todos os casos, um bom complemento à ela. Mais do que isto, descobri que já utilizávamos no desenvolvimento de nossos projetos em software livre, mesmo que intuitivamente, muitos dos conceitos de XP.
…
O desenvolvimento de um projeto com XP passa por quatro fases: Planejamento, Projeto, Codificação e Testes, cada fase contemplando um conjunto de regras.
…
O planejamento começa com a escrita de User Stories, uma espécie de Use Cases (UML) “diet”. O usuário ou cliente escreve histórias que representam o que o sistema deve fazer por eles, evitando usar qualquer terminologia técnica. Em conjunto com os programadores, o tempo de desenvolvimento de cada módulo do sistema que contemple cada uma das User Stories é estimado. Caso o tempo estimado para o desenvolvimento seja maior do que três semanas a Use Story deve ser subdividida em outras.
A fase seguinte é a Release Planning, onde a equipe de negócios e a de desenvolvimento concordam com a ordem na qual os módulos do sistema serão desenvolvidos e entregues para a produção. importante que a equipe de negócios esteja envolvida, pois nem sempre é possível para os programadores avaliarem a importância da disponibilização de um determinado módulo do sistema, ao mesmo tempo que pode ser difícil para a equipe de negócios entender a dependência entre os módulos do sistema. Para um executivo pode ser crucial que um relatório financeiro possa estar disponível rapidamente, mas ele depende de módulos contábeis que devem ser escritos antes. Ao final do Release Planning deve estar claro para todos a ordem na qual os módulos do sistema serão disponibilizados, e todos devem se comprometer com isto. Para facilitar este planejamento, a equipe deve procurar levar em conta apenas quatro variáveis: escopo, recursos, tempo e qualidade. vezes pode ser possível adiantar o desenvolvimento de um módulo, por exemplo, se diminuirmos seu escopo, ou seja, a quantidade de coisas pela qual tal módulo é responsável. Sempre é possível também diminuir o tempo de realização de um projeto aumentando os recursos disponíveis para ele. Não é recomendável, porém, acelerar um projeto diminuindo os testes do sistema, comprometendo assim sua qualidade. Concentrando-se apenas nestas quatro variáveis é possível acelerar as decisões sobre a seqüência de desenvolvimento.
Outra regra é Move People Around. O conhecimento não deve ser concentrado nas mãos de poucas pessoas. Envolva pessoas em diferentes projetos e troque-as de tempos em tempos.
A comunicação entre as pessoas e o envolvimento dos usuários (clientes) no desenvolvimento é extremamente importante. Não se deve, porém, perder mais tempo na comunicação dos resultados e na tomada de decisões do que no desenvolvimento em si. Por isto a XP propõe Stand-up Meetings, reuniões que devem acontecer todos os dias pela manhã, preferencialmente no ambiente de desenvolvimento. Estas reuniões informais devem tender a substituir integralmente todas as demais reuniões.
Uma das regras mais importantes do Planejamento em XP é Fix XP when it breaks, ou seja, se a metodologia não está funcionando, conserte a metodologia! Nem sempre pode ser possível seguir tudo o que uma determinada metodologia propõe, e faz mais sentido mudar a metodologia do que querer acomodar, em todos os casos, o desenvolvimento de um sistema a regras imutáveis.”
Leia o artigo completo no: https://www.dicas-l.com.br/brod/brod_20060928
