Desenvolvimento Ágil - Visão Geral

Palestra apresentada em 2012, no Alogoinhas Dev Day, organizado pelos alunos da Uneb (Universidade do Estado da Bahia).

Visando facilitar o entendimento dos slides, também estão inclusas as minhas anotações sobre o que é falado durante a palestra.

Transcript

1. Rafael Miranda @rafaelmbr Desenvolvimento Ágil Visão Geral
2. Rafael Miranda @rafaelmbr Desenvolvimento Ágil Visão Geral Vamos falar um pouco sobre agilidade, Scrum e sistemas complexos, fazendo um paralelo rápido com o formato “tradicional”
3. Transparência Inspeção Adaptação
4. “Utiliza um processo empírico e adaptativo, e é estruturado em atividades iterativas e incrementais” http://bit.ly/KN9G5V - http://bit.ly/KjD7Qi - http://amzn.to/IBrWQI
5. Em um processo empírico a informação não é obtida pela Previsão, e sim pela Observação
6. Empírico/Adaptativo: Se vc está num barco pequeno, só consegue enxergar 4 milhas a frente. Você precisa levantar a cabeça e olhar para o horizonte de tempos em tempos para ajustar o caminho, identificar riscos ou oportunidades e continuar. Precisa inspecionar e se adaptar.
7. Fornecedor Cliente Valor Feedback Transparência, em um ciclo simples, rápido e contínuo
8. Acompanhamento Controle Previsibilidade Riscos Iteração por iteração, ciclo por ciclo: você sabe o que fez, pode alterar facilmente o que vai fazer, refina suas estimativas e minimiza riscos
9. “Utiliza um processo empírico e adaptativo, e é estruturado em atividades iterativas e incrementais” http://bit.ly/KN9G5V - http://bit.ly/KjD7Qi - http://amzn.to/IBrWQI
10. Incremental Você parte do princípio que sabe exatamente como será o produto final, e vai entregando-o pouco a pouco
11. Iterativo Você parte do princípio que não sabe exatamente como será o produto final e vai refinando-o, pouco a pouco
12. Iterativo e Incremental Você evolui, parte a parte, e o todo, reconhecendo que não sabe exatamente como ele será desde o início
13. Iterativo e Incremental E você define como e o quê será o seu incremento, com base no contexto do projeto, cliente, produto, time, organização, etc
15. Estratégia Portfólio Produto Release Iteração Dia Horas Min Seg Programação por par TDD Integração contínua Ágil Corporativo (Enterprise Agile) Focando nestes horizontes, o time, assim como no barco pequeno, trata o que é importante e que têm visibilidade
16. Permite Entregar mais “valor de negócio”, em um período de tempo menor Entregar software funcionando a cada duas a quatro semanas Cliente defina as prioridades e ordem de atendimento O time se auto-organize para entregar as funcionalidades mais prioritárias “Permitir” não é “Garantir”
17. Por que mudar para o Ágil? As coisas já não funcionam nesta forma “tradicional”, cascata, que usamos?
18. “66% dos projetos ultrapassam significativamente os custos estimados” [1] “33% dos clientes estão altamente desapontados com os prazos e qualidade” [3] “50% dos projetos é concluído no dobro do prazo estimado” [2]
19. The CHAOS Manifesto - 2011 Projetos tradicionais de 2002 a 2010 Sucesso 14% Contestado 57% Fracasso 29% Estatisticamente falando, se você está num projeto tradicional, suas chances de sucesso são absurdamente baixas!
20. The CHAOS Manifesto - 2011 Projetos Ágeis de 2002 a 2010 Sucesso 42% Contestado 49% Fracasso 9%
21. Ágeis: 3x Mais Sucesso Apesar dos critérios de “sucesso” do CHAOS Report serem questionáveis (como toda pesquisa do tipo), quando projetos ágeis e tradicionais são avaliados sob os mesmos critérios, chega-se a esta taxa
22. 7% 13% 16% 19% 45% Sempre Geralmente Algumas vezes Raramente Nunca Índice de uso de funcionalidades Jim Johnson. The Standish Group International Inc. 2002
23. Nós estamos falando de 64% de puro desperdício! De dinheiro sendo, literalmente, jogado fora!
24. Necessidades de alta importância Outras necessidades No ágil o foco é nas necessidades de alta importância, pois são muitas as incertezas dos projetos. Investe-se mais tempo em poucas coisas prioritárias, e as outras vão emergindo naturalmente com o passar do tempo.
25. Quantidade 20% 20% 60% Tempo a investir 60% 30% 10%
26. Requisitos Tecnologia Pessoas Um projeto é marcado pela presença de inúmeras incertezas, que podem ser agrupadas em 3 dimensões
27. “Em média, 35% dos requisitos dos projetos são alterados” http://amzn.to/IBrWQI Não importa o quão detalhado seja o seu planejamento ou quão exaustiva seja sua elicitação de requisitos: eles vão mudar!
28. Projetos tradicionais, que partem da premissa de que os requisitos serão detalhados, aprovados e não vão mudar: falham mais!
29. Tecnologias, mesmo quando conhecidas, se comportam de maneira desconhecida, principalmente quando utilizadas dentro do contexto do projeto
30. Projetos tradicionais, que partem da premissa de que a tecnologia é conhecida e não se comportará de maneira inesperada: falham mais!
31. Pessoas não são robôs! São pessoas! Que têm dias bons e dias ruins. Dias muito bons e dias muito ruins!
32. Projetos tradicionais, que partem da premissa de que as pessoas (recursos) se comportarão sempre de forma conhecida, quando alocadas à atividades pré-determinadas, com tempos pré- determinados: falham mais!
33. Por fim, coisas completamente inesperadas acontecem!
34. Projetos tradicionais, que partem da premissa de que um plano detalhado, que prevê todos os riscos e eventualidades e suas ações de mitigação, será suficiente: falham mais!
35. Um projeto tradicional investe muito tempo no planejamento. Na manufatura este investimento pode se pagar, pois o plano será repetido e reaproveitado para toda unidade do produto fabricado. Infelizmente, a analogia da fábrica é muito comum no desenvolvimento de software
36. Na construção civil, também alvo de comparação com a Engenharia de Software, existem inúmeros elementos estáveis e conhecidos: leis de Newton, materiais e peças padronizadas e padrões de construção
37. Desenvolvimento de software não é tão conhecido, estável ou repetitível assim. O plano é único e otimizado para cada projeto/produto. As ferramentas e tecnologias, apesar de avançadas, se comportam de maneiras desconhecidas frente à contextos novos. E, fundamentalmente, trata-se de uma produção intelectual mais do que manual, o que implica em alta dependência da criatividade das pessoas, algo difícil de se medir.
38. Ralph D. Stacey
39. The Stacey Graph
40. + - - - The Stacey Graph Avaliadas as 3 dimensões sobre a qual falamos
41. The Stacey Graph Desenvolvimento de software
42. “Problema ou contexto Complexo é aquele em que a quantidade de coisas que não sabemos é maior do que a quantidade de coisas que sabemos” http://amzn.to/IBrWQI
43. The Stacey Graph Engenharia civil
44. 14% Desenvolver software é um problema complexo . Usando o formato tradicional alcançamos taxas baixíssimas de sucesso. Estas taxas seriam aceitáveis numa fábrica de carros ou construção de edifícios?
45. Para lidar com as incertezas, os projetos tradicionais criam “pulmões” nos cronogramas
46. As famosas gorduras!
47. Projetos ágeis têm gordura zero! Transparência!
48. Nos projetos tradicionais tenta-se antecipar o máximo de requisitos, riscos, estimativas, etc...
49. ...demandando muito tempo e energia. Porém, como as incertezas são muitas (e coisas inesperadas acontecem, além de não termos como antecipar tudo), gasta-se mais tempo e energia ainda com replanejamentos
50. Mike Cohn
51. 20% esforço 80% acurácia As estimativas não ficam proporcionalmente melhores na medida em que se investe mais tempo nelas. Os projetos ágeis tentam investir o mínimo necessário para se chegar num resultado aceitável pelas partes interessadas no projeto
52. Todo o tempo extra utilizado nos projetos tradicionais, seja para planejar, estimar, detalhar requisitos, etc, deixa o processo lento, ineficiente...
53. Implicando em um índice de falha 3x maior do que os projetos ágeis!
54. Steve McConnell
55. +400% de Variação -400% de Variação Cone da Incerteza Projetos tradicionais fixam compromissos no momento comprovadamente maior incerteza do projeto, de maior chances de erros. Gerando os famosos deadlines!
56. Deadline Faz sentido trabalhar todos os dias em algo que faça alusão à sua morte?
57. Implicando em um índice de falha 3x maior do que os projetos ágeis!
58. Variabilidade da previsão Futuro Presente Olhando o Cone da Incerteza do ponto de vista da previsão...
59. Alta incerteza Baixa acurácia
60. Menor incerteza Maior acurácia
61. Redução da incerteza global
62. Maior acurácia Adaptação às Incertezas Aumento da acurácia Redução da incerteza global Principalmente, se adaptando!
63. Assim como um escalador, que planeja o caminho inicialmente, mas se adapta durante o percurso
64. Independentemente do tamanho do desafio (Excalibur, maior parede de escalada do mundo, na Holanda)
65. Por mais louca que possa parecer esta abordagem, uma malha de segurança é criada (Testes Automatizados, etc), assim como o escalador instala ganchos de segurança
66. Requisitos Tecnologia Pessoas Com isto vamos ganhando conhecimento, aprendendo sobre as dimensões de incertezas, gradativamente
67. STATE OF AGILE SURVEY 2011 GANHOS Melhoria na habilidade de lidar com mudanças de prioridades 84% 77% Aumento da visibilidade do andamento do projeto para partes interessadas 75% Aumento de produtividade 65% Aumento de qualidade 65% Redução de riscos Respondentes
68. Planejar Desenvolver Pré-homologar Priorizar Esclarecer Homologar Implantar Documentar Auto-avaliar Como fazemos eme um dos nossos projetos, dentro do Governo
74. Planejar Desenvolver Pré-homologar Priorizar Esclarecer Homologar Implantar Documentar Auto-avaliar Melhor acompanhamento, maior controle e previsibilidade e redução de riscos: mais qualidade e engajamento do time
78. http://amzn.to/IBrWQI Pesquisa realizada com CEOs de grandes empresas
79. Tempo de planejamento cada vez maior Tempo entre entregas cada vez maior Datas acordadas são extendidas Tempo de estabilização entre entregas cada vez maior Introduzir mudanças no meio do projeto é extremamente difícil Qualidade do produto está deteriorando O moral das equipes está diminuindo
80. Continuar usando modelos tradicionais é continuar neste cenário, de falhas com os clientes, com os produtos e com os times, envoltos em uma aparente tranquilidade e segurança
81. 14% Queremos sair deste índice de sucesso...
82. 42% ...para este índice, que ainda não é excelente, mas já é 3x melhor que o atual
83. Obrigado! Rafael Miranda @rafaelmbr
84. [1] Albert Lederer e Jayesh Prasad - Nine Management Guidelines for Better Cost Estimating - ACM, 1992) [2] Standish Group - Extreme Chaos, 2001 [3] Forrestere Report - Corporate Software Development Fails to Satisfy on Speed or Quality, 2005 Referências