viernes, 17 de abril de 2015

Continous Delivery Rsgecu 2015

Continuos Delivery es habitualmente sinónimo de automatización y esta a su vez puede implicar llevar errores a producción de forma automática.

En esta charla descubrimos que Continuos Delivery es el resultado de alterar exitosamente la cultura y los procesos organizacionales utilizando la automatización como una pieza importante para lograr y eficiencia y procesos repetibles.

La felicidad como pilar para lograr efectividad Rsgecu2015

Ser feliz es simple. Solo aprende del pasado, vive el presente construyendo el futuro que deseas, ayudas a los demás, y valora tus logros.

Ser exitoso es simple. Solo busca ser feliz.

Ser una gran organización es mas simple aún. Crea un ambiente en el que las personas sean felices

Esta presentación se relaciona con una entrada que publiqué hace varios meses titulada "The happiness Advantage" y es una versión mejorada de mi presentación para agiles 2014


domingo, 14 de diciembre de 2014

El arte detrás de los incentivos

Históricamente el juego de la zanahoria y el garrote han sido la dinámica preferida para incentivar las buenas acciones y corregir los malos comportamientos en las personas. Si haces algo bueno entonces tienes una recompensa, si te comportas mal entonces obtendrás un castigo. Pero... ¿Esto será suficiente? Quiero iniciar compartiendo una gran experiencia vivida con mi hijo de 6 años.

Los papi puntos


Papi billete
Desde sus 3 años inicié un pequeño juego con mi hijo, llamado los papi puntos. Este tenía 2 grandes objetivos: Enseñarle a manejar el dinero e incentivar las buenas acciones. 

Cada vez que Jerónimo actuaba de la forma esperada era recompensado con uno o varios papi billetes y a su vez estos podrían ser canjeados por cualquier cosa que el quisiera. De manera inversa cada vez que su comportamiento no era el deseado perdía papi puntos. 

A esto complemento el hecho de que los buenos actos eran recompensados con muestras de afecto y los malos, con gritos y regaños.

Pero...

En el tiempo descubrimos que nuestro hijo no quería hacer casi nada a cambio de su preciada recompensa. Incluso entendí que mi actitud cuando el cometía errores era aún mas perjudicial pues con esto no lograba mejorar su conducta, sino todo lo contrario. No me contaba nada por temor a ser regañado. Mi ilusa percepción era que todo andaba muy bien pero la realidad es que tal vez las cosas habían empeorado y ahora no me daba por enterado.


¿Por que pasa esto?

  1. Penalizar el error solo provoca que estos se oculten cuando son cometidos.
  2. Los incentivos aplicados en el contexto inadecuado solo acaban con la motivación interior de la persona para actuar de forma correcta. Es decir no cambian a la persona en sí, solo cambian su reacción ante determinadas situaciones.
  3. Incentivar requiere un fin claro, valores y comportamientos conocidos por reforzar. Va mas allá del ego que nos impulsa a querer controlar la forma en que los demás actúan.
