Open Data

viernes, 13 de diciembre de 2013

Uno de los temas de interés en Tercer Planeta es Open Data


http://galecia.com/blogs/lori-ayre/open-data-movement-great-graphic
http://galecia.com/blogs/lori-ayre/open-data-movement-great-graphic

Las conferencias de las Octavas Jornadas de Data Mining nos impulsaron a investigar, explorar varios links y discernir sobre los alcances del mismo. Aquí un resumen:



¿Qué es Open Data?

Podríamos definir Open Data como la  publicación sistemática de datos. Es una filosofía y práctica que propone que determinados datos estén disponibles de forma libre a todo el mundo, sin restricciones de copyright, patentes u otros mecanismos de control.

Open Data se relaciona con otros movimientos abiertos: open source (código y tecnología), open governance (decisiones y recursos) y open innovation (conocimiento). Estamos hablando de información de gestión, recursos compartidos, transparencia, colaboración y participación.
Surgen varios desafíos, entre ellos el entender a Open Data como un servicio público y  entender que esta información es un derecho ciudadano. Sin olvidar las responsabilidades que este nuevo derecho implica.


Open Data
http://www.flickr.com/photos/notbrucelee/5241176871/

Una de las primeras definiciones de open data fue publicada por la  Unesco: directrices para políticas de acceso abierto: 
"Mediante el Acceso Abierto, los investigadores y estudiantes de todo el mundo alcanzan cada vez más acceso al conocimiento, las publicaciones obtienen mayor visibilidad y número de lectores y el impacto potencial de la investigación es fortalecido [..] facilitan las oportunidades para el desarrollo económico y social equitativo, el dialogo inter cultural y tienen el potencial de estimular la innovación."

En 2007 el grupo de trabajo denominado Open Government Working Group reunido en Sebastopol
(California, EE.UU.) propuso estos 8 principios para la liberación del acceso a datos gubernamentales, los cuales se han convertido en la base de un estándar de facto.
Así, se denomina liberación del acceso a datos gubernamentales (open government data) a: la puesta en disponibilidad pública por parte de los estados de datos en forma digital a través de Internet de manera que permita y promueva su análisis y re utilización. 

El acceso a datos gubernamentales se considera abierto si los datos son puestos a disposición del público cumpliendo con los siguientes principios:




Hay comentarios muy lúcidos respecto a la aplicación 'real' de estos principios, en el blog de Alejandro Barros.


¿Qué es consumo de datos?

La apertura de datos no es un fin por sí misma. El consumo de datos sí. 
Entendamos que no basta con tener datos disponibles, es necesario poner manos a la obra para que se pueda sacar provecho de los mismos.

El consumo de Datos Públicos debería cumplir etapas:

1. Obtener los datos: implica el uso de datos publicados por distintas organizaciones
2. Asegurar el derecho a utilizar los datos: (tema de licencias, permisos)
3. Procesar los datos: (Analizar, entender, limpiar, relacionar de forma transparente, re producible)
4. Publicar
5. Hacerse cargo de lo realizado, en particular, posibilitar la reproducción y ser responsables de una retro alimentación a las fuentes


Data Journalism 

De acuerdo con el interesante Data Journalism Handbook, podríamos decir que es Periodismo a partir de Datos. Ambos términos, 'data' y 'periodismo' son  difíciles de definir.
Para muchos, 'data' es una colección de números, a lo sumo reunidos en una hoja de cálculo. Hasta ahora, este tipo de datos fueron los que los periodistas enfrentaron, pero hoy por hoy toda nuestra vida se podría definir con números, unos y ceros. Desde documentos hasta conexiones entre distintos usuarios, por ejemplo.
Qué diferencia al periodismo de datos del periodismo en general? Quizás las nuevas posibilidades que surgen al combinar el olfato por las noticias, con la habilidad para contar buenas historias y la magnitud de la información digital ahora disponible.
Data puede ser la fuente del periodismo de datos, puede ser la herramienta para contar una historia, o puede ser ambas. Debe ser tomado con el mismo escepticismo con el que se toma toda fuente, y como herramienta requiere tomar conciencia de la forma en que esta puede orientar y sesgar lo que se informa.

Las tecnologías de la información están cambiando  la forma como se publica la información pública. El Periodismo de Datos es una nueva rama, y tiene un papel importante en la capacitación masiva de lectores que puedan  comprender la información publicada.

En esta tarea es fundamental:
  • La recopilación y el asociación de diversas fuentes de datos no relacionados previamente.
  • El procesamiento de los datos que permita sintetizarlos (deductivamente) o generalizarlos (inductivamente) para explicitar conocimientos que no son accesibles directamente.
  • La visualización adecuada que permita que esta información “penetre” en el usuario de una manera física, sensorial y hasta irracional.

Armamos esta lista de portales de datos oficiales y de buenos ejemplos de consumo de datos:


Hablando de Periodismo, varios de los  premios 2013 corresponden a visualizaciones hechas a partir de datos públicos.

Finalmente, podemos profundizar  estos temas, con la ayuda de Jornalism in the Age of Data y el Data Journalism Handbook  mencionado previamente.

 
Leer más...

De JSON a objeto dinámico C#

lunes, 2 de diciembre de 2013

La anterior semana me encontré con el reto de usar un JSON gigante, que tenía alrededor de 22.000 líneas de código,  para simplemente ciclar por una de sus colecciones y extraer no más de 5 campos. Me pareció una locura intentar siquiera sumergirme en entender cómo estaba estructurado, qué colecciones tenía, etc.

Googleando bastante, encontré un Nuget que les puede facilitar mucho esta tarea: DynamicJson

DynamicJson es un Nuget, disponible a partir del framework .NET 4.0, que nos va a proporcionar una clase que transforma un JSON en un objeto dinámico con esta simple sintáxis:
 
    var myObj = DynamicJson.Parse(myJSON);

Como resultado, obtenemos un objeto iterable que respeta la estructura del JSON con todos sus valores y cuyo contenido es muchisimo más fácil de explorar, pasando de esto:


A esto:



Se nota la diferencia?

Este Nuget, además, nos proporciona algunos métodos para verificar existencia de algúna propiedad, eliminar elementos, serializador, deserializador y acceso a sus propiedades por medio de notación C#.

Espero que les sea de utilidad.

  
Leer más...

Octavas Jornadas de Data Mining

miércoles, 27 de noviembre de 2013

El 26 de octubre pasado tuve la oportunidad de asistir a las Jornadas anuales que organiza la Maestría en Exploración de Datos y Descubrimiento del Conocimiento, en la Facultad de Ciencias Exactas, de la Universidad de Buenos Aires.
Logo Maestría (UBA)

El tema principal fue de especial interés, puesto que se enfocaba en Visualización,   tema que venimos abordando en Tercer Planeta.



Algunas apreciaciones

Muy buena  la presentación de Visual Analytics (SAS). Mediante esta herramienta es posible representar en forma gráfica grandes cantidades de información. Permite tener una vista general de los datos, aplicar zoom y filtrar, y mostrar detalles a demanda, teniendo en cuenta el mantra de visualización de Ben Shneiderman.
 Se relacionó con visualización la conferencia sobre Técnicas de Visualización de Sistemas Complejos en Bio informática, donde se postuló la necesidad de superar la problemática de la cantidad y heterogeneidad de los datos.
La presentación de Claudio Delrieux (UNS) destacó las  Problemáticas Actuales de la Visualización en Big Data:  volumen, velocidad, variedad, verosimilitud y valor (las 5V).
Finalmente, Alejandro Baranek presentó sus trabajos en la conferencia “Visualización experimental en 3D”.

