Jornadas Anuales Versión 2010

miércoles, 24 de noviembre de 2010

Acercándonos a diciembre, todos nos encontramos planificando reuniones y despedidas.
Nadie deja de celebrar de alguna manera el cierre del año. Fiestita, happy hour, eventos de todo tipo y color. También evaluaciones de objetivos, controles de desempeño.

Nuestra empresa no escapa a la tradicional costumbre, pero dándole un toque distintivo. No nos conformamos con un simple brindis ni con el animador de turno. Tampoco queremos terminar el año sin hacer una retrospectiva del mismo.
Por eso es ya una obligación escaparnos de la vorágine laboral hacia algún punto turístico. Playa o campo, lo importante es compartir un mini break con la gente de la oficina. Queremos hacer un preview de las vacaciones y simultáneamente repasar el trabajo de los últimos meses.

Con este espíritu nos encaminamos este año hacia La Posesiva, un antiguo casco de estancia en Capilla del Señor dedicado ahora al turismo. Lo primero que se nos propuso en la charla inicial al llegar fué detenernos un poco y disfrutar del lugar, como premio a un año difícil y de muchísimo trabajo.
Empanadas, asado, alguna jineteada, ping pong y por supuesto metegol! Todo esto para lograr concentrarnos en el tarea de descansar y divertirnos.

Todo este despliegue de tiempo libre suscita más de un resquemor. No deberíamos estar evaluando los objetivos de la empresa? Cuáles fueron los puntos débiles del trabajo del año? Cómo estuvimos en comunicación?
Mejoramos en la implementación de las nuevas tecnologías? Pues bien, este año la consigna fue 'no hablar' de todo esto. Simplemente descansar, olvidarnos de las presiones diarias y pasar un buen rato.

Después de todo un día sin 'hacer' nada, la llegada de Carola Herrscher una de nuestras coach de Nuevas Miradas, parecía el momento de corte para empezar a hablar de algo serio. Reunidos el viernes a la mañana, nos propuso jugar a 'El teléfono descompuesto'. Contar una historia a un integrante, y esté debe representársela a otro. Este último a su vez re actúa lo entendido para un tercero. Finalmente el que termina debe explicar con palabras el cuento original a toda la audiencia.

Después de divertirnos un rato comprobando nuestras dotes actorales,terminamos el juego, tratando de descubrir algún mensaje o metáfora. Pero esto fué tarea para cada uno. Caro simplemente condujo. No dijo nada ...

Segundo juego : las manos en la masa!
Arcilla. Una buena hora para desarrollar capacidades creativas. Por cierto muy enterradas o inexistentes en algunos, increíbles en otros. Pero faltaba lo mejor: romper todo lo hecho! Seguir el trabajo de otro! Volver a empezar otra obra! Finalmente ... la construcción de la casa entre todos. Cada uno armó algo, todos aportamos y nos dimos cuenta de lo difícil que es armar algo coherente sin ponernos de acuerdo y planificar antes ... En fin, nuevamente Caro dijo poco, pero todos nos divertimos y no nos dimos cuenta que habíamos pasado toda la mañana trabajando.

Mientras todos jugábamos, Andrea y José trabajaban intensamente. Dedicaron un buen rato de su tiempo para charlas individuales con cada uno. La idea de estos encuentros es hacer una especie de 'evaluación de desempeño'. Con su estilo directo y sencillo, nos ayudaron a ver los logros. Que por cierto no son pocos, hacia afuera y dentro de la empresa. Con tanta asertividad, lograron que cada uno se propusiera buenas metas para el 2011 ...

Conclusiones después de estos dos días?

Qué difícil es no hacer nada 'serio' y no hablar de nada filosófico!
Es raro no evaluar, corregir ni planificar. Pero qué importante es conocer a los otros desde otra óptica. Respetar este tiempo de silencio. Darnos cuenta que en la acción conjunta está el valor, y que el ver a otros de una manera distinta enriquece al grupo y a cada uno.

Después de un año de trabajo intenso con el tema de la comunicación, la integración y profundizando en distintas metodologías de trabajo este corte 'formalmente informal' fue más que positivo.

Que es repita!!!


Leer más...

Visitando Giran

lunes, 8 de noviembre de 2010

A principios de este año fue lanzado internamente en Tercer Planeta, la iniciativa "PAI".
PAI no implica nuestra conversión a la religión Umbanda, sino que se trata de las siglas Profesionalismo, Apertura e Intercambio.
Sin entrar en demasiados detalles, cómo parte de esta iniciativa incurrimos en muy diversas acciones, por ejemplo:


PAI Mercosur


La presentación de esta iniciativa en las oficinas de Tercer Planeta se realizó a principios de este año, mientras yo me encontraba trabajando de forma remota desde Vitória, Brasil, asi que asistí via Skype a este anuncio (empanadas acá, suco de manga allá), así fue que tuve la idea de coordinar algun tipo de intercambio con una empresa de la ciudad donde me encontraba, asi fue como buscando en algunos eventos de la comunidad ágil de la región encontré una empresa que se posicionó como referente en metodologías ágiles de Espirito Santo (estado del sudeste brasilero), Giran

Turismo Ágil

Me puse en contacto con la idea de hacer una visita similar a las que hemos hecho con otras empresas cercanas, con el fin de intercambiar algunas ideas, y muy cordialmente me invitaron a visitarlos, lo que finalmente pude concretar el mes pasado.


View Larger Map

Giran es una empresa muy joven (cumplieron un año recientemente) y nació como una empresa enfocada no sólo en la práctica, sino también en la enseñanza y mentoring de metodologías ágiles, especialmente SCRUM + XP. Por lo cual mi visita, como supuse, fue muy fecunda.

Por el lado tecnológico usan en sus proyectos (y enseñan) Java, PHP y Ruby on Rails.

El primer día que los visité se encontraban en medio de un sprint bi-semanal, con lo cual pude asistir, luego de
la charla técnica de la semana, a la reunión diaria y parte del desarrollo. Me recibieron muy amablemente y son muy divertidos :), por supuesto, no sólo es un equipo ágil de geeks, además son brasileros!.

Finalmente asistí a la retrospectiva de ese sprint, el cuál resulto ser un sprint con varios imprevistos, lo que hizo más interesante mi visita :)

Me llamó la atención la ausencia total de "roces" o comentarios CYA entre miembros del equipo (esperables en un sprint accidentado), y como todos los integrantes se mostraron muy involucrados en la mejora contínua del proceso SCRUM, admirable.

De la visita me quedo con una grata experiencia y varias ideas interesantes que observé, sin duda tenemos mucho por aprender y enseñarnos, queda la puerta abierta para futuros encuentros.


Con parte del equipo de Giran en sus oficinas

Leer más...

Trabajo en background

BackgroundWorker


Durante la construcción de una aplicación es habitual encontrarnos con procesos que son muy lentos y no dan feedback al usuario. A continuación les mostramos una de las formas de resolverlo utilizando un control que nos brinda .Net a partir de su versión 2.0: el BackgroundWorker.

Caso de Uso

Una de nuestras aplicaciones tiene una pantalla donde se muestran filtros para obtener un informe que finalmente se graba en un archivo con formato Excel. Anteriormente, cuando el usuario apretaba el botón para iniciar el proceso, la pantalla se quedaba congelada hasta que la búsqueda de datos terminaba. En ese lapso de tiempo no se podía saber que estaba pasando: si se debía seguir esperando, o todo había dejado de funcionar. Aún informando “el proceso puede demorar”, después de unos instantes la aplicación comenzaba a mostrarse con el alerta de “(No Responde)”  y el usuario ya no sabía si seguir esperando, cancelar la ejecución de la aplicación, o en el peor de los casos reiniciar la computadora.

