Introducción a las Analíticas Ágiles

Un enfoque basado en el valor para Business Intelligence y Data Warehousing

This article is the first chapter from the book Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing.

Al igual que el desarrollo de software Ágil, las Analíticas Ágiles se establecen sobre un conjunto de valores y principios fundamentales. No es una metodología rígida o prescriptiva; más bien es una forma de elaborar data warehouse, data mart, aplicaciones de inteligencia de negocios y aplicaciones de análisis que se centran en la entrega temprana y continua de valor de negocio a lo largo del ciclo de vida del desarrollo. En la práctica, las Analíticas Ágiles consisten en un conjunto de prácticas y técnicas altamente disciplinadas, algunas de las cuales se pueden adaptar a las demandas únicas de un proyecto de Data Warehouse/Inteligencia de Negocio (DW/BI por sus siglas en inglés) que se encuentran en una organización.

Las Analíticas Ágiles incluyen prácticas para la planificación, gestión y monitoreo de proyectos; para una colaboración efectiva con los clientes del negocio y los stakeholders administrativos; y para garantizar la excelencia técnica por parte del equipo de desarrollo. Este artículo contempla el primer capítulo de mi libro Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing (Analíticas Ágiles: un enfoque basado en el valor para Business Intelligence y Data Warehousing), en el cual se describen los principios de las Analíticas Ágiles y se establecen los principios fundamentales detrás de cada una de las prácticas y técnicas que se presentan en los capítulos sucesivos del libro. 

Ágil es una palabra reservada cuando se usa para describir un estilo de desarrollo. Significa algo muy específico. Desafortunadamente, "ágil" ocasionalmente se usa mal como un apodo para procesos que son ad hoc, descuidados y carentes de disciplina. Ágil se basa en la disciplina y el rigor; sin embargo, no es un proceso pesado o muy ceremonioso a pesar de los intentos de algunos metodólogos de codificarlo con esos adornos. Por el contrario, Agile cae en algún lugar en el medio entre la estructura suficiente y la flexibilidad suficiente. Se ha dicho que Agile es simple pero no fácil, describiendo el hecho de que se basa en un conjunto simple de valores y principios sensibles, pero requiere un alto grado de disciplina y rigor para ejecutarse adecuadamente. Es importante comprender con precisión el conjunto mínimo de características que diferencian un verdadero proceso ágil de aquellos que son demasiado desestructurados o demasiado rígidos. El objetivo de este artículo es dejarlo con una comprensión clara de esas características, así como de los valores y principios subyacentes de Agile Analytics. Estos se derivan directamente de los fundamentos probados y establecidos por la comunidad de software Agile y se adaptan a los matices del almacenamiento de datos y el desarrollo de inteligencia empresarial.

Desarrollo de Sistemas al Estilo Alpino

Me considero un apasionado por el alpinismo, a pesar de no haberlo practicado. Siempre estuve fascinado por las pruebas y dificultades de escalar montañas altas como el Everest, Annapurna y otras que se elevan a más de 8,000 metros sobre el nivel del mar. Estas expediciones son complicadas, involucran planificación y logística desafiantes, un alto grado de riesgo e incertidumbre, una alta probabilidad de muerte (por cada dos escaladores que llegan a la cima de Annapurna, ¡otro muere en el intento!), decisiones difíciles frente a incontrolables variables, y recompensas increíbles cuando se logra el éxito. Si bien, construir sistemas de inteligencia de negocio complejos no es una actividad tan arriesgada y aventurera, es muy parecida al alpinismo. Nos enfrentamos a muchos riesgos e incertidumbres, planificación compleja, decisiones difíciles en el calor de la batalla y la probabilidad de morir. Está bien, quizás no la última parte. Desafortunadamente, la tasa de éxito para la construcción de sistemas DW/BI no es mucho mejor que la tasa de éxito para las expediciones de alpinismo.

Los equipos de ascenso comenzaron a conquistar con éxito las altas montañas en la década de los 50. En esos primeros años, el estilo de montañismo preferido era conocido como "escalada de expedición", que tenía muchas similitudes con las excursiones militares. Las expediciones fueron dirigidas en forma autocrática con comando y control, a menudo por alguien con más experiencia en liderazgo militar que en escalar. Los equipos de ascenso fueron apoyados por un gran número de cargadores, requeridos para llevar cantidades masivas de equipo y suministros al campamento base y tan alto como la expedición llegase. Montar una expedición lleva más de un año de planificación y puede llevar dos meses o más para ejecutarse durante la temporada de escalada. La escalada de expedición es un asunto de tipo yo-yo en el que las cuerdas se fijan cada vez más alto en la montaña, se establecen campamentos semi-permanentes en varios puntos a lo largo de la ruta y los cargadores transportan una gran cantidad de suministros a los campamentos situados a mayor altura. Finalmente, con todo este apoyo, un pequeño equipo de escaladores sale del último campamento hacia la cumbre en un solo día. Equipos brillantes han escalado con éxito montañas durante años de este modo, pero las expediciones son prohibitivamente caras, requieren mucho tiempo de ejecución y están plagadas de procedimientos pesados y burocracia.



El desarrollo tradicional de sistemas de inteligencia de negocios se parece mucho a la escalada de expedición. Puede dar como resultado sistemas funcionales de alta calidad que brindan las capacidades deseadas. Sin embargo, estos proyectos suelen ser costosos, exhiben mucha planificación, un diseño extenso antes del desarrollo y largos ciclos de desarrollo. Al igual que las expediciones, toda la energía se concentra en el último tramo hacia la cima. Si el intento de llegar a la cumbre falla, lleva demasiado tiempo volver al campo base y reagruparse para otro intento. He visto múltiples proyectos tradicionales de DW/BI con presupuestos de $ 20 millones o más, y plazos de 18 a 24 meses, fracasar. Cuando estos proyectos fallan, la respuesta típica de la administración es cancelar el proyecto por completo en lugar de ajustar, adaptar y reagruparse para otro "intento de llegar a la cima".

En la década de 1970, surgió un nuevo método de escalar llamado "estilo alpino", que hace posible que equipos más pequeños alcancen la cima de altas montañas más rápido, con costos más bajos y con menos protocolo. La “escalada de estilo alpino” aún requiere una planificación sustancial, un equipo de soporte y suficientes suministros para alcanzar la cima de manera segura. Sin embargo, en lugar de pasar meses preparando la ruta para el viaje final a la cumbre, los escaladores de estilo alpino pasan aproximadamente una semana trasladando lo esencial a los campamentos más altos. En este estilo, si las condiciones son adecuadas, las cumbres se pueden alcanzar en apenas diez días. Equipos de dos a tres escaladores comparten una sola carpa y un saco de dormir, se necesitan menos cuerdas y los escaladores pueden viajar mucho más livianos y más rápido. Cuando las condiciones no son las adecuadas, es factible que los escaladores de estilo alpino regresen al campamento base y esperen a que mejoren las condiciones para hacer otro intento de subir a la cumbre.