Otro tema de interés en las jornadas fueron la búsqueda de artículos científicos en la web y Open Data.

Djamel Abdelkader Zighed,  invitado especial de la Universidad de Lyon, trató  el problema de la complejidad en el proceso de búsqueda de artículos científicos en la web y su posterior análisis entre millones de referencias disponibles. Al respecto señaló que la dinámica de crecimiento de los datos abiertos en Internet, conocida como Open Data, y la ambigüedad existente en los nombres de los autores de los artículos, vuelve imprescindible implementar una metodología en minería de datos. Como ejemplo de ello, Zighed mencionó la herramienta Babel, que cuenta actualmente con interesantes resultados para refinar la información de las bibliotecas digitales.

La conferencia “Open Data: oportunidades y desafíos para el Estado, la sociedad y la industria”, permitió ubicarnos en la realidad actual del tema, siendo de particular interés los ocho principios de gobierno abierto, declarados por la UNESCO. No hay dudas de la oportunidad que se abre a partir de esta área.

 
Leer más...

Factores a considerar en la elección de un CMS

martes, 19 de noviembre de 2013

Como hemos mencionado en otras oportunidades, llevamos una larga experiencia trabajando con los departamentos de RRHH, Comunicación y Marketing de empresas nacionales y en el exterior. Y a medida que fue pasando el tiempo hemos visto que la necesidad de organizar, centralizar y ordenar lo que se quiere exponer, tanto en el área interna como en el aspecto público, creció enormemente y a gran velocidad.

Evidentemente la tecnología ha acompañado y fomentado este crecimiento ganando una gran incidencia en los sectores antes mencionados y ayudando con muy variadas herramientas (ver artículo Incidencia de las TIC en la gestión del Capital Humano). Un ejemplo de las mismas son los CMS (Content Management System) es decir, sistemas para la administración de contenidos de sitios web, internos o públicos, que han tenido un gran crecimiento desde hace varios años.

Imagen: sictanet.org
Si bien existen en el mercado CMS de muy variadas características y precios, en determinado tipo de empresas hemos comprobado que las mejores opciones se encuentran entre CMS pagos (hay compañías que tienen una larga trayectoria en productos muy sólidos) o CMS hechos a medida.  De hecho, venimos acompañando a organizaciones que mantienen una combinación de estos dos tipos de herramientas para su sitio público y para sus intranets.

Esto no quita, por supuesto, mencionar que existen varias opciones de CMS gratuitos, muchas muy buenas, pero más apropiados para objetivos y empresas con características diferentes a las que nos ocupan en este artículo.

Qué es un CMS?

A grandes rasgos un CMS consta de 2 partes:
  1. Administración de contenidos: o sea, una aplicación a través de la cual los editores o encargados de contenidos ingresan las notas, artículos, archivos, etc. que quieren mostrar en el sitio, definen en qué categoría ubicarlos, en qué "zona" dentro del diseño definido, cuándo publicarlos, etc.. Un buen CMS debe incluir también un sistema de permisos confiable, permitir la modificación de ciertas configuraciones como así también la asignación de distintos roles a diferentes usuarios.
  2. Presentación de contenidos: que es la aplicación encargada de mostrar los contenidos programados por los usuarios correspondientes desde la aplicación anterior para las distintas vistas, idiomas y dentro del diseño previamente definido.

Factores a considerar

Qué puntos se deben evaluar cuando se quiere cambiar o incorporar por primera vez un CMS?

  • Volatilidad de contenidos: Si bien son varios los factores que hacen a una compañía decidir invertir en un CMS, uno de los que más influye es la gran volatilidad de los contenidos a comunicar. Esto aplica tanto a intranets como a sitios públicos donde se necesita administrar de forma autónoma, rápida y verstátil  los diferentes tipos de información (textos, imágenes, videos, sonido, archivos, etc.)).
  • Tamaño de organización y dispersión geográfica: Otro de los puntos a considerar es el tamaño de la organización y su dispersión geográfica. Para el caso de empresas que reparten sus sedes entre varios países e idiomas, el CMS a elegir deberá contar con determinadas características que, seguramente, no serán requeridos por otro tipo de empresas.
  • Variedad de datos y funcionalidades: Por otro lado, es necesario considerar el tipo y variedad de datos que la organización quiere manejar a través del sitio para poder seleccionar un CMS que sea capaz de administrar la complejidad de contenidos que la empresa requiere.
  • Seguridad: Por supuesto, la seguridad de la información es otro de los puntos críticos y prioritarios.
  • Escalabilidad: Es importante también visualizar el rumbo que tomarán los portales y pensar que la herramienta que se elija tenga una flexibilidad tal que permita escalabilidad en cuanto a diseño, contenidos y funcionalidades en general.
  • Integración: Otro tema a tener en cuenta es que el CMS elegido pueda integrarse fácilmente con otras aplicaciones utilizadas en la organización para intercambio de información.
  • Curva de aprendizaje: Un punto fundamental es que la curva de aprendizaje de utilización de la herramienta no sea muy alta. Una de las características primordiales es que el CMS elegido sea de fácil uso para que los responsables puedan utilizarlo sin dificultad, sin riesgo de cometer errores y sin oponer resistencia al mismo.
  • Soporte: algo fundamental a considerar es que el lenguaje utilizado para el desarrollo de una herramienta como esta sea ampliamente conocida, sólida y confiable.

Imagen: gestiondepymes
Para el caso de CMS más complejos, que permitan cubrir necesidades avanzadas o desde los cuales se deban administrar funcionalidades más sofisticadas, es necesario tener en cuenta que se debe contar con personal capacitado para la administración del mismo.
Para firmas de cierto tamaño y caracteristicas, obviamente será necesario disponer de un equipo interno o externo que se encargue del mantenimiento de determinados componentes de la herramienta, su integración con otras aplicaciones de la empresa y el control de la instalación e infraestructura de la misma.

Si bien puede no resultar simple encontrar un único producto que satisfaga 100% estas y otras necesidades, hay que tener en cuenta que las herramientas pagas suelen tener una enorme variedad de posibilidades, soporte técnico de muy buena calidad y comunidades que ayudan a difundir y optimizar el uso del producto. En estos casos la evaluación crucial está en determinar el retorno de inversión que se obtendrá versus el pago de licencias por la compra del producto, si ese fuera el caso.

Pensar en un CMS a medida nos permite contar con la posibilidad de adaptar las funcionalidades del mismo a las necesidades exactas de la organización, escalabilidad en la medida que se necesite y personalización de determinadas funcionalidades cuando sean requeridas. Esta opción no tiene por qué necesariamente estar siempre asociada a la idea de "quedar atado" a un solo proveedor, pago de abonos interminables o riesgo de no tener soporte. Una herramienta estabilizada y bien construida evita tener que lidiar con estos problemas.


En la experiencia que tenemos vemos que una buena combinación de usuarios expertos, usuarios de funcionalidades más básicas y un equipo de desarrollo y mantenimiento pequeño - interno o externo a la organización - da excelentes resultados en cuanto a velocidad de respuesta, calidad y eficiencia en el uso de este tipo de productos.

 










Leer más...

Scrum - Impedimentos

martes, 5 de noviembre de 2013

Muchas veces nos ha pasado en nuestro trabajo encontrarnos con eventos o situaciones imprevistas que nos obligan a buscar soluciones creativas para continuar según lo planificado o que nos llevan a modificar directamente la planificación hecha, con el cambio de humor que esto implica dentro del equipo. Este tipo de situaciones o eventos son lo que llamamos impedimentos.


