Extreme Programming para mudar seu destino voc precisa

Extreme Programming

“. . . para mudar seu destino, você precisa primeiro mudar sua atitude. . . ” Kent Beck

Assuntos Metodologias Ágeis XP (Extreme Programming) Ferramentas para XP Sugestões de uso: 1) XP com ERP 2) XPM (Extreme Project Management)

Metodologias Ágeis l l l Cenário encontrado Possível solução Movimentos iniciais Manifesto Ágil Um estudo comparativo

Cenário encontrado l Metodologias pesadas: l l l Supõem que é possível prever o futuro; Pouca interação com os clientes; Ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc. ); Avaliação do progresso baseado na evolução da burocracia e não do código; Com software l l l Quantidade de erros; Falta de flexibilidade; Alto custo inicial;

Possível solução l Melhores práticas: l l l l Padrões de Projeto (reutilização de idéias); Componentes (reutilização de código); Requisitos mutáveis; Atividade que apresente baixo custo; Equipes pequenas; Datas de entrega curtas; Desenvolvimento rápido; Metodologia indicada nesse cenário: l Metodologia Ágil

Movimentos iniciais l Movimento iniciado por programadores experientes e consultores em desenvolvimento de software; l Questionam e se opõe a uma série de mitos/práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos; l Manifesto Ágil: • Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001.

Manifesto Ágil “Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a entender que: l l Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o cliente é mais importante do que negociação de contratos. Adaptação a mudanças é mais importante do que seguir o plano inicial. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. “ http: //www. agilemanifesto. org/

Metodologias Ágeis Um estudo comparativo “Metodologias ágeis têm sido apontadas como uma alternativa às abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas também como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situações em que os requisitos do sistema são estáveis e requisitos futuros são previsíveis. Entretanto, em projetos em que há muitas mudanças, em que os requisitos são passíveis de alterações, onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, não pode haver requisitos estáticos, necessitando então de metodologias ágeis. ” Michel dos Santos Soares

Metodologias Ágeis Um estudo comparativo “Processos orientados a documentação para o desenvolvimento de software são, de certa forma, fatores limitadores aos desenvolvedores e muitas organizações não possuem recursos ou inclinação para processos pesados de produção de software. Por esta razão, as organizações pequenas acabam por não usar nenhum processo. Isto pode levar a efeitos desastrosos na qualidade do produto final, além de dificultar a entrega do software nos prazos e custos predefinidos. ” Michel dos Santos Soares

XP (Extreme Programming) l l l O surgimento do XP O que é e. Xtreme Programming? Papéis no XP Valores Boas Práticas Fluxo do XP

O surgimento do XP l Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software l l Identificou o que tornava simples e o que dificultava o desenvolvimento de software Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia XP - e. Xtreme Programming

O que é e. Xtreme Programming? “Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” Kent Beck

Uma pergunta “Como você programaria se tivesse tempo suficiente? ” Kent Beck

Possíveis respostas Mais testes? l Mais projeto e arquitetura? l Menos pessoas? l Mais qualidade? l

Programando ao Extremo l Levar todas as boas práticas ao Extremo Se testar é bom, vamos testar toda hora!! l Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! l Se integrar é bom, vamos integrar a maior quantidade de vezes possível! l Se iterações curtas é bom, vamos deixar as iterações realmente curtas! l

k ac db Fe e Si m pl ic id ad e m ge Co ra Co m un ic aç ão XP inclui. . . Respeito

Co m un ic aç ão XP inclui. . .

Comunicação l l Soluções de problemas normalmente já são conhecidas. . . O problema é a solução chegar a quem precisa Comunicação face a face é a maneira mais rápida de “espalhar” conhecimento Preferir l l l Chat a e-mail Telefone a chat Conversa pessoal a telefone

Co ra ge m Co m un ic aç ão XP inclui. . .

Coragem l Indicar problemas no projeto l Parar quando está cansado !!! l Pedir ajuda quando necessário l l Simplificar código que já está funcionando Seguir o XP como ele é

Fe ed ba ck Co ra ge m Co m un ic aç ão XP inclui. . .

Feedback l Cliente participando do desenvolvimento l Oportunidades e problemas são evidenciados o mais cedo possível l Testes fornecem feedback sobre sistema

