Inteligencia de negocios y big data para el mundo hispano parlante.

¡Subscríbase al boletín gratuito!


Inteligencia de Negocios en Español - Decideo.com





Actualidades y análisis

Proyectos de BI: Hay que combinar Agile y DevOps


, el 27 Noviembre 2016 | Leído 899 veces

Stephen Brobst, director de tecnología de Teradata, aboga por la agilidad aplicada a la informática decisional; y para dar en el clavo con su mensaje no duda en castigar a los BICC (Centros de Competencia en Business Intelligence) y sus “traje-y-corbata”, que se oponen a los jóvenes con camisa hawaiana. Según él, la solución está en la agilidad dentro de los procesos de desarrollo y en la implementación del método DevOps, es decir, la agilidad en la producción de los proyectos. Una desorganización en los métodos y en la cultura que se nota hoy en día en todo el mundo.



Los proyectos de BI que defraudan, pero ¿Por qué razones?

Proyectos de BI: Hay que combinar Agile y DevOps
Ya sea de estudios de gabinete de consejo, o de simples comprobaciones en empresas, muchos de los proyectos de BI se estancan o simplemente no alcanzan sus objetivos. Mientras que las empresas alzan vuelo, en cuanto al valor creado por el análisis de datos, se torna difícil para muchos proyectos justificar a posteriori la inversión en software y en recursos.

Para Stephen Brobst, las razones son varias, e intenta enumerarlas:
- Los ciclos de desarrollo son demasiado largos, y toman muy poco en cuenta los puntos de vista y las necesidades de los usuarios de negocios.
- Intentar modelar todo en el contexto de una arquitectura global es un error, y eso no permite tener en cuenta suficientemente las necesidades del negocio, y sobre todo de su evolución en el tiempo.
- Para tratar de responder a todas las necesidades, los desarrolladores BI abarcan mucho y construyen “plantas de gas”.
- Las necesidades de negocios evolucionan cada vez con más rapidez. Congelar los tiempos de desarrollo, conduce a entregar soluciones inadaptadas, y difíciles de cambiar.
- Los proyectos de integración de datos se encuentran entre los más complejos desarrollados en las empresas.
- Utilizar los recursos offshore para reducir los costos de desarrollo es una buena idea, pero se vuelve incompatible con la agilidad.
- Y sobre todo, los usuarios de negocios no tienen confianza en lo que los departamentos informáticos producen, y en los plazos de tiempo que se necesitan para la entrega.

Incluso aunque la presentación sea un poco exagerada, Stephen Brobst resume sus antagonismos en una lucha de generaciones, que se materializa en la indumentaria de los protagonistas: se opone a los partidarios de traje y corbata, en vez de esos que usan una simple camisa. Una comparación graciosa porque Stephen Brobst interviene cada vez más así a los eventos de Teradata donde solo los “traje-y-corbata” son invitados, y donde nada más él es autorizado a usar su eterna camisa hawaiana.

El mundo de la informática empresarial sería binario. Por un lado, los que tienen actualmente los cordones de la bolsa de valores: Leen Decideo -bromeo… aunque… -detestan tomar riesgos, y prefieren a vendedores que conocen bien y a los grandes editores de software, eligen tecnologías viejas, probadas, y basadas en sus habilidades actuales.
Por otra parte, los jóvenes vestidos menos elegantes también leen Decideo -De eso estoy seguro – ponen prioridad en buscar soluciones a código abierto, quieren trabajar con las últimas tecnologías disponibles, no dudan en tomar riesgos, e incluso si todavía no son responsables de tomar decisiones, aspiran formar parte rápidamente en los procesos de elección.

Esta comparación poco favorable beneficia sin dudas a un segundo nivel de lectura, ya que los equipos de Teradata, particularmente del lado comercial y de consultoría, pareciéndose más hoy en día a los “traje-y-corbata” que a los jóvenes en camisa hawaiana. Un mensaje subliminal que Stephen Brobst sin dudas amaría hacer a los equipos.

Desde el punto de vista metodológico, los primeros confían en los métodos tradicionales de gestión de proyecto (waterfall), los segundos están adaptados a los métodos ágiles.

Aplicado a lo decisional, la oposición de dos métodos es aún más sorprendente. Los “traje-y-corbata” esperan que todas las necesidades de los clientes sean explicadas para avanzar, cuando los jóvenes de camisa escuchan oportunidades. Los primeros dan privilegio a una aproximación de arriba hacia abajo, y a la reutilización de desarrollos, cuando los segundos parten de las necesidades de los usuarios, y prefieren lo desechable para ser más eficaces.
Los objetivos de los primeros son la toma de mejores decisiones al nivel empresarial, cuando los segundos buscan innovación.

Para Stephen Brobst, los términos usados para describir sus organizaciones son diferentes. Y se irrita con los BICC (Centros de competencias en business intelligence). Para él, el termino de BI queda en el pasado, y se limita a la presentación de informes. Haría falta hoy en día hablar de analítica. Y en el término de “competencia”. Resalta igualmente la falta de agilidad y la capitalización sobre tecnologías viejas. En cuanto al término de “centro”, simboliza una centralización, opuesta a la colaboración moderna al perímetro evolutivo.

