1. Agradecimentos
Primeiramente gostaria de agradecer o convite e a presença de todos vocês. Estou muito
contente de estar aqui depois de um bom tempo. Sou formando da PUC da turma de
2002.
Quem Sou eu
Formado na PUC em 2002
Desenvolvedor Sênior da Gonow a quase 3 anos. (Contratando)
Evangelista de métodos ágeis desde 2007.
Eventos DevInSampa, Fatec
Falando em palestras, vai ocorrer dia 3 e 4 de novembro agora o RubyConf 2011. Local
para aprender, abrir a mente, fazer networking...Hoje temos muita informação na internet
e conteúdos e palestras temos acesso, porém a presença em eventos é muito importante
para formar uma rede de relacionamentos profissionais.
Por que ser ágil?
Por que eu preciso ser ágil? Preciso realmente aplicar essas técnicas que falam? Não vou
responder, quero que reflitam nessa apresentação.
Quem aqui gosta de trabalhar no feriado? Temos um feriado agora. Levanta a mão quem
gosta de trabalhar de sábados e domingos? Quem gosta de fazer 14 horas de trabalho
por dia?
Não estou dizendo que se vocês forem agilistas não vão trabalhar até mais tarde, não vão
trabalhar nos feriados. Estou dizendo que existem possibilidades que isso seja evitado
com a adoção de padrões e técnicas.
O que é ser ágil?
Ser ágil não é fazer rápido, é ser consistente. É pensar no futuro como um investimento. É
usar melhor o tempo. É inspecionar, adaptar, receber feedback mais cedo. Metáfora:
“Quem já comeu um boi inteiro? Eu já, mas não de uma vez e sim iterativamente”
Inspire-se em alguém
Antes de falar sobre métodos ágeis eu gostaria que vocês pensassem em uma pessoa
que inspira vocês. Temos vários exemplos de líderes, inovadores, pessoas bem
sucedidas. Exemplos no esporte como Bernardinho do volei, um líder que sempre tem a
equipe na mão. Exemplos como Dalai Lama, Chico Xavier.
Jobs
Steve Jobs nasceu de uma família pobre e foi levado para adoção. Seus pais não tinham
dinheiro para pagar-lhe uma faculdade, então concordaram em adotar apenas para uma
família que tivesse condições de pagar a faculdade. Porém aos 25 anos Jobs já tinha
sucesso profissional e tornou-se rico. Poderia ter se conformado com isso pois dinheiro
não era mais problema, porém continuava buscando algo a mais. Fazia isso não pelo
dinheiro mas porque amava o que fazia. Já sabia exatamente o que queria ver escrito no
seu epitáfio.
Você ama o que faz?

2. Não estou dizendo que não se pode conseguir estabilidade financeira sem fazer o que
gosta. Estou dizendo que nunca será como Steve Jobs se não fizer o que ama. Portanto,
se ainda não sabe o que gosta, continue procurando.
Manifesto Ágil
Tudo começou quando alguns profissionais líderes e respeitados (o qual deveriamos
conhecer e seguir) se reuniram para pensar o porquê de tantos fracassos na indústria de
desenvolvimento de software. Porque tanto software sendo entregue sem alguma
qualidade. Porque tão difícil de evoluir um projeto e o motivo de tantos atrasos de
projetos. Então surgiu o manifesto ágil.
Métodos Ágeis
Extreme Programming, Scrum, Kanban, Lean Thinking, FDD
Saia da Sona de conforto!
Ok, mas por que ainda é tão difícil, nos dias de hoje, aplicar algumas técnicas ágeis?
Porque ela mexe com a zona de conforto das pessoas. Mexe com a sua zona de conforto.
E isso é bom para você, bom para a empresa. Comodidade não é bom. Se achar que está
numa zona de conforto se incomode. Veja o que você pode agregar para seu trabalho
senão outros podem fazer isso por você.
Extreme Programming
Um divisor de águas na minha carreira foi quando conheci Vinícius Teles, autor desse livro
que é referência na literatura portuguesa. Isso me ajudou a ser um tomador de decisões e
me tornar um melhor profissional.
Esse livro ensina técnicas para atingir esses 5 valores: Comunicação, Respeito,
Simplicidade, Coragem e Feedback.
Segredo da produtividade
Como fazer para se tornar um desenvolvedor produtivo? Como fazer para cumprir metas,
prazos, entregar valores para o cliente?
Ah já sei, estão falando de frameworks novos para fazer uma aplicação web. Existem
livros de desenvolvimento ágil com a tecnologia tal. bibiotecas para tudo.
Resposta: Não. É claro que o domínio de uma tecnologia ajuda, mas o grande segredo da
produtividade é a noção de negociação. É ter um executável o mais rápido possível. É
lançar um produto antes dos concorrentes. É ter ROI.
Exemplo:
Sistema de autenticação. Você precisa desenvolver um complexo sistema de login. Além
da autenticação existem grupos com permissões diferentes de autorização. E também é
necessário aplicar regras de segurança no login. Além disso você tem um prazo apertado
para entregar a funcionalidade. Normalmente nesses casos o desenvolvedor já separa o
telefone da pizzaria e aproxima o puff da empresa pra perto. Cansado mentalmente a
chance de inserção de bugs aumenta e as boas práticas vão para o ralo.
Vem do profissional a capacidade de negociar um escopo para que algo com boa
qualidade possa ser entregue dentro do prazo. Ele poderia entregar uma primeira versão
apenas com a autenticação e aplicar regras de segurança. Como ainda não existe a
funcionalidade de grupos, o sistema não seria aberto para todos, mas alguns já poderiam
testar a aplicação e dar feedback sobre o sistema, que é algo importantíssimo para os
desenvolvedores.

