O documento discute práticas ágeis e fornece dicas para implementá-las. Em particular, aborda tópicos como user stories, arquitetura ágil, simplicidade, design evolutivo, TDD e code review.
1. Praticas Ageis
Agile dentro de você!
Felipe Rodrigues de Almeida
blog.fratech.net 1
2. Who we are?
Felipe Rodrigues de Almeida
Arquiteto de Sistemas responsável por implantação de processos
arquiteturais em clientes da Fratech.
blog.fratech.net 2
fratech
3. PRáticas ágeis
Por quê?
Neste material, Manoel e eu buscamos passar aos participantes alguns
princípios por trás das práticas. Muitos desses benefícios já foram vistos
ou discutidos por alguns de vocês sob outros títulos, eu sei, não é
novidade.
Mas então porque falar sobre essas técnicas? Porque preferimos
apresentar a verdadeira lógica por trás das técnicas. Mostraremos aqui
quais os conceitos que motivam as práticas mais comuns do mundo
ágil. E finalmente porque ninguém o fez ainda. (Não no brasil e em
português).
blog.fratech.net 3
fratech
4. para pensar!
Não importa o quão longe você foi pela estrada errada,
volte. (Provérbio Turco)
blog.fratech.net 4
fratech
5. QUal a sua agilidade?
Tartaruga
Lebre
blog.fratech.net 5
fratech
7. O que é Agile? (Visão Geral)
Habilidade de criar e responder à mudanças com eficiência e eficácia
dentro de ambientes de negócios turbulentos.
Habilidade de balancear flexibilidade e estabilidade. (Jim Highsmith,
2002)
blog.fratech.net 7
fratech
8. alimentando a agilidade
Um projeto ágil requer continuamente práticas que não fazem parte do
desenvolvimento por si só, mas que são extremamente importantes para
a saúde do time.
Agile requer manutenção. Mas como nos manter atualizados o tempo
todo?
Mesmo se você está no caminho certo, você não chegará a lugar
algum se ficar sentado. (Will Rogers)
blog.fratech.net 8
fratech
9. alimentando a agilidade
Mantendo-se atualizado
Algumas dicas sobre manter-se atualizado:
x Aprenda iterativamente e incrementalmente
x Conheça a ultima buzz
x Participe de grupos de usuários
x Participe de workshops e palestras
x Leia de forma voráz
Não há nada permanente exceto a mudança. (Heraclitus)
blog.fratech.net 9
fratech
10. alimentando a agilidade
Cuidado
Algumas dicas sobre manter-se atualizado:
x Muitas idéias nunca tornam-se tecnologia úteis
x Você não pode ser expert em tudo
x Entenda porque uma nova tecnologia é necessária
x Fuja do impulso de converter sua aplicação para a última tecnologia, framework
ou linguagem, apenas para aprender
blog.fratech.net 10
fratech
11. alimentando a agilidade
Outras dicas úteis
x Saiba quando “desaprender”
Velhos hábitos podem atrapalhar o desempenho e o aprendizado
x Pergunte até você entender
Não aceite as explicações somente porque alguém muito bom falou. Questione.
“Porque?” é uma ótima pergunta.
x Invista no seu time
Compartilhe suas experiências e conhecimentos com sua equipe. Isso ajuda a nivelar
o ambiente criando um padrão. Aceite que os outros compartilhem também. Absorva
tudo que for interessante.
blog.fratech.net 11
fratech
13. postura em um ambiente ágil
Liberdade é ágil
Normalmente, empresas que investem em agile oferecem liberdade para
seus empregados. Não deixe que isso atrapalhe sua produção.
x Disciplina
x Honestidade
x Transparência
x Humildade
x Dedicação
x Bom Senso
O que seu chefe espera de você?
blog.fratech.net 13
fratech
14. confiança
Confiança traz agilidade
As práticas ágeis exigem um alto grau de confiança no time. É preciso
confiar para que o processo seja agradável e não burocrático.
Além de confiar nos outros garanta que você também é confiável. Essa
garantia é facilitada por uma postura aderente à agilidade.
blog.fratech.net 14
fratech
15. Gerenciado ROI com Business Value
Business Value será uma moeda de troca durante o projeto e o cliente
empresta um determinado valor dessa moeda para a equipe e esta por
sua vez, terá que devolver o valor correspondente em forma de software,
ou seja, é uma dívida que a equipe assume com o cliente e que deverá
ser amortizada a cada ciclo (Sprint), até que a mesma seja totalmente
liquidada (zerada).
blog.fratech.net 15
fratech
16. o que é uma user story
Descreve uma funcionalidade que deve fornecer valor para o cliente;
Independent
Negotiable
Valuable to users or costumers
INVEST estimatable
Small
testable
blog.fratech.net 16
fratech
17. user story e épicos
User Story User Story
Épico User Story User Story
User Story User Story
- INVeSt + INVeSt
blog.fratech.net 17
fratech
18. user story e temas
Tema
User Story User Story
User Story User Story
User Story User Story
blog.fratech.net 18
fratech
19. o que o cliente vê?
Analise o projeto pelos olhos do cliente
Como desenvolvedores não somos acostumados a pensar em questões
de negócio. Mude isso em você. Tudo que o cliente precisa é de pessoas
que pensem em suas necessidades. Veja o que o cliente vê.
O que seu cliente espera de você?
blog.fratech.net 19
fratech
22. Repensando a qualidade do Software
O que é projeto de software com
qualidade?
Software entregue no prazo?
Software entregue no custo?
Software entregue de acordo com
o escopo?
Software entregue sem defeitos?
Um novo conceito:
Software = rOI
blog.fratech.net 22
fratech
24. trabalhando para entregar
O cliente só quer output
O único objetivo de um projeto de software é produzir software. Dessa
forma a produção de software não pode ser deixada de lado para satisfazer
desejos pessoais ou profissionais dos envolvidos.
Todos devem trabalhar para entregar software mais rápido e com mais
qualidade.
blog.fratech.net 24
fratech
27. arquitetura ágil
O Papel do Arquiteto
Num time ágil podemos ter a impressão de não precisar de arquitetos,
afinal o design é evolutivo e cada um é co-responsável pelo design.
A verdade é que é necessário ter um arquiteto e que pode ser resumido
na seguinte declaração de Martin Fowller:
“...o mais experiente e completo membro do time, que ensina outros
membros e sempre está lá para as coisas mais complicadas.”
blog.fratech.net 27
fratech
28. arquitetura ágil
O Papel do Arquiteto
Dessa forma podemos concluir algumas das tarefas de um arquiteto em
um time ágil.
x Entender os requisitos (User Stories, Itens de Backlog, etc...)
x Formular o Design Geral do sistema
x Disseminar os conceitos da arquitetura
x Oferecer suporte aos desenvolvedores
x Verificar a implementação
Mais informação em http://www.agilearchitect.org/agile/role.htm
blog.fratech.net 28
fratech
30. Simplicidade
evite o complexo de
“cérebro”
blog.fratech.net 30
fratech
31. Simplicidade
Conceito KISS
Keep It Simple, Stupid!
blog.fratech.net 31
fratech
32. como aumentar a simplicidade
Kent Beck, na segunda edição do Livro Extreme Programming Explained abordou algumas
sugestões interessantes para garantir do desenvolvimento de um sofware simples.
apropriado para o público alvo
Não importa o brilhantismo ou “elegância” de um software, se as pessoas que irão trabalhar com
ele (usuários ou desenvolvedores) não o compreendem, então ele não é simples para elas.
comunicativo
Os elementos de um software deverá favorecer a boa comunicação com os futuros leitores.
fatorado
Duplicação de lógica ou estrutura, dificultam o etendimento e a modificação do código.
Mínimo
Devido às 3 características acima, o sofware deverá ter um menor número possível de elementos,
pois assim, teremos menos “coisas” a serem testadas, documentadas e comunicadas.
blog.fratech.net 32
fratech
34. faça seu código auto-explicativo
blog.fratech.net 34
fratech
35. Escrevendo Código Coeso
Guarda Roupa, Piano, Cama
Fuja da patente do Guarda Roupa, Piano, Cama, mas lembre-se uma caixa
de fibra de algodão não ajuda muito quando você precisa de uma meia.
blog.fratech.net 35
fratech
36. Design Evolutivo
Evolução do aprendizado
em forma de baby step’s
blog.fratech.net 36
fratech
37. Evolução iterativa de um produto
Iteração 1
PreGame (Concepção e Planejamento)
Aprendizagem Incremento do Produto
Necessidade Visão
Iteração 2 Iteração 3
Aprendizagem Incremento do Produto Aprendizagem Incremento do Produto
blog.fratech.net 37
fratech
38. TDD - Test Driven Development
blog.fratech.net 38
fratech
39. TDD - Test Driven Development
E x emplo de P roduc t B ac k L og c om C as o de T es te
Área Atividade Item B us ines s V alue C as o de T es te
- Ao informar o ano letivo,
G erenciamento
S ec. Acadêmica C ontrolar os curs os dis poníveis pela ins tituição 100 mos trar os curs os
de curs os
dis poníveis ;
- Ao informar o ano letivo,
mos trar as vagas
dis poníveis por curs o;
G erenciamento
S ec. Acadêmica Definir as vagas dis poníveis por curs os 90
de curs os
- Ao informar um curs o,
informar quais vagas es tão
dis poníveis no ano atual.
blog.fratech.net 39
fratech
40. REFACTORING
Martin Fowler
Aplicação: Quando apropriada, pois sua necessidade diminui quando o
design e o código estão padronizados e simples.
Benefícios: Códigos mais simples, legíveis e com melhor qualidade.
Exemplos: Extração de variáveis locais, Alteração de nomes, Extração de
métodos, Extração de classes e interfaces.
blog.fratech.net 40
fratech
41. Conversas Cara a Cara
Crie condições para FeedBack
Quebre as barreiras
Diminua os intermediários
blog.fratech.net 41
fratech
42. Pensando em Negócio
Ter um entedimento o suficientemente alinhado ao
Ter toda equipe, alinhada aos objetivos da
negócio da empresa
empresa (cliente e/ou fornecedor).
blog.fratech.net 42
fratech
44. Code review
Code Review Checklist
Não há uma regra definitiva para o que devemos procurar num code
review, porém há algumas sugestões:
x Você pode ler e entender o código?
x Há algum erro óbvio?
x Há algum efeito colateral que atinja outras partes da aplicação?
x Há alguma duplicidade no código (dentro do código mesmo ou com
outras partes do sistema)?
x Há alguma melhora ou refactoring que possa melhorar o código?
blog.fratech.net 44
fratech
45. Pair Programming
Escolha dos pares
Reunião em pé Programação em par
blog.fratech.net 45
fratech
47. construtivismo
Critique idéias, não pessoas
O sucesso de um projeto ágil é altamente acoplado à harmonia entre os
integrantes do time. Processos ágeis são muito focados em reuniões e
interações face-a-face. Dessa forma, é de extrema importância não criticar
as pessoas e sim as idéias propostas, quando aplicável.
Há 3 maneiras de se criticar uma idéia:
1. Você é estúpido? Não vai dar certo. Isso é obvio.
2. Essa idéia é estúpida! Não vai dar certo. Isso é obvio.
3. Ei, como você pretende resolver esse problema aqui com essa idéia?
blog.fratech.net 47
fratech