1. Traditional "waterfall" software development approaches from the 1970s often failed due to inability to adapt to changing requirements late in the process. 2. Agile software development methods emerging in the 1990s emphasized iterative development, adaptive planning, early delivery of value, and ability to manage changing priorities. 3. Studies show the success rate of software projects has improved from around 16% in 1994 to over 37% in 2011, which many attribute to the rise of agile principles and practices.

1. As reais razões do
porque eu devo ser Ágil
São Paulo, 19 de novembro de 2011.

2. Planejamento Ruby on Rails
Coaching Consultoria

3. somos referência

5. 9º projeto mais popular
250.000 views/mês

6. à venda na

7. Evolução

8. a tecnologia está evoluindo

9. e a maneira que fazemos
software também...

10. Evolução da Taxa de Sucesso
em Projetos de Software
37%!
35%!
34%!
32%!
29%!
28%!
27%!
26%!
16%!
1994! 1996! 1998! 2000! 2002! 2004! 2006! 2008! 2011!
Fonte: Standish Group, CHAOS Report

11. mas ainda há
63%
para avançar

12. O que causou esta melhora
nos últimos 15 anos?

13. 1970 1980 1990 2000 2010
13

14. 70’s

15. Managing the development
of large software systems
Dr. Winston W. Royce (11 pages)
15

16. I SYSTE
M
I ANALYSIS
PROGRAM
DESIGN
I ANALYSIS
PROGRAM
DESIGN I coo,.o
I coo,.o TESTING
TESTING
I O
I OPERATIONS
Figure 2. Implementation steps to develop a large computer program for delivery to for delivery to a customer.
Figure 2. Implementation steps to develop a large computer program a customer.
I believe in this concept, but the implementation described above is risky and invites failure. T
16
lem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle i

17. Engenharia de Software

18. h vy
ea
weight processes

19. 80’s

21. Custo de mudança
Custo de Mudança
Fase do projeto
21

22. a tentativa em 80’s...

23. 1980’s
=
Controlar
Reduzir Custos
Processos
23

24. TI orientada a Cu$to$

25. 90’s

27. enfim, reforços...

28. forte adoção
Programação
Orientada a Objetos

29. surgem os primeiros
llight weight processes
ight

30. 1995~1996
Scrum
eXtreme
Programming
Feature Driven
Development
Crystal
Clear
Dynamic Systems
Development Method
Adaptive Software
Development

31. o resultado...

32. Custo da Mudança
Custo de mudança
Tempo
“Waterfall” (1970)
Novas abordagens 1990’s
32

33. a conclusão...

34. 1990’s
=
Ciclos Entregas Constantes
curtos de Valor
34

35. TI orientada a
Geração de Valor

36. 2000’s

37. O Manifesto Ágil

38. Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Fonte: http://agilemanifesto.org

39. 2010’s

40. duas realidades
em projetos...

41. realidade #1

42. equipes
na realidade #1

43. realidade #1
equipe de especialistas
passagem de bastão = empurrar o problema

44. execução do projeto
na realidade #1

45. realidade #1
requisitos mudam
I SYSTE
M
sempre atrasa
I ANALYSIS
espero que
PROGRAM
não condiz com
DESIGN funcione
os requisitos
I coo,.o
TESTING
I OPERATIONS
não há tempo
Figure 2. Implementation steps to develop a large computer program for delivery to a customer.
I believe in this concept, but the implementation described above is risky and invites failure. The

