Rápido ou Ágil? (AgileBrazil 2010)
•
11 gefällt mir•2,278 views
Palestra feita no AgileBrazil 2010 em Porto Alegre, Junho de 2010. http://www.agilebrazil.com/2010/pt/index.html
![Rápido ou ágil? Giovanni Bassi [email_address]](https://image.slidesharecdn.com/agilebrazil2010-rpidoougil-100625133922-phpapp01/85/Rapido-ou-Agil-AgileBrazil-2010-1-320.jpg)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (19)
Ähnlich wie Rápido ou Ágil? (AgileBrazil 2010)
Ähnlich wie Rápido ou Ágil? (AgileBrazil 2010) (20)
Mehr von Giovanni Bassi
Mehr von Giovanni Bassi (20)
Rápido ou Ágil? (AgileBrazil 2010)
- 1. Rápido ou ágil? Giovanni Bassi [email_address]
- 4. Sem planejamento Sem documentação Só escreve o código!
- 8. Agil == Rápido? Como fazemos para ir mais rápido atualmente Quais as consequências? Podemos melhorar? Agenda
- 11. "Que se move depressa, com muita velocidade" Rápido Fonte: Dicionário Aulete: http://aulete.uol.com.br
- 12. “ Que se move ou age com muita facilidade, destreza e rapidez” Ágil Fonte: Dicionário Aulete: http://aulete.uol.com.br
- 13. Rápido Ágil
- 23. Chaos Report Desafiado: atrasou, custou mais, ou entregou menos Fracasso: cancelado, ou entregue e nunca usado Fonte: Standish Group
- 24. Uso de Funcionalidades 64% Nunca ou Raramente Utilizadas 20% do Software é Realmente Útil Fonte: Standish Group, 2002
- 27. Em vez de ...
- 28. Padrões de projeto Padrões arquiteturais Princípios de OO Cenários vs. Padrões corporativos
- 29. Em vez de ...
- 36. Em vez de ...
- 43. Em vez de ...
- 50. Prazo Escopo Custo Qualidade
- 52. Requisito Código
- 54. TDD
- 55. Devia ter escrito mais documentos!
- 57. Os primeiros 90% da aplicação levam 90% do tempo para ficarem prontos Os 10% finais levam mais 90% do tempo para terminar
- 58. Cone da incerteza Fonte: NASA (Cone of uncertainty)
Hinweis der Redaktion
- “ Ágil” no dicionário Aulete, tem como primeira definição: “Que se move ou age com muita facilidade, destreza e rapidez”. Tenho certeza que você conhece desenvolvedores que se movem e agem com rapidez: é só aparecer o patrocinador do projeto que ele se esconde. Ele também “age com muita facilidade” na hora de arrumar desculpas pros problemas no código ou no projeto. Será que esse desenvolvedor é ágil? Nesta palestra vamos analizar porque tantas empresas parecem estar caminhando para o “rápido” enquanto deveriam estar buscando o “ágil”. Veremos os conceitos errôneos frequentemente associados à agilidade como falta de compromisso, anarquia, falta de planejamento, falta de documentação, baixa qualidade, entre outros, e vamos tentar entender de onde eles vieram.
- Quando falamos em velocidade geralmente queremos dizer produtividade. E como buscamos produtividade?
- Padronização Vem da engenharia clássica Dimimui a variabilidade do processo Ideal para produção seriada
- Comando e controle Hierarquia, típica do militarismo O superior dá a visão e garante que ela vai ser executada controlando o processo
- Medições Vem da engenharia clássica Medições intermediárias garantiriam o processo e aumentariam a velocidade Qual o impacto das medições num processo de criação intelectual?
- BDUF Planejamento antecipado
- Expectativa de previsibilidade Pré-definições de escopo, prazo e custo. Nada muda.
- Está funcionando?
- Iniciamos achando que vamos rápido, e rápidamente nos colocamos na parede. Nossa produtividade cai. Porque?
- Porque potência não é nada sem controle.
- Em vez de padronização
- Em vez de Comando e controle
- Anarquia? Não!
- Auto gestão
- Auto organização Habilita resolução mais rápida dos problemas
- Transparência Ninguém esconde nada Foco maior nos problemas e oportunidades
- Habilita que você faça inspeção em vários pontos do processo
- Adaptaçao
- Em vez de medições...
- Métricas motivacionais Bonus Punições
- Funcionários mentem com medo de serem punidos Pior que não medir, é medir errado
- Hiperfoco mata a produtividade “ Cachorro hiperfocado dentro da jaula não ve a porta aberta”
- Métricas informativas, para o time usar Alguém tem interesse em adulterar esta métrica?
- Em vez de BDUF... Crise...
- Iterativo e incremental
- Planeje mais! Iterativamente!
- Há uma quarta variável escondida: qualidade Ilusão de previsibilidade
- Quality...
- Como tornar mais fácil aceitar mudanças?
- Código Limpo
- Somente a documentação necessária, não como proteção
- Boa parte dos nossos problemas está na ilusão de previsibilidade
- Vendemos estimativas como previsões de futuro
- Desenvolvimento de software é não linear
- Apenas arranhamos os conceitos iniciais. Mais estudo é necessário.