Programação extrema
Imagine o seguinte: um projeto de desenvolvimento de software para um novo produto, baseado na vantagem de primeiro no mercado, acaba de ser detectado no radar da sua empresa. Métodos tradicionais de programação extrema, onde o cliente sabe "exatamente" o que deseja, estão disponíveis. Sua equipe é pequena e composta por jovens profissionais que provavelmente responderão bem a um modelo radical de gerenciamento de projetos. Quais são as suas opções?
Você provavelmente dirá, Gerenciamento Ágil de Projetos, é claro! Mas qual metodologia você gostaria de usar? Existem várias opções: por um lado, existe o imensamente popular Scrum: que envolve a criação de "sprints" curtos com base no backlog de tarefas do cliente. E há o Kanban, que trabalha para otimizar o pipeline de trabalho. Há também Extreme Programming, muitas vezes abreviado para XP, que se concentra em amplificar os aspectos positivos dos modelos de programação tradicionais para que eles trabalhem em seu potencial máximo.
A Programação extrema é uma metodologia extremamente popular (embora não tão popular quanto o Scrum), focada em atender às mudanças nos requisitos dos clientes. O primeiro projeto de programação extrema foi iniciado em março de 1996 por Kent Beck na Chrysler. Em seu livro de 1999, Extreme Programming Explained: Embrace Change, ele detalhou os aspectos do desenvolvimento de software.
Kent Beck também foi o pioneiro do desenvolvimento orientado a testes, que colocou os testes de casos de uso no radar como uma melhoria na maneira como as coisas eram feitas na época: escrever linhas e linhas de código e testá-las. Ele também foi um dos signatários originais do Manifesto Ágil, ajudando a moldar o manifesto para mudar a maneira como o software de programação extremo foi escrito.
Os cinco valores da Programação Extrema baseados em Explained estamos:
Comunicação
A programação extrema não depende de documentação extensa. Por uma questão de fato, documentação de programação extrema é sugerida apenas quando necessário. Portanto, a metodologia depende muito da comunicação entre os membros da equipe e também com os usuários.
Simplicidade
Este é o cerne da Extreme Programming. A metodologia favorece projetos simples, sem pensar muito no futuro, mas com foco nos requisitos atuais, enquanto torna o programa robusto o suficiente para adicionar os requisitos que o futuro apresenta.
Comentários
Esse ciclo essencial de alternância entre sistemas Agile em geral e Extreme Programming em particular, de outras metodologias de gerenciamento de projetos de software. O feedback contínuo pode funcionar de maneiras diferentes, mas todos eles trabalham para tornar o sistema mais forte e mais confiável.
O feedback pode ter diferentes sabores:
- Do próprio programa: o código é vigorosamente testado ao longo do ciclo de desenvolvimento do projeto, para que as mudanças possam ser implementadas pelos desenvolvedores.
- Do cliente: essa é uma parte essencial da maioria dos sistemas Agile. Os clientes escrevem os testes de aceitação nos quais o desenvolvimento se baseia e isso forma a espinha dorsal do processo de desenvolvimento. Todas as iterações também são entregues ao cliente, para um feedback periódico.
- Da equipe: Depois que um novo caso / história de uso é criado, a equipe reverte imediatamente com estimativa de custo e linha do tempo, fortalecendo os requisitos à medida que surgem. Na Programação Extrema, ninguém é dono de nenhum código e, portanto, dentro de equipes de programação extremas, o feedback sobre o código de outra pessoa é incentivado.
Coragem
Isso pode parecer um valor estranho em programação extrema para desenvolvimento de software, mais adequado para algo como o exército ou os fuzileiros navais! No entanto, pense bem: há muito que os projetos de software são afetados pelos métodos tradicionais de gerenciamento extremo de programação; seguro no conforto de uma extensa documentação e hierarquia que não permite inovação. Este valor exemplifica o núcleo da programação extrema: esteja pronto para pular, sem pára-quedas, se for o caso! Observe esse estilo diferente de gerenciamento de projetos e esteja pronto para ser responsável, renunciar à hierarquia e ser responsável e trabalhar sem saber tudo no início.
Respeito
O respeito, o quinto valor, foi acrescentado mais tarde e significa respeito pelos outros e pelo eu. Implica também o respeito pelo código que está sendo escrito e pelas expectativas e necessidades do cliente. Esse valor está subjacente à comunicação entre diferentes partes interessadas também.
Atividades de um projeto de programação extrema
A Programação extrema distingue quatro atividades simples de um projeto. Eles são:
- Codificação : a programação extrema considera essa a atividade mais importante. "Sem código, não há nada", diz Kent Beck, fundador da Extreme Programming.
- Teste : o código é apenas isso, a menos que seja testado. A Extreme Programming é obsessiva em relação ao teste, usando testes de unidade para confirmar que o código está funcionando e testes de aceitação gerados pelo cliente para confirmar que o código está testando o que precisa ser testado.
- Ouvir: ouvir, exemplificado pelo valor principal da comunicação, é uma atividade que exige que os desenvolvedores não apenas ouçam os clientes, mas realmente ouçam o que desejam. Desenvolvimento e negócios são duas coisas diferentes e, geralmente, os desenvolvedores não conseguem entender o caso de negócios de uma decisão específica. As necessidades do cliente, assim como as do desenvolvedor, formam a base da atividade de "escuta".
- Design : pode surpreendê-lo que, em um projeto de desenvolvimento de software, a atividade de design, geralmente tão importante e primária, seja colocada no final. Isso ocorre porque a Extreme Programming deseja deliberadamente tirar as pessoas da mentalidade de “projetar e desenvolver” que a indústria alimenta há muitos anos. Não é para limitar a importância do design. Em vez disso, o design bom e minimalista é uma das características de um projeto.
Dos valores e atividades emergem os 12 princípios da Extreme Programming, conforme elaborados por seu fundador, em seu livro Extreme Programming Explained.
- Jogo de Planejamento
- Programação em pares
- Desenvolvimento Orientado a Testes
- Equipe inteira
- Integração contínua
- Design Improvement
- Pequenas Versões
- Padrões de codificação
- Propriedade do código coletivo
- Design simples
- Metáfora do Sistema
- Ritmo Sustentável
Algumas dessas práticas extremas de programação, todas mapeadas para as melhores práticas da engenharia de software, são diferentes das metodologias genéricas do Agile. Algumas das práticas de programação extrema são explicadas abaixo:
-
Jogo de Planejamento
Esta é a parte do planejamento do projeto, chamada de "Jogo do Planejamento". Inclui planejamento para a próxima iteração e release, em consulta com o usuário / cliente, além de um planejamento interno das equipes, bem como das tarefas nas quais eles trabalharão.
-
Programação em pares
Isso envolve duas pessoas trabalhando em um pedaço de código. Uma pessoa, chamada teclado, digita o código, enquanto a outra, chamada monitor, supervisiona o código, comentando e refinando-o, conforme a necessidade. As duas pessoas geralmente trocam seus papéis. Foi provado que isso melhora significativamente a eficiência do código. Isso pode não ser adequado para todos os cenários de desenvolvimento, e isso é algo a considerar antes de se inscrever na Extreme Programming.
-
Desenvolvimento orientado a teste
Todo o código que é escrito é revisado por unidade, ou seja, cada pedaço de código que pode fazer algo é testado primeiro. A programação extrema enfatiza bastante os testes. Isso ajuda a confirmar que o código funciona e, portanto, pode ser considerado para inclusão no próprio projeto de programação extremo. É análogo aos testes de unidade na escola: pequenas informações testadas, para que o professor / aluno possa fazer as correções do curso e não se atrapalhar durante os exames anuais!
-
Melhoria de design (refatoração)
Os projetos XP, baseados em seu recurso de simplicidade, visam melhorar continuamente o código que é escrito. Isso significa que todo o código (e às vezes também o banco de dados) é sempre aprimorado. A refatoração não adiciona nenhuma funcionalidade; apenas melhora o código existente. Torna mais apertado e claro. É como editar um pedaço de texto, polir e torná-lo melhor.
-
Design simples
Na Programação extrema, os recursos não são adicionados até que seja especificamente necessário. Mesmo se o código que está sendo trabalhado atualmente for muito semelhante ao que pode ser necessário no futuro, ele não será utilizado, a menos que seja acordado como uma história de usuário.
-
Metáfora do Sistema
Isso inclui a padronização de todas as convenções de nomenclatura para que seu objetivo e função sejam facilmente decifrados. Por exemplo, as operações ou podem ajudar qualquer programador a entender sua funcionalidade. Isso deve ser feito em todo o projeto de programação extremo, para que seja fácil para qualquer um olhar para o código e modificá-lo ou melhorá-lo, conforme o caso.
Funções em um projeto de programação extrema:
Como o Scrum, a Extreme Programming tem algumas funções designadas em cada projeto. Agora, os papéis nem sempre precisam ser desempenhados por pessoas distintas, e uma pessoa pode assumir mais de um papel.
As funções de programação extrema são:
- Cliente : Auto-explicativo. O motivo do projeto. Ela decide o que o projeto precisa fazer. Ela fornece as histórias de usuários.
- Programador : é a pessoa que:
- Leva as histórias que o cliente cria
- Cria tarefas de programação a partir de histórias
- Implementa as histórias de usuário
- Testa o código por unidade
- Coach : O coach geralmente garante que o projeto esteja no caminho certo e também ajuda quando necessário.
- Rastreador : O Rastreador faz consultas específicas aos programadores em um intervalo definido. Normalmente, ele verifica o progresso dos programadores, oferecendo ajuda sempre que necessário de várias maneiras: arregaçando as mangas e ajudando diretamente com o código, informando o técnico ou organizando uma reunião com o cliente, conforme a necessidade.
- Testador : executa testes funcionais. O testador não executa testes de unidade, que são executados pelos próprios programadores.
- Doomsayer: Isso, como o nome sugere, é semelhante ao Black Hat no sistema de pensamento em grupo de Edward De Bono. Qualquer pessoa pode ser um Doomsayer, que normalmente sinaliza problemas em potencial e ajuda a manter os problemas na perspectiva correta.
- Gerente : O gerente de um projeto de programação extrema é mais como um agendador, garantindo que as reuniões ocorram conforme o planejado e assegurando que as decisões tomadas durante as reuniões sejam repassadas à pessoa apropriada, com mais frequência do que o rastreador. O gerente, no entanto, não diz às pessoas o que fazer e quando fazer. Isso é feito pelo cliente e / ou pelas próprias histórias de usuário.
- Dono de ouro : O Dono de ouro é a pessoa que financia o projeto. Este poderia ser o cliente, mas não necessariamente.
Algumas das funções extremas de programação, como descritas acima, podem ser combinadas, mas algumas claramente não podem.
O cliente, por exemplo, também não pode ser o programador. O Programador e o Rastreador, da mesma forma, não podem ser com sucesso a mesma pessoa.
As funções extremas de programação são definidas com clareza suficiente para que não haja confusão e criadas para máxima flexibilidade e eficiência.
Desvantagens da programação extrema:
Embora os proponentes da Programação Extrema pintem uma imagem otimista, o fato é que a Programação Extrema, como o nome provavelmente sugere, é Extremamente Difícil de implementar. As facetas da programação extrema podem ser incorporadas aos projetos com mais êxito do que a adoção completa do XP.
Alguns dos negativos da Extreme Programming são:
- A programação extrema é mais eficaz em grupos menores . Sua eficiência em grupos maiores é contestada, e uma opção melhor é dividir equipes de programação extremas para que os grupos sejam menores.
- Um dos principais recursos da Extreme Programming, a programação em pares não funciona bem em muitos casos . A codificação complexa pode exigir duas cabeças, mas nem todas as tarefas podem exigir duas pessoas, com a segunda pessoa sendo um peso morto. De fato, a programação em pares, se um dos membros não estiver sincronizado com o outro, é uma das principais razões pelas quais a Programação Extrema falha em muitos casos.
- A dependência do cliente, a ponto de sugerir um recurso no local por parte do cliente, pode ser profundamente irritante. Também pode levar a interferências, reais e imaginárias, durante o desenvolvimento.
- O foco da Extreme Programming na simplicidade pode dificultar a adição ao projeto atual, o que significa um orçamento mais alto para alterações simples, que não são mais simples.
- A estrutura hierárquica simples significa que a equipe deve sempre estar focada e, na ausência de um gerente para encurralar tipos divergentes de pessoas, uma equipe de Programação Extrema depende inteiramente da maturidade emocional de todos os membros da equipe, um fator que nem sempre é confiável .
Mesmo com esses fatores, a Extreme Programming continua sendo uma ferramenta poderosa a ser usada no projeto certo, com as empresas relatando um aumento múltiplo em sua eficiência após adotar o processo de programação extremo. Um sistema orientado a desenvolvedores, em oposição ao Scrum, que é mais um sistema orientado a processos, Extreme Programming, ou pelo menos partes dele, pode levar a uma revolução na maneira como desenvolvemos software de programação extremo.