Por qué la decisión de usar el BackgroundWorker

Al comprobar que la performance de la búsqueda ya había sido optimizada desde el motor de bases de datos, llegamos a la conclusión de que debíamos hacer algo para que la aplicación no quede inutilizable mientras se genera el reporte. Sabiendo que lo más importante del reporte  es el resultado final, decidimos hacer todo el proceso de búsqueda de los datos  en un segundo plano y así lograr que la aplicación siga funcionando sin inconvenientes, incluso para realizar otras tareas que necesiten utilizar al mismo tiempo la base de datos de la que estoy esperando la respuesta para el reporte inicialmente deseado.
A pesar que no es ampliamente configurable y adaptable a todo tipo de necesidades, como podría serlo una solución que maneje varios hilos de ejecución desarrollada manualmente, el BackgroundWorker tiene una serie de ventajas muy prácticas para nuestra necesidad en particular y nos evita, entre otras cosas, planear la solución ideal para el problema y escribir “bastante” código para manejar hilos de ejecución lo cual es sumamente delicado ya que debemos tener en cuenta el ciclo de vida de cada hilo (y no perder ninguno en el camino),  la comunicación entre distintos hilos de ejecución, validar y manejar posibles errores, etc..
Todo esto sumado a que solo necesitamos realizar una única tarea indivisible, que consume mucho tiempo y no podríamos mejorar eso con más hilos de ejecución nos llevó a tomar la decisión de inclinarnos por el BackgroundWorker.

Manos a la obra

Veamos cómo en pocos pasos y sin mucho esfuerzo podemos obtener una aplicación que utilice varios hilos de ejecución.
Inicialmente nuestro código lucía así.  


image

Lo primero que debemos hacer es agregar un control BackgroudWorker en el designer del form y configurar los eventos a usar.  Básicamente en nuestro ejemplo utilizamos dos:


 BackgroundWorker, RunWorker

DoWork : Evento lanzado desde el código para realizar las tareas asincrónicas
RunWorkerCompleted : Evento lanzado por el control una vez finalizada la ejecución de las tareas asincrónicas.
Una vez hecho ésto lo único que resta hacer es reorganizar el código:



BackgroundWorker, RunWorker

Si observan con atención al hacer clic en el botón  invocamos al método RunWorkerAsync que se encarga del manejo de hilos y realización de tareas en background lanzando el evento DoWork.
Antes debemos verificar que el control no se encuentre trabajando actualmente, de esta forma evitamos un error.


BackgroundWorker, RunWorker

En el evento DoWork indicamos cuáles son las tareas que se ejecutan asincrónicamente, en nuestro caso hacemos el llamado a la base de datos.



BackgroundWorker, RunWorker

Vale aclarar que contamos con la opción de pasar como parámetro un objeto a través del RunWorkerAsync que es recibido dentro del DoWorkEventArgs. Esto puede ser de utilidad si necesitamos tener acceso al estado de objetos definidos en nuestro primer hilo de ejecución.  

Finalmente en el evento RunWorkerCompleted colocamos todas las tareas que  debemos realizar una vez que se ejecutaron todas las tareas asincrónicas. En nuestro ejemplo, como ya obtuvimos los datos debemos generar el reporte


image

Conclusión:

El BackgroundWorker nos brinda la posibilidad de que nuestras aplicaciones WinForms sean más “ágiles” y luzcan más “veloces“ en la realización de tareas que demandan demasiado tiempo, siendo además su implementación muy sencilla.
Leer más...

Intercambiando experiencias

martes, 14 de septiembre de 2010

Parte del valor agregado de la empresa es su preocupación (o mejor dicho ocupación) por ensayar cosas nuevas, siempre probando las ultimas tecnologías y metodologías.
Uno de los objetivos que nos impusimos para este año es abrir Tercer Planeta al mundo. Es decir, intentar dar a conocer más lo que ocurre acá adentro (las prácticas que utilizamos, los experimentos técnicos y los problemas con los que nos enfrentamos) y al mismo tiempo poder aprender de las experiencias de otros grupos de desarrollo. Para esto nos propusimos varios hilos de acción, entre ellos escribir mas seguido en este blog.
Otro hilo, el que nos ocupa en este post, fue armar un encuentro de intercambio de experiencias con el equipo de desarrollo de uno de nuestros clientes.
La idea en este primer encuentro fue juntarnos para que cada equipo presente dos temas que consideraba que era interesante mostrarle al otro. Después de una previa coordinación de temas y logística, encaramos el encuentro con la participación de todos los desarrolladores de cada equipo.

Desarrollo


El encuentro arrancó con un “check in” donde contamos los objetivos del encuentro. Luego cada uno se presentó, esto es importante para desarrollar cualquier charla pero en este caso también fue la oportunidad de conocer la cara detrás de los mails!
Después expusimos intercalando una presentación por equipo.
Nuestro equipo presentó dos temas:
  • Un Sprint en 3p: Armamos una presentación donde contamos las metodologías que aplicamos en un sprint de un proyecto. En la misma mostramos la implementación que hacemos de las reuniones diarias, la planificación, el desarrollo, el uso de los pizarrones, la demo y la retrospectiva entre otras prácticas aplicadas.
  • BackgroundWorker: el uso del control, ventajas y desventajas y los problemas con los que nos enfrentamos al implementarlo. Este control facilita el manejo de distintos hilos de ejecución (próximamente tendremos un artículo del blog que profundice sobre este control)