Cuando recién empezamos con Scrum nos resultaba muy difícil comprender qué hacer con estas cosas y cómo tratarlas. Algo que nos sirvió y que me parece fundamental es entender claramente de qué se trata y cómo identificarlos.

Impedimentos Scrum
Entonces, qué es realmente un Impedimento? De las muchas definiciones que al respecto podemos encontrar, la que más me gusta es la que ve a los impedimentos como cualquier obstáculo que bloquea o demora el progreso del equipo. Es decir, cualquier situación que impide a una o más personas del equipo continuar con su tarea, con su correlativo impacto en el progreso del sprint en el que estén trabajando y/o en el backlog general.

Y algo que nos ayudó mucho a "aceptarlos como tales" fue comprender que no hay team que no se encuentre con trabas de cualquier tipo que impacten en los Sprint. Que todos los miembros del equipo entiendan esto suele ser "liberador" ....

Cómo detectarlos

Estas trabas o imprevistos surgen durante el trabajo diario y DEBEN ser comunicados al resto del equipo, en general durante las reuniones diarias. Pero, dado que uno de los roles más importantes del Scrum Master (SM) es el de eliminar los problemas para lograr la mayor eficiencia del team, es esperable también que sea él quien tenga la capacidad de estar muy atento a buscarlos y detectarlos.
Por otro lado existe una contrapartida a este rol del SM y es la responsabilidad que tiene el equipo de comunicarle, en cualquier momento, la aparición de toda situación que impida o retrase una tarea , para que ese problema pueda ser tratado adecuadamente.

Y, por supuesto, las retrospectivas son el mejor momento para exponer, identificar y categorizar todas las "molestias" surgidas durante el sprint.

En resumen, tanto las capacidades del SM como una fluida y abierta comunicación dentro del team son fundamentales para la detección, reconocimiento, tratamiento y resolución de los impedimentos.

Tipos de impedimentos

Una posible clasificación de los impedimentos se basa en el tratamiento que necesiten:


  • Impedimentos del equipo, que son los típicos problemas que pueden ser resueltos dentro del team, ya sea tomando medidas internas para evitar que se repitan, estableciendo cambios en la forma de trabajo, definiendo el uso de nuevas herramientas, etc.

  • Impedimentos de la organización, que son problemas que dependen de otros para ser resueltos como temas de infraestructura, demoras en los entregables de otros equipos, entre otros.

Ejemplos típicos de impedimentos:

  1. Enfermedad de algún miembro del equipo
  2. Operaciones de mantenimiento de hardware o software corporativo que afecten la continuidad de las tareas planificadas
  3. Interacción con proveedores que no cumplen con los plazos o los servicios comprometidos. Este es, tal vez, uno de los impedimentos más preocupantes dado el poco margen de intervención que puede llegar a tener el SM para solucionarlo
  4. Ausencias o poco compromiso del Product Owner que demora la toma de decisiones o aprobaciones. Particularme este caso lo hemos sufrido en algunos de nuestros proyectos y representa  realmente un gran problema, la clave está en tratar de mantener un muy buen diálogo con el PO y hacerle notar la importancia de su presencia durante todo el proceso y las consecuencias que puede provocar su no involucramiento
  5. Un backlog mal definido o con requerimientos que no estén listos o bien detallados para iniciar la planificación del sprint
  6. Reuniones largas, innecesarias o que involucren a miembros del equipo que podrían no estar, restándoles tiempo para avanzar según lo planificado

Cómo tratarlos

La lista de puntos a seguir con los impedimentos debería recorrer los siguientes pasos:
Impedimentos Scrum
  • Registrarlos
  • Piorizarlos
  • Hacerlos públicos
  • Actuar sobre su resolución
  • Informar de su resolución

Muchos de los impedimentos que pueden encontrarse en las tareas diarias suelen ser pequeños y de fácil y rápida resolución  (pedir ayuda a otro miembro del team, un mail, una llamada telefónica al equipo de operaciones, etc.). Como muchos aconsejan, estos ítems pueden ser incluídos en el backlog y tratados dentro del mismo.  Para el resto de los impedimentos se aconseja llevar un Backlog de Impedimentos.

Yendo en el mismo sentido, la Scrum Alliance nos da 5 tips para manejar la resolución de Impedimentos:

  1. Hacerlos visibles, dejarlos escritos y a la vista de todo el equipo, cerca de la pizarra de tareas. Deben estar especialmente visibles durante la reunión diaria para que el SM pueda contar al equipo cuáles se fueron removiendo y junto con el equipo re-categorizar el resto.
  2. Buscarlos, indagar, sobre todo en equipos que recién empiezan con la práctica el SM debe encargarse de detectarlos y sacarlos a la luz (por ejemplo, cuando las tareas quedan inmóviles en la pizarra por mucho tiempo, cuando hay más tareas "En Progreso" que desarolladores). Preguntar siempre qué haría que las tareas se resuelvan lo más rápido posible.
  3. Limitar el número de Impedimentos, ya sea por tiempo o por cantidad. Por tiempo implica establecer un máximo de horas que se permite a un impedimento permanecer en la lista, por ejemplo "un impedimento puede existir por un máximo de 24 hs", pasado ese tiempo tiene que ser resuelto o enviado al próximo sprint. Por cantidad implica establecer un máximo de impedimentos abiertos por sprint para ser resueltos. El equipo decidirá qué hacer en el caso en que surja alguno nuevo en el medio. En el punto siguiente hacemos una salvedad a este tip.
  4. Diferenciar entre impedimentos globales y locales. Esta categorización es importante para entender cuáles son los impedimentos que disminuyen la velocidad del equipo (globales) y cuáles los que bloquean la continuación de alguna tarea (locales o blockers). Esto nos remite al punto 3: ese tip sirve para los impedimentos de tipo global. A los impedimentos locales, que bloquean una o más tareas, la Scrum Alliance nos aconseja agregarlos a la pizarra del sprint con algo que los diferencie visualmente del resto de las historias para que sean enfrentados cuanto antes.
  5. Ayudar al equipo a resolverlos. En la medida que se pueda, es aconsejable encontrar un equilibrio entre los impedimentos que toma para solucionar el SM y aquellos que puede solucionar el team por sí solo.Si bien una de las capacidades del SM es la de "limpiar" los impedimentos, es bueno dejar que el equipo pueda hacerse cargo de algunos de ellos.
 
Para finalizar, me quedo con una una frase que encontré respecto de este tema y me pareció muy buena: "No puedes eliminar los impedimentos pero tampoco deberías ignorarlos, o peor aún, aceptarlos como algo normal". (de Impediments Management and The Agile Triangle )


Más para leer:

Identificando Impedimentos

Impedimentos en Scrum

Top ten organizational impediments

   

Leer más...

Probando Pentaho IV: sparkline, dataBar y paleta de colores.

miércoles, 23 de octubre de 2013


 Con este tablero de control queremos mostrar cómo probamos algunos componentes de Pentaho y CTools.
 El gráfico muestra la variación de las ventas de Internet durante un período, por país. 
Permite comparar el porcentaje de ventas por año y muestra tendencias por medio de sparklines. 
 La base de datos es AdventureWorksDW, de Microsoft SQL Server Database Product Samples

Internet Sales

Es una línea de tiempo en años con el total de ventas por país.
Componente usado: CCC Line Chart.


Propiedades relevantes del componente: 
  • Data Source:  ventas por territorio y por año.
 