El desarrollo ágil de DW/BI es muy parecido a la escalada de estilo alpino. Es esencial que tengamos una cantidad suficiente de planificación, el apoyo necesario para tener éxito y una cantidad apropiada de protocolo. Nuestra "cumbre" es la finalización de un sistema de inteligencia de negocios de alta calidad que funcione y que sea de gran valor para sus usuarios. Al igual que en el montañismo, alcanzar nuestra cima requiere de condiciones adecuadas. Necesitamos la cantidad justa de planificación, pero debemos poder adaptar nuestro plan a factores cambiantes y nueva información. Debemos prepararnos para un alto grado de riesgo e incertidumbre, pero debemos ser capaces de administrar y responder con destreza a medida que se desarrollan los riesgos. Necesitamos el apoyo y la participación de una comunidad más grande, pero buscamos la auto-organización del equipo en lugar del liderazgo de comando y control.

La Analíticas Ágiles son un "estilo" de desarrollo no son una metodología o un framework. La línea entre la escalada de estilo expedición y estilo alpino no está definida con precisión, y las escaladas de estilo alpino pueden incluir algunas prácticas del estilo expedición. Cada estilo se describe mejor en términos de sus valores y principios. Cada expedición de estilo alpino emplea un conjunto distinto de prácticas de escalada que apoyan un conjunto común de valores y principios. De manera similar, cada equipo de proyectos DW/BI ágiles debe adaptar sus prácticas técnicas, de gestión de proyectos y de colaboración con el cliente para respaldar mejor los valores y principios de ágiles.

El alpinista de élite Ed Viesturs tiene una fórmula, o valor central, que es su regla fundamental en las grandes montañas: "Llegar a la cima es opcional. Descender es obligatorio". (Viesturs y Roberts 2006) Este valor central es simple y elegante, y proporciona una base clara para toda la toma de decisiones que Ed ha hecho cuando está en la montaña. En el estrés de la escalada, o en medio de un proyecto intensamente desafiante, necesitamos una base para la toma de decisiones, nuestra "Estrella del Norte". En el 2000, un grupo de los desarrolladores de software más influyentes se reunieron en Salt Lake City y formaron la Agile Alliance. A través del proceso de compartir y comparar cada uno de sus "estilos" de desarrollo de software, el Manifiesto Ágil surgió como una base simple y elegante para la orientación de proyectos y la toma de decisiones. El Manifiesto Ágil expone:

Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Con el debido respeto a la Agile Alliance, de la que soy miembro, he adaptado un poco el Manifiesto Ágil para hacerlo más apropiado para las Analíticas Ágiles:

Manifiesto por el Desarrollo Ágil de Analíticas
Estamos descubriendo formas mejores de desarrollar data warehousing y sistemas de inteligencia de negocios tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Sistemas funcionales de DW/BI sobre documentación extensiva
Colaboración con usuarios finales y stakeholders sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Mi intención no es modificar demasiado el manifiesto original, pero es importante reconocer que los sistemas DW/BI son fundamentalmente diferentes de las aplicaciones de software. Además de tratar con grandes volúmenes de datos, estas aplicaciones incluyen la integración con otros sistemas, personalización y programación. No obstante, los valores ágiles son muy relevantes para el desarrollo de sistemas DW/BI. Estos valores enfatizan el hecho de que nuestro objetivo principal es la creación de sistemas DW/BI de alta calidad, alto valor y funcionamiento. Cada actividad relacionada con cualquier proyecto (a) contribuye directa y materialmente a este objetivo principal o (b) no lo hace. Las Analíticas Ágiles intentan maximizar las actividades de tipo A al tiempo que reconocen que hay algunas actividades de tipo B que aún son importantes, como documentar el modelo de datos.

¿Qué son las Analíticas Ágiles?

En este artículo, se presentan un conjunto de principios y prácticas ágiles de DW/BI. Estas incluyen prácticas técnicas, de gestión de proyectos y de colaboración con usuarios. Se muestra cómo pueden aplicarse en proyectos y cómo pueden adaptarse a los matices del entorno. Sin embargo, el título de esta sección es: "¿Qué son las Analíticas Ágiles?" así que iremos un poco más lejos de la analogía del montañismo.

Estas son las Analíticas Ágiles

Así que aquí hay un resumen de las características clave de Analíticas Ágiles. Esto es simplemente un vistazo de alto nivel a los rasgos clave del proyecto que son la marca del agilismo, no una lista exhaustiva de prácticas. A lo largo del resto de este libro, se presentan un conjunto de prácticas específicas que permitirán lograr agilismo en proyectos de DW/BI. Además, las Analíticas Ágiles son un estilo de desarrollo, no una metodología prescriptiva que dice con precisión qué debe hacer y cómo debe hacerlo. La dinámica de cada proyecto dentro de su organización requiere prácticas que se pueden adaptar adecuadamente al entorno. El objetivo principal es un sistema DW/BI funcional de alta calidad y valor. Estas características simplemente sirven a ese objetivo:

Iterativo, incremental, evolutivo. En primer lugar, Agile es un estilo de desarrollo iterativo, incremental y evolutivo. Trabajamos en iteraciones cortas que generalmente duran de una a tres semanas, y nunca más de cuatro. Construimos el sistema en pequeños incrementos o "trozos" de funcionalidad valorada por el usuario y evolucionamos el sistema de trabajo adaptándonos a los comentarios frecuentes de los usuarios. El desarrollo ágil es como conducir en una ciudad desconocida; se evita ir muy lejos sin una cierta validación de que está en el curso correcto. Las iteraciones breves con revisiones frecuentes de usuarios ayudan a garantizar que nunca nos alejamos del curso de nuestro desarrollo.

Desarrollo impulsado por valores. El objetivo de cada iteración de desarrollo es producir características valoradas por el usuario. Si bien los desarrolladores aprecian la dificultad de las arquitecturas de datos complejas, los modelos de datos elegantes, los scripts ETL eficientes (Extracción, Transformación y Carga por sus siglas en inglés Extraction, Transformation and Load), etc, los usuarios generalmente no se preocupan por estas cosas. Lo que importa a los usuarios de los sistemas DW/BI es la presentación y el acceso a la información que les ayuda a resolver un problema de negocios o a tomar mejores decisiones. Cada iteración debe producir al menos una característica nueva valorada por el usuario, a pesar de que las características del usuario son solo la punta del iceberg arquitectónico que es un sistema DW/BI.

Calidad de producción. Cada característica desarrollada recientemente debe ser probada y depurada completamente durante la iteración de desarrollo. El desarrollo ágil no se trata de construir prototipos huecos; se trata de evolucionar progresivamente hacia la solución correcta con los mejores fundamentos arquitectónicos. Hacemos esto integrando pruebas en forma temprana y continua en el proceso de desarrollo de DW/BI. Los desarrolladores deben planificar e incluir pruebas rigurosas en su proceso de desarrollo. Una característica del usuario se considera "Hecha" cuando tiene la calidad de producción, se integra con éxito en el sistema en evolución y los desarrolladores están orgullosos de su trabajo. Esa misma característica está "¡Hecha! ¡Hecha!" cuando el usuario acepta que entrega el valor correcto.

