Técnico

Metodologias: Parte 2 – XP (Extreme Programming)

Primeira parte: Metodologias: Parte 1 – Scrum

Antes de iniciar o contexto do XP, é necessário entender que metodologias ágeis assim como, o Scrum e o XP, que são as que estão sendo analisadas neste post, possuem um problema de interpretação do conceito ágil. O conceito de ágil não é ser rápido, e sim ser adaptativo, é a capacidade de mudar, de acompanhar as mudanças de ambiente, e de vários fatores que podem interferir no projeto, como os requisitos do cliente, leis, equipe, por isso, todos os envolvidos no projeto devem estar preparados para este tipo de mudança, e assim, sempre poder entregar ao cliente o que realmente seja útil e funcional em seu software.

Obs.: Ao decorrer deste post pode-se notar semelhanças com o post anterior relacionado ao Scrum, isto ocorre pois algumas características não são exclusividade de uma única metodologia, estes pontos serão citados normalmente, afim de manter o contexto da Extreme Programming.

No XP e como qualquer outra metodologia, os integrantes das equipes possuem opiniões, gostos e sentimentos diferentes um dos outros. Uma pessoa pode achar que o que realmente importa é o design do software antes de sua implementação, outra pode pensar o contrário. Em muitos casos as pessoas agem com ações e comportamentos individuais, mas o que realmente importa é o seu trabalho em equipe, cada indivíduo se familiariza com um estilo de codificação diferentes uma das outras, mas em uma equipe deve-se escolher e adotar um estilo em comum. Todos devem se concentrar no que realmente é importante para a equipe como um todo, sendo assim, no XP tem-se 5 valores em que ela se baseia, para guiar o desenvolvimento do projeto, são eles:

Comunicação dentro do XP, é um dos fatores mais importantes, pois uma boa comunicação entre Cliente e Desenvolvedor é imprescindível para o sucesso do projeto. O cliente de um projeto de software possui uma série de problemas e dificuldades, que espera ser solucionada com o software solicitado, e também possui ideias de possíveis funcionalidades que possam resolver estes problemas. E do outro lado tem-se o time de desenvolvedores que possuem todos os conhecimentos técnicos para solucionar os problemas do cliente. Para que o projeto caminhe de forma correta, é necessário que haja a devida comunicação entre essas duas partes, para que os desenvolvedores entendam o que realmente o cliente necessita, e que o cliente saiba também os desafios técnicos que devem ser vencidos. Uma das melhores formas de comunicação é a comunicação presencial, nela se torna possível a análise de vários fatores que podem influenciar na interpretação do diálogo, sejam elas gestos, tom de voz, postura, emoções, expressões faciais, entre vários outros. Quanto maior for a capacidade de se compreender as partes, menores as chances de se ter entendimentos equivocados ou ambíguos.

Coragem, tem-se o fato de que um projeto sempre está sujeito a mudanças, as ideias dos clientes mudam com frequência, eles mudam pois aprendem a visualizar os problemas que possuem de um forma diferente ao decorrer do projeto, descobrem problemas com maiores prioridades, e isso é algo considerado normal, mas, por outro lado gera uma certa preocupação para com a equipe de desenvolvimento, que de tempos em tempos, necessita alterar módulos do sistema que já estavam até prontos, correndo o risco de quebrar o que já estava em funcionamento. O XP não apresenta uma solução para este tipo de risco, ele existe dentro de um projeto XP, como existe em qualquer outro. Porém, em equipes XP consideram que errar é algo natural, e que quebrar eventualmente o que já estava funcionando pode ocorrer, por isso, é necessário ter a devida coragem para lidar com esse tipo de risco, as práticas do XP são voltadas para proteger o software das mais variadas formas, e as equipes confiam nessas práticas, o que os tornam adeptos as mudanças quando necessário, ao invés de impedir as ideias do cliente e evitar mudanças.

Feedback deve ser frequente em um desenvolvimento, para que os integrantes não precisem pensar excessivamente na expansão do projeto, mas sim simplificar ao máximo o caminho para completar as tarefas, deve haver uma comunicação contínua entre cliente e desenvolvedor, afim de sempre se ter em mãos as reais necessidades do cliente, e se ter resultados claros para lidar com os problemas encontrados. Em alguns casos é necessário implementar alguma funcionalidade rapidamente para o cliente, demonstrando o processo e recebendo todo o feedback necessário, assim identificando os possíveis problemas com maior rapidez e corrigindo-os o quanto antes, evitando futuros prejuízos e custos excedentes com o projeto. Os desenvolvedores sempre procuram entregar novas funcionalidades no menor prazo possível, para que o cliente entenda com maior rapidez as consequências do que foi solicitado. Os clientes devem se manter próximos dos desenvolvedores, para sempre que necessário passar informações sobre quaisquer dúvidas ao longo do projeto.

