-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathagileAsBruceLee
220 lines (176 loc) · 7.06 KB
/
agileAsBruceLee
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
1.
Ágil como Bruce Lee
João Vortmann [email protected]
Luiz Ribeiro [email protected]
<data>
2.
Agenda
3.
O que é ser ágil?
4.
Usar Scrum? XP?
Reuniões diárias? (1)
TDD? (2, 4)
Integração contínua? (1, 2, 4)
Show-cases? (3)
Programação em pares? (1, 2)
Iterações? (1, 2, 3, 4)
Retrospectiva? (
5.
NÃO
6.
...necessariamente....
7.
Por que?
8.
Antes.... um outro 'por que':
Por que utilizamos essas práticas?
9.
Por que stand-ups?
- compartilhar informações relevantes
- auxiliar na identificação de problemas/impedimentos
- levantar pontos em que algum integrante pode ajudar o outro
Incentivar:
- Colaboração entre os indivíduos
(falar sobre experiencias)
10.
Por que TDD?
- testes servem como verificação de requisitos
- garante que após uma modificação, outros requisitos não são afetados
- consequentemente, facilitam mudanças de requisitos
- testes servem como documentação do projeto (le o teste pra entender o codigo/documentacao sempre atualizada)
Incentivar:
- Feedback curto (quebra, fixa, e já sabe que tá funfando)
- Qualidade do código (ou seja, do produto)
11.
Por que integração contínua?
- para informar rapidamente o time caso algo de errado (facilitando a sua resolução)
- facilitar a manunteção do código em um estado saudável
(falar de experiencias com colaboracao + ci - times distribuidos)
Incentivar:
- Feedback curto
- Colaboração
- Qualidade do código
Por que show-cases?
- Verificar quão alinhado o estado do produto está com o idealizado pelo cliente
- Direcionar o andamento futuro do desenvolvimento com a necessidade do cliente
Incentivar:
- Feedback curto
- Colaboração com o cliente
Colaboração entre os indivíduos:
Individuals and interactions over processes and tools
Colaboração com o cliente:
Customer collaboration over contract negotiation
Qualidade do código:
Valor do produto:
Working software over comprehensive documentation
Feedback curto:
Responding to change over following a plan
12.
Por que iteraçoes?
- ciclo de feedback curto
- alinhar o real objetivo do software utilizando o conhecimento adquirido durante o desenvolvimento
- ter algo entregavel em espacos definidos de tempo
Incentivar:
- Entrega de valor com frequencia (constante geralmente) / Ter software funcionando em intervalos constantes?
- Colaboracao com o cliente
- Responder a mudanca de ideias com mais rapidez
13.
Por que retrospectiva?
- analisar o andamento do desenvolvimento
- corrigir alguma decisao incorreta
- reforcar decisoes corretas
Incentivar:
- Qualidade do desenvolvimento
- Adaptar o processo para o melhor resultado possivel
14.
Apenas aplicando estas tecnicas te fazem agil?
Nao?
Por que?
15.
Apenas aplicar as tecnicas garantem sucesso?
16.
Práticas dependem do time, do projeto, do ambiente.
(experiencias)
- falar como eh um projeto agil
- por que um projeto da NASA nao faz sentido ser agil
- por que um projeto de consultoria faz mais sentido ser agil
- o que agil nesse contexto (acho que isso pode ficar mais pro fim, quem sabe)
17.
Paralelo com metodologias tradicionais.
[quem sabe colocar essa parte antes?]
18.
Como saber quando aplicar essas praticas?
Quando mudar as praticas?
!Entendendo as ideias.!
19.
E X E M P L O S
20.
I D E I A S
Entrega de valor com frequencia: (e em menos tempo) | Time to market | $$
- usando iteracoes com um tempo definido e que faca sentido para a estrutura do projeto
eh possivel entregar valor ao cliente de forma constante, reduzindo o time to market
e monetizando a aplicacao sem a necessidade dela contar todos os features previamente
pensados
21.
Comunicacao:
- com programacao em par tens a vantagem de code review on the fly, dois desenvolvedores
com background diferentes e com approaches diferentes, o que beneficia uma solucao
diferenciada geralmente
- um ambiente aberto propicia a comunicacao entre diferentes partes do time de
desenvolvimento, facilitando a resolucao de bloqueios (ai inclue-se as stand-ups)
e o compartilhamento de conhecimento sobre tecnologias, dominio da aplicacao ou
ate sobre uma solucao de para um problema recorrente
22.
Colaboracao:
- ter o cliente por perto como parte integrante do time beneficia um melhor entendimento
sobre o dominio e sobre a solucao desejada. Torna a atividade de desenvolvimento menos
burocratica, e a tomada de decisao muito mais agil e efetiva. A solucao encontrada
geralmente esta mais alinhada com a real necessidade do cliente, o que representa
o principal valor para o cliente.
23.
Atividade Intelectual e criativa:
- seres humanos sao seres criativos e nao funcionam como maquinas. Manter as pessoas 8h
na frente de um computador nao garante produdividade e nem qualidade. Eh mais efetivo
fazer com que elas entendam o valor de seu trabalho e produzam o maximo com o maximo
de concentracao, sem a necessidade de um regime industrial. Um ambiente agradavel e
livre de arcadismos colabora fortemente nesse quesito.
24.
Qualidade:
- qualidade de codigo e produto final eh um ponto muito relativo. O que faz geralmente
uma abordagem agil ser mais efetiva eh o que se entende como qualidade. Qualidade
nesse caso eh ter um produto de facil manutencao, com a menor quantidade de bugs
(e com sua rapida resolucao), e, o mais importante, o mais proximo do que o cliente
realmente deseja. Praticas como iteracoes e manter o cliente proximo melhoram a
qualidade fortemente nesse sentido.
25.
Processo adaptativo:
- o maior valor dos metodos ditos ageis eh a abordagem adaptativa que tomam. Responder
a mudanca de requesitos durante o desenvolvimento eh fundamental para chegar a um
produto final de maior qualidade. Mudancas de requesitos entende-se aqui como um
entendimento maior por parte do cliente sobre a solucao desejada, sobre a capacidade
das tecnologias utilizadas, da solucao propostas pelo consultor e assim por diante.
Uma abordagem agil tenta minimizar o trabalho necessario para se realizar uma mudanca
em relacao a solucao inicial, deixando o processo de desenvolvimento leve e com
a maior possibilidade de sucesso (atingir as expectativa$$$ do cliente)
26.
Feedback curto | Change change change
- o feedback curto eh um ponto relevante em varios niveis em uma abordagem agil.
Pode-se ver o feedback curto durante a programacao em par, onde um dos integrantes
detecta um erro que o outro integrante nao havia detectado, ou propoe uma solucao
diferente para o problema. Com a IC, onde todo o time fica siente do estado do codigo
quando da introducao de algum bug e age em seguida para soluciona-lo. E no nivel
entre o cliente e o time de desenvolvimento, onde o cliente pode expor suas ideias
sobre a solucao desejada, obter ideias do time de desenvolvimento e vice-versa.
Novamente entrando em cena a ideia de adaptacao e alinhamento da melhor solucao
possivel e o menor time to market $$$$.
27.
E o que eh o mais importante de tudo?
O que eh mais fundamental?
!Adaptar!
28.
Be water, my friend.
---
Falar da técnica e alinhar com um dos itens do manifesto.
Puxar ideias do manifesto a partir de práticas e detalhá-las.
Uma vez as ideias in place, times podem mudar as práticas.