Procesos suficientes. Los estilos tradicionales de desarrollo de DW/BI están llenos de un alto grado de ceremonia. Muchos proyectos involucran reuniones elaboradas entre las etapas del desarrollo, para tratar la transición del análisis de requerimientos y diseño. Estas reuniones casi siempre van acompañadas de un documento formal que debe ser "firmado" como parte del proceso. A pesar de que existen estas ceremonias, muchos proyectos DW/BI luchan o fracasan. Agile DW/BI hace hincapié en una cantidad suficiente de ceremonias para satisfacer las necesidades prácticas del proyecto (y las generaciones futuras), pero nada más. Si un diccionario de datos se considera importante para que lo utilicen los futuros desarrolladores, tal vez sea suficiente una imagen digital de una tabla de pizarra o una hoja de cálculo simple. Dado que nuestro principal objetivo es la producción de sistemas de trabajo de alta calidad y alto valor, debemos poder minimizar la cantidad de ceremonia requerida para otras actividades.

Automatización, automatización, automatización. La única manera de ser verdaderamente ágil es automatizar tantos procesos rutinarios como sea posible. La automatización de pruebas es quizás la más crítica. Si debe probar sus funciones y su sistema manualmente, ¿con qué frecuencia es probable que vuelva a ejecutar sus pruebas? La automatización de pruebas le permite revalidar con frecuencia que todo sigue funcionando como se esperaba. La automatización de compilación del proyecto le permite construir con frecuencia una versión del sistema DW/BI completo en un entorno de demostración o pre-producción. Esto ayuda a establecer confianza continua de que nunca faltan más de unas pocas horas o días para poner en producción una nueva versión del sistema. Los equipos de Analíticas Ágiles buscan automatizar cualquier proceso que se realice más de una vez. Cuanto más se pueda automatizar, más podrá centrarse en desarrollar funcionalidades para el usuario.

Colaboración. Muy a menudo, en los proyectos tradicionales, el equipo de desarrollo tiene la carga de garantizar que se cumplan los plazos, se entregue el alcance completo, se administren los presupuestos y se garantice la calidad. La inteligencia de negocios ágil reconoce que existe una comunidad de proyectos más amplia que comparte la responsabilidad del éxito del proyecto. La comunidad del proyecto incluye a los usuarios, dueños del negocio, stakeholders, patrocinadores ejecutivos, expertos técnicos, gerentes de proyectos y otros. La colaboración frecuente entre las comunidades técnicas y de usuarios es fundamental para el éxito. La colaboración diaria dentro de la comunidad técnica también es crítica. De hecho, establecer un espacio de trabajo de equipo colaborativo es un ingrediente esencial de los proyectos ágiles exitosos.

Equipos auto-organizados, auto-gestionados. Contrate a las mejores personas, bríndeles las herramientas y el apoyo que necesitan, luego quédese a un lado y permita que tengan éxito. Hay un cambio clave en el estilo de gestión de proyectos ágiles en comparación con la gestión de proyectos tradicional. El rol del gerente de proyecto ágil es permitir a los miembros del equipo trabajar y facilitar un alto grado de colaboración con los usuarios y otros miembros de la comunidad del proyecto. El equipo del proyecto ágil decide cuánto trabajo puede completar durante una iteración, y luego se responsabiliza de cumplir con esos compromisos. El estilo ágil no sustituye a las personas adecuadas en el equipo.

Principios Guía

Los valores centrales contenidos en el Manifiesto Ágil inspiran a un conjunto de principios para el diseño y desarrollo de sistemas DW/BI. Estos principios a menudo ayudan a tomar decisiones difíciles que involucran priorización de tareas y recursos. De manera similar, la Agile Alliance ha establecido un conjunto de principios para el desarrollo de software. Los siguientes principios de Analíticas Ágiles se basan en los principios de la Agile Alliance:

• Nuestra mayor prioridad es satisfacer al usuario de sistemas DW/BI mediante la entrega temprana y continua de funcionalidades con valor.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al usuario de sistemas DW/BI.
• Entregamos funcionalidades nuevas a los usuarios DW/BI frecuentemente, cada semana. 
• Los usuarios, los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
• Los proyectos se desarrollan en torno a expertos en inteligencia de negocio motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 
• El método más eficiente y efectivo de comunicar información al equipo de desarrollo y a sus miembros es la conversación cara a cara.
• Un sistema de inteligencia de negocios funcionando es la medida principal de progreso.
• Reconocemos el balance entre el alcance, el itinerario y los costos del proyecto. El equipo de data warehousing debe ser capaz de mantener un ritmo constante de forma indefinida.
• La atención continua a las mejores prácticas de datawarehousing mejora la Agilidad.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
• A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Tomemos un minuto para reflexionar sobre estos principios. ¿Cuántos de ellos están presentes en los proyectos de su organización? ¿Tienen sentido para su organización? Dales otra mirada. ¿Son principios realistas para su organización? He descubierto que estos no solo son principios de sentido común, sino que también son efectivos y alcanzables en proyectos reales. Además, la adhesión a estos principios en lugar de confiar en un modelo de procesos prescriptivos y ceremoniosos es liberador.

Mitos y Conceptos Erróneos

Hay algunos mitos y conceptos erróneos que parecen prevalecer entre los profesionales y expertos en DW/BI con los que he hablado acerca de este estilo de desarrollo. Hace poco tuve una conversación sobre este tema con un veterano experimentado en el desarrollo de software y data warehousing que está certificado a nivel de dominio en DW/BI y gestión de datos y que ha administrado grandes equipos de desarrollo de software. Su mala interpretación del desarrollo ágil hizo evidente que los mitos y los conceptos erróneos abundan incluso entre los practicantes de DW/BI más avanzados. Las Analíticas Ágiles no son:

Un reemplazo al por mayor de las prácticas tradicionales. No estoy sugiriendo que todo lo que hemos aprendido y practicado en la breve historia del desarrollo de sistemas DW/BI esté mal, y que Agile sea el nuevo salvador que nos rescatará de nuestro infierno. Hay muchas historias de éxito de proyectos de DW/BI, por lo que DW/BI sigue estando entre las cinco iniciativas estratégicas principales para la mayoría de las grandes empresas en la actualidad. Es importante que mantengamos las prácticas y los métodos que funcionan bien, mejoremos aquellos que pueden ser mejorados y reemplacemos aquellos que son problemáticos. Las Analíticas Ágiles buscan modificar nuestro enfoque general para el desarrollo de sistemas DW/BI sin descartar las mejores prácticas que hemos aprendido en nuestro viaje hasta ahora.