SELECT   T.CalendarYear,st.SalesTerritorycountry ,SUM(S.SalesAmount) TotalSalesAmount 
FROM dbo.FactInternetSales S
INNER JOIN DimTime T ON S.OrderDateKey = T.TimeKey
INNER JOIN DimSalesTerritory st on S.SalesTerritoryKey = st.SalesTerritoryKey
GROUP BY T.CalendarYear,st.SalesTerritoryCountry
ORDER BY T.CalendarYear


  • CrossTabMode = FALSE.
  • SeriesInRows = TRUE.
  • PostFetch: definimos algunos extensionPoints y el formato de las marcas de cantidades.
 
function f(cdaData) {
    var newLine = this.chartDefinition;
    newLine.extensionPoints= [
        ["dot_fillStyle","#ffffff"],
        ["dot_shapeRadius","3"],
        ["dot_lineWidth","2"],
        ["line_lineWidth","2"],
   
        ["legendLabel_font","10px sans-serif"], 
        ["legend_font","12px sans-serif"],
        ["xAxisLabel_font","12px sans-serif"],
        ["yAxisLabel_font","10px sans-serif"],
        ["xAxisLabel_text",function(g){return (g.vars.tick)}]];
    newLine.yAxisTickFormatter= function(value){
            return (value / 1000).toFixed() + " K"; };
    newLine.showYScale= true;
    newLine.yAxisPosition= "left";
    newLine.colors=colorFill;
    newLine.xAxisFullGrid= true 
    newLine.yAxisFullGrid= true 
    newLine.xAxisEndLine= true 
    newLine.yAxisEndLine= true  
 this.chartDefinition= newLine;
}

Year Percentage

Es  una tabla con las ventas por región y por año, con porcentaje correspondiente sobre el total para poder comparar la proporción de aumento en las ventas de un año a otro. El componente de Ctools usado es una tabla, con una columna de tipo 'dataBar'.

Propiedades relevantes del componente: 
  • DataSource: busca el total de ventas por año y calcula el porcentaje que representa cada año respecto al periodo en estudio.

 
WITH TotalSales ( SumTotal)
AS(
SELECT  SUM(S.SalesAmount)
FROM dbo.FactInternetSales S
)
SELECT T.CalendarYear,SUM(S.SalesAmount) SalesAmount,
100 * SUM(S.SalesAmount)/ MAX(TotalSales.SumTotal)  SalesAmountPercentage,
100 * SUM(S.SalesAmount)/ MAX(TotalSales.SumTotal)  SalesAmountPercentage2
FROM dbo.FactInternetSales S
INNER JOIN DimTime T ON S.OrderDateKey = T.TimeKey
CROSS JOIN TotalSales
GROUP BY T.CalendarYear
ORDER BY T.CalendarYear

  • ColumnTypes: dataBar para SalesAmountPercentage

Country Trend

Esta tabla muestra la tendencia de variación de las ventas en un periodo de 4 años, usando sparklines.

A sparkline is a small intense, simple, word-sized graphic with typographic resolution. Sparklines mean that graphics are no longer cartoonish special occasions with captions and boxes, but rather sparkline graphic can be everywhere a word or number can be: embedded in a sentence, table, headline, map, spreadsheet, graphic
La columna correspondiente al sparkline debe ser una cadena separada por comas con los valores que formarán la tendencia.

  • DataSource: ventas por territorio y por año, totales por año en columnas y columna resumen de totales para conformar el sparkline.

 
 SELECT  SalesTerritoryCountry as Country ,
    CAST([2001]/1000 as CHAR(10)) + ','+CAST([2002]/1000 as CHAR(10))+ ','+CAST([2003]/1000 as CHAR(10))+ ','+CAST([2004]/1000 as CHAR(10)) as Trend
,[2001] , [2002]  ,[2003] ,[2004] 
FROM 
(SELECT st.SalesTerritoryCountry, CalendarYear,cast(S.SalesAmount  as int) as salesamount
FROM dbo.FactInternetSales S
INNER JOIN DimTime T ON S.OrderDateKey = T.TimeKey
INNER JOIN DimSalesTerritory st on S.SalesTerritoryKey = st.SalesTerritoryKey) p
PIVOT
(
sum(SalesAmount)   
    for CalendarYear in 
([2001] , [2002]  ,[2003] ,[2004]     )) as pvt order by SalesTerritoryCountry
  


Los Colores

Se intenta unificar e integrar los colores de los componentes, procurando usar un mismo color por país para los tres casos.
Fue necesario definir una paleta de colores: una lista de códigos rgb preseleccionados.
Buscamos en Protovis, que provee varias paletas de colores Colores Protovis.
En  un 'resource' de tipo javascript asociado al dashboard se definieron las listas con colores ( para aplicar en los componentes y tablas) y un color general (para los encabezados y marcos de tablas).  
rgbPasaHex se encarga de la conversión a RGB.

 
colorFill=pv.Colors.category19();
colores= colorFill.range();
var colorBase=rgbPasaHex(colores[9].color);


 Colores en tabla Year Percentaje
En la propiedad PreExecution de la tabla, seteamos 'AddInOptions' para configurar el color del DataBar usando 'colorBase'

   this.setAddInOptions("colType","dataBar", function(val)  
    {
            return { startColor: colorBase, endColor: colorBase}
       
    });


Colores en la CCC Line Chart  
Asignamos la paleta de colores en la propiedad  postFetch  de CCC Line Chart ( que mostramos previamente)
 
   
    newLine.colors=colorFill;
    this.chartDefinition= newLine;
   

Colores en la tabla Country Trend: 