Propuesta: combinar los métodos Agile y DevOps

Stephen Brobst, CTO Teradata
Stephen Brobst, CTO Teradata
Esta combinación permite aplicar la agilidad tanto en el centro de desarrollo como en la producción. DevOps es en efecto, en resumen, la aplicación de los métodos ágiles en la fase de test, y de producción de una aplicación.
Limitarse al desarrollo ágil, es en efecto limitarse a mitad de camino. Las aplicaciones son desarrolladas rápidamente, en interacción con los usuarios. Pero se bloquea cuando se pone en práctica la producción. Y parte del beneficio de la agilidad durante el desarrollo se pierde cuando inicia la producción.

DevOps alienta la entrega de cambios rápidos del proyecto, centrándose en el valor producido por los usuarios.

En resumen, la metodología ágil consiste en:
-Dar más importancia a las personas y a las interacciones, que a los procesos y a las herramientas
- Priorizar un software que funcione, en su documentación.
-Valorizar la colaboración con los clientes/usuarios, más que la negociación por contrato.
-Y sobre todo, aceptar los cambios y aportar respuestas, en lugar de aferrarse a seguir con el plan inicial.

Esto se resume en la imagen de arriba: en una metodología tradicional, las necesidades son fijadas; los recursos y plazos son estimados. En una metodología ágil, los recursos y los plazos son fijados, y las características que se puedan desarrollar son estimadas.

Para que esto funcione, el proceso de desarrollo debe modificarse.

-Las soluciones deben ser desarrolladas por etapas, y cada etapa da lugar a una entrega; Esto mejora la satisfacción de los usuarios que quieren que las características de valor añadido sean desarrolladas regularmente.
-Cada versión intermediaria responde a una necesidad de negocio precisa: la colaboración en los equipos es mejorada, como su productividad.
-Y los desarrollos en curso son presentados frecuentemente a sus futuros usuarios, a fin de reacciones, y antes que cada desarrollo finalice; esto muestra a los usuarios la capacidad del equipo de desarrollo a adaptarse a los cambios de necesidades -aceptar y comprender que las necesidades de negocio pueden cambiar rápidamente y que los desarrollos deben seguir.
-La velocidad es privilegiada: los desarrollos rápidos, integrados velozmente, y entregados rápido; sin embargo, desarrollo rápido no significa ausencia de calidad. Al contrario, los desarrollos intermediarios son comprobados con más rapidez, y los errores son detectados antes que se vuelva complicado corregirlos.

-Una planificación de producción a corto plazo, actualizada con frecuencia. Las actualizaciones cotidianas dan visibilidad a los usuarios, a cada iteración.

Cuando Teradata aplica esos consejos al desarrollo del cliente

Según Stephen Brobst, Teradata ha mejorado sus métodos de gestión de proyectos de clientes, y es ahora capaz de aplicar esta combinación Agile/DevOps a sus propios proyectos con clientes.

La base de este nuevo método, la descomposición de un proyecto en incremento. Cada uno de los incrementos aporta una solución a una necesidad de negocio en particular. Así los ciclos son más cortos, y el valor es demostrado a los clientes más rápido. El acento está en la satisfacción de la expectativa del cliente, más que en el confort del equipo de desarrollo.

Incluso internamente en una empresa, se trata de aplicar el principio de la satisfacción del cliente, y de un departamento informático al servicio de sus clientes internos.
Todo esto no es sino sentido común. Desde nuestra juventud, siempre nos hemos dicho que para resolver un problema muy complejo, hace falta cortarlo en pedazos pequeños, y avanzar paso a paso.

Por supuesto, la metodología propuesta por Teradata se apoya en Scrum. Ese marco de desarrollo ágil precisa cómo los desarrolladores son cortados en “sprints”, pequeñas etapas iterativas, donde cada una da lugar a una entrega, y sobre todo una validación permanente para los usuarios.
Sin dudas in fine, el tiempo de desarrollo global es un poco más largo, pero permite llegar a una solución que responda a las necesidades. Muchos proyectos probablemente respetan la planificación inicial, pero su solución final es inadecuada para los usuarios, y ahí la insatisfacción y el sentimiento de fracaso entran en escena.

Otro componente del método recomendado por Teradata, el « data driven design ». En lugar de abarcar todo al principio, intenta centrarse en una parte de los datos, aquellos que correspondan a la necesidad de negocios tratado, y de seguir la integridad de la cadena de la colecta, limpieza, preparación, almacenamiento y análisis. Y luego, pasar a la siguiente serie de datos.

Y así terminó el grueso informe que detalla cómo construir un enorme almacén de datos de la empresa, que finalmente no corresponderá más a las necesidades una vez ejecutado. Se toman los datos uno por uno, y se avanza de nuevo, paso a paso, por cada una de las necesidades de negocios.