Sinónimo de Scrum o eXtreme Programming (XP). Scrum es quizás el sabor Agile que más publicidad ha recibido (junto con XP) en los últimos años. Sin embargo, es incorrecto decir que "Agile antes se conocía como eXtreme Programming", como mencionó un escéptico. De hecho, hay muchos sabores diferentes de desarrollo ágil que agregan principios y prácticas valiosas al colectivo más amplio conocido como desarrollo ágil. Estos incluyen Scrum, Agile Modeling, Agile Data, Crystal, Adaptive, DSDM, Lean Development, Feature Driven Development, Agile Project Management (APM) y otros. Cada uno está guiado por los valores centrales expresados en el Agile Manifesto. Las Analíticas Ágiles son una adaptación de los principios y las prácticas de una variedad de estos métodos a las complejidades de los esfuerzos de integración de sistemas basados en análisis de datos, como el data warehousing y el desarrollo de data mart.

Simplemente iterando. Las iteraciones de desarrollo cortas y frecuentes son una piedra angular esencial del desarrollo Agile. Desafortunadamente, esta práctica clave se suele malinterpretar como la definición de ágil. No hace mucho, me pidieron que asesorara a un equipo de desarrollo que se había "vuelto ágil" pero que no estaba experimentando los beneficios esperados. Tras una inspección más cercana, descubrí que estaban planificando "iteraciones" de cuatro semanas, pero no esperaban entregar ninguna funcionalidad hasta aproximadamente el sexto mes del proyecto. Efectivamente, habían dividido el modelo de cascada tradicional en bloques de tiempo que llamaban iteraciones. Ellos perdieron completamente el punto. El objetivo del desarrollo iterativo es demostrar características de trabajo y obtener comentarios frecuentes de la comunidad de usuarios. Esto significa que cada iteración debe dar como resultado un software funcional.

Para la integración de sistemas; Es solo para programar. Gran parte de nuestro esfuerzo en el desarrollo de DW/BI se centra en la integración de múltiples herramientas comerciales, minimizando así el volumen de programación requerida. Los proveedores de herramientas de DW/BI nos hacen creer que el desarrollo DW/BI es simplemente una cuestión de conectar las herramientas a los sistemas de origen y presionar el botón "Ir". Probablemente ya descubrieron que construir un sistema DW/BI efectivo no es tan simple. Un equipo de desarrollo de DW/BI incluye una mezcla heterogénea de habilidades, incluido el desarrollo de extracción, transformación y carga (ETL); desarrollo de bases de datos; modelado de datos (tanto relacional como multidimensional); desarrollo de aplicaciones; y otros. De hecho, en comparación con las habilidades más homogéneas requeridas para el desarrollo de aplicaciones, el desarrollo de DW/BI es bastante complejo en este sentido. Esta complejidad requiere un enfoque que admita un alto grado de colaboración con el cliente, entrega frecuente de software en funcionamiento y retroalimentación frecuente: ¡ah, un enfoque ágil!

Una excusa para el comportamiento ad hoc. Algunos han confundido los principios del desarrollo ágil con el abandono del rigor, la calidad o la estructura, en otras palabras, "piratear". Esta percepción errónea no podría estar más lejos de la verdad. El agilismo se centra en la entrega frecuente de software con calidad de producción y funcional para la comunidad de usuarios con el objetivo de adaptarse continuamente a las críticas de los usuarios. Esto significa que las pruebas automatizadas y la garantía de calidad son componentes críticos de todas las actividades de desarrollo iterativo. No construimos prototipos; construimos funcionalidades y luego maduramos esas características en respuesta a las aportaciones del usuario. Otros confunden el Manifiesto Ágil con un desdén de la documentación, lo cual también es incorrecto. El DW/BI Ágil busca asegurar que se produzca una cantidad suficiente de documentación. La palabra clave aquí es suficiente. Suficiencia que implica que hay un propósito legítimo para un documento, y que cuando se cumple ese propósito, no hay necesidad de documentación adicional.

En mi trabajo con equipos que están aprendiendo y adoptando el estilo de desarrollo DW/BI Ágil, a menudo encuentro que están buscando una metodología prescriptiva que deje en claro qué prácticas aplicar y cuándo. Esta es una inclinación natural para los nuevos practicantes de metodologías ágiles, y proporcionaré algunas recomendaciones que pueden parecer de naturaleza prescriptiva. De hecho, pueden beneficiarse inicialmente al crear su propia "receta" para la aplicación de principios y prácticas de DW/BI Ágil. Sin embargo, debo volver a enfatizar que las Analíticas Ágiles son un estilo, no una metodología ni un marco de trabajo. Figurativamente, se puede absorber el agilismo en el ADN con suficiente enfoque, práctica y disciplina. Usted sabrá que ha llegado a ese punto cuando comience a aplicar los principios ágiles a todo lo que hace, como comprar un auto nuevo, remodelar un baño o escribir un libro.

Arquitecturas de Data Warehousing y Conjuntos de Habilidades

Para asegurarnos de que estamos trabajando desde un entendimiento común, aquí hay un breve resumen de las arquitecturas de data warehousing y los conjuntos de habilidades necesarios para su aplicación. Este no es un sustituto de ningún libro técnico más completo sobre data warehousing, pero debe ser suficiente como referencia para el resto del libro.

Arquitecturas Conceptuales de Data Warehousing

La Figura 1.1 muestra una arquitectura de data warehousing clásica y es adecuada para transmitir una arquitectura de estilo Kimball (Kimball y Ross 2002) o de estilo Inmon (Inmon 2005). Esta es una arquitectura conceptual de alto nivel que contiene múltiples capas, cada una de las cuales incluye una integración compleja de tecnologías comerciales, modelado y manipulación de datos y código personalizado.


Figura 1.1 Arquitectura clásica de Data Warehousing

La arquitectura de data warehousing incluye uno o más sistemas operacionales desde los cuales se extraen datos, se transforman y se cargan en los repositorios de data warehousing. Estos sistemas están optimizados para el procesamiento transaccional diario requerido para ejecutar las operaciones del negocio. La mayoría de los sistemas DW/BI obtienen datos de múltiples sistemas operacionales, algunos de los cuales son sistemas heredados que pueden tener varias décadas de antigüedad y residir en tecnologías antiguas.

Los datos de estas fuentes se extraen en un nivel de integración en la arquitectura que actúa como un "bolígrafo de retención" donde los datos se pueden fusionar, manipular, transformar, limpiar y validar sin imponer una carga indebida en los sistemas operacionales. Este nivel puede incluir un almacén de datos operacionales o un repositorio de integración de información empresarial (EII por sus siglas en inglés Enterprise Information Integration) que actúa como un sistema de registro para todos los datos operativos relevantes. La base de datos de integración generalmente se basa en un modelo de datos relacionales y puede tener múltiples sub-componentes, incluyendo pre-staging, staging y un repositorio de integración, cada uno con un propósito diferente relacionado con la consolidación y el preprocesamiento de datos de sistemas de origen diverso. Las tecnologías comunes para bases de datos provisionales (staging databases) son Oracle, IBM DB2, Microsoft SQL Server y NCR Teradata. La comunidad DW/BI está comenzando a ver un uso creciente de bases de datos de código abierto como MySQL para este componente arquitectónico.