el nombre de cada país, tiene el mismo color que el sparkline y que la linea de tiempo correspondiente.  
Para modificar los labels, se define un span con el color correspondiente en hexa.
Para los sparklines, se define el 'strokeStyle' a medida que se construye la tabla.

 
   function f() {
    var idx=-2;
  
    this.setAddInOptions("colType","formattedText",   
         {textFormat: function(v, st) { 
                 idx = idx+1;
          var colorHexa = rgbPasaHex(colorFill(idx).color);     
             return ""+v.toUpperCase()+" }
      });

   var idj = -2;
     this.setAddInOptions("colType","pvSparkline",function(val) {
        idj=idj+1;
        return {lineWidth:2,strokeStyle:colorFill(idj).color}});

   }



Colores en los encabezados y en los bordes de las tablas
Para manipular los colores de las tablas y los distintos elementos del documento, se usaron variables. En este caso, la variable global 'colorBase'. La asignación de color debe estar en el  postExecution de cada una de las tablas.



 
function p(){
    var color=colorBase.toString();
    $("th").css( 'color' ,  color );
    $("td").css( 'border' ,  '1px dotted '+color );
    $(".tit").css("color",color); // definida una clase tit para los encabezados
  
}




Artículos relacionados:

Probando Pentaho I (Instalación de Pentaho Community)
Probando Pentaho II (Dashboard de ejemplo)
Probando Pentaho III (Introducción a Pentaho CTools)


 









Leer más...

Innovación conciente

martes, 10 de septiembre de 2013

¿Cómo lograr un balance “perfecto” entre lo que nos suena más atractivo tecnológicamente hablando, y lo que resulta mejor para nuestro cliente?

Somos una empresa de Tecnología, nuestro equipo está formado por profesionales entusiastas, no sólo por lograr cumplir con los objetivos que plantea cualquier desarrollo de software, sino también por ofrecer un producto tecnológicamente de avanzada y moderno.

Para lograr nuestros objetivos se nos suelen plantear, entre otros, dos dilemas que podrían titularse así:

1- Tratar de ver más allá, nuestros clientes sabrán agradecerlo ¿Cómo recomendar y/o implementar una tecnología, sin haberla visto en real funcionamiento?
No siempre todo lo que se vende por ahí como lo mejor, resulta serlo y es muy importante recomendar implementaciones tecnológicas que sean acordes a la necesidad que buscamos satisfacer.

2- La mejor tecnología no es una en particular, es la que mejor se aplica a cada caso ¿Cómo lograr que nuestro entusiasmo tecnológico no le gane a nuestra conciencia profesional?.

(imagen tomada de http//wasanga.com/flormpecasique/files/2013/07/Proceso-de-Toma-de-Decisiones2.jpg?id=flormpecasique)

Nuestra experiencia en tantos años, nos permite volcar algunos tips que pueden ser útiles para lograr el objetivo principal, un producto de excelencia que cumpla con las necesidades planteadas en tiempo y forma, que permita seguir un ciclo de vida acorde a los tiempos en los que le toca vivir. 

Tratar de ver más allá, nuestros clientes sabrán agradecerlo

Primer paso: 


Lo más conveniente es Leer, Leer y Leer, en todo equipo siempre hay personas más predispuestas a saber interpretar por dónde viene la mano, es importante escucharlas y darles el lugar para poder llevar a cabo esa tarea.

Los foros de discusión son de mucha ayuda, se suelen volcar allí inquietudes sobre problemas reales con los que nos encontramos o nos vamos a encontrar.

Es muy útil saber elegir quienes son los gurúes a los que podemos seguir, buscar gente que sea responsable en lo que recomienda, y no dejarse llevar por charlatanes de turno.

Segundo paso 

Aprender una nueva tecnología, es una inversión no solo personal sino también para el equipo y por consiguiente para la empresa, permitir esta inversión cada vez que sea posible nos va a dejar mejor parados para el futuro, se podría decir que es un poquito de hambre para hoy, pero es pan para mañana.

Prototipar las partes más complejas sin entrar en los detalles para luego tratar de someterlo a pruebas que lo pueden poner al límite.

Tener muy claro en todas estas pruebas que lo importante es ver si la tecnología nos sirve para lo que queremos hacer, tratar de mantenerse distantes.

Normalmente en los equipos están los perfiles más innovadores, y los más reaccionarios al cambio, buscar el equilibrio de ambos nos puede dar los mejores resultados, hay que saber escuchar todas las campanas.

La mejor tecnología no es una en particular, es la que mejor se aplica a cada caso 

Cuando se elige una tecnología hay muchos factores en juego, menciono algunas de las preguntas que nos deberíamos hacer:

¿Qué impacto tiene la tecnología en la usabilidad del producto, si es que lo tiene?

¿Qué durabilidad en el tiempo pretendemos que tenga?

El mercado donde el producto va a vivir ¿le permitirá un soporte adecuado? en términos de posibilidades y costos. Etc. Etc…

Creo que la clave de todo esto es, ponerse en lugar del cliente en todo momento, y buscar la alternativa que realmente más le convenga a él.

Esto no siempre nos va a llevar al lugar más cómodo para nosotros, pero si nos va a permitir ganar la confianza del cliente, algo muy importante para poder llevar adelante una tarea tan compleja como apasionante, que es el desarrollo de software.

Leer más...

Probando Pentaho III: Introducción a Pentaho CTools

jueves, 5 de septiembre de 2013

Encontré un muy buen documento (Introducción...) que me ayudó a sintetizar todo lo leído y probado respecto la construcción de Dashboards con CTools. Comparto mi traducción y síntesis:

Pentaho CTools es un framework para crear y mantener dashboards en la versión Community de Pentaho business intelligence server (bi-server)

Una de sus características relevantes es la creación de dashboards interactivos, integrados con el bi-server. Todos los datos disponibles se pueden visualizar, aprovechando la configuración de seguridad del bi-server de Pentaho.

Está compuesto por:

1. Community Dashboards Framework (CDF)
2. Community Chart Components (CCC)
3. Community Data Access (CDA)
4. Community Dashboard Editor (CDE)

1. CDF: motor generador de dashboards. Estos dashboards están formados por COMPONENTES, conectados entre si.

Componente: es un objeto de javascript que encapsula otros objetos con propiedades y funcionalidades. Puede ser visual o no. Tienen interacción entre ellos, la más básica es que un componente puede re-dibujarse a partir del cambio de una variable.
Se puede customizar su comportamiento.

2. CCC: componentes gráficos que permiten la interacción del usuario,  basados en Protovis Raphaeljs


3. CDA: componente diseñado para recopilar, compaginar y distribuir información desde diferentes origenes.

Aunque CDF puede acceder a consultas SQL y MDX directamente, recomiendan el uso de CDA por asegurar accesos seguros, permitir joins de datos desde diferentes fuentes, exportar los datos de las queries fácilmente. También habilita la definición de las data sources y queries de SQL del lado del server. De esta manera, CDA disminuye el riesgo de inserción de código malicioso por medio de SQL injection (cuando la query esta almacenada del lado del cliente)

4. CDE: Editor que permite crear dashboards siguiendo estos pasos

    1. Crear el layout o presentación de la página.
    2. Especificar los data sources con la información a mostrar.
    3. Crear los componentes visuales específicos. Conectarlos a los datos y ubicarlos en el layout.
    4. Introducir más flexibilidad parametrizando los componentes y logrando interacción entre los mismos.

A continuación una descripción de las secciones de Layout, Components y Data Sources ...

Layout workspace

Formado por un área de estructura y otra de propiedades, relacionadas entre sí.




Layout Structure :

El layout mas simple esta formado por tres filas: Header, Contents y Footer.
Para modificar este layout, se pueden agregar columnas, filas, espacios, bloques de html, imágenes. Bloques de javascript.
Hay que tener en cuenta que las filas y columnas generadas están mapeadas a una estructura de <div> anidados, dentro de un archivo html generado en forma dinámica por el pentaho-CDE-plugin.

Properties:

Hay una lista de propiedades, describo las principales.
Nombre del elemento: se usa después para ubicar dentro del mismo los componentes gráficas.
Tamaños: toma blueprint css’ stylesheets. 'Width' se basa en las columnas de blueprint. 
Se puede ajustar, pero es mejor que estos tamaños sean dados por el componente en si.
Si los tamaños sumados de todos las columnas exceden el ancho de la página, tomarán la fila siguiente. Por otro lado, con blueprint los 'Heigths' son definidos por las alturas de lo que contiene, por eso, si una columna está vacía, queda invisible porque su altura es de 0 px.
Seleccion de color: área de color y saturación, pueden ser configuradas por el selector de colores.

Data source workspace



Hay once tipos de datasources, de los cuales probamos SQL Queries y MDX queries. 

Se puede seleccionar el acceso via JDBC ó JDNI.
Se recomienda acceder por JDNI en los casos en que se quiera acceder a mas de una tabla. Otra ventaja es que para setear JDNI se necesita solo el nombre de la datasource.
Dentro de las propiedades, se puede seleccionar un origen de datos creado anteriormente por Pentaho.
Al ingresar la consulta, se recomienda controlar la sintaxis de las consultas SQL o MDX en otro entorno. Un error en la consulta no se detecta fácilmente desde CDE.
También es útil probar la datasource creada por medio del Preview de CDA
Hay que guardar las modificaciones al datasource en cada cambio, y limpiar el cache de la CDA, entre una prueba/ corrección y prueba
Tener en cuenta que el cache del repositorio no es el mismo que el cache de la CDA.

Component workspace


El concepto de componente intenta simplificar la construcción de dashboards. Es un objeto de JavaScript que encapsula todas las propiedades y métodos. 

Destacamos:
  1. Genéricos: simple paramenter (javascript parameter), custom parameter(arrays, objetos, funciones), date parameter. Parametros con su inicialización, se usan para conectar los componentes entre si
  2. Scripts: funciones de javascript
  3. Otros. Usamos los botones, tablas.
  4. Charts: los componentes para gráficos específicamente. Pie chart, line chart, bar chart
  5. Selects: componentes usados para seleccionar valores. Permiten la interacción del usuario, desde text inputs hasta combos.
  6. Custom: Raphael component: Raphaeljs es una librería para Scalable Vector Graphics (svg).

Propiedades  de los componentes:
Cada tipo de componente tiene propiedades específicas, pero hay algunas comunes a todos que se pueden usar para controlar el ciclo de vida y comportamiento. Este cuadro resume el ciclo de vida de un componente y permite entender el sentido de las distintas propiedades.

















- executeAtStart: una variable booleana o (función que devuelva booleano). Indica si el componente será ejecutado (renderizado) en el load del dashboard o no.

Parameters: array de parámetros a pasar al componente, en general basados en el input del usuario. Permiten customizar (al data source que está detrás)
- Parameter: Parámetro de salida de la función 
Listeners: array de parámetros que disparan la ejecución y renderización del componente.
- PreExecution: función ejecutada antes de la inicializar o actualizar el componente. Si la función devuelve False, el componente no se actualiza.
- PostExecution: función que se ejecuta después del update del componente y se puede usar para indicar que la actualización terminó.
PreChange: function(v), siendo v el nuevo valor del componente. Tiene sentido para componentes de tipo selector, para validar los inputs. Si esta función devuelve F no se ejecuta el evento 'fireChange'
PostChange: se ejecuta después del cambio.
Click action: Si la  CCC charts es clickable ( Clickable = true), se ejecuta una función cuyo prototipo es:
function(s, c, v) { <body> }, cons = label of the seriesc = category label (value at the x-axis)v = value (value at the y-axis)

El uso más común de esta función es modificar el valor de un parámetro por medio de   Dashboards.fireChange(param, value). Pero se pueden crear interacciones más complejas con un popup, por ejemplo. Que permitan que el usuario tome distintas acciones.


-Height - Width: usar solamente si al ubicar el componente dentro del layout no se ajusta a lo 

que necesitamos.
-Datasource: la cda datasource definida antes.
-HtmlObject: es el id del html del layout, definido antes, que será reemplazado por el componente.
-Listeners: qué parámetros definidos previamente,  disparan el cambio del componente
- Priority: por default 5, si es menor el componente se ejecuta primero. Se usa en los casos en que se quiere dar un orden de ejecución.
-Cross tab mode y series in rows
están relacionados con la estructura del dataset y con la información a mostrar.

Cross tab mode: si la consulta generada esta compuesta por series y categorías, en general si la consulta es MDX o una SQL con la clausula group by.
Series in rows: determina si las filas corresponden a las series o no.
If series in rows = false los datos deben venir como Serie, Category, Data. If series in rows =
true deben ser Category, Serie, Data.

Si crosstab mode = False los column headers (nombres) no son parte del dataset, por ende no serán visibles en el dashboard.




-Extension points:

Permiten setear el font family, font-size, text-orientation de los distintos componentes de texto del chart. Se forman como 'ItemTipo_propiedad', por ejemplo titleLabel_font.

Cuadro con ItemTipo más usados,  propiedades y ejemplos de valores para las propiedades






Artículos relacionados:

Probando Pentaho I (Instalación de Pentaho Community)
Probando Pentaho II (Dashboard de ejemplo)


 









Leer más...

Incidencia de las TIC en la gestión del Capital Humano

En estos últimos años venimos acompañando a los departamentos de RRHH de algunos de nuestros clientes, que buscaban incorporar tecnología en varios de sus procesos comunes (evaluaciones, comunicación, búsquedas internas, promociones, capacitaciones, outplacement, etc..)

Esto no se debe a un movimiento aislado sino a la influencia que las TIC (Tecnologías de la Información y Comunicación) vienen teniendo desde hace años en todas las áreas de la compañía, y particularmente destacable, en la gestión del Capital Humano.

Las TIC engloban a un sector de actividad donde se aplican en conjunto dos tipos de tecnologías: las TI (tecnologías de la Información) y las telecomunicaciones, con el objetivo de administrar y transformar la información, protegerla y recuperarla para analizarla desde distintos enfoques.

Para poder entender los efectos positivos que la aplicación de las TIC puede acarrear es necesario tener en claro que "tecnología" no es sinónimo de "producto" (un software en particular) sino de un concepto mucho más amplio. La implementación de la tecnología lleva a nuevas formas de colaboración, desarrollo de nuevos conocimientos, organización del trabajo, y en el caso del área de RRHH, exige nuevas capacidades de parte de sus responsables.

Justamente parte de esas nuevas capacidades implican, entre otras cosas, una evaluación estratégica de la tecnología a usar, teniendo claro que para el desarrollo de dichas capacidades es fundamental el apoyo de la alta dirección de las empresas.

En qué aspectos ayudan las TIC al sector de RRHH?

  • En la comunicación, por supuesto
  • En el diseño de puestos y roles
  • En la supervisión
  • En la detección de la duplicidad de trabajo
  • En la detección de tareas que se pueden tercerizar
Si bien, en muchos casos la tecnología, aún hoy, no se reconoce como un agente de éxito en el área de RRHH, es innegable el rol que cumple en la mejora de procesos de negocio, y como consecuencia, en la productividad.

Objetivos

El objetivo de las TIC como concepto global es el de agregar valor a la operación diaria. Cualquier estrategia de aplicación de tecnología de la información en la gestión del capital humano debe permitir a la organización, entre otras cosas:
  1. Centralización y gestión de toda la información de la compañía y su análisis en tiempo real
  2. Gestión y evaluación de desempeño
  3. Mejora de la motivación de los empleados a través de una comunicación más abierta y fluida
  4. Mejora de la información interna y del acceso a la misma, promoviendo la cultura corporativa
  5. Que el área de RRHH pueda enfocar sus esfuerzos en decisiones estratégicas, al quedar liberados de otras cuestiones rutinarias que insumen tiempo y esfuerzo
  6. Reducción de costos y tiempos con la automatización de procesos, eliminación del uso de papeles en muchas operaciones y la gestión del tiempo
Procesos como Audit Management o Knowledge Management, por ejemplo, son factibles de aplicación de tecnologías a través de diversas aplicaciones.

Encontramos también herramientas para e-recruitment (búsqueda de canidatos a través de la web corporativa, por ejemplo), e-learning, B2E (businees to employe), administración de Intranets (de código abierto, pagas o a medida).
Las redes sociales juegan un papel muy importante hoy en día en la comunicación interna de las empresas y distintos modelos de teletrabajo son también incorporados en búsqueda de reducción de costos, flexibilidad, retención de empleados, mejoras en productividad, entre otros beneficios.

El enorme valor que estas tecnologías ofrecen hace que estén presentes en casi todas - si no todas - las actividades sociales y económicas en cualquier tamaño de empresa. En el caso de la gestión de capital humano no hay que perder de vista que, más allá de aplicar y saber usar las herramientas necesarias de la mejor forma, las tecnologías deben incidir positivamente en la vida de las personas.

Artículo relacionado:
Las redes sociales dentro de la empresa

 




Leer más...

SCRUM, problemas en la reunión diaria: qué podemos hacer al respecto?

martes, 3 de septiembre de 2013


Internamente muchas veces nos preguntamos si las reuniones diarias están cumpliendo el objetivo que realmente tienen y al leer blogs y foros sobre metodologías ágiles descubrí que muchos equipos tienen los mismos problemas que detectamos puertas adentro.

Revisar objetivos

Para comenzar es bueno recordar cuál es el objetivo y qué debe hacer cada miembro del equipo en una típica reunión diaria.


La reunión diaria tiene como fin el facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.


Cada miembro del equipo participa del trabajo que el resto está realizando (dependencias entre tareas, progreso y problemas) para luego de finalizar la reunión poder hacer las adaptaciones que permitan cumplir con las historias que el equipo comprometió para el sprint en curso.

Cada miembro del equipo debe responder las siguientes preguntas en un tiempo estipulado de como máximo 15 minutos:
  • ¿Qué he hecho desde la última reunión diaria? ¿ Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema?
  • ¿Qué voy a hacer a partir de este momento?
  • ¿Qué problemas tengo o voy a tener para cumplir con este sprint y en el proyecto?
Como apoyo a la reunión, el equipo cuenta con la lista de tareas del sprint (sprint backlog) donde se actualiza el estado y el esfuerzo pendiente para cada tarea. 

Con esto se ponen en evidencia los beneficios y restricciones que tiene cada equipo en realizar sus tareas. 

(Para quienes quieran profundizar recomendamos leer "Scrum y XP desde las trincheras")

¿Problemas? ¿Qué problemas?

Si bien la práctica descripta en el párrafo anterior puede ser muy clara y parecer muy simple, nos pasa que, con el correr del tiempo notamos que hay cosas que empiezan a fallar o a sacarnos del eje de lo que indican los libros. ¿Cuáles son esas cosas? Aquí listamos algunos ejemplos de situaciones que pueden presentarse en las reuniones diarias y que pueden ser tratadas durante la misma, así como también recomendaciones recopiladas entre experiencia propia y de otros:


1. Algún miembro del equipo se queda sin tareas dentro del sprint
  • Que él mismo elija qué cosas puede hacer para ayudar al equipo (test, documentación, scripts, etc.)
  • O decidir entre todos que ayude con otros tipos de tareas, por ejemplo que sea el cadete del grupo. 

    2. Falta tiempo para corregir código o hacer una corrección que no produce historias válidas dentro del sprint.
    • Bajar el rendimiento del equipo, para poder dedicarle el tiempo suficiente a las tareas de mejoras o correcciones, es decir, plantearse hacer menos historias para el sprint.

    3. Ante un proyecto grande con muchos desarrolladores
    • Cuando la cantidad de personas en un proyecto es grande, se dispersa mucho la información, lo ideal es armar varios grupos más pequeños de entre 3 y 10 desarrolladores.
    • Si hay varios equipos en el mismo proyecto , lo más recomendado sería, un solo project owner (dueño del proyecto), sprint sincronizados para que las demos sean el mismo día, la planificación unificada para repartir las historias y luego cada equipo hace su propia planning poker. Hacer en diferentes horarios las reuniones diarias, para que el project owner esté en todas. La gran ventaja de esta experiencia es que cuando termina cada sprint los miembros del equipo pueden ser intercambiados, o reorganizados minimizando así las dudas y/o problemas. 

    4. Llegadas tarde a la reunión diaria
    • Elegir una hora buena para todos ( en la generalidad de los casos, se toma como horario de la reunión diaria, entre 15 y 30 minutos posteriores al horarios de inicio de la jornada).
    • Si los retrasos son habituales se puede "llenar la alcancía", "traer algo para compartir para todos". Ante la reincidencia eligen hacer que duela un poco más el bolsillo y así tratar de evitar llegar retrasado.  
    • Llegar tarde se puede deber al desinterés, con lo cual es válido plantear como alternativa que el propio implicado en los sucesivos retrasos puede exponer sus propias explicaciones ante el grupo y/o alternativas de participación para aumentar su interés. 
    • Contar o no qué paso en la reunión o a los que no estuvieron presentes, depende de dos puntos de vista, el interés de escribir en una breve "minuta" sobre lo hablado por el project owner y el otro punto de vista el interés del integrante retrasado en interiorizarse en lo sucedido en la reunión diaria. 

    5. Equipo distribuido geográficamente
    • Skype, o cualquier vía de comunicación on line conectado permanentemente, reunión diaria del equipo completo, comunicación lo más fluida posible (skype, cámaras web, mail, de ser necesario palomas mensajeras!!!)

    En forma anecdótica podemos decir, que en Tercer Planeta, hemos intentado varias de estas recomendaciones, algunas con funcionamiento óptimo y otras en vías de mejoras seguras. 
    La más importante que hacemos es la de realizar una reunión diaria del grupo completo, ya sea que pertenezcan o no al mismo proyecto, contándonos en qué estamos cada uno y pidiendo todos los S.O.S. necesarios, esto permite que ninguno de los proyectos quede estancado, reconociendo que no todos sabemos todo. Además de poder contar con ayuda, podemos saber en qué estado está cada uno. A esta reunión diaria grupal general, muy cortita, le siguen las reuniones diarias específicas de cada proyecto en concreto (reuniones de avance). 

    Personalmente, la primer reunión diaria es la más saludable y a veces hasta la más esperada por todos, nos permite entender el estado de cada uno, estar al tanto de temas generales del equipo y temas más sociales. Es una manera de mantener la comunicación "viva", más allá de los detalles particulares que presente cada proyecto. 

    Leer más...

    Conceptos sobre Cloud Computing

    lunes, 26 de agosto de 2013

    El Cloud Computing tiene como objetivo la oferta de recursos y servicios - de negocios y de tecnología - en ambientes escalables, adaptables y flexibles. Es decir, "la Nube" sostiene la idea de que el almacenamiento y la administración de la información se manejen sobre Internet aprovechando la oportunidad de tener redes de servidores, centros de datos, servicios, etc. diseminados en la enorme extensión de la web.

    A quiénes está dirigido?


    Este modelo de prestación de servicios y tecnología ofrece una variedad tan amplia de productos y aplicaciones que puede ser usado tanto por grandes corporaciones, pequeñas y medianas empresas, instituciones educativas, entre otros, e incluso particulares.

    Con esto se apunta a que cualquier tipo de usuario tenga acceso a una serie de servicios estandarizados para utilizar según sus necesidades, en forma totalmente flexible y pagando sólo por el consumo efectuado, ahorrando además en los costos de equipos, mantenimiento, actualización de los mismos, personal que los administre, licencias, espacio físico, etc..


    De qué se trata


    El modelo de Cloud Computing se afirma sobre 3 patas:

    1. Software - Software as a Service (SaaS): la Nube ofrece una serie de aplicaciones del tipo "Software como Servicio" que los usuarios pueden consumir a través de Internet. Este concepto existe desde hace tiempo y se trata de cualquier servicio que se base en la web, como podría ser el webmail de Gmail o los típicos CRM, por ejemplo. En este caso el usuario consume los servicios que necesita y es el proveedor el encargado del desarrollo y mantenimiento. El cliente puede decidir en todo momento qué aplicaciones usar y qué tipo de servicio contratar. Algunos servicios pueden ser gratuitos (esto depende del proveedor) pero en el caso de aplicaciones pagas, el costo varía según el tiempo de uso, volumen de información, usuarios, tipo de servicio, etc..
    2. Plataforma - Platform as a Service (PaaS): algunos describen a la "Plataforma como Servicio" como un modelo donde están dadas todas las condiciones que necesitan los desarrolladores para la construcción integral - testing, almacenamiento de datos y documentación, administración de versiones, backups, etc.- e instalación de sus aplicaciones o servicios web. Es decir, todas las herramientas necesarias para el desarrollo de software se encuentran alojadas en la web y el desarrollador accede a las mismas desde cualquier browser. Un ejemplo claro de PaaS puede ser el Google App Engine.
    3. Infraestructura - Infraestructure as a Service (IaaS): la infraestructura como servicio se refiere a una forma de distribución del equipamiento pensada como servicio. O sea, existen proveedores de equipamiento en la Nube que prestan servicios de hardware o infraestructura, en general, en base a plataformas de virtualización. Cualquier usuario puede "alquilar" los servicios de CPU, RAM, Sistema Operativo, redes, Firewall y todo lo que necesite que mejor se adapte a sus necesidades en cada momento. El dueño de esa infraestructura es el proveedor de dicho servicio y él se encarga del mantenimiento, administración y buen funcionamiento de lo que ofrece.

    Buenas y Malas


    Dos de los principales beneficios del Cloud Computing son, sin duda alguna, la simplicidad y la baja inversión requerida para comenzar a trabajar. Y podemos también enumerar estas otras ventajas:

    • Rápida implementación, en general los tiempos para empezar a usar cualquier servicio que se contrate son muy cortos
    • Actualizaciones automáticas e independientes de los recursos propios, a cargo de los proveedores de los servicios. 
    • Fácil integración con otro tipo de aplicaciones
    • Menor riesgo ante "caídas" de los servicios
    • Movilidad, por la posibilidad de acceder a los servicios desde cualquier punto y en cualquier momento
    • Adaptable a necesidades estacionales de los distintos negocios
    • Uso eficiente de la energía, que permite, por un lado, bajar costos que requiere el funcionamiento de una infraestrucutra propia, y por otro lado, reducir el desperdicio de la energía al contar con sistemas centralizados 
    (Imagen tomada de http://www.zdnet.com/blog/hinchcliffe/eight-ways-that-cloud-computing-will-change-business/488)

    Ahora bien, a pesar de los muchos beneficios que nos muestra este modelo no son pocos los que ponen el ojo en las desventajas y riesgos que puede acarrear:

    • La disponibilidad y estabilidad del acceso a Internet sigue siendo un problema en algunas zonas
    • Existe un riesgo de vulnerabilidad de la información al "sacarla" de las instalaciones propias y "entregarla" al proveedor elegido
    • Los niveles de seguridad crecientes que deben implementarse pueden afectar la velocidad de respuesta a los requerimientos
    • Asi como los proveedores de los servicios son los responsables de su mantenimiento y mejora continua, los usuarios de los mismos dependen absolutamente de ellos sin poder hacer nada en caso de interrupciones imprevistas de las prestaciones contratadas
    • Muchos dudan sobre cómo afectará a la efectividad de los servicios expuestos el aumento de la cantidad de usuarios y el tráfico creciente
    • Y el punto más debatido respecto del modelo de la Nube reside en la seguridad de la información. Hay quienes incluso recomiendan no confiar los datos más sensibles al universo del Cloud.

    Aún así y dada la flexibilidad de esta plataforma siempre existe la opción de llevar un esquema mixto de trabajo entre cosas que pueden consumirse desde la nube sin mucho riesgo y otras - las más críticas - que puedan mantenerse en las propias instalaciones.

    Artículos para recomendar:

    Eight ways that cloud computing will change business


    Leer más...

    Por qué estimar con puntos y no con horas?

    martes, 6 de agosto de 2013

    Cuando comenzamos a introducirnos en la práctica de Scrum muchos nos preguntamos por qué es mejor hacer las estimaciones basadas en puntos que hacerlas basadas en horas. No existe acaso una relación directa entre ambas medidas?


    La gran mayoría de los expertos en el tema coinciden en que la respuesta a la segunda pregunta es NO.


    Story points
    Los puntos en Scrum son un reflejo del riesgo y la complejidad que cada miembro del equipo puede percibir sobre una historia, mientras que las horas asignadas a esa misma historia son una estimación absoluta, basada en forma casi exclusiva, en la experiencia previa.

    La estimación con puntos es lo que usualmente se denomina "estimación relativa" y tiene como principal objetivo el agrupar cosas de similar medida en vez de darles a cada una una magnitud categórica y terminante.

    Una de las ventajas de dimensionar las historias a través de puntaje es que nos permite mirarlas desde 3 ángulos distintos:
    • complejidad
    • esfuerzo
    • duda - representada por las cosas que no sabemos si van a poder ser hechas o que no sabemos cómo van a ser encaradas porque incluyen factores con cierto grado de incertidumbre -

    El medir una historia con puntos permite encarar un aspecto diferente de la estimación: cuando preguntamos "cuántas horas va a llevar una historia?" el número dado como respuesta está pensado, en la gran mayoría de los casos, sólo según la experiencia anterior. En cambio, el pensar una medida en puntos permite relativizar los 3 aspectos mencionados antes y compararlos contra las estimaciones hechas para otras historias dando la posibilidad de ajustar y afinar dichas estimaciones a cada paso. Estos ajustes son normales cuando recién comenzamos a usar esta forma de "medir".

    Otro aspecto positivo es que esta técnica permite a todo el equipo estar involucrado. La decisión de qué valor darle a una tarea ya no depende exclusivamente de quien va a desarrollarla sino que todos los participantes deben aportar su punto de vista respecto de los 3 aspectos enumerados. Las distintas visiones  al estimar una historia permiten a los miembros entender cuestiones que podrían no ser tenidas en cuenta en forma individual.

    Algunos opinan además que las estimaciones por puntos no llevan la "carga psicologica" que tiene la estimación por horas, con el impacto negativo que puede llegar a provocar en alguien que excede el tiempo previamente estimado para terminar una tarea.

    Una forma sencilla de comenzar a pensar en puntos


    Planning Poker
    Planning Poker cards
    La forma de estimar es uno de los cambios más grandes al que tenemos que hacer frente cuando empezamos con la práctica de Scrum y puede ser muy frustrante no encontrar la manera de hacer ese "click" de dejar de pensar en "tiempo" para pasar a pensar en "puntaje".  Cuando comenzamos a implementar esta técnica en Tercer Planeta, alguien nos recomendó arrancar con estos pasos, y realmente nos fue muy útil:

    1. Elegir un par de historias de nivel medio en complejidad, historias "conocidas" o "repetidas" en cualquier tipo de aplicación.
    2. Asignarles puntos de las cartas (la serie de Fibonacci reflejada en las cartas de Planning Poker)
    3. Estas historias elegidas pasan a ser entonces "historias de referencia" para puntuar el resto de las historias
    4. Luego, asignar puntos al resto de las historias, basándonos en puntajes relativos a los puntos asignados a las "historias de referencia": las historias que parezcan más complejas o más grandes que las de referencia recibirán puntajes más altos.

    Al final de la estimación se suman los puntos de las historias para tener una dimensión total del sprint. Después de completar un par de sprints se podrá tener una idea más certera de cuántos puntos puede hacer el equipo en cada iteración, lo que determina la "velocidad" de ese equipo.

    A partir de esto las estimaciones por puntos se harán cada vez más naturales y se irá mejorando la técnica hasta llegar a dejar de pensar en el reloj al momento de medir las entregas en cada intervalo.


    Para leer más:
    Story points vs. development hours
    Sobre Ratas, elefantes y timeboxing








    Leer más...