Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Nexus y la Deuda Tecnica

Se comparte en esta presentación el framework Nexus y retos que conlleva al usarlo como estrategia de escalar scrum, Uno de estos riesgos es la generción de deuda técnica.

  • Soyez le premier à commenter

Nexus y la Deuda Tecnica

  1. 1. por: Jorge H. Abad L – jorge.abad@gmail.com twitter@jorge_abad – blog: www.lecciones-aprendidas.info Nexus – El Exoesqueleto para Escalar Scrum y la Deuda Técnica
  2. 2. Mis objetivos con esta sesión: - Compartir sobre Nexus - Elevar nuestro nivel de conciencia sobre la deuda técnica
  3. 3. Esto no es del todo mío, se basa en crecer sobre el compartir  Presentación esta basada en las diapositivas de mi amigo Lucho Salazar @LuchoSalazarC  Blog: http://www.gazafatonarioit.com/
  4. 4. A planes más largos, mayores serán los supuestos y mayores los riesgos. No permitas que la incertidumbre te gobierne @ourfounder
  5. 5. Historias de la vida real ¿Cuál de los siguientes procesos de software estás usando en tu organización? • Lean (Software Development) • Kanban • DevOps • SAFe • DAD • LeSS • eXtreme Programming • Scrum
  6. 6. Historias de la vida real ¿Has estado involucrado en esfuerzos para escalar Scrum? Levanta la mano si tu organización define ‘escalar’ como: • Múltiples equipos trabajando en un producto • Múltiples equipos trabajando en sus productos individuales • Múltiples equipos trabajando en una suite de productos integrados • Un equipo trabajando en varios productos en paralelo • Toda la organización TI adoptando Scrum • Una transformación organizacional de 180º hacia Ágil
  7. 7. Historias de la vida real ¿Has estado involucrado en esfuerzos para escalar Scrum? Levanta la mano si tu organización define ‘escalar’ como: • Múltiples equipos trabajando en un producto • Múltiples equipos trabajando en sus productos individuales • Múltiples equipos trabajando en una suite de productos integrados • Un equipo trabajando en varios productos en paralelo • Toda la organización TI adoptando Scrum • Una transformación organizacional de 180º hacia Ágil
  8. 8. Scrum: diseñado para la complejidad • Fomentar la creatividad de las personas • Controlar el riesgo (Time-Boxing) • Permitir el aprendizaje validado • Dirigido por metas • Exitoso en el descubrimiento • Entrega de valor • Un entorno delimitado para la acción
  9. 9. DNA de Scrum Autoorganización • Los componentes de un sistema interactuando con un único propósito hacia una meta compartida, evitando cualquier poder externo Empirismo • Las decisiones frecuentes de adaptación se basan en el conocimiento ganado vía la inspección y la experiencia
  10. 10. SIN EMBARGO…
  11. 11. ¿Qué tal si empezamos haciendo Scrum antes de intentar escalarlo?
  12. 12. La Esencia de Scrum 1. Un equipo saca trabajo de una Lista de Producto 2. Cada Sprint entrega un Incremento distribuible del producto Incrementos Equipo Scrum Lista de Producto
  13. 13. Definición de Scrum a Escala • Cualquier implementación de Scrum donde múltiples Equipos Scrum construyen un producto o un conjunto de características de un producto en uno o más Sprints. • Cualquier implementación de Scrum donde múltiples Equipos Scrum construyen múltiples productos relacionados o conjuntos de características de productos en uno o más Sprints.
  14. 14. La Esencia de Scrum 1. Un producto tiene una Lista de Producto manejado por un Dueño de Producto 2. Múltiples Equipos crean Incrementos integrados Lista de Producto Equipos Scrum Incrementos (Integrados)
  15. 15. ¿Cuáles son tus mayores obstáculos al escalar Scrum, implementar Scrum a gran escala? Los desafíos de escalar Scrum
  16. 16. La integración del trabajo (o la ausencia de ella) Código pobremente mantenido produce EL EFECTO MEDUSA
  17. 17. Un Equipo Scrum Haciendo el Trabajo Lista de Producto
  18. 18. Algunos Equipos Scrum Haciendo el Trabajo Lista de Producto
  19. 19. Lista de Producto Muchos Equipos Scrum Haciendo el Trabajo
  20. 20. Tu habilidad de escalar depende de tu habilidad para: – Manejar dependencias – Integrar el trabajo en todos los niveles – Crear Incrementos integrados continuamente
  21. 21. Pausa… Despues volveremos sobre lo de la deuda tecnica
  22. 22. Nexus Scrum Profesional a Escala “Un hombre que toma un gato por la cola aprende algo que no puede aprender de otra forma”. - Mark Twain
  23. 23. Nexus –noun ˈnek-səs : a relationship or connection between people or things http://www.merriam-webster.com/dictionary/nexus
  24. 24. ¿3-9 Equipos Construyendo un Producto? ¡Ayuda! Incrementos (Integrados) Equipos Scrum Lista de Producto
  25. 25. Nexus™ – Un Exoesqueleto para 3-9 Equipos Scrum
  26. 26. Identifica y trabaja alrededor de las dependencias:  Antes de que se haga el trabajo  Continuo  Persistente  En todas las dimensiones Revela dependencias que permanecen desapercibidas:  Integración Frecuente  Pruebas de aceptación  Compilación y entrega continua  Reduce la deuda técnica Diseñado para Manejar Dependencias Proactivo Reificación* *Reificación: Hacer que algo se vuelva real o hacer que algo abstracto se vuelva concreto
  27. 27. Nexus Aumenta Scrum Construido sobre los principios, valores y fundamentos de Scrum  Crea rutas de comunicación  Extiende y profundiza los mecanismos de inspección y adaptación  Fomenta la transparencia continuada  Depende en la inteligencia hacia arriba Evita soluciones fijas y definidas que agregan sobrecostos.
  28. 28. Nexus - Roles, Eventos y Artefactos Roles Eventos Artefactos Equipos de Desarrollo El Sprint Lista de Producto El Equipo de Integración Nexus* Planificación del Sprint Nexus* Lista de Pendientes del Sprint Nexus* Dueño de Producto Planificación del Sprint Lista de Pendientes del Sprint Scrum Master Scrum Diario Nexus* Incremento Integrado Scrum Diario Revisión del Sprint* Revisión del Sprint Retrospectiva del Sprint Nexus**Específico de Nexus
  29. 29. El Equipo de Integración Nexus  Un Equipo Scrum  Trabaja con la Lista de Producto  Los Miembros están tiempo completo o medio tiempo  Su composición puede cambiar entre Sprints  Se enfoca en las dependencias y en la facilitación de la integración
  30. 30. Scrum Diario Nexus • ¿El trabajo del día anterior fue integrado exitosamente? Si no fue así, ¿por qué no? • ¿Cuáles nuevas dependencias han sido identificadas? • ¿Qué información necesita compartirse entre los equipos del Nexus?
  31. 31. Prácticas de Scrum Profesional a Escala Dependencias Reificación Equipos de Características Automatización de artefactos ALM Micro-servicios Desarrollo conducido por pruebas Metadatos de la Lista de Producto Integración continua de todo el trabajo Refinamiento continuo de la Lista de Producto Compilaciones frecuentes Story mapping Pruebas Frecuentes Mapeo de dependencias entre equipo de la Lista de Producto Limited branching Comunidades de práctica Descaling and Scrumble La Arquitectura contiene experimentación Porciones de los elementos de la Lista de Producto componen los Pendientes del Sprint para ATDD
  32. 32. Desescalar  Escale con precaución  Adicione prácticas o herramientas  Reduzca el paso total, disminuyendo el número de equipos a un número más sostenible (o la velocidad)  Limpie e integre el software actual para que se pueda compilar sobre él en futuros Sprints Velocidad Equipos
  33. 33. Scrumble  Cuando la deuda técnica, el conocimiento del dominio y los resultados de las pruebas abrumen el progreso, haga ‘Scrumble’  Scrumble es un periodo de duración desconocida y de reclutamiento de personal cuando se trabaja para lograr que el progreso se reinicie  El reclutamiento debería minimizarse y el talento aplicado maximizado Equipos Velocidad
  34. 34. Nexus interconecta 3-9 Equipos Scrum que: – Exhiban los principios y el DNA de Scrum –Creen un Incremento de producto reificado – Reduzcan sobrecostos, maximicen resultados
  35. 35. Volvamos al tema de la Deuda Técnica
  36. 36. Indaguemos
  37. 37. La deuda técnica son las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware. Wikipedia
  38. 38. La deuda técnica son las consecuencias de: • un desarrollo apresurado • un desarrollo inconsciente de software • o un despliegue descuidado de hardware Que se terminará pagando ya sea con: • baja velocidad de desarrollo • inversión de tiempo removiéndola o • bajo rendimiento del sistema @jorge_abad
  39. 39. ¿Quienes han estado en un Proyecto que fue cancelado debido a que era más práctico iniciar de cero que continuar trabajando en el?
  40. 40. ¿Y CÓMO LUCE?
  41. 41. Nuestro servidor agotado por : • La carga • Necesita continuos reinicios • Carecemos de • buen hardware • Software liviano adecuado para el hardware • Software bien construido (por lo general las últimas dos)
  42. 42. Ejemplos
  43. 43. ¿Algún ejemplo más?
  44. 44.  Presiones de Negocio  Poco entendimiento del proceso  Software no modular, clases muy acopladas  Falta de una buena suite de pruebas  Falta de documentación  Falta de colaboración entre equipos  Falta de acompañamiento a desarrolladores jóvenes  Desarrollo paralelo (en dos o más branches)  Postergar la refactorización  Inexistencia de estándares o no alineación con ellos  Poco conocimiento por parte del desarrollador de buenas prácticas  Poca apropiación del código  Pobre liderazgo técnico  Subutilización del software base  Sobreutilización del software base  Presiones por cambios de último minuto  Entre otros Causas
  45. 45. Síntomas  Despliegue lentos  Constantes reinicios del servidor por consumo de memoria  Código inmantenible  Código inestable o con el síndrome de castillo de naipes  Toco aquí y daño allá  No sé donde tocar  Tengo miedo a tocar  Costo alto de cambios  Costo alto de corrección de código  Disminución de la velocidad de los sprints  Entre otros
  46. 46. Efectos
  47. 47. Deuda técnica a ser pagada
  48. 48. Process Debt Methodology Debt
  49. 49. Prácticas Técnicas compartidas por todo el equipo • Revisiones de código • Pruebas de Aceptación • Pruebas Unitarias • Propiedad Colectiva de Código • Clean Code • Test Driven Development • Integración Continua • Entrega Continua (Continuous Delivery) • Diseño Simple • Programación por pares • Mob Programming • Estándares de codificación • Refáctoring • Monitoreo de la deuda técnica
  50. 50. Como resolverla
  51. 51. Como resolverla
  52. 52. Cerrando
  53. 53. Qué nos ha enseñado la experiencia
  54. 54. Qué nos ha enseñado la experiencia Colaboración Entrega de Valor (Temprana, continua y con excelencia técnica) Adaptación al Cambio Mejora Continua – Alistair Cockburn Maximice el “Corazón de Ágil”
  55. 55. Qué nos ha enseñado la experiencia
  56. 56. Qué nos ha enseñado la experiencia
  57. 57. Qué nos ha enseñado la experiencia
  58. 58. Donde No hay • Ni compromisos • Ni planes • Ni métricas • Ni Arquitectura • Ni ingenieria AGILE NO es desarrollo hippie
  59. 59. PREGUNTAS
  60. 60. Sobre el material utilizado  Esta presentación se basa en el trabajo de Guther Verheyen (@Ulizee) y otras personas de Scrum.org  Adicional en – Lucho Salazar @LuchoSalazarC – Javier Garzas @jgarzas – Ángel Nuñez @snahider  Además de las referencias explícitas, esta presentación puede contener material o ideas de otras personas u organizaciones que omití sin intención.  Nota: Trate de dar crédito a todos, pero si consideras que faltaste por que no te referencié o debo modificar algo de tu propiedad, por favor, no dudes en hacérmelo saber, contactándome a: Jorge.abad@gmail.com
  61. 61. Aviso de Copyright  Eres libre de: – Compartir- copiar, distribuir y transmitir este trabajo – Modificar- adaptar el trabajo  Bajo las siguientes condiciones – Atribución: debes atribuir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo).  Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.  Para más información ver http://creativecommons.org/licenses/by/3.0/
  62. 62. Información de contacto  Jorge Hernán Abad Londoño –Jorge.abad@gmail.com

×