1 Qualidade Processos e Gesto de Software XP

1

Qualidade, Processos e Gestão de Software XP e. Xtreme Programming Rebeka Brito (rsb 2@cin. ufpe. br) 06/10/2008 2

Agenda 1. Metodologia Ágil 2. XP – e. Xtreme Programming 3. Quando o XP não deve ser utilizado 4. Conclusões 5. Referência Bibliográfica 3

Metodologia Ágil ü Desenvolvimento ágil de software Software Development) ou Método ágil. (Agile ü É um conjunto de metodologias desenvolvimento de software. de ü O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software. 4

Metodologia Ágil Processos Ágeis de Desenvolvimento ü Compartilham a premissa de que o cliente aprende sobre as suas necessidades, na medida em que é capaz de manipular o sistema que está sendo produzido. ü Com base no feedback do sistema, ele reavalia as suas necessidades e prioridades, gerando mudanças que deverão ser incorporadas ao software. ü O cliente direciona o desenvolvimento de modo que a equipe produza sempre aquilo que tem o maior valor para o seu negócio. 5

Agenda 1. Metodologia Ágil 2. XP - e. Xtreme Programming 3. Quando o XP não deve ser utilizado 4. Conclusões 5. Referência Bibliográfica 6

XP - e. Xtreme Programming ü É um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. 7

XP - e. Xtreme Programming O XP é voltado para: ü Projetos cujos requisitos são vagos e estão em constante mudança. ü Equipes pequenas e médias (preferencialmente até 12 desenvolvedores). ü Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. 8

XP - e. Xtreme Programming ü Desenvolvimento objetos. de sistema orientados a ü Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai adquirindo novas funcionalidades ao longo do tempo. 9

XP – e. Xtreme Programming ü Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. ü Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. ü Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas. 10

XP – Valores e Princípios ü O XP é organizado em torno de um conjunto de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software. 11

XP – Valores e Princípios ü Os quatro valores fundamentais da metodologia XP são: Ø Feedback: Quando o cliente aprende com o sistema que utiliza e reavalia as suas necessidades, ele gera um feedback para a equipe de desenvolvimento, realimentando a equipe com novas necessidades ou alterações. v O cliente atua como Produtor e Consumidor, ou seja, ele produz uma nova idéia e rapidamente apresenta à equipe de desenvolvimento, que por sua vez, a consome, produz alterações no sistema e as apresenta (Forma-se, então, um ciclo repetido várias vezes devido a redução do tempo de feedback com o cliente). 12

XP – Valores e Princípios Ø Comunicação: A comunicação é um dos valores crucial para manter aberta a interação com o cliente. v A forma como nos comunicamos influência entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com atenção e agilidade. v A comunicação face a face é a mais eficaz, pois permite que o interlocutor possa interpretá-la levando em consideração a expressão facial, o tom de voz, os gestos, estimulando vários sentidos. É dinâmica e viabiliza questionamentos e respostas. 13

XP – Valores e Princípios v O XP utiliza esse tipo de comunicação para evitar problemas na interpretação, diminuir as falhas na comunicação e evitar o retrabalho. v Os documentos continuam sendo usados, porém exercem um papel diferente: são usados para registrar o trabalho que já foi executado e não, o que deverá ser realizado, pois essa informação é transmitida pessoalmente. 14

XP – Valores e Princípios ATENÇÃO! A falta de comunicação é uma inimiga grande de qualquer negócio principalmente no negócio onde o entendimento é crucial para o êxito do projeto. Muita informação técnica é envolvida no simples ato de “criar um projeto”. Aparentemente é simples, mas requer muita técnica e conhecimento para fazê-lo da forma que fique ideal tanto para o desenvolvedor quanto para o cliente. 15

XP – Valores e Princípios ü Simplicidade: Quando um cliente solicita uma funcionalidade, esse valor sugere que essa funcionalidade seja desenvolvida da forma mais simples possível, para que o cliente tenha seu pedido atendido e possa validá-lo. v. A equipe se preocupará com as atividades do presente e não especularão algo que poderia vir a ser necessário no futuro. A equipe é focada no “HOJE” e evita o re-trabalho, implementando algo genérico. 16

XP – Valores e Princípios ü Coragem: A equipe precisa ser corajosa para mudar, incrementar uma nova funcionalidade, não deixando que os riscos a impeçam de mudar. v Coragem para desenvolver o software de forma incremental; v Manter o sistema simples; v Permitir que o cliente priorize as funcionalidades; v Fazer os desenvolvedores trabalharem em par; v Investir tempo em refactoring; v Investir tempo em testes automatizados;

XP – Valores e Princípios v Estimar as estórias na presença do cliente; v Expor o código a todos os membros da equipe; v Integrar o sistema diversas vezes do dia; v Integrar o sistema diversas vezes ao dia; v Adotar um ritmo sustentável; v Abrir mão de documentações que servem como defesa; v Propor contratos de escopo variável; v Propor a adoção de um processo novo.

XP – Valores e Princípios ü A partir destes valores, possui como princípios básicos: Ø feedback rápido, assumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade. 19

XP – Práticas ü Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. ü Há uma confiança muito grande na harmonia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras. 20

XP – Práticas ü Jogo de Planejamento (Planning Game): Ø O desenvolvimento é feito em iterações semanais. Ø No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Ø Essa reunião recebe o nome de Jogo do Planejamento, onde o cliente identifica prioridades e os desenvolvedores as estimam. Ø O cliente é essencial neste processo pois assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. 21

XP – Práticas Ø Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ø Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção. 22

XP – Práticas ü Pequenas Versões (Small Releases): Ø A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente. Ø O cliente já pode testar uma parte do sistema que está comprando. Ø As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. 23

XP – Práticas ü Metáfora (Metaphor): Ø Procura facilitar a comunicação com o cliente, entendendo a realidade dele. Ø É uma linguagem comum estabelecida entre a equipe de desenvolvimento e o cliente, já que ela tem o poder de transmitir idéias complexas de forma simples. Ø É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto. 24

XP – Práticas ü Projeto Simples (Simple Design): Ø Simplicidade é um princípio da XP. Ø A equipe precisa ser ágil no desenvolvimento. Ø Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. (atendendo por vez, a cada solicitação do cliente) 25

XP – Práticas ü Time Coeso (Whole Team): Ø A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento. ü Testes de Aceitação (Customer Tests): Ø São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema. ü Ritmo Sustentável (Sustainable Pace): Ø Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. 26

XP – Práticas ü Reuniões em Pé (Stand-up Meeting): Ø Reuniões em pé para que o foco nos assuntos não seja perdido, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe. üPosse Coletiva (Collective Ownership): Ø O código-fonte não possui dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema. 27

XP – Práticas Ø O programador que está digitando é chamado de driver e o outro é o partner. O partner deve estar engajado, ajudando a todo minuto. Ø Dessa forma, o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs). ØBusca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado. 28

