![Page 1: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/1.jpg)
As reais razões do porque eu devo ser Ágil
São Paulo, 19 de novembro de 2011.
![Page 2: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/2.jpg)
Ruby on Rails
Coaching Consultoria
Planejamento
![Page 3: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/3.jpg)
somos referência
![Page 4: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/4.jpg)
![Page 5: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/5.jpg)
9º projeto mais popular
250.000 views/mês
![Page 6: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/6.jpg)
à venda na
![Page 7: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/7.jpg)
Evolução
![Page 8: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/8.jpg)
a tecnologia está evoluindo
![Page 9: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/9.jpg)
e a maneira que fazemos software também...
![Page 10: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/10.jpg)
Fonte: Standish Group, CHAOS Report
16%!
27%!26%!
28%!
34%!
29%!
35%!
32%!
37%!
1994! 1996! 1998! 2000! 2002! 2004! 2006! 2008! 2011!
Evolução da Taxa de Sucessoem Projetos de Software
![Page 11: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/11.jpg)
mas ainda há
63%para avançar
![Page 12: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/12.jpg)
O que causou esta melhora nos últimos 15 anos?
![Page 13: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/13.jpg)
13
1970 1980 1990 2000 2010
![Page 14: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/14.jpg)
70’s
![Page 15: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/15.jpg)
15
Managing the development of large software systemsDr. Winston W. Royce (11 pages)
![Page 16: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/16.jpg)
16
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
Figure 2. Implementation steps to develop a large computer program for delivery to a customer.
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
![Page 17: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/17.jpg)
Engenharia de Software
![Page 18: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/18.jpg)
heavy weight processes
![Page 19: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/19.jpg)
80’s
![Page 20: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/20.jpg)
![Page 21: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/21.jpg)
Custo de mudança
21
Fase do projeto
Cus
to d
e M
udan
ça
![Page 22: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/22.jpg)
a tentativa em 80’s...
![Page 23: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/23.jpg)
23
1980’s
=Controlar Processos Reduzir Custos
![Page 24: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/24.jpg)
TI orientada a Cu$to$
![Page 25: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/25.jpg)
90’s
![Page 26: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/26.jpg)
![Page 27: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/27.jpg)
enfim, reforços...
![Page 28: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/28.jpg)
forte adoção
ProgramaçãoOrientada a Objetos
![Page 29: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/29.jpg)
surgem os primeiroslight weight processeslight
![Page 30: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/30.jpg)
Scrum
CrystalClear
eXtremeProgramming
Adaptive Software Development
Feature DrivenDevelopment
Dynamic Systems Development Method
1995~1996
![Page 31: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/31.jpg)
o resultado...
![Page 32: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/32.jpg)
Custo de mudança
32
“Waterfall” (1970)
Novas abordagens 1990’s
Cus
to d
a M
udan
ça
Tempo
![Page 33: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/33.jpg)
a conclusão...
![Page 34: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/34.jpg)
34
1990’s
=Cicloscurtos
Entregas Constantes de Valor
![Page 35: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/35.jpg)
TI orientada a Geração de Valor
![Page 36: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/36.jpg)
2000’s
![Page 37: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/37.jpg)
O Manifesto Ágil
![Page 38: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/38.jpg)
Individuals and interactions over processes and tools
Fonte: http://agilemanifesto.org
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:
That is, while there is value in the items onthe right, we value the items on the left more.
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
![Page 39: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/39.jpg)
2010’s
![Page 40: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/40.jpg)
duas realidadesem projetos...
![Page 41: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/41.jpg)
realidade #1
![Page 42: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/42.jpg)
equipesna realidade #1
![Page 43: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/43.jpg)
equipe de especialistas
passagem de bastão = empurrar o problema
realidade #1
![Page 44: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/44.jpg)
execução do projetona realidade #1
![Page 45: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/45.jpg)
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
requisitos mudam
não condiz com os requisitos
sempre atrasa
não há tempo
espero que funcione
realidade #1
![Page 46: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/46.jpg)
realidade #1
ProblemasProblemas
Problemas
Problemas
Problemas
Problemas
Problemas
Problemas
Problemas
Problemas
Problemas
Problemas
Problemas
ProblemasProblemas
Problemas
Projeto
é tarde de mais!:(
![Page 47: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/47.jpg)
lidando com mudançasna realidade #1
![Page 48: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/48.jpg)
• processo lento e desgastante
• change requests
• adendo de contratos
• consome muito tempo e dinheiro
realidade #1
![Page 49: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/49.jpg)
Custo de mudançaC
usto
da
Mud
ança
Tempo
realidade #1
![Page 50: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/50.jpg)
entregasna realidade #1
![Page 51: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/51.jpg)
Requisitos Design Coding IntegraçãoTestes Deploy
25%
% prontorealidade #1
0%
Projeto
Uso
2 meses de projeto
![Page 52: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/52.jpg)
Entrega de Valor
Tempo
Valo
r E
ntre
gue
realidade #1
![Page 53: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/53.jpg)
realidade #2
![Page 54: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/54.jpg)
equipesna realidade #2
![Page 55: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/55.jpg)
realidade #2
Times multi-disciplinaresformados por Generalistas Especialistas
![Page 56: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/56.jpg)
execução do projetona realidade #2
![Page 57: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/57.jpg)
realidade #2
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
Sprint 1I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
Sprint 2I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
Sprint ...I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
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 problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
Sprint n
![Page 58: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/58.jpg)
realidade #2
ProblemasProblemas
Problemas
Problemas
Problemas
Problemas
Problemas
ProblemasProblemas
Problemas
Problemas
Problemas
Problemas
Problemas Problemas
Problemas
Projeto
=D
![Page 59: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/59.jpg)
lidando com mudançasna realidade #1
![Page 60: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/60.jpg)
• é rápido e indolor
• re-priorizar o backlog (lista de features)
• reunião de sprint planning
• resolve-se tudo em apenas uma reunião
realidade #1
![Page 61: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/61.jpg)
Custo de mudançaC
usto
da
Mud
ança
Tempo
realidade #2
realidade #2 (metodologias ágeis)
realidade #1
![Page 62: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/62.jpg)
entregasna realidade #2
![Page 63: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/63.jpg)
25%
% prontorealidade #2
Projeto
Uso
2 meses de projeto
~25%
![Page 64: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/64.jpg)
Entrega de Valor
Tempo
Valo
r E
ntre
gue
realidade #2
realidade #2 (metodologias ágeis)
realidade #1
![Page 65: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/65.jpg)
faz sentido?
![Page 66: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/66.jpg)
Fonte: Standish Group, CHAOS Report
16%!
27%!26%!
28%!
34%!
29%!
35%!
32%!
37%!
1994! 1996! 1998! 2000! 2002! 2004! 2006! 2008! 2011!
Evolução da Taxa de Sucessoem Projetos de Software
![Page 67: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/67.jpg)
Metodologias Ágeis
![Page 68: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/68.jpg)
Qual é melhor?
Lean Scrum XPvs. vs.
![Page 69: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/69.jpg)
Lean - origens
• resposta da Toyota para sua crise, 1950
• precisava de “cash” no caixa (reduzir o inventário)
• reduzir custos
• melhorar qualidade
![Page 70: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/70.jpg)
Lean
• Pull vs. Push Systems
• Kanban
• Pensamento Sistêmico
• Fluxo Equilibrado
• Células de Trabalho
• Melhoria Contínua
![Page 71: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/71.jpg)
Scrum!"#$%&'()*+,"(
-&"%.(/01',"(
23%45,(
![Page 72: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/72.jpg)
!"#$%&'()*&+,#-( ./"01'()*&+,#-(
.01&"#102*34#($#(567( 809'*(/*"*(
:7,;#"0*9(
<7,7*97(!,*1101-( ./"01'(!,*1101-( =*0,>(?9@( =76#( <7'"#9/7&5A*(
.#BC*"7(D%1&0#1*,(
Scrum
![Page 73: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/73.jpg)
XP
• Test Driven Development
• Integração Contínua
• Entendimento Comum
• Pair-programming
• Ritmo sustentável
![Page 74: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/74.jpg)
Qual é melhor?
Lean Scrum XPvs. vs.
![Page 75: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/75.jpg)
É melhor!
Lean Scrum XP+ +
![Page 76: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/76.jpg)
Lean + Scrum + XP
![Page 77: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/77.jpg)
Tradicional Agileplanejar para antecipar “todos” os problemas
detectar problemase remover impedimentos
decisões são tomadaso quanto antes
decisões são adidaso máximo possível
passagem de bastãoentre especialistas
equipe unificadae multi-disciplinar
the big release(feedback tarde)
entregas contínuas(feedback contínuo)
perde-se tempo comnegociação com o cliente
gera-se valor comcolaboração com o cliente
obedecer o processo para controlar custos
ajustar o processo para otimizar a entregar de valor
seguir um plano responder à mudanças
vs.
![Page 78: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/78.jpg)
Quem usa Agile?
![Page 79: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/79.jpg)
![Page 80: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/80.jpg)
http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation
![Page 81: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/81.jpg)
2000 2001 2002 2003 2004 2005 2006 2007
Features Delivered per Team
Days between Major Releases
Transformation Results
![Page 82: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/82.jpg)
+94 Increase in feature requests delivered -
2007 v. 2006
%
![Page 83: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/83.jpg)
+38 Increase in feature requests delivered per
developer - 2007 v. 2006
%
![Page 84: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/84.jpg)
Agile has delivered total visibility, total transparency and unbelievable productivity! a complete win! ”
Steve Fisher Sr. Vice President, Platform Product
Management Salesforce.com
“
![Page 85: As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo](https://reader036.vdocuments.site/reader036/viewer/2022081400/55593352d8b42a4f3d8b4a1e/html5/thumbnails/85.jpg)
568% more value
delivered in the first year
of being agile.
fonte: Greene and Fry 2008.