El otro equipo de desarrollo presentó:
  • Controles customizables: Una muestra de los nuevos controles DevExpress (para mas informacion ver http://www.devexpress.com/) que utilizan y las ventajas para el usuario que traen. Estos controles brindan la posibilidad de que el usuario les cambie los colores, los cambie de lugar, etc., guardando esta configuración para poder tener siempre la aplicación como cada usuario prefiere verla.
  • SpreadsheetGear: El uso de las nuevas clases de SpreadsheetGear (para mas informacion ver http://www.spreadsheetgear.com/) usada para generar reporte en Excel. También nos mostraron algunos agregados que hicieron a estas clases para poder resolver algunos pedidos de los reportes. 
  • Envío de mails: Formas de realizar el envío de mails desde una aplicación, los problemas con los que se encontraron y las configuraciones necesarias.
Todas las presentaciones contaron con momentos de debate y preguntas que sirvieron para enriquecer el intercambio. En esos momentos aprovechamos los conocimientos y experiencias de cada uno, que por suerte son muy diversos, para aportar a las presentaciones y hacer preguntas que ayuden a profundizar los temas planteados.
Al finalizar propusimos armar una retrospectiva en 3 columnas: Lo que me gusto de la charla, lo que me gustaría que pase en la próxima charla y lo que nos comprometemos a hacer para el próximo encuentro. La idea fue tomarnos diez minutos para pensar que cosas estuvieron buenas del encuentro y que cosas nos interesaría profundizar, por ejemplo: temas técnicos (como Silverlight o la velocidad en las páginas web) y otros relacionados con la dinámica de los encuentros. Al final votamos y pusimos objetivos puntuales para un próximo encuentro: proponer distintas metodologías que se pueden utilizar e intentar resolver entre todos algún problema técnico que tenga alguno de los dos equipos en un desarrollo.
En la retrospectiva tuvimos visiones bastante parecidas, varias de las cosas que salieron podríamos agruparlo en lo positivo que fue el conocer las metodologías de trabajo de cada equipo y, por otro lado, lo interesante de ver distintas miradas de un mismo problema.

Conclusión

Lo interesante del encuentro fue poder mostrar los problemas con los que nos enfrentamos y poder aprovechar las diferentes visiones para aportar soluciones.
Es muy interesante ver como trabajan los distintos equipos de desarrollo y como para un mismo problema se encuentran distintas soluciones.
Otro aspecto positivo de estos encuentros es que es muy motivante ya que ayuda a valorar el trabajo que uno hace cotidianamente y a ver otras cosas muy interesantes que uno en el trabajo del día a día no llega a poder profundizar.
También nos ayuda a conocernos más con el cliente y generar una relación de mayor confianza que mejora el trabajo diario.
Leer más...

Aprendiendo un poco más acerca de la Retrospectiva

lunes, 6 de septiembre de 2010

Recientemente leí el libro "Agile Retrospective" de Esther Derby y Lana Larsen. Me resultó interesante, sencillo de leer, lleno de conceptos claros y principalmente, con ideas y consejos para poner en práctica. Está fundamentalmente orientado hacia los que dirigen una retrospectiva, acercándoles herramientas y conocimiento para facilitar su labor.


Al libro lo podemos dividir en dos partes: la primera presenta las habilidades y consideraciones que tendría que tener aquella persona que lidere una retrospectiva; la segunda parte describe algunas actividades que se pueden llevar a cabo durante las diferentes etapas de una retrospectiva.

En este artículo dejo algunas anotaciones que me parecieron mas interesantes y útiles para remarcar, acerca de la primer parte.

Acerca de la retrospectiva

La retrospectiva es una reunión que se lleva a cabo cuando termina un hito (iteración, release, proyecto), en la cual participan los miembros del equipo. Su fin es lograr que los participantes hagan una revisión de lo que pasó, inspeccionen y adapten sus métodos de trabajo y su forma de trabajar como equipo para incrementar la calidad del producto y mejorar el trabajo y la calidad de vida de los miembros.
Algunos puntos importantes para remarcar acerca de esta reunión:
  • Tiene que aportar valor al equipo, así los participantes no piensan que es una pérdida de tiempo
  • Hay que definir su objetivo, para tener una meta a la cual llegar
  • Se tiene que establecer el tiempo de duración y respetarlo

Con respecto a quien lidere la retrospectiva, también citado como facilitador, se destaca:
  • Tiene que entender su rol y las funciones inherentes al mismo
  • Permanece neutral durante las discusiones
  • Maneja la dinámica del grupo, permitiendo que todos participen de igual forma
Acerca del equipo:

  • Identifican sus valores como equipo y los respetan
  • Establecen acuerdos de trabajo (reglas para la colaboración y la convivencia) y son responsables por hacer que todos los respeten
  • Entienden la importancia de su participación en pos de la mejora continua
  • Asumen un compromiso, al finalizar la retrospectiva, para cumplir con lo acordado






 

Estructura de una Retrospectiva

La retrospectiva puede dividirse en 5 fases o etapas:
  • Setear el estado
  • Recopilar datos
  • Profundizar
  • Decidir qué hacer
  • Finalizar la retrospectiva

Setear el estado.
En esta fase el facilitador le presenta al equipo el objetivo de la retrospectiva y la agenda para poner en conocimiento cómo van a invertir el tiempo.

La información que se recolecte lo ayudará a trabajar con el equipo en la elección de un objetivo apropiado. Lo que observe le dará las pistas acerca de qué preguntas hacer y qué problemas podría enfrentar el equipo.

Un objetivo útil ayuda a contestar la pregunta: "¿Cuál será el valor que se obtenga en el tiempo que dure la reunión?" proporcionando una razón para que las personas inviertan su tiempo en la reunión.
Si se define un objetivo amplio ayudará al equipo a que pueda reflexionar y pensar creativamente acerca de sus experiencias y descubrir los puntos de vista que sean importantes para los integrantes.

Evitar los objetivos que definan un resultado específico; por ejemplo, el objetivo "Determinar cómo persuadir a Recursos Humanos para eliminar las evaluaciones de desempeño", bloquea la consideración de otros canales de acción u otros problemas que el equipo esté enfrentando.

Algunos objetivos útiles:

  • Encontrar maneras de mejorar nuestras prácticas
  • Descubrir qué se hizo bien
  • Entender las razones detrás de los objetivos no alcanzados
  • Reconstruir relaciones dañadas
Se le puede solicitar al equipo que describa un objetivo.
En cuanto a la duración, es proporcional a la
cantidad de personas que participan de la retrospectiva y al tiempo transcurrido desde la retrospectiva anterior. Otros factores que influyen son:


  • Complejidad, en cuanto al entorno tecnológico, relaciones entre los miembros del equipo o con departamentos externos, organización del equipo
  • Nivel de conflicto o controversia (planear mas tiempo para tratar temas complicados)
Si el tiempo es extenso, guardar tiempo para recreos entre las distintas etapas de la retrospectiva. También estar atento, durante el desarrollo de la misma, si el equipo necesita descansar unos minutos.

Recopilar datos

Una vez que se conoce el objetivo, se crea una imagen compartida de lo que sucedió en el tiempo que se está evaluando, con esta imagen común, se puede evitar que los participantes analicen según sus propias opiniones y creencias.
Armar la información y eventos en forma visual, para que las personas vean fácilmente patrones y conexiones. Los hechos son una parte de la información, y la otra mitad son los sentimientos, las emociones, éstas dicen lo que es importante para las personas de los hechos y hablan acerca del equipo.

Profundizar

Ahora es el momento de preguntar "¿Por qué?" y comenzar a pensar acerca de soluciones para hacer de forma diferente. Es un momento en que el equipo piensa en conjunto.
Considerar posibilidades adicionales, no quedarse con la primer solución que aparece. Buscar las causas y efectos, y pensar más analíticamente.

Decidir qué hacer

Elegir algunas de las soluciones (2 o 3, no tienen que ser muchas) y planear qué hacer.
Muchas veces el equipo tiene una lista larga de mejoras pero esto puede ser contraproducente ya que tener demasiadas iniciativas pueden abrumar y entorpecer la habilidad para cambiar. El facilitador tiene que ayudar al equipo a elegir los ítems a los que pueden comprometerse y que tengan un efecto positivo.
Una forma de planear los experimentos y los cambios es crear historias o ítems para que puedan ser incluidos en el próximo plan de trabajo de la iteración. Esta es una forma en que se asegure que las personas se comprometan a ejecutar las tareas; sin un compromiso individual, las personas asumen que "el equipo" hará la tarea, y entonces nadie la hace.

Finalizar la retrospectiva

Al completar el plan de acción, terminar en forma clara la reunión. Decidir cómo documentar la experiencia y el plan a seguir.
Lo que se aprende le pertenece al equipo y a sus miembros. El equipo necesita adueñarse de las enseñanzas que consigue.
Antes de finalizar, tomarse unos minutos para evaluar la retrospectiva que se llevó a cabo (sería una retrospectiva de la retrospectiva).

Beneficios de esta estructura

  • Entender los diferentes puntos de vista
  • Seguir un orden natural de pensamiento
  • Tomar una visión comprensiva de los métodos del equipo y sus prácticas
  • Permite que las discusiones vayan adonde se necesita
  • Queda una acción concreta y experimentos para realizar en la próxima iteración.




Dirigiendo Retrospectivas


No se necesita ser un facilitador experto para liderar una retrospectiva, pero sí necesita contar con algunas habilidades básicas. Estas habilidades se pueden aprender, para lo cual es necesario primero entender el rol, practicar y buscar feedback para ir haciendo los cambios necesarios.

Un facilitador de retrospectiva tiene como principal responsabilidad dirigir el proceso, es decir gestionar las actividades, la dinámica de grupo y el tiempo. Él permanecerá neutral durante las discusiones, aún si tiene opiniones firmes o si son temas que le preocupan, ya que si se involucra en las discusiones perderá total atención al proceso.

Los participantes se focalizan en el contenido, discusiones, desacuerdos (pero no desagradables) y toman decisiones; apuntan a un objetivo y manejan sus propios pensamientos, sentimientos y respuestas así contribuyen positivamente a las conversaciones y al resultado.

Si el facilitador, durante la retrospectiva, considera que tiene algo importante que ofrecer, puede contribuir en la discusión, pero antes debe ceder su rol a otro miembro. Una vez ofrecido su aporte, recuperará su rol.

Actividades

En cada una de las fases se puede realizar alguna actividad para crear acuerdos de trabajo, construir una línea de eventos en el tiempo, hacer una lluvia de ideas o priorización, entre otras . Las actividades ayudan al equipo a pensar en conjunto. Será necesario introducir y explicar cada actividad, monitorear su desarrollo y sacar conclusiones al finalizarla.
Puede ser de mucha utilidad armar un guión de la actividad y practicar las instrucciones para recordar qué decir. Tener presente, que como líder de la retrospectiva, es responsable de contestar todas las preguntas acerca de la actividad y monitorearla, centrándose en el nivel de ruido del grupo, mientras trabaja, para tener una pista si las personas necesitan mas tiempo o ya finalizaron.
El sacar conclusiones de cada actividad ayudará al equipo a examinar su experiencia y extraer diferentes puntos de vista.

Manejar la Dinámica del grupo

Está relacionado con la participación de las personas durante la reunión, asegurándose que las personas que tienen algo que decir tengan la oportunidad de decirlo y asegurarse que quien tiene demasiado para decir no domine la reunión.
Otra faceta tiene que ver con estar atento al lenguaje que utilizan los participantes de la retrospectiva. Si éste tiende a culpar a otros, como sucede con el "lenguaje de vos" ("Vos rompiste el build") y con las "etiquetas" ("Vos sos inmaduro"), ésto derivará en que algunos integrantes comiencen a estar a la defensiva. Estas actitudes hieren la retrospectiva, distrayendo la atención de los problemas reales.
El facilitador tiene como función fomentar el lenguaje "Yo", este lenguaje se centra en la experiencia y observación de la persona que habla, en lugar de etiquetar a las otras personas. Al escuchar culpas o críticas, el facilitador tiene que intervenir y redireccionar la discusión.
Otro punto importante en la dinámica de grupo está relacionado con la interacción y las emociones de los miembros del equipo. A pesar que el facilitador no es responsable de las emociones de otras personas, es responsable por mantener una reunión productiva. Esto significa que tiene que estar preparado para manejar situaciones e interacciones emocionales.
En la retrospectiva, lo primordial es la interacción del equipo como un todo, no de individualidades. Esto no significa que se tengan que ignorar las emociones individuales, al contrario, significa tratar con emociones en una forma que sea de ayuda y respeto al equipo y al individuo.
Manejar el tiempo
El facilitador de una retrospectiva tiene que responder a las necesidades del grupo y prestar atención al tiempo para respetar el tiempo fijo, presentado en la agenda de la retrospectiva, en la fase Setear el estado.
Si una discusión, al cumplirse el tiempo estipulado, aún no finalizó y sigue en su punto alto, el facilitador le preguntará al grupo qué desea hacer: continuar con la discusión o seguir a la siguiente fase o actividad. Ésta decisión queda en manos del equipo, no del facilitador. Generalmente, la respuesta es clara para todos; cuando no lo es, se propone limitar la discusión en curso a un tiempo fijo o revisarla luego o en otra retrospectiva.
Dado que el facilitador tiene como responsabilidad que se llegue al objetivo de la retrospectiva (identificar y planear experimentos y mejoras), tiene que estar preparado con actividades extra de diferente duración, en caso que se requiera cambiar por una mas corta.

Manejar al facilitador

Además de manejar las actividades, la dinámica del grupo y el tiempo, cada facilitador tiene que poder manejarse a él mismo.
Estar atento a la dinámica de equipo e interpersonal puede resultar abrumador. No existe una técnica para manejar la dinámica del grupo (aunque sirve tener algunas estrategias). La clave radica en entender y manejar su propio estado emocional y sus respuestas, para poder mantenerse centrado en su responsabilidad.
Cuando las emociones están en un nivel alto, el equipo necesita a alguien que esté fuera de la confusión; esa persona es el facilitador de la retrospectiva. Por lo tanto, tiene que mantener la calma y la claridad durante toda la reunión. Él mismo sabrá si necesita unos minutos de descanso para recobrar su serenidad o para oxigenarse y, de esta forma, pensar con claridad y bajar la ansiedad y tensión. Así, una vez que logre re-centrarse, podrá utilizar alguna estrategia para manejar al grupo y cumplir con su responsabilidad. Tiene que tener siempre presente que no es quien causa las emociones y no es responsable por hacer que todos estén felices y bien.
Es muy práctico que cada facilitador encuentre un tutor, en quien confie y a quien haya visto manejar las emociones en un grupo. Él lo ayudará a ganar confianza y aprender mas opciones para manejar situaciones emocionales. También le brindará el feedback que necesita para mejorar sus habilidades como facilitador.

Opinión personal

Después de haber estado en varias retrospectivas de diferentes equipos, como observadora o participante, leer el libro me ayudó a valorar la importancia del facilitador y de entender la dinámica del grupo. Si bien en las retrospectivas no había una persona que desempeñara ese rol, creo que todos los que participamos nos hicimos responsables de hacer cumplir sus funciones, como si ello fuera nuestro "acuerdo de trabajo" implícito.
El libro me parece de gran interés para aquellos que participan de retrospectiva, no solo para los que actúen de facilitadores. Creo que es útil para entender un poco mas acerca del concepto y de la filosofía detrás de la retrospectiva, y además acerca de la dinámica de la misma y de sus participantes y como cada uno, desde su lugar, puede aportar para darle a la retrospectiva la importancia que tiene.


Leer más...

Debates que enriquecen

lunes, 23 de agosto de 2010

En marzo de este año junto con la gente de Kinética Solutions organizamos en el Club del Golf un evento para compartir experiencias con algunos de nuestros clientes y colegas.

Bajo el nombre WebCrucijadas 2010 y en medio de un “opíparo” desayuno mantuvimos un debate abierto y enriquecedor, tomando como eje principal el análisis de factores que afectan a la toma de decisiones en la implementación de proyectos Web.

Para ello se presentaron 2 casos ejemplo:

Desarrollos convencionales (custom) vs. Integración sobre plataformas existentes

En este primer ejemplo, se comparó el desarrollo convencional de aplicaciones web (soluciones custom, de punta a punta) con el uso de plataformas existentes.

Para eso, Adrián Eidelman de Kinética Solutions mostró su experiencia en la implementación de una solución web montada sobre Community Server, resaltando pros y contras de su utilización.


El modelo WebForms vs. el modelo MVC ASPNET

En el segundo ejemplo, se comparó el modelo clásico de desarrollo de aplicaciones ASPNET (WebForms, WebControls, etc.) con su “challenger” más reciente, el modelo MVC para aplicaciones Web.

Aquí Ricardo D. de Guzmán y Benjamín Eidelman, integrantes de Tercer Planeta destacaron las características conceptuales de cada uno de los dos modelos.

¿Qué nos llevo a hacerlo?

La idea principal del evento fue exponer y escuchar experiencias debatiendo sobre un tema frecuente para quienes nos dedicamos al desarrollo de software, como es el de tomar decisiones sobre este tipo de tecnologías al momento de encarar un proyecto nuevo.

Además buscamos agasajar a clientes y pares, con quienes llevamos recorridos varios años de trabajo conjunto, pero esta vez en un entorno distendido y lejos de las negociaciones propias de un proyecto en particular.

¿Qué nos dejo?

Nos beneficiamos con el aporte de todos los participantes aprovechando los diferentes puntos de vista que ofrecieron desde la diversidad de sus perfiles.

Como experiencia nos pareció muy enriquecedora y recomendable, esperamos poder organizar otra pronto.
Leer más...

Herramientas para trabajo distribuido

miércoles, 18 de agosto de 2010

En el artículo sobre trabajo distribuido comentamos que estamos aplicando ésta forma de trabajo desde el 2009. Por supuesto al principio la implementación supuso varios desafíos, entre los cuales estaban sostener una comunicación fluida en el equipo, mantener el código actualizado y además llevar a cabo las prácticas ágiles a las cuales estamos acostumbrados.
¿Cuáles serían las herramientas que nos facilitarían esta tarea? A continuación hago una breve reseña de las aplicaciones que utilizamos y cómo nos ayudaron:

Team Foundation Server

Es una herramienta de control de código que no presenta inconvenientes a la hora de trabajar tanto en la red local como desde una conexión de Internet.
También cuenta con un modo de trabajo offline que funciona muy bien si por una de esas casualidades nos quedamos sin conexión.
Team Foundation Server

Live Mesh

Es un sistema de sincronización de datos que nos permite mantener compartidos y actualizados los cambios que vamos realizando en archivos y carpetas de uso conjunto.
Principalmente nos ayudó a mantener actualizada nuestras bases de datos ya que cada uno poseía una copia local (solo de las que necesitaba) y era indispensable algún medio que nos permitiera aplicar los cambios realizados por otros miembros del equipo.
El procedimiento que seguimos fue el siguiente: Cuando realizábamos alguna modificación creábamos un script de actualización. Estos scripts se iban colocando numerados en una carpeta compartida de cada proyecto, donde además teníamos un documento con un registro de las actualizaciones que había corrido cada uno. Luego, para saber si necesitábamos actualizar la BD, sencillamente entrábamos a esta carpeta y verificábamos hasta que script habíamos corrido y de haber nuevos scripts a continuación de éste, ejecutábamos los que nos faltaban.
Pronto va a ser reemplazado por la nueva versión de Windows Live Sync.
Live Mesh

Scrumy

Esta aplicación web hace las veces de Task Board permitiéndonos realizar el seguimiento de nuestro sprint virtualmente. Realmente es muy fácil de usar y posee una versión gratuita con las funcionalidades necesarias. La única desventaja es que no podemos agregar La columna del medio.
Pizarra Virtual:
Scrumy
Scrumy

Google Docs:

La posibilidad de que varias personas puedan editar un documento al mismo tiempo convierte a esta aplicación en una excelente herramienta para trabajo distribuido.
En nuestro caso, nos sirvió muchísimo a la hora de hacer las retrospectivas de cada proyecto. Para hacerlo utilizábamos una planilla en la cual podíamos escribir todos, y que además tenía unas columnas adicionales para realizar la votación.
Retrospectiva en Docs: Retrospectiva
Google Docs

Skype:

Si bien no hace falta ninguna presentación, debo decir que esta aplicación se ha vuelto fundamental en nuestras vidas a la hora de comunicarnos mediante voz, mensajería instantánea y video. Resulta de gran utilidad por ejemplo a la hora de realizar la reunión diaria.
Skype

Yuuguu:

Esta herramienta nos permite compartir escritorio con varias personas al mismo tiempo, e inclusive ceder el control de Mouse y teclado. Como punto interesante quiero añadir que la persona que se conecta a nuestra computadora puede hacerlo desde cualquier navegador sin instalar la aplicación.
Yuuguu
Seguramente habrá muchas más herramientas que se puedan explorar (sobre todo las que no son específicas para desarrollar) y que no conocemos. Lo importante es que cada equipo incorpore aquellas con las que se sienta más cómodo en cada caso. Para esto resulta muy valioso el conocer experiencias de otros en el tema. Cualquier intercambio en este sentido es siempre muy bienvenido !!

Leer más...

Trabajo distribuido

martes, 10 de agosto de 2010

Durante el mes de Julio del año pasado tuvimos la oportunidad de empezar a experimentar con esta modalidad de trabajo. Si bien la idea rondaba desde hacía tiempo por nuestras cabezas, todavía no habíamos tenido motivos suficientes como para tomar el riesgo de enfrentarnos a este terreno desconocido.

Lo que verdaderamente nos dio el impulso final fue el brote de Gripe A que por ese entonces estaba en su punto más alto. Siendo que varios de nosotros (entre los cuales me incluyo) pertenecíamos al grupo de riesgo, surgía la necesidad de desarrollar medidas preventivas. Entonces, con el objetivo de abogar por nuestra salud, y de paso aprovechar la oportunidad para probar que tal nos iba trabajando de forma remota , tomamos la decisión de replegarnos todos con nuestros equipos hacia nuestros respectivos hogares. Sólo una persona quedó en la oficina haciendo un poco de auxiliar en caso de que surgiera cualquier necesidad.

Mi experiencia

Debo decir que al principio me costó algo la adaptación, sin embargo a los pocos días ya me sentía como “en casa”. Realmente la tecnología con la que contamos hoy en día nos otorga una gran flexibilidad a la hora de trabajar.

Enfocándonos en la calidad de vida, quiero decir que el hecho de evitar las complejidades que se nos presentan camino a la oficina (como el tráfico) es una experiencia más que grata. Esto sin mencionar el tiempo y dinero que nos ahorramos.

Durante todo el mes trabajando en mí en casa sufrí algunos desperfectos técnicos. Afortunadamente como contamos con un buen servicio técnico los pudimos solucionar rápidamente, por lo tanto les recomiendo tener este tipo de seguridad a su disposición.

Los Resultados

Luego de un mes trabajando fuera de la oficina hicimos una evaluación de cómo nos había ido. Los resultados en general fueron bastante positivos:

  • Pudimos mantener sincronizados código y bases de datos sin demasiado esfuerzo.
  • Comprobamos nuestra flexibilidad para trabajar en equipo .
  • Se notó una gran autonomía para administrar los tiempos individuales con responsabilidad.
  • Logramos sostener la productividad.
  • Ahorramos tiempo y dinero en viajes.

En cuanto a lo negativo, creo que una de las cosas más importantes a destacar es la pérdida de la comunicación cara a cara.

Pienso que uno de los ingredientes principales que nos permitió obtener buenos

resultados donde otros fallan, es que hace tiempo que venimos trabajando juntos.

El hecho de que nos conozcamos y que estemos acostumbrados al trabajo en equipo hace que tengamos un lenguaje común. Es mucho más fácil lograr la resolución de un problema cuando las partes involucradas hablan el mismo idioma.

Trabajo Distribuido Hoy

Ahora bien, si esta experiencia nos dio tan buenos resultados cabe preguntarse ¿Por qué no adoptar esta modalidad de trabajo siempre y trabajar todos desde nuestros hogares?

En una empresa como la nuestra, donde mantener el espíritu de equipo y la identidad son valores muy importantes, esto sería difícil. Sin embargo, vimos que podíamos aprovechar esta metodología para los casos en los que nos es más útil y necesario.

Por ejemplo, uno de nuestros compañeros dentro de unos días va a ser padre, y más alla del tiempo contemplado para ello, va a trabajar durante unas semanas desde su casa ya que creemos que es importante que este cerca de su familia. Lo mismo se da para otros casos personales donde un día a la semana o cada 2 ó 3 semanas alguno de nosotros hace trabajo remoto.

Mirando al futuro

Evidentemente esta modalidad está totalmente instalada entre quienes nos dedicamos al software, modificando la calidad de vida de quienes la practican. Me parece importante señalar que para aprovechar los beneficios de la misma y lograr que este cambio sea positivo, no debemos olvidar lo valioso de poder salir de nuestras computadoras y ensayar distintas soluciones entre varios frente una pizarra, experimentar las virtudes de programar de a dos (de la forma” tradicional”) o simplemente compartir una charla extra laboral mientras nos tomamos una taza de café.

Leer más...

Model View ViewModel

lunes, 26 de julio de 2010

En un mail reciente de MSDN apareció un artículo que toca un tema de diseño interesante.
Y es el patrón Model-ViewModel-Model, en el artículo se hace referencia a su implementación en WPF/Silverlight, sin embargo es un tema con el que seguramente muchos se topen al incursionar en Asp.Net Mvc, y en realidad es imposible de esquivar en cualquier implementación de MVC, ya sea en Asp.Net, WinForms, Ruby o Haskell.

ViewModels

Cuando trabajamos con un modelo MVC, especialmente si elegimos algún mecanismo de DataBinding entre M y V (y en un sentido amplio de la palabra consideremos los templates (como las vistas de Asp.Net Mvc) como un caso particular de DataBinding), resulta inmediato que cualquier aplicación que escape de lo elemental necesita algun tipo de transformación entre un Modelo y su Vista, ahi es donde llegan al rescate los ViewModels.

Para hacerlo menos abstracto, pongamos un ejemplo, imaginemos que nuestros amigos de Facebook® quieren construir la pagina de perfil de un usuario:


Perfil de Usuario
 supongamos también que utilizan MVC y construyen su "Model" de la siguiente forma:
Nota: el modelo real de Facebook® podría ser más complejo
La duda es cómo obtener los datos resaltados en amarillo en la captura de ejemplo

  • Antigüedad del mensaje de estado ("lunes pasado").
  • Ubicación ("Villa Devoto" en lugar de el GUID correspondiente)
  • Amigos en común (con el usuario logueado actualmente)
Para esto podemos "envolver" estas entidades del modelo con otras más emparentadas a la vista que queremos construir:

Estas clases extienden a las anteriores con campos calculados, listas filtradas, consolidaciones, u otro tipo de transformaciones sobre el modelo original.
Para ilustrar ésta sería una versión (muy naive) de la nueva propiedad "CommonFriends" en UserVM:

public IList<UserVM> CommonFriends        {            get            {                return this.Friends                    .Where(f => f.Friends                      .Any(ff => ff.UserID == User.CurrentUserID))                    .ToList();            }        }

Si usted ya estuvo agregando este tipo de campos calculados y transformaciones, y se sentía culpable por haber violado la prístina pureza de su modelo MVC


 siéntase liberado de la culpa!, esto ya tiene nombre y se llama ViewModel!

Separación Model-ViewModel-Model

Por supuesto en esto podemos imaginar un gradiente de creciente complejidad:
  • Propiedades agregadas directamente a las entidades de nuestro modelo
  • Algunas clases nuevas y propiedades agregadas a entidades que descienden de las de nuestro modelo
  • Una capa de ViewModels que se interpone y separa completamente View de Model.
Volviendo un poco al principio, el artículo de MSDN trata sobre la última opción, implementada como assemblies separados para View, Model y ViewModel, en el que no existen referencias entre View y Model.

Véase este gráfico explicativo que tomé prestado de un artículo que resume muy bien el tema

 

Rápidamente puede verse el problema burocrático en que nos pone este enfoque, ya que implica tener para casi todas las clases del modelo, una equivalente en ViewModel, con wrappers para todas las propiedades visibles. Imagínense la flagrante violación al principio DRY que supone crear páginas y páginas de código como este:

public string Fullname        {            get            {                return InnerEntity.Fullname;            }            set            {                InnerEntity.Fullname = value;            }        }

Tiene que haber algo mejor!


Dynamic Proxies

Como dice la máxima "El mejor código es aquel que no se escribe", y el artículo al que hice referencia propone generar estos ViewModels como proxies dinámicos, implementar esos "gets" y "sets" automáticamente con el nuevo tipo dynamic en .Net 4.0, un poco de Reflection y unos atributos muy elegantes para declarar dependencias entre propiedades (ej: Edad <-depende de-> FechaDeNacimiento).

Existen también librerías muy famosas para la creación de proxies dinámicos (que funcionan con .Net 2.0), como por ejemplo las que son usadas en NHibernate (para crear proxies que soporten lazy loading):

que hacen fácil agregarle a estos proxies interceptores en getters y setters (u otros métodos) que implementen notificación de cambios, logging, autorización y otras cosas por el estilo.

Y finalmente...KISS! es importante recordar que puede resultar más que suficiente con mantener las clases en el modelo accesibles a las vistas, y las clases "ViewModel" mezcladas con el "Model", o separadas simplemente por namespace.

Leer más...

Sitecore, otra opción que ofrecer

miércoles, 7 de julio de 2010

Algunas semanas atrás, uno de nuestros clientes más importantes, nos invitó a participar junto con otros proveedores de un curso intensivo de una semana sobre Sitecore.
Sitecore es un CMS que proporciona software de gestión de contenidos web y portales a organizaciones que requieran funciones empresariales, integración y escalabilidad a la hora de administrar sitios web.

Sitecore fue desarrollado en Dinamarca, y tiene su mayor mercado actualmente en Estados Unidos y Europa. Nuestro cliente vio interesante, la posibilidad de que sus proveedores de mayor confianza, se puedan instruir en esta herramienta para que en el futuro los acompañen en la integración de Sitecore con otras aplicaciones, puedan agregar nuevas funcionalidades o colaboren en la implementación de la herramienta.

Como en Tercer Planeta estamos acostumbrados a realizar nuestros propios desarrollos, la primera reacción a la invitación fue “y no sé, ¿te parece que tengamos que aprender Sitecore?”, pero rápidamente comprendimos que la mejor respuesta a esa pregunta con un , “claro que sí”, y hoy en día vemos los beneficios de haber participado en ese encuentro.

Más allá que nuestro fuerte esté en los desarrollos a medida, siempre es enriquecedor poder conocer cómo otros pueden encarar una determinada solución. En este caso puntual, Sitecore nos pareció un producto muy completo, que tiene cubiertas muchísimas funcionalidades, muchas de las cuales todavía no pudimos explorar, pero en las que sí pudimos indagar descubrimos que están resueltas de manera muy diferente al enfoque que le hubiéramos dado nosotros, simplemente porque fue pensado por otras personas, en otro contexto, con otra experiencia y otras costumbres.

Con lo cual la posibilidad de poder salir, tomar distancia de nuestros tareas diarias, y ver cómo piensan otros, nos resultó más que interesante.

El curso fue dictado por Craig Nelson, un instructor técnico especializado en Sitecore, que viajo especialmente desde Estados Unidos. Cada día estaba orientado a diferentes perfiles (Usuarios Finales, Diseñadores, Desarrolladores, etc.), constaba de partes teóricas y prácticas, las cuales resolvíamos en grupos, esta interacción con otros colegas fue también una experiencia que valió la pena.

Este curso nos sirvió para conocer una nueva herramienta, y fundamentalmente para ver otra forma de hacer las cosas, e independientemente del uso que la vayamos a dar en el futuro, hoy en día, sentimos que tenemos una posibilidad más, otra opción que ofrecer, o tener en cuenta, y eso creo que es lo más importante, para nosotros y para nuestros clientes.
Leer más...

Cómo entendemos el crecimiento

lunes, 5 de julio de 2010

Cuando en diciembre del 2009 nos reunimos con Jose a definir los objetivos del 2010 decidimos que teníamos que poner el foco en madurar.

Pero, qué significaba en ese momento “madurar” para nosotros ? Para el tamaño de organización que tenemos y por los lineamientos que seguimos, lo que buscábamos era lograr un crecimiento de la empresa pero no medido en este caso en cantidad de integrantes o en monto de facturación, sino en base al crecimiento profesional y desarrollo personal de todos los integrantes del equipo de Tercer Planeta.


Help, I need somebody!

Para quienes no somos especialistas en coaching y tenemos un perfil más técnico, el objetivo se presentaba como un gran desafío y sabíamos también que nos embarcábamos en un trabajo de largo plazo que implicaba grandes cambios individuales y en el grupo.

Estaba claro que para poder llevar a cabo esta tarea necesitábamos contactar a especialistas en el tema y fue así que acudimos a Pablo Fondevila y su empresa “Nuevas Miradas en Organizaciones”, quien junto con Carola Herrscher y Marisa Bergés se dedican al Coaching Ontológico . Con ellos empezamos a transitar este camino desde hace 6 meses.


Algunos caminos a seguir

Uno de los aspectos que comenzamos a abordar es tratar de lograr una convergencia entre la vida personal y la laboral ¿cómo pensar que con la cantidad de horas que compartimos en la oficina ambos entornos marchan cada uno por un “carril exclusivo” sin tocarse en ningún momento?
Es lógico entender que estas dos “vidas” se cruzan en varios puntos pero no nos resultaba tan lógico hacer visible y poner un esfuerzo claro y público en juntarlas y complementarlas.


Y para qué querríamos hacer esto? Una de las respuestas que encontramos a esta pregunta es que creemos que la realización de las personas debe ser algo integral, el desarrollo personal y profesional implica poder mostrar los logros, tomar nuevos compromisos, cerrar etapas, explorar nuevos caminos, descubrir y explotar nuestras habilidades.

Por otro lado, aceptar la influencia que las emociones tienen en nuestras vidas es fundamental para entender algunos comportamientos: por ejemplo, aclarar que estamos viviendo un momento difícil o que tenemos algo importante que resolver puede evitarnos conflictos de comunicación si encontramos un ámbito donde nos sintamos cómodos para declararlo y los demás entiendan el por qué de ciertas actitudes.

Entender cuán valioso es el esfuerzo de alguien por terminar una carrera o por emprender nuevos retos, por ejemplo, nos anima a fomentar ese tipo de logros, que sin duda, redundarán en valor para los objetivos de la empresa.

Cómo hacer entonces para acercar estos dos mundos y lograr que se retroalimenten ? O que el trabajo sea un medio más a través del cual alcanzar objetivos personales ?
Cómo hacer que la "vida de la oficina" no genere trabas en la vida privada ? O que la vida privada (logros, alegrías, tristezas) puedan ser, de alguna manera, compartidos, apoyados y comprendidos por la empresa?

Estas fueron algunas de las dudas que empezaron a surgir. Dudas que, gracias a las herramientas que nos van dando quienes nos acompañan (talleres, entrevistas individuales periódicas, consejos para la organización de eventos internos y externos, etc.), empezaron a disiparse.

Puede asombrarnos pensar que con pequeños cambios o con la creación de ámbitos de discusión de cosas simples y concretas, es absolutamente posible y realizable encarar el tema.

De la misma manera las charlas individuales para desarrollo personal nos están abriendo los ojos a nuevas posibilidades de solución de conflictos, de aprovechamiento de las capacidades de cada uno, de alineamiento con los objetivos y visión de la empresa, de comunicación, de roles, etc.


Esfuerzo vs. Beneficios

Según mi opinión, el mayor desafío en este emprendimiento está en saber incorporar y mantener estos valores. Lo cual implica un trabajo de replanteo individual, de delegación de tareas, de acompañamiento, de promoción de la creatividad, de generación de espacios de intercambio, entre otras cosas.

Creo que el entender que estos procesos implican pensar a largo plazo, esfuerzo y modificaciones en la mentalidad, en las costumbres, en las estructuras y en la mirada con que enfocamos las cosas, es una de las principales claves para obtener buenos resultados.

Ahora, sin dejar de lado un enfoque más “empresario”, qué beneficios veo en estos cambios en relación con la organización y la productividad ?

• Mayor compromiso de todos
• Mayor motivación
• Mejoramiento del ambiente laboral
• Mayor confianza entre los miembros del equipo
• Mejoras en la comunicación
• Hacer que los objetivos y la visión de la empresa sean sostenibles en el tiempo

Me animo a decir también que todo este “movimiento” trasciende los límites de la empresa y repercute en la relación con nuestros clientes, quienes, en definitiva, se benefician con los resultados que un equipo de trabajo motivado y “en sintonía” es capaz de producir.


Vale la pena?

Considero que para empresas como la nuestra, donde el capital humano es considerado uno de los puntos más importantes, la inversión en este tipo de emprendimientos está más que justificada y muestra sus frutos en muchas áreas.

Finalmente, creo que para “poner a rodar la maquinaria” en todo esto, el principal motor es ver y reconocer la importancia que tienen estas cuestiones en nuestra vida cotidiana, cualquiera sea el carril por el que marche.
Leer más...

¡Qué comience la sesión!

martes, 29 de junio de 2010

Resulta común que durante el almuerzo o en esos 5' que lleva batir el café o preparar el mate surjan temas o ideas interesantes que son para "discutir entre todos", o al menos entre muchos; y, por lo general, se hace difícil buscar y encontrar el tiempo necesario para hacerlo, por lo que esas ideas quedan sin transmitir ni impulsar.
Esto nos sucedió a nosotros, hemos de reconocerlo. Pero encontramos la solución y, como era lógico, la misma surgió en esos momentos de "recreo laboral".
La propuesta fue tener reuniones cortas para charlar y debatir acerca de diferentes temas. Así surgió nuestro "Cabildo Abierto", pensado como un espacio en el que se pudieran plantear problemas o inquietudes, discutir soluciones, propuestas o acciones a tomar y llegar a alguna conclusión con una solución rápidamente aplicable.

El nombre elegido no fue al azar, ya que combina el nombre de la Avenida en la cual está nuestra oficina con el llamado a debate mediante la participación activa y sin límites de cualquier integrante de Tercer Planeta (3P) que quiera hacerlo.

¿En qué consiste?
El término Cabildo Abierto no es nuevo, surge en la época del Virreinato del Río de La Plata en la cual algunos pobladores se reunían para tratar diversos temas.

Nuestro Cabildo Abierto consiste en hacer sesiones para debatir temas propuestos por los integrantes de 3P. Cada uno, al tener un tema a tratar, anota un título representativo en una Wiki. Fue designada la figura de moderador quién es el encargado de seleccionar 2 o 3 temas propuestos para debatir en la siguiente sesión, estos temas pueden estar conectados o no; la particularidad de ellos es que el debate no debería llevar mas de 1 hora.

Una vez seleccionados los temas, se proponen días y horarios (es deseable mas de 2 opciones para elegir) y cada interesado en participar se anota según su conveniencia. Aquel día-horario que tenga mas participantes será el día elegido para sesionar. Es fundamental que aquella persona que propuso el tema asista a la sesión ya que es la encargada de presentar el tema, impulsar el debate y anotar las conclusiones.

Al comenzar la sesión, se expone cada tema, se lo discute y, al dar cierre al debate, se anotan las conclusiones propuestas en la Wiki. En caso de requerir un seguimiento, la persona que propuso el tema tendrá la responsabilidad de hacerlo.

Anotando temas
Los temas a proponer pueden ser muy variados, ellos surgen de la motivación personal de mejorar algo que vemos y sentimos puede ser mejorado o revisado. Por supuesto dado que cada persona tiene al respecto una visión distinta, un enfoque distinto, esto es lo que enriquecerá la gama de tipos de temas propuestos.

Se pueden proponer temas que traten asuntos relacionados con la metodología de trabajo o con cuestiones técnicas del desarrollo. También pueden sumarse aquellas cuestiones que tienen que ver con la convivencia o el espacio físico en el que nos encontramos. En definitiva, vale anotar cualquier tema que cada uno quiera tratar en una sesión de Cabildo Abierto.

Nosotros, en particular, hemos presentado diversos temas. Algunos de ellos fueron:

  • Cómo manejamos el Collate en SQLServer?
  • Timeboxing (como afecta la calidad, como tenerlo en cuenta en la planificación, como prever y manejar imprevistos, etc)
  • Equipar lo necesario para poder hacer reuniones remotas
  • Cómo mejorar nuestra relación con el cliente?
  • Cambiar las cortinas
por citar algunos títulos.

Conclusiones
Es importante saber que existe un epacio en el que se puede proponer y accionar esas propuestas. El Cabildo Abierto intenta ser eso precisamente: un espacio en el cual se planteen y canalicen las inquietudes de todos y se busquen las respuestas y soluciones en forma conjunta.
Leer más...

HTML5, un paso más cerca

jueves, 18 de marzo de 2010

Html5: Html para aplicaciones web

Desde hace mucho tiempo, oímos culpar de los problemas intrínsicos de las aplicaciones web, a la naturaleza “document-oriented” de la web. La web fue pensada originalmente como una red para compartir documentos “hipervinculados”, y no como plataforma de aplicaciones distribuídas. De hecho fue éste el argumento expuesto por Google en forma de historieta para lanzar Chrome.

Para subsanar esta brecha surgieron una gran variedad de tecnologías, como javascript, Java Applets, Ajax, Flash, y más recientemente Google Gears, Java FX y Silverlight con la intención de crear en los browsers lo que se conoce como Rich Clients, clientes que permitan una experiencia de usuario similar a la de una aplicación de escritorio, con todas la ventajas de la web.

Sin embargo en todo este tiempo, el “poder legislativo” de la web, la W3C, no se quedó de brazos cruzados, y como es de esperar, respondieron con un estándar, tomándose su tiempo. La respuesta de la W3C fue: HTML5

HTML5 traerá muchas novedades, pero lo importante, la idea que está detrás de la mayoría de ellas, es la creación de aplicaciones web “ricas” en nuestros browsers. Para muestra basta un botón:

  • Graficos vectoriales, animaciones y efectos visuales más avanzados
  • Almacenamiento local en el browser, no sólo como diccionarios, también en forma de bases de datos SQL, y otras facilidades para aplicaciones “offline/online”
  • WebWorkers, tareas asincrónicas, y un sistema de mensajería entre ellas.
  • Navegación Ajax
  • Streaming de audio y video
  • DOM Events, los elementos de un documento html, expondrán una serie eventos (ej: div.resize)
  • Drag & Drop
  • Tags semánticos asociados a aplicaciones como: <progress>, <meter>, <command>, <datalist>, <output>, y nuevos tipos de campos para formularios (<input>) como “datetime”, “range”, “search”, etc.
  • varios etc.

A esta altura, resulta evidente que tener soporte para todo esto, de forma nativa en HTML, se ve como una amenaza para todos los que proveen estos features actualmente mediante plugins, como Flash, Java FX, Silverlight y otros.

HTML5 todavía está en pañales, y se acerca lentamente, sin embargo la mayoría de los browsers ya soportan varios features de HTML5.

IE9, Podría Microsoft estar suicidando Silverlight?

Con la salida de IE8, Microsoft empezó a soportar algunos features de HTML5, sin embargo este era muy limitado, y con la ausencia del elemento <canvas> que permite la inclusión de gráficos vectoriales, se especuló sobre una estratégica defensa de Silverlight.

Sin embargo, con la llegada de IE9 están anunciando un soporte para HTML5 mucho más completo, tanto que publicaron una pagina para probar entre otras cosas el soporte HTML5 de IE9 (incluyendo animaciones y gráficos vectoriales con aceleración por hardware).

Y a esto se suma un nuevo engine Javascript, que pretende ponerse a tiro con el resto con benchmarkings prometedores. Esto me recuerda un comentario sobre el futuro de Javascript de Martín Salías.

Para los que trabajamos con .Net surgen ahora dudas existenciales sobre como afectará esto el futuro de Silverlight.

Sin duda la familiaridad del framework .Net, C#, y la integración con VisualStudio son la panacea para los desarrolladores que ya trabajamos con .Net, sin embargo, ¿Qué features realmente distintivos tendrá Silverlight para los usuarios?

Gráficos 3D, Out-of-browser y Smooth Streaming?

Quizás todavía sea solo futurología, pero la llegada de IE9 nos acerca bastante a la pregunta:

¿Cuál será el lugar que ocupará Silverlight (y otras RIU) con la llegada de HTML5?.

Profecía autocumplida: Google + Apple + Microsoft

Ya no hace falta decirlo, a esta altura, HTML5 será un caso evidente de profecía autocumplida, no sólo por tratarse de un estándar de la W3C, sino por contar con el apoyo de Google (además de incluir soporte en Chrome, decidió abandonar Google Gears, por considerarlo un subset de lo que HTML5 proveerá y creo una versión HTML5 de YouTube), Apple (soporte en Safari, que incluirá IPhones que actualmente no soportan Flash), y finalmente Microsoft con la llegada IE9.

Falta aún saber cuanto falta para que sea soportado completamente por los browsers más populares, y para que nuestras IDEs nos permitan aprovecharlo.

Leer más...