Qualidade, Processos e Gestão de Software

Apresentação em tema: "Qualidade, Processos e Gestão de Software"— Transcrição da apresentação:

1

2 Qualidade, Processos e Gestão de Software
XP eXtreme Programming Rebeka Brito 06/10/2008

3 Agenda Metodologia Ágil XP – eXtreme Programming
Quando o XP não deve ser utilizado Conclusões Referência Bibliográfica 3

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

5 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

6 Agenda Metodologia Ágil XP - eXtreme Programming
Quando o XP não deve ser utilizado Conclusões Referência Bibliográfica 6

7 XP - eXtreme 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

8 XP - eXtreme 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

9 XP - eXtreme Programming
Desenvolvimento de sistema orientados a objetos. 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

10 XP – eXtreme 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

11 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

12 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. 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

13 XP – Valores e Princípios
Comunicação: A comunicação é um dos valores crucial para manter aberta a interação com o cliente. 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. 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

14 XP – Valores e Princípios
O XP utiliza esse tipo de comunicação para evitar problemas na interpretação, diminuir as falhas na comunicação e evitar o re-trabalho. 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

15 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

16 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. 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

17 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. Coragem para desenvolver o software de forma incremental; Manter o sistema simples; Permitir que o cliente priorize as funcionalidades; Fazer os desenvolvedores trabalharem em par; Investir tempo em refactoring; Investir tempo em testes automatizados;

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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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. Os desenvolvedores escrevem testes para cada funcionalidade antes de codificá-las. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. 30

31 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

32 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

33 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

34 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

35 XP - Equipe É o responsável técnico do projeto
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

36 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

37 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

38 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

39 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

40 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

41 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

42 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

43 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

44 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

45 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

46 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

47 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

48 XP – Documentação Modelo de Dados Processo de Negócios
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

49 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

50 XP – Documentação Acompanhamento Diário Acompanhamento do Projeto
É um documento gerencial que pode ser adotado pelo gerente para acompanhar as pendências do projeto e cobre dos responsáveis o cumprimento dos compromissos. 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

51 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

52 Agenda Metodologia Ágil XP – eXtreme Programming
Quando o XP não deve ser utilizado Conclusões Referência Bibliográfica 52

53 Quando o XP não deve ser utilizado
Existe um consenso na Comunidade de Desenvolvimento Ágil de que 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

54 Quando o XP não deve ser utilizado
Algumas questões culturais: Sistema de premiação 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. 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 Tendem a dificultar as mudanças impondo uma barreira que prejudica tanto a equipe de desenvolvimento quanto o cliente. 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

55 Quando o XP não deve ser utilizado
Clientes que fazem questão de um grande número de artefatos Alguns clientes exigem a produção de uma grande quantidade de documentos e artefatos ao longo do desenvolvimento. 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. O processo necessita de agilidade, leveza e flexibilidade. 55

56 Quando o XP não deve ser utilizado
Escritório O XP é extremamente dependente do ambiente de trabalho. É 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. 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 É um processo de desenvolvimento que muda fortemente a maneira como as pessoas estão habitadas a desenvolver software. As mudanças e efeitos não devem ser subestimados. A equipe precisa ser “preparada” para a mudança. 56

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

58 Agenda Metodologia Ágil XP – eXtreme Programming
Quando o XP não deve ser usado Conclusões Referência Bibliográfica 58

59 Conclusões O XP é um processo de desenvolvimento flexível que se adapta facilmente às mudanças nos projetos de desenvolvimento; 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

60 Agenda Metodologia Ágil XP – eXtreme Programming Conclusões
Referência Bibliográfica 60

61 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

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

63