SlideShare une entreprise Scribd logo
1  sur  91
Télécharger pour lire hors ligne
Conhecendo as
Metodologias Ágeis
Quem sou eu?

        Guilherme Lacerda
     guilhermeslacerda@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)

 Consultor de TI, com mais de 15 anos na área de desenvolvimento de Software e 10 anos
de experiência em modelagem e desenvolvimento OO

  Instrutor/Consultor de Metodologias Ágeis da TargetTrust Treinamento e Tecnologia

 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 a SUCESU-RS

 Membro do IASA (International Association of Software Architects)
Quem 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 processos complexos
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 para
os desenvolvedores
   Baseados no paradigma do comando e controle
   Tenta minimizar o papel do cliente


Foco em tecnologia e não no negócio
Comunicação
Comunicação
Comunicação
Comunicação
Como resolvê-los?
Como resolvê-los?
O que é ser Ágil?
Ágil é ser rápido, ligeiro (dicionário)
    Eficaz: produz o resultado esperado
    Eficiente: produz o resultado esperado, mas com qualidade


Características importantes:
    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 a
que custo

 Ver e acompanhar o andamento do projeto e, principalmente, o
progresso do SW, passando por testes definidos em conjunto com a
equipe

 Mudar de idéia, substituir funcionalidades, sem pagar custos
exorbitantes

  Ser informado de mudanças no cronograma, em tempo de escolher e
reduzir o escopo

  Poder cancelar o projeto a qualquer momento e ainda assim ter um
sistema funcionando, refletindo o investimento realizado até o
momento
Direitos do Desenvolvedor (Ron Jeffries)

  Saber o que é necessário, com declarações claras de
prioridade


 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 desenvolver
software 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;

Ou seja, mesmo tendo valor os itens à direita, valorizamos
mais os itens à esquerda.”

Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward
Cunningham, 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
Waterfall X Ágil
Cone da Incerteza
Riscos

Riscos de Planejamento
  Será     que      conseguiremos
  terminar até outubro?


Riscos de Custo
  Será que conseguiremos comprar o servidor pelo preço definido
  anteriormente?


Riscos de Requisitos
  Será que temos todas as informações para começar o trabalho?
Risco X Valor
           Alto Risco               Alto Risco
          Baixo Valor               Alto Valor
Risco


          Baixo Risco              Baixo Risco
          Baixo Valor               Alto Valor


                           Valor


             Evitar            Fazer Primeiro
Risco



        Fazer por último           Fazer depois



                        Valor
Waterfall, Iterativo
Metodologias Ágeis
Preparando o terreno

         Cultura (princípios e valores)
Lean     Foco no ROI
         Eliminação de desperdícios
         Foco no planejamento e priorização
         Autogestão
Scrum    Colaboração e Comprometimento
         Comunicação e feedback
         Práticas de engenharia
 XP      Entregas frequentes
         Ênfase em qualidade
Lean Software Development
Principais Nomes




Kiichiro Toyoda
   JIT na linha de produção

Taiichi Ohno
   Fluxo JIT e Autonomação (Jidoka)


Shingeo Shingo
   Produção sem estoques e Zero Inspeções
Problemas de Produção



Muda
   Desperdícios

Mura
   Falta de regularidade

Muri
   Sobrecarga
STP
Conceitos
Just in Time

Jidoka

Heijunka

Kanban

Andon

Poka-Yoke

Jishuken

Genchi Genbutsu

Trabalho Padronizado e 5S

Hansei e Kaizen
Kanban
Trabalho Padronizado/5S
Prevenção X Inspeção

STP
  Foco    em   prevenção     e       eliminação   de
 desperdícios
  JIT e Autonomação


      100
             Falhas
            Externas       Economia

              Falhas       Falhas Externas
      50     Internas
                              Falhas
                             Internas

            Avaliação      Avaliação

                           Prevenção
       0    Prevenção

             Antes          Depois
Lean Software Development



Principais nomes são Mary e Tom Poppendieck
SCRUM
O que é SCRUM?
O que é SCRUM?



 Framework ágil para gerência de projetos
     Pode ser utilizada para qualquer tipo de projeto

 Processo empírico para gerência e desenvolvimento de produtos
complexos
     Empirismo é dependente de inspeção frequente e adaptações dos
   objetivos
     Inspeção é dependente de transparência
     Equipes auto-gerenciadas

 SCRUM = jogada no Rugby
O que é SCRUM?




 Principais nomes são Ken Schwaber, Jeff Sutherland e Mike
Beedle
SCRUM Alliance


Instituição sem fins lucrativos

Centraliza cursos, artigos, materiais e eventos sobre SCRUM

Responsável pelas certificações
                   http://www.scrumalliance.org/scrum_certification



                                              Professional Level
 Foudation Level




                                                                        Guide Level
                               Mid Level
Valores


Comunicação


Trabalho em Equipe


Flexibilidade


Foco no produto e em atividades que agregam valor


Respeito e coragem
Fluxo de Valor do SCRUM


        Aprovação                                                         Suporte
Visão                Time           Desenvolvimento       Implantação
        do Projeto                                                      e Feedback


                                     Durante


    Feedback do Cliente

                                  Aprendizado
                                                        Agregar Valor
                          Antes                Depois
Framework SCRUM
Framework SCRUM
Desenvolvimento Sequencial
                                                X SCRUM

Requerimentos      Projeto                Código                   Teste




                Fonte: “The New New Product Development Game” by
                Takeuchi and Nonaka. Harvard Business Review, January
                1986.
eXtreme Programming
XP



 Criado por Kent Beck, Ron Jeffries e Ward Cunningham

  Disciplina de desenvolvimento de SW, voltada para equipes
pequenas e médias, com requisitos vagos ou que mudam
freqüentemente

 Principal tarefa é a codificação
XP
Valores do XP



Comunicação
   Práticas valorizam a comunicação, não limitada a procedimentos formais

Simplicidade
   Incentiva ao extremo práticas que reduzam a complexidade

Feedback
   Práticas garantem um rápido feedback sobre várias partes do projeto

Coragem
   Práticas aumentam a confiança dos desenvolvedores e do próprio cliente
Variáveis de um Projeto

Processos Tradicionais
  Tempo
  Escopo                      Manipula-se a
  Custo                        Qualidade




eXtreme Programming
  Tempo                       Manipula-se a
  Qualidade                     Escopo
  Custo
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
  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
   desenvolvedores avaliam)
     Planejamento da iteração (define as funcionalidades da iteração e os
   desenvolvedores 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, Planejamento
               Release 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       2
                                       3          7
                                                  4

                           5                  4
                                              5

                       2       6       4
                                       2          5
                                                  6
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 e
  quanto 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


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 e
   refinamento de código (refactoring)


Em XP, é levado ao extremo
     Não é permitido implementar qualquer funcionalidade adicional que
   não será usada na iteração atual


Implementação ideal é aquela que
     Passa por todos os testes
     Expressa todas as idéias definidas no planejamento
     Não contém código duplicado ou que “cheire”


Prever o futuro é impossível e é “anti-XP”
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

Benefícios
    Melhor qualidade de código (refactoring, testes)
    Revisão constante do código
    Nivelamento da equipe
    Maior comunicação

“Um” pelo preço de “Dois”??
     Pesquisas demonstram que duplas produzem código de melhor
   qualidade em aproximadamente o mesmo tempo que programadores
   que trabalham sozinhos
Desenvolvimento Dirigido por Testes (Test-Driven
                                              Development)


XP valoriza o desenvolvimento dirigido por testes
    São automatizados, executados o tempo todo



Testes “puxam” o desenvolvimento
   Cada unidade de código só tem valor se o teste funcionar 100%




Testes dão coragem para mudar
   De que adianta a OO isolar a interface da implementação se o
 desenvolvedor tem medo de mudar a implementação?
Desenvolvimento Dirigido por Testes (Test-Driven
                                              Development)



                                       TDD
Obter
tarefa    Criar Código de              Codificar             Fazer
         Teste 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 desta
   prática (elimina o medo dos desenvolvedores de adotar a mudança)

“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 os
  riscos de dependência de indivíduos

Todos compartilham a responsabilidade pelas alterações


Ideal que se troque os pares periodicamente
    “Todos conhecem tudo”
    Testes e integração contínua são essenciais e dão segurança
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



Práticas e valores favorecidos
    Posse coletiva
    Comunicação
    Programação em Pares
    Refactoring
    Projeto Simples
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 as
estimativas




 Pattern de alto nível
Ritmo Saudável (Sustainable Pace)
 XP está na arena para ganhar




 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
    Assuntos demorados e desgastantes
    Impedem os desenvolvedores de codificar




As reuniões são valiosas quando
    Não perdem o foco
    São breves




São abordadas tarefas realizadas e a realizar
Spikes de Planejamento (Spike Solution)

  São investigações de tecnologias que podem ser utilizadas no
projeto
     Auxiliam nas estimativas e na especificação do projeto
     Podem durar horas ou dias, porém devem ser curtos



 Englobam
     Avaliações de arquiteturas
     Algoritmos
     componentes e frameworks
     BDs
     Servidores de aplicação, Web
     Utilização de artefatos e ferramentas
Ambiente de Trabalho
O ambiente deve apoiar a aplicação das práticas
    Tem importância vital para um projeto de software
    Trabalhar próximo dos colegas
    Facilitar a comunicação



Equipamentos
    Mesas e cadeiras
    Equipamentos tecnológicos
    Telefones
    Mural
    Quadro Branco
    Calendário
    Comida ☺
    Isolamento (equipes e projetos)
Documentação Ágil
Complexidade do Software
    Tempo de desenvolvimento
    Equipes
    Futuras manutenções

Até que ponto documentar?
   Uso incorreto da documentação
   Quando documentar?

Documentos que compõem a documentação
    User stories, testes de aceitação, testes de unidade, documentação de
  código fonte, Modelo de Classes, Modelo de Dados, Processos de
  Negócio,     Manual      de     usuário,     Acompanhamento      diário,
  Acompanhamento do Projeto
Ferramentas de Apoio




 Mais em http://xprogramming.com/software.htm
Teste de Unidade
Teste de Unidade
Teste de Unidade
Patterns, Boas Práticas, Refactoring
Patterns, Boas Práticas, Refactoring
Code Coverage
Code Coverage
Code Coverage
Integração Contínua
Integração Contínua
Padrões de Codificação
Padrões de Codificação
Mercado
HP
Ford                  Objective Solutions
Symantec              ImproveIt
Motorola              Brasil Telecom
Chrysler              Embrapa
BMW                   Qualiti
Borland               Trevisan Tecnologia
IBM                   Argonavis
First National Bank   CETIP
Thought Works         Secretaria da Fazenda SP
CC Pace Systems       Smart Tech Consulting
Industrial Logic      iQualy
Moore                 IME-USP
Workshare             EverSystems
Xerox                 PowerLogic Consultoria
Siemens               UFRJ
Object Mentor         PUC-Rio
Microsoft             Surya Tecnologia
Google
Nokia
Yahoo
Principais Eventos
Adotando e Escalando Metodologias Ágeis

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
   Aceitar/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 práticas ágeis
   Equipes grandes e distribuídas geograficamente
   Perda do controle sobre código
   Feedback demorado
Adotando e Escalando Metodologias Ágeis


Metodologias ágeis valorizam as pessoas
   Bons desenvolvedores criam bons SWs

Processos ágeis são suplementos aos outros métodos
   São atitudes
   São efetivos
   Não é um ataque à documentação e sim a criação de
 documentos que tem valor
   Não são para todos

O segredo está na sinergia de suas práticas
   Menos formalidade, mais diversão
Combinando Lean + SCRUM + XP
Combinando Lean + SCRUM + XP
Exercício de Superação do medo



  Dois voluntários, por favor...
Apoio

Contenu connexe

Tendances

Palestra Modelagem Ágil - Manoel Pimentel
Palestra Modelagem Ágil -  Manoel PimentelPalestra Modelagem Ágil -  Manoel Pimentel
Palestra Modelagem Ágil - Manoel PimentelManoel Pimentel Medeiros
 
Desenvolvimento Ágil de Software
Desenvolvimento Ágil de SoftwareDesenvolvimento Ágil de Software
Desenvolvimento Ágil de SoftwareMassimus CT
 
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)Rildo (@rildosan) Santos
 
Agile PMI: o que é a PMI-ACP?
Agile PMI: o que é a PMI-ACP?Agile PMI: o que é a PMI-ACP?
Agile PMI: o que é a PMI-ACP?Massimus CT
 
Bate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPBate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPWildtech
 
Scrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveScrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveMarcos Alves
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGNeubio Ferreira
 
Metodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosMetodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosLeandro Faria
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareAdolfo Neto
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREErnesto Bedrikow
 
Melhoria de Processos de Software
Melhoria de Processos de SoftwareMelhoria de Processos de Software
Melhoria de Processos de SoftwareAlessandro Almeida
 
