O XP foi criado considerando que mudanças são inevitáveis e que
devem ser incorporadas constantemente. Este processo ágil resultou da experiência no projeto
C3 Payroll na empresa Chrysler, e após seu sucesso, começou a despontar no meio
acadêmico e empresarial e se tornou alvo de inúmeras pesquisas e discussões, além de
ser adotado em diversas empresas de software do mundo inteiro.
Este método se baseia em alguns valores (comunicação, simplicidade, feedback e coragem) que servem como critérios que norteiam as pessoas envolvidas no desenvolvimento de software e princípios (feedback rápido, assumir
simplicidade, mudança incremental, abraçando mudanças e trabalho de qualidade) que devem ser seguidos por equipes que forem usar XP em projetos.
Existem alguns fatores
que são fortes indicadores para não usar XP como, cultura organizacional, equipes grandes, clientes
desconfiados e tecnologia que não dá suporte facilitado para mudanças. Segue uma breve descrição destes indicadores:
• Cultura: A organização pode estar inserida dentro de uma cultura
tradicional de desenvolvimento de software, produzindo muita
documentação, gastando muito tempo com análise e projeto antecipado,
entre outras coisas. Fazer com que a equipe passe a adotar as práticas de
XP e esqueça as antigas pode ser muito difícil;
• Tamanho da equipe: Um projeto XP deve possuir uma equipe pequena
– geralmente até 12 programadores. É difícil imaginar como ficariam
alguns conceitos de XP como comunicação, programação em par e
outras em uma equipe grande (Ex. 100 pessoas);
• Tecnologia: Não se deve usar XP quando uma tecnologia é complicada
para escrever casos de teste, quando retorna feedback em um tempo
longo ou quando não incorpora facilmente as mudanças.
• Espaço físico: A organização do espaço físico onde a equipe de XP
trabalha deve facilitar a comunicação e deixar todos próximos uns dos
outros;
• Cliente: XP exige que o cliente participe da equipe do projeto e trabalhe
no mesmo local dos demais, estando a disposição, de preferência, o
tempo todo para esclarecer dúvidas. Caso não possa ser alguém da
organização do cliente alguém deve ser alguém que entenda do negócio do cliente e que seja capacitado para exercer este papel. O cliente
também não precisa estar disponível todo o tempo embora seja
preferível.
Gostou ? Ao decorrer dos posts irei trazer mais informações sobre este método ágil tão atual e presente no dia-a-dia da maioria das organizações desenvolvedoras de software.
Referências
.
Nenhum comentário:
Postar um comentário