Desarrollo Agil

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

more share options
Embed For WordPress.com

Without related presentations

1 comments

Comments 1 - 1 of 1 previous next Post a comment

+ Jose Ramón Díaz 4 weeks ago
Podeis ver el video de la charla en: http://www.navarparty.org/content/view/136/200/

Notes on slide 1

¿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

5 Favorites

Martin D favorited this 1 month ago
Rafael Igual, Business Development Manager at Realtech Spain, favorited this 1 month ago
Tags software agile development
mmannise favorited this 1 month ago
Tags development agile
abcakr favorited this 1 month ago
Jose M Beas, Self employed consultant favorited this 1 month ago
Tags agile

Desarrollo Agil - Presentation Transcript

DESARROLLO SOFTWARE ÁGIL Jose Ramón Díaz
¿Problemas?
razones 2
PRODUCTO = EQUIPO
El Software es un Juego Cooperativo
Software for your Head Jim and Michelle McCarthy Agile Software Development The Cooperative Game Alistair Cockburn
¿Cambiamos el desarrollo?
METODOLOGÍAS ÁGILES:
- XP (1996)
- Scrum (1995)
- Lean Software Development
- DSDM (1995)
- Feature Driven Development (1999)
MANIFIESTO ÁGIL (2001)
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.
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
VALORAMOS POR ENCIMA DE ELLOS LOS QUE ESTÁN A LA IZQUIERDA . AUNQUE LOS ELEMENTOS A LA DERECHA TIENEN VALOR,
PROYECTOS ÁGILES PRINCIPIOS
Desarrollo Iterativo e Incremental
Colaboración con el cliente
Priorizar el valor de negocio
Adaptación a los cambios
Excelencia técnica
Equipo
- Autoorganizado
- Responsable del producto
- Motivación
- Proceso de mejora continua
Bajemos al mundo real
Equipo Ecosistema software Metodología Organización Lean Scrum XP Principios Gestión de proyectos y equipos Principios Ingeniería
- Ecosistema software
- ¿Puedo encontrar el código relacionado con el problema o cambio?
- ¿Puedo entender el código?
- ¿Es fácil cambiar el código?
- ¿Puedo verificar rápidamente los cambios?
- ¿Puedo cambiar las cosas con un riesgo bajo de romper funcionalidades existentes?
- Si rompo algo, ¿es fácil detectar y diagnosticar el problema?
- Prácticas de eXtreme Programming
- Historias de Usuario
- Integración Continua
- Test Driven Development
- Testeo automático
- Refactorización
- Programación en parejas y/o revisiones de código
Ecosistema software
Lean: The Toyota way
Organización: Lean
- Respetar a las personas , porque el equipo es quien conoce cómo mejorar el proceso en que trabaja.
- Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor añadido en el producto.
- Aplazar el compromiso , retardar las decisiones hasta que se disponga de toda la información o no se pueda esperar más.
- Crear conocimiento , tener feedback regular con el cliente para alinearse con sus expectativas.
- Hacer entregas rápidas , para permitir que el cliente pueda aprovechar antes los beneficios que le aporta el proyecto.
- Desarrollar con calidad interna , de manera que el producto pueda ir creciendo con una velocidad sostenida.
- Optimizar la totalidad del proceso , mejorar el proceso de creación del producto, desde la idea hasta su entrega.
Scrum
Iterativo Incremental Mejora Continua Fortalece los equipos
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.
multidisciplinar, Autogestionado, comparte un mismo objetivo, comunicación Equipo
Facilitador de la colaboración intraequipo y con el cliente, Elimina impedimentos, Asegura el proceso Scrum Scrum Master
Burndown chart
Para ser ágiles CONFIANZA COOPERACIÓN
Sitios de referencia