Desafíos en las organizaciones de software que usan Agile

906 views
805 views

Published on

Las organizaciones de software que han adoptado métodos ágiles con éxito se encuentran con que sus organizaciones son lentas en comparación. Hay que "agilizarlas".

Published in: Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
906
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
16
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Desafíos en las organizaciones de software que usan Agile

  1. 1. Desafíos en la gestión de las organizaciones de software 19 de febrero de 2014
  2. 2. Desafíos en la gestión de las organizaciones de software LIDICALSO Laboratorio de Investigación y Desarrollo en Ingeniería y Calidad de Software LIDICALSO http://www.institucional.frc.utn.edu.ar/sistemas/lidicalso/ Departamento de Ing. en Sistemas de Información UTN FRC
  3. 3. Álvaro Ruiz de Mendarozqueta aruiz@sistemas.frc.utn.edu.ar aruizdemendarozqueta@fundacionsadosky.org.ar skype: alvaro.rdm http://www.slideshare.net/AlvaroRuizdeMendaroz
  4. 4. Hoy el software está en todos lados
  5. 5. ¿Software en un BMW? 2006
  6. 6. 2014 Auto autónomo
  7. 7. Fuente: Revista IEEE Spectrum (página web) 2014
  8. 8. Pierna biónica
  9. 9. Mano biónica
  10. 10. Google Glass
  11. 11. SARA
  12. 12. SAC-D Aquarius
  13. 13. La industria creció mucho desde el año 2000
  14. 14. Empleo, ventas, exportaciones El regreso 16
  15. 15. Egresados 17
  16. 16. Ventas/Exp. Empleo Egresados 2005 2007 2006 2009 2008 2011 2010 2015 ? 2013 2012 2014
  17. 17. Ciencias de la Computación FCEyN - UBA 80 70 67 75 61 60 50 46 40 30 20 Porcentaje de egresadas 19 11 10 0 60s 70s 80s 90s 00 Actual 19
  18. 18. Costos Costos 72 % RH 13 RH Directos 15 9 RH Indirectos 63 Infraestructura Otros Fuente:
  19. 19. Algunas ventajas de la región en la que estamos
  20. 20. Alto PBI
  21. 21. Universidades Personas formadas Time zone con USA y Latam MERCOSUR Ley de Software Polos tecnológicos Emprendedorismo
  22. 22. Ley de Software influyó en el uso de modelos de calidad
  23. 23. Evaluaciones 2003-2007 40 evaluaciones 13 empresas CMM, CMMI, ISO Normalización de datos Fuente: Lidicalso UTN FRC
  24. 24. CMMI 5
  25. 25. Fuente: Lidicalso UTN FRC
  26. 26. Fuente:
  27. 27. Observaciones ¿CMMI se usa menos? ¿se dejó de usar? Foco en procesos Hay problemas de calidad La industria se expande
  28. 28. Observaciones… Poco uso de herramientas Procesos descritos en documentos Poca integración entre herramientas
  29. 29. Cómo se hizo la mejora de procesos
  30. 30. Qué deberíamos hacer Inicio Establecer objetivos y necesidades de mejora Evaluar comparando con un modelo y planificar las mejoras
  31. 31. Qué se hace Inicio Establecer nivel de CMMI deseado Empezar por nivel 2 en orden y seguir una receta
  32. 32. Problemas No asignar recursos a mejora “Están ocupados trabajando…” No planificar El área de calidad no hace lo que recomienda… Personal de calidad sin experiencia
  33. 33. Problemas Interpretar a los modelos de una única manera Repetir recetas sin entender el contexto Repetir recetas sin entender al equipo de trabajo
  34. 34. Problemas Es difícil ver mejoras concretas en el corto plazo
  35. 35. Riesgos SQA no es lo único que se hace Calidad es lo que hacen los de calidad Falta de integración de actividades Poca planificación Que la mejora no sea continua
  36. 36. Procesos Toda construcción de software sigue un proceso: Formales Informales Muchos procesos están tan mal hechos como el software
  37. 37. Horror de proceso CMMI, PP SG 3 Commitments to the project plan are established and maintained. SP 3.3 Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution. Planilla con firma de cada uno de los miembros del equipo (pocos participaron de la confección del plan)
  38. 38. Más horror… Procesos con 15 roles para una organización cuyo promedio es de 4 personas por proyecto
  39. 39. Percepción de la mejora de procesos
  40. 40. Al mismo tiempo se comenzaron a usar los métodos ágiles
  41. 41. El desarrollo de software es, esencialmente, un proceso de aprendizaje Mary & Tom Poppendieck Lean Software Development
  42. 42. Manifiesto por el desarrollo Ágil de software Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: http://agilemanifesto.org/
  43. 43. Manifiesto Individuos e interacciones sobre procesos y herramientas A Valoramos más B C
  44. 44. Manifesto Software funcionando sobre documentación extensiva Valoramos más
  45. 45. Manifesto Colaboración con el cliente sobre negociación contractual Valoramos más
  46. 46. Manifesto Respuesta ante el cambio sobre seguir un plan Valoramos más
  47. 47. Manifiesto ágil (‘01) principio #1 satisfacer al cliente a través de entregas tempranas y continuas de software que provea valor http://agilemanifesto.org/
  48. 48. … de software que provea valor despachador de pedidos generador de valor software que funciona software que cubre una necesidad
  49. 49. enfoque predictivo enfoque adaptativo c1 concepto producto plazo de entrega cn c2 p1 p2 plazos de entrega pn
  50. 50. un buen proyecto ágil tendrá que desarrollar algo mejor que lo planeado originalmente Martin Fowler The New Methodology
  51. 51. Ventajas Agile Cambios de requerimientos son bienvenidos Entregas rápidas Feedback del cliente todo el tiempo Software funcionando pronto Testing temprano
  52. 52. Comparemos proyectos de software con la mejora de procesos
  53. 53. ISO Fecha de auditoría 9001 Manual de Calidad Procesos de la organización Auditoría Comité de Calidad
  54. 54. ISO Fecha de auditoría 9001 Manual de Calidad Procesos de la organización Auditoría Comité de calidad
  55. 55. ¿Es ágil?
  56. 56. Mejora de Procesos Parece que valoramos más personas e interacción herramientas y procesos software funcionando documentación exhaustiva colaboración con clientes responder a los cambios foco en los resultados negociación de contratos seguir un plan ¿cuál es el foco?
  57. 57. Habíamos dicho en nuestro estudio
  58. 58. No es ágil
  59. 59. Comparemos proyectos de software con un plan de entrenamiento
  60. 60. Capacitación Presupuesto anual Calendario anual de cursos Revisión mensual Dictados Asistencia Costos Encuesta de satisfacción Evaluación anual de desempeño
  61. 61. Capacitación ¿Cómo podemos agilizar a la capacitación?
  62. 62. Tenemos proyectos ágiles y organizaciones lentas Proyecto “Diseño de un sistema de gestión” Lidicalso UTN FRC
  63. 63. Desafío: cómo hacemos que la organización sea más ágil
  64. 64. Veamos cómo hacerlo en mejora de procesos
  65. 65. Qué deberíamos hacer Inicio Establecer objetivos y necesidades de mejora Evaluar comparando con un modelo y planificar las mejoras con un backlog
  66. 66. Qué deberíamos hacer Aplicar manifiesto y principios ágiles Extender resultados de proyectos a mejora continua
  67. 67. Individuos e interacciones sobre procesos y herramientas Equipo Scrum para la mejora Proceso de mejora A Valoramos más B C
  68. 68. Software funcionando sobre documentación extensiva Mejora implementada Valoramos más Proceso modificado
  69. 69. Colaboración con el cliente sobre negociación contractual Empleados son los clientes Valoramos más Despliegue de procesos
  70. 70. Respuesta ante el cambio sobre seguir un plan Implementar mejora de alto impacto Valoramos más Implementar los procesos
  71. 71. Manifiesto ágil (‘01) Apliquemos el principio #1 a la mejora continua satisfacer al cliente a través de entregas tempranas y continuas de software que provean valor
  72. 72. Manifiesto ágil (‘01) Apliquemos el principio #1 a la mejora continua satisfacer al cliente a través de entregas tempranas y continuas de mejoras que provean valor
  73. 73. Un enfoque ágil para la mejora de procesos Caso
  74. 74. Empresa de desarrollo de software con filosofía ágil Objetivo 2014 Certificación ISO 9001:2008 Toda la organización Aplicar Agile en toda la organización
  75. 75. Comité de calidad PMO Quality champion Scrum El sistema de gestión de calidad es el producto Todos los empleados son los clientes
  76. 76. Scrum Team Representa la mayoría de los roles de la organización Define el esfuerzo disponible Director es el PO
  77. 77. Puntos claves Mapas Agile vs ISO Conocimiento de Scrum Prácticas de Ingeniería Team members
  78. 78. Backlog
  79. 79. Mapa entre Agile e ISO Acciones preventivas y correctivas
  80. 80. Tablero Scrum trello.com Create Quality Policy [5.3] [4.2.1]
  81. 81. Mapa entre ISO y Scrum
  82. 82. QMS 7 Reviwers 7.3 7.2 Product realization 7.1 7.3.4/5/6 Sprint planning 7.2 7.3.1 8.2.2 7.3.4 V&V 6.2 Product Backlog Sprint Backlog 7.1 7.3 Scrum Master 7.2 Sprint Review 7.2 Impediments 7.3.3 8.2.1 7.2.3 Customer Product Owner Customer Daily 7.3 Sprint One to four weeks Team Needs Retrospective 6.2 Requirements Product UX A3 A4 A2 A5 A1 Records 7.3 Architecture 7.3 8.2.1
  83. 83. Un enfoque ágil para la mejora de procesos Caso
  84. 84. Empresa de desarrollo de productos para grandes empresas Objetivo 2014 Mejora de un producto y sus procesos Consolidar prácticas ágiles Automatización
  85. 85. Scrum Equipo: multi empresa y multi rol Cliente: técnico y gestión Empresa: técnico y gestión Consultor externo Scrum master PO: gerente del cliente
  86. 86. Backlog de mejoras priorizado Implementación de herramientas Capacitación Visita a clientes y reuniones con usuarios finales
  87. 87. Puntos claves Gestión de impedimentos Team members Balance: mejora vs. producción Compromiso
  88. 88. Tablero Scrum Integrado al sistema de gestión
  89. 89. User Story Desarrollo propio
  90. 90. ¿Qué más podemos hacer?
  91. 91. Cambiar la mirada sobre las organizaciones
  92. 92. Testing Desarrollo [PMBOK]
  93. 93. Área de responsabilidad Clientes Productos Proyectos Ingeniería Personas Planeamiento, educación, calidad, infraestructura, presupuesto
  94. 94. Funciones antes que organigramas el enfoque predictivo limita ciclos de aprendizaje capacidad de adaptación generación de valor Ejemplo: Modelo EFQM
  95. 95. Pasos a seguir Para cada área o función clave Determinar las sub funciones Aplicar el manifiesto ágil
  96. 96. what why Individuals Tangible Customer Responding continues and Results over collaboratio to change delivery interactions comprehensi n over over of over ve contract following a valuable processes documentati negotiation plan Results and tools on M#3 M#4 P#1 M#1 M#2 Products know the to align communicat roadmap customer make sure roadmap projects and e roadmap should be needs being changes and (strategy) resources often, face- clear, covered by its reasons to-face, and makingthe roadmap are properly collect sense for should be introduced feedback engineering clear for all and and business parts communicat ed to all relevant actors roadmap means available for the whole involved people
  97. 97. Organización
  98. 98. Algunas conclusiones
  99. 99. La mejora de procesos no parece ser efectiva con el enfoque usual Agile trajo un cambio de paradigma Sus principios aportan sentido común Pueden extrapolarse a otras actividades Mejora de procesos
  100. 100. Si hay una oportunidad para las empresas de software… …necesitarán agilidad para aprovecharla
  101. 101. Es parte de un proyecto…
  102. 102. diseño de un sistema de gestión de una operación de desarrollo de software, usando métodos ágiles y modelos de calidad Laboratorio de Investigación y Desarrollo en Ingeniería y Calidad de Software LIDICALSO http://www.institucional.frc.utn.edu.ar/sistemas/lidicalso/ Departamento de Ing. en Sistemas de Información UTN
  103. 103. Aplicar Extender principios resultados ágiles de proyectos a una organización
  104. 104. Qué aprendimos en los proyectos principios Lean concepto - producto proceso Scrum-Kanban generación de valor expandir conocimiento gestión de proyectos entregas frecuentes flujo de trabajo prácticas XP disciplina diseño de calidad automatización construcción de SW
  105. 105. Marco de gestión típicamente foco en procesos propuesta generación de valor organización organigrama áreas de responsabilidad mecanismo conformidad visión / resultados
  106. 106. Participantes Natalia Andriano Miguel Insaurralde Mariano Zibecchi Alvaro Ruiz de Mendarozqueta
  107. 107. ¡Gracias! LIDICALSO UTN FRC
  108. 108. ¡Gracias por venir! http://www.slideshare.net/AlvaroRuizdeMendaroz
  109. 109. Versiones Versión Fecha Descripción Autor 1.0 Feb-2014 Versión inicial. Materiales basados en el proyecto Diseño de un sistema de gestión y presentaciones hechas en UTN y BPM Forum Alvaro Ruiz de Mendarozqueta 1.1 Feb-2014 Comentarios de Mariano Zibecchi y Natalia Andriano Alvaro Ruiz de Mendarozqueta

×