Agile DW/BI in a Nutshell

Agile DW/BI is based upon the classic agile approach called scrum that revolutionizes the way software professionals collaborate within the project room. We put business and coders in the same room, repeatedly giving them two or three weeks to deliver the next increment of shippable code. We provide them only a high-level design to work from, letting them work in the fastest way they can devise, figuring out the remaining details as they go. We ask them to accumulate and utilize a reference model to guide their detailed designs, and have them work to a tough definition of "done" that's applied daily, using only two, light-weight, paper-based tracking tools that all parties can use to monitor progress within and between iterations.
We have to adapt generic scrum in two important ways for data integration projects. First, the solution architect must work with the project's business partner to draft a short vision document, partition the development work into "bite-size" chunks, and sequence the list of desired features for business priority and technical dependencies. Second, we utilize a second agile technique called Kanban to organize the work of the data modeler and systems analyst so that their specs for each module are 80 percent complete when the developers start building each module of code. At that point, however, the developers proceed with largely generic Scrum methods, gaining tremendous speed through a combination of self-organized teams, information-rich programming, and quality-driven development -- all of which allow them to fail fast and fix quickly. Let's consider these aspects to see where "fail fast and fix quickly" begins.

Self-Organized Teams

Whereas waterfall projects prepare a detailed work breakdown structure before coding starts, agile leaves most of that detail for teams to figure out for themselves. Activity within the project room during the first few iterations may look chaotic for a new team, but scrum requires teams to end each cycle with a discussion of how to improve their work habits. Agile places a tough burden upon the team: demo new, shippable code to your business partner every few weeks. Teams quickly devise for themselves exhaustive standards for module development, including traditional quality techniques such as peer reviews and thorough "as-built" documentation for operations. At the end of the cycle, the embedded business partner either accepts or rejects the new modules based upon their functional capabilities.

By placing such tough objectives upon the team and repeating the process every few weeks, agile forces the developers to get good at delivering increments of new value and keeps them good at it. They quickly eliminate every inefficiency in their process, evolving their work habits to be many times more effective than the highly-managed approach offered by waterfall methods.

Fail Fast and Fix Quickly

All three aspects we've described save labor, but more important, they form a synergy that further doubles a team's development velocity. Software professionals make mistakes during projects -- mistakes in requirements, design, and coding. By generating a big, detailed design before coding starts, waterfall methods ossify these mistakes, so they cost a tremendous amount of time to resolve once the application reaches system test.
Through regular demos of shippable code and continuous integration testing, agile forces a team's mistakes to the surface quickly, allowing business and IT to have informed, adult conversations about what can be done with the resources available. The early discovery of major issues means the developers still have time to correct misconceptions in requirements and design. They can keep the project on track, avoid large-scale rework, and consolidate designs so less must be built. Building less, avoiding major defects, preventing rework -- this is where agile DW/BI gets its tremendous speed.

By Ralph Hughes, MA, PMP, CSM.

Lecciones de un CIO: las 5 cosas que tenemos que considerar sobre la nube

La mayoría de los Directores de Información (CIO) ya están hablando sobre la nube y conocen sus beneficios, pero el gran interrogante sigue siendo cuál debería ser el primer paso para conseguir dichos beneficios. El CIO de Microsoft, Tony Scott, publicó recientemente un artículo basado en su propia experiencia de implementación de computación en la nube en la compañía y las lecciones que aprendió en el proceso.

Dado que en Latinoamérica observamos una creciente adopción de computación en la nube (tanto en el ámbito público como en el privado), esas experiencias son lecciones valiosas que pueden ayudar a los clientes a realizar una adecuada priorización para sacar adelante su proyecto.

1. Trasladarse a la nube es una decisión tanto comercial como técnica. Al tomar la determinación de migrar hacia la nube, se deben tener en cuenta —y se deben balancear— los elementos comerciales y técnicos. Identificar las prioridades de negocio y qué problemas de índole comercial se están tratando de resolver, es una parte vital. Pregúntele a su CEO (Director Ejecutivo) cuál es el sistema más importante en la empresa, y cuál es su interés principal. Esta es una buena oportunidad para cambiar las suposiciones y comprender cuáles son las áreas de oportunidad.

2. No hay una talla única. Las necesidades comerciales siempre serán el motor clave y no existe una solución que pueda ajustarse a todos los tamaños y necesidades. Si bien hace unos años muchas empresas construyeron y planificaron para los picos de trabajo, la utilización de servidores fue disminuyendo y los costos de soporte se fueron elevando. La virtualización puede ser el primer paso, pero obtener los beneficios de la nube junto con el nivel de control requerido por ciertos servicios y capacidades, puede extender dichos beneficios. La Tecnología de la Información (TI) de Microsoft pudo reducir los costos de soporte en un 35%; reforzar los SLA (acuerdos de nivel de servicio) y mejorar la satisfacción de los clientes al construir una nube privada, de manera que la flexibilidad en su uso, ya sea en la forma pública o privada, o una combinación de ambas, es la clave.

Toda organización tiene que considerar preguntas cruciales como: ¿cuáles son las capacidades de nuestra oferta?, ¿cuál es nuestro plan de acción?, ¿cuál de nuestras aplicaciones puede trasladarse más fácilmente?, ¿cuáles ya están separadas por estados?, ¿cuál puede ser virtualizada?, ¿cuáles no vale la pena mover a la nube? y ¿cuál es el impacto comercial de trasladar cada aplicación a la nube? Estas respuestas pueden ayudar a definir el equilibrio que mejor se adapta a su empresa.