XP – Práticas ü Padrões de Codificação (Coding Standards): Ø A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Ø Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possua 10 ou 100 membros. Ø Busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado. 29

XP – Práticas ü Desenvolvimento Orientado a Testes (Test Driven Development): Ø Primeiro, cria-se os testes unitários (unit tests) e depois, o código para que os testes funcionem. Esses testes são essenciais para que a qualidade do projeto seja mantida. v Os desenvolvedores escrevem funcionalidade antes de codificá-las. testes para cada Ø Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. 30

XP – Práticas ü Refatoração (Refactoring): Ø É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Ø Refatorar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte; 31

XP – Práticas ü Integração Contínua (Continuous Integration): Ø Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Ø Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Ø Integrar de forma contínua permite saber o status real da programação. 32

XP - Equipe ü Uma equipe que utiliza o XP normalmente é composta por pessoas que representam os seguintes papéis: Ø Ø Ø Gerente de Projeto; Coach; Analista de Testes; Redator Técnico; Desenvolvedor. 33

XP - Equipe ü Gerente de Projeto Ø É responsável pelos assuntos administrativos do projeto. Ø Libera a equipe de questões que não estejam diretamente ligadas à atividade diária de desenvolvimento. Ø Administra o relacionamento com o cliente, assegurando que o mesmo participe ativamente do desenvolvimento e forneça informações essenciais para que a equipe possa implementar o sistema desejado. 34

XP - Equipe ü Coach Ø É o responsável técnico do projeto Ø O XP recomenda que um profissional tecnicamente preparado seja destacado para orientar a equipe de modo que ele siga as boas práticas recomendadas pelo XP. Ø Pode atuar na implementação do sistema. Ø A principal tarefa é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente. 35

XP - Equipe ü Analista de Testes Ø É responsável por ajudar o cliente a escrever os testes de aceitação. Ø Deve fazer com que os testes sejam executados diversas vezes ao longo das iterações do projeto quando os testes não são automatizados. Ø Faz com que eventuais defeitos do sistema sejam identificados logo, fornecendo feedback para a equipe rapidamente, de modo que ela possa fazer as correções com rapidez para evitar que os problemas se propaguem. 36

XP - Equipe ü Redator Técnico Ø Ajuda a equipe de desenvolvimento a documentar o sistema. Ø A sua presença permite que os desenvolvedores se concentrem prioritariamente na implementação do software. Ø Embora eles possam continuar fazendo algumas documentações, o redator técnico é quem faz maior parte do trabalho de documentação. 37