Los datos se extraen de la base de datos provisional, se transforman y se cargan en un nivel de presentación en la arquitectura que contiene las estructuras adecuadas para consultas analíticas y multidimensionales optimizadas. Este sistema está diseñado para admitir el data slicing y dicing que definen la potencia de un sistema de data warehousing. Existe una variedad de alternativas para la implementación de la base de datos de presentación, incluidos los esquemas relacionales normalizados y los esquemas desnormalizados como estrella, copo de nieve e incluso "copo de estrella". Además, el nivel de presentación puede incluir un único almacén de datos empresariales o una colección de datos específicos al mercado. Algunas arquitecturas incluyen un híbrido de ambos. Los repositorios de presentación normalmente se implementan en las mismas tecnologías que la base de datos de integración.

Finalmente, los datos se presentan a los usuarios empresariales en el nivel de análisis de la arquitectura. Esta capa conceptual en el sistema representa la variedad de aplicaciones y herramientas que brindan a los usuarios acceso a los datos, incluidos redactores de informes, consultas ad hoc, procesamiento analítico en línea (OLAP por sus siglas en inglés OnLine Analytical Processing), visualización de datos, extracción de datos y análisis estadístico. Los proveedores de herramientas de BI como Pentaho, Cognos, MicroStrategy, Business Objects, Microsoft, Oracle, IBM y otros, producen productos comerciales que permiten que los datos de la base de datos de presentación se agreguen y se presenten en las aplicaciones de usuario.

Esta es una arquitectura generalizada, y las implementaciones reales varían en los detalles. Una variación importante de la arquitectura de Kimball es la arquitectura Inmon (Inmon 2005), que inserta una capa de data marts específicos del tema que contienen subconjuntos de datos del sistema principal de data warehousing. Cada data mart admite sólo las aplicaciones específicas para el usuario final que son relevantes para el área de negocios para la que se diseñó. Independientemente de su preferencia respecto a las arquitecturas de estilo Kimmon versus Inmon, y de las variaciones que se encuentran en los detalles de implementación, la Figura 1.1 servirá como arquitectura de referencia para las discusiones en este libro. Los principios y prácticas de DW/BI Ágil que se presentan no son específicos de ninguna arquitectura en particular.

Habilidades Técnicas Diversas y Dispares

Los siguientes aspectos del desarrollo son inherentes a la implementación de esta arquitectura, y cada uno requiere un conjunto único de habilidades de desarrollo:

Modelado de datos. El diseño y la implementación de modelos de datos son necesarios para los repositorios de integración y presentación. Los modelos de datos relacionales son claramente diferentes de los modelos de datos dimensionales, y cada uno tiene propiedades únicas. Además, los modeladores de datos relacionales pueden no tener experiencia en modelado dimensional y viceversa.

Desarrollo de ETL. ETL se refiere a la extracción de datos de los sistemas de origen hacia los repositorios de staging, las transformaciones necesarias para difundir los datos de origen para su análisis y la carga de datos transformados en el repositorio de presentación. ETL incluye los criterios de selección para extraer datos de los sistemas de origen, realizar las transformaciones o derivaciones de datos necesarias, auditorías de calidad de datos y limpieza.

Limpieza de datos. Los datos de origen normalmente no son perfectos. Además, la fusión de datos de múltiples fuentes puede inyectar nuevos problemas de calidad de datos. La higiene de los datos es un aspecto importante de los sistemas de data warehousing que requiere habilidades y técnicas específicas.

Diseño OLAP. Normalmente, los almacenes de datos admiten una variedad de procesamiento analítico en línea (HOLAP, MOLAP o ROLAP). Cada técnica OLAP es diferente pero requiere habilidades de diseño especiales para equilibrar los requisitos de reportería con restricciones de rendimiento.

Desarrollo de aplicaciones. Los usuarios comúnmente requieren una interfaz para el sistema de data warehousing que proporcione un front-end fácil de usar combinado con capacidades analíticas integrales, y que se adapten a la forma en que trabajan los usuarios. Esto a menudo requiere un cierto grado de programación personalizada o personalización de la aplicación comercial.

Automatización de la producción. Los sistemas de data warehousing generalmente están diseñados para actualizaciones automáticas periódicas cuando se introducen datos nuevos o modificados para que los usuarios puedan ver los datos más recientes disponibles. Estos procesos de actualización automatizados deben tener estrategias integradas de recuperación de errores y deben garantizar la consistencia y corrección de los datos.

Sistemas y administración de bases de datos. Los desarrolladores de sistemas de data warehousing deben tener muchas de las mismas habilidades que tienen los roles tradicionales de administrador de red y de base de datos. Deben comprender las implicaciones de mover de manera eficiente grandes volúmenes de datos a través de la red y los problemas de almacenamiento efectivo de datos cambiantes.

¿Por qué necesitamos de Analíticas Ágiles?

En mis años como consultor y practicante de DW/BI, he aprendido tres verdades consistentes: Construir un sistema exitoso DW/BI es difícil; el desarrollo de estos proyectos a menudo falla; y es mejor fallar rápido y adaptarse que fallar después de que el presupuesto haya sido gastado.

Primera Verdad: Construir sistemas DW/BI es difícil

Si eres parte de un proyecto de Data Warehousing, estás consciente de los numerosos desafíos y puntos de falla. Ralph Kimball, Bill Inmon, y otros pioneros de proyectos DW/BI han realizado un excelente trabajo en desarrollar patrones de arquitectura reutilizables para Data Warehouse e implementaciones DW/BI. Los vendedores de Software han realizado un gran trabajo en crear herramientas y tecnologías para apoyar estos conceptos. Sin embargo, los proyectos DW/BI son difíciles por las siguientes razones:

