A revolução Agile >

Luiz Fernando Ribeiro “Perdido”

26 de Agosto de 2010
Por que você está aqui?
 Agenda

●
Sobre a ThoughtWorks
●
Modelos tradicionais de desenvolvimento
●
Agile manifesto
●
Descendo o nível...
 Sobre a ThoughtWorks

●
Pioneira e totalmente focada em Agile
●
Referência em práticas ágeis
●
8 países, 21 cidades
●
Open Source: Cruise Control, Selenium, outros

Martin Fowler
Agile funciona!
Mas o que é Agile mesmo?
Modelos tradicionais de desenvolvimento
Características

- Previsibilidade
- BDUF (engenharia)
- Documentação abrangente
- Orientado a processo e a ferramentas
Quais os problemas desses modelos?
 Baixo índice de interação

Pouca comunicação entre pessoas trabalhando em diferentes níveis de abstração

 Baixo índice de interação

Ciclo de Feedback muito longo

Como sabemos se estamos indo no caminho certo?

 Baixo índice de interação
Ciclo de Feedback muito longo

Proteção contra o cliente

Qual o valor por trás disso tudo?

 Baixo índice de interação
Ciclo de Feedback muito longo
Proteção contra o cliente

Dificuldade de mudança

Change requests, change requests...

 Baixo índice de interação
Ciclo de Feedback muito longo
Proteção contra o cliente
Dificuldade de mudança

Previsibilidade a longo prazo

The Standish Group International, “The CHAOS Report ,”

 Baixo índice de interação
Ciclo de Feedback muito longo
Proteção contra o cliente
Dificuldade de mudança
Previsibilidade a longo prazo

Baixa motivação

Trate as pessoas como macaquinhos

Macaquinhos elas serão
Agile Manifesto
 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.
 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

 Foco no processo
X
Foco nos indivíduos
Linha de montagem
Aprendizado
Desenvolvimento de software
=
Atividade intelectual, criativa
 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente
 Design sessions
Whiteboard
Fotos
Documentação como ferramenta

Documentação como fim

 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Documento de requisitos
X
Comunicação constante
 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita,

valorizamos mais os itens à esquerda.
 Agile Manifesto

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a

fazerem o mesmo.

Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Baixo índice de interação
Ciclo de Feedback muito longo
Ou seja, mesmo havendo valor nos itens à direita,
Proteção contra o cliente
Dificuldade de mudança valorizamos mais os itens à esquerda.
Previsibilidade a longo prazo
Baixa motivação
Mudança de mentalidade
Adaptação

“Esvazie sua mente. Seja sem forma, como a água.

Você coloca água em uma caneca, ela se torna a
caneca. Você coloca água em uma garrafa, ela se torna
a garrafa… A água pode fluir ou pode destruir!
Seja água, meu amigo.” Bruce Lee
Pessoas

Confiança
Descendo o nível....
 O que é mais difícil em
programação?
●
Entender o problema
●
Estruturar suas ideias
●
Elaborar uma solução
●
Conhecer a plataforma de programação
●
Digitar o código
●
Testar o resultado
Programação em pares
Vantagens de programação em
pares
●
Eficiência (duas cabeças pensam melhor que uma)
●
Feedback instantâneo
●
Propriedade coletiva
●
Menor “fator caminhão”

Zaphod Beeblebrox
Testes?
Testes unitários
package calculator;

public class Calculator {

public float divide(float dividend, float divisor) {

if (divisor == 0) {
throw new CalculatorException("Can't divide by zero.");
}
return dividend / divisor;
}

// other methods....
}
package calculator;

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class CalculatorTests {

@Test
public void divideShouldReturnTheDivisionQuotient() {
float result = new Calculator().divide(56, 8);
assertEquals(7, result, 0.0);
}

@Test
public void divideShouldReturnDecimalPartsOfNonExactDivisions() throws Exception {
float result = new Calculator().divide(5, 2);
assertEquals(2.5, result, 0.0);
}

@Test(expected = CalculatorException.class)
public void divideShouldThrowACalculatorExceptionWhenDividingByZero() throws Exception {
new Calculator().divide(5, 0);
}
}
Test-driven development (TDD)
package calculator;

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class CalculatorTests {

@Test
public void divideShouldReturnTheDivisionQuotient() {
int result = new Calculator().divide(56, 8);
assertEquals(7, result);
}
}

package calculator;

public class Calculator {

public int divide(int n1, int n2) {

return n1 / n2;
}
}
package calculator;

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class CalculatorTests {

@Test
public void divideShouldReturnTheDivisionQuotient() {
float result = new Calculator().divide(56, 8);
assertEquals(7, result, 0.0);
}

@Test
public void divideShouldReturnDecimalPartsOfNonExactDivisions() throws Exception {
float result = new Calculator().divide(5, 2);
assertEquals(2.5, result, 0.0);
}
}
 Benefícios de TDD

●
Simplicidade
●
Modularização
●
Extensibilidade
●
Produtividade
Testes como documentação
def "project can't be deleted if it has expenses"() {
given:
currentUserIsProjectOwner()
projectHasExpenses()
projectHasNoActivities()

when:
tryToDeleteProject()

then:
projectIsNotDeleted()
}

// Taken from: http://www.aqris.com/display/DEV/2010/01/19/Testing+with+Spock

 Pessoas
Adaptação
Colaboração
Feedback
Software

Mentalidade
Mais perguntas?

Obrigado!!!!!

luizfar@gmail.com
lribeiro@thoughtworks.com
(51) 8105-1520