Co m un ic aç ão Co ra ge m Si m pl ic id ad e Fe ed ba ck XP inclui. . .

Simplicidade l l l Regra geral: “Pensar sempre no que pode ser feito para simplificar o que já está funcionando”; Simplicidade normalmente gera mais valor satisfatório; Fazer o mínimo necessário para funcionar; (cuidado com esse conceito!!!) É mais barato adaptar depois caso não esteja funcionando; O projeto deve ser simplificado continuamente.

k ac db Fe e Si m p lic id ad e m ge Co ra Co m un ic aç ão XP inclui. . . Respeito

Respeito Conceito psicológico introduzido pela mulher do Kent ! Coragem, Feedback , Simplicidade, Comunicação. . . l Respeito é necessário para tirar o máximo desses valores l Respeito pelo próximo l l l Feedback, Comunicação Respeito por si mesmo l Coragem, Simplicidade

Características Comuns dos Métodos Ágeis l Coloca o foco Na entrega freqüente de sub-versões do software [funcionando] para o cliente. l Nos seres humanos que desenvolvem o software. l l Retira o foco de Processos rígidos e burocratizados. l Documentações e contratos detalhados. l Ferramentas que são usadas pelos seres humanos. l

Papéis no XP Big Boss / Xp. Manager Deve fazer: • Agendar reuniões; • Escrever atas ; • Manter o XP Tracker informado dos acontecimentos das reuniões Não deve fazer: • Deixar que problemas externos interfiram no desenvolvimento • Dizer quando as coisas devem acontecer • Dizer às pessoas o que fazer • Cobrar das pessoas

Papéis no XP Cliente Xp Gold Owner (O proprietário do ouro) ouro É quem paga pelo sistema, geralmente o dono da empresa. Xp Goal Donor Deve fazer: • Escrever User Stories • Definir prioridades • Definir testes de aceitação • Validar testes de aceitação • Esclarecer dúvidas Não deve fazer: • Implementar código • Definir quanto tempo uma tarefa leva para ser feita

Papéis no XP Xp Coach Coordenador Xp Tracker Responsável pela negociação com o cliente quanto ao escopo e pela coordenação do Planning Game. Deve fazer: • Coletar métricas • Manter todos informados do que está acontecendo • Definir testes de aceitação • Tomar atitudes diante de problemas • Sugerir sessões de CRC (Class, Responsabilities , Collaboration)

Papéis no XP Programador (Driver/Partner) Deve fazer: • Estimar prazos de User Stories • Implementar código de produção • Trabalhar em par • Fazer refactoring • Corrigir bugs Não deve fazer: • Criar/Alterar novas funcionalidades • Escrever testes de aceitação

Papéis no XP Alguns papéis podem ser combinados numa só pessoa Xp Manager + Xp Tracker Alguns papéis não podem ser combinados numa só pessoa Xp Programmer + Xp Tracker Xp Customer+ Xp Programmer Xp Coach + Xp Tracker

Boas Práticas l Test First Design l Refactoring l Stand-up Meeting l Continuous Integration A criação de testes leva em conta não o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema. A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos. Reuniões rápidas e diárias com a equipe Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.

Boas Práticas l Pair Programming l Move People Around l l Collective Code Ownership Coding Standards Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. As duplas de programação são revezadas em média a cada 2 h. E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo. Todo código é desenvolvido seguindo um padrão.

Boas Práticas l l l The Customer is Always Available O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades. Small Release O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos. Simple Design O código está, a qualquer momento, na forma mais simples que passe todos os testes.

Boas Práticas l l l 40 -Hour Week On-Site Customer Acceptance Tests Cada programador trabalha 40 horas por semana. Se o horário for flexível, deve -se respeitar o horário do par naquele período, senão enquanto um trabalha o outro vai pra casa. Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas São definidos pelo usuário e são os critérios de aceitação do software.

