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.

1. O Ciclo da Vida
@luizborba
http://borba.blog.br

5. 1
A Visão

6. SCRUM
de cabo a rabo
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. Exemplos

9. THE LEAN STARTUP
Luiz%Borba%
@luizborba%
h.p://borba.blog.br%

10. startup is an organization
formed to search for a
repeatable and scalable
business model
Steve Blank
February 1, 2005
http://amzn.to/lPHq10

11. Customer)Development!
The!search!for!the!business!model!
The!Search!for!a!Business! The!Growth!of!a!Business!

12. 2
Onde os problemas
começaram

13. U$ 1.5M

22. 5/4/14
slide 23
Efetividade da Comunicação

23. The Pragmatic Programmer
Andrew Hunt & David Thomas

24. Communicate!
• A good idea 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. todas&as&coisas&que&todo&
programador&não&pode&
deixar&de&saber&
(parte&1)&
Luiz&Borba&
h;p://borba.blog.br&
@luizborba&

27. priorização)

28. escopo&mínimo&

29. What I don´t know 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
• Code That 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 time between pivots (fails)
we can increase our odds of success
Minimize the TOTAL time
through the loop

34. itera&vo)e)incremental)

36. 3
Não me venham com a
problemática que eu tenho
a solucionática

37. Luiz Borba
@luizborba - http://borba.blog.br
Arquitetura Pragmática

38. "A arquitetura de software 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. Arquitetura
Design

40. Atributos de Qualidade
• Performance
• Segurança
• Disponibilidade
• Usabilidade
• Confiabilidade
• Manutenibilidade
• Testabilidade
• Portabilidade
• Integrabilidade
• Reusabilidade
• Legibilidade
• Escalabilidade

41. Visões

42. Principais fatores para
um bom design
Baixo acomplamento Alta coesão

43. Melhorando a
qualidade do
seu código
com GRASP
Luiz Borba
http://borba.blog.br
1

44. Aula 4
Baixo Acoplamento

45. Acoplamento é a medida de o quão forte um
elemento está conectado, tem conhecimento
ou depende de outros elementos

46. Aula 5
Alta Coesão

47. Coesão é a medida 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 de Arquitetura
de Software de Borba
(Borba's 1st Software Architecture Law)
Toda arquitetura definida está errada.

49. Precisa PROVAR!

50. Segunda Lei de Arquitetura
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 fazer então?

53. Design Incremental

54. TDD
DIRETO DAS TRINCHEIRAS
Luiz Borba
@luizborba
http://borba.blog.br

55. Separa o quê do como

56. TDD é mais importante que tudo

57. "As melhores arquiteturas,
requisitos e design emergem
de times auto organizados"
(manifesto para desenvolvimento de software ágil)

58. 1. Não existe nada de especial
sobre arquitetura
2. Evite arquiteturas torres de
marfim
3. Todo sistema tem uma
arquitetura
4. Arquitetura viabiliza projetos
grandes

59. 4
Merda Acontece

60. http://borba.blog.br
Merda Acontece
Luiz Borba

61. Ada Lovelace
“Think of my 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 compilador já
escrito para um
computador eletrônico

63. 1947

64. "There is no program 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 a Merda Acontece?

67. Onde há catinga, há merda

68. Martin Fowler’s Code Smells
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
deixamos janelas quebradas

71. O milagre da multiplicação

73. Cuidado com ORM

74. Merda Acontece porque
usamos abstrações sem saber
o que acontece por “debaixo
dos panos”

75. 11 HISTÓRIAS E 1 SEGREDO
Luiz Borba
http://borba.blog.br

76. “All non-trivial abstractions,
to some degree, are leaky.”
!
- Joel Spolsky

77. Linguagens de
programação são leaky
abstractions.

78. Temos obrigação de
conhecer o 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 Leis de Borba

81. Twitter no Início

82. Twitter Hoje

83. Merda Acontece porque não
evoluimos nossos sistemas ao
longo do tempo

84. 2º Ato
Como lidar com a Merda?

85. O Paradoxo do Deploy

86. Porque temos
medo do Deploy?
O Deploy de 180 Dias

87. Deploy Frequente minimiza a
chance de dar Merda e
quando acontece, é mais fácil
de detectar o problema

88. O Caso Facebook

89. Qual a frequência de deploy
em produção do Facebook?

90. 2 vezes por dia

91. E o que acontece quando dá
merda?

92. "Reverting is for losers!"
!
(Chuck Rossi)

93. IRC para localizar os
desenvolvedores, resolver a
bronca na hora e fazer um
novo deploy

94. Desenvolvedores
tem karma

95. Quanto tempo leva o processo
de deploy? (dezenas de
milhares de servidores e um
pacote de 1.5Gb)

98. 3º Ato
Tendências

100. Um C seguro

101. “Rust is a general purpose,
multi-paradigm, compiled
programming language
developed by Mozilla Research”
!
- Wikipedia

102. Exemplos

105. Obama não conhecia
as Leis de Borba

107. U.S. Airforce blows
$1 Billion on failed
Enterprise Software

108. Fornecedor x Integrador
x Cliente

109. Hierarquia Militar
(troca constante de
comando)

110. Informatização do
CAOS

111. 5
Quando Desligar

113. Exemplos

117. 6
Metamorfose Ambulante

118. “O Futuro”
luiz borba

119. o mundo era !
mais simples

120. mas foi ficando !
mais complexo

121. e os produtos também

122. o chave para o futuro é a
redução da complexidade

123. “Change is the process by which !
the future invades our lives”
Alvin Toffler

124. Coisas que levei
um tempo para
aprender
Luiz Borba
http://borba.blog.br

125. Primeiro
emprego
1991

126. 1993

128. Por que você precisa
(re)aprender linguagens
funcionais?
Luiz Borba
Maio-2010

129. Software is getting slower faster
than hardware becomes
faster (Nicklaus Wirth)

130. código existente será
obsoleto

131. As Coisas Mudam
Luiz Borba
http://borba.blog.br

134. A gente muda mesmo sem querer...

135. “Eu vou desdizer
Aquilo tudo que eu lhe disse antes
Eu prefiro ser
Essa metamorfose ambulante
Do que ter aquela velha opinião
Formada sobre tudo”

136. Coisa 13:
Seja uma
metamorfose
ambulante

137. what
killed
rup
could
kill
agile,
too
Luiz Borba

138. COURAGE

139. Obrigado!
Luiz Borba
http://borba.blog.br