• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo
 

As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo

on

  • 350 views

 

Statistics

Views

Total Views
350
Views on SlideShare
350
Embed Views
0

Actions

Likes
1
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo As reais razões do porque eu devo ser Ágil - Agile Tour São Paulo Presentation Transcript

    • As reais razões doporque eu devo ser Ágil São Paulo, 19 de novembro de 2011.
    • Planejamento Ruby on RailsCoaching Consultoria
    • somos referência
    • 9º projeto mais popular 250.000 views/mês
    • à venda na
    • Evolução
    • a tecnologia está evoluindo
    • e a maneira que fazemos software também...
    • Evolução da Taxa de Sucesso em Projetos de Software 37%! 35%! 34%! 32%! 29%! 28%! 27%! 26%! 16%! 1994! 1996! 1998! 2000! 2002! 2004! 2006! 2008! 2011!Fonte: Standish Group, CHAOS Report
    • mas ainda há 63%para avançar
    • O que causou esta melhora nos últimos 15 anos?
    • 1970 1980 1990 2000 2010 13
    • 70’s
    • Managing the developmentof large software systemsDr. Winston W. Royce (11 pages) 15
    • I SYSTE M I ANALYSIS PROGRAM DESIGN I ANALYSIS PROGRAM DESIGN I coo,.o I coo,.o TESTING TESTING I O I OPERATIONS Figure 2. Implementation steps to develop a large computer program for delivery to for delivery to a customer. Figure 2. Implementation steps to develop a large computer program a customer. I believe in this concept, but the implementation described above is risky and invites failure. T 16lem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle i
    • Engenharia de Software
    • h vy ea weight processes
    • 80’s
    • Custo de mudançaCusto de Mudança Fase do projeto 21
    • a tentativa em 80’s...
    • 1980’s = Controlar Reduzir Custos Processos 23
    • TI orientada a Cu$to$
    • 90’s
    • enfim, reforços...
    • forte adoção ProgramaçãoOrientada a Objetos
    • surgem os primeirosllight weight processes ight
    • 1995~1996 Scrum eXtreme Programming Feature Driven Development Crystal Clear Dynamic Systems Development Method Adaptive Software Development
    • o resultado...
    • Custo da Mudança Custo de mudança Tempo “Waterfall” (1970) Novas abordagens 1990’s 32
    • a conclusão...
    • 1990’s = Ciclos Entregas Constantes curtos de Valor 34
    • TI orientada aGeração de Valor
    • 2000’s
    • O Manifesto Ágil
    • Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.Fonte: http://agilemanifesto.org
    • 2010’s
    • duas realidades em projetos...
    • realidade #1
    • equipesna realidade #1
    • realidade #1 equipe de especialistaspassagem de bastão = empurrar o problema
    • execução do projeto na realidade #1
    • realidade #1 requisitos mudamI SYSTE M sempre atrasa I ANALYSIS espero que PROGRAMnão condiz com DESIGN funcione os requisitos I coo,.o TESTING I OPERATIONS não há tempo Figure 2. Implementation steps to develop a large computer program for delivery to a customer. I believe in this concept, but the implementation described above is risky and invites failure. The
    • realidade #1 é tarde de mais! :( Problemas Problemas Problemas Problemas Problemas Problemas Problemas Problemas ProblemasProjeto Problemas Problemas Problemas Problemas Problemas Problemas Problemas
    • lidando com mudanças na realidade #1
    • realidade #1• processo lento e desgastante • change requests • adendo de contratos • consome muito tempo e dinheiro
    • realidade #1Custo da Mudança Custo de mudança Tempo
    • entregasna realidade #1
    • realidade #1% pronto 2 meses de projeto Requisitos Design Coding Testes Integração DeployProjeto 25% Uso 0%
    • realidade #1 Entrega de ValorValor Entregue Tempo
    • realidade #2
    • equipesna realidade #2
    • realidade #2 Times multi-disciplinaresformados por Generalistas Especialistas
    • execução do projeto na realidade #2
    • realidade #2 I SYSTE M I SYSTE MYSTE M I SprintSYSTEM SYSTE I M1 I SYSTE M I SYSTE M I Sprint 2 SYSTE M I SYSTE M I SYSTE M I SYSTE M I Sprint ... I SYSTE M I SYSTE M SYSTE M Sprint n SYSTE M I SYSTE M I SYSTE M I SYSTE M I SYSTE M I SYSTE M I SYSTE M I SYSTE M I ANALYSIS I I I ANALYSIS I I I ANALYSIS I II ANALYSIS I ANALYSIS I ANALYSIS I ANALYSIS I ANALYSIS I ANALYSIS I ANALYSIS I ANALYSIS ANALYSIS I ANALYSIS I I I PROGRAM DESIGN ANALYSIS PROGRAM PROGRAM ANALYSIS DESIGN PROGRAM DESIGN ANALYSIS I PROGRAM DESIGN ANALYSIS PROGRAM PROGRAM DESIGNANALYSIS PROGRAM DESIGN ANALYSIS PROGRAM DESIGN I ANALYSIS PROGRAM PROGRAM DESIGNANALYSIS PROGRAM DESIGN ANALYSIS PROGRAM DESIGN ANALYSIS PROGRAM I ANALYSIS I ANALYSIS DESIGN PROGRAM DESIGN PROGRAM DESIGN PROGRAM DESIGN PROGRAMI coo,.o I I DESIGN c o o , . PROGRAM o I DESIGN c o o , .PROGRAM o DESIGN DESIGN c o o , . oPROGRAM I I DESIGN c o o , . oPROGRAM DESIGN c o o , . o I DESIGN c o o , . o PROGRAM DESIGN c o o , . o PROGRAM I I DESIGN c o o , . o I I DESIGN PROGRAM DESIGN I I I I coo,.o coo,.o I I I I coo,.o coo,.o coo,.o coo,.o I I I coo,.o coo,.o coo,.o coo,.o TESTING TESTINGo o , . o TESTINGc o o , . o TESTINGc o o , . o I I I c TESTING TESTINGo o , . o c TESTINGc o o , . o TESTING c o o , . o TESTING TESTING TESTING TESTING TESTING TESTING TESTING TESTING TESTING TESTING TESTING I OPERATIONS I OPERATIONSTESTING I OPERATIONSTESTING I OPERATIONS TESTING I OPERATIONS I OPERATIONS TESTING TESTING I OPERATIONS TESTING I OPERATIONS I OPERATIONS I OPERATIONS I OPERATIONS I OPERATIONmplementation steps to develop a large computer program for Implementation steps to develop a large computer program 2. Implementation steps to develop a large computer program for delivery to Ia customer. ivery to a customer. I OPERATIONS Figure 2. delivery to a customer. I OPERATIONS Figure for delivery toI a OPERATIONS I OPERATIONS customer. OPERATIONS I OPERATIONSer program for delivery to a customer. to develop a large computer program for delivery to a customer.to develop a large computer program 2. Implementation steps to develop a large computer program for delivery to a customer. Figure 2. Implementation steps Figure 2. Implementation steps I OPERATIONS I OPERATIONS delivery to a customer. toI a OPERATIONS I OPERATIONS program for delivery to I a customer. Figure for OPERATIONS I OPEop a large computer program for delivery to a customer. to develop a large computer program 2. Implementation steps to develop a large computer program 2. Implementation steps to develop a large computer Figure 2. Implementation steps Figure for delivery to a customer. Figure for delivery customer.and steps tofailure. The implementation described above programand steps tofailure.customer. to develop programcomputer is risky aand steps tofailure.theaimplementation describedfor Implementation steps tofailure.a customer. develop programcomputer program for n thisImplementationa steps to develop programcomputerbelieve a customer. ion concept, but thelarge computer e 2. invites develop Figure 2. delivery risky this invites develop a implementation described above a large for Implementation concept, but the large computer I is to in for delivery to a The Figure 2. Implementation steps Figure for delivery toin this invites develop large computer program 2.above is risky a customer. develop a large computer a large 2. Implementation concept, but The I believe customer. Figure program 2. Implementation steps to develop a large computer program 2. invites Figure for delivery to a customer. delivery to and delivery to The Figure forImplementation steps to a large for delivery to a custo ed in Figure risky andtesting phase but Theoccurs at the is illustrateddevelopment cycletesting phase but the occursto develop aof the computer is4. Figuretesting phaseto a the occurs to develop described above isprogram 2. invites failure. customer. develop a large comp ed aboveI is 4.cycle 2. invites failure. the implementation described abovebelieve in for delivery to which steps at theisend described above programthis invites failure. customer. at the end a large development cycle forthe development The thisImplementation steps problem end large computer program and invites failure. The problem believe in is the Figure concept, which to develop a of the in Figure 4.Figurethis the I is riskyThe 2. concept, a customer. is Implementation implementation large development Theand the illustrated in Figure risky for concept, but The I believe in 2. delivery which steps cycle is Implementation implementation of the computer risky and Implementation steps to Figure is delivery to a The mentation described above believe in this Implementation steps to develop a described above program and delivery tobutcustomer. to develop a large computer is risky and invites failure.the implementation described above isprogram 2. invites failure. customer. de I is risky and invites failure. the implementation large computerbelieve in for invites failure. the steps Figure 2. concept, but The I is risky this concept, a Figure 2. Implementation implementation described above program forconcept, buta customer. develop a large computer risky and Implementation steps to The I believe in this delivery to Figure 2. Implementation steps toThe Figure for delivery to a Theshat the endillustrated in Figure 4.transfers, etc.,isare experienced problem isTheof theinput/output4.transfers,thefirst event and which timing,isstorage, input/outputdescribedisabove arerisky and occurs at the end of the development cycle isabove is risky and invites failuproblem isstorage, development cycle isabovefirstriskywhichinvites failure. end implementation describedisabovephase which occurs at the end of the development cycletesting believewhich invites distinguished from s distinguished the input/output The testing believe in for occurs timing, the timing,the of from ept, but implementation described the I phase and which at the storage, development cycle testing believe infor invites distinguished fromin Figure 4.transfers, the phase in this concept, but the implementation described the event this concept, but illustrated in Figure as distinguished from The are experiencedproblem illustrated etc., is risky this concept, but the implementation I as failure. The The etc., is experienced as failure. The Iphase which occurs at the end of the development cycle isabove believewhich invites failure. end of the development cycletesting believewhich occurs at the end of the development The testing believewhich occurs at the endThe the development cycle isabove is ris elieve in this concept, but is illustrated in Figure 4. The testing phase in thisoccurs at theis the implementation describedisabove is risky and invites failure.illustrated in Figure 4. cycle isabove is risky and concept, but the of problem the implementation described the I is risky and concept, but illustrated in Figure 4. The problem The the phase in this concept, but the implementation described the phase in this invites failure. I problem is The I implementation described thehenomenatesting asprecisely analyzable. the end of not the in Figure 4.cycle forthe as partial analyzable. They areof theThese phenomena for which timing, analyzable.atTheyend of the developmentexperienced as partial ns4. experienced phase which occurs input/output transfers, etc., areevent is which distinguished fromat the analyzed. the in Figure 4. experienced as partial storage, input/output not the in Figure 4. cycletesting phase which occurs at the end of the development e toeventstandard partial irst The for whichdistinguished fromat They are the development to The are not phase which occurs are the are not timing, storage, problem is illustrated solutions experienced precisely storage, input/output not development cyclestandard distinguished from theis are transfers, etc., are The standard distinguished from analyzed. These phenomena standard timing, first the testing problem is illustrated solutions event are the precisely end transfers, etc., are The testing phase which occurs first to the is not problem illustrated solutions to the is the ut transfers, Figure 4.event this concept, but the occursinput/output transfers, FigureriskyTheforinvitesastiming, The occurs at theisenddescribed abovebelieve infor isinvitestiming, storage, input/outputdescribed above are experienced as distinguished from the enddes llustrated in etc., are experienced as distinguished from the enddescribed in etc., are cycle thiswhich failure. the implementation of the developmentexperienced as failure. the occurs at the end of the development The this invites failure. the occurs at first The for which timing, storage, at I believe in testing phase which implementationillustrated aboveI is problem is of the development first 4. experienced phasebut storage, input/output transfers, Figure event and whichphasebut The problem is illustrated in Figureis4. cycle is concept, but The event testing distinguished from believe andis the in concept, which problem illustrated in etc., is 4. cycletesting distinguished from first risky this the I are The concept, which implementation transfers, etc., I believe in and the phase which implementation of risky testingons nottoinput/output physicsstandard are eventthis these phenomena implementation describedfor instance. experienced as equations ofimplementation physics for aboveprecisely andthese astiming, storage, the solutionsvarious standard are experienced as distinguishedarefail mathematical various for etc.,first experienced as distinguishednottoinput/output to the standardprecisely forinvites phenomena fail from solutionsvarious are instance. experienced phenomena fail toinput/outputdescribed above is risky and invites failure.the imanalyzed.satisfy the to the are instance. in differential timing, analyzed.the solutionsvarious are etc.,isare Yet thiswhichfailure. analyzed. the a of solutions transfers, not precisely for concept, but the of fromsatisfy phenomena abovefirst event analyzable. They The nottoinput/output to the standard is event for which distinguished from torage, theThese phenomena I believe Yet analyzable. They storage, These the physics partial if which equations failmathematical transfers, not believe in if these timing, the mathematical described not believe in analyzable.failure. the not satisfy the to the are risky differential distinguished I partialand concept, but storage, These phenomena are satisfy the transfers, etc., are Yet thisinvites They are implementation transfers, etc., partial this concept, but The firstpartial if concept, but The I risky I believe inor which timing, analyzed. These phenomenastandard precisely for whichat the endillustrated in Figure 4.transfers, notfirstpartial for occurs timing,end of theinput/output tocycle standard are experienced asatTheyend of the development cyclestandard are experience nalyzable. They storage, the in Figure 4.transfers, etc., are event analyzable. They storage, the solutions to The is the phaseexperiencedproblem analyzed. the in Figure 4.transfers,thefirst partial for which timing, storage,from solutions4.transfers, the phase which oc problem is are not input/output to The testing first experienced as distinguishedthe development cycle are etc.,precisely analyzable.distinguished from solutions Theare not precisely analyzable. distinguished the in Figure to The testing partial illustrated solutions the are notphase which occurs timing,analyzed. input/output partial problem is are not These phenomena standard are which which at They storage, These phenomena testing phase which occurs of from the testing event as the is are not development the is etc., event illustrated problem is are not input/output the illustrated the is etc.,atch not redoequationsisolated They analyzed. externalphenomenatesting phase of somefail mathematicalrequired.These phenomena is the invariably aanalyzable. They areof the These phenomena are the redo of which fail to satisfy isendvarious development cycletestindifferential of somemajor redesign is required.These constraints,are notinvariably a majorto at the end of not external constraints, are not redo ofwhich of mathematicalrequired. development cyclestandard partial analyzable.atThey are of the in Figure 4. The stand s, these invariablyanalyzable. if then precisely a fail to satisfy is are physics inAFigure 4.octal patch or redo which occursredesign is are the thein simple 4.cycle standard partialsomefail to satisfy analyzed. theAsolutions4. Yet if is not precisely are or phenomena of problem the various for simple to The differential equations of problem the physics for Figure octal differential equations occurs at the is illustratedfor simple octal patch or phenomena occurs mathematical not the solutions illustrated instance. the standard precisely analyzable. They illustrated A instance. The if these phase Yet ifthen phenomena isolated these partial satisfy analyzed. development to Yet testing precisely major problem the physics in instance.to The testing phase some isolated the the not the solutions to the is th is various solutions the patch or phenomena isolated then redesign end various not Figure the these problem illustrated or instance. Yet differential equationsfail toinput/outputvarious These phenomenastandard precisely analyzable. They are transfers, instance.to Yet for theseas equations of mathematicalare transfers, instance. toYet for these astiming, analyzable. They are transfers, e if these precisely analyzable. They analyzed. for etc., first to the for these phenomena of from satisfy analyzed. the solutions event arewhich distinguished from They physicsthe solutionsevent arewhich distinguished from phenomena of mathematical physics solutions experienced as distinguished mathematical physics These phenomena if not precisely analyzable. hese phenomena for which timing, storage, first event are not satisfy the transfers, instance. Yet arewhich partial storage, input/outputvarious for etc., are experienced phenomena fail toinput/outputvariousfor etc., are experienced precisely storage, input/outputvarious sol are not the are event differential timing, if not equations fail to the not first differential timing, storage, satisfy analyzed. These phenomena ifstandard partial the standard partial the not first the not phenomena fail to satisfy the not theexternal constraints,that the event for these phenomena required. to bethe disruptive that the eventdifferential changesnot fail mathematicaldisruptive then theare ofYeta if designphenomena of mathematicaldisruptive that the areofYet for these astiming, storage, input/o to be so disruptive then redo ofYet differential changes notof toinput/outputoftransfers,then first experienced asphenomena of fromsatisfy so ofvarious for instance. experienced redesign isarefail from A be so physics for instance. experienced phenomena fail to satisfy esesimple physics for instance. requiredwhich redesign storage, these kinds various patch instance. ofYet for these code will isare fix toexternal the physics that invariablydifferential changes storage, input/output transfers, or first event if which distinguished from ematical of difficulties.first A kinds octal patch or invariably if major code willisare fix satisfy so physics for etc., invariably aifmajor redesign storage,these kinds octal patch etc., required these as equations likely satisfy the octal patch etc., The some isolated equations likely A simple octal a designtiming, fail mathematical difficulties. The required designdistinguished likely to be constraints, external constraints, or redo are some which timing, required. A simple difficulties.or The event for which timing, required. to simple various isolated equations input/output transfers, redo first some isolated major distinguished to redo some isolateddesign is required.external constraints, then redo ofYetdifferential equationsfail mathematical variouspatch instance. ofYeta if theseredesign isareof mathematical physics for instance. ofYet analyzable. They are fail to These phenomena for instance. ofYet analyzable. The equations of mathematical physics for instance. somemajor phenomenarequired.These the physics for notinvariablydifferential equations fail to These phenomena standardpreciselya if these phenomenaofnot theAsolutionsoctal patch not redo analyzed. These phenomena are not invariablyanalyzable. They is not to externalphenomena are or redo A simple octal patch or precisely a these redesign are of the solutions to the standard precisely analyzable. Theyanalyzed.the A simple octal patch not redo if isolated analyzed. satisfy constraints, then partial some isolated A simple octal major phenomena not external constraints, are orinvariablysome isolated required. satisfy the various then solutions to the major redesign is required. satisfy the variousare or precisely if these pheno partialdifferential equationsanalyzed. simple to the mathematical physics standard partial some isolatedents uponmajor redesign so disruptiveandsimple octal patch notrationalewill aare likely todesign disruptivesolutions torequiredthen invariably aare isolateddesign are not the A which provides are not redo offoraanalyzable. are so are not theAsolutions to the are not redo ofchangesaare likelythearekinds is basedThese phenomena arethen redo ofupon not fix redesign so is not theand which providesaredesign changesanalyzable. are so is basedexternalphenomena standard changes are likely to They disruptive that phenomena standard partiacode for everything designrequired.external constraints, the precisely analyzable. They analyzed. externalthe octal patch not redo of for not fix theto Theyis disruptive that the octal patch orinvariably everything be analyzed. These the octal patch or precise nale will not fix these analyzed. ariably which to be is of difficulties. The required designcode somewhich the are is required.These phenomena the or codeupon which these be analyzed. andsolutions requiredthen precisely major redesign is required. Athat the software requirements for everything be areof difficulties. constraints, which provides or invariably major these kinds based A simple changes isolated that The the requirements will everything kinds required.These constraints, the rationale some isolated software standard precisely major redesign rationale some likely partial of difficulties. The to the design partial simple simplenstraints, then invariably aare likely to be so disruptive A instance. requiredthen redo ofwill aare fix these be so disruptive A instance. Yetpatch orinvariably not fail mathematicalofvarious for instance. Yetpatch or redo of some likely satisfy so disruptive A instance. Ye required design code will not fix redesign is required. for simple octal patchdesign changes notisolatedto kinds various external the octal differential changesaarefix toredesign so disruptive A simple octal differential changesaarefailmathematicalrequired. for simple octa differential changes major these kinds physics external The Yet differential equations of to redesign is required. for simple requiredthen code willsomeof these kinds required. that the requiredthen invariably majorto to be the physics that the equations of mathematical of difficulties.the that constraints, these invariably faillikely if or phenomena major satisfy the of difficulties. The code some mathematical physics that constraints,if these redo of design equations likelysatisfy the physics phenomena isolated be is major to difficulties. The external constraints, if designphenomena ofisolated these equations redesign is variousof requirements The In be differentialor are will are likelythese kindssoftwareforrequired. Inupon everythingaare violated.these bethesoftware is required. In Yet if theseor changesnotbased and kinds disruptiverequired. In effect designphenomena of mathematicaldisrupsoftware requirements effect which thea designviolated. to be sotheof difficulties.the design is required. required design code e difficulties.rationale upon provides the must for everything substantial change which design isthat rationale effect design changes notof to satisfy thedisruptive the rationale effect design a design are fixmathematicalofvarious for instance. Yet everything are modified, changes notbased and in thephysics requirementsbe forif these phenomenaarebased and kinds various requirementsbe for everything are of mathematicaldisruptive the must required equations is fix Either provides instance. Yet differential equations likely Either so of difficulties. must required requirements The modified, or design is fix which the substantial mathematical design for instance. upon which theequations failchange which design is the rationale for if these changes arefail to satisfyso physi code will fail change which physics that the to in requirements The provides modified, code will is of to satisfythe provides that the required differential substantiallikely to in so physics phenomena these be the difficulties. The differential equations likely to be the variootbased external constraints,requirements uponmajor redesign is are based external constraints, that rationalesomewhich the design notbased externalso disruptive theor the required design changes is based external so ofoctal patch or invariably a everything are is are lik fix these kinds software the rationale fora everything arewill required. and kinds octal patch or the of upon everything are is are fix these kinds of difficulties.rationale forawhich the design not fix these kinds disruptivethe rationale for major redesign requir and which of difficulties. invariably provides then The required which the design not likely to simple of difficulties. redo requiredisolated changes is likely to which provides then invariably everything are is are likely to which provides then The required design changes changes is fix thesebe so software requirements fora major redesign required.and simple octal patch design code A which provides the invariably disruptive then The design code will A be software requirements of some isolated will required. A simple difficulties. the of some isolated constraints, that The upon major code redo redesign and be constraints, that redoviolated. overrunthebasedexternal andprovides requirementssubstantial change in is thedesign external must In effectthe rationale somewhich hasEither therequired.and which one canrequirementssubstantial changeare theis basedexternal constraints, the orinvariably aeveryt -percent Either is to the origin constraints, the developmentlO0-percent Eithertheis to the is required. one can expectinvariablylO0-percent overrun istoschedule simple providesexpect invariably aeverything design required. required. provides thenrationale for major rocessthe design in schedule which software the rationale uponmajor redesign required. and which octal patch development processchange in theinbasedexternalmustoctalmodified, or atoof for which theoverrun in schedule which octal patch tial changereturned requirements must becan then invariably aeverything arewhich has in the design is required. one modified, or ato for process hasoverrun inbased origin and provides then redo ato uponviolated.thereturned design origin and In effectthe or redo upon major redesign is design is A simple In effect and In effect expect up a violated. returned requirements constraints, or or of a aeverything design requirements constraints, thenrationalea some isolated in which the design schedulesimplesoftware the A be modified, up substantial redesign is requirements for major isolated are the is required. be patch A software up lO0-percent and redo of some isoquirementssubstantial change kinds is based is required. providesrequirementssubstantial change kinds is requirements must requiredthe rationale for are likely Either so disruptive required. provides the rationale fornot fix these are theis based is required. provides the r ified, or a uponnot fix these in the of requirements The requiredthe rationaleuponnot fix these in the ofbased isthatwhich provides designcode uponnot fix theseare theisrequirements must be effect design changes are likely to be so disruptive that the required desi code will violated. Either the difficulties. must be modified, or a willare likelythe are sothe design and/or costs. In effect which the design design and whichsoftware design changes violated. to be In effect which Either disruptive and the software requirementssubstantial change be for everything design difficulties. The be modified, or changesviolated. the design ofbased is that the required required. a everything kinds design and which In modified, or a substantial change kinds of difficulties. The In effect which in software requirements upon which the design design and which everything in and/orand one canrequired.codeeffect design hasoverrunnotlikelythese kinds of difficulties.the up to will process hasto substantial the origin anddisruptiveexpect Theto will costs. difficulties. The xpect up be lO0-percent a substantial change in the of difficulties.development process code will are schedule in and one canthe developmentlO0-percent overrunnot schedule kinds one can required. required design overrun are fix these in the of difficulties. he development process codereturned fix the origin has will violated. Either design is the in to these expect uprequired changes violated. origin the requirements The required design a will are likely Either the design is that the be effect mustto lO0-percent substantial change in fix Either disruptive expect required. beeffect codereturnedin fix to to change in the requirements up code ents mustto a modified, or overrunnot schedule kindsthe requirementsThe In bea modified, or areturned to the to be sothedesign isthat must In a modified, or changesviolated.these be so of difficulties. must In a modified, or changesnot schedule kinds disruptiverequir lO0-percent a substantial change be so design is that code will in likely to therand one canrequirementsbea modified, or overrun is based and which software requirementsbea modified, hasare gin the requirements mustto upon process hasdesign violated. origin the provides the developmentlO0-percent overrun is toschedule in and one canrequirementsIn a modified,has returnedisto schedule inand one canrequirementsbeafor everything design in schedule whi expect up the development which lO0-percent a returned to change in anddesign is the rationale upon which theadesignviolated. and substantial the Either the one can required. In for process or returnedinbased origin the design the development lO0-percent overrun in the origin the requirementsrationale effect in schedule requirements mustto effect expect up substantial the Either the requirements mustto upon which or adesign change software isexpect up befor required. process effect substantial changeEither software is required. to upon which or overrun violated. and design expect up In modified, must lO0-percent a substantial change indenote software cannot, of one can expect the the aanalysis andhasdesign thatschedule whichofprovideseverything the uponOne andhasarewhichisprovides the rationale can everything toanalysisbasedcode whichistoschedule which one can expect the toupon is based andare returned costs.the software requirements the development One lO0-percent code phases.to the origin and skipping-over of to analysis might returned there has which provides expect the area process has returned provides the andand/or that One originbeen a skipping-over up toupon processtheoverrun costs.One cannot, software requirements forlO0-percentand/or that toOne and beenof one t phases.to there has and of and/or is there has note in the rationale a process the note costs.schedule expect up which code phases. the origin and skipping-overrationale for everything design design a the ofup the and requirements upon which the are phases. One origin software requirementsare lO0-percent overru whichmight returnedbased and been aone canthe development everything overrun inbased cannot, software the developmentlO0-percent overrun inbased cannot, of provides the rationaleafor everything desigthe and up which the ment process hasand/orthe to the origin and one can the development process has returned to the origin and In be can expect or ato a lO0-percentEither costs. schedule and oneeffect development lO0-percent returned design is required. one effect Either costs. returned expect up to a lO0-percent and/or costs. overrun design is in schedule one and/or the to the development process has overrun in the origin must be can expect up to a process has overrun in schedule and be can expect up to a up returned the to the origin edanalysis h o umight note violated. cannot, must be modified,mustthe analysis o umightsubstantial therecannot,theseskipping-over must substantialumighta notethe design isEithertheseskipping-over of thesubstantial changesubstantial change in the design is required. a In ef ftware violated.code phases.requirements the a skipping-over orsoftware w i t h and these phases.requirements must phases are managedanalysisoandthese inandviolated. cannot, costs.In modified,must Inanalysis and oreasein the requirements must In modified,must subs e with wrelative theseand thatOne Either of requirements managed modified, t code steps, but generally the requirements of the effectviolated.code steps, but change been adesign is are managed withviolated.code phases. One cannot, the requirements or be m i t andt ease steps, but generally these phases are of a substantial change in andviolated. required. design modified, software w i trelative easephases.requirements the requirements or a beeffect One there and/or costs. has been course, produce be withviolated. aEither the One and/or costs. effect relative ease thethat change in been course,isproduce One or note Either of a has the withOne changesubstantial generally the phases required. required. In be modified, h t or required. One has in that there and/or of relative Either the modified, a andviolated. Either ofskipping-over of the analysis andhas returned toOne cannot, of one can expect up theaanalysis andhas returned schedule been aone can the development process hasoverrun . One might note that there and/or costs. code phases. the originbeen a skipping-over of to lO0-percent code phases.toOne cannot, costs. has and One might note that there origin of skipping-over of the analysis and code phases. there and/or and one canthe development process code phases. One cannot, of has and/or One might note that schedule beenof skipping-over of the analysis and One hascannot,costs. aon requirements,softwarethe development process might impactareOne cannot,managed with relative overrun processgenerally andon wholecannot, ofaone a lO0-percenteasesteps, intoandhasoverrun intoOne cannot, of onewith expecthas overrun in schedule phases.tosche whole the development process of easeanalysis but generally these there has been one can expect up ease steps, butthe code phases.tophasesdepartments with expectof to a lO0-percent notethese there origin and to a lO0-percentthe and to the code and onethe there produce skipping-over are managed relative the my One little there on the origin development process of thea andin and code phases. the my One might notethese requirements, up skipping-over up returned but the origin are the expect up have little there are One has and to expect course,has been a design, and testing. In steps,have has returned to wholeproduce software and testing.to Inanalysis andhas returnedcourse, produce software andrelative the analysis might returned whole has been a skipping-over ofup to analysis andhas overrun in One phasesdepartments with without theseand experience note that phasesdepartments course, are and a skipping-over these lO0-percent overrun thatschedule arebeen design, without these and experience therethat phasesdepartments can relative ease a lO0-percent returned requirements, design, without of the development experienceimpact in there originmanaged canthetesting. In my process code phases. schedule managed the development One generally are returned the development process origin ca e might notethese there has been software wrelative these and One might notethese One cannot, of a skipping-overt of easesteps, but might notethese there cannot, software w i t h o u t of easeanalysis and code phases.there has beenof skipping-over of easeanalysis and ut generally thatcourse, produce a skipping-overuof easeanalysisbut generally that thereproduce software w i trelative the analysis and code phases. phases arebeen a skipping-over these steps, but might notethese phasescannot, a and/or costs.phases are managed with iconsumed with the mathematical costs.phases arebeen t h o t the steps, and code phases.and/or optimization spacecraft with consumed with the analysis of orbit course, produce of course, has managed h o u these and One generally that One has managed with relative the andOne generally that One are managed with relative the and and/or costs. and/or costs.hout these impact but requirements, design, and testing. In mywithoutlittle ofand are whole and/or these phases are managed with experience impactare whole and/or these phases are determination, relative easesteps, but generally these phases are managed with relative have littlethere optimization spacecraft attitude determination,have these steps, on requirements, design, and testing. In mywithout these steps,on requirements, design, and testing. In withexperience there optimization mathematical areon generally these phases produce software relative easeimpact mechanics, perience of orbit mechanics, costs. analysis steps, whole and/or departments course, are managed with experience there but generally costs. attitude determination,relative ease and mechanics, spacecraft attitude managed mywithout these andare whole and/or costs. analysis orbit departmentscourse, produce software have little there optimization mathematical but generally costs. departmentscourse, produce software mathematical departmentsduce software wexperience note thaton requirements,a design, and testing. Inwithwexperience impactareOnegenerally of design, and testing. Inanalysis o ulittleeasesteps, but generally these phases are managed mywexperience note that wholecannot,these phases are ma testing. In my One u t little there are whole has been course, produce software One u little note that whole has been a skipping-over of the withhave might impact are whole has been design, and testing.the analysisoand these steps, but generally ofa skipping-over o i t have theseimpact but generally these phases are managed my relativethese and on there departments h o might steps, there departments ihave t ease steps, but cannot, these phases are managed mywexperience note that requirements, course, produce software One u t code and tho there requirements, course, produce software i trelative there on One departments h and these and t code In withi t h mightease are One departments relative there difficultforth, complex work, departments have completed theirbeenso skipping-over might of departments have completed cannot, determination,whenof the analysis therecannot, of a skipping-over of a skipping-over of the analysistherecode been and so and but mathematical optimization note thatskipping-over determination, when work, orbit mechanics,phases. Oneattitude of a skipping-over these phases. and code spacecraft attitudebeen when these orbit mechanics, spacecraft attitude of a forth, but and code analysis and code note that there has difficult with butOne of payload activityconsumed with complex the phases. and the analysis mathematical optimization payload activityconsumed and the analysis of departments have phases. there cannot, of and complex work, phases. and has phases. there cannot, difficult and the analysis these of spacecraft their been forth, complex work, orbitOne might note that One has difficult and so completed their determination, mathematical optimization note that One has beenments, design, and testing. In my One might there areon requirements, design, and testing. In my One might impact onwhole departments consumed with the analysis of e determination, experience impact whole has have little there departments of testing. In my experience there on requirements, design, and testing. In my One might there are whole departm experience there are requirements, design, and mathematical optimizationimpactare whole departments have little mechanics, have little experience
    • realidade #2 =D Problemas Problemas Problemas Problemas Problemas Problemas Problemas Problemas Problemas ProblemasProjeto Problemas Problemas Problemas Problemas Problemas Problemas
    • lidando com mudanças na realidade #1
    • realidade #1• é rápido e indolor • re-priorizar o backlog (lista de features) • reunião de sprint planning • resolve-se tudo em apenas uma reunião
    • realidade #2Custo da Mudança Custo de mudança Tempo realidade #1 realidade #2 (metodologias ágeis)
    • entregasna realidade #2
    • realidade #2% pronto 2 meses de projetoProjeto 25% Uso ~25%
    • realidade #2 Entrega de ValorValor Entregue Tempo realidade #1 realidade #2 (metodologias ágeis)
    • faz sentido?
    • Evolução da Taxa de Sucesso em Projetos de Software 37%! 35%! 34%! 32%! 29%! 28%! 27%! 26%! 16%! 1994! 1996! 1998! 2000! 2002! 2004! 2006! 2008! 2011!Fonte: Standish Group, CHAOS Report
    • Metodologias Ágeis
    • Lean vs. Scrum vs. XP Qual é melhor?
    • Lean - origens• resposta da Toyota para sua crise, 1950• precisava de “cash” no caixa(reduzir o inventário)• reduzir custos• melhorar qualidade
    • Lean• Pull vs. Push Systems• Kanban• Pensamento Sistêmico• Fluxo Equilibrado• Células de Trabalho• Melhoria Contínua
    • Scrum !"#$%&( )*+,"( -&"%.( /01,"( 23%45,(
    • Scrum <7,7*97(!,*1101-( ./"01(!,*1101-( =*0,>(?9@( =76#( <7"#9/7&5A*(!"#$%&()*&+,#-( ./"01( .01&"#102*34#( .#BC*"7( )*&+,#-( $#(567( D%1&0#1*,( 809*(/*"*( :7,;#"0*9(
    • XP• Test Driven Development• Integração Contínua• Entendimento Comum• Pair-programming• Ritmo sustentável
    • Lean vs. Scrum vs. XP Qual é melhor?
    • Lean + Scrum + XP É melhor!
    • Lean + Scrum + XP
    • Tradicional vs. Agile planejar para antecipar detectar problemas “todos” os problemas e remover impedimentos decisões são tomadas decisões são adidas o quanto antes o máximo possível passagem de bastão equipe unificada entre especialistas e multi-disciplinar the big release entregas contínuas (feedback tarde) (feedback contínuo) perde-se tempo com gera-se valor com negociação com o cliente colaboração com o cliente obedecer o processo ajustar o processo para controlar custos para otimizar a entregar de valor seguir um plano responder à mudanças
    • Quem usa Agile?
    • http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation
    • Transformation Results Features Delivered per Team Days between Major Releases 2000 2001 2002 2003 2004 2005 2006 2007
    • +94 %Increase in feature requests delivered - 2007 v. 2006
    • +38 %Increase in feature requests delivered per developer - 2007 v. 2006
    • Agile has delivered total visibility, total transparencyand unbelievable productivity! a complete win! Steve Fisher Sr. Vice President, Platform Product Management Salesforce.com
    • 568% more value delivered in the first year of being agile.fonte: Greene and Fry 2008.
    • @marcelopark