DESARROLLO SOFTWARE ÁGIL La alternativa
Tiempo Alcance Recursos ? Calidad (Buffers) (Indefinible + cambios) (Precios)
MANIFIESTO ÁGIL (2001)
Individuos e interacciones   sobre   procesos y herramientas 1
Software que funciona   sobre     documentación exhaustiva 2
Colaboración con el cliente   sobre   negociación de contratos 3
Responder ante el cambio   sobre   seguimiento de un plan 4
<ul><li>Siguientes pasos: </li></ul><ul><li>Scrum </li></ul><ul><li>eXtreme Programming </li></ul><ul><li>Lean </li></ul><...
Próxima SlideShare
Cargando en…5
×

La alternativa desarrollo software agil

286 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
286
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.
  • En la primavera de 2001 (no hace tanto), se reunieron unos señores en Salt Lake City (USA) y llegaron a escribir lo siguiente. (-&gt; ) A continuación unas referencias por si alguien pregunta... Kent Beck (uno de los padres de XP y creador de JUnit), Mike Beedle, Arie van Bennekum, Alistair Cockburn (“Writing Effective Use Cases”), Ward Cunningham (el padre de wiki y otro de los padres de XP), Martin Fowler (“Refactoring”, “Analysis Patterns”, etc), James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries ( el padre que falta de XP ), Jon Kern, Brian Marick (especialista en Agile Testing, estará en Agiles 2009), Robert C. Martin ( UncleBob : los principios SOLID, “Clean Code”, Fitnesse), Steve Mellor, Ken Schwaber (el padre rico de Scrum), Jeff Sutherland (el otro padre de Scrum), Dave Thomas (“The Pragmatic Programmer”)
  • Los procesos y las herramientas deben facilitar las tareas de los individuos y no limitarlas . Por eso, p.ej. se utilizan pizarras y post-its.
  • Si le vamos presentando al cliente sucesivas versiones del producto para que nos vaya indicando (e incluso para que él mismo vaya averigüando ) si vamos bien encaminados o no. El resultado es que, indefectiblemente, el cliente tendrá algo que funciona (más o menos), mientras que si le damos documentación NO TENDRÁ NADA . el camino para llegar hasta lo que necesita el cliente no es un documento muy pesado sino acercamientos sucesivos (y funcionando) del producto. Esto es lo que dará el “feedback” necesario.
  • Debemos ganarnos la confianza de nuestros clientes y colaborar con ellos para darles valor en vez de parapetarnos detrás de los contratos y rechazar todas sus peticiones de cambio.
  • En un entorno tan caótico como los coches de tope hay que aceptar que no puedes ir durante mucho rato hacia donde has previsto ir. En el mundo de los negocios es algo parecido. Y los desarrolladores de software tenemos que aceptar esta realidad y ayudar a las empresas en esto .
  • La alternativa desarrollo software agil

    1. 1. DESARROLLO SOFTWARE ÁGIL La alternativa
    2. 2. Tiempo Alcance Recursos ? Calidad (Buffers) (Indefinible + cambios) (Precios)
    3. 3. MANIFIESTO ÁGIL (2001)
    4. 4. Individuos e interacciones sobre procesos y herramientas 1
    5. 5. Software que funciona sobre documentación exhaustiva 2
    6. 6. Colaboración con el cliente sobre negociación de contratos 3
    7. 7. Responder ante el cambio sobre seguimiento de un plan 4
    8. 8. <ul><li>Siguientes pasos: </li></ul><ul><li>Scrum </li></ul><ul><li>eXtreme Programming </li></ul><ul><li>Lean </li></ul><ul><li>Sitios: </li></ul>

    ×