Boas Práticas l System Metaphor Ajuda a manter todos os desenvolvedores em sintonia com o projeto quando dando nomes a objetos ou classes. A Fábrica A idéia é que exista um objeto "produto" que sofre várias modificações ao longo da "linha de montagem", onde outros objetos trabalham sobre o produto. A vantagem é que é simples adicionar "máquinas novas" a linha de montagem. O Correio Quando o "produto" precisa passar pela mão de várias pessoas, às vezes para conhecimento, aprovação ou modificação do conteúdo. Podem existir modificações feitas pelo sistema, nesse caso, existem "destinatários virtuais" que recebem a mensagem, analisam e despacham para quem deve. A diferença básica do Correio para a Fábrica é que ele não segue uma linha. Turista O objeto é um "turista", o Servlet e o Banco são hospedagens, os dados são a bagagem, o objeto que tira os dados do "turista" e coloca ou no Servlet (em XML) ou no Banco são "carregadores de bagagem". Quando a "bagagem" está guardada no hotel "Banco de Dados" o "turista" recebe um ticket da bagagem para poder pegar ela depois (o Identificador único da tabela).

Chegou a hora. . . Como funciona o fluxo de utilização do XP ?

1º Passo: Escopo !!! 1. 2. 3. 4. 5. 6. 7. 8. Defina os elementos que se relacionam com o sistema. (atores) Defina os mecanismos de controle do sistema (procedimentos, indicadores, objetivos) Defina os mecanismos de execução do sistema (recursos) Defina um fluxo de informações de alto valor agregado (processo) Elabore um diagrama inter-relacionando todos os elementos Identifique o numero de partes do sistema (módulos) Identifique a funcionalidade de cada parte do sistema (User Stories) Estime o prazo do projeto (utilize a equipe. . . É mais fácil)

Escopo !!!

Fluxo de XP (site oficial)

User Stories X Use Case l l Um Use Case define um conjunto de cenários que descreve o comportamento do sistema em termos de seqüências de ações gerando o mapa para a realização de um requisito ou necessidade do cliente. As User Stories são usadas para criar estimativas de tempo para a reunião de Release Planning. Elas também são usadas no lugar de um documento enorme descrevendo os requisitos. (e são enviadas ao Acceptance Test)

User Stories X Use Case l As User Stories são escritas como coisas que o sistema precisa fazer para eles. Elas são similares aos cenários de uso, exceto que elas não estão limitadas a descrever uma interface com o usuário. l O formato delas é de cerca de três sentenças de texto escrito pelo cliente, na terminologia do cliente, sem uma sintaxe específica. (senão, crie o texto em entrevista e o valide junto ao cliente!!!) l As User Stories também conduzem a criação dos Acceptance Test. Um ou mais testes de aceitação automatizados devem ser criados para verificar se as User Stories foram corretamente implementadas.

Fluxo de XP (site oficial)

Planejar ar iterações l l l Divida o projeto em etapas de 1 ou 2 semanas; Considere prazos fixos e escolha um dia da semana para integrações e entregas; (segunda ou sexta-feira); Planeje reuniões diárias para acompanhar a evolução do projeto (“stand-up”, meeting matinal); As iterações serão a unidade de referencia para utilizar as métricas; Entre no jogo para entregar umou produto a cada iteração.

Velocidade e Fator de Carga l l l Velocidade é o numero de Story Points que a equipe faz por iteração; Story Point é um esforço equivalente a 1 dia de trabalho ideal (Sunny Day) de 1 desenvolvedor (dois a três dias de 8 horas); User Stories não devem ter mais do que 3 Story Points; Fator de carga é a relação entre o numero de horas ideais e o numero de horas disponíveis na iteração; geralmente calculado pelo numero de story points estimado pelo numero de story points realizados na iteração anterior; Ex: 14 SP / 9 SP = 1. 55 SP; Sempre que um desenvolvedor estimar o esforço de uma Story Point, multiplique pelo fator de carga.

Métricas: Mensurabilidade da Velocidade do Projeto l l l Se o fator de carga variar muito durante um ciclo de iteração para finalização de uma versão do software, uma nova reunião de planejamento de entrega do produto é realizada com a finalidade de reavaliar o cronograma e o escopo comprometidos na versão. Uma desvantagem do fator de carga é que devido às características do processo de implementação, ele não pode ser usado como base histórica para estimativas. Outro fator indicativo da velocidade que deve ser considerado durante a fase de implementação é a quantidade de user stories implementadas até o momento na iteração. Este fator simples pode ser utilizado para estimar quantas user stories serão implementadas em um dado prazo.

Fluxo de XP (site oficial) posse coletiva do código