Respeito é o valor mais básico de todos, é o que dá sustentação aos demais. Os membros da equipe só possuirão uma perfeita comunicação, a partir no momento em que se importarem uns com os outros, respeitando o ponto de vista de cada integrante, sabendo ouvir e compreender cada um deles, assim garantir que o projeto seja bem-sucedido. A falta do respeito dentro de um projeto, pode ser o suficiente para que o mesmo enfrente muitos problemas, causando até a impossibilidade de sua continuação.

Simplicidade, pode ser controvérsia, a alguns pensamentos como, por exemplo, o Just in Time implantado pela Toyota no Japão, no início era visto como uma ideia absurda, especialmente perante a indústria automobilística Norte Americana, sua ideia era não produzir mais do que o necessário. E hoje a Toyota é exemplo de eficiência e qualidade, sendo a montadora mais lucrativa do mundo. No caso do desenvolvimento de sistemas, a ideia de simplicidade não se difere muito, tendo como objetivo produzir realmente o que será utilizado, funcionalidades que realmente solucionem o problema do cliente, com o objetivo de ser o mais simples possível, ao invés de um sistema repleto de funcionalidades desnecessárias, e visualmente poluído. Alguns estudos mostram que em torno de 64% das funcionalidades geralmente produzidas em um software não são utilizadas, isso representa mais da metade do projeto todo, causando um gasto de tempo e custos desnecessários, já que tais funções não serão utilizadas. O XP se empenha em assegurar que a equipe se concentre em desenvolver primeiramente o que é realmente necessário, ao invés de rechear o projeto com várias funcionalidades que o cliente um dia possa a vir utilizar.

O Extreme Programming possui ao todo 12 práticas em que se constitui, elas foram criadas com base nos valores e princípios já apresentados anteriormente. Tais práticas não são novidades e nem exclusividade do XP, tanto que já são utilizadas a anos em projetos de software, e com eficiência. Um detalhe sobre tais práticas é que elas foram desenvolvidas para que sua utilização e avaliação fosse coletiva, afim de reduzir possíveis inconsistências, caso fossem aplicadas de forma individual. A seguir tem-se uma breve descrição de cada uma dessas práticas:

• Planning Game;
• Small Releases;
• Metaphor;
• Simple Design;
• Testing;
• Refactoring;
• Pair Programming;
• Collective Code OwnerShip;
• Continuos Integration;
• 40 Hour Week;
• On-site Customer;
• Coding Standars.

Planning Game, onde se inicia o projeto, uma curta fase exploratória. O cliente expressa seus requisitos a partir de casos de uso simplificados, que são representados como um cartão história, neste momento se torna necessário a atuação conjunta da equipe de desenvolvimento e o cliente, que irão definir um plano para a liberação destes casos de uso em determinadas versões do sistema, negociando também datas para cada lançamento, com base nas prioridades do cliente e estimativas técnicas. Nesta parte vale ressaltar, que este é apenas um plano, a equipe e o cliente devem estar ciente que não se trata da realidade, sendo que, caso a realidade supere o plano, o mesmo deverá ser atualizado. O planejamento deve se tornar uma atividade diária dentro do projeto XP, ao invés de se montar um plano inicial já concluído e irrealista. A boa equipe XP, como já dito anteriormente deve estar sempre preparada para futuras mudanças em qualquer parte do processo.

Small Releases trata do fato de não se desenvolver grandes partes de um software, e sim deve seguir um pensamento diferente, implementar uma pequena parte inicial, e em seguida desenvolvê-la gradualmente. O ideal é que a equipe entregue as novas versões do software em poucas semanas, ou até dias, e não se deve prolongar seu desenvolvimento a muitas semanas.
Uma regra fundamental no XP, é que não se deve fazer um código para o futuro, afim de antecipar possíveis exigências. Não se deve adicionar flexibilidade desnecessária em uma tarefa atual, se o desenvolvedor entende que tal flexibilidade seja necessária em uma futura semana, não se deve faze-la agora, e sim aguardar e verificar se realmente é necessária, enfim, refatorar o código e adicionar tal flexibilidade.

