Conhecendo as Conhecendo as Metodologias ÁgeisMetodologias Ágeis

Quem 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)

� 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