Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Deuda tecnica (Extracto del curso)

17.068 visualizaciones

Publicado el

Extracto del curso sobre Deuda Técnica

Publicado en: Tecnología

Deuda tecnica (Extracto del curso)

  1. 1. @jgarzas DEUDA TECNICA...
  2. 2. @jgarzas
  3. 3. 2001Mi primer proyecto ágil
  4. 4. Esta presentación contiene situaciones reales, basadas en las experiencias del autor, después de pasar ya por más de 80 proyectos, y que… pueden herir la sensibilidad del espectador WARNING  
  5. 5. Y ES QUE HAY VECES QUE LOS PROYECTOS SOFTWARE TIENEN MUCHO PARECIDO CON UNA PELI DE TERROR WARNING  
  6. 6. The walking dead software El desarrollo software zombi
  7. 7. En vez de alimentarse de humanos se alimentan de lo mas importante para un proyecto: su felicidad, productividad y presupuesto
  8. 8. Clean Code Calidad Software Ágil Deuda Tecnica...QA Agil
  9. 9. La agilidad ha recuperado del pasado (y adaptado al presente) grandes buenas prácticas de gestión y desarrollo software
  10. 10. Deuda técnica, eufemismo tecnológico que refiere a las consecuencias de un desarrollo software malo
  11. 11. Un desarrollo con mala calidad, obtiene beneficios a corto plazo. Pero puede generar deudas cuyos intereses se disparen, se alarguen o incluso sean imposibles de pagar.
  12. 12. “Poca deuda técnica acelera el desarrollo, siempre que se page con prontitud.” Ward Cunningham, OOPSLA 1992
  13. 13. “El peligro viene de la deuda que no se paga. Cada minuto que pasamos con código no del todo correcto se incrementan los intereses”
  14. 14. “Hay organizaciones enteras bloqueadas por la carga de la deuda técnica”
  15. 15. En 2004, en Refactoring to Patterns, Joshua Kerievsky introdujo la “negligencia arquitectónica”, concepto similar a la Deuda Técnica.
  16. 16. Definición de Deuda Técnica de Kruchten
  17. 17. Visible Mayoritariamente invisible Visible Aspectos de evolución: capacidad de evolucionar Aspectos de calidad: mantenibilidad Nuevas características Nueva funcionalidad Defectos Mala calidad externa Brechatecnológica arquitectura código Deuda arquitectónica Mala calidad interna Deuda estructural Deuda de pruebas Deuda de documentación Complejidad de código “Code smells” Violaciones de estilo de código Definición de las DeudAS Técnicas de Kruchten
  18. 18. El cuadrante de la Deuda Técnica de Fowler Temeraria Prudente DeliberadaInadvertida “No tenemos tiempo para pensar el diseño” “Tenemos que entregar ya y asumir las consecuencias” “¿Qué está pasando?” “Ahora sabemos cómo deberíamos haberlo hecho”
  19. 19. El cuadrante de la Deuda Técnica de Fowler Temeraria Prudente DeliberadaInadvertida “No tenemos tiempo para pensar el diseño” “Tenemos que entregar ya y asumir las consecuencias” “¿Qué está pasando?” “Ahora sabemos cómo deberíamos haberlo hecho” IRRESPONSABLE INCOMPETENTE DEUDA TÉCNICA
  20. 20. La Taxonomía de la Deuda Técnica de McConnell
  21. 21. NO DEUDA: Funcionalidades no desarrolladas, funcionalidades eliminadas, etc., no es deuda ya que no implica pago de interés
  22. 22. DEUDA TÉCNICA I. Deuda incurrida sin intención debido trabajo de mala calidad
  23. 23. DEUDA TÉCNICA I. Deuda incurrida sin intención debido trabajo de mala calidad II. Deuda incurrida de manera intencional II.A). A corto plazo, incurrida reactivamente, por razones tácticas II.A.1. Buscar atajos (como el préstamo de un coche) II.A.2. Buscar muchos pequeños atajos (como la tarjeta de crédito)
  24. 24. “Déjate de probar (o de diseñar, refactorizar, etc.) y ponte a programar, que no tenemos tiempo”
  25. 25. Bond, el Jefe de Proyectos Bond, Sangre fría para no saltarse la calidad, diseño, pruebas, e ir a programar a destajo, cuando hay problemas.
  26. 26. Saltarse una actividad necesaria y hacerla a destiempo lleva entre un x10 a un x100 de sobre tiempo Fagan, IBM, 1976
  27. 27. II. Deuda incurrida de manera intencional II.B.) A largo plazo, PROACTIVAMENTE, por razones estratégicas…
  28. 28. Los proyectos software chupa sangre
  29. 29. Ahorro de costes en personal
  30. 30. Las ofertas más competitivas del mercado
  31. 31. Fidelización de clientes
  32. 32. Aumento, casi indefinido, vitalicio, del tiempo de proyecto (y de la facturación)
  33. 33. Aumento de las tarifas
  34. 34. ¿Te has comprado un walking dead software?
  35. 35. La buena de la película
  36. 36. La deuda técnica buena…
  37. 37. La deuda técnica buena (Henrik Kniberg, 2013)
  38. 38. ¿Cuánto es corto plazo?
  39. 39. “My experience is that, in software, the “good mess” is only good up to a few days, definitely less than a week”. Henrik Kniberg
  40. 40. La deuda técnica buena (Henrik Kniberg, 2013) Fija un tope
  41. 41. Evita el síndrome de las ventanas rotas, pon un tope de deuda técnica
  42. 42. KYBELE  CONSULTING  S.L.  www.kybeleconsul;ng.com  -­‐  Copyright  ©  2012  All  rights  reserved.  Contains  propietary  informa;on.     Hoy se impone el “construir lo correcto” antes que “construirlo correctamente” (A. Savoia. Testing is dead, GTAC 2011)
  43. 43. “La vida es demasiado corta para construir algo que nadie quiere”   - Ash Maurya
  44. 44. El que parecía bueno pero era muy malo
  45. 45. La Deuda Técnica MALA que parecía BUENA
  46. 46. “Muchos confunden la deuda técnica con la idea de que se puede hacer código malo con la idea de mejorarlo después” Ward Cunningham, YOUTUBE 2009
  47. 47. “La capacidad de mejorar depende de haber preparado el código para poder refactorizarlo” Ward Cunningham, YOUTUBE 2009
  48. 48. 29220 Líneas de código ¿Alguien cree que esto tiene solución?
  49. 49. Las causas: qué crea al malo
  50. 50. Por no obrar bien cuando se debía 1  
  51. 51. La mayor causa de fracaso en proyectos software viene de la presión del calendario…” - Brooks (1975)
  52. 52. IMPACTO LINEAL DEBIDO A LA LEY DE PARKINSON IMPACTO NO LINEAL DEBIDO A ERRORES EN LA PLANIFICACIÓN, ERRORES, PRÁCTICAS DE ALTO RIESGO 100% >100%< 100% Objetivo como porcentaje de la estimación nominal Sobre estimaciónEstimación por debajo Coste Esfuerzo
  53. 53. KYBELE CONSULTING S.L. www.kybeleconsulting.com - Copyright © 2008 All rights reserved. Contains propietary information. 6060
  54. 54. KYBELE CONSULTING S.L. www.kybeleconsulting.com - Copyright © 2008 All rights reserved. Contains propietary information.
  55. 55. KYBELE CONSULTING S.L. www.kybeleconsulting.com - Copyright © 2008 All rights reserved. Contains propietary information.
  56. 56. Lo que nunca, nunca, nunca nadie lo ha vulnerado…. Calidad
  57. 57. Causas naturales 2  
  58. 58. El software es ajeno a todas las Leyes físicas salvo una…
  59. 59. La entropía
  60. 60. Las Leyes de Lehman
  61. 61. Los que vienen del pasado 3  
  62. 62. Durante años la “calidad software clásica” luchó en vano
  63. 63. ¿Calidad Software? EL de calidad
  64. 64. ¿Los registros de calidad?
  65. 65. Pidiendo… ¿comentarios en el código?
  66. 66. Los creados por el hombre 4  
  67. 67. ¿Solucionas los problemas de productividad añadiendo gente y más gente?
  68. 68. ¿Hay métodos de cálculo?
  69. 69. No existe una única definición
  70. 70. SQALE(Software Quality Assessment based on Life-cicle Expectations) (Letouzey, 2012)
  71. 71. SQALE: medir la calidad del software equivale a medir su deuda técnica.
  72. 72. SQALE, define 8 características en base a la ISO 9126 (añade la reutilización)
  73. 73. La organización define estos datos
  74. 74. Con esos datos, la herramienta correspondiente podrá calcular la deuda técnica del proyecto (en SQALE se llama SQI), realizando un análisis del código y sumando cada requisito no funcional incumplido que encuentre por su coste asociado (función de remedio).
  75. 75. Herramientas que lo soportan: SonarQube, SQuORE y Mia-Quality
  76. 76. SQALE, en SonarQube.
  77. 77. CAST - Bill Curtis et al. (Curtis et al., 2012)
  78. 78. Limitaciones de SQALE, Bill y el plugin deuda técnica de SonarQube: no suele costar el mismo esfuerzo solucionar cada violación en los distintos módulos del software.
  79. 79. Chin et al, 2010
  80. 80. Aportan una visión de la deuda técnica que engloba desarrollo y mantenimiento software. Distinguen entre distintos tipos de intereses y explican cómo calcularlos.
  81. 81. Pero cuantifican la deuda técnica en términos de todo el software. Sería más objetivo centrarse en pequeñas partes del software y dar soluciones y mejoras para cada situación particular.
  82. 82. El científico al que se le va de las manos
  83. 83. (Nugroho et al., 2011) utilizan el método SIG/TÜViT de evaluación de calidad del software, pero es MUY COMPLEJO
  84. 84. (Short, 2010), NO CONSIDERA LOS errores o problemas técnicos, se basa en salarios, licencias, etc.
  85. 85. El final…
  86. 86. Pros, fácil de entender
  87. 87. Contras, no hay una única manera de calcularla
  88. 88. “¿Qué hay de malo en copy pegar código?”servicios de 256 parámetros? 30 campos demás en una tabla? Tu carrera es tu responsabilidad. Tu jefe no es tu madre.
  89. 89. No todo es dinero…
  90. 90.  
  91. 91. @jgarzas Recuerda: la mala calidad software siempre la paga alguien, el cliente o el proveedor (aunque no sea consciente de ello)
  92. 92. @jgarzas Trabajas en un desarrollo software o con un desarrollo zombi
  93. 93. ¡Gracias! @jgarzas
  94. 94. Agradecer a Ana María del Carmen que me ha ayudado sobre todo en la parte de las formulas de cálculo. AGRADECIMIENTO
  95. 95. @jgarzas   es.linkedin.com/in/jgarzas/   facebook.com/javiergarzas.blog   www.javiergarzas.com   CONTACTO
  96. 96. dfsfsdf   Realicé el mayor esfuerzo y propósito de referenciar fuentes y atribuir reconocimiento a todos los autores de los textos e imágenes que no fuesen míos, de reconocer los derechos de autor, etc. Pero si crees que algo se me ha pasado o que algo debe ser modificado, añadido o eliminado, por favor mándame un correo a jgarzas@gmail.com DISCLAIMER

×