Testes, testes e mais testes. . . Em XP, quando um programador recebe uma tarefa, para concluí-la deve seguir os seguintes passos: l l l Escrever primeiro um teste. Depois o código de produção. E por fim, verificar se o teste deu positivo. Com isso os testes Unitários lhe dão uma melhor visão do problema, fazendo que você consiga o máximo de velocidade no desenvolvimento por está evitando códigos desnecessários. Quando testar ? l Antes de fazer um refactoring – isso garante que o sistema funcione dentro do l esperado e permite a confiança de ir adiante. Após o refactoring – isso garante que o trabalho que você fez não mudou o comportamento do sistema.

Testes, testes e mais testes. . . O teste de aceitação é composto por três partes: l l l Cenário: o número mínimo de coisas que devemos fazer antes que possamos executar o teste. Operação: o teste em si. Verificação: a pós-condição, aquilo que é verdadeiro após o teste estar concluído.

Fluxo de XP (site oficial)

Resumindo…

Ferramentas para XP XPlanner l dot. Project l Microsoft Visual C#. Net l Target Process l

x. Planner

Visão Da Iteração

XPlanner Métricas Da Iteração

Estatísticas Da Iteração

dot. Project

dot. Project

dot. Project

dot. Project

dot. Project

Microsoft Visual C#. Net

dot. Project

dot. Project

dot. Project

Target Process http: //fulldemo. targetprocess. com/default. aspx

dot. Project

dot. Project

dot. Project

dot. Project

Sugestões de uso XPM (Extreme Project Management) XP com ERP (Entreprise Resource Planning)

Sugestões de uso XPM (Extreme Project Management)

XPM (Extreme Project management) APM – Agile Project Management l Princípios: Baseado em Sistemas Adaptativos Complexos como revoadas, cardumes, enxames onde o comportamento é coletivo, ou seja, encontramos: ordem, auto-organização, inteligência coletiva e adaptação a ambientes dinâmicos; l Organizações: sistemas adaptáveis, com seres inteligentes; l Confiança na habilidade coletiva para resolver problemas; l Imprevisibilidade limita o planejamento: enfatizar a adaptabilidade; l Gerente de projeto: líder adaptável que promove o trabalho colaborativo em equipe, defende o projeto e remove obstáculos para sua progressão.

Comparativo de Gerenciamento Tradicional X Ágil l l l l Abordagem Tradicional Preditivo: detalhar o que ainda não é bem conhecido Rígido: seguir especificação predefinida, a qualquer custo Burocrático: controlar sempre, para alcançar objetivo planejado Orientado a processos: segui-los possibilita garantir a qualidade Documentação gera confiança Sucesso = entregar o planejado Gerência = “comando-e-controle” voltado para trabalho em massa, ênfase: papel do gerente, com planejamento e disciplina fortes Abordagem Ágil Adaptativo: conhecer o problema e resolver o crítico primeiro Flexível: adaptar-se a requisitos atuais, que podem mudar Simplista: fazer algo simples de imediato e alterar, se necessário Orientado a pessoas: motivadas, comprometidas e produtivas Comunicação gera confiança Sucesso = entregar o desejado Gerência = liderança / orientação trabalhadores do conhecimento, ênfase: criatividade, flexibilidade, atenção às pessoas

Sugestões de uso XP com ERP (Enterprise Resource Planning)

Cenário encontrado em implantação de software ERP l l l l Ainda precisamos definir padrões claros para a documentação e para o Projeto (reutilização de idéias inexistente); Utilizar componentes que já foram implementados em outros módulos (reutilização de código); Novos requisitos ainda estão sendo definidos através das customizações nos módulos existentes; Custo de desenvolvimento precisa compensar o custo da consultoria; Customizações geralmente utilizam pequenas equipes; A data de entrega é sempre curta; Existe a necessidade de desenvolvimento rápido para alocar o profissional em outras customizações;

Solução para este cenário ?

Referências l l l l www. xispe. com. br www. google. com. br www. extremeprogramming. org www. xprogramming. com www. agilealliance. org www. cin. ufpe. br/~xprecife fulldemo. targetprocess. com/default. aspx Extreme Programming Explained Second Edition, Kent Beck - 2004

Dúvidas ? ? ? ricardo. afonso@nutes. ufpe. br