Conceptos de las Metodologas Agiles para la Administracin de Proyectos

Los problemas ms habituales que provocan fracasos

Estudio Ao 1995, The Chaos Report, Standish Group International (Muestra: 365 IT managers de 8380 aplicaciones de diversas industrias en empresas de diferente envergadura) 31.1% de los proyectos fueron cancelados antes de terminarse 52.7% de los proyectos superaron el tiempo estimado, requirieron mayores presupuestos y no ofrecieron la funcionalidad pautada. 16.2% de los proyectos se finalizaron en tiempo y con el presupuesto estimado.

2000

28

49

23

1998

26

46

28

Exitosos Superados Fracasados

1996

27

33

40

1994

16

53

31

0%

20%

40%

60%

80%

100%

 Cmo reducir estos problemas ? Factores de xito

Participacin del Usuario

Respaldo Gerencial Requerimientos y objetivos claros y precisos

Planificacion adecuada

1 2

Expectativas realsticas / Fijar alcance / Etapas cortas

Chaos 2004
People know that the more common scenario in our industry is still: over budget,

over time, and with fewer features than planned.

Most of the comments I get on that are: "I don't have ANY that come in on time..."
Jim Johnson is the founder and chairman of the Standish Group, a globally respected source of independent primary research and analysis of IT project performance.
http://www.infoq.com/articles/Interview-JohnsonStandish-CHAOS

Standish Group, 2006: Factores de xito

Standish Group, 2006

A big problem was project bloat, causing projects to go over time, over budget, and creating features and functions not required. Especially in government. Agile really helps this - small increments. You know: they say "I need this", but by next sprint: "it's not as important as I originally thought it was."

GD: Yes, prioritizing features helps... always asking: what's the business advantage? Identifying low value items and putting them at the end... and then maybe the project never gets there, so you didn't need them after all.

 De qu hablamos cuando hablamos de agilidad ?

1 - Ligero, rpido 2 - Moverse con soltura

 Qu entendemos por Cambios ?

Traditionally, users are educated that its much more expensive to change or add requirements during or after the software is built. Some organisations quote some impressive statistics designed to frighten users into freezing the scope. The result: It becomes imperative to include everything they can think of in fact everything they ever dreamed of! And whats more, its all important for the first release, because we all know Phase 2s are invariably hard to get approved once 80% of the benefits have been realised from Phase 1. Ironically, users may actually use only a tiny proportion of any software product, perhaps as low as 20% or less, yet many projects start life with a bloated scope. In part, this is because no-one is really sure at the outset which 20% of the product their users will actually use. Equally, even if the requirements are carefully analysed and prioritised, it is impossible to think of everything, things change, and things are understood differently by different people.

 Agile Development works on a completely different premise.

Agile Development works on the premise that requirements emerge and evolve, and that however
much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software. And in the time you would have spent analysing and reviewing requirements and designing a solution, external conditions could also have changed. So if you believe that point that no-one can really know what the right solution is at the outset when the requirements are written its inherently difficult, perhaps even practically impossible, to build the right solution using a traditional approach to software development.