Este documento lista diversas práticas ágeis utilizadas no desenvolvimento de software, incluindo: planejamento de produto e requisitos, metodologias ágeis como Scrum e Kanban, práticas de desenvolvimento como pair programming e TDD, e ferramentas de gestão como daily meetings e retrospectivas.

1. Lista de Práticas Ágeis
• Pós Engenharia de Software Ágil
• Prof. Edgard Davidson
• Aluno: Julio Cezar da Silva
• UNA

2. Product Vision

3. Product Backlog

4. User Stories

5. Uses Cases

6. Usage Scenario

7. Personas

8. Planning Poker

9. Requirement Prioritization

10. User Story Mapping

11. Lean Canvas

12. Spike Solutions

13. Domain Driven Development

14. Design Evolutivo

15. CRC

16. DbC
public class Cor{
public int Vermelho { get; private set; }
public Cor(int pVermelho, int pVerde, int pAzul) {
this.Vermelho = pVermelho;
// Configurar as outras propriedades...
}
public void AdicionarVermelho(int pValor) {
// Aqui estamos garantindo que ao final da execução desse método, a
//propriedade Vermelho deverá respeitar o limite de 255;
Contract.Ensures(this.Vermelho <= 255);
this.Vermelho += pValor;
}
}

17. Metáfora
• “Para facilitar a criação de um design simples,
a equipe de desenvolvimento utiliza
metáforas, já que elas têm o poder de
transmitir ideias complexas de forma simples,
através de uma linguagem comum que é
estabelecida entre a equipe de
desenvolvimento e o cliente.”
• Fonte: Extreme Programming – Vinícius Manhães Teles

18. Coding Standard
“Para que todos os desenvolvedores possam manipular qualquer
parte do software de forma rápida, a equipe estabelece padrões de
codificação, que servem também para tornar o sistema mais
homogêneo e permitir que qualquer manutenção futura seja
efetuada mais rápidamente.”
Fonte: Extreme Programming – Vinícius Manhães Teles

19. TDD

20. BDD
• “Uma técnica de desenvolvimento ágil que visa integrar regras de negócios com
linguagem de programação”
public class ComportamentoDoControladorDeJanela {
@Test
public void deveFecharJanelas() {
// Dado que
ControladorDeJanela controlador = new ControladorDeJanela("Meu Quadro");
Quadro quadro = new Quadro();
//Quando
controlador.fecharJanelas();
// Então
garantirQue(!frame.estaAparecendo());
}
}

21. Pair-Programming

22. Refactoring

23. Código coletivo

24. Build Automático

25. Integração Contínua
• “Integração Contínua é uma pratica de
desenvolvimento de software onde os membros de um
time integram seu trabalho frequentemente, geralmente
cada pessoa integra pelo menos diariamente –
podendo haver multiplas integrações por dia. Cada
integração é verificada por um build automatizado
(incluindo testes) para detectar erros de integração o
mais rápido possível. Muitos times acham que essa
abordagem leva a uma significante redução nos
problemas de integração e permite que um time
desenvolva software coeso mais rapidamente.”
Martin Fowler

26. Peer Reviews
• Na utilização da programação em par do XP a
técnica de revisão é aplicada todo o tempo da
programação já que enquanto um digita o outro
vai verificando o código, em ambientes
burocráticos que não têm a programação em par,
poderia ser utilizado os testes unitários e ao ser
alterado o código ser verificado através dos testes
se nenhum bug foi introduzido.

27. Controle de Versão

28. Entregas Frequentes
• Ágeis “nossa maior prioridade é satisfazer o cliente
através da entrega contínua e desde cedo de
software com valor” e “entregar frequentemente
software em funcionamento, desde a cada duas
semanas até a cada dois meses, com uma
preferência por prazos mais curtos” (FOWLER & HIGHSMITH, 2001)

29. Clean Code

30. Teste Unitário

31. Teste Fumaça
• O Termo originou-se de testes de hardware quando
uma parte era corrigida ou atualizada simplesmente
ligava o hardware e se o mesmo não der fumaça
significa que passou nos testes. Em software consiste
em um teste rápido, executando as principais
funcionalidades do sistema, sem se preocupar com
as condições de erro.

32. Testes de Sistemas

33. Teste Exploratório
• Segundo o livro "Base de Conhecimento de Teste de
Software", Teste Exploratório "é indicado quando existe
pouca documentação para orientar os testes ou
quando o prazo é tão curto que não é possível preparar
um teste mais formal. É um teste executado a partir da
experiência e da intuição do testador"

34. Testes de aceitação

35. Fixed Sprints

