José Manuel Ferri - DevOps la evolución de la fábrica de software
•Descargar como PPTX, PDF•
0 recomendaciones•238 vistas
Ponencia: DevOps la evolución de la fábrica de software - XIV Congreso de Ingeniería Informática de la Comunitat Valenciana – SI2019
Recomendados
Recomendados
Más contenido relacionado
Similar a José Manuel Ferri - DevOps la evolución de la fábrica de software
Similar a José Manuel Ferri - DevOps la evolución de la fábrica de software (20)
Más de COIICV
Más de COIICV (20)
Último
Último (20)
José Manuel Ferri - DevOps la evolución de la fábrica de software
- 1. DevOps: La evolución de la fábrica de Software 11 de abril 2019 SEMANAINFORMATICA.COM #SI2019
- 6. Fábrica SW Fábrica de productos SW #SI2019
- 7. Fábrica SW Fábrica de SW viejuna #SI2019
- 8. Agilidad 1ª fase del cambio #SI2019
- 11. DevOps Flujo de entrega continua #SI2019
- 17. Fábrica SW Nueva fábrica de SW #SI2019
Notas del editor
- PRESENTACIÓN Buenos días, gracias por vuestra asistencia. Soy Jose Manuel Ferri, Director de Operaciones en AHORA. Os voy a hablar de DevOps. ¿Estáis familiarizados con esto de DevOps?. Bueno yo supongo que hoy os llevaréis una idea mucho más clara de DevOps, ya que luego hay otra charla que habla de DevOps con alguien que sabe mucho de esto. Bueno, yo os voy a trasladar nuestra experiencia en todo esto. Y espero que os sirva. Supongo que os veréis reflejados en algunos de los aspectos que voy a comentar en la presentación. Y os voy a hablar de DevOps desde la perspectiva Personas.
- Si nos centramos en la industria del automóvil. Hablo de este tipo de industria porque creo que muchos estándares y procesos de fabricación se crean con esta industria. Tuvo su evolución desde la producción artesana, a la producción en masa.
- Y como de la producción en masa, pasa la producción Lean. Y pasan muchos años para que esto produzca. En este momento ya estamos con cosas como mejora continua, eliminación de desperdicios, tableros Kanban, etc.
- Y claro llega la transformación digital, automatización, industria 4.0 y demás. Y yo creo que el gran reto de la industria, de las empresas es entender que Hoy todas las empresas son de Software, y creo que ese el reto de la transformación digital y las industria 3, 4 o 5.0. Entender esto y saber que ese es el problema que hay que resolver. Y para resolver esto, la agilidad no es una opción, o algo que pertenece a los equipos de desarrollo, si no que es un imperativo de la empresa. Y cómo los marcos de trabajo que vamos a ver a continuación son ahora un referente para todo tipo de industria o empresa. Así como fueron previamente referentes para nosotros, cambiaron las tornas y ahora es al contrario.
- Y esto es una fábrica de Software, al menos la nuestra es así. Una fábrica formada, mayoritariamente, por personas.
- Y cuando de fábrica de Software, hablo de productos Software que se vayan a utilizar mayoritariamente de forma estándar. A diferencia de lo que sería un proyecto para un cliente o un producto para una empresa. Esto no quiere decir que lo que voy a explicar no sirva para este tipo de proyectos o de productos.
- Nosotros representamos la fábrica de Software viejuna, como pone ahí, como un Croissant donde únicamente existe la visión tecnológica. Es decir, un producto Software lo diseñan únicamente desarrolladores. Muchas más visiones.
- Para transitar de una fábrica viejuna a una fábrica actual nosotros tropezamos casi por casualidad con la agilidad. Y aquello para nosotros fue el punto de inflexión. Donde entre otras bondades, comenzamos a ver la importancia del equipo y las distintas dinámicas que hacen que el equipo evolucione hacia equipos autoorganizados o equipos autogobernados. Conceptos como Producto Mínimo Viable, Backlog ordenado, entregas frecuentes, Dailys, Retrospectivas, etc. Esto de la agilidad puede que suene ya a viejuno. Si hablamos de Scrum, podemos pensar que eso está ya muy visto. Lo que yo creo es que la agilidad tiene que estar ya en la genética de la empresa, no es algo que hoy por hoy tengamos que decir: tenemos que implementar agilidad o virar a la agilidad. Esto debería de estar asumido y actuar de forma ágil en todos los sentidos. Es ya un hábito como lavarse los dientes, comer verdura o cantar en la ducha.
- Y descubriendo la agilidad, descubrimos el manifiesto Ágil. Yo decía por ahí que son un fan del manifiesto ágil y de sus principios. Pero es que lo primero que habla es de Personas e interacciones, sobre procesos y herramientas. Esto es lo que estoy destacando en la charla. Los principios vienen a reforzar estos cuatro aspectos: equipos auto-organizados, entregas frecuentes, respuesta ante el cambio, software funcionando, ruptura de silos, etc.
- Bueno, y llegamos a DevOps. Habitualmente este símbolo representa DevOps: Developer – Operations. Pero para mí, esto es una parte, donde básicamente representamos la integración continua y el despliegue continuo.
- Nos falta una parte muy importante que es la exploración continua. Quiere decir esto que tenemos que estar constantemente inspeccionando el mercado, sondeando sus necesidades, ver cómo innovar nuestros productos, estudios de mercado, etc.
- Entrega de valor a mayor velocidad, por tanto entrega de valor en un flujo continuo. Aunque estemos trabajando con Sprints, para qué queremos guardar en la nevera una funcionalidad si ya está lista, la entregamos. La generación de flujo en el Kanban es esencial para poder conseguir esto. Y la velocidad es esencial en esto y esto es lo que tienen que entender todas las personas. Y aspirar a desplegar todos los días. Entrega de valor a diario. Organizar al equipo alrededor del valor. Muchas veces es complicado dar valor a todo lo que hacemos y debemos de aprenderlo.
- DevOps viene a resolver la brecha entre Desarrolladores, los que desarrollan y sacan paquetes del producto y Operaciones, los que los despliegan en los clientes, aseguran que se utiliza y dan feedback. Ruptura de silos, departamentos, etc. Yo me acuerdo cuando trabajábamos en cascada y recuerdo sesiones de toma de requerimientos por una serie de personas que luego los documentaban, y esos documentos pasaban por otros analistas, de ahí a los programadores, a los implantadores y, finalmente, llegaba al cliente y cuando el cliente lo veía … venía el problema: esto no es lo que yo esperaba. Y entonces empezaba el lío. Lo mismo cuando estoy desarrollando, espera que el test lo hacemos al final del ciclo de desarrollo, cuando ya no hay tiempo de reacción en el sprint.
- Trabajar juntos o estar sentados unos al lado de otros no es trabajar en equipo. Así como si por cercanía se fuera a producir algún tipo de milagro. Vuelvo a lo del manifiesto ágil: personas e interacciones. Un equipo multidisciplinar es un equipo que cuenta con todas las capacidades necesarias como para sacar un producto adelante desde principio a fin. Normalmente un equipo multifuncional minimiza las dependencias con otros equipos, aunque sigue habiendo en la medida de que haya varios equipos trabajando sobre el mismo producto. Esto no quiere decir que en un equipo multidisciplinar todos las personas sepan hacer de todo. Habrá especialistas expertos en lo suyo, pero que serán capaces de colaborar con otras personas del equipo para conseguir compromisos.
- Pero también introduce otras muchas visiones en el producto Software que estemos desarrollando: visión negocio, UX/UI, QA, arquitectura, sistemas, etc.
- Al final se crea una cultura alrededor de todo esto. Es complicado por la propia naturaleza de las personas, que tenemos muchas teclas. Y los informáticos tenemos más teclas que los demás. (la patrona de los informáticos es Santa Tecla).
- Llegamos a la nueva fábrica de Software, con personas que se organizan y actúan de forma diferente. Para llegar a la nueva fábrica de Software, donde se han eliminado barreras, equipos multidisciplinares, integrando múltiples visiones Relación de valores y capacidades que exigimos a los equipos. Descentralización de decisiones Compromiso (asumir la responsabilidad) Transparencia Construir con calidad Alineamiento Visión sistémica Visión económica Todos aquellos valores que propone la agilidad, DevOps y otros marcos como SAFe.
- Pero cuidado con los fantasmas, que siempre están ahí acechando. La vuelta al mundo antiguo o al mundo oscuro es muy fácil, simplemente porque es lo que conocemos. La mayoría de estos fantasmas vienen por el Legacy que arrastramos. Normalmente a las personas nos cuesta aceptar el cambio y entrar en estas dinámicas requiere preparación. Y no únicamente preparación técnica o metodológica, sino también psicológica, mental. Muchas veces no nos sentimos con la libertad, el tiempo o el poder de hacerlo. Decirles a las personas que se pueden equivocar, para evitar el miedo al fracaso o sentimiento de culpa. Asumir responsabilidad, porque por defecto nos hemos acostumbrados al quietismo, a no asumir riesgo o a hacer lo que nos dicen los demás. Yo creo que estamos programados así. Excusas de todo tipo. Dependencias. Paternalismo. Departamentos. Proteccionismo. Falta de empatía. Son cuestiones que tienen mucho peso es ese Legacy al que hacía referencia.
- Y hay que estar constantemente con el evangelio. Que la dirección de la empresa sea la fuerza motora de esto. Dinámicas como Dailys, Plannings, Reviews que nos permitan apreciar los avances. U otras como como las retrospective donde el equipo aprende e innova y maduran. Virar o pivotar sin culpabilidad ni piedad. Quiere decir esto que si los equipos asumen responsabilidad y compromiso es porque saben que pueden equivocarse, no tienen miedo al fracaso o aprenden de él. Y si el camino no es el adecuado no persistamos por ese camino, cambiemos aunque tengamos que tirar trabajo a la basura. Porque nada es para siempre y pensar que un producto va a ser eterno no tiene sentido.
- Bueno como resultado, como conclusión, nuestro croissant ya no está cerrado y no está solo. Hemos aprendido a colaborar y aquí hay unos cuantos grandes profesionales que nos están ayudando a crecer con sus visiones.