Métricas Em Fabricas De Software
Métricas Em Fabricas De SoftwareMétricas Em Fabricas De Software
Métricas Em Fabricas De SoftwareLuiz Borba
 

Tendances (20)

Palestra Modelagem Ágil - Manoel Pimentel
Palestra Modelagem Ágil -  Manoel PimentelPalestra Modelagem Ágil -  Manoel Pimentel
Palestra Modelagem Ágil - Manoel Pimentel
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Palestra scrum
Palestra scrumPalestra scrum
Palestra scrum
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
 
Desenvolvimento Ágil de Software
Desenvolvimento Ágil de SoftwareDesenvolvimento Ágil de Software
Desenvolvimento Ágil de Software
 
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
 
Synapses Scrum
Synapses ScrumSynapses Scrum
Synapses Scrum
 
Agile PMI: o que é a PMI-ACP?
Agile PMI: o que é a PMI-ACP?Agile PMI: o que é a PMI-ACP?
Agile PMI: o que é a PMI-ACP?
 
Bate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPBate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XP
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Introdução ao Scrum
Introdução ao ScrumIntrodução ao Scrum
Introdução ao Scrum
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
Scrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveScrum in a nutshell - business perspective
Scrum in a nutshell - business perspective
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
 
Metodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosMetodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de Projetos
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
 
Melhoria de Processos de Software
Melhoria de Processos de SoftwareMelhoria de Processos de Software
Melhoria de Processos de Software
 
Métricas Em Fabricas De Software
Métricas Em Fabricas De SoftwareMétricas Em Fabricas De Software
Métricas Em Fabricas De Software
 

Similaire à Oficina Métodos Ágeis UDESC

Introdução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumIntrodução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumJuan Bernabó
 
Palestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROPalestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROWildtech
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)André Dias
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareRoberto Brandini
 
Desenvolvimento ágil pensando além
Desenvolvimento ágil   pensando alémDesenvolvimento ágil   pensando além
Desenvolvimento ágil pensando alémilegra
 
Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Lourenco P Soares
 
Metodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareMetodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareUniversidade Tiradentes
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrumjrompkovski
 
Desmitificando o ágil e o scrum
Desmitificando o ágil e o scrumDesmitificando o ágil e o scrum
Desmitificando o ágil e o scrumScumpb
 
Gestao Agil de Projetos com Scrum
Gestao Agil de Projetos com ScrumGestao Agil de Projetos com Scrum
Gestao Agil de Projetos com ScrumRafael Ramos
 
Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0Juan Bernabó
 
Lean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de softwareLean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de softwareTiago França
 
O que não te contaram sobre o Ágil
O que não te contaram sobre o ÁgilO que não te contaram sobre o Ágil
O que não te contaram sobre o ÁgilWilhelm Meier
 
Agile, mudando o foco
Agile, mudando o focoAgile, mudando o foco
Agile, mudando o focoewerttonbravo
 

Similaire à Oficina Métodos Ágeis UDESC (20)

Desmistificando Agile & Scrum
Desmistificando Agile & ScrumDesmistificando Agile & Scrum
Desmistificando Agile & Scrum
 
Introdução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumIntrodução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com Scrum
 
Palestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROPalestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPRO
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
 
Scrum
ScrumScrum
Scrum
 
Agile
AgileAgile
Agile
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
 
Desenvolvimento ágil pensando além
Desenvolvimento ágil   pensando alémDesenvolvimento ágil   pensando além
Desenvolvimento ágil pensando além
 
Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013
 
Metodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareMetodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de software
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrum
 
Princípios Ágeis
Princípios ÁgeisPrincípios Ágeis
Princípios Ágeis
 
Desmitificando o ágil e o scrum
Desmitificando o ágil e o scrumDesmitificando o ágil e o scrum
Desmitificando o ágil e o scrum
 
Gestao Agil de Projetos com Scrum
Gestao Agil de Projetos com ScrumGestao Agil de Projetos com Scrum
Gestao Agil de Projetos com Scrum
 
Curso Scrum
Curso ScrumCurso Scrum
Curso Scrum
 
Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0
 
Lean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de softwareLean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de software
 
O que não te contaram sobre o Ágil
O que não te contaram sobre o ÁgilO que não te contaram sobre o Ágil
O que não te contaram sobre o Ágil
 