1. Falta de experiencia. La mayoría de las organizaciones no construyen múltiples sistemas DW/BI, y durante el proceso no tienen la oportunidad de madurar a través de la experiencia. 
2. Objetivos ambiciosos. Las organizaciones a menudo construyen data warehouse empresariales, o al menos un data mart transversal lo cual hace el proceso más complejo.
3. Conocimiento del dominio versus experiencia en el tema. Los practicantes de DW/BI a menudo tienen una amplia experiencia en Inteligencia de Negocios pero no en el dominio del negocio de la organización, causando brechas en el entendimiento. Los usuarios del negocio típicamente no saben qué pueden o deberían esperar de un sistema DW/BI.
4. Expectativas irrealistas. Los usuarios de negocio a menudo piensan que los sistemas de data warehouse son una aplicación plug-and-play que obtles proporcionará información milagrosa rápidamente.
5. Fenómeno del usuario educado. A medida que los usuarios obtienen una mejor comprensión de data warehousing, sus necesidades y deseos cambian.
6. Disparando al mensajero. Los sistemas DW/BI son como encender una luz brillante en el ático: es posible que no te guste lo que encuentres. Cuando el sistema expone los problemas de calidad de los datos, los usuarios comerciales tienden a desconfiar del sistema DW/BI.
7. Centrarse en la tecnología. Las organizaciones a menudo ven un sistema DW/BI como una aplicación de TI en lugar de un esfuerzo conjunto entre partes interesadas del negocio y desarrolladores de TI.
8. Habilidades especializadas. El data warehousing requiere un conjunto de habilidades completamente diferente al de los administradores de bases de datos (DBA por sus siglas en inglés) y los desarrolladores. La mayoría de las organizaciones no tienen personal con experiencia adecuada en estas áreas.
9. Múltiples habilidades. El data warehousing requiere una multitud de habilidades únicas y distintas, como modelado multidimensional, limpieza de datos, desarrollo de ETL, diseño OLAP, desarrollo de aplicaciones, etc.

Estas características de desarrollo únicas de DW/BI componen el proceso ya complejo de crear software o crear aplicaciones de bases de datos.

Segunda verdad: El desarrollo de proyectos DW/BI fallan a menudo

Desafortunadamente, no soy el único que ha experimentado fallas en los proyectos de DW/BI. Una búsqueda rápida en Google sobre "encuestas de fallas de data warehouse" da como resultado una pequeña biblioteca de estudios de casos, postmortems y artículos de evaluación. Las tasas estimadas de fracaso de alrededor del 50 por ciento son comunes y rara vez se disputan.

Cuando hablo con grupos de profesionales de inteligencia empresarial, a menudo comienzo mis conversaciones con una encuesta informal. Primero, pido a todos los que han participado en la finalización de uno o más proyectos DW/BI que se presenten. Varía dependiendo de la audiencia, pero generalmente más de la mitad del grupo se pone de pie. Luego, les pido a los participantes que se sienten si han participado de proyectos que se entregaron tarde, proyectos que excedieron su presupuesto de forma significativa o proyectos que no cumplieron con las expectativas de los usuarios. Por lo general, la tercera pregunta no deja a nadie en pie, y ni siquiera he llegado a preguntas sobre la calidad aceptable o cualquier otro problema. Es evidente que la mayoría de los profesionales experimentados en DW/BI han vivido al menos un fracaso en algún proyecto.

Si bien no hay una definición clara de lo que constituye "fracaso", Sid Adelman y Larissa Moss clasifican las siguientes situaciones como características de aceptación limitada o fracaso total del proyecto (Moss y Adelman 2000):

• El proyecto está sobre el presupuesto.
• El calendario se ha pospuesto.
• Algunas funcionalidades esperadas no fueron implementadas.
• Los usuarios están descontentos.
• El rendimiento es inaceptable.
• La disponibilidad de las aplicaciones de data warehouse es pobre.
• No hay capacidad de expandirse.
• Los datos y/o informes son pobres.
• El costo del proyecto no lo justifica.
• La gerencia no reconoce los beneficios del proyecto.

En otras palabras, simplemente completar la implementación técnica de un sistema de data warehouse no constituye un éxito. Echa un vistazo a esta lista. Casi todas las situaciones están enfocadas en el "cliente"; es decir, principalmente los usuarios finales determinan si un proyecto tiene éxito.

Hay literalmente cientos de evaluaciones similares de fallas de proyectos, y muestran una gran cantidad de superposición en su origen: requisitos incorrectos, procesos débiles, incapacidad para adaptarse a los cambios, mala gestión del alcance del proyecto, calendarios poco realistas, expectativas infladas, etc.

Tercera verdad: Es mejor fallar rápido y adaptarse

Desafortunadamente, el modelo de desarrollo tradicional hace poco para descubrir estas deficiencias al principio del proyecto. Como dice Jeff DeLuca, uno de los creadores de Feature Driven Development (FDD), "deberíamos intentar romper la arquitectura del proyecto lo antes posible para evitar el alto costo del cambio que se realizará posteriormente". En un enfoque tradicional, es posible que los desarrolladores puedan seguir adelante con la confianza ciega de que están construyendo el producto correcto, solo para descubrir al final del proyecto que estaban tristemente equivocados. Esto es cierto incluso cuando uno utiliza todas las mejores prácticas, procesos y metodologías.

Lo que se necesita es un enfoque que promueva el descubrimiento temprano de los riesgos del proyecto. Dicho enfoque debe asignar la responsabilidad del éxito a los usuarios, partes interesadas y desarrolladores, y debe recompensar la capacidad de un equipo para adaptarse a nuevas direcciones y cambios sustanciales en los requisitos.

Como observamos anteriormente, la mayoría de las fallas en proyectos están orientadas a la satisfacción del usuario. Si podemos adaptar continuamente el sistema DW/BI y alinearnos con las expectativas de los usuarios, los usuarios estarán satisfechos con el resultado. En toda mi participación en implementaciones tradicionales de DW/BI, he visto constantemente los siguientes fenómenos al final del proyecto:

Los usuarios se han educado más sobre Inteligencia de Negocios (Business Intelligence, BI). A medida que el proyecto avanza, también lo hace la comprensión de BI de los usuarios. Por lo tanto, lo que le dijeron al principio del proyecto podría haberse basado en un malentendido o en expectativas incorrectas.

Los requisitos del usuario han cambiado o se han vuelto más refinados. Eso es cierto para todos los proyectos de software e implementación. Es solo un hecho de la vida. Lo que te dijeron al principio es mucho menos relevante que lo que te dicen al final.

Los recuerdos de los usuarios sobre sus primeros requerimientos son borrosos. A menudo sucede que, contractualmente hablando, el sistema de producción cumple con un requisito, pero los usuarios no están tan contentos, con reacciones como "Lo que realmente quise decir fue ...". o "Eso puede ser lo que dije, pero no es lo que quiero".

Los usuarios tienen altas expectativas al anticipar una herramienta nueva y útil. Dejados a su propia imaginación, los usuarios a menudo elevan sus expectativas del sistema de BI mucho más allá de lo que es realista o razonable. Esto solo los deja decepcionados cuando ven el producto real.

Los desarrolladores se basan en la instantánea inicial de los requisitos de usuario. En el desarrollo estilo cascada, los requisitos iniciales se revisan y aprueban, y luego actúan como el contrato de alcance. Cumplir con los términos del contrato no es tan satisfactorio como cumplir con las expectativas de los usuarios.

Todos estos factores conducen a una brecha natural entre lo que se construye y lo que se necesita. Un enfoque que con frecuencia lanza nuevas funciones de BI a los usuarios, escucha los comentarios de los usuarios y se adapta al cambio, es la mejor manera de fallar rápido y corregir el curso del desarrollo.