3. Faça meio produto, não um produto “meia-boca”
Variáveis de um projeto
Tempo, Custo e Escopo. Não se pode manter fixo as três num projeto, senão o nome não
seria variáveis e sim constantes. Então se tiver que manter o escopo, é necessário mexer
no custo ou no tempo e assim por diante.
“Uma mulher faz um filho em 9 meses, mas 9 mulheres não fazem um filho em um
mês”
Prática (TDD)
Vou agora um pouquinho para o lado técnico porque é o que alguns esperam. Pretendo
começar com um exemplo simples mas já cair num assunto bastante comentado nos
últimos meses.
O TDD é uma técnica do XP que consiste em fazer o teste antes da implementação. O
desenvolvimento é guiado pelos testes e o ciclo consiste em vermelho, verde e
refactoring.
ATTD
Uma variância disso é o ATDD (Acceptance Test Driven Development), que é escrever os
testes de aceitação antes e começar a implementar as estórias no nível de negócio.
Estórias são descrições de um problema e cenários são exemplos de uso do sistema.
Cenários podem ser critérios de aceite de uma história.
Agile Testing
Após isso, procuro aprimorar minhas técnicas de teste lendo o livro Agile Testing e vejo
que além dos testes automatizados, posso tirar métricas do meu código, preciso gerenciar
o débito técnico, aprender a usar mocks, stubs, etc.
Isso é o suficiente? Não.
Integração Contínua
Preciso colocar todos meus testes num servidor separado de forma que a cada integração
de código novo, sejam executados todos meus testes unitários e de aceitação. Dessa
forma o time tem o feedback rápido se alguma nova funcionalidade quebrou uma regra
antiga do sistema.
Estou tranquilo agora? Não.
Jobs
Imaginem Steve Jobs quando inventou o primeiro computador pessoal e propôs para a
IBM vender. A IBM disse: Imagina, as pessoas nunca comprariam isso. Elas não tem
dinheiro para comprar um computador pessoal. Stege Jobs: Mas se vendermos por muito
mais barato e em grande quantidade, podemos ter o retorno no futuro. Sem o acordo da
IBM, Jobs montou então a empresa Macintosh.
Deploy em produção
Imaginem agora vocês após todo trabalho com qualidade, testes automatizados,
cobertura 100%, métricas, chegam para a equipe de infraestrutura e pedem um deploy.

4. Infra: Ok, mas para isso você tem que abrir um chamado e em até 30 dias atenderemos
seu pedido, sendo que depois disso temos 40 horas para te responder por email se o
deploy foi executado com sucesso, ou não.
Então você corre de volta pra Amazon procurando desesperadamente o livro com o título
“Como ganhar dinheiro fácil e rápido. Em três passos”. Você abre o livro e lê: Primeiro
passo, ganhe dinheiro. Agora dê três passos.
Devops - Release-it
1 click deploy já não basta
Flikr, Facebook, Google