36. Release Planning
• O Release Plan deverá abordar:
• A quantidade e a duração dos Sprints
• Quantas pessoas ou times deverão participar do projeto
• O número de Releases
• O valor a ser entregue em cada Release
• A data de liberação do(s) Release(s)
• As principais informações para o Release Planning são:
• A priorização dos Product Backlogs
• A estimativa da velocidade
• O Product Owner deve atender as datas importantes (time-to-market) impostas pelo mercado.

37. Iteration Planning
• A meta do planejamento da iteração é estabelecer
objetivos de alto nível do que será realizado durante
uma iteração, produzir um plano suficientemente
detalhado, indicando quem deve fazer o que para
realizar os objetivos e definir como avaliar se o que
deveria ser realizado foi feito.

38. Sprint backlog

39. Task Board

40. WIP Limits
• No Kanban, as tarefas em execução devem ser
explicitamente limitadas de modo a não haver
muitas tarefas sendo executadas ao mesmo tempo,
no Scrum não existe explicitamente esse limite, mas
o mesmo é implícito quando é limitada a
quantidade de pontos que a equipe consegue
entregar por sprint.

41. Class of Service

42. Lead Time
• lead time is the time between the initiation and
delivery of a work item.

43. Definition of done

44. Daily Stand-up Meeting

45. Velocity

46. Sprint Review
• Ao final de cada Sprint, uma Reunião Sprint Review
é realizada. Durante esta reunião, o Scrum Team
apresenta o que foi realizado durante o Sprint.
Tipicamente, esta apresentação é feita na forma de
uma demonstração das novas funcionalidades.
Fonte: http://epf.eclipse.org/wikis/scrumpt/Scrum/tasks/sprint_review_meeting_8735340C.html

47. Mapa de Cadeia de Valor
• Os mapas da cadeia de valor são uma forma
popular de detectar desperdícios nos processos de
uma empresa — passos que não adicionam valor
ao produto final.
Fonte: http://office.microsoft.com/pt-pt/visio-help/criar-um-mapa-da-cadeia-de-valor-
HA010113024.aspx

48. Root Cause Analysis
• A Análise de Causa Raiz, também conhecida como
RCA (Root Cause Analysis) é uma maneira de
identificar as causas de um problema, afinal os
problemas são melhores resolvidos ao tentar corrigir
ou eliminar as suas causas.

49. Burn Down Chart
• A burn down chart is a graphical representation of
work left to do versus time.

50. Cumulative Flow Chart
• Um Diagrama de fluxo cumulativo (CFD) é uma
área gráfica que mostra o progresso do trabalho de
um produto, versão ou Sprint. O eixo horizontal em
um CFD indica o tempo, e o eixo vertical indica os
cards (tarefas). Cada área colorida equivale o
gráfico para o status do workflow.

51. Gestão a Vista
• A gestão à vista tem como objetivo disponibilizar as informações
necessárias de uma forma simples e de fácil assimilação, buscando
tornar mais fácil o trabalho diário e também a busca pela melhoria
da qualidade. Ela torna possível a divulgação de informações para
um maior número de pessoas simultaneamente e ajuda a
estabelecer a prática de compartilhamento do conhecimento
como parte da cultura organizacional.

52. Retrospectiva
• Retrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de
desenvolvimento de software parem para pensar no trabalho que vem realizando e questionem
o que pode se melhorado. É uma excelente ferramenta para que o famoso ciclo PDCA (Plan /
Do / Check/ Act) possa ser aplicado. O método ágil Scrum sugere que as reuniões de
retrospectiva aconteçam no final da iteração (sprint) e que a equipe se faça duas perguntas
básicas:
o O que está indo bem?
o O que pode ser melhorado?
• Alguns preferem perguntar:
• O que devemos parar de fazer?
o O que devemos continuar fazendo?
o O que devemos começar a fazer?
• No fim das contas o que realmente importa é que a reunião tenha como resultado ações a
serem tomadas pela equipe para que a melhoria continua seja aplicada, e que na próxima
retrospectiva, a equipe seja melhor do que era na última.

53. Retrospectiva

54. Backlog de melhorias
• O Backlog é nada mais nada menos do que os
requisitos do produto que precisa ser entregue, bem
como todo o entendimento necessário para se
atender aos requisitos, produzir funcionalidades e
por fim entregar um produto.
• Em resumo é uma lista de todas as características,
funções, tecnologias, melhorias e correções que
constituem a versão futura do produto.

55. Small Team

56. Cross-Functional Team
• Times podem ser funcionais (ex: um tipo somente
de sys admins) ou cross-funcionais (um time formado
por desenvolvedores, designers e testadores)