¿Ser ágiles es realmente mejor?

Cada vez hay más pruebas de que los enfoques ágiles conducen a tasas más altas de éxito en los proyectos. Scott Ambler, líder en desarrollo de bases de datos ágiles y modelado ágil, ha realizado numerosas encuestas sobre el desarrollo ágil en un esfuerzo por cuantificar el impacto y la eficacia de estos métodos. A partir de 2007, Ambler realizó tres encuestas específicamente relacionadas con las tasas de éxito de proyectos de TI.6. La encuesta de 2007 exploró las tasas de éxito de diferentes tipos y métodos de proyectos de TI. Solo el 63 por ciento de los proyectos tradicionales y los proyectos de data warehousing tuvieron éxito, mientras que los proyectos ágiles experimentaron una tasa de éxito del 72 por ciento. La encuesta de 2008 se centró en cuatro criterios de éxito: calidad, retorno de la inversión, funcionalidad y cronograma. En las cuatro áreas, los métodos ágiles superaron significativamente a los enfoques tradicionales de desarrollo secuencial. La encuesta de 2010 continuó mostrando que los métodos ágiles en TI producen mejores resultados.

Debo señalar aquí que las definiciones tradicionales de éxito involucran métricas tales como el tiempo, presupuesto y las especificaciones. Si bien estas métricas pueden satisfacer los esfuerzos de la gerencia para controlar los presupuestos, no siempre se relacionan con la satisfacción del cliente. De hecho, el alcance, el cronograma y el costo son malas medidas de progreso y éxito. Martin Fowler sostiene que "el éxito del proyecto es más sobre si el software entrega un valor mayor que el costo de los recursos que se le asigna". El expositor de la conferencia XP 2002, Jim Johnson, presidente del Grupo Standish, observó que una gran parte de las funciones no se utilizan con frecuencia en los productos de software. Citó dos estudios: un estudio de DuPont, encontró que sólo el 25 por ciento de las características de un sistema eran realmente necesarias, y un estudio de Standish, que encontró que el 45 por ciento de características nunca se usaron y sólo el 20 por ciento se usó con frecuencia o siempre (Fowler 2002). Estos hallazgos son respaldados por un estudio del Departamento de Defensa, que encontró que únicamente el 2 por ciento del código en software, equivalente a $ 35.7 mil millones de dólares, se usó como se entregó, y el 75 por ciento nunca se usó o se canceló antes de la entrega (Leishman y Cook 2002).

El desarrollo ágil se dirige principalmente a la entrega de valor de alta prioridad a la comunidad de clientes. Las medidas de progreso y éxito deben centrarse más en la entrega de valor que en las métricas tradicionales de acuerdo con el calendario, el presupuesto y las especificaciones.

Jim Highsmith señala: Esta declaración refleja la noción de que la evolución gradual de un sistema al buscar y adaptarse con frecuencia a la retroalimentación de los clientes resultará en la construcción de la solución correcta, pero puede que no sea la solución que se planeó originalmente.

Las dificultades de las Analiticas Ágiles

La aplicación de métodos ágiles a DW/BI no está exenta de desafíos. Muchas de las prácticas de gestión de proyectos y técnicas que presento en este libro están adaptadas de las de nuestros colegas de desarrollo de software que han estado madurando estas prácticas durante la última década o más. Desafortunadamente, las prácticas y herramientas específicas que se usan para crear software a medida, en lenguajes como Java, C ++ o C #, no siempre se transfieren fácilmente a la integración de sistemas utilizando tecnologías propietarias como Informática, Oracle, Cognos y otras. Entre los problemas que hacen que el agilismo sea difícil de aplicar al desarrollo de DW/BI se encuentran los siguientes:

Soporte de herramientas. No hay muchas herramientas que apoyen las prácticas técnicas como test-driven databases o el desarrollo de ETL, refactorización de bases de datos, automatización de la construcción de warehouse, y otras que se presentan en este libro. Las herramientas que existen son menos maduras que las utilizadas para el desarrollo de software. Sin embargo, el estado actual de soporte de herramientas continúa mejorando, tanto a través de herramientas de código abierto como comerciales.

Volumen de datos. Se requiere de un pensamiento creativo para usar prácticas de desarrollo livianas para construir sistemas de data warehouse de gran volumen y sistemas de BI. Necesitamos utilizar muestras de datos pequeñas y representativas para construir y probar nuestro trabajo rápidamente, a la vez que comprobamos continuamente que nuestros diseños funcionarán con volúmenes de datos de producción. Esto es más bien, un impedimento para nuestra forma de abordar el problema en lugar de una barrera que es inherente al dominio del problema. Los impedimentos son aquellos desafíos que pueden eliminarse o solucionarse; las barreras son insuperables.

"Levantar objetos pesados". Si bien las Analíticas Ágiles son un enfoque basado en funcionalidades (piense en las funcionalidades de inteligencia de negocios), el aspecto más costoso en la creación de sistemas DW/BI se encuentra en el almacén de datos de back-end o en los mercados de datos. Al principio del proyecto puede parecer que se necesita mucho "trabajo pesado" en el back-end solo para exponer una característica de BI relativamente básica en el front-end. Al igual que el desafío del volumen de datos, se necesita creatividad para crear una solución de datos de back-end más pequeña/simple que permita generar valor comercial en el front-end.

Despliegue continuo. La capacidad de implementar nuevas funciones en producción con frecuencia es un objetivo del desarrollo ágil. Este objetivo se ve obstaculizado por los sistemas DW/BI que ya están en producción con grandes volúmenes de datos. A veces, la actualización de un sistema de data warehouse con una simple revisión del modelo de datos puede requerir un tiempo considerable y una ejecución cuidadosa. El despliegue continuo puede verse muy diferente en DW/BI y en el desarrollo de software.

Las sutilezas de cada proyecto pueden introducir otras dificultades similares. En general, aquellos que adoptan con éxito los valores fundamentales y los principios ágiles aprenden cómo adaptar efectivamente sus procesos para mitigar estas dificultades. Para cada uno de estos desafíos, me parece útil formular la pregunta "¿Estará mejor el proyecto si podemos superar esta dificultad a pesar de lo difícil que pueda ser superarla?" Mientras la respuesta a esa pregunta sea afirmativa, vale la pena lidiar con los desafíos para hacer que las Analíticas Ágiles funcionen. Con el tiempo y la experiencia, estas dificultades se vuelven más fáciles de superar.

Introduciendo FlixBuster Analytics

Ahora parece ser un buen momento para presentar el ejemplo de DW/BI al que haré referencia a lo largo de este libro para mostrarles cómo se aplican las diversas prácticas ágiles. El planteamiento del problema usa una cadena de alquiler de videos imaginaria para demostrar las prácticas de Analíticas Ágiles. La compañía es FlixBuster, y tienen tiendas minoristas en ciudades de Estados Unidos. FlixBuster también ofrece alquiler de videos en línea donde los clientes pueden administrar sus solicitudes de alquiler y las películas se envían directamente a su dirección de correo. Finalmente, FlixBuster ofrece descargas de películas directamente a las computadoras de los clientes.

