Desarrollo Agil
•
14 gefällt mir•1,690 views
El documento resume conceptos y metodologías clave del desarrollo de software ágil. Explica que en 2001 se creó el Manifiesto Ágil que valora individuos e interacciones, software que funciona, colaboración con el cliente y adaptación al cambio por encima de procesos, documentación, negociación de contratos y seguimiento de planes. También describe principios y prácticas como historias de usuario, integración continua y desarrollo iterativo e incremental de metodologías como Scrum, XP y Lean Software.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Desarrollo Agil
Ähnlich wie Desarrollo Agil (20)
Mehr von Jose Ramón Díaz
Mehr von Jose Ramón Díaz (16)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Desarrollo Agil
- 1. DESARROLLO SOFTWARE ÁGIL Jose Ramón Díaz
- 2. ¿Problemas?
- 3. razones 2
- 5. El Software es un Juego Cooperativo
- 6. Software for your Head Jim and Michelle McCarthy Agile Software Development The Cooperative Game Alistair Cockburn
- 10. A TRAVÉS DE ESTA EXPERIENCIA HEMOS APRENDIDO A VALORAR... Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros.
- 11. Individuos e interacciones sobre procesos y herramientas 1
- 12. Software que funciona sobre documentación exhaustiva 2
- 13. Colaboración con el cliente sobre negociación de contratos 3
- 14. Responder ante el cambio sobre seguimiento de un plan 4
- 15. VALORAMOS POR ENCIMA DE ELLOS LOS QUE ESTÁN A LA IZQUIERDA . AUNQUE LOS ELEMENTOS A LA DERECHA TIENEN VALOR,
- 17. Desarrollo Iterativo e Incremental
- 18. Colaboración con el cliente
- 19. Priorizar el valor de negocio
- 20. Adaptación a los cambios
- 23. Bajemos al mundo real
- 24. Equipo Ecosistema software Metodología Organización Lean Scrum XP Principios Gestión de proyectos y equipos Principios Ingeniería
- 28. Lean: The Toyota way
- 30. Scrum
- 31. Iterativo Incremental Mejora Continua Fortalece los equipos
- 32. Product Owner Representa los interesados en el proyecto, el cliente Define los objetivos, los prioriza, y dirige los resultados del proyecto para maximizar el ROI.
- 33. multidisciplinar, Autogestionado, comparte un mismo objetivo, comunicación Equipo
- 34. Facilitador de la colaboración intraequipo y con el cliente, Elimina impedimentos, Asegura el proceso Scrum Scrum Master
- 35. Burndown chart
- 36. Para ser ágiles CONFIANZA COOPERACIÓN
Hinweis der Redaktion
- ¿por qué estoy aquí? Agile-spain, interés por razones que verán…
- Los cambios se hacen intolerables El cliente tarda mucho tiempo en poder utilizar el resultado del proyecto Procesos muy pesados que no generan Valor al cliente El equipo de desarrollo “se quema”
- Pero no vamos a desglosar problemas para justificar un cambio a ágiles, voy a dar dos razones por las que yo creo que se ajustan mejor a la casuística del desarrollo de software..
- 1 .- El producto de un gestor es su equipo -> no eres responsable proyecto, no puedes hacerlo solo, debes 2.- El producto generado es tan bueno como el equipo que lo ha creado… ¿son equivalentes? Un gran equipo (como lo quieras entender) ¿será capaz de hacer un mal producto?
- Juegos como ajedrez, de adultos.. Un juego con una meta clara (que no todos lo tienen) Un juego cooperativo, finito, en busca de un fin, en grupo El juego es entregar el software. Cualquier otra actividad es secundaria,… los modelos, comunicaciones, documentos,… son suficientes con tal que permitan a la siguiente persona hacer el siguiente movimiento del juego… Los trabajos del equipo deberían ser medidos respecto a la suficiencia con respecto a su labor en el juego…
- Dos libros abundando en esta idea… el primero trata de software, pero unicamente habla de equipos, patrones que funcionan en el funcionamiento de equipos…. El segundo, alistair cockburn nos presenta
- Basado en las premisas anteriores… buscar la meta, reforzar el espíritu de equipo… “ ¿Cuál quieres Neo, la pastilla roja, o la azul?
- La denominación viene de mediados de los 90, como respuesta a los métodos “pesados”, con procesos y documentos… Se considera un poco como la vuelta a cómo se desarrollaba antes de generar la burocracia existentes en algunas metodologías usadas en los 90
- En la primavera de 2001 (no hace tanto), se reunieron unos señores en Salt Lake City (USA) y llegaron a escribir lo siguiente. (-> ) 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 .
- Son 12 principios que siguen… resumidos…
- ROI: SOFTWARE QUE FUNCIONA: Construir software cuesta dinero y normalmente lo paga el cliente. Cuanto antes reciba resultados por su dinero, antes podrá conocer si su inversión está mereciendo la pena, es decir, el Retorno de la Inversión o ROI. Por eso, cuanto antes pueda recibir software que funciona , antes podrá empezar a usarlo y recibir el valor para el que se creó.
- COLABORACIÓN: RESPETO: CONFIANZA: Pero para lograr colaborar eficazmente es necesario respetar a los demás. Sólo así conseguiremos ganarnos su confianza. Y es que la confianza no es fácil de construir, pero es clave para lograr el éxito de un proyecto ágil, puesto que no podemos escondernos detrás de los contratos. Por eso es muy frecuente que los equipos ágiles usen tablones para explicar a todos diariamente el estado del proyecto.
- Valor para el cliente: Pero, ¿con valor para quién? Para el cliente, ¡por supuesto! Frecuentemente nos olvidamos de para quién trabajamos y (los técnicos) nos dedicamos a resolver nuestros propios problemas.
- En el mundo de los negocios, el cambio es una constante y adaptarse rápidamente es una ventaja. Los procesos de desarrollo tradicionales dan por supuesto que lo que se dice al principio del proyecto “va a misa” y esto puede ser válido en la construcción de un puente, pero no en el desarrollo de software empresarial porque hay cambios frecuentes, algunos porque cambian las necesidades del cliente, otras porque no lo conocemos todo desde el principio. Lo único cierto es que habrá cambios.
- Concepto de deuda técnica (han surgido técnicas como TDD, ATDD, integración continua)…
- Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte que necesitan, y confiando en ellos para que realicen el trabajo. Este principio representa un gran cambio de mentalidad, tanto para los directivos (jefes de proyecto, directores de rrhh, etc) como para nosotros los técnicos. Ellos deben hacer un acto de fé en que nosotros seremos responsables y disciplinados mientras que nosotros perdemos la excusa del jefe de proyecto que está encima nuestro y nos dice lo que hay que hacer.
- written by Mary Poppendieck and Tom Poppendieck
- Mejora continua Herramienta: Mapas de flujo de valor: unnecessary code and functionality delay in the software development process unclear requirements bureaucracy slow internal communication Comparar con diagrama de gantt, el opuesto a esperar tener toda la info Deuda técnica “ parar la cadena”
- Al abandonar paulatinamente el control basado en procesos , empiezas a confiar en que las personas desarrollarán su trabajo de la manera adecuada por que saben hacerlo y quieren hacerlo. Esto tiene numerosas implicaciones. De repente el departamento de calidad no tiene que vigilar el obligado cumplimiento de normas, procesos y burocracia. Los jefes deben confiar en sus empleados (no me gusta decir "la empresa debe...". La empresa no confía, la empresa no siente ni padece). Los empleados y jefes deben confiar en sus compañeros.Confianza en los conocimientos de los empleados, en su sabiduría y buen hacer. Confianza en la palabra de las personas. No necesitas poner exhaustivamente todo por escrito. Confías en ellos, si te dicen algo, lo harán. Pasar a un modelo colaborativo exige confiar. Cuando en una organización se han creado los procesos para controlar el trabajo, es dificil volver atrás. Pero no debe ser imposible.
- http://alistair.cockburn.us/Software+development+as+a+cooperative+game Ecosistema http://www.manuelrecena.com/blog/archives/219 http://codebetter.com/blogs/jeremy.miller/archive/2006/08/13/148258.aspx XP Scrum Lean