57. Equipes Auto Organizadas
• Essas equipes caracterizam-se por 3 condições:
• Autonomia: após receberem uma missão com objetivos claramente definidos, o time
está livre para definir sua própria direção. A alta gerência limita-se a dar orientação,
recursos e apoio moral;
• Auto-transcedência: a equipe busca continuamente estender seus limites. Partem da
diretriz recebida da alta gerência, estabelecem objetivos iniciais, elevando-os
constantemente durante o processo de desenvolvimento. Ao perseguir objetivos
aparentemente contraditórios a equipe supera seu "status quo" e faz descobertas
incríveis; e
• Fertilização cruzada: uma equipe multidisciplinar, com variados padrões de
comportamento, processos conhecidos e especialização funcional conduz o
desenvolvimento do novo produto. A referida fertilização acontece na iteração entre
essas pessoas. Ao compartilharem um mesmo ambiente de trabalho o processo de
transferência de conhecimento entre seus membros acontece naturalmente,
caracterizando o termo fertilização cruzada.

58. Common Workspace

59. Product Owner

60. Scrum Master
• A missão do Scrum Master é facilitar o dia-a-dia do Time,
removendo tudo aquilo que está atrapalhando o seu progresso.
É garantir que o time siga os valores e práticas do Scrum,
protegendo para que ele não se comprometa excessivamente
com aquilo que é capaz de executar dentro de um Sprint.
É aprimorar a produtividade do time da melhor maneira possível.
!=

61. Sustainable pace
• Trabalhar com qualidade, buscando ter ritmo de
trabalho saudável (40 horas/semana, 8 horas/dia),
sem horas extras. Horas extras são permitidas
quando trouxerem produtividade para a execução
do projeto. Outra prática que se verifica neste
processo é a prática de trabalho energizado, onde
se busca trabalho motivado sempre. Para isto o
ambiente de trabalho e a motivação da equipe
devem estar sempre em harmonia.

62. Move People Around
• A ideia é não deixa a pessoa fazendo sempre a
mesma coisa ou sempre a mesma dupla, o ideal é
que o código seja coletivo e todos mexam em tudo
de modo que na necessidade não tenha somente
um responsável por determinada funcionalidade.

63. Scrum Escalado

64. Communities of Practices

65. Coding Dojo

66. Clube do Livro

67. Palestra da Equipe
para a Equipe
• A ideia é a própria equipe repassar o que está
aprendendo, no blog abaixo eles foram além,
gravam as apresentações e disponibilizam para a
comunidade.
• http://blog.bluesoft.com.br/

68. Biblioteca a Disposição

69. Participação em Eventos
O Agile Brazil 2012 acontecerá em São Paulo de 3 a 7 de setembro.

70. Contratação com participação do
time
• O time deve participar da contratação de novos
colaboradores.

71. Feedback 360º
• Consiste na equipe avaliando a equipe frente a
frente.

72. One-on-ones meetings
• É uma reunião do gerente com cada um dos
colaboradores, individualmente.

73. Índice da Felicidade
• A tendência, que põe a praticidade dos resultados
financeiros em segundo plano e a complexa
subjetividade do bem-estar social em primeiro.

74. Definição de Metas
• A definição de metas é essencial no processo
dentro das empresas nos dias de hoje. É através
deste posicionamento que se estabelece o esforço
para implementação das condições necessárias
para o resultado dentro de um prazo estipulado.

75. Gemba Walks
• Já teve a ligeira impressão de que os engenheiros
que projetam os ônibus parecem que nunca
andaram de ônibus? Então, Gemba Walks é o
processo de imersão naquilo que se está disposto a
fazer ou mudar, seria “o cliente estar dentro do taxi
quando do engarrafamento.” a visão é diferente
dependendo de como se vê.

76. Delegation Poker

77. Authority Board

78. ROTI
• Is a quick and easy method to gauge the time spent
on meetings or workshops, and to improve their
effectiveness.

79. Resolução de Problemas com A3

80. Hackathon
• Hackathon é uma maratona de programação, onde os
colaboradores da empresa tiram o dia (ou viram uma noite), para
trabalharem em suas próprias ideias que possam vir a agregar valor
ao produto da empresa.
• É o dia que você deixa de lado o seu trabalho do dia-a-dia para
colocar em prática algo novo ou algo que você sempre pensou
que podia ser legal adicionar ao produto.
• O objetivo é que ao final da maratona, todos apresentem algo
implementado para que a equipe dê feedback e decida se vale a
pena dar continuidade em sua ideia.

81. SlackTime
• É uma prática de incluir em cada plano uma série
de tarefas ou histórias de usuários que podem ser
descartados se o time ficar sem tempo.

82. Impedimentos Visíveis
• Impedimento é qualquer coisa que atrapalhe um
membro da equipe de executar o trabalho. Os
impedimentos podem ser identificados nas reuniões
diárias, onde cada membro da equipe tem a
oportunidade de comunicar o Scrum Master do
impedimento existente. O Scrum Master é
responsável pela solução dos impedimentos.