Entendí entonces donde radicaba el problema del mecanismo de incentivos.
  1. Estaba anunciando por anticipado la recompensa obtenida a partir de ciertas acciones ejecutadas. Incluso tenía cosas como: Tender la cama 2 papi puntos, lavar los platos 3 papi puntos, compartir los juguetes con los amigos 10 papi puntos. :-( Ahora que lo escribo incluso suena absurdo.
  2. Estaba premiando las acciones concretas (los resultados), no los valores y comportamientos que consideramos valiosos en nuestra familia, es decir; recompensaba cosas como tender la cama, barrer y lavar los platos; cuando en el fondo lo que quería era recompensar una actitud de colaboración.

¿Que hicimos?

  1. Definir cuales son nuestros valores familiares y las conductas que manifiestan adherencia a estos valores.
  2. Penalizar los errores de conducta y las faltas a nuestros valores familiares. Bajo ninguna circunstancia penalizar un error en el resultado obtenido, pues solo el fallo habilita el éxito posterior.
  3. No anticipar los incentivos ni incentivar acciones concretas sino toda una conducta y la adherencia a nuestros valores familiares. Ejemplo Ahora no recompensamos cosas como lavar los platos, o tender la cama; recompensamos su actitud de colaboración, y no lo hacemos por anticipado sino cuando lo consideramos adecuado.


¿En que se basa todo esto?


Muchos estudios de varios expertos en la materia como Daniel Pink, y Jurgen Appelo han hablado sobre este tema. Incluso hay un pequeño checklist escrito por Jurgen Appelo sobre como manejar los incentivos:
  1. No prometas recompensas previamente
  2. Haz que las recompensas sean pequeñas
  3. Recompensa continuamente, no solo en pequeños periodos de tiempo.
  4. Recompensa públicamente
  5. Recompensa el comportamiento, no los resultados
  6. Recompensa entre pares, no solo a los  subordinados.
Pero al final solo el contexto familiar o empresarial define la forma y los mecanismo de recompensa que mas se ajusten para conseguir los resultados deseados.

Bibliografía

Drive, Daniel H Pink.
Management 3.0 Workout, Jurgen Apppelo

jueves, 16 de octubre de 2014

La felicidad como pilar para lograr efectividad.

El ser humano no es feliz al obtener logros. Al contrario, logra grandes cosas cuando es feliz. De esto se trata esta presentación. De un conjunto de técnicas que te pueden ayudar a ser mas feliz y de como la felicidad beneficia increíblemente la efectividad de las organizaciones. 

Esta presentación se relaciona con una entrada que publiqué hace varios meses titulada "The happiness Advantage".

viernes, 10 de octubre de 2014

Desarrollador de software. Mucho mas que código fuente

Hace poco uno de mis estudiantes me pidió que le recomendara algunas cosas para convertirse en un mejor desarrollador. Esta entrada es mi respuesta para él y refleja mi posición respecto al conjunto de habilidades tanto técnicas como soft skills que conforman un buen profesional del desarrollo de software.

Considero que un desarrollador va mas allá de ser la persona que escribe el código fuente. Es la persona que materializa los deseos de sus clientes. 

Quien programa construye producto y un verdadero producto esta conformado por sus características funcionales, atributos de calidad y los elementos tecnológicos necesarios para construirlo entre ellos la infraestructura y el código fuente. 

Articular todos estos elementos es una tarea compleja que requiere conocimiento y habitualmente este se encuentra segregado en diferentes personas de modo que el trabajo en equipo, y las habilidades de comunicación se convierten en elementos indispensables para cumplir su labor social.

Hacer software es un trabajo de comunidad, de apoyo mutuo y de mejora continua. En torno a esto, construir software que entiendan otros seres humanos es de gran importancia para lograr cultura de colaboración. Las siguientes practicas y herramientas pueden apoyar la necesidad de construir software mantenible.

  • Code Smells: Una recopilación de malas practicas de programación.
  • Patrones de refactor: Un conjunto de soluciones a problemas comunes de mantenibilidad y que pueden ser aplicadas en determinados contextos. Martin Fowler es referente en este tema. Es recomendable visitar la pagina web http://refactoring.com/, leer el libro Refactoring. Improving the design of existing code y Refactoring databases. Evolutionary database design
  • Análisis estático de código: Herramientas que nos apoyan en la identificación de malas practicas de programación. Algunas de las mas comunes son: Sonar Qube, Check Style, PMD, Find Bugs.
  • TDD (Test Driven Design): Es una practica de programación cuya aplicabilidad garantiza código de mejor calidad (Pues todo el el tiempo el código se prueba) y un diseño mas simple.
  • Principios SOLID: Un conjunto de principios que apoyan la construcción de un mejor código fuente.
  • Patrones GRASP: La asignación de responsabilidades es uno de los factores que mas influencia la escritura de código fuente limpio.
  • Clean Code: Un muy buen libro de Robert C. Martin.
  • Coding Standards: Los estándares de codificación varían dependiendo del lenguaje de programación. Acá están los estándares de Java.

Por otro lado hacer código mantenible no garantiza el éxito del producto pues la mantenibilidad se centra en la forma como se estructura el código fuente mas no en los elementos de ejecución. Por esta razón es muy importante conocer conceptos como el manejo de Threads, Programación MultiThread, Agents, profiling, sincronización, Dead Locks, o cualquier otro elemento propio de cada lenguaje o estilo de programación.

También es absolutamente importante que quien escribe código fuente tenga un buen conocimiento en patrones de diseño de cualquier tipo (Siempre serán de gran ayuda) ya sean GOF, JEE, etc.

Hasta ahora tenemos un conjunto de elementos que nos pueden apoyar en la realización de código mantenible y que tenga un buen comportamiento en tiempo de ejecución pero falta algo mas. Aunque no sea su área de experiencia, todo desarrollador debe tener conocimientos aun siendo básicos sobre arquitectura de software, esto le permitirá tomar mejores decisiones y no limitarse a construir con base en la restricciones que otra persona define. En torno a este tema recomiendo un muy buen libro N-Layerd Domain Oriented Architecture Guide with .Net 4.0. Aunque esta basado en arquitectura Microsoft es un muy buen referente de estilos arquitectónicos Layer y puede ser bastante ilustrativo.

Pero aun no es suficiente. Para que todo esto se puede articular en producto construido son importantes dos cosas:
  1. Conocer el paradigma de programación. Ya sea programación procedimental, declarativa, orientada a objetos, funcional o cualquier otra. Es muy común ver programas hechos en scala (Con programación funcional) que en su construcción son orientados a objetos. Al hacer esto no solo se pierde todo el poder del paradigma sino que terminamos construyendo productos innecesariamente complejos.
  2. Conocer el lenguaje de programación: Lenguajes de programación hay muchos, cada uno tiene sus ventajas, desventajas y características especiales que al ser aplicadas de forma correcta nos permiten lograr grandes cosas.
Recomiendo los siguientes libros para quienes quieran profundizar en los conceptos que permiten garantizar software mantenible que promueva unos buenos niveles de servicio con el  paradigma de Programación orientada objetos y Java
Y algo que les permitirá conectarse con el software como producto: Libro Lean Mindset. Ask the rigth Questions

Espero que esta pequeña entrada le sea de utilidad a todos aquellos que quieren hacer del software un producto. Aquellos que quieren ir mucho mas allá del código fuente

viernes, 3 de octubre de 2014

Architectural Kata - Procesamiento de facturas

Kata

Una aseguradora de vehículos tiene un área dedicada a recibir las facturas de las entidades a las cuales acuden los usuarios para hacer uso de los servicios (Talleres, Proveedores de servicio de grúa, etc). En este momento reciben aproximadamente 10.000 facturas al mes las cuales deben ser digitadas en un sistema de información, auditadas y posteriormente pagadas. 

Un usuario puede hacer uso de los servicios solo si tiene una póliza vigente con la entidad aseguradora y dicha póliza cubre el servicio que le van a prestar.



La dirección del área desea que las facturas cuyo valor sea menor a $150.000 puedan ser pagadas de forma automática con el fin de reducir la cantidad de trabajo operativo. Para esto exigirán a las entidades prestadoras de servicio que envíen la información de las facturas a través de archivos de texto, de esta manera se podrán hacer cargas masivas de información, se aplicarán algunas reglas de negocio para determinar que las facturas se puedan pagar y finalmente se realizará el pago a la entidad. 

Resuelva

Diseñe la arquitectura mas apropiada para solucionar esta problemática de negocio. Especifique que asunciones se tomaron para realizar dicho diseño y especifique por que esta arquitectura apoya la estrategia de negocio.

miércoles, 1 de octubre de 2014

DevOps como habilitador de continous delivery

Les comparto una presentación que hice hace poco. Esta habla un sobre DevOps y su gran influencia para lograr procesos de continous delivery de software que dinamicen y apoyen la evolución de los negocios.

Este será el tema sobre el que estaré hablando en Barcamp Medellin 2014 y Agiles 2014