Agile, en que te hemos convertido v2
Descargar como PPTX, PDF0 recomendaciones96 vistas
El documento aborda la transformación del área de IT de ser un centro de costos a convertirse en un núcleo de negocio estratégico mediante metodologías como Agile y DevOps. Se discuten las dificultades que enfrentan las empresas en la adopción de estas prácticas, enfatizando la necesidad de un enfoque integral que incluya la mejora de la calidad y la colaboración multidisciplinaria. Además, se plantean estrategias y métricas para la mejora continua y la obtención de resultados eficientes en el sector tecnológico.
Agile, en que te hemos convertido v2
- 1. Juanma Gómez @JuanmaGomeR0 foto ponente 2 Eduardo Ferro @eferro in progress Agile, ¿en qué te hemos convertido? Software Crafters
- 2. Estamos volviendo a joder el sector
- 6. ¿Qué está pasando en las empresas?
- 7. IT en la actualidad Antes ● IT como área de soporte ● Centro de coste ● Proyectos ● No es área estratégica ○ Outsourcing Ahora ● IT como núcleo de negocio ● Centro de beneficio ● Productos ● Es área estratégica ○ Insourcing
- 8. ¿Cómo lo hacen los mejores?
- 9. Accelerate: The Science of Lean Software and Devops (link) / DORA Report 2019 (link)
- 10. “Firms with high-performing IT organizations were twice as likely to exceed their profitability, market share and productivity goals” DORA Report 2014 (link)
- 11. Entrega Continua Agile / Devops Excelencia técnica Edu
- 12. Business Agility
- 13. Lean, Lean Startup, Design Sprints, Customer research, Discovery track...
- 15. “According to Gartner, 70% of the IT market is focusing on DevOps and another study found that 88% of organizations have adopted agile, but only 26% of organizations have broadly adopted test automations.” Chris Richardson
- 19. ¿Qué pasa con Agile en este esquema?
- 20. ¿Cómo estamos contribuyendo a esto nosotros?
- 22. Existen importantes diferencias entre las consultoras generalistas y las de nicho ¿Qué le vendes a tus clientes? ¿Vendes tus soluciones o solucionas sus problemas? ¿Cuánto entiendes lo que vendes?
- 23. Ejemplos
- 24. “¿Quieres automatizar? Toma, un ingeniero Dev/Ops”. “¿Agile? ¿Cuántos Scrum Masters quieres? ¿3? Te dejo 5 al precio de 3”. “¿Programadores? ¿30? Toma. Están bien educados, sólo hacen lo que les digas que hagan”.
- 25. Los profesionales (tú y yo)
- 26. “No me gusta desarrollar” ¿Para qué estudias informática y curras en un área de desarrollo?
- 27. “Si programo toda la vida me quedo en la base. Quiero ganar más” Lucha contra el establishment actual
- 28. “A mí lo que me gusta es la gestión” ¿De algo que no comprendes?
- 29. “A mí sólo me importan las personas” Pues monta una empresa y verás que bien te va
- 31. “Hago un curso de 2 días para ser Scrum Master certificado” ¡¡¡Salario +10K!!!
- 32. “Después, me hago Agile Coach, que es el siguiente paso en la escala” ¡¡¡Salario +15K!!!
- 33. “Agile es una metodología”
- 35. “Soy Agile Coach. Acompaño ya a 2 ó 3 equipos”
- 37. “Cuando el equipo no quiere Scrum, hacemos Kanban”
- 39. “¿Extrim Programin? Na, yo paso de programar, y menos en plan talibán”
- 41. “Las empresas no quieren transformarse”
- 43. Primer aviso
- 44. Por si aún no ha quedado claro...
- 45. Estamos volviendo a joder el sector
- 46. Primeras claves ● Agile no es únicamente Scrum. ● Agile no es únicamente foco en las personas. ● No existe Agile sin Agile software delivery ● Tu cliente no se resiste al cambio, se resiste a tu propuesta. Tú sabrás por qué. ● Las cosas no son mejores o peores porque sí. Indaga, comprende y haz buena pedagogía.
- 47. Segundo aviso
- 48. Un Scrum Master no se hace en un curso de 16 horas
- 49. Un Agile Coach no se hace en un curso de 24 horas
- 50. ¡Ser Agile Coach no es el siguiente peldaño del Scrum Master!
- 54. 1. Establecer el POR QUÉ 2. Establecer el OBJETIVO 3. Diseñar el CAMINO 4. Identificar STAKEHOLDERS 5. Elegir INDICADORES 6. Definir EQUIPO MOTOR 7. Establecer PRIMEROS PASOS Cómo lo enfocamos nosotros Motivación y expectativas. ¿A dónde nos queremos dirigir? ¿Qué planteamos hacer? ¿Quiénes son los protas de la historia? ¿Cómos vamos a medir el resultado de nuestras decisiones? Generación de un equipo que traccione el cambio. ¿Cómo vamos a arrancar este camino? La receta de arranque de Enciende la Luz
- 55. 1. Establecer el POR QUÉ 2. Establecer el OBJETIVO 3. Diseñar el CAMINO 4. Identificar STAKEHOLDERS 5. Elegir INDICADORES 6. Definir EQUIPO MOTOR 7. Establecer PRIMEROS PASOS Motivación y expectativas. ¿A dónde nos queremos dirigir? ¿Qué planteamos hacer? ¿Quiénes son los protas de la historia? ¿Cómos vamos a medir el resultado de nuestras decisiones? Generación de un equipo que traccione el cambio. ¿Cómo vamos a arrancar este camino? La receta de arranque de Enciende la Luz Cómo lo enfocamos nosotros
- 56. 3. Diseñar el CAMINO ¿Qué planteamos hacer? La receta de arranque de Enciende la Luz Cómo lo enfocamos nosotros EFICACIA EFICIENCIA Visualizar y meter orden. Usamos principalmente Scrum Ingeniería Ágil para mejorar el producto bien enfocado
- 57. 4. Identificar STAKEHOLDERS ¿Quiénes son los protas de la historia? La receta de arranque de Enciende la Luz Cómo lo enfocamos nosotros También hay Stakeholders de tecnología, no son únicamente de negocio. Si entre tus Stakeholders no hay personas de tecnología, es probable que no estés prestando la atención adecuada a esta dimensión.
- 58. Si quieres dejar de ser parte de este engaño...
- 61. Sé el ejemplo de lo que enseñas ● Trabaja junto a tu cliente. ● Preocúpate por conocer su problema y no aceptes tan rápido su solución. Igual no comprende lo que te está pidiendo. ● Monta un equipo multidisciplinar de intervención. ● Utiliza las prácticas que esperas de los demás. ● PERSIGUE SIEMPRE LA EXCELENCIA en lo que hagas.
- 63. Flujo continuo y sostenible de entrega ● Entrega continua como hilo conductor (exige prácticas agile ingeniería) ● Eliminación silos (Prod, DS, Dev, Ops) ● Propiedad producto compartida (equipo) ● Mide
- 65. ¿Es que no hay otra manera de hacer las cosas?
- 67. Alea Soluciones ● Despliegue 5-10/semana ● XP & DevOps practices (Consolidadas) ● Equipo multidisciplinar (Producto, Ops, Dev) ● Nueva producto (Gpon 3 meses) ● 3 Nuevas verticales (Hoteles, Eléctricas, Hospitales) 2012-2016 Telecomunicaciones Depto. Producto 9 personas (1 Equipo)
- 68. The Motion ● Despliegue 5-10/dia ● XP & DevOps practices (Consolidadas) ● Equipo multidisciplinar (Ops, Dev) + Prod ● Nueva producto / Nuevo mercado ● 4 Pivots ● No product market fit ● Fondos europeos H2020 2015-2018 Startup Videos / Publicidad Depto. Producto 12 personas (2-3 Equipos)
- 69. Nextail ● Despliegue 1-3/dia ● XP & DevOps practices (mejorando) ● Equipo multidisciplinar (Squads) ● Nuevo producto / Nuevo mercado ● Market fit consolidado ● Escalando 2018-Actualidad Startup SaaS Retail IA y Analitica prescriptiva Depto. Producto 34 personas (6 Equipos)
- 70. Payvision ● 14 Scrum teams. ● XP & DevOps practices (mejorando) ● 60 builds in a day and 11 deployments in a day (2 in production) ● 2392 test passed. 99.99% green on last 14 days 2018-Actualidad Fintech, parte de ING
- 71. Toyota España ● Plan de transformación global de la compañía. ● Indicadores: ○ Tasa de entrega de producto terminado. ○ Cantidad de trabajo aceptado y no planificado. ○ Calidad del Software: Código/ Tasa de Bugs x entorno. ○ Experiencia del peticionario. ○ Satisfacción del empleado de IT. ● Herramientas: ○ Propiedad compartida del código. ○ Automatización de pruebas. ○ Afianzamiento estándares de calidad. 2019-Actualidad Sector automoción
- 72. Cómo he usado la consultoría externa ● Agile technical coaches ● Ayuda desarrollo (agile / XP) ● Facilitación puntual ● Activación circuitos de mejora continua
- 73. Alea Soluciones ● Aprender haciendo ● Sobre nuestro producto / No cursos ● Expertos XPs ○ Carlos Ble ○ Nestor salceda Cultura / Facilitación puntual ● Ariel Ber ● JM Beas ● Thinking with you
- 74. The Motion ● Aprender haciendo ● Sobre nuestro producto / No cursos ● Expertos XPs ○ Codesai (Alfredo Casado, Modesto San Juan) ● Pairing presencial ● Sobre nuestro producto ● Foco en testing
- 75. The Motion ● Aprender haciendo ● Sesiones específicas Arquitectura Frontend ○ Ricardo Borillo + CodingStones ● Mob programming (presencial) ● Architecture clinic (Asinc/Remoto + presencial)
- 76. Nextail ● Acciones formativas agile@work ○ Ricardo Borillo, Xavi Gost ○ Testing / Arquitectura Front ○ Prácticas para Data Scientists ○ Refactoring Backend Activación circuito Kaizen Makoto Squad ● Retrospectivas ● Técnicas facilitación retrospectivas
- 77. ¿Qué le pido a un Agile Coach (no tech)? ● Reconocer la importancia de las prácticas de ingeniería ● Identificar los problemas (falta prácticas, deuda, calidad, etc.) ● Defender la necesidad o al equipo haciendo XP y Devops ● Facilitar iniciativas internas (si las hay) ● Introducir Coaching tecnico / XP / Devops (es necesario)
- 78. Cómo lo enfoco ● Mindset (Facilitación / Paciencia / Visión Largo Plazo) ● Entrega continua (requiere prácticas agile/devops ingeniería) Como pilares ● Personas y Colaboración ● Enfoque a cliente final
- 79. Conclusiones
- 81. El éxito radica en hacer lo adecuado y hacerlo bien
- 82. Pero sólo con decirlo ¡NO VALE!
- 83. ¿Cómo podemos mejorar el sector? Persigamos lo que nos dice la ciencia (DORA/Accelerate): ● Lean Product Management ● Lean Management ● Entrega Continua Métricas contrastadas (Software delivery and operational performance) ● Frecuencia Despliegue ● Lead time ● Tiempo medio de recuperación ● Porcentaje fallos / despliegues
- 84. DORA Report 2019 (link)
- 86. Referencias: A letter to agile coaches Blog post Accelerate The Science of Lean Software and DevOps Building and Scaling High Performing Technology Organizations
Notas del editor
- #8: Todos intentando contratar más desarrolladores, pero con mirada al “antes”. Escasez de desarrolladores ágiles.
- #14: Si desplegamos una vez cada 6 meses, el ciclo de experimentación es demasiado lento… asi que si todavia no eres capaz de construir y poner a producción con una buena frecuencia y de forma sostenible, decir que mejoras la agilidad si no estás mejorando eso es un engaño. En el caso de una enterprise, que despliega 2 o 4 veces a producción por año. ¿De verdad decimos que estamos mejorando la agilidad cuando no ponemos peso en mejorar esa frecuencia de despliegue?
- #36: ¿A dónde les acompañas? ¿Al barranco?
- #37: ¿A dónde les acompañas? ¿Al barranco?
- #39: Tablero sin orden ni concierto = ¿Kanbanismo?
- #41: Claro que sí, guapi.
- #43: Igual no has entendido aún la necesidad y situación de tu cliente.
- #68: TDD, Pairing/Mob (>70%), Collective ownership (Product/Code), Trunk base development, Hexagonal architecture, Service-oriented architecture, CI, CD, Infraestructura como código Stakeholders CEO, Operaciones de Red
- #69: TDD, Pairing/Mob (>70%), Collective ownership (Product/Code), Trunk base development, arquitectura Hexagonal, Microservices, arquitectura dirigida por eventos, CI, CD, Infraestructura como código, etc.
- #70: TDD (no siempre), Pairing/Mob (>30%), Collective ownership (Product/Code), Trunk base development (not always), Hexagonal architecture (for new services), Splitting the monolith, CI, CD, Infrastructura como codigo. Market fit consolidado, fase de escalado, último año (users x1.5, clientes x2, data x2, escalabilidad horizontal (parcial), excepciones -x50, consumo mem/tiempo -2x, fault tolerance, 3 a 6 países)
- #74: Prácticas Learning by doing Expertos XP Carlos Ble (1.5 días/sem 1Mes) (Arranque TDD) Nestor Salceda (3 días/sem 2/3años) (Miembro equipo) Pairing remoto Sobre nuestro producto / No cursos Ariel Ber Preparación terreno 10 sesiones JM Beas agile inception y retro momento muy complicado 1 sesión Thinking with you facilitación retros, expansión a otros equipos
- #75: Prácticas Learning by doing Expertos XP Codesai (Alfredo Casado, Modesto San Juan) 2 días/sem 4Mes (Arranque TDD, Pairing) Pairing (presencial) Sobre nuestro producto / Foco en testing
- #76: Aprender haciendo Sesiones específicas Arquitectura Frontend Ricardo Borillo + CodingStones 3 días (Arquitectura testable frontend) Mob programming (presencial) Architecture clinic (Asinc/Remoto + presencial)
- #78: O por lo menos, no dinamites las iniciativas por la calidad. No hay nada más destructivo que un supuesto experto en agilidad pasando de la calidad técnica. Si un equipo no necesita coaching técnico, lo más seguro es que su nivel de agilidad y flow haga que ya estén a un nivel de madurez excelente.
- #79: El enfoque al cliente final se trabaja consiguiendo centrarnos en Outcomes y cambiando el mindset de los desarrolladores para que entiendan para quién hacemos las cosas y por qué hacemos las cosas. Tengo muy en cuenta que sólo con un equipo motivado se consiguen grandes cosas, por lo que dedico mucho tiempo a las personas y a ayudarlas a crecer. Un efecto curioso de la entrega continua, es que aunque sea dificil, impacta mucho en la calidad de vida de los equipos (menos estrés, menos miedos, más sentimiento de impacto, etc).
- #84: Usemos las métricas (contrastadas) para la agilidad. Frecuencia de despliegue, Lead time, Mean time to recover y Change failure rate
- #85: Todo esto no se hace con postits y abrazando arboles… aunque los postits sean útiles y abrazar árboles relaje. Se hace tomandonos las prácticas de ingeniería agile en serio.
- #87: Usemos las métricas (contrastadas) para la agilidad. Frecuencia de despliegue, Lead time, Mean time to recover y Change failure rate
- #88: Juanma/Edu