Pero es la implementación de DevOps que representa el principal cambio en la metodología. “DevOps”, es la colaboración entre los desarrolladores, y los gestores operacionales del sistema de información, que trabajan juntos durante todo el ciclo de vida de la aplicación, desde la definición de las necesidades, hasta la puesta en producción, pasando por el desarrollo lógico”, explica Stephen Brobst. Hasta ahora, los equipos de producción esperan que un desarrollador haya finalizado antes de empezar a producir. De esta forma, se acumulaba un método de desarrollo ágil, y un método de producción a la antigua. Para el cliente, el extremo de la cadena, solo la lentitud en la puesta en producción era perceptible, borrando los aportes del desarrollo ágil que la precedían.

Evidentemente, las intenciones de los equipos de puesta en marcha son laudables; no quieren desplegar herramientas inestables o mal probadas. Pero esperar no es necesariamente la solución. Así, Netflix, que practica el DevOps, ha establecido un equipo fuerte, responsable de probar los desarrollos, a lo largo del proceso, sin esperar la versión final. Estos desarrollos son son objeto de pruebas intensas, permitiendo corregir los errores a todo lo largo del proceso de desarrollo ágil.

Stephen Brobst sugiere el uso de varias herramientas para apoyar DevOs:
-Herramientas de gestión de versiones: Jenkins, Travis, Teamcity
-Herramientas de gestión de configuración: Puppet, Chef, Ansible, Cfengine
-Herramientas de orquestación: Zookeper, Noah, Mesos.
-Herramientas de virtualización y de disposición en contenedores: Amazon Web Services, OpenStack, Vagrant Docker.

Pero insiste también en una de las fallas de numerosos apasionados de la tecnología: usar estas herramientas no significa en lo absoluto que estés poniendo en práctica DevOps; no son más que herramientas, son útiles mas no suficiente, y no hacen más que apoyar el método.

Un cambio cultural importante, para las empresas y para Teradata

En el papel, puede parecer simple. Bastaría aplicar los ingresos descritos anteriormente. Pero la reticencia es fuerte por parte de los “traje-y-corbata” consientes que su poder se apoya sobre una metodología más a un servicio hacia ellos que hacia los clientes. Esto también pone en tela de juicio las jerarquías y las organizaciones. Stephen Brobst propone un cierto número de preguntas que deberíamos tomar en cuenta.
- ¿Cómo vas a pedir a tus gerentes ejercer su nuevo poder de dirección?
- ¿De qué manera los miembros de los equipos deberán comportarse?
- La transparencia total puede dar miedo. ¿Cómo manejar esto?
- La organización física de oficinas puede tener que evolucionar para facilitar el trabajo en equipo y la aplicación de métodos ágiles. ¿Es posible para usted?
- ¿Quiénes son los campeones de esta nueva agilidad
- ¿Cómo hacer que cambien los signos externos de la organización?: títulos, desarrollo de carrera, competencias, organigrama.
- ¿Cómo agregar una dosis de placer al trabajo en equipo?

Esta ruptura entre los antiguos y los nuevos métodos y equipos… las antiguas y nuevas formas de vestirse… es visible en todas partes del mundo, no solamente en Silicon Valley. Tanto en Francia como en Canadá, en España y América del Sur, basta con pasar un poco de tiempo en las conferencias profesionales. Los “traje-y-corbata” están cómodamente instalados en las conferencias donde se habla de Business Intelligence y de Big Data. Los de camisa están ausentes a estos eventos. Sin embargo, los meetups, hackathons, son frecuentados por generaciones más jóvenes, adeptas a la Data Science. Mientras que los primeros reflejan la “transformación” digital, los segundos la ponen en práctica. ¡Atención a la desorganización!




Comentarios

1.Publicado por Jorge Alvarez Cortez el 05/12/2016 16:49
Muy buen artículo, es por donde se caminará en los próximos años. El reto es pasar de la teoría a la práctica y lograr el apoyo para el cambio no solo en los procesos sino también en la cultura organizacional.

2.Publicado por Diego el 06/12/2016 10:02
No puedo creer que Teradata proponga metodologías ágiles y uso de Devops cuando han sido los grandes promotores de las Arquitecturas y de "modelos de industria" super complejos... Quiero ver como van a cambiar.

Nuevo comentario:
Facebook Twitter

Usted puede comentar o proporcionar más información a todos los artículos de este sitio. Los comentarios son libres y abiertos a todos. Sin embargo, nos reservamos el derecho a eliminar, sin previo aviso ni explicación, todo comentario que no cumpla con nuestras normas internas de funcionamiento, es decir, cualquier comentario difamatorio o sin relación con el tema del artículo. Así mismo, los comentarios anónimos son eliminados sistemáticamente si son demasiado negativos o muy positivos. Exprese sus opiniones, compártalas con los demás y asúmalas. Gracias de antemano. Igualmente, agradecemos tener en cuenta que los comentarios no sean enviados automáticamente a los redactores de cada artículo. Si usted desea realizar una pregunta al autor de un artículo, contáctelo directamente, no utilice los comentarios.


Twitter
Rss
LinkedIn
Google+
Facebook
Pinterest