46. realidade #1
é tarde de mais!
:(
Problemas Problemas
Problemas
Problemas Problemas
Problemas
Problemas Problemas Problemas
Projeto
Problemas
Problemas Problemas
Problemas Problemas
Problemas Problemas

47. lidando com mudanças
na realidade #1

48. realidade #1
• processo lento e desgastante
• change requests
• adendo de contratos
• consome muito tempo e dinheiro

49. realidade #1
Custo da Mudança
Custo de mudança
Tempo

50. entregas
na realidade #1

51. realidade #1
% pronto
2 meses de projeto
Requisitos Design Coding Testes Integração Deploy
Projeto 25%
Uso 0%

52. realidade #1
Entrega de Valor
Valor Entregue
Tempo

53. realidade #2

54. equipes
na realidade #2

55. realidade #2
Times multi-disciplinares
formados por Generalistas Especialistas

56. execução do projeto
na realidade #2

57. realidade #2
I SYSTE
M I SYSTE
M
YSTE
M
I SprintSYSTEM
SYSTE
I
M1 I SYSTE
M
I SYSTE
M
I Sprint 2
SYSTE
M
I SYSTE
M
I SYSTE
M
I SYSTE
M
I Sprint ... I
SYSTE
M
I SYSTE
M
SYSTE
M
Sprint n
SYSTE
M I SYSTE
M I SYSTE
M I SYSTE
M
I SYSTE
M I SYSTE
M I SYSTE
M I SYSTE
M
I ANALYSIS
I I I ANALYSIS
I I I ANALYSIS
I I
I ANALYSIS
I
ANALYSIS
I
ANALYSIS
I ANALYSIS
I
ANALYSIS
I
ANALYSIS
I ANALYSIS
I ANALYSIS
ANALYSIS
I
ANALYSIS
I I I
PROGRAM
DESIGN
ANALYSIS
PROGRAM
PROGRAM
ANALYSIS
DESIGN PROGRAM
DESIGN
ANALYSIS I
PROGRAM
DESIGN
ANALYSIS
PROGRAM
PROGRAM
DESIGNANALYSIS
PROGRAM
DESIGN
ANALYSIS
PROGRAM
DESIGN
I
ANALYSIS
PROGRAM
PROGRAM
DESIGNANALYSIS
PROGRAM
DESIGN
ANALYSIS
PROGRAM
DESIGN
ANALYSIS
PROGRAM
I ANALYSIS
I ANALYSIS
DESIGN PROGRAM DESIGN PROGRAM DESIGN PROGRAM DESIGN PROGRAM
I coo,.o
I I
DESIGN c o o , . PROGRAM
o
I
DESIGN c o o , .PROGRAM
o DESIGN
DESIGN c o o , . oPROGRAM
I I
DESIGN c o o , . oPROGRAM
DESIGN c o o , . o
I
DESIGN c o o , . o PROGRAM
DESIGN c o o , . o PROGRAM
I I
DESIGN c o o , . o
I I
DESIGN PROGRAM
DESIGN
I I I I
coo,.o coo,.o
I I I I
coo,.o coo,.o coo,.o coo,.o
I I I
coo,.o coo,.o coo,.o coo,.o
TESTING TESTINGo o , . o TESTINGc o o , . o TESTINGc o o , . o
I I I
c
TESTING TESTINGo o , . o
c TESTINGc o o , . o TESTING c o o , . o
TESTING TESTING TESTING TESTING
TESTING TESTING TESTING TESTING
TESTING TESTING TESTING
I OPERATIONS I OPERATIONSTESTING I OPERATIONSTESTING I OPERATIONS TESTING
I OPERATIONS I OPERATIONS TESTING TESTING
I OPERATIONS TESTING
I OPERATIONS
I OPERATIONS I OPERATIONS I OPERATIONS I OPERATION
mplementation steps to develop a large computer program for Implementation steps to develop a large computer program 2. Implementation steps to develop a large computer program for delivery to Ia customer.
ivery to a customer. I OPERATIONS
Figure 2. delivery to a customer. I OPERATIONS Figure for delivery toI a OPERATIONS I OPERATIONS
customer. OPERATIONS
I OPERATIONS
er program for delivery to a customer. to develop a large computer program for delivery to a customer.to develop a large computer program 2. Implementation steps to develop a large computer program for delivery to a customer.
Figure 2. Implementation steps Figure 2. Implementation steps I OPERATIONS I OPERATIONS delivery to a customer. toI a OPERATIONS I OPERATIONS program for delivery to I a customer.
Figure for OPERATIONS I OPE
op a large computer program for delivery to a customer. to develop a large computer program 2. Implementation steps to develop a large computer program 2. Implementation steps to develop a large computer
Figure 2. Implementation steps Figure for delivery to a customer. Figure for delivery customer.
and steps tofailure. The implementation described above programand steps tofailure.customer. to develop programcomputer is risky aand steps tofailure.theaimplementation describedfor Implementation steps tofailure.a customer. develop programcomputer program for
n thisImplementationa steps to develop programcomputerbelieve a customer.
ion concept, but thelarge computer
e 2. invites
develop Figure 2. delivery risky this invites develop a implementation described above
a large
for Implementation concept, but the large computer
I is to in for delivery to a The
Figure 2. Implementation steps
Figure for delivery toin this invites develop large computer program 2.above is risky a customer. develop a large computer
a large
2. Implementation concept, but The
I believe customer. Figure
program 2. Implementation steps to develop a large computer program 2. invites
Figure for delivery to a customer.
delivery to and
delivery to The
Figure forImplementation steps to a large
for delivery to a custo
ed in Figure risky andtesting phase but Theoccurs at the is illustrateddevelopment cycletesting phase but the occursto develop aof the computer is4. Figuretesting phaseto a the occurs to develop described above isprogram 2. invites failure. customer. develop a large comp
ed aboveI is 4.cycle 2. invites failure. the implementation described abovebelieve in for delivery to which steps at theisend described above programthis invites failure. customer. at the end a large development cycle forthe
development The thisImplementation steps problem end large computer program and invites failure. The problem
believe in is the
Figure concept, which to develop a of the in Figure 4.Figurethis the
I is riskyThe 2. concept, a customer.
is Implementation implementation large development Theand the
illustrated in Figure risky for concept, but The
I believe in 2. delivery which steps
cycle is Implementation implementation of the computer risky and Implementation steps to
Figure is delivery to a The
mentation described above believe in this Implementation steps to develop a described above program and delivery tobutcustomer. to develop a large computer is risky and invites failure.the implementation described above isprogram 2. invites failure. customer. de
I is risky and invites failure. the implementation large computerbelieve in for invites failure. the steps
Figure 2. concept, but The I is risky this concept, a
Figure 2. Implementation implementation described above program forconcept, buta customer. develop a large computer risky and Implementation steps to
The I believe in this delivery to
Figure 2. Implementation steps toThe Figure for delivery to a The
shat the endillustrated in Figure 4.transfers, etc.,isare experienced problem isTheof theinput/output4.transfers,thefirst event and which timing,isstorage, input/outputdescribedisabove arerisky and occurs at the end of the development cycle isabove is risky and invites failu
problem isstorage, development cycle isabovefirstriskywhichinvites failure. end implementation describedisabovephase which occurs at the end of the development cycletesting believewhich invites distinguished from
s distinguished the input/output The testing believe in for occurs timing, the
timing,the of from
ept, but implementation described the I phase and which at the storage, development cycle testing believe infor invites distinguished fromin Figure 4.transfers, the phase in this concept, but the implementation described the
event this concept, but illustrated in Figure
as distinguished from The are experiencedproblem illustrated
etc., is risky this concept, but the implementation
I as failure. The The etc., is experienced as failure. The
I
phase which occurs at the end of the development cycle isabove believewhich invites failure. end of the development cycletesting believewhich occurs at the end of the development The testing believewhich occurs at the endThe the development cycle isabove is ris
elieve in this concept, but is illustrated in Figure 4. The testing phase in thisoccurs at theis the implementation describedisabove is risky and invites failure.illustrated in Figure 4. cycle isabove is risky and concept, but the of
problem the implementation described the I is risky and concept, but illustrated in Figure 4. The
problem The the phase in this concept, but the implementation described the phase in this invites failure.
I problem is The I implementation described the
henomenatesting asprecisely analyzable. the end of not the in Figure 4.cycle forthe as partial analyzable. They areof theThese phenomena for which timing, analyzable.atTheyend of the developmentexperienced as partial
ns4. experienced phase which occurs input/output transfers, etc., areevent is which distinguished fromat the analyzed. the in Figure 4. experienced as partial storage, input/output not the in Figure 4. cycletesting phase which occurs at the end of the development
e toeventstandard partial
irst The for whichdistinguished fromat They are the development to The are not phase which occurs
are the are not timing, storage, problem is illustrated solutions experienced precisely storage, input/output not development cyclestandard distinguished from theis are transfers, etc., are The standard distinguished from
analyzed. These phenomena standard timing,
first the testing problem is illustrated solutions event are the precisely
end transfers, etc., are The testing phase which occurs
first to the is not problem illustrated solutions to the is the
ut transfers, Figure 4.event this concept, but the occursinput/output transfers, FigureriskyTheforinvitesastiming, The occurs at theisenddescribed abovebelieve infor isinvitestiming, storage, input/outputdescribed above are experienced as distinguished from the enddes
llustrated in etc., are experienced as distinguished from the enddescribed in etc., are cycle thiswhich failure. the implementation of the developmentexperienced as failure. the occurs at the end of the development The this invites failure. the occurs at
first The for which timing, storage, at
I believe in testing phase which implementationillustrated aboveI is
problem is of the development first 4. experienced phasebut storage, input/output transfers, Figure event and whichphasebut The problem is illustrated in Figureis4. cycle is concept, but The
event testing distinguished from
believe andis the
in concept, which problem illustrated in etc., is 4. cycletesting distinguished from
first risky this the
I are The concept, which implementation transfers, etc.,
I believe in and the phase which implementation of
risky testing
ons nottoinput/output physicsstandard are eventthis these phenomena implementation describedfor instance. experienced as equations ofimplementation physics for aboveprecisely andthese astiming, storage, the solutionsvarious standard are experienced as distinguished
arefail mathematical various for etc.,first experienced as distinguishednottoinput/output to the standardprecisely forinvites phenomena fail from solutionsvarious are instance. experienced phenomena fail toinput/outputdescribed above is risky and invites failure.the im
analyzed.satisfy the to the are instance. in differential timing, analyzed.the solutionsvarious are etc.,isare Yet thiswhichfailure. analyzed. the
a of solutions transfers, not precisely for concept, but the of fromsatisfy phenomena abovefirst event analyzable. They The nottoinput/output to the standard is event for which distinguished from
torage, theThese phenomena I believe Yet analyzable. They storage, These the physics
partial if which equations failmathematical transfers, not believe in if these timing, the mathematical described not believe in analyzable.failure. the not satisfy the to the
are risky differential distinguished
I partialand concept, but storage, These phenomena
are satisfy the transfers, etc., are Yet thisinvites They are implementation transfers, etc., partial this concept, but The
firstpartial if concept, but The
I risky I believe in
or which timing, analyzed. These phenomenastandard precisely for whichat the endillustrated in Figure 4.transfers, notfirstpartial for occurs timing,end of theinput/output tocycle standard are experienced asatTheyend of the development cyclestandard are experience
nalyzable. They storage, the in Figure 4.transfers, etc., are event analyzable. They storage, the solutions to The is the phaseexperiencedproblem analyzed. the in Figure 4.transfers,thefirst partial for which timing, storage,from solutions4.transfers, the phase which oc
problem is are not input/output to The testing first experienced as distinguishedthe development cycle are etc.,precisely analyzable.distinguished from solutions Theare not precisely analyzable. distinguished the in Figure to The testing partial
illustrated solutions the are notphase which occurs timing,analyzed. input/output
partial problem is are not These phenomena standard are which which at They storage, These phenomena testing phase which occurs
of from the testing event as the is are not development the is etc., event
illustrated problem is are not input/output
the illustrated the is etc.,
atch not redoequationsisolated They analyzed. externalphenomenatesting phase of somefail mathematicalrequired.These phenomena is the invariably aanalyzable. They areof the These phenomena are the redo of which fail to satisfy isendvarious development cycletestin
differential of somemajor redesign is required.These constraints,are notinvariably a majorto at the end of not external constraints, are not redo ofwhich of mathematicalrequired. development cyclestandard partial analyzable.atThey are of the in Figure 4. The stand
s, these invariablyanalyzable.
if then precisely a fail to satisfy is are physics inAFigure 4.octal patch or redo which occursredesign is are the thein simple 4.cycle standard partialsomefail to satisfy analyzed. theAsolutions4. Yet if is not precisely
are or phenomena of problem the various for simple to The differential equations of problem the physics for Figure octal differential equations occurs at the is illustratedfor simple octal patch or phenomena occurs
mathematical not the solutions
illustrated instance. the standard precisely analyzable. They illustrated A instance. The if these phase
Yet ifthen phenomena isolated
these partial satisfy analyzed. development to Yet testing precisely major problem the physics in instance.to The testing phase some isolated the the not the solutions to the is th
is various solutions the patch or phenomena isolated
then redesign end various
not Figure the these problem illustrated
or instance. Yet differential equationsfail toinput/outputvarious These phenomenastandard precisely analyzable. They are transfers, instance.to Yet for theseas equations of mathematicalare transfers, instance. toYet for these astiming, analyzable. They are transfers, e
if these precisely analyzable. They analyzed. for etc., first to the for these phenomena of from satisfy analyzed. the solutions event arewhich distinguished from They physicsthe solutionsevent arewhich distinguished from
phenomena of mathematical physics solutions experienced as distinguished mathematical physics These phenomena if not precisely analyzable.
hese phenomena for which timing, storage,
first event are not satisfy the transfers, instance. Yet arewhich partial storage, input/outputvarious for etc., are experienced phenomena fail toinput/outputvariousfor etc., are experienced precisely storage, input/outputvarious sol
are not the are event differential timing,
if not equations fail to the not first differential timing, storage, satisfy analyzed. These phenomena ifstandard partial
the standard partial the not first the not phenomena fail to satisfy the not the
external constraints,that the event for these phenomena required. to bethe disruptive that the eventdifferential changesnot fail mathematicaldisruptive then theare ofYeta if designphenomena of mathematicaldisruptive that the areofYet for these astiming, storage, input/o
to be so disruptive then redo ofYet differential changes notof toinput/outputoftransfers,then first experienced asphenomena of fromsatisfy so ofvarious for instance. experienced redesign isarefail from A be so physics for instance. experienced phenomena fail to satisfy
esesimple physics for instance. requiredwhich redesign storage, these kinds various patch instance. ofYet for these code will isare fix toexternal the physics that invariablydifferential changes storage, input/output transfers, or first event if which distinguished from
ematical of difficulties.first
A kinds octal patch or invariably if major code willisare fix satisfy so physics for etc., invariably aifmajor redesign storage,these kinds octal patch etc., required these as equations likely satisfy the octal patch etc.,
The some isolated equations likely A simple octal
a designtiming, fail mathematical difficulties. The required designdistinguished likely to be constraints,
external constraints, or redo
are some which timing, required. A simple difficulties.or The event for which timing, required. to simple various
isolated equations input/output transfers, redo
first some isolated
major distinguished to redo some isolated
design is required.external constraints, then redo ofYetdifferential equationsfail mathematical variouspatch instance. ofYeta if theseredesign isareof mathematical physics for instance. ofYet analyzable. They are fail to These phenomena for instance. ofYet analyzable. The
equations of mathematical physics for instance. somemajor phenomenarequired.These the physics for notinvariablydifferential equations fail to These phenomena standardpreciselya if these phenomenaofnot theAsolutionsoctal patch not redo
analyzed. These phenomena are not invariablyanalyzable. They is not to externalphenomena are or redo
A simple octal patch or precisely a these redesign are of the solutions to the standard precisely analyzable. Theyanalyzed.the A simple octal patch not redo
if isolated analyzed. satisfy constraints, then partial some isolated
A simple octal major phenomena not external constraints, are orinvariablysome isolated
required. satisfy the various then
solutions to the major redesign is required. satisfy the variousare or precisely if these pheno
partialdifferential equationsanalyzed. simple to the
mathematical physics standard partial some isolated
ents uponmajor redesign so disruptiveandsimple octal patch notrationalewill aare likely todesign disruptivesolutions torequiredthen invariably aare isolateddesign are not the A which provides are not redo offoraanalyzable. are so are not theAsolutions to the are not redo of
changesaare likelythearekinds is basedThese phenomena arethen redo ofupon not fix redesign so is not theand which providesaredesign changesanalyzable. are so is basedexternalphenomena standard changes are likely to They disruptive that phenomena standard partia
code for everything designrequired.external constraints, the precisely analyzable. They analyzed. externalthe octal patch not redo of for not fix theto Theyis disruptive that the octal patch orinvariably everything be analyzed. These the octal patch or precise
nale will not fix these analyzed.
ariably which to be is of difficulties. The required designcode somewhich the are is required.These phenomena the or codeupon which these be analyzed. andsolutions requiredthen precisely major redesign is required.
Athat the software requirements for everything be areof difficulties. constraints,
which provides or invariably major these kinds based A simple
changes isolated that The the requirements will everything kinds required.These constraints, the rationale some isolated
software standard precisely major redesign
rationale some likely
partial of difficulties. The to the design partial
simple simple
nstraints, then invariably aare likely to be so disruptive A instance. requiredthen redo ofwill aare fix these be so disruptive A instance. Yetpatch orinvariably not fail mathematicalofvarious for instance. Yetpatch or redo of some likely satisfy so disruptive A instance. Y
e required design code will not fix redesign is required. for simple octal patchdesign changes notisolatedto kinds various external the octal differential changesaarefix toredesign so disruptive A simple octal differential changesaarefailmathematicalrequired. for simple octa
differential changes major these kinds physics external The Yet differential equations of to redesign is required. for simple requiredthen code willsomeof these kinds required. that the requiredthen invariably majorto to be the physics that the
equations of mathematical of difficulties.the that constraints, these invariably faillikely
if or phenomena major satisfy the of difficulties. The
code some mathematical physics that constraints,if these redo of design equations likelysatisfy the physics
phenomena isolated be is
major to difficulties. The
external constraints, if designphenomena ofisolated
these equations redesign is various
of requirements The In be differentialor are will are likelythese kindssoftwareforrequired. Inupon everythingaare violated.these bethesoftware is required. In Yet if theseor changesnotbased and kinds disruptiverequired. In effect designphenomena of mathematicaldisrup
software requirements effect which thea designviolated. to be sotheof difficulties.the
design is required. required design code
e difficulties.rationale upon
provides the must for everything substantial change which design isthat rationale effect design changes notof to satisfy thedisruptive the rationale effect design a design are fixmathematicalofvarious for instance. Yet everything are
modified, changes notbased and in thephysics requirementsbe forif these phenomenaarebased and kinds various requirementsbe for everything are
of mathematicaldisruptive the must required
equations is fix Either provides instance. Yet differential equations likely Either so of difficulties. must required
requirements The modified, or design is fix
which the substantial mathematical design for instance. upon which theequations failchange which design is the rationale for if these changes arefail to satisfyso physi
code will fail change which physics that the
to in requirements The
provides modified, code will is of to satisfythe provides that the required
differential substantiallikely to in so physics
phenomena these be the difficulties. The differential equations likely to be the vario
otbased external constraints,requirements uponmajor redesign is are based external constraints, that rationalesomewhich the design notbased externalso disruptive theor the required design changes is based external so ofoctal patch or invariably a everything are is are lik
fix these kinds software the rationale fora everything arewill required. and kinds octal patch or the of upon everything are is are fix these kinds of difficulties.rationale forawhich the design not fix these kinds disruptivethe rationale for major redesign requir
and which of difficulties. invariably
provides then The required which the design not likely to simple of difficulties. redo requiredisolated changes is likely to which provides then invariably everything are is are likely to which provides then The required design changes
changes is fix thesebe so software requirements fora major redesign required.and simple octal patch
design code A which provides the invariably
disruptive then The design
code will A be software requirements of some isolated will required. A simple difficulties. the of some isolated
constraints, that The upon major code
redo redesign and be constraints, that redo
violated. overrunthebasedexternal andprovides requirementssubstantial change in is thedesign external must In effectthe rationale somewhich hasEither therequired.and which one canrequirementssubstantial changeare theis basedexternal constraints, the orinvariably aeveryt
-percent Either is to the origin constraints, the developmentlO0-percent Eithertheis to the is required. one can expectinvariablylO0-percent overrun istoschedule simple providesexpect invariably aeverything design required. required. provides thenrationale for major
rocessthe design in schedule which software the rationale uponmajor redesign required. and which octal patch development processchange in theinbasedexternalmustoctalmodified, or atoof for which theoverrun in schedule which octal patch
tial changereturned requirements must becan then invariably aeverything are
which has in the design is required. one modified, or ato for process hasoverrun inbased origin and provides then redo ato uponviolated.thereturned design origin and In effectthe or redo upon major redesign is design is A simple In effect
and In effect expect up a violated. returned requirements constraints, or or of a aeverything design requirements constraints, thenrationalea some isolated in
which the design schedulesimplesoftware the
A be modified, up substantial redesign is
requirements for major
isolated are the is required. be patch
A software up lO0-percent and redo of some iso
quirementssubstantial change kinds is based is required. providesrequirementssubstantial change kinds is requirements must requiredthe rationale for are likely Either so disruptive required. provides the rationale fornot fix these are theis based is required. provides the r
ified, or a uponnot fix these in the of requirements The requiredthe rationaleuponnot fix these in the ofbased isthatwhich provides designcode uponnot fix theseare theisrequirements must be effect design changes are likely to be so disruptive that the required desi
code will violated. Either the difficulties. must be modified, or a willare likelythe are sothe design and/or costs. In effect
which the design design and whichsoftware design changes violated. to be
In effect which Either disruptive and the software requirementssubstantial change be
for everything design difficulties. The be modified, or changesviolated. the design ofbased is that the required
required. a everything kinds design and which In modified, or a substantial change kinds of difficulties. The In effect
which in software requirements upon which the design design and which
everything in
and/orand one canrequired.codeeffect design hasoverrunnotlikelythese kinds of difficulties.the up to will process hasto substantial the origin anddisruptiveexpect Theto will
costs. difficulties. The
xpect up be lO0-percent a substantial change in the of difficulties.development process code will are schedule in and one canthe developmentlO0-percent overrunnot schedule kinds one can required. required design overrun are fix these in the of difficulties.
he development process codereturned fix the origin
has will violated. Either design is the
in to these expect uprequired changes violated. origin the requirements The required design a will are likely Either the design is that the be effect
mustto lO0-percent substantial change in fix Either disruptive expect required. beeffect codereturnedin fix to
to change in the requirements up
code
ents mustto a modified, or overrunnot schedule kindsthe requirementsThe In bea modified, or areturned to the to be sothedesign isthat must In a modified, or changesviolated.these be so of difficulties. must In a modified, or changesnot schedule kinds disruptiverequir lO0-percent a substantial change be so design is that
code will in likely to
therand one canrequirementsbea modified, or overrun is based and which software requirementsbea modified, hasare
gin the requirements mustto upon process hasdesign violated. origin the provides the developmentlO0-percent overrun is toschedule in and one canrequirementsIn a modified,has returnedisto schedule inand one canrequirementsbeafor everything design in schedule whi
expect up
the development which
lO0-percent a returned to change in anddesign is the rationale upon which theadesignviolated. and
substantial the Either the one can required. In for process or returnedinbased origin the design the development lO0-percent overrun in the origin the requirementsrationale effect
in schedule requirements mustto effect
expect up substantial the Either the requirements mustto upon which or adesign
change software isexpect up befor
required. process
effect substantial changeEither software is required. to upon which or overrun
violated. and design expect up In modified,
must lO0-percent a substantial change in
denote software cannot, of one can expect the the aanalysis andhasdesign thatschedule whichofprovideseverything the uponOne andhasarewhichisprovides the rationale can everything toanalysisbasedcode whichistoschedule which one can expect the toupon is based andare
returned costs.the software requirements
the development One
lO0-percent code phases.to the origin and skipping-over of to analysis might returned there has which provides expect the area process has returned provides the and
and/or that One originbeen a skipping-over up toupon processtheoverrun costs.One cannot, software requirements forlO0-percentand/or that toOne and beenof one
t phases.to there has and of and/or is there has
note in the rationale a process the note costs.schedule
expect up which code phases. the origin and skipping-overrationale for everything design
design a the ofup the and
requirements upon which the are phases. One origin software requirementsare lO0-percent overru
whichmight returnedbased and been aone canthe development everything overrun inbased cannot, software the developmentlO0-percent overrun inbased cannot, of provides the rationaleafor everything desigthe and up which the
ment process hasand/orthe to the origin and one can the development process has returned to the origin and In be can expect or ato a lO0-percentEither costs. schedule and oneeffect development lO0-percent returned design is required. one effect
Either costs.
returned expect up to a lO0-percent and/or costs.
overrun design is
in schedule one and/or the to
the development process has overrun in the origin must be can expect up to a process has overrun in schedule and be can expect up to a
up returned the to the origin
edanalysis h o umight note violated. cannot, must be modified,mustthe analysis o umightsubstantial therecannot,theseskipping-over must substantialumighta notethe design isEithertheseskipping-over of thesubstantial changesubstantial change in the design is required. a In ef
ftware violated.code phases.requirements the a skipping-over orsoftware w i t h and these phases.requirements must phases are managedanalysisoandthese inandviolated. cannot, costs.In modified,must Inanalysis and oreasein the requirements must In modified,must subs
e with wrelative theseand thatOne Either of requirements managed modified, t code steps, but generally the requirements of the effectviolated.code steps, but change been adesign is are managed withviolated.code phases. One cannot, the requirements or be m
i t andt ease steps, but generally these phases are of a substantial change in andviolated. required. design modified, software w i trelative easephases.requirements the requirements or a beeffect
One there and/or costs.
has been course, produce be withviolated. aEither the One and/or costs. effect
relative ease thethat change in been course,isproduce
One or note Either of a
has the withOne changesubstantial generally the phases required.
required. In be modified, h t or required.
One has in
that there and/or of relative Either the
modified, a andviolated. Either of
skipping-over of the analysis andhas returned toOne cannot, of one can expect up theaanalysis andhas returned schedule been aone can the development process hasoverrun
. One might note that there and/or costs.
code phases. the originbeen a skipping-over of to lO0-percent code phases.toOne cannot, costs.
has and One might note that there origin of skipping-over of the analysis and code phases. there and/or and one canthe development process code phases. One cannot, of
has
and/or One might note that schedule beenof skipping-over of the analysis and
One hascannot,costs.
a
on requirements,softwarethe development process might impactareOne cannot,managed with relative overrun processgenerally andon wholecannot, ofaone a lO0-percenteasesteps, intoandhasoverrun intoOne cannot, of onewith expecthas overrun in schedule phases.tosche
whole the development process of easeanalysis but generally these there has been one can expect up ease steps, butthe code phases.tophasesdepartments with expectof to a lO0-percent notethese there origin and to a lO0-percentthe and to the code and onethe
there produce skipping-over
are managed relative the my One little there on the origin development process of thea andin
and code phases.
the my One might notethese requirements, up skipping-over up returned but the origin are the expect up
have little there are One has and to expect
course,has been a design, and testing. In steps,have has returned to wholeproduce software and testing.to Inanalysis andhas returnedcourse, produce software andrelative the analysis might returned whole has been a skipping-over ofup to analysis andhas overrun in One
phasesdepartments with without theseand experience note that phasesdepartments course, are and a skipping-over these lO0-percent overrun thatschedule arebeen design, without these and experience therethat phasesdepartments can relative ease a lO0-percent returned
requirements, design, without
of the development experienceimpact in there originmanaged canthetesting. In my process code phases. schedule managed
the development One generally are
returned
the development process
origin ca
e might notethese there has been software wrelative these and One might notethese One cannot, of a skipping-overt of easesteps, but might notethese there cannot, software w i t h o u t of easeanalysis and code phases.there has beenof skipping-over of easeanalysis and
ut generally thatcourse, produce a skipping-overuof easeanalysisbut generally that thereproduce software w i trelative the analysis and code phases. phases arebeen a skipping-over these steps, but might notethese phasescannot, a
and/or costs.phases are managed with iconsumed with the mathematical costs.phases arebeen
t h o t the steps, and code phases.and/or optimization spacecraft with consumed with the analysis of orbit course, produce of
course, has managed h o u these and One generally that One has managed with relative the andOne generally that One are managed with relative the and
and/or costs. and/or costs.
hout these impact but requirements, design, and testing. In mywithoutlittle ofand are whole and/or these phases are managed with experience impactare whole and/or these phases are determination, relative easesteps, but generally these phases are managed with relative
have littlethere optimization spacecraft attitude determination,have these steps, on requirements, design, and testing. In mywithout these steps,on requirements, design, and testing. In withexperience there optimization
mathematical areon generally these phases produce software relative easeimpact mechanics,
perience of orbit mechanics, costs.
analysis steps, whole and/or departments course, are managed with experience there but generally costs. attitude determination,relative ease and mechanics, spacecraft attitude managed mywithout these andare whole and/or costs.
analysis orbit departmentscourse, produce software have little there optimization
mathematical but generally costs.
departmentscourse, produce software mathematical departments
duce software wexperience note thaton requirements,a design, and testing. Inwithwexperience impactareOnegenerally of design, and testing. Inanalysis o ulittleeasesteps, but generally these phases are managed mywexperience note that wholecannot,these phases are ma
testing. In my One u t little there are whole has been course, produce software One u little note that whole has been a skipping-over of the withhave might impact are whole has been design, and testing.the analysisoand these steps, but generally ofa skipping-over o
i t have theseimpact but generally these phases are managed my relativethese and on there departments
h o might steps, there departments ihave t ease steps, but cannot, these phases are managed mywexperience note that requirements, course, produce software One u t code and
tho there requirements, course, produce software i trelative there on One departments
h and these and
t code In withi t h mightease are One departments
relative there
difficultforth, complex work, departments have completed theirbeenso skipping-over might of departments have completed cannot, determination,whenof the analysis therecannot, of a skipping-over of a skipping-over of the analysistherecode been
and so and but mathematical optimization note thatskipping-over determination, when work, orbit mechanics,phases. Oneattitude of a skipping-over these phases. and code spacecraft attitudebeen
when these orbit mechanics, spacecraft attitude of a forth, but and code analysis and code note that there has difficult with butOne
of payload activityconsumed with complex the phases.
and the analysis mathematical optimization payload activityconsumed and the analysis of departments have phases. there cannot, of and complex work, phases. and has phases. there cannot,
difficult and the analysis these of spacecraft their been forth, complex work, orbitOne might note that One has difficult
and so completed their determination, mathematical optimization note that One has been
ments, design, and testing. In my One might there areon requirements, design, and testing. In my One might impact onwhole departments
consumed with the analysis of
e determination, experience impact whole has
have little there departments of testing. In my experience there on requirements, design, and testing. In my One might there are whole departm
experience there are requirements, design, and mathematical optimizationimpactare whole departments
have little mechanics,
have little experience

58. realidade #2
=D
Problemas
Problemas Problemas
Problemas Problemas
Problemas Problemas Problemas Problemas Problemas
Projeto
Problemas Problemas Problemas
Problemas
Problemas
Problemas

59. lidando com mudanças
na realidade #1

60. realidade #1
• é rápido e indolor
• re-priorizar o backlog (lista de features)
• reunião de sprint planning
• resolve-se tudo em apenas uma reunião

61. realidade #2
Custo da Mudança
Custo de mudança
Tempo
realidade #1
realidade #2 (metodologias ágeis)

62. entregas
na realidade #2

63. realidade #2
% pronto
2 meses de projeto
Projeto 25%
Uso ~25%

64. realidade #2
Entrega de Valor
Valor Entregue
Tempo
realidade #1
realidade #2 (metodologias ágeis)

65. faz sentido?

66. Evolução da Taxa de Sucesso
em Projetos de Software
37%!
35%!
34%!
32%!
29%!
28%!
27%!
26%!
16%!
1994! 1996! 1998! 2000! 2002! 2004! 2006! 2008! 2011!
Fonte: Standish Group, CHAOS Report

67. Metodologias Ágeis

68. Lean vs. Scrum vs. XP
Qual é melhor?

69. Lean - origens
• resposta da Toyota para sua crise, 1950
• precisava de “cash” no caixa(reduzir o inventário)
• reduzir custos
• melhorar qualidade

70. Lean
• Pull vs. Push Systems
• Kanban
• Pensamento Sistêmico
• Fluxo Equilibrado
• Células de Trabalho
• Melhoria Contínua

71. Scrum
!"#$%&'(
)*+,"(
-&"%.(
/01',"(
23%45,(

72. Scrum
<7,7*97(!,*1101-( ./"01'(!,*1101-( =*0,>(?9@( =76#( <7'"#9/7&5A*(
!"#$%&'()*&+,#-( ./"01'( .01&"#102*34#( .#BC*"7(
)*&+,#-( $#(567( D%1&0#1*,( 809'*(/*"*(
:7,;#"0*9(