Versión de la presentación "La alternativa ágil" usada en la charla del mismo nombre durante el Uniencounter de Marzo de 2011
Como novedad incorpora la parte "El profesional", y habla de orgullo, habilidades y software craftmanship :)
6. El proyecto ideal Req. Análisis Diseño Actividades Construcción Pruebas http://idealgiftguide.com/women_gifts.JPG Al final del proyecto el cliente recibe lo que esperaba y no hay que cambiar nada .
9. http://www.flickr.com/photos/marxxiana/209752547/ El cliente tarda mucho tiempo en poder utilizar el resultado del proyecto. Mientras tanto, el contexto cambia y los competidores lanzan nuevos productos. Si se cancela el proyecto se habrá gastado el dinero a cambio de NADA .
14. ¿POR QUÉ APARECEN ESTOS PROBLEMAS? http://www.flickr.com/photos/fuck_fhash/2967505877/
15. Un proyecto tradicional Req. Análisis Diseño Plan inicial Construcción Pruebas La realidad Req. Análisis Diseño Construcción 30% 95% 96% 98% 100% 10% El cliente sólo ha estado viendo papel 50% Retraso El equipo “se pasa la pelota” ufff! ¿Pruebas? ¡Cambios!
16. “ No estaba en el alcance” “ Estoy perdiendo dinero!” “ No entendiste lo que quería” “ No cumpliste los plazos” “ ¡Todo es prioritario!” Un proyecto tradicional
17. Los cambios son inevitables y necesarios http://www.jjying.cn/blog2/attachment/apple_evolution.jpg ¿ ? Ya no existe el “vamos a hacer el producto perfecto” Los productos son infinitos, los proyectos nunca se acaban
18. Dinero y tiempo tirados a la basura. ¿Quién paga esto? De las funcionalidades desarrolladas: 7% se usan “siempre” 13% se usan “a menudo” 16% “a veces” 19% “pocas veces” 45% “ NUNCA ” Fuente: Standish Group http://www.bbc.co.uk/coventry/content/images/2005/06/17/rubbish_pile_420x320.jpg Dedicamos mucho esfuerzo a objetivos que aportan poco valor .
19. http://www.vuidesign.net/wp-content/images/documentation.jpg Dedicamos mucho esfuerzo a actividades cuyo enfoque es arriesgado . Cliente validando un análisis de 3 meses ¡¡ No puedo abandonar mi trabajo durante dos semanas para revisar esto !!! En 2 horas lo firmo. Ya nos pelearemos después si no entendieron lo que necesito.
20. La construcción de un producto es un proceso de aprendizaje , tanto del producto como de la construcción. ¿Dónde se ha ido ese tiempo? Si desapareciesen todos los entregables de tu último proyecto, incluido el producto final , ¿en cuánto se reduciría el tiempo para volver a desarrollarlo? http://blog.adw.org/wp-content/uploads/burning_book1.jpg http://cdn.slashgear.com/wp-content/uploads/2009/05/burning_pc.jpg
21.
22. “ Locura: Hacer lo mismo que la vez anterior, pero esperar resultados diferentes.” Albert Einstein (atribuida)
25. Media y telecos Software y Hardware Internet ERP Banca e Inversión Sanidad y Salud Defensa y aeroespacial Juegos Otros
26. 2001 Lean Scrum XP Principios Gestión de proyectos y equipos Ingeniería Metodos ágiles Kanban Gestión de servicios / operaciones http://agilemanifesto.org/background.jpg Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentación exhaustiva Colaboración con el cliente sobre negociación de contratos Responder ante el cambio sobre seguimiento de un plan Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda. Manifiesto ágil
30. Hacer entregas cortas y regulares del producto final (cada 2-4 semanas) para obtener feedback e irse acercando a las expectativas del cliente. Cliente Equipo Participación del cliente y transparencia para que pueda guiar de manera regular los resultados del proyecto. Control empírico Iterativo e incremental Iterativo e incremental Tradicional Metáfora de Henrik Kniberg
31. Proporcionar resultados anticipados (“time to market”) Orientar el proyecto a objetivos para el cliente, no a tareas, priorizando según el valor de negocio vs esfuerzo y riesgo . Cliente Entregas de los objetivos más importantes Entrega final Equipo http://www.1000steine.com/brickset/images/6162-1.jpg Priorización por valor de negocio Dividir el producto en partes e ir construyendo el lego priorizando las que aportan más valor ¡ Pareto !
32. Cada iteración , no sólo al final del proyecto. ¿Qué ha funcionado? ¿Qué hay que mejorar y cómo? Mejora continua Retrospectivas http://www.cornetdesign.com/images/AgileRetrospectives_134B2/IMG_0016.jpg Process Backlog
47. Incremento de alcance http://davenicolette.wikispaces.com/Agile+Metrics Valor entregado Finalización estimada Entrega de objetivos y velocidad Defectos Gráficos de progreso “ Sprint burndown chart” Horas pendientes en la iteración
51. Para obtener las mejores sinergias , creatividad, productividad y motivación. Colaboración del equipo en la creación del producto, planificación y El equipo Potenciación del equipo Mejora continua Más autonomía y más responsabilidad Compromiso compartido Apoyo del management de la organización, tienen que creer en esto Cultural
53. El gestor, facilitador y coach El buen gestor no busca culpables, sino mejorar el proceso de trabajo. Parálisis Innovación
54. El gestor, facilitador y coach El buen gestor sabe que siempre hay cosas por aprender, y ofrece su comportamiento como ejemplo. Humildad Soft Skills Crecimiento del equipo
55.
56. Socios en lugar de clientes y proveedores http://www.rdacorp.com/images/img_partners_main.jpg El cliente forma parte del equipo y tiene disponibilidad para planificar, revisar y dar detalle a los objetivos en cada iteración. Colaboración Transparencia Team Product Owner
66. Comunidades ágiles España Latinoamérica Mundial Mundial Grupo local de Barcelona Grupos locales Madrid, Barcelona, Galicia, Castilla y León, Canarias, Zona Norte, Aragón, Levante, Andalucía
67. Media y telecos Software y Hardware Internet ERP Banca e Inversión Sanidad y Salud Defensa y aeroespacial Juegos Otros
68. La diferencia no está en saberlo, sino en cambiar “ Locura: Hacer lo mismo que la vez anterior, pero esperar resultados diferentes.” Albert Einstein (atribuida)
"El desarrollo de software es un juego colaborativo"
La falta de involucración en el total del proyecto es la que produce falta de compromiso. La gente quiere ver el resultado de sus acciones.
El faseado de actividades (análisis, desarrollo, pruebas) y “pasa pelota” entre los participantes del proyecto produce ineficiencias, retrasos y poco compromiso . Es necesario encontrar una manera mejor de interrelacionarse .
Los proyectos de SW suelen ser complejos . Hay muchas variables en juego. Es difícil predecir qué sucederá a lo largo del proyecto. El desarrollo de SW en esencia es comunicación y aprendizaje , por lo que es mejor si es empírico . El cliente necesita “tocar” la aplicación para entender mejor qué es lo que necesita. Innovación y construcción van ligados. El equipo necesita entender la tecnología e ir descubriendo cómo crear una solución.
¿sabemos identificar aquellas cosas que realmente son valorables por el cliente, o el "piloto automático" nos lleva a hacer las cosas de uan determinada manera?
¿sabemos identificar aquellas cosas que realmente son valorables por el cliente, o el "piloto automático" nos lleva a hacer las cosas de uan determinada manera?
Hay a gente que esto le funciona, tampoco lo olvidemos, pero (pregunta al público) ¿cuantos de vosotros os habeis sentido identificados con algo de lo que he contado?
Al principio de cada iteración el equipo planifica cómo conseguir el siguiente incremento de producto , según las prioridades del cliente, dividiendo objetivos de negocio en tareas, estimándolas y autoasignandolas. Al final de la iteración el equipo demuestra al cliente los objetivos completados (probados y documentados: la duración de las iteraciones es fija, el alcance es variable ) y hace una retrospectiva sobre qué mejorar en el proyecto. El cliente reprioriza el proyecto en función de los objetivos completados, sus expectativas, prioridades y otros cambios que hayan sucedido en el contexto del proyecto. Todas las actividades son timebox
Al principio de cada iteración el equipo planifica cómo conseguir el siguiente incremento de producto , según las prioridades del cliente, dividiendo objetivos de negocio en tareas, estimándolas y autoasignandolas. Al final de la iteración el equipo demuestra al cliente los objetivos completados (probados y documentados: la duración de las iteraciones es fija, el alcance es variable ) y hace una retrospectiva sobre qué mejorar en el proyecto. El cliente reprioriza el proyecto en función de los objetivos completados, sus expectativas, prioridades y otros cambios que hayan sucedido en el contexto del proyecto. Todas las actividades son timebox
Al principio de cada iteración el equipo planifica cómo conseguir el siguiente incremento de producto , según las prioridades del cliente, dividiendo objetivos de negocio en tareas, estimándolas y autoasignandolas. Al final de la iteración el equipo demuestra al cliente los objetivos completados (probados y documentados: la duración de las iteraciones es fija, el alcance es variable ) y hace una retrospectiva sobre qué mejorar en el proyecto. El cliente reprioriza el proyecto en función de los objetivos completados, sus expectativas, prioridades y otros cambios que hayan sucedido en el contexto del proyecto. Todas las actividades son timebox
Otras herramientas: Excel Banana Scrum Team System Rally Version One Danube X Planner Scrum Works
La medida que nos interesa es valor entregado, o trabajo pendiente por hacer. Las horas no significan "nada" para un avance de proyecto.
En español: Foro Agiles – Lista de correo hispanoamericana con experiencias y soluciones. Agile-Spain – Lista de correo y web para temas españoles Encuentros ágiles (mensuales) – En Barcelona, Madrid, Zona Norte. PlanetaScrum – Agregado de blogs de temática ágil. En inglés: Agile Alliance - Recursos y eventos Scrum Alliance – Recursos y eventos Más: Biblioteca de agile-spain, wiki de trabajo, drigg, directorio, ...
La base del equipo es la confianza mutua, que se basa en cuatro pilares: > (buscaré la referencia al autor) * Visión compartida * Toma de decisiones compartidas, dede abajo. * Comunicación * Comportamiento ético
Las personas no necesitan sentirse sermoneadas, aplastadas, afeadas, … se quedan avasalladas. Necesitan sentirse escuchadas, hacerse valer.
En español: Foro Agiles – Lista de correo hispanoamericana con experiencias y soluciones. Agile-Spain – Lista de correo y web para temas españoles Encuentros ágiles (mensuales) – En Barcelona, Madrid, Zona Norte. PlanetaScrum – Agregado de blogs de temática ágil. En inglés: Agile Alliance - Recursos y eventos Scrum Alliance – Recursos y eventos Más: Biblioteca de agile-spain, wiki de trabajo, drigg, directorio, ...
En español: Foro Agiles – Lista de correo hispanoamericana con experiencias y soluciones. Agile-Spain – Lista de correo y web para temas españoles Encuentros ágiles (mensuales) – En Barcelona, Madrid, Zona Norte. PlanetaScrum – Agregado de blogs de temática ágil. En inglés: Agile Alliance - Recursos y eventos Scrum Alliance – Recursos y eventos Más: Biblioteca de agile-spain, wiki de trabajo, drigg, directorio, ...
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Agenda](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)