FlixBuster tiene clientes que son miembros y clientes que no lo son. Los clientes se dividen en tres grupos de comportamiento de compra: los que compran exclusivamente en tiendas minoristas, los que compran exclusivamente en línea y los que dividen su actividad a través de los canales. Los clientes de FlixBuster pueden solicitar un alquiler en línea o en la tienda, y pueden devolver los videos en la tienda o mediante un sobre de devolución con franqueo pagado proporcionado por la empresa.

Los miembros pagan una tarifa de suscripción mensual, que determina sus privilegios de alquiler. Los miembros de primer nivel pueden alquilar hasta tres videos al mismo tiempo. También hay un nivel de membresía que permite dos videos a la vez, y un nivel que permite solo un vídeo. Los miembros pueden mantener sus alquileres por tiempo indefinido sin cargos por demora. Tan pronto como FlixBuster recibe un vídeo devuelto por un miembro, se envía el siguiente. Los no miembros también pueden alquilar videos en las tiendas siguiendo el modelo tradicional de alquiler de videos con una política de devolución de cuatro días.

Aproximadamente el 75 por ciento de las tiendas de FlixBuster en toda América del Norte son de propiedad y administración corporativa; el 25 por ciento restante son franquicias de propiedad privada. FlixBuster trabaja en estrecha colaboración con los propietarios de las franquicias para garantizar que la experiencia del cliente sea coherente en todas las tiendas. FlixBuster se enorgullece de su gran inventario de títulos, la tasa de solicitudes de los clientes que se cumplen con éxito y la rapidez con la que los miembros reciben cada video nuevo por correo.

FlixBuster tiene una asociación compleja con los estudios que producen las películas y los centros de intercambio de información que proporcionan medios autorizados a FlixBuster y administran los pagos de regalías y los acuerdos de licencia. Cada título está asociado con un porcentaje de regalías que se pagará al estudio. Las declaraciones de regalías y los pagos se realizan mensualmente a cada una de las oficinas de compensación.

Además, los canales de venta de FlixBuster (e-tail y retail) reciben un porcentaje de los ingresos por alquiler de videos. Los propietarios de las franquicias reciben un monto de ingresos negociado que generalmente es más alto que el de las tiendas minoristas de propiedad corporativa. El canal en línea aún recibe un porcentaje de ingresos diferente para cubrir sus costos operativos.

FlixBuster ha determinado que existe un buen caso comercial para desarrollar un sistema de inteligencia de negocios. Este sistema DW/BI servirá a usuarios corporativos de finanzas, marketing, ventas, gestión de clientes, gestión de inventario y otros departamentos. FlixBuster también tiene la intención de lanzar un portal de BI por subscripción para sus socios de la oficina de compensación, estudios, franquicias y posiblemente incluso proveedores de bases de datos de películas en Internet. Se espera que dicho portal de intranet proporcione flujos de ingresos adicionales para FlixBuster.

Existen múltiples fuentes de datos para el sistema FlixBuster DW/BI, incluido FlixBackOffice, el sistema ERP corporativo; FlixOps, el sistema de cumplimiento de video por correo; FlixTrans, el sistema transaccional y de puntos; FlixClear, el sistema de gestión de regalías; y otros.

FlixBuster ha completado con éxito otros proyectos de desarrollo utilizando metodologías ágiles y está decidido a adoptar un enfoque de Analíticas Ágiles en el desarrollo de su sistema DW/BI, FlixAnalysis. Durante el análisis y las revisiones del comité directivo ejecutivo de alto nivel, se decidió que el primer lanzamiento a producción de FlixAnalysis será para el departamento financiero y será un ciclo de lanzamientos de seis meses.

Resumen

Este artículo ha sentado las bases para una comprensión precisa, aunque de alto nivel, de Analíticas Ágiles. Los siguientes capítulos del libro sirven para completar detalladamente las técnicas de "cómo hacerlo" que un equipo de Analíticas Ágiles necesita para poner estos conceptos en práctica. Ahora hay que comprender que las Analíticas Ágiles no son simplemente una cuestión de dividir las tareas en iteraciones de dos semanas, tener una reunión diaria de 15 minutos con el equipo o cambiar al gerente de proyecto por un "scrum master". Aunque estos pueden ser rasgos ágiles, los nuevos equipos ágiles a menudo limitan su agilidad a estos conceptos más simples y pierden de vista las cosas que realmente definen la agilidad. La verdadera agilidad se refleja en rasgos como la entrega temprana y frecuente de funcionalidades de BI, trabajo con calidad de producción, entrega temprana de funciones de mayor valor, abordando el riesgo y la incertidumbre de manera temprana, y la interacción y colaboración continua entre los interesados ​​y los desarrolladores.

Los equipos de Analíticas Ágiles evolucionan hacia el mejor diseño de sistemas buscando y adaptándose continuamente a los comentarios de la comunidad empresarial. Las Analíticas Ágiles equilibran la estructura y formalidad con la flexibilidad, con un enfoque constante en la construcción de la solución correcta. La clave para la agilidad reside en los valores fundamentales y los principios rectores más que en un conjunto de técnicas y prácticas específicas, aunque las técnicas y prácticas eficaces son importantes. Los equipos de Analíticas Ágiles maduros se elevan por encima de un catálogo de prácticas y establecen actitudes y patrones de comportamiento que fomentan la búsqueda de retroalimentación, la adaptación al cambio y la entrega de valor máximo.

Si estás considerando adoptar Analíticas Ágiles, mantén estos valores y principios fundamentales en mente. Cuando se aprende cualquier técnica nueva, es natural buscar patrones exitosos que puedan imitarse. Este es un enfoque valioso que permitirá a un nuevo equipo ágil avanzar en el camino correcto y evitar dificultades innecesarias. Si bien he enfatizado que el desarrollo ágil no es un proceso prescriptivo, los nuevos equipos ágiles se beneficiarán de algunas técnicas al estilo receta. Por lo tanto, muchas de las prácticas introducidas en este libro pueden dar la sensación de ser prescriptivas. Lo aliento a probar estas prácticas primero según lo prescrito y luego, a medida que adquiera experiencia, adáptelas según sea necesario para hacerlas más eficaces. Pero asegúrese de que está adaptando las prácticas por las razones correctas. Tenga cuidado de no adaptar una práctica simplemente porque fue difícil o incómodo en el primer intento. Además, asegúrese de no simplemente seleccionar las prácticas fáciles mientras ignora las más difíciles. A menudo, las prácticas más difíciles son las que tendrán el mayor impacto en el rendimiento de su equipo.

Disfrutaste este capítulo? Lee más u ordena una copua de ​Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing.             

Traducción realizada por: Fernanda Vega y Gonzalo Martinez