Indivíduos e Interações mais que processos e ferramentas.

Software funcionando mais que documentação abrangente.

Colaboração com cliente mais que negociação de contratos

Resposta a mudança mais que seguir um plano.

www.agilemanifesto.org

• Effective Smalltalk • Extreme Programming• Junit Pocket guide • Tdd By example• Implementation Patterns•  Refactoring• Domain-Specific

Languages• Patterns of Enterprise

Application Architecture

• UML• Beyond Software

Architecture• Clean Code • Programming in Ruby

São métodos utilizados no intuito de facilitar a adoção de práticas ágeis em processos tradicionais já definidos – não precisa substituir o processo

Algumas são: Extreme Programming – XP Scrum Kanban

PROJETOS DE PONTESPROJETOS DE SOFTWARE

– Prazo – OK ( menos no Brasil )

– Orçamento – OK – Quase nenhuma cai – Ciência Antiga – 4 a 6

mil anos

– Prazo – estoura – Orçamento – estoura – Têm problemas com

freqüência – Ciência nova – 50 anos

Aspectos críticos– Projetos de ponte são engessados e ninguém dá “pitaco”– Projetos de software normalmente precisam suportar mudanças nas regras de negócio– Pontes que caem têm relatórios de erros. Softwares são mascarados eignorados. Não há aprendizado

Fonte: Joaquim Lopes Júniorjoaquim@f6sistemas.com.br

Fonte: Joaquim Lopes Júniorjoaquim@f6sistemas.com.br

1º Encontro PHPMG/2009

Desenvolvimento ágil não garante necessariamente que o projeto terá mais ou menos sucesso

Mas ajuda a descobrir antes que algo não está indo bem – ITERAÇÕES CURTAS E ENVOLVIMENTO DO CLIENTE PARA VALIDAÇÃO

Fonte: Joaquim Lopes Júniorjoaquim@f6sistemas.com.br

1º Encontro PHPMG/2009

Vamos a elas:Scrum e XP

Baseado na teoria de controle de processo industrial– Auto-organização e emergência

Utilizado há 15 anos com sucesso em milhares de projetos, centenas de organizações

É gerencial. Não serve apenas para projetos de software

Scrum é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível.

Equipes que se auto-organizam Prescreve os papéis de Product Owner (cliente) e

Scrum Master, além da equipe (team) O produto evolui em uma série de “Sprints” mensais Os requerimentos são listados em um “Product

Backlog” Não há prática de engenharia prescrita (o Scrum

adequa-se a todas) Usa regras generativas na criação de um ambiente

ágil para a entrega de projetos

Product backlog

Burndown Chart

Planejamento do Sprint

Scrum Diário

Revisão do Sprint

Retrospectiva do Sprint

Microsoft Yahoo Google Electronic Arts The New York Times Philips Siemens Nokia Globo.com BBC Intuit Nielsen Media

First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

Extreme Programming

“Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver

software” - KentBeck

Programadores trabalham em coisas que realmente importam

Cliente tem maior valor agregado possível a cada semana de desenvolvimento

Comunicação: Interna e com o cliente

Simplicidade Não olhar para frente. Para que pensar no trabalho

de amanhã, se amanhã talvez ele não faça mais sentido?

“XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never

be used anyway.” - Kent Beck

PROGRAMAÇÃO EM PAR

PLANNING POKER

TDD Integração contínua Pequenas liberações Refactoring Padrões de Código e código de vários donos

“Contrate bons profissionais, dê a eles ferramentas e treinamentos para que façam o

trabalho, depois saia da frente deles”Dave Thomas – OBT

Linguagens e Frameworks

Linguagens de alto nível Não são compiladas (em sua maioria) Tipagem dinâmica Duck Type Vantagens e Desvantagens Protocolo de Meta-Objeto (Meta-Object Protocol),

ou MOP. Forte presença no Ambiente ágil de

Desenvolvimento. Algumas Aceitam tipagem estática.

Três principais linguagens Dinâmicas da Atualidade

Ruby e Python Tipagem apenas dinâmica e não compiladas. Mais populares linguagens do Meio ágil Orientadas a objeto Código legível

Groovy Tipagem Dinâmica e Estática. Pode ser Compilada . Solução ágil para plataforma JVM. Grande integração com código Java.

Desenvolvendo Ágil

Testes Automatizados, TDD e BDD, Refatoração, CI

Improve it

“Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object orientated or well-

encapsulated it is. With tests, we can change the behavior of our code quickly and verifiable. Without them, we really don’t know if our

code is getting better or worse.”

Working Effectively With Legacy Code - Michael C. Feathers

“To me, legacy code is simply code without tests.”

Working Effectively With Legacy Code - Michael C. Feathers

De autoria do desenvolvedor

Escritos durante o desenvolvimento

Casos de teste Sucesso Falha Especificação Assert

Frameworks: Junit EasyMock Selenium Rspec Cucumber

Pedaços de código Métodos classes