Metaphor, a função da metáfora é melhorar a comunicação, tanto dentro da equipe, como para com o cliente. Pode-se utilizar a definição de palavras, ou nome comum para todos, afim de criar uma fácil assimilação e entendimento de alguns assuntos.

Simple Design, o sistema deve possuir simplicidade em qualquer fase de sua evolução, seu código deve ser escrito da forma mais clara possível, possuindo uma fácil compreensão e permitindo sua continuidade por qualquer integrante do projeto. Caso alguma complexidade extra for encontrada, ela deve ser removida o quanto antes, neste caso, deve-se fazer a coisa mais simples possível que poderia funcionar.

Testing, nesta prática cada componente do sistema devem possuir testes de unidades, afim de se ter confiança no comportamento do sistema, fazendo com que seja parte do próprio sistema. Existem também casos em que os testes de unidades são desenvolvidos antes mesmo do próprio código do trabalho real, também chamado de Test-Driven.

Refactoring, neste processo, ocorre a reestruturação do sistema de forma continua, afim de melhora-lo, porém, sem alterar seu funcionamento. A cada nova funcionalidade adicionada ao sistema, ocorre a refatoração do código, com o intuito de deixá-lo em sua forma mais simples possível. Essa prática pode ser minimizada, quando o projeto é desenvolvido com 100% de seu conteúdo orientado a objeto, pois desta forma tem-se códigos mais genéricos e reutilizáveis, reduzindo o trabalho de fatoração.

Pair Programming, nesta prática há literalmente uma programação em dupla, dois desenvolvedores utilizando-se de uma mesma máquina, ela tende a melhorar a qualidade do código produzido, mas sem afetar em sua velocidade de desenvolvimento. Outro fator, é que está prática tende a melhorar também a comunicação entre todos os membros da equipe, principalmente quando estes pares se alteram com frequência, ou todos os dias. Um dos critérios para definir os pares, não é só a sua disponibilidade, mas também deve ser levado em consideração a experiência de cada pessoa. Por exemplo, quando se necessita desenvolver algo que necessite da utilização de duas tecnologias, como interface Web e banco de dados, haverá dois integrantes, cada um experiente em uma área necessária.

Collective Code OwnerShip, com a utilização da programação em dupla e o rodízio das pessoas, cada integrante do projeto automaticamente é responsável por cada arquivo de código, qualquer desenvolvedor pode efetuar quaisquer alterações nos arquivos do sistema em qualquer momento, sem ter que pedir autorização a ninguém. Levando em consideração que existam para cada componente, seus respectivos testes de unidade, isso minimiza a questão de um desenvolvedor quebrar o código do outro, e também mantêm uma melhora da agilidade da equipe.

Continuos Integration, os vários módulos do software devem ser armazenados em um repositório compartilhado entre todos, a cada nova tarefa concluída, um novo código deve ser gerado, testado, e se estiver tudo certo, integrado ao repositório. Estas alterações são executadas várias vezes ao dia, portanto, o código só deve ser adicionado ao repositório, a partir do momento que o mesmo conclua 100% dos testes unitários, gerando um novo código nos padrões do XP.

40 Hour Week, é uma prática muito importante, pois deve-se respeitar o ritmo de trabalho que se pode sustentar, sem prejudicar os integrantes, no caso, 40 horas semanais. Uma equipe desgastada fisicamente e intelectualmente, possui grandes chances de produzir um software de baixa qualidade. Caso seja necessário fazer horas extras, essa condição é aceitável, contanto que não se torne uma rotina. Este pode ser um sinal de que pode haver algo errado com o projeto.

On-site Customer, é a condição de sempre manter como parte da equipe, um usuário real do sistema, e estando sempre disponível afim de responder possíveis perguntas. Não importando o que venha a ocorrer com o projeto, nunca haverá para o cliente uma grande surpresa, se o mesmo estiver presente no desenvolvimento diariamente.

Coding Standars, por fim está é a última prática que será citada neste artigo. O time de desenvolvedor no início do projeto, deve definir e concordar com algumas regras em comum para o sistema, sobre um padrão para seu desenvolvimento. Tendo em vista esta questão, todos os integrantes possuirão a mesma visão diante do código. Isto permite que grupos de vários desenvolvedores, possam produzir um código consistente, e também facilita a sua devida comunicação.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Compartilhe isso: