Post on 18-Dec-2014
description
ConhecendoConhecendo o o
Bate-papo com o Especialista
ConhecendoConhecendo o o
eeXXtremetreme PProgrammingrogramming
BacklogQuem sou eu?
Guilherme Lacerdaguilhermeslacerda@gmail.com
� Mestre em Ciência da Computação, área de Engenharia de Software (UFRGS)
� Professor de Graduação (FACENSA e UniRitter) e Pós-Graduação (UniRitter)� Professor de Graduação (FACENSA e UniRitter) e Pós-Graduação (UniRitter)
� Consultor de TI, com mais de 15 anos na área de desenvolvimento deSoftware e 10 anos de experiência em modelagem e desenvolvimento OO
� Instrutor/Consultor de Metodologias Ágeis da TargetTrust
� Pioneiro em Metodologias Ágeis no Brasil (Lean, SCRUM e XP)
� Fundador do XP-RS (Grupo de Usuários de Metodologias Ágeis do RS) e Vice-Coordenador do GUMA (Grupo de Usuários de Metodologias Ágeis) vinculado aSUCESU-RS
� Editor do Portal InfoQ Brasil
BacklogQuem faz programa?
Por que 80% a 90% dos projetos de SW fracassam?
Fonte: Standish Group
Principais Problemas
� Sistemas entregues com atrasos e/ou orçamento estourado
�� Não atendem os requisitos de negócio
� Clientes descontentes (sem confiança nos desenvolvedores)
� Clientes não têm compreensão clara do que é desenvolvido
� Clientes não dão suporte correto para o desenvolvimento
� Clientes não estão interessados em participar de processoscomplexos
Principais Problemas
� Desenvolvedores trabalham muitas horas!
� Desenvolvedores relaxam na disciplina
� Desenvolvedores perdem o foco
� Processos prescritivos são atrativos para a gerência mas não paraos desenvolvedores� Baseados no paradigma do comando e controle
� Tenta minimizar o papel do cliente
� Foco em tecnologia e não no negócio
Como resolvê-los?
Como resolvê-los?
O que é ser Ágil?
� Características importantes:� Foco nas necessidades do cliente (resultado!)
� Ágil é ser rápido, ligeiro (dicionário)� Eficaz: produz o resultado esperado� Eficiente: produz o resultado esperado, mas com qualidade
� Foco nas necessidades do cliente (resultado!)� Liderança� Envolvimento das pessoas� Melhoria Contínua� Tomada de decisões baseada em análise de dados e informações(controle!)
Direitos do Cliente (Ron Jeffries)
� Planejamento Geral, definindo o que pode ser realizado, quando e aque custo
� Ver e acompanhar o andamento do projeto e, principalmente, oprogresso do SW, passando por testes definidos em conjunto com aequipe
� Mudar de idéia, substituir funcionalidades, sem pagar custosexorbitantes
� Ser informado de mudanças no cronograma, em tempo de escolher ereduzir o escopo
� Poder cancelar o projeto a qualquer momento e ainda assim ter umsistema funcionando, refletindo o investimento realizado até omomento
Direitos do Desenvolvedor (Ron Jeffries)
� Saber o que é necessário, com declarações claras deprioridade
� Produzir trabalho de qualidade o tempo todo
� Pedir e receber ajuda da equipe, superiores e clientes
� Fazer e atualizar suas próprias estimativas
� Aceitar as suas responsabilidades, ao invés de tê-las impostas
Processos de Software
� Processos Tradicionais� Analisar, projetar e só depois iniciar codificação
� Prever o futuro� Ter certeza do que se sabe hoje será exatamente o que se quer amanhã
� Temores� Mudança de requisitos depois de concluída a fase de análise e projeto
Manifesto Ágil“Estamos evidenciando maneiras melhores de desenvolversoftware fazendo-o nós mesmos e ajudando outros a fazê-lo.Através desse trabalho, passamos a valorizar:
� Interação entre pessoas MAIS QUE processos e ferramentas;
� Software em funcionamento MAIS QUE documentação abrangente;
� Responder a mudanças MAIS QUE seguir um plano.
� Colaboração com o cliente MAIS QUE negociação de contratos;
� Responder a mudanças MAIS QUE seguir um plano.
Ou seja, mesmo tendo valor os itens à direita, valorizamosmais os itens à esquerda.”
Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, WardCunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum,Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick,Ken Schwaber, Jeff Shuterland, Dave Thomas
Utah – Fevereiro de 2001
Waterfall X Ágil
Cone da Incerteza
Riscos
� Riscos de Planejamento� Será que conseguiremosterminar até outubro?
� Riscos de Custo� Riscos de Custo� Será que conseguiremos comprar o servidor pelo preço definidoanteriormente?
� Riscos de Requisitos� Será que temos todas as informações para começar o trabalho?
Risco X ValorAlto RiscoAlto Valor
Baixo RiscoAlto Valor
Alto RiscoBaixo Valor
Baixo RiscoBaixo Valor
Risco
ValorValor
Fazer Primeiro
Fazer depois
Evitar
Fazer por último
Risco
Valor
Waterfall, Iterativo
eXtreme Programming
eXtremeeXtreme ProgrammingProgramming
XP
� Criado por Kent Beck, Ron Jeffries e Ward Cunningham
� Principal tarefa é a codificação
� Disciplina de desenvolvimento de SW, voltada para equipespequenas e médias, com requisitos vagos ou que mudamfreqüentemente
XP
Valores do XP
� Comunicação� Práticas valorizam a comunicação, não limitada a procedimentosformais
� Simplicidade� Simplicidade� Incentiva ao extremo práticas que reduzam a complexidade
� Feedback� Práticas garantem um rápido feedback sobre várias partes doprojeto
� Coragem� Práticas aumentam a confiança dos desenvolvedores e do própriocliente
Comunicação
Comunicação
Comunicação
Variáveis de um Projeto
Processos Tradicionais � Tempo� Escopo� Custo
Manipula-se aQualidade
eXtreme Programming� Tempo� Qualidade� Custo
Manipula-se aEscopo
XP – eXtreme Programming
Práticas organizacionais
Práticas de equipe
Práticas de pares
Equipe (Whole Team)
Equipe XP = Cliente + Time de Desenvolvimento
� As funções do cliente englobam:
� Definição dos requisitos do projeto� Definição de prioridades� Controle do rumo do projeto� Controle do rumo do projeto� Definir os testes de aceitação do SW
� Os papéis do time de desenvolvimento englobam:
� desenvolvedores� testadores (ajudam o cliente com os testes de aceitação)� analistas/projetistas (ajudam o cliente a definir requisitos)� gerente (garante os recursos necessários)� coach (orienta a equipe, controlando a aplicação do XP)� tracker (coleta as métricas do projeto)
Equipe (Whole Team)
Jogo de Planejamento (Planning Game)
� Principais definições
� Definição das User Stories (atividade + tarefas)� Estimativas de User Stories� Prioridades (tarefas + importantes)
� Próximos passos
� Planejamento de release (cliente propõe as funcionalidades e� Planejamento de release (cliente propõe as funcionalidades edesenvolvedores avaliam)� Planejamento da iteração (define as funcionalidades da iteração e osdesenvolvedores estimam)
� Ótimo feedback para o cliente, que dirige o projeto
� Idéia clara do avanço do projeto� Clareza: Redução de Riscos, aumentando a chance de sucesso
Produto, Release, PlanejamentoRelease 1 Release 2 Release 3
Planejamento
Iteração 1 Iteração 2 Iteração 3-5
Tarefa A
Tarefa B
Tarefa C
Releases, Iterações, Velocidade
� Um release é formado de múltiplas iterações
� Cada iteração pode ser planejada com o mesma caixa de tempo
� Stories são colocadas dentro de cada caixa, até estar completa
�� O tamanho da caixa é a velocidade planejada
3 4
5
2 6
3 4
5
2 6
2 7
4
4 5
Testes de Aceitação (Acceptance Tests)
� São elaborados pelo cliente em conjunto com analistas e testadores
� São automatizados� Quando rodarem com sucesso, funcionalidade foi implementada� Devem ser rodados a cada iteração� Roteiro com um conjunto de respostas esperadas
� Ótimo feedback para o cliente
� Pode se saber, a qualquer momento, o % de implementação do SW equanto falta
Pequenos Lançamentos (Small Releases)
� Disponibiliza a cada iteração SW 100% funcional� Versão disponibilizada imediatamente� Redução de riscos (se o projeto terminar, parte existe e funciona)� Detecção prévia de problemas� Comunicação entre cliente e desenvolvedor
� Cada lançamento possui funcionalidades prioritárias para a iteração� Cada lançamento possui funcionalidades prioritárias para a iteração
� Lançamento pode ser destinado a� usuário/cliente (testa, avalia e oferece feedback)� usuário/final (sempre que possível)
� Design simples e integração contínua são práticas essenciais
Projeto Simples (Simple Design)
� Projeto está presente em todas as etapas XP� Projeto começa simples e se mantém assim através de testes erefinamento de código (refactoring)
� Não é permitido implementar qualquer funcionalidade adicional quenão será usada na iteração atual
� Em XP, é levado ao extremo
� Implementação ideal é aquela que
não será usada na iteração atual
� Prever o futuro é impossível e é “anti-XP”
� Passa por todos os testes� Expressa todas as idéias definidas no planejamento� Não contém código duplicado ou que “cheire”
Programação em Pares (Pair Programming)
� SW é desenvolvido em pares� “2 cabeças juntas são melhores que duas cabeças separadas”� 1 piloto e 1 co-piloto� Papéis são alternados freqüentemente
� Melhor qualidade de código (refactoring, testes)� Revisão constante do código
� Benefícios
� “Um” pelo preço de “Dois”??
� Revisão constante do código� Nivelamento da equipe� Maior comunicação
� Pesquisas demonstram que duplas produzem código de melhorqualidade em aproximadamente o mesmo tempo que programadoresque trabalham sozinhos
Programação em Pares (Pair Programming)
� Efeitos sobre a produtividade da equipe� “Um trabalha enquanto o outro não faz nada...”� Pressupõe comunicação contínua� pesquisas mostram atividades desempenhadas na metade do tempo dedesenvolvimento� Produtividade a curto prazo X longo prazo
� Pressão do Par
� Desafios
�Concentração, incentivo, responsabilidade� Revezamentos� Disseminação do conhecimento
� Pressão do Par
�Organização do escritório, visão gerencial, relacionamento humano,competição
Desenvolvimento Dirigido por Testes (Test-Driven Development)
� XP valoriza o desenvolvimento dirigido por testes
� Testes “puxam” o desenvolvimento
� São automatizados, executados o tempo todo
� Testes dão coragem para mudar
� Cada unidade de código só tem valor se o teste funcionar 100%
� De que adianta a OO isolar a interface da implementação se odesenvolvedor tem medo de mudar a implementação?
Desenvolvimento Dirigido por Testes (Test-Driven Development)
Obtertarefa Criar Código de
Teste para a tarefa
TDD
Codificar Fazer RefactoringTeste para a tarefa Refactoring
Passou nos testes?
Sim: Nova tarefa Não: Revisar código
Refatoração (Refactoring)
� Design é melhorado continuamente através de refinamento� Mudança proposital no código que está funcionando� Melhorar sua estrutura interna sem alterar a funcionalidade� Visa simplificar o código, remover o código duplicado
� Principal referência é o catálogo de refactorings de Martin Fowler
� Existência prévia de testes é fundamental para utilização destaprática (elimina o medo dos desenvolvedores de adotar a mudança)
� Principal referência é o catálogo de refactorings de Martin Fowler
� “Software é como a nossa casa”� Organizados X desorganizados
� XP enfatiza código de alta qualidade
Integração Contínua (Continuous Integration)
� XP mantém o SW integrado o tempo todo� Realizada pelo menos uma vez por dia� Para integrar, deve-se realizar os testes primeiro
� “Reduz o tempo passado no inferno da integração” - Martin Fowler
� Benefícios� Expõe o estado atual de desenvolvimento� Oferece feedback� Estimula agilidade e versões freqüentes do SW
Posse Coletiva (Collective Ownership)
� O código tem um único dono: a equipe� Qualquer par de programadores pode melhorar o código� Revisão constante do código� Aumenta a comunicação� Aumenta a qualidade (menos duplicação, maior coesão) e diminui osriscos de dependência de indivíduos
� Todos compartilham a responsabilidade pelas alterações
� “Todos conhecem tudo”� Testes e integração contínua são essenciais e dão segurança
� Ideal que se troque os pares periodicamente
Padrões de Codificação (Coding Standards)
� Os padrões de codificação são definidos pela equipe� Organização de código� Nomenclaturas
� Código com aspecto de escrito por um único desenvolvedor
� Competência� Organização
� Posse coletiva� Comunicação� Programação em Pares� Refactoring� Projeto Simples
� Práticas e valores favorecidos
� Organização
Metáfora (Metaphor)
� Equipes XP mantém uma visão compartilhada do sistema�Analogia com outros sistemas (natural, computacional, abstrato)�Exercício de criatividade e abstração
�� Ótima fonte de comunicação entre a equipe, facilitando inclusive asestimativas
� Pattern de alto nível
Ritmo Saudável (Sustainable Pace)
� XP está na arena para ganhar
� Semanas de 80 horas
� Projetos vampiros não são projetos XP
� Semanas de 80 horas� Código ruim, relaxamento da disciplina, stress da equipe� Tempo ganho será perdido depois
� São aceitáveis eventuais horas extras quando a produtividade émaximizada
Reuniões em Pé (StandUp Mettings)
� A maioria dos desenvolvedores odeiam reuniões
� As reuniões são valiosas quando
� Assuntos demorados e desgastantes� Impedem os desenvolvedores de codificar
� Não perdem o foco� São breves
� As reuniões são valiosas quando
� São abordadas tarefas realizadas e a realizar
Spikes de Planejamento (Spike Solution)
� São investigações de tecnologias que podem ser utilizadas noprojeto
�
� Auxiliam nas estimativas e na especificação do projeto� Podem durar horas ou dias, porém devem ser curtos
� Avaliações de arquiteturas� Algoritmos� componentes e frameworks� BDs� Servidores de aplicação, Web� Utilização de artefatos e ferramentas
� Englobam
Ambiente de Trabalho
� O ambiente deve apoiar a aplicação das práticas
� Equipamentos
� Tem importância vital para um projeto de software� Trabalhar próximo dos colegas� Facilitar a comunicação
� Mesas e cadeiras� Equipamentos tecnológicos� Telefones� Mural� Quadro Branco� Calendário� Comida ☺
� Isolamento (equipes e projetos)
� Equipamentos
Documentação Ágil
� Complexidade do Software� Tempo de desenvolvimento� Equipes� Futuras manutenções
� Até que ponto documentar?
� Uso incorreto da documentação
� User stories, testes de aceitação, testes de unidade, documentação decódigo fonte, Modelo de Classes, Modelo de Dados, Processos deNegócio, Manual de usuário, Acompanhamento diário,Acompanhamento do Projeto
� Documentos que compõem a documentação
� Uso incorreto da documentação� Quando documentar?
Ferramentas de Apoio
Mais em http://xprogramming.com/software.htm
Teste de UnidadeTeste de Unidade
Teste de UnidadeTeste de Unidade
Teste de UnidadeTestes
Patterns, Boas Práticas, RefactoringPatterns, Boas Práticas, Refactoring
Patterns, Boas Práticas, RefactoringPatterns, Boas Práticas, Refactoring
Code CoverageCode Coverage
Code CoverageCode Coverage
Code CoverageCode Coverage
Integração ContínuaIntegração Contínua
Integração ContínuaIntegração Contínua
Padrões de CodificaçãoPadrões de Codificação
Padrões de CodificaçãoPadrões de Codificação
Mercado
� HP� Ford� Symantec� Motorola� Chrysler� BMW� Borland� IBM�
� Objective Solutions� ImproveIt� Brasil Telecom� Embrapa� Qualiti� Trevisan Tecnologia� Argonavis� CETIP�
� IBM� First National Bank� Thought Works� CC Pace Systems� Industrial Logic� Moore� Workshare� Xerox� Siemens� Object Mentor
� CETIP� Secretaria da Fazenda SP� Smart Tech Consulting� iQualy� IME-USP� EverSystems� PowerLogic Consultoria� UFRJ� PUC-Rio� Surya Tecnologia
Pesquisas na Web
Pesquisas na Web
Pesquisas na Web
Principais Eventos
Adotando e Escalando XP
� Adote as práticas em doses homeopáticas� Não seja afobado, saboreie a mudança� Enfatize o problema mais importante
� Dificuldades culturais� Deixar alguém mexer no seu código� Pedir ajuda� Pedir ajuda� Ânsia de tentar prever o futuro� Escrever testes antes de codificar� Refatorar com freqüência (superar o medo)
� Situações difíceis de aplicar XP� Equipes grandes e distribuídas geograficamente� Perda do controle sobre código� Feedback demorado
Adotando e Escalando XP
� XP e os processos ágeis valorizam as pessoas� Bons desenvolvedores criam bons SWs
� Processos ágeis são suplementos aos outros métodos� São atitudes� São efetivos� São efetivos� Não é um ataque à documentação e sim a criação de documentos quetem valor� Não são para todos
� O segredo está na sinergia de suas práticas� Menos formalidade, mais diversão
Considerações Finais� XP é uma disciplina de desenvolvimento ágil de SW baseada em comunicação, feedback, simplicidade e coragem
� Para usar XP é preciso fazer com que a equipe se una em torno depráticas simples, obtendo feedback e reajustando estas práticas paracada situação particular
� XP pode ser implementada aos poucos, porém, a maior parte daspráticas são essenciais
� Nem todos os projetos são bons candidatos para XP.� XP não é para todo mundo, mas todo mundo pode aprender com XP
� Adotar Processos Ágeis não é simplesmente aplicá-lo� É preciso entender sua filosofia
XP
SCRUM
Lean
IntegrandoIntegrando váriasváriasMetodologiasMetodologias ÁgeisÁgeis
Desenvolvimento Ágil
SCRUM
Lean
XP
Combinando Lean + SCRUM + XP
Combinando Lean + SCRUM + XP
Exercício de Superação do Medo
Dois voluntários, por favor...
Formação em Metodologias Ágeis
� Introdução ao Lean – Promovendo a Mudança Cultural (8h)
� Projetos Ágeis com SCRUM – Gestão e Acompanhamento (20h)
� Técnicas para gerar Código de Qualidade com eXtreme Programming(12h)
Cursos In Company e Consultorias