3. La ventaja de la oportunidad de re-edificar. Muchas veces, en especial en el campo de TI, la tentación detrás del ‘funciona, entonces mejor no lo toques’ impide que las empresas aprovechen las oportunidades de implementar ‘nuevas formas de hacer cosas nuevas’, y no solamente ‘nuevas formas de hacer lo mismo’. Con la incorporación de la nube, TI ahora tiene la oportunidad de cambiar drásticamente el perfil de costo de aplicaciones más antiguas y trasladarlas a una plataforma que sea más escalable. Según Tony Scott, uno de los primeros proyectos en la nube fue mover la herramienta de subastas de Giving, la campaña interna de Microsoft, a Windows Azure porque solamente se usaba una vez al año durante un mes, y las últimas 48 horas de ese mes, siempre mostraba un alto pico en la cantidad de usuarios. Al reconstruir la herramienta, Microsoft redujo el costo de ejecutarla, a la vez que ganó mayor confiabilidad.

4. Busque ahorros de costos en entornos upstream (flujo de datos del cliente al servidor). Detrás de cada entorno de producción hay varios entornos upstream, tales como los de prueba, que muchas veces no se usan o se desaprovechan. La nube le brinda capacidad a estos entornos con solo presionar un botón, disminuyendo los recursos de TI desaprovechados. Esto es ahorro de costos instantáneo en lugares en los que la mayoría de los CIO ni siquiera buscan.

5. El rol de los Directores de Información (CIO) cambiará a medida que la nube se imponga y las organizaciones cambien. Los CIO necesitan prepararse para la evolución de su rol dentro de la compañía. A medida que las empresas se vuelven digitales y se alejan de lo analógico, el CIO debe centrarse más en los procesos de negocios que en los límites organizacionales.

La cuestión principal en relación con la computación en la nube es que los CIO tienen que ponerse en marcha. Esa es la parte más difícil. Sin embargo, una vez que empiezan y experimentan una de estas plataformas, las posibilidades se disparan. Con la visión única de Microsoft y la capacidad que tenemos de ofrecerla a empresas de prácticamente cualquier tamaño, tenemos una gran posibilidad de construir juntos este camino.

La oportunidad es única: conectar las actuales inversiones en activos y conocimiento para aprovechar este nuevo paradigma y beneficiar a empresas en toda Latinoamérica.

Autor Por Aylton Souza

Gerente de Producto Cloud
Microsoft Latinoamérica

¿Por qué unos líderes inspiran y otros no?

Hace pocas semanas me encomendaron dictar una conferencia tomando como modelo el caso Wal-Mart en el mundo, el día de ayer, un buen amigo me recomendó una conferencia en internet y las cosas se concatenan maravillosamente.

Existe un común denominador de los grandes líderes u organizaciones, de aquellos que logran realmente hacer que miles o millones de personas se vinculen con sus marcas, productos, ideas y/o atributos.

Resulta que las empresas e instituciones se comunican siempre “de afuera hacia adentro”, le dicen al mercado primero “qué hago” y luego “cómo lo hago” ejemplo: “vendo coches (qué)…. Los mejores coches deportivos al mejor precio” (cómo); pero pocas empresas o instituciones, pocos líderes, aterrizan en un “porqué lo hago”.

Y no sólo es importante comunicar el por qué, sino que, más aún, hay que ponerlo por delante. Cuando Sam Walton inicio su negocio, nunca empezó una reunión con su equipo de trabajo diciendo “somos la empresa de venta al menudeo más grande y rentable del mundo (el qué) porque damos el precio más bajo siempre (el cómo). Lo que él realmente les decía es el por qué…. “debemos poner al alcance de la familia americana cualquier producto o servicio permitiendo mejorar la calidad de vida del hombre promedio”.

Cuando uno comparte el IDEAL, la Visión, el fin final del esfuerzo, cuando uno externa en qué CREE, permite a las personas identificar el mismo sistema de creencias básico y permitir que, quienes coinciden con ese ideario, se vinculen “de adentro hacia afuera” con la causa del líder.

Si analizamos cualquier estructura social masiva con miles o millones de seguidores encontraremos el mismo patrón… las personas se vinculan con el porqué aunque el cómo y el qué, incluso, no les sean del todo agradable.

Lo mismo que Amway que genera “libertad financiera” para miles de personas, Casas GEO “creando el mejor lugar para vivir en comunidades sostenibles”, Disney “creando el lugar más feliz del mundo” o cualquier otra institución de liderazgo probado…. Sus seguidores se vinculan con el “por qué” del esfuerzo.

Cuando el líder habla “al corazón” de su equipo, realmente le habla al cerebro límbico, al que están encargados de decodificar los instintos, la inteligencia emocional, subjetiva.

No hay líder que genere seguidores con datos y cifras, como tampoco hay producto que se venda en el mercado previa lectura del manual de funcionamiento.

Las relaciones entre personas, marcas y productos se generan a través de los vínculos emocionales, de confianza, ese “no sé qué, que qué sé yo”, se obtiene al vincular tu discurso y tu accionar a la emocionalidad de tus seguidores, a su sentido sublime por encima del cognitivo.

Así pues, antes de intentar ser seguido porque tu producto o empresa “es el mejor en el mercado”, “tiene los mejores precios” o “es socialmente responsable”, trata de identificar cuál es el fin final de tu servicio o producto, tu propia gestión como líder, ¿porqué es que el mundo puede ser un mejor lugar si me vinculo a tu causa?… a tu esfuerzo… a tu cotidianidad.

Si mi corazón (mi cerebro límbico) realmente confía y cree en ello… tendrás un soldado dispuesto a todo por tu empeño.

Hoy más que nunca…
Piensa, Reflexiona y Actúa….


Autor: Helios Herrera
Derechos Reservados