Agile, mudando o foco
Agile, mudando o focoAgile, mudando o foco
Agile, mudando o foco
 

Plus de Wildtech

Voltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágilVoltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágilWildtech
 
O que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de softwareO que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de softwareWildtech
 
XP e a Academia
XP e a AcademiaXP e a Academia
XP e a AcademiaWildtech
 
Abordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coachingAbordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coachingWildtech
 
TDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TITDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TIWildtech
 
TDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion ArchitectureTDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion ArchitectureWildtech
 
TDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria ContínuaTDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria ContínuaWildtech
 
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...Wildtech
 
Agile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching PatternsAgile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching PatternsWildtech
 
TDC 2016 - O Novo Professor
TDC 2016 - O Novo ProfessorTDC 2016 - O Novo Professor
TDC 2016 - O Novo ProfessorWildtech
 
Swarm Debugging
Swarm DebuggingSwarm Debugging
Swarm DebuggingWildtech
 
[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme Programming[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme ProgrammingWildtech
 
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...Wildtech
 
[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de Dados[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de DadosWildtech
 
(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários Complexos(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários ComplexosWildtech
 
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...Wildtech
 
5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"Wildtech
 
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)Wildtech
 
Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Wildtech
 
CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)Wildtech
 

Plus de Wildtech (20)

Voltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágilVoltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágil
 
O que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de softwareO que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de software
 
XP e a Academia
XP e a AcademiaXP e a Academia
XP e a Academia
 
Abordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coachingAbordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coaching
 
TDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TITDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TI
 
TDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion ArchitectureTDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion Architecture
 
TDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria ContínuaTDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
 
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
 
Agile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching PatternsAgile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching Patterns
 
TDC 2016 - O Novo Professor
TDC 2016 - O Novo ProfessorTDC 2016 - O Novo Professor
TDC 2016 - O Novo Professor
 
Swarm Debugging
Swarm DebuggingSwarm Debugging
Swarm Debugging
 
[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme Programming[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme Programming
 
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
 
[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de Dados[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de Dados
 
(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários Complexos(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários Complexos
 
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
 
5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"
 
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
 
Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)
 
CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)
 

Oficina Métodos Ágeis UDESC

  • 2. Quem sou eu? Guilherme Lacerda guilhermeslacerda@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) Consultor de TI, com mais de 15 anos na área de desenvolvimento de Software e 10 anos de experiência em modelagem e desenvolvimento OO Instrutor/Consultor de Metodologias Ágeis da TargetTrust Treinamento e Tecnologia 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 a SUCESU-RS Membro do IASA (International Association of Software Architects)
  • 3. Quem faz programa? Por que 80% a 90% dos projetos de SW fracassam? Fonte: Standish Group
  • 4. 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 processos complexos
  • 5. 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 para os desenvolvedores Baseados no paradigma do comando e controle Tenta minimizar o papel do cliente Foco em tecnologia e não no negócio
  • 12. O que é ser Ágil? Ágil é ser rápido, ligeiro (dicionário) Eficaz: produz o resultado esperado Eficiente: produz o resultado esperado, mas com qualidade Características importantes: 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!)
  • 13. Direitos do Cliente (Ron Jeffries) Planejamento Geral, definindo o que pode ser realizado, quando e a que custo Ver e acompanhar o andamento do projeto e, principalmente, o progresso do SW, passando por testes definidos em conjunto com a equipe Mudar de idéia, substituir funcionalidades, sem pagar custos exorbitantes Ser informado de mudanças no cronograma, em tempo de escolher e reduzir o escopo Poder cancelar o projeto a qualquer momento e ainda assim ter um sistema funcionando, refletindo o investimento realizado até o momento
  • 14. Direitos do Desenvolvedor (Ron Jeffries) Saber o que é necessário, com declarações claras de prioridade 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
  • 15. 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
  • 16. 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 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; Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.” Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward Cunningham, 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
  • 20. Riscos Riscos de Planejamento Será que conseguiremos terminar até outubro? Riscos de Custo Será que conseguiremos comprar o servidor pelo preço definido anteriormente? Riscos de Requisitos Será que temos todas as informações para começar o trabalho?
  • 21. Risco X Valor Alto Risco Alto Risco Baixo Valor Alto Valor Risco Baixo Risco Baixo Risco Baixo Valor Alto Valor Valor Evitar Fazer Primeiro Risco Fazer por último Fazer depois Valor
  • 24. Preparando o terreno Cultura (princípios e valores) Lean Foco no ROI Eliminação de desperdícios Foco no planejamento e priorização Autogestão Scrum Colaboração e Comprometimento Comunicação e feedback Práticas de engenharia XP Entregas frequentes Ênfase em qualidade
  • 26. Principais Nomes Kiichiro Toyoda JIT na linha de produção Taiichi Ohno Fluxo JIT e Autonomação (Jidoka) Shingeo Shingo Produção sem estoques e Zero Inspeções
  • 27. Problemas de Produção Muda Desperdícios Mura Falta de regularidade Muri Sobrecarga
  • 28. STP
  • 29. Conceitos Just in Time Jidoka Heijunka Kanban Andon Poka-Yoke Jishuken Genchi Genbutsu Trabalho Padronizado e 5S Hansei e Kaizen
  • 32. Prevenção X Inspeção STP Foco em prevenção e eliminação de desperdícios JIT e Autonomação 100 Falhas Externas Economia Falhas Falhas Externas 50 Internas Falhas Internas Avaliação Avaliação Prevenção 0 Prevenção Antes Depois
  • 33. Lean Software Development Principais nomes são Mary e Tom Poppendieck
  • 34. SCRUM
  • 35. O que é SCRUM?
  • 36. O que é SCRUM? Framework ágil para gerência de projetos Pode ser utilizada para qualquer tipo de projeto Processo empírico para gerência e desenvolvimento de produtos complexos Empirismo é dependente de inspeção frequente e adaptações dos objetivos Inspeção é dependente de transparência Equipes auto-gerenciadas SCRUM = jogada no Rugby
  • 37. O que é SCRUM? Principais nomes são Ken Schwaber, Jeff Sutherland e Mike Beedle
  • 38. SCRUM Alliance Instituição sem fins lucrativos Centraliza cursos, artigos, materiais e eventos sobre SCRUM Responsável pelas certificações http://www.scrumalliance.org/scrum_certification Professional Level Foudation Level Guide Level Mid Level
  • 39. Valores Comunicação Trabalho em Equipe Flexibilidade Foco no produto e em atividades que agregam valor Respeito e coragem
  • 40. Fluxo de Valor do SCRUM Aprovação Suporte Visão Time Desenvolvimento Implantação do Projeto e Feedback Durante Feedback do Cliente Aprendizado Agregar Valor Antes Depois
  • 43. Desenvolvimento Sequencial X SCRUM Requerimentos Projeto Código Teste Fonte: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
  • 45. XP Criado por Kent Beck, Ron Jeffries e Ward Cunningham Disciplina de desenvolvimento de SW, voltada para equipes pequenas e médias, com requisitos vagos ou que mudam freqüentemente Principal tarefa é a codificação
  • 46. XP
  • 47. Valores do XP Comunicação Práticas valorizam a comunicação, não limitada a procedimentos formais Simplicidade Incentiva ao extremo práticas que reduzam a complexidade Feedback Práticas garantem um rápido feedback sobre várias partes do projeto Coragem Práticas aumentam a confiança dos desenvolvedores e do próprio cliente
  • 48. Variáveis de um Projeto Processos Tradicionais Tempo Escopo Manipula-se a Custo Qualidade eXtreme Programming Tempo Manipula-se a Qualidade Escopo Custo
  • 49. XP – eXtreme Programming Práticas organizacionais Práticas de equipe Práticas de pares
  • 50. 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 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)
  • 52. 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 desenvolvedores avaliam) Planejamento da iteração (define as funcionalidades da iteração e os desenvolvedores 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
  • 53. Produto, Release, Planejamento Release 1 Release 2 Release 3 Planejamento Iteração 1 Iteração 2 Iteração 3-5 Tarefa A Tarefa B Tarefa C
  • 54. 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 2 3 7 4 5 4 5 2 6 4 2 5 6
  • 55. 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 e quanto falta
  • 56. 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 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
  • 57. 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 e refinamento de código (refactoring) Em XP, é levado ao extremo Não é permitido implementar qualquer funcionalidade adicional que não será usada na iteração atual Implementação ideal é aquela que Passa por todos os testes Expressa todas as idéias definidas no planejamento Não contém código duplicado ou que “cheire” Prever o futuro é impossível e é “anti-XP”
  • 58. 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 Benefícios Melhor qualidade de código (refactoring, testes) Revisão constante do código Nivelamento da equipe Maior comunicação “Um” pelo preço de “Dois”?? Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos
  • 59. Desenvolvimento Dirigido por Testes (Test-Driven Development) XP valoriza o desenvolvimento dirigido por testes São automatizados, executados o tempo todo Testes “puxam” o desenvolvimento Cada unidade de código só tem valor se o teste funcionar 100% Testes dão coragem para mudar De que adianta a OO isolar a interface da implementação se o desenvolvedor tem medo de mudar a implementação?
  • 60. Desenvolvimento Dirigido por Testes (Test-Driven Development) TDD Obter tarefa Criar Código de Codificar Fazer Teste para a tarefa Refactoring Passou nos testes? Sim: Nova tarefa Não: Revisar código
  • 61. 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 desta prática (elimina o medo dos desenvolvedores de adotar a mudança) “Software é como a nossa casa” Organizados X desorganizados XP enfatiza código de alta qualidade
  • 62. 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
  • 63. 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 os riscos de dependência de indivíduos Todos compartilham a responsabilidade pelas alterações Ideal que se troque os pares periodicamente “Todos conhecem tudo” Testes e integração contínua são essenciais e dão segurança
  • 64. 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 Práticas e valores favorecidos Posse coletiva Comunicação Programação em Pares Refactoring Projeto Simples
  • 65. 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 as estimativas Pattern de alto nível
  • 66. Ritmo Saudável (Sustainable Pace) XP está na arena para ganhar 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
  • 67. Reuniões em Pé (StandUp Mettings) A maioria dos desenvolvedores odeiam reuniões Assuntos demorados e desgastantes Impedem os desenvolvedores de codificar As reuniões são valiosas quando Não perdem o foco São breves São abordadas tarefas realizadas e a realizar
  • 68. Spikes de Planejamento (Spike Solution) São investigações de tecnologias que podem ser utilizadas no projeto Auxiliam nas estimativas e na especificação do projeto Podem durar horas ou dias, porém devem ser curtos Englobam Avaliações de arquiteturas Algoritmos componentes e frameworks BDs Servidores de aplicação, Web Utilização de artefatos e ferramentas
  • 69. Ambiente de Trabalho O ambiente deve apoiar a aplicação das práticas Tem importância vital para um projeto de software Trabalhar próximo dos colegas Facilitar a comunicação Equipamentos Mesas e cadeiras Equipamentos tecnológicos Telefones Mural Quadro Branco Calendário Comida ☺ Isolamento (equipes e projetos)
  • 70. Documentação Ágil Complexidade do Software Tempo de desenvolvimento Equipes Futuras manutenções Até que ponto documentar? Uso incorreto da documentação Quando documentar? Documentos que compõem a documentação User stories, testes de aceitação, testes de unidade, documentação de código fonte, Modelo de Classes, Modelo de Dados, Processos de Negócio, Manual de usuário, Acompanhamento diário, Acompanhamento do Projeto
  • 71. Ferramentas de Apoio Mais em http://xprogramming.com/software.htm
  • 84. Mercado HP Ford Objective Solutions Symantec ImproveIt Motorola Brasil Telecom Chrysler Embrapa BMW Qualiti Borland Trevisan Tecnologia IBM Argonavis First National Bank CETIP Thought Works Secretaria da Fazenda SP CC Pace Systems Smart Tech Consulting Industrial Logic iQualy Moore IME-USP Workshare EverSystems Xerox PowerLogic Consultoria Siemens UFRJ Object Mentor PUC-Rio Microsoft Surya Tecnologia Google Nokia Yahoo
  • 86. Adotando e Escalando Metodologias Ágeis 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 Aceitar/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 práticas ágeis Equipes grandes e distribuídas geograficamente Perda do controle sobre código Feedback demorado
  • 87. Adotando e Escalando Metodologias Ágeis Metodologias ágeis valorizam as pessoas Bons desenvolvedores criam bons SWs Processos ágeis são suplementos aos outros métodos São atitudes São efetivos Não é um ataque à documentação e sim a criação de documentos que tem valor Não são para todos O segredo está na sinergia de suas práticas Menos formalidade, mais diversão
  • 88. Combinando Lean + SCRUM + XP
  • 89. Combinando Lean + SCRUM + XP
  • 90. Exercício de Superação do medo Dois voluntários, por favor...
  • 91. Apoio