Mitos do Desenvolvimento de Software

8,062 views
7,743 views

Published on

Apresentação do Rodrigo Yoshima na palestra do JustJava

Published in: Technology
1 Comment
6 Likes
Statistics
Notes
  • gostei muito deta materia e gostaria que me envia-se mais sobre o mitos e as razões
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
8,062
On SlideShare
0
From Embeds
0
Number of Embeds
566
Actions
Shares
0
Downloads
157
Comments
1
Likes
6
Embeds 0
No embeds

No notes for slide
  • Mitos do Desenvolvimento de Software

    1. 1. Mitos do Desenvolvimento de Software (e soluções ágeis) Rodrigo Yoshima
    2. 2. Agenda <ul><li>Como era nos anos 90? </li></ul><ul><li>Mitos do Gerenciamento </li></ul><ul><li>Mitos dos Requisitos </li></ul><ul><li>Mitos do Design e do Código </li></ul>
    3. 3. Conheça o Tonhão!
    4. 4. Perfil do Sponsor 90’ <ul><li>O que ele queria: </li></ul><ul><li>Uma solução rápida e barata </li></ul><ul><li>Feedback rápido </li></ul><ul><li>Ver coisas concretas </li></ul><ul><li>Implantar o mais rápido possível </li></ul><ul><li>Ganhar dinheiro com o software </li></ul><ul><li>Estar presente </li></ul>
    5. 5. Uma ligação que mudou tudo... <ul><li>Y2K </li></ul>
    6. 6. Depois da virado do Milênio <ul><li>Os projetos não voltaram mais para as empresas! Ficaram nas consultorias! </li></ul><ul><li>Contratos ganharam muita importância </li></ul><ul><li>O usuário ficou distante </li></ul><ul><li>O report do andamento do projeto ficou abstrato </li></ul><ul><li>Os projetos ficaram maiores e mais custosos </li></ul><ul><li>RUP Cascata, CMM, PMBOK </li></ul>
    7. 7. O que estamos procurando? Definição de Sucesso de um Projeto de Software <ul><li>O software resolve o problema (qualidade externa) </li></ul><ul><li>O software é fácil de manter e evoluir (qualidade interna) </li></ul><ul><li>Menor custo e prazo possível (qualidade do projeto) </li></ul>
    8. 8. Mitos do Gerenciamento <ul><li>A base do gerenciamento de projetos de software é o processo iterativo incremental! </li></ul>
    9. 9. Mitos do Gerenciamento: Escopo <ul><li>Escopo em software não são requisitos detalhados ! Escopo são os problemas que o software pretende resolver! </li></ul>
    10. 10. As empresas tem problemas!!!
    11. 11. Duas empresas oferecem seus serviços: <ul><li>Bravos Guerreiros S/A </li></ul><ul><li>Experiência </li></ul><ul><li>Humildade </li></ul><ul><li>Foco em resultados </li></ul><ul><li>Escopo Aberto </li></ul><ul><li>DXA Ltda. </li></ul><ul><li>Certificações </li></ul><ul><li>Planos detalhados </li></ul><ul><li>Foco no contrato </li></ul><ul><li>Escopo Fechado </li></ul>
    12. 12. Bravos Guerreiros S/A <ul><li>Contrato de Escopo Aberto (Risco-Benefício) </li></ul><ul><li>Cegar o dragão na semana 1 </li></ul><ul><li>Tirar sua habilidade de voar na semana 2 </li></ul><ul><li>Fazê-lo parar de cuspir fogo na semana 3 </li></ul><ul><li>Impedi-lo de destruir casas na semana 4 </li></ul><ul><li>Cortar suas pernas na semana 5 </li></ul><ul><li>O pagamento é semanal </li></ul>
    13. 13. DXA Ltda. <ul><li>Contrato Escopo Fechado (por Entregáveis) </li></ul><ul><li>Estudo exaustivo do dragão </li></ul><ul><li>Atirar 200 flechas </li></ul><ul><li>Lançar 30 pedras com a Catapulta </li></ul><ul><li>400 golpes de espada </li></ul><ul><li>250 golpes com o machado </li></ul><ul><li>O pagamento é por ação tomada </li></ul>
    14. 14. Trazendo isso para software... <ul><li>Num primeiro planejamento rápido elabore uma “pilha de requisitos” que inicialmente é suficiente para solucionar o problema. </li></ul><ul><li>Não é necessário detalhar os requisitos neste momento pois essa pilha pode mudar </li></ul><ul><li>Priorize os requisitos (os mais importantes primeiro) </li></ul>
    15. 15. Desenvolvimento Iterativo <ul><li>Defina o tamanho das iterações </li></ul><ul><ul><li>Todas elas terão o mesmo tamanho </li></ul></ul><ul><ul><li>Qual a maturidade da equipe? </li></ul></ul><ul><ul><li>Qual a disponibilidade do cliente? </li></ul></ul>1 2 3 4 ... 2 semanas 5
    16. 16. Desenvolvimento Iterativo <ul><li>Desenvolva uma parte da pilha na iteração 1: </li></ul><ul><ul><li>Plano: O que podemos entregar? </li></ul></ul><ul><ul><li>Execute o trabalho focado só nesses requisitos </li></ul></ul><ul><ul><li>Entregue com qualidade </li></ul></ul><ul><ul><li>Demonstre o resultado para os interessados </li></ul></ul>1 2 3 4 ... 2 semanas 5
    17. 17. Desenvolvimento Iterativo <ul><li>O ciclo recomeça!!!! </li></ul><ul><ul><li>Avalie as “avarias” no dragão (ele pode morrer antes!) </li></ul></ul><ul><ul><li>Atualize a lista de requisitos (novos ou priorização) </li></ul></ul><ul><ul><li>Faça o planejamento da iteração 2 </li></ul></ul>1 2 3 4 ... 2 semanas 5
    18. 18. Desenvolvimento Iterativo <ul><li>SIM, pode ser que nosso planejamento da iteração não se CUMPRA!!!! </li></ul>1 2 3 4 ... 2 semanas 5 ? ? ?
    19. 19. Por que não gerenciar tarefas? “ Você não consegue controlar aquilo que você não consegue mensurar.” Tom Demarco, 1983
    20. 20. Mito do Gerenciamento <ul><li>Em software, a soma das tarefas não é garantia de sorriso na cara do cliente. </li></ul><ul><li>O Gerenciamento de Projetos deve responder quais resultados você está obtendo e não o que você está fazendo! </li></ul>
    21. 21. Como é a sua equipe? Requisitos Análise Desenvolvimento Teste
    22. 22. Por que não aplicamos Taylorismo? Especialização e rigorosamente “dividir e conquistar” serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido.Kent Beck, 2004
    23. 23. Mito: Divisão e Especialização Promova a Colaboração!!!!
    24. 24. Mito: Divisão e Especialização Papéis do SCRUM Product Owner Equipe ScrumMaster
    25. 25. Erros em Requisitos! <ul><li>Ficar muito tempo sem reduzir a incerteza (sem entregar software funcionando) </li></ul><ul><li>Requisitos mudam! </li></ul><ul><li>(não adianta especificar todos no início) </li></ul><ul><li>Papel e Diagramas aceitam qualquer coisa </li></ul><ul><li>Software funcionando é o melhor artefato para levantar requisitos </li></ul>
    26. 26. Faça junto com o Cliente!!!
    27. 27. Mitos da Análise e do Design <ul><li>O que é Análise para você? </li></ul><ul><li>O que eu quero com o meu Design? </li></ul><ul><li>Análise e Design focam principalmente a qualidade interna do software. </li></ul>
    28. 28. Como modelamos atualmente? <ul><li>Uso do modelo é homeopático </li></ul><ul><li>Modelamos em Grupo! </li></ul><ul><li>Focamos a comunicação dentro da Equipe </li></ul><ul><li>Poucos modelos viram artefatos </li></ul><ul><li>Buscamos um bom código e não um bom modelo </li></ul><ul><li>Rascunhos também servem </li></ul><ul><li>Modelagem = minutos / Codificação = horas </li></ul>
    29. 29. Usamos UML? Sim!
    30. 30. Usamos UML? Sim!
    31. 31. Sempre UML? Não!!! Seu código sempre deve ser bonito. O modelo visual não!
    32. 32. O que é um modelo afinal? “ O modelo é uma simplificação de uma coisa complexa.” Grady Booch, 1999
    33. 33. Mitos da codificação <ul><li>O que é programar para você? </li></ul><ul><li>Analista é melhor que Programador? </li></ul><ul><li>A codificação é a atividade que deve ser valorizada no desenvolvimento de software, afinal, o código é o elemento mais próximo do que queremos de fato: solucionar problemas de negócio. </li></ul>
    34. 34. Como programamos atualmente? <ul><li>Nosso código é formal </li></ul><ul><li>Nosso código documenta praticamente 95% do projeto: </li></ul><ul><ul><li>Comentários em código </li></ul></ul><ul><ul><li>Orientação a Objetos: Alta Coesão / Baixo Acoplamento </li></ul></ul><ul><ul><li>Design Patterns (Padrões) </li></ul></ul><ul><ul><li>Domain-Driven Design </li></ul></ul><ul><ul><li>TDD / BDD : Testes, Testes e Mais Testes Automatizados </li></ul></ul><ul><ul><li>Fazer mais com menos código (frameworks e abstrações fortes) </li></ul></ul><ul><ul><li>Isso garante a manutenção do projeto!!!! </li></ul></ul><ul><li>Programamos em Grupo </li></ul><ul><li>Arquitetura Aberta </li></ul><ul><li>Design Emergente </li></ul>
    35. 35. O Código é o seu Design! <ul><li>Programar é uma atividade de design – um bom processo reconhece isso, e não teme iniciar a codificação quando isso fizer sentido. </li></ul><ul><li>Jack W. Reeves, 1992 </li></ul>
    36. 36. O Mito “Nerd” Desenvolver software é uma atividade social e imersa na área de negócios do cliente. Quem quer simplesmente receber especificações e se isolar não terá espaço no mercado!
    37. 37. Mito da Melhoria do Processo
    38. 38. Obrigado!!! Mail: [email_address] Blog: http: //blog.aspercom.com.br

    ×