Upload
uniritterufrgstjrswildtech
View
380
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
Conhecendo as Conhecendo as Metodologias ÁgeisMetodologias Ágeis
Quem sou eu?
Guilherme [email protected]
� 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 anosde 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-Coordenadordo 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 paraos 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?
� 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
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 Valor
Alto RiscoAlto Valor
Baixo RiscoAlto Valor
Alto RiscoBaixo Valor
Baixo RiscoBaixo Valor
Risco
Valor
Fazer Primeiro
Fazer depois
Evitar
Fazer por último
Risco
Valor
Waterfall, Iterativo
Metodologias Ágeis
� Cultura (princípios e valores)� Foco no ROI� Eliminação de desperdícios
Lean� Foco no planejamento e priorização� AutogestãoScrum
Preparando o terreno
� Autogestão� Colaboração e ComprometimentoScrum� Comunicação e feedback� Práticas de engenharia� Entregas frequentes� Ênfase em qualidade
XP
LeanLean Software Software DevelopmentDevelopment
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� 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 dedesperdícios� JIT e Autonomação
100100
Antes
0
50
Depois
Prevenção
Avaliação
Falhas Internas
Falhas Externas Economia
Prevenção
Avaliação
Falhas Internas
Falhas Externas
Lean Software Development
� Principais nomes são Mary e Tom Poppendieck� Principais nomes são Mary e Tom Poppendieck
SCRUMSCRUM
O que é SCRUM?
O que é SCRUM?
� Framework ágil para gerência de projetos� Pode ser utilizada para qualquer tipo de projeto� Pode ser utilizada para qualquer tipo de projeto
� Processo empírico para gerência e desenvolvimento de produtoscomplexos
� 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 MikeBeedle
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
Foudation Level
Mid Level
Professional Level
Guide Level
Valores
� Comunicação
� Trabalho em Equipe� Trabalho em Equipe
� Flexibilidade
� Foco no produto e em atividades que agregam valor
� Respeito e coragem
Fluxo de Valor do SCRUM
VisãoAprovação do Projeto
Time Desenvolvimento ImplantaçãoSuporte
e Feedback
Durante
Feedback do Cliente
Agregar Valor
Aprendizado
Durante
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.
eXtremeeXtreme ProgrammingProgramming
XP
� Criado por Kent Beck, Ron Jeffries e Ward Cunningham� 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� 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� 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, 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
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
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 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� Symantec� Motorola� Chrysler� BMW� Borland� IBM� First National Bank� Thought Works
� Objective Solutions� ImproveIt� Brasil Telecom� Embrapa� Qualiti� Trevisan Tecnologia� Argonavis� CETIP�� Thought Works
� CC Pace Systems� Industrial Logic� Moore� Workshare� Xerox� Siemens� Object Mentor� Microsoft� Google� Nokia� Yahoo
� CETIP� Secretaria da Fazenda SP� Smart Tech Consulting� iQualy� IME-USP� EverSystems� PowerLogic Consultoria� UFRJ� PUC-Rio� Surya Tecnologia
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�� 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
� 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
Adotando e Escalando Metodologias Ágeis
� São efetivos� Não é um ataque à documentação e sim a criação dedocumentos 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...Dois voluntários, por favor...
Apoio