Exemplo:Class matematica def soma(a,b)

a+b endend

class TestMatematica def test_soma math = Matematica.new result = math.soma(2, 2) assert_equal(result, 4) endend

def test_parsearquivo = File.new(“tests/arquivo.txt”)parser = Parser.newparsed_content = parser.parse(arquivo)assert_equal(parsed_content, “teste”)

end

def cliente_nao_deve_ser_salvo_sem_nome cliente = Cliente.new(:nome =>’’)

salvo = cliente.saveassert !salvo

end

Funcionalidades Interação Fluxo Robôs

Exemplos:def test_deve_criar_cliente

assert_difference(‘Cliente.count’)do post :create, :cliente =>{:nome => ‘josé’}

end

assert_redirected_to cliente_path(assigns(:cliente))

end

Exemplos:def test_deve_criar_cliente

assert_difference(‘Cliente.count’)do post :create, :cliente =>{:nome => ‘josé’}

end

assert_redirected_to cliente_path(assigns(:cliente))

end

Módulos Banco de Dados WebServices RMI

Fixtures Dados utilizados nos testes Simulam dados reais Independente de esquema

TDD não é descrever testes, é descrever um comportamento.

Testar Antes Codificar depois Codificar somente o necessário para o teste

passar Falha do teste indica próximo passo de

codificação

Se você escrever testes antes, irá codificar melhor depois.

Teste Falha Teste passa Refatorar

Ciclo do TDD

Usando TDD, quando acabamos, realmente acabamos.

DSL - Domain Specific Language Especificar um comportamento Especificar o sistema

Exemplo com Rspec

describe Userend

Usuário não existe!

class usuarioend

OK!

describe usuarioit “deve estar no papel atribuido a ele” do

usuario= Usuario.new usuario.should be_no_papel(“papel atribuido”)end

end

Método “no_papel?” não existe!

Class Usuariodef no_papel?(papel)end

end

Método “no_papel?” retornou nulo mas deveria ter retornado verdadeiro!

Class Usuariodef no_papel?(papel)

trueend

end

OK!

describe usuarioit “deve estar no papel atribuido a ele” do

usuario= Usuario.new usuario.should be_no_papel(“papel atribuido”)end

end

describe usuarioit “deve estar no papel atribuido a ele” do

usuario= Usuario.newusuario.atribuir_papel(“papel atribuido”)

usuario.should be_no_papel(“papel atribuido”)end

end

Método “atribuir_papel” não existe!

Class Usuariodef no_papel?(papel)trueenddef atribuir_papel(papel)end

end

OK!

describe usuarioit “deve estar no papel atribuido a ele” do

usuario= Usuario.newusuario.atribuir_papel(“papel atribuido”)

usuario.should be_no_papel(“papel atribuido”)endit “não deve estar no papel não atribuido a ele” do

usuario= Usuario.new usuario.should_not be_no_papel(“papel não atribuido”)end

end

Método “in_role” retornou true

Class Usuariodef no_papel?(papel)papel == “papel atribuido”enddef atribuir_papel(papel)end

end

OK!

Hora de refatorar!

Class Usuario@papeldef no_papel?(papel)@papel ==papelenddef atribuir_papel(papel)@papel = papelend

end

OK!

Usuario-deve estar no papel atribuido a ele-Não deve estar no papel não atribuido a ele

Finished in 0.018 seconds2 examples, 0 failures

Assuntos Pendentes

CI – Integração Contínua Repositório de codigo Build automático Execução de testes Controle de releases Deploy

CI – Integração Contínua Diminui o tempo de integração Ambiente de build controlado Detecção de bugs Reduz riscos

Refatoração Pequenas mudanças Preservam o comportamento externo Mudanças estruturais Organizam o código Melhoram o entendimento Facilitam adição de novas funcionalidades

Considerações Finais Testes especificam o software Testes aumentam a qualidade Testes melhoram o design Testes provêem segurança Testes dão liberdade

Está provado que Desenvolvimento Ágil funciona e que é o que o mercado procura

Tendências do Mercado de TI apontam: Programação em nuvem Tecnologias que cortem custos e de retorno rápido

do investimento aplicado Tecnologias OpenSource e Sustentáveis Comunidades coperativas

Ninguém faz nada sozinho Mobilidade

Criar grupos Trocar conhecimentos Aprender coisas novas Estar sempre atualizados Participar de eventos Assistir palestras

E depois, porque não:Um Happy Hour!!

agilemanifesto.org neactar.com ruby-lang.org rubyonrails.pro.br python.org groovy.codehaus.org djangoproject.com scrumalliance.org improveit.com.br/scrum improveit.com.br/xp testdriven.com improveit.com.br/xp/praticas/tdd behaviour-driven.org/ martinfowler.com/articles/continuousIntegration refactoring.com infoq.com/br grails.org

@abacrazytech@thiagocifani

aba532@gmail.com cifani.thiago@gmail.com