XP - Equipe ü Desenvolvedor Ø É a pessoa que analisa, projeta e codifica o sistema. Ø É a pessoa que constrói o software. Ø Dentro do XP, não existem divisões entre analistas, projetistas, programador etc. Cada desenvolvedor exerce estes diferentes papéis em diversos momentos do projeto. 38

XP – Documentação ü Muitas pessoas acreditam que não exista documentação nos projetos que utilizam o XP pelo fato do XP não ter como objetivo principal do projeto documentar. ü O tempo que se gasta documentando, o XP defende que é um tempo que poderia estar sendo usado para codificar. ü A equipe deve esta atenta para não cometer excesso nem omissões. Precisa documentar apenas o suficiente para que outros desenvolvedores, no futuro, possam dar manutenção no código. 39

XP – Documentação ü As práticas do XP como refactoring, código coletivo e programação em par, que fazem o código gerado ser mais simples e mais limpo que o normal, levam uma menor necessidade de documentação. ü Mas isso não elimina a necessidade de documentar, apenas reduz o esforço, sugerindo que a documentação seja adequada, simples e suficiente e que seja produzida de forma eficaz. 40

XP – Documentação ü A princípio não existe um conjunto de documentos que atendam às necessidades de todos os projetos, pois cada projeto possui características diferentes e pode precisar de mais ou menos documentos. 41

XP – Documentação ü A seguir, um conjunto reduzido de documentos que podem ser criados com o uso do XP: Ø Estória Ø Testes de Aceitação Ø Testes de Unidade Ø Javadoc Ø Modelo de Classes Ø Modelo de Dados Ø Processos de Negócios Ø Manual do Usuário Ø Acompanhamento Diário Ø Acompanhamento do Projeto Ø Fotos 42

XP – Documentação ü Estória Ø Toda funcionalidade começa com uma estória. Ela é escrita pelo cliente em um cartão e a equipe escreve a estimativa da estória indicando a quantidade de pontos que acredita ser necessária para implementá-la. Ø Serve como um lembrete da necessidade da equipe dialogar com o cliente no momento de desenvolver a funcionalidade. Ø A lista de estórias servem de roteiro para as funcionalidades que compõe o sistema. 43

XP – Documentação ü Testes de Aceitação Ø Toda estória é associada a um conjunto de testes de aceitação. Ø Definem respostas que a funcionalidade deve fornecer de acordo com cada utilização por parte do usuário. Ø Se materializam na forma de roteiros que indicam os resultados esperados bem como os resultados que não pode ser fornecidos pelo sistema (bugs). 44

XP – Documentação ü Testes de Unidade Ø Atende aos objetivos de documentar e validar o funcionamento do sistema. Ø É o teste em uma ou mais classes de cada funcionalidade do sistema. Ø Além de testar cada classe para assegurar que o funcionamento das mesmas esteja dentro do esperado, também serve como uma documentação que informa ao seu leitor qual o funcionamento esperado para os métodos das classes. 45

XP – Documentação ü Javadoc Ø É utilizado para gerar automaticamente uma documentação das classes que compõe o sistema. Ø Outras linguagens, tais como C++, por exemplo, também contam com ferramentas para geração de documentação automática. 46

XP – Documentação ü Modelo de Classes Ø Pode ser feito de forma manual ou automática. Ø Pode automatizar o processo com o uso de ferramentas que fazem a engenharia reversa no código. Ø Se não puder automatizar, opte por uma documentação mais leve, modelando apenas as classes e seus relacionamentos, sem atributos e métodos na ferramenta que estiver a sua disposição. Ø Os desenvolvedores podem buscar informações dos atributos e métodos no javadoc ou no código. 47

XP – Documentação ü Modelo de Dados Ø Faz a engenharia reversa das tabelas que compõe o banco de dados. Ø Quando cliente exigir que o modelo seja alterado antes das alterações no banco sejam efetuadas, faz-se a engenharia reversa do que já foi feito e atualiza aquele documento com o que é novo. ü Processo de Negócios Ø Descreve os processos de negócios que são implementados pelo sistema. ØRepresenta uma visão conceitual destes processos que tem por objetivo orientar as áreas de negócios da empresa que irá utilizar o sistema. 48

XP – Documentação ü Manual do Usuário Ø É uma extensão dos processos de negócios. Ø Mostra como os processos de negócios foram mapeados para dentro do sistema indicando todos os passos que o usuário deve seguir para efetuar as operações no software. Ø Descreve os processos de negócios através de telas do sistema e das ações que o usuário deve fazer em cada uma delas. 49

XP – Documentação ü Acompanhamento Diário Ø É um documento gerencial que pode ser adotado pelo gerente para acompanhar as pendências do projeto responsáveis o cumprimento dos compromissos. e cobre dos ü Acompanhamento do Projeto Ø Também é um documento gerencial, atualizado semanalmente e serve para reportar ao cliente a situação do projeto a cada semana. Ø Indica as estórias que fazem parte da iteração corrente, as que foram concluídas, os problemas que foram encontrados, o motivos de eventuais atrasos, os riscos, entre outros. Ø É utilizado para que os gestores possam monitorar e rever as prioridades do projeto. 50

XP – Documentação ü Fotos Ø São fotos digitais tiradas dos quadros que a equipe de desenvolvimento usa para diversas atividades. Ex: Todo processo de modelagem. Ø As fotos dos quadros são tiradas porque o que foi documentado neles nas discussões pode ser perdido, pois é preciso apagar para dar lugar a novos itens de novas discussões. 51

Agenda 1. Metodologia Ágil 2. XP – e. Xtreme Programming 3. Quando o XP não deve ser utilizado 4. Conclusões 5. Referência Bibliográfica 52

Quando o XP não deve ser utilizado ü Existe um consenso na Comunidade de Desenvolvimento Ágil de questões culturais impedem a adoção do XP. ü Tecnicamente, o XP está preparado para atender a grande maioria dos projetos de software, desde que seja respeitado o tamanho máximo de 12 desenvolvedores na equipe 53

Quando o XP não deve ser utilizado ü Algumas questões culturais: Ø Sistema de premiação v Baseia-se fortemente no trabalho da equipe. No XP é difícil identificar desempenhos individuais isoladamente, pois tudo é organizado para que o trabalho da equipe tenha destaque. v O XP baseia-se em cooperação e não existe espaço para competição, desta forma, não utiliza premiações baseadas no desempenho individual. ØContrato de escopo fechado v Tendem a dificultar as mudanças impondo uma barreira que prejudica tanto a equipe de desenvolvimento quanto o cliente. v Muitos projetos XP são regidos por contratos de escopo fechado, embora o ideal seja a utilização de contratos de escopo variável. Ø 54

Quando o XP não deve ser utilizado Ø Clientes que fazem questão de um grande número de artefatos v Alguns clientes exigem a produção de uma grande quantidade de documentos e artefatos ao longo do desenvolvimento. v Se tal exigência não for flexibilizada, isso pode inviabilizar o uso do XP, não sendo possível obter os benefícios do XP. v O processo necessita de agilidade, leveza e flexibilidade. 55

Quando o XP não deve ser utilizado Ø Escritório v O XP é extremamente dependente do ambiente de trabalho. v É fundamental que as pessoas da equipe possam trabalhar próximas umas das outras, possuam quadros para disponibilizar as discussões, mesas que permitam que os desenvolvedores pratiquem a programação em par. v Muitos projetos XP são regidos por contratos de escopo fechado, embora o ideal seja a utilização de contratos de escopo variável. Ø Mudanças v É um processo de desenvolvimento que muda fortemente a maneira como as pessoas estão habitadas a desenvolver software. v As mudanças e efeitos não devem ser subestimados. A equipe precisa ser “preparada” para a mudança. 56

Quando o XP não deve ser utilizado Ø Apoio v Existe apoio para a adoção do XP no projeto ou na organização? v Se não existir apoio interno, dificilmente a adoção será bem sucedida. Ø Avaliação da cultura organizacional v Deve ser realizada antes da adoção do XP. v Tão importante quanto saber usá-lo é saber quando não utilizá-lo. 57

Agenda 1. Metodologia Ágil 2. XP – e. Xtreme Programming 3. Quando o XP não deve ser usado 4. Conclusões 5. Referência Bibliográfica 58

Conclusões ü O XP é um processo de desenvolvimento flexível que se adapta facilmente desenvolvimento; às mudanças nos projetos de ü As mudanças devem ser gradativas de modo que não cause um grande impacto na equipe/organização; ü O acompanhamento em um projeto é realizado em curtos intervalos de tempo; ü Reuniões curtas ocorrem diariamente; 59

Agenda 1. Metodologia Ágil 2. XP – e. Xtreme Programming 3. Conclusões 4. Referência Bibliográfica 60

Referência Bibliográfica § Livro: Extreme Programming : Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. Autor: Vinícius Manhães Teles -Novatec Editora 61

Obrigada! Qualidade, Processos e Gestão de Software XP e. Xtreme Programming Rebeka Brito 06/10/2008 62

63