Baixe o app para aproveitar ainda mais
Prévia do material em texto
6ºAula Programação extrema - XP Objetivos de aprendizagem Ao término desta aula, vocês serão capazes de: entender os conceitos da Metodologia XP saber os papéis e as principais práticas da metodologia XP entender o ciclo de vida do XP Olá, pessoal, tudo bem? Vamos agora abordar uma das Metodologias Ágeis mais populares. A Programação Extrema, que trabalha com uma série de práticas de Engenharia de Software, como a programação em pares, integração contínua, etc. Será a primeira de três metodologias que veremos nesta reta final do nosso curso. Vamos lá? Bons estudos! 185 42Met. para de Desenvolvimento de Software Seções de estudo 1 - Introdução à Programação 1. Introdução à Programação Extrema (XP) 2. Papéis da Programação Extrema 3. Principais Práticas do XP 4. O processo XP A Programação Extrema, também conhecida pela sua sigla XP (do inglês: Extreme Programming), é uma metodologia ágil que define uma série de boas práticas de desenvolvimento de software que devem ser seguidas. Bassi (2014) define XP como: A Programação Extrema é a combinação de uma abordagem colaborativa, livre boas práticas de engenharia de software independentemente do contexto. Cada uma dessas práticas contribui para o aumento da qualidade do software e ajuda a garantir que necessidades do negócio. Alguns exemplos dessas práticas são: revisão de código, integração rápida, testes automatizados, O XP surgiu na década de 1990, quando Kent Beck entrou em um projeto que já estava fadado ao fracasso na Chrysler. Diante dessa situação, Beck adotou uma abordagem totalmente diferente, usando várias boas práticas da engenharia de software (sendo que algumas dessas práticas já haviam sido documentadas na década de 1980). No final, um projeto que estava sendo considerado um desperdício de dinheiro, passou a ser um case da indústria de software. Em 2001, o próprio Kent Beck representou a metodologia XP na reunião que criou o manifesto ágil. 1.1 - Valores A proposta da metodologia XP é sintetizada em cinco valores, que são: Comunicação: Bassi (2014) afirma que o processo de desenvolvimento de um software requer que desenvolvedores e clientes se entendam mutuamente, para que a confiança da equipe seja sempre elevada. Além disso, uma boa comunicação torna a difusão do conhecimento e a implicidade: Esse valor prega em desenvolver somente o que é necessário no momento. No jargão da Keep It Simple, Stupid! - Mantenha isso simples!). Evitar o excesso de classes, excesso de complexidade, não desenvolver requisitos Como já sabemos, quando mais tempo o cliente se manifestar por uma mudança em um software já pronto, mais custos acarretará no desenvolvimento e na manutenção desse software. Assim, a metodologia XP prega que o cliente sempre manifeste suas opiniões sobre o andamento do software, para que seja verificado se o software Coragem: Esse valor está relacionado ao fato de nos processos tradicionais, os envolvidos se escondem nos processos, omitindo informações e comprometimento. No XP, as pessoas envolvidas precisam ter coragem para se comprometer com o andamento do software e coragem para informar ao cliente o que está acontecendo. Respeito: O processo de desenvolvimento de software é colaborativo. Assim o respeito mútuo entre as partes da equipe é fundamental para o que o processo ande. Portanto, são enfocadas atividades colaborativas durante todo o processo, para que seja criado um ambiente de sinergia entre os participantes. Perceba que os valores da Programação Extrema se interligam aos valores e aos princípios do manifesto ágil, que você viu na aula anterior. 1.2 - Princípios Além dos valores, a Programação Extrema define 14 princípios, que servem para definir as práticas dessa metodologia. Esses princípios também ajudam a validar se uma nova prática ou adaptação a ser agregada à metodologia está válida com os propósitos da metodologia XP. Veremos esses valores a seguir: A produção do software depende dos desenvolvedores. É importante levar em conta que suas necessidades individuais devem ser respeitadas e balanceadas com os interesses do negócio e as necessidades da equipe. A equipe deve conhecer as necessidades de negócio intervalo de tempo. Flexibilidade para reagir a mudanças com rapidez é importante para acompanhar revisões nas prioridades de negócio. Melhorias devem ser implementadas constantemente. da economia e ajudará a equipe a melhorar seu entendimento do problema. Depois, busque uma solução elegante e, por último, se isso ainda for prioritário, busque a solução ótima. Começar tentando a solução ótima vai custar mais tempo, e nem sempre será necessária. As atividades devem sempre trazer benefícios para os envolvidos. Testes, refatorações e metáforas são exemplos de atividades que trazem ganhos imediatos, pois aumentam a compreensão e planejamentos detalhados de longo prazo não trazem benefício imediato e estão altamente sujeitos a mudanças no futuro. Boas soluções devem poder ser aplicadas novamente, inclusive em outros contextos e escalas. Devemos estar atentos para processo de desenvolvimento. A equipe deve reunir muitas habilidades, opiniões e perspectivas que ajudarão a encontrar a melhor abordagem para cada situação. É importante que a equipe possua o valor do respeito 186 43 para garantir que as diferenças criem um ambiente colaborativo que favoreça o crescimento de todos. A integração do código, o desenvolvimento dirigido por testes e a entrega de novas versões devem manter um tamanho trabalho, assim poderá avaliar suas decisões e aprender com o passado, ser repetidas. O ritmo de trabalho deve ser sustentável ao longo do tempo, e a quantidade de software entregue também deve se manter estável. código em períodos os mais curtos possíveis para minimizar o risco e o tamanho de prováveis defeitos. atenta às oportunidades que surgem. Mudanças e problemas são vistos como meios para aprendizado e melhoria. Devemos acrescentar maneiras de assegurar a qualidade do software e reduzir os riscos do projeto como um todo. Aumentar as oportunidades de aprendizado diminui a concentração de conhecimento. Testar frequentemente reduz a chance de que defeitos sejam entregues ao cliente. A equipe deve ter coragem para experimentar alternativas quando o seu caminho não estiver claro, mesmo sabendo que algumas dessas opções falharão. O mais importante é aproveitar essas oportunidades para adquirir aprendizado e estar disposto a abandoná- las para investir seus esforços na melhor opção. A qualidade não é um fator negociável. O escopo e o tempo devem ser ajustados para entregar software de alta qualidade. O investimento na qualidade do código é importante para estabelecer o As responsabilidades são aceitas, e não impostas. Cada membro deve estar comprometido e disposto a colaborar da melhor forma possível com a equipe. Veremos a seguir, quais são os papéis que participam em um processo XP. 2 - Papéis da Programação Extrema Uma equipe na metodologia XP possui vários papéis de diferentes objetivos, mas que suas funções são essenciais para a sua execução. Não há um limite de pessoas na metodologia, e uma pessoa pode ocupar dois papéis diferentes em um projeto. Porém, essa prática é desaconselhável. A metodologia XP tem como principais papéis: Desenvolvedor: É o papel mais crucial na metodologia, pois são os desenvolvedores que fazem as tarefas mais vitais em um projeto XP. Escrita de história de usuário, estimativa do tempo de desenvolvimento, quebra histórias em tarefas, escreve os testes e os códigos referentes a essa tarefa, automatiza processos de desenvolvimento e melhora - aos poucos - o design dessa tarefa. Assim, um desenvolvedor multidisciplinar é ideal para o projeto. Além disso, habilidades sociais e de relacionamento são também recomendadas, visto que a programação é realizada em pares. Cliente: Ele faz a priorização do que será desenvolvido ea verificação se o software corresponde aos seus anseios. Vale lembrar que o cliente sempre deve estar o mais próximo possível da equipe para que sejam resolvidas dúvidas com os desenvolvedores. Um cliente (que financia o sistema) pode não ser um dos usuários efetivos do sistema. Nesse caso, deve-se sempre aproximar daqueles que usarão o sistema. Se o cliente não pode estar presente o tempo todo, podem ser usadas formas de que saiba das necessidades dos usuários. Coach: Deve manter o time engajado no projeto, orientando a todos sobre a disciplina nas práticas a seguir). Um coach deve ser representado por uma pessoa que não exerça o papel de gerente, para que em uma situação de dificuldade, o processo seja respeitado. Testador: Ele chefia as operações de teste do sistema de diversas formas. Ajuda o cliente a escrever os testes de aceitação, ajuda outros programadores a escrever seus testes e na resolução de problemas do sistema. Cleaner: É um profissional de excelência técnica, que “limpa” o código, promove refatorações, reduz a complexidade do sistema, aumentar a coesão do código e transforma o código no mais enxuto possível. Ele coleta as métricas do time de desenvolvimento durante a iteração, gerando dados que podem ser usados para o aperfeiçoamento da equipe durante o projeto. Gerente: Desempenha diversas tarefas no projeto, como a facilitação da comunicação entre desenvolvedores e clientes, auxilia o cliente na priorização de histórias, agenda reuniões com o cliente, auxilia no planejamento do projeto (no XP, o planejamento não é uma fase, mas sim uma fase contínua durante o projeto), gera relatórios de acompanhamento do projeto etc. Mas, vale lembrar que um Gerente não chefia a equipe de desenvolvimento. Vimos, nesta seção, os principais papéis do XP. Vamos ver, a seguir, as principais práticas adotadas na metodologia XP. 3 - Para que a metodologia XP atenda seus objetivos, várias técnicas são empregadas, sendo que muitas delas vieram das aclamadas boas-práticas de desenvolvimento de software. Veremos algumas dessas principais práticas a seguir: Testes automatizados: Nos projetos XP, é comum que os testes sejam automatizados e criados junto com o desenvolvimento do código. A razão para cedo os erros forem detectados, menos impactos 187 44Met. para de Desenvolvimento de Software eles causarão no software e mais barato será corrigi- ser determinado como pronto, deve vir com os testes implementados e funcionando. Isto evita a sobrecarga de escrever todos os testes após o código ficar pronto. Para isso são usados frameworks de testes automatizados (JUnit, PHPUnit, Selenium etc.) junto a uma técnica chamada de TDD. TDD é a sigla para “Desenvolvimento Dirigido a Testes”. É uma das práticas mais populares da engenharia de software. É uma técnica de desenvolvimento que, você pode usá-la em qualquer projeto, independentemente da metodologia que você segue para esse 1. Essa etapa consiste em você escrever o teste antes de escrever a implementação da funcionalidade. Escrevendo funcionalidade. Como nenhuma funcionalidade foi implementada, obviamente o teste irá falhar; 2. Após escrever o teste, você implementa a funcionalidade da forma mais simples possível para que ele funcione; 3. Após terminar de escrever as funcionalidades, melhore o Refatorações: São mudanças no código, com o intuito de torná-lo mais flexível, mais fácil de fazer manutenções e mais fácil de entender. Essa técnica foi descrita por Martin Fowler, em seu livro “Refatoração - Aperfeiçoando o Projeto de Código Existente”. Nesse livro, Fowler mostra possíveis situações no código que podem ser melhoradas, as quais ele chama de “Mau cheiro” (bad smells). Os testes são importantes para que sejam feitas as refatorações, pois podem indicar se um aperfeiçoamento em um trecho pode causar efeitos Programação em Pares: No processo XP, cada dupla é responsável por analisar, projetar, implementar, testar e integrar a funcionalidade na qual estão trabalhando. Assim, cada passo é realizado por dois membros da equipe, que se revezam de tempos em tempos na condução do computador: enquanto um escreve, o outro revisa o código, pensa em outras situações de testes e sugere melhorias. Essa técnica diminui as chances de soluções inadequadas e aumenta o conhecimento Para que o código seja mais legível e mais compreensível por toda a equipe, são estabelecidos padrões que os programadores devem respeitar para programar seu código (por exemplo, número de espaços de indentação nomes Propriedade Coletiva: O código não possui como dono uma única pessoa, é de propriedade de toda a equipe. Assim, qualquer um pode realizar modificações, se achar necessário. Vale lembrar que os testes garantem se uma modificação é segura ou Para que a propriedade coletiva seja colocada em prática, o código é disponibilizado em um repositório único, onde controla as alterações que foram feitas. São exemplos de programas que fornecem esse serviço o Git, Subversion e Mercurial. Além disso, pode ser usada para a integração contínua, onde a cada nova atualização do código, um programa roda todos os testes automatizados para verificar se tem algum erro ou não. São exemplos de programas (ou serviços) de integração contínua: Jenkins e Travis-CI. User Stories: Representa de forma conceitual a necessidade do usuário, sem entrar em detalhes complexos. Uma User Story é um cartão onde o usuário escreve sua necessidade da seguinte forma: Como um (tipo de usuário - gerente, cliente, funcionário), eu gostaria de (funcionalidade - ex.: cadastrar um produto, emitir um relatório) para (benefício - ex.: controlar o estoque, disponibilizar para venda, etc.). Como veremos a seguir, um cartão pode vir também com a estimativa de trabalho para a sua implementação e a prioridade especificada pelo cliente. Ainda, no verso do cartão podem conter testes que indicam se uma funcionalidade está dentro dos padrões ou não. 188 45 Vimos aqui as principais práticas da Programação Extrema. A seguir, entraremos no estudo dos processos da metodologia XP. 4 - O processo XP inicia-se na fase de exploração, onde o cliente expõe as suas necessidades aos desenvolvedores que participarão do projeto. Diante do entendimento inicial, a equipe pesquisa e discute quais tecnologias podem ser empregadas para desenvolver o software. Pode demorar de alguns dias a algumas semanas, dependendo da situação do projeto proposto. Depois que os desenvolvedores entenderem o problema, o(s) cliente(s) descreve(m) suas necessidades. Diante das necessidades expostas, os clientes e desenvolvedores discutem sugestões de mudança e tiram dúvidas sobre pontos não entendidos a respeito desses requisitos. Após todos entenderem suas necessidades (o que é fundamental nessa etapa), o(s) cliente(s) escreve(m) seus requisitos em um cartão, chamado de User Story, que é a base dos requisitos nessa metodologia. Depois que as User Stories estiverem definidas, os desenvolvedores estimam qual será o volume de trabalho exigido para programar uma User Story. Técnicas diversas podem ser usadas, como o Planning Poker ou qualquer outra técnica que considere o valor de todo o grupo de desenvolvedores. Após essa definição, a estimativa é anotada no cartão, junto com a prioridade especificada pelo cliente. Uma vez as user stories definidas e estimadas, os programadores separam essas estórias em conjuntos, com valor de mercado, para entrarem em produção juntas. Esse conjunto de estórias constitui em um release. Depois de selecionado um conjunto de cartões para ser programado em um release, os programadores dividem esse conjunto em grupos menores. As funcionalidades que compõem esses grupos menores são desenvolvidas em uma iteração. Em um release, é entregue um software executável com as estórias que foram definidas nesse período de tempo. Cada release é composto por uma ou mais iterações. Essa maneirade organizar o desenvolvimento em iterações e releases serve para tornar mais facilitada a medição do progresso de software e para que o cliente tenha o mais rapidamente possível um software pronto, que seja útil de alguma forma ao cliente. Vale lembrar que o critério que seleciona quais user stories serão implementadas é a prioridade estabelecida pelo cliente. Em cada dia da iteração, é realizada uma reunião em pé. É uma reunião rápida, com duração de 15 minutos, onde cada participante mostra o que foi feito no dia anterior, o que pretende fazer no dia, que problemas foram encontrados e se ele precisa de ajuda. Isso serve para sincronizar toda a equipe sobre o andamento do projeto. Se for detectado um problema, os interessados em resolvê-lo se identificam para encontrar uma solução após a reunião. Após isso, os desenvolvedores se organizam em pares para realizar suas tarefas. Se uma dupla não estiver trabalhando em algum cartão previamente, eles escolhem um cartão que seja de maior prioridade e compatível com o nível técnico. Posteriormente, a dupla escolhe um computador, faz o download da última versão do projeto e executa todos os testes para ver se está funcionando. Depois, a dupla se organiza para definir qual será a forma de implementar o que foi descrito na história do cartão selecionado. Se houver dúvidas de interpretação, elas consultam o cliente para saná-las. Com a implantação definida, os programadores utilizam a abordagem TDD para escrever o código e os testes, revezando-se no controle do computador. Feita a implementação, com todos os testes aprovados, o cliente é chamado para emitir um parecer sobre a funcionalidade definida. Após a aprovação do cliente, o código escrito pela dupla é integrado ao código do restante da equipe. Porém, devem ser feitos testes para confirmar se a integração do novo código não afetará o dos demais. Em outros momentos, podem ser realizadas refatorações para melhorar o design do código, para que sua manutenção seja mais fácil. Ao final de cada iteração, o cliente avalia e inspeciona o que foi feito e a equipe avalia o que deu certo e o que pode melhorar na próxima iteração. E o ciclo se reinicia. No transcorrer de um projeto, podem ocorrer mudanças durante o processo de desenvolvimento. Nesse caso, o cliente pode alterar, criar e excluir user stories. Caso isso aconteça, um novo processo de estimativa ocorre e as divisões dos grupos de user stories são refeitas para refletir as alterações realizadas na lista de requisitos. Com isso, finalizamos o nosso estudo sobre a metodologia Programação Extrema (XP). Na próxima oportunidade, estudaremos a consagrada metodologia Rational Unified Process (RUP). Retomando a aula abordamos as práticas da metodologia Extreme 1. Introdução à Programação Extrema (XP) A Programação Extrema é uma metodologia que prega o uso de várias boas práticas de desenvolvimento de software. Suas diretrizes são especificadas em cinco valores: Comunicação, Simplicidade, Coragem, Feedback e Respeito. 189 46Met. para de Desenvolvimento de Software 2. Papéis da Programação Extrema A Programação Extrema utiliza diversos papéis, como Testador, Coach, Cleaner, Desenvolvedor, Tracker, Gerente e Cliente, sendo que cada papel exerce diferentes obrigações no processo. 3. Principais Práticas do XP A metodologia XP prega o uso de diversas boas práticas de engenharia de software, como testes automatizados, integração contínua, programação em pares, cartões de história e propriedade coletiva do código. 4. O processo XP O processo XP, em poucas palavras, é baseado em iterações e releases, onde, em cada release, um software deve ser entregue funcionando com as funcionalidades acertadas. Cada release é composto por uma ou mais iterações. ANICHE, Mauricio. Test-Driven Development: Teste e Design no Mundo Real. São Paulo: Casa do Código, 2014a. SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Addison Wesley, 2014. PRESSMAN, Roger S. Engenharia de software: uma BASSI, Dairton. Programação Extrema (XP). In: Métodos Ágeis para Desenvolvimento de Software. Porto Alegre: Bookman, 2014. p. 37–57. Cap. 4 TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec Editora, 2014. WILDT, Daniel et. al. eXtreme Programming: Práticas para o dia a dia no desenvolvimento ágil de software. São Paulo: Casa do Código, s.d.. Vale a pena Vale a pena ler ANICHE, Maurício. TDD. [S.l.:] Caelum, 2014b. Disponível em: <http://tdd.caelum.com.br/>. Acesso em: 06 out. 2017. GOMES, André Faria. Programação em Par. [S.l.:] André Faria Gomes, 2008. Disponível em: <http://blog.andrefaria.com/programacao-em-par>. Acesso em: 06 out. 2017. MEDEIROS, Higor. Introdução ao Extreme Programming (XP). [S.l.:] Devmedia, 2013. Disponível em: <http://www. Vale a pena acessar devmedia.com.br/introducao-ao-extreme-programming- xp/29249>. Acesso em 06 out. 2017. FONSECA, Daniel. Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento de Software (Metodologias Clássicas x Extreme Programming) [S.l.:]. DevMedia, s.d. Disponível em: <http://www.devmedia.com.br/conceitos-basicos- sobre-metodologias-ageis-para-desenvolvimento- de-sof tware-metodolog ias-c lass icas-x-extreme- programming/10596>. Acesso em: 06 out. 2017. TELES, Vinícius Manhães. Programação em Par | XP. [S.l.:] DesenvolvimentoAgil.com.br, 2006. Disponível em: <http://www.desenvolvimentoagil.com.br/xp/praticas/ programacao_par>. Acesso em: 06 out. 2017. Minhas anotações 190
Compartilhar