Transferir como PDF, PPTX
Carregado porLuiz Borba
O ciclo da vida
O documento discute os principais conceitos do Ciclo de Vida de Desenvolvimento de Software, incluindo: 1. A importância da Visão e Objetivos do projeto para orientar o time. 2. Exemplos de como problemas podem surgir quando os requisitos não são claros ou a tecnologia é desconhecida. 3. A necessidade de evoluir os sistemas incrementalmente através de iterações e deployes frequentes para lidar com mudanças e imprevistos.
Mais conteúdo relacionado
O ciclo da vida
- 1. O Ciclo daVida @luizborba http://borba.blog.br
- 5.
- 6. SCRUM de cabo arabo Luiz Borba borba@pitang.com Uma empresa C.E.S.A.R
- 7. 5/4/14 slide 39 Visão ! Essência ! Por que esse projeto está sendo feito? ! Quais os objetivos ! Investimentos x Retorno
- 8.
- 9.
- 10. startup is anorganization formed to search for a repeatable and scalable business model Steve Blank February 1, 2005 http://amzn.to/lPHq10
- 11.
- 12.
- 13.
- 22. 5/4/14 slide 23 Efetividade daComunicação
- 23. The Pragmatic Programmer AndrewHunt & David Thomas
- 24. Communicate! • A goodidea is an orphan without effective communication – Know What You Want to Say – Know Your Audience – Choose Your Moment – Choose a Style – Make it Look Good – Involve Your Audience – Be a Listener – Get Back to People
- 25. Communicate! • TIP 10:It’s Both What You Say and the Way You Say It – There’s no point in having a great ideas if you don’t communicate them effectively • Challenge – Write an article for a magazine – Share your ideas in a Presentation for us
- 26.
- 27.
- 28.
- 29. What I don´tknow about startups Luiz Borba @luizborba http://borba.blog.br
- 30. Minimum Viable Product(MVP) The minimum set of features needed to learn from early adopters
- 31. Tracer Bullets • “Ready,fire, aim…” • Tracer Bullets leave pyrotechnic trails from the gun to whatever they hit – Immediate Feedback – Equivalent to regular ammunition • Darkness – Vague Requirements – Unfamiliar Technologies – Unfamiliar Frameworks – Changes
- 32. Tracer Bullets • CodeThat Glows in the Dark • TIP 15: Use Tracer Bullets to Find the Target – Tracer Bullets let you home in on your target by trying things and seeing how close they land • Tracer Code is not Disposable – But not fully-functional
- 33. Speed matters Reducing timebetween pivots (fails) we can increase our odds of success Minimize the TOTAL time through the loop
- 34.
- 36. 3 Não me venhamcom a problemática que eu tenho a solucionática
- 37. Luiz Borba @luizborba -http://borba.blog.br Arquitetura Pragmática
- 38. "A arquitetura desoftware de um programa ou sistema computacional é a estrutura (ou estruturas), a qual envolve os elementos de software, as propriedades desses elementos visíveis externamente e seus respectivos inter- relacionamentos."
- 39.
- 40. Atributos de Qualidade •Performance • Segurança • Disponibilidade • Usabilidade • Confiabilidade • Manutenibilidade • Testabilidade • Portabilidade • Integrabilidade • Reusabilidade • Legibilidade • Escalabilidade
- 41.
- 42. Principais fatores para umbom design Baixo acomplamento Alta coesão
- 43. Melhorando a qualidade do seucódigo com GRASP Luiz Borba http://borba.blog.br 1
- 44.
- 45. Acoplamento é amedida de o quão forte um elemento está conectado, tem conhecimento ou depende de outros elementos
- 46.
- 47. Coesão é amedida de quão forte estão relacionadas as responsabilidades de um elemento. Quanto mais coeso, menor o esforço para realizar suas responsabilidades. Esta é a razão pela qual o padrão MVC é considerado uma boa prática. Reponsabilidades de GUI ficam aqui Mediação entre Model eView Responsabilidade para alterar os modelos
- 48. Primeira Lei deArquitetura de Software de Borba (Borba's 1st Software Architecture Law) Toda arquitetura definida está errada.
- 49.
- 50. Segunda Lei deArquitetura de Software de Borba (Borba's 2nd Software Architecture Law) Toda arquitetura definida que comprovadamente funciona estará errada em breve.
- 51. As coisas mudam •Tecnologias mudam • Requisitos/Planos/Negócios mudam • Pessoas mudam • Usuários mudam • TUDO MUDA. O TEMPO TODO.
- 52. O que fazerentão?
- 53.
- 54. TDD DIRETO DAS TRINCHEIRAS LuizBorba @luizborba http://borba.blog.br
- 55. Separa o quêdo como
- 56. TDD é maisimportante que tudo
- 57. "As melhores arquiteturas, requisitose design emergem de times auto organizados" (manifesto para desenvolvimento de software ágil)
- 58. 1. Não existenada de especial sobre arquitetura 2. Evite arquiteturas torres de marfim 3. Todo sistema tem uma arquitetura 4. Arquitetura viabiliza projetos grandes
- 59.
- 60.
- 61. Ada Lovelace “Think ofmy horror then at just discovering that the table & diagram (over which I have been spending infinite patience & pains) are seriously wrong, in one or two points”. 1843
- 62. Grace Hopper 1952 A-0primeiro compiladorjá escrito para um computador eletrônico
- 63.
- 64. "There is noprogram that, given a description of an arbitrary computer program, can decide whether the program finishes running or continues to run forever". ! (Alan Turing, 1936)
- 65. Seja empírica ou matematicamente,já faz décadas que descobrimos que MERDA ACONTECE!
- 66. 1º Ato Porque aMerda Acontece?
- 67. Onde há catinga,há merda
- 68. Martin Fowler’s CodeSmells Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy Data Clumps Primitive Obsession Switch Statements Parallel Inheritance Hierarchies Lazy Class Speculative Generality Temporary Field Message Chains Middle Man Inappropriate Intimacy Alternative Classes with Different Interfaces Incomplete Class Libraries Data Class Refused Bequest Comments
- 70. Merda Acontece porque deixamosjanelas quebradas
- 71. O milagre damultiplicação
- 73.
- 74. Merda Acontece porque usamosabstrações sem saber o que acontece por “debaixo dos panos”
- 75. 11 HISTÓRIAS E1 SEGREDO Luiz Borba http://borba.blog.br
- 76. “All non-trivial abstractions, tosome degree, are leaky.” ! - Joel Spolsky
- 77. Linguagens de programação sãoleaky abstractions.
- 78. Temos obrigação de conhecero que a linguagem que utilizamos faz por debaixo dos panos.
- 79. “When someone says:‘I want a programming language in which I need only say what I wish done’, give him a lollipop.” ! - Alan J. Perlis
- 80. As 2 Leisde Borba
- 81.
- 82.
- 83. Merda Acontece porquenão evoluimos nossos sistemas ao longo do tempo
- 84. 2º Ato Como lidarcom a Merda?
- 85. O Paradoxo doDeploy
- 86. Porque temos medo doDeploy? O Deploy de 180 Dias
- 87. Deploy Frequente minimizaa chance de dar Merda e quando acontece, é mais fácil de detectar o problema
- 88.
- 89. Qual a frequênciade deploy em produção do Facebook?
- 90. 2 vezes pordia
- 91. E o queacontece quando dá merda?
- 92. "Reverting is forlosers!" ! (Chuck Rossi)
- 93. IRC para localizaros desenvolvedores, resolver a bronca na hora e fazer um novo deploy
- 94.
- 95. Quanto tempo levao processo de deploy? (dezenas de milhares de servidores e um pacote de 1.5Gb)
- 98.
- 100.
- 101. “Rust is ageneral purpose, multi-paradigm, compiled programming language developed by Mozilla Research” ! - Wikipedia
- 102.
- 105. Obama não conhecia asLeis de Borba
- 107. U.S. Airforce blows $1Billion on failed Enterprise Software
- 108. Fornecedor x Integrador xCliente
- 109. Hierarquia Militar (troca constantede comando)
- 110.
- 111.
- 113.
- 117.
- 118.
- 119. o mundo era! mais simples
- 120. mas foi ficando! mais complexo
- 121. e os produtostambém
- 122. o chave parao futuro é a redução da complexidade
- 123. “Change is theprocess by which ! the future invades our lives” Alvin Toffler
- 124. Coisas que levei umtempo para aprender Luiz Borba http://borba.blog.br
- 125.
- 126.
- 128. Por que vocêprecisa (re)aprender linguagens funcionais? Luiz Borba Maio-2010
- 129. Software is gettingslower faster than hardware becomes faster (Nicklaus Wirth)
- 130.
- 131. As Coisas Mudam LuizBorba http://borba.blog.br
- 134. A gente mudamesmo sem querer...
- 135. “Eu vou desdizer Aquilotudo que eu lhe disse antes Eu prefiro ser Essa metamorfose ambulante Do que ter aquela velha opinião Formada sobre tudo”
- 